AI時代の新人育成：禁止から「制御ハーネス」による自律的成長への転換

多くのエンジニアリング組織が直面している「AIによるコード生成の功罪」という難問に対し、いえらぶGROUPの和田氏が提示したアプローチは、単なる禁止令を超えた極めて実践的な解法だ。かつて新人にAI利用を一時禁止した際、彼らが直面したのは「なぜそのコードを書いたのか」という問いに答えられないという、エンジニアとして致命的な思考停止状態だった。AIが生成したコードをそのまま貼り付け、コメントが800件を超えてもなお本質的な理解に至らないという状況は、まさに現代の新人教育におけるデッドロックである。しかし、禁止という強硬手段は運用コストを増大させ、属人化を招く。そこで開発されたのが、新人AI制御教育ハーネス『newcomer』である。

このハーネスの核心は、AIを「禁止」するのではなく、習熟度に応じて「権限を段階的に解放する」というゲーミフィケーションの導入にある。社内スキルマップの5軸（PHP、JS、MySQL、HTML・CSS、AI利用）に基づき、ランク0から3+までを定義。ランク0〜1ではコードの代筆を一切禁じ、AIの役割を「調査・説明・レビュー・誘導」に限定する。この仕組みは、単なる制限ツールではない。AIが「方針」「擬似コード」「最小スニペット」という順序で段階的に誘導することで、新人が自ら考え、手を動かすプロセスを強制的に組み込んでいるのだ。これは、スパゲッティコードを量産する前に、設計の基礎を叩き込むための極めて合理的な「教育的制約」と言える。

特筆すべきは、このハーネスがClaude CodeのPreToolUseフックやCLAUDE.mdを駆使し、機械的に制御をかけている点だ。これにより、マネージャーの気分や目視に頼っていた運用がシステム化された。新人が「なぜこのコードが必要か」を理解していない段階で、AIが安易な解決策を提示することを防ぐ。この「あえて不便を強いる」設計こそが、エンジニアとしての基礎体力を養うための現代的な処方箋であると私は確信している。

『newcomer』の導入で最も驚かされたのは、新人がこの制限を「レベル上げ」としてポジティブに捉えたことだ。数値が可視化され、ランクが上がると使える機能が増えるという構造は、まさにRPGのステータス画面そのもの。期日前に自ら習熟度チェックを要求する新人が現れたという事実は、AIを「魔法の杖」としてではなく、自らのスキルを証明するための「対戦相手」として認識し始めた証左である。この心理的変化は、受動的なコーディングから能動的な設計への転換を促す強力なエンジンとなっている。

具体的には、以下のようなランク別の制御が行われている。

興味深いのは、AIが「代筆」を拒否した際に、新人が自ら回避策を模索したり、制限の趣旨を理解した上で境界を主張したりする場面が生まれたことだ。例えば、設定ファイルの改行コード修正をAIに依頼した際、AIが「PHP軸がランク1のため修正不可」と返すと、新人は「これは実装ではなくツールの復旧である」と論理的に反論した。このやり取りこそが、我々が求めていた「AIを道具として使いこなすためのリテラシー」そのものである。AIが広げた修正範囲を、新人が「ここは不要」と縮小させるという逆転現象も起きている。レビューでバグを指摘されるよりも、AIの提案を覆す回数が増えたことこそが、彼らがエンジニアとして成長している何よりの証明ではないだろうか。

しかし、このハーネスにも課題は残る。和田氏自身が指摘するように、AIが「どのファイルをどう修正するか」を詳細に指示しすぎると、結局は「位置決めと転記」という作業に終始してしまうリスクがある。これは設計の本質をAIに奪われ、人間が単なる「入力インターフェース」に成り下がる危険性を孕んでいる。真の教育とは、AIが答えを出す前に、人間が「調べる・決める・書く・確かめる」という工程をいかに深く体験させるかにある。ハーネスのチューニングは、今後「AIにどこまで使わせるか」ではなく「どの工程を渡さないか」という、より高度な線引きへとシフトしていくだろう。

我々シニアエンジニアが明日から取るべき対策は明確だ。AIを単なる効率化ツールとして放置するのではなく、組織の教育方針をコードとして定義し、AIの挙動を制御する「ハーネス」を自ら構築することである。AIが生成するコードの品質を担保するのは、結局のところ、その背後にある設計思想を理解している人間の目だ。もし、あなたのチームの新人たちが「AIがそう言ったから」という理由でコードをコミットしているなら、それは組織としての敗北である。AIに依存するのではなく、AIを「思考の壁打ち相手」へと昇華させる仕組みを、我々は自らの手で実装しなければならない。

最後に、読者であるあなたに問いたい。あなたのチームでAIが生成したコードは、誰がその責任を負っているのか？ AIが提示する「正解」を疑い、あえて遠回りをしてでも本質的な理解を求めるプロセスを、あなたは仕組みとして提供できているだろうか？ AIという強力な武器を手にした今、我々が守るべきは「コードを書く速度」ではなく、「コードを書く理由を説明できる能力」ではないだろうか。この問いに対する答えを、明日からのコードレビューや育成計画の中に刻み込んでほしい。