「書ける」から「作らせて、検証できる」へ
これまでエンジニアの成長は、文法を覚え、写経で真似し、やがて自分で書けるようになる、という学習曲線を前提にしていました。AIコーディングが日常化した2026年7月時点では、この前提が崩れています。実装のかなりの部分はAIが生成し、人間の仕事は生成物を読み、疑い、直し、統合することへと移りました。書く速さや書いた量は、もはや実力の中核でも、実力を測る指標でもありません。
これは基礎が不要になったという話ではありません。むしろ計算量・データ構造・HTTP・認証といった土台は、「生成コードのどこを疑うか」を判断するための足場として重要性が増しています。変わったのは学ぶ順序です。抽象論を先に積むのではなく、動くものを作りながら、疑うために基礎へ降りていく。育成プログラムもこの順序に合わせて設計し直す必要があります。
採用・登用の見極めも変わります。「フレームワークXの経験年数」よりも「生成物のどこを疑うかを語れるか」のほうが、これからのエンジニア適性を正確に映します。面接や評価の観点をここに寄せていくことが、育成の出発点になります。
第3層に必要な力の再定義 ― 4つの力
本シリーズでは人材を3つの層で捉えています。AIを「使える」第1層、社内アプリを「作れる」第2層、そして設計・運用まで「回せる」第3層です。実装の手をAIが担う前提に立つと、第3層のエンジニアに残る中核は次の4つに整理できます。採用も登用も、この4つで見るのが実態に合っています。
| 力 | 内容 |
|---|---|
| 設計 | 要件の最小化、信頼境界の設定、アーキテクチャ選定、技術選定。何を作らないかを決める力。 |
| セキュリティ | LLM特有の脅威への理解、認可、出力検証、エージェントのガードレール設計。 |
| 評価・運用 | ゴールデンセットによる評価、監視、コスト管理、インシデント対応。 |
| 検証 | AIが生成したコード・構成を疑い、レビューし、直せる力。第3層育成の最重要科目。 |
注目すべきは、これら4つのいずれもがAIに丸投げできない領域だという点です。そして、業務知識と技術の両方を併せ持つ第3層人材は、採用や外注では得にくい価値を持ちます。だからこそ「育てる」対象として位置づける意味があります。
学び方の転換 ― 「作らせて、読む」を基本動作にする
では具体的に、学び方はどう変わるのでしょうか。写経の現代版は「AIの出力の精読」です。AIに実装させ、生成物を読み、なぜそう書いたかを説明させ、別解と比較する。この一連の動作を反復させることが、新しい基本トレーニングになります。
- 「作らせて、読む」が基本動作。手を動かして書くのではなく、生成物を精読し、根拠を問い、別解と比べる習慣を身につけさせる。
- 要求の言語化が上流に繰り上がる。曖昧な指示は曖昧な実装になる。仕様を構造化して伝える力(設計力の入口)が、コーディングスキルの中核に上がった。
- 小さく作って検証するリズム。一気に大きく生成させず、動く最小単位で「生成→検証→積み上げ」を回す。テスト・段階リリースの規律にそのまま接続する。
- 基礎は「疑うための土台」として学ぶ。順序を変え、作りながら必要に応じて基礎へ降りる。
生成コードを疑う力の育て方
AIの生成コードは流暢で、いかにも正しそうに見えます。しかし実際には、秘密情報のハードコード、入力検証の欠落、存在しない依存パッケージの捏造、SQLインジェクションの余地といった欠陥が、ごく普通に混ざります。この「流暢だが欠陥がある」状態を見抜く力は、座学では育ちません。訓練が要ります。
効果的なのは欠陥探し演習です。意図的に問題を仕込んだ生成コードを教材化し、「このコードには重大な問題が5つ以上ある。レビューコメントを書け」といった課題でレビューさせます。狙いは正解数を競わせることではなく、「動きそうに見える。だからこそ観点を持って読む」という感覚を体に入れることにあります。
レビューには共通の型を持たせます。➀セキュリティ ➁正しさ ➂運用の3観点をチェックリスト化し、PRレビューの共通言語にするのです。例えば、秘密情報がハードコードされていないか、外部入力を検証しSQLはプレースホルダを使っているか(セキュリティ)。空・ゼロ件・巨大入力・文字コードのエッジケースを踏むか、日時やタイムゾーンの扱いは正しいか(正しさ)。何が起きたか追えるログがあるか、半年後の他人が直せる構造か、再実行しても壊れない冪等性があるか(運用)、といった具合です。
さらに、AIによるレビューにも限界があることを体験させます。AIレビューは有用な一次フィルタですが、それだけで通してしまった欠陥の実例を見せ、最終責任は人にあることを体で理解させます。チェックリストは配って終わりにせず、必ず欠陥探し演習とセットで運用するのがコツです。
実プロジェクトOJTと教育の内製化
疑う力も設計力も、研修室だけでは完成しません。本物のプロジェクトで、守られた責任範囲を持って初めて仕上がります。ポイントは「守られた実戦」にすることです。ビルダーが作ったアプリの本格化や共通基盤の部品開発など、失敗しても事業影響が限定される案件を教材案件に指定し、そこで責任を段階的に広げていきます。
- レビューされる側から始め、指摘の意図を説明でき、同種の指摘が減ることを目安にする。
- 小さな設計判断のオーナーへ。チャンク戦略やモデル選定を比較検証付きで提案・決定させ、設計判断記録が書けているかを見る。
- 1アプリの技術オーナーへ。評価セット整備から本番リリース、運用引き継ぎまでを主導させ、運用チェックリストを自力で全項目クリアさせる。
- レビューする側へ。次のOJT対象者のレビューを担当し、欠陥探し演習の教材も更新できるようにする。ここまで来れば「教えられる」段階です。
各フェーズで「設計判断の記録」を書かせるのも重要です。何を・なぜ選んだか、どんな比較をし、採らなかった案は何かまでを1枚に残す。これは属人化を防ぐドキュメント文化の訓練であり、同時に「疑い、検証し、説明する」習慣の訓練でもあります。8領域×4レベルのスキルマップで年次棚卸しをすれば、各人の現在地と次に伸ばす領域(2〜3に絞る)が可視化でき、OJT設計シートに落とし込めます。
最終段は「教えられる人」を育てること
継続的な育成運営を外部依存のままにすると、コストと文脈の両面で持続しません。最終段は教育の内製化です。教えることは最良の学習でもあります。第2層の修了生の優秀者を講師補助から講師へ、第3層人材にはメンター役を正式な役割として割り当てます。カリキュラムや演習・実例集は社内共有リポジトリでOSS的に運営し、教材が属人化しないようにします。そして教える活動そのものを評価・表彰の対象に明記すること。本業の片手間の善意に依存した教育体制は、その人の異動とともに崩壊するからです。外部パートナーの使い方も「代行」からTrain the Trainer(講師の講師)へ段階的に移していきます。