「AIがコードを書くなら、若手は採らなくていいのでは」。開発部門の会議で、この問いが出始めています。

答えは「採らない」でも「今までどおり」でもありません。新人が最初に任されていた実装の仕事がAIに移った分、若手が経験を積む場所と、先輩の教え方を作り直す必要が出てきました。2026年10月時点の公開データは、定義まで確かめて読み分けます。そのうえで、採用・研修・OJTを開発部長やCTO、人事が設計し直せる形まで落とし込みます。

この記事でわかること

  • 2026年10月に話題になった「若手の採用比率が27%から9%に低下」という数字の正しい読み方と、自社に当てはめてはいけない理由
  • AIがコードを書く時代に、若手が身につけるべき力と、その力が育つ条件
  • AIを使う練習と使わない練習の切り分け方（表とチェックリスト付き）
  • 指導側の負担を増やさない、レビュー中心のOJT設計
  • 採用を絞るか、育成を設計し直すかの判断軸

結論から言うと、若手エンジニアの価値は「コードを書く量」から「AIが出した成果を読み、疑い、判断すること」に移っています。育成の設計はこの一点から逆算できます。全部を一度にやる必要はありません。数字の前提だけ最初の章で押さえれば、あとは研修なら「AIを使う練習と使わない練習」、採用なら最後の章から読んでも通じます。

Anthropicレポートの数字は採用比率・在籍比率・稼働時間を分けて読む

話題の3つの数字は、それぞれ測っているものが違います。混ぜて読むと「若手は要らなくなる」という結論に飛びますが、原文はそこまで言っていません。

3つの数字が測っているもの

Anthropicが2026年10月16日に公開した雇用レポートは、同社の社内データが対象です。雇用記録、AI利用、成果指標、従業員調査に加えて、従業員17名へのインタビューを材料にしています。

数字何の数字か注意点
21% → 14%技術部門の従業員全体に占める若手（junior）の割合（2025年初頭以降）在籍している人の比率。人が辞めたことを意味しない
27% → 9%若手の技術職採用の比率分母は技術職の採用者と読めるが、原文に明示はなく、比較期間も本文に明記がない
約6倍2026年8月時点で、従業員が指示したエージェントの稼働時間が、その従業員の人間の労働時間（週40時間と仮定）の約6倍稼働時間であり、成果量や生産性の比較ではない

「21→14%」は在籍比率、「27→9%」は採用比率です。前者は過去に採った人が残っているため、後者より緩やかにしか動きません。

稼働時間の「6倍」は、エージェントが推論とツール利用に費やした時間の合計です。30分を超える待機は除かれ、サブエージェントは合算されています。人間1人が6人分の成果を出した、という意味ではありません。

当協会の読みでは、自社への当てはめは2点で危うい

1つめは、定義の問題です。原文には「若手」の等級・年齢・経験年数の定義がありません。「lower band technical positions」という表現があるだけです。自社の「新卒3年目まで」と同じ集合かどうかはわからない。27%→9%の比較期間も、報道によって「過去1年」などと揺れていて、原文では確認できません。

2つめは、因果の問題です。原文自身が、社内の観察は因果関係を示すものではないと留保しています。採用されなかった若手を既存社員の雇用保護では救えない、という政策面の指摘もあわせて書かれています。

つまり読み取れる事実は、AIの開発現場への浸透が最も進んだ会社の1つで、若手の採用枠が大きく縮んだ、というところまでです。他社が同じ道をたどるとは書かれていません。

外部のデータも「複数要因」の留保つきで読む

Stanford Digital Economy Labの「Canaries in the Coal Mine?」は、22〜25歳でAIの影響を受けやすい職種の雇用が、影響の少ない職種の同年代より19%低いと報告しています。これは2026年8月12日改訂版の数字で、ADPの給与データ（2026年6月まで）に基づきます。それ以前の版は16%と報告していたため、引用するときは版を明記してください。経験者には同様の差が見られません。

同じ著者らは、若手の雇用減はAIだけが要因ではなく、金利などを含む複数要因の結果だと補足しています。ソフトウェア開発者だけに絞った数字は、今回確認した公式ページでは取得できていません。

若手が採用されにくくなっている傾向は、複数の資料で一致しています。ただ「AIのせいだ」と断定できる材料はありません。

AIがコードを書く時代に若手へ求める力は「読む・疑う・言葉にする」

若手に求める力の中心は、コードを速く書く力から、AIの出力を読んで検証し、判断の根拠を言葉にする力へ移っています。理由は2つあります。人間の注意が全体のボトルネックになっていること、そして検証力は放っておくと育たないことが測定されていることです。

速さの上限を決めるのは人間の注意

先ほどのレポートによれば、社内の対話型Claudeセッションの約80%の時間は、人間の入力を待っています。あるエンジニアは、人間が「エージェントのボトルネックになっている」と表現しました。非技術職でも、担当のClaudeが出す成果物をすべて読もうとすると、週の半分ほどの時間がかかる規模だといいます。

AIの稼働が増えるほど、「出力を読み、確認し、次の指示を出す人」の数が足りなくなります。若手の役割は、この読む作業を引き受けることです。

面接でも同じ変化が出ています。同じレポートによると、面接評価でAIツールの活用実績に触れる割合は、2024年に技術職で約5%でしたが、2026年には3倍になりました。技術職で言及が最も増えたのは「自律性と判断力」で、ドメイン専門性への言及は減っています。

AIを使った群は理解度クイズが17ポイント低かった

Anthropicの学習研究（2026年1月公開）は、若手を含む52名に未知のPythonライブラリ（Trio）を使う課題を与えて比べました。結果は次のとおりです。

  • 後日のクイズ平均は、AI群が約50%、手作業群が約67%（17ポイント差）
  • 作業時間はAI群が約2分短かったが、有意な差ではない
  • 差が最も大きかったのはデバッグの問題

この研究はサンプルが少なく、測ったのは短期の理解度だけです。長期の成長への影響まではわかっていません。

ただし、AIの使い方によって結果が分かれた点は、育成設計の手がかりになります。AI群の使い方を6パターンに分類した結果が次のとおりです。各パターンは2〜7名ずつと少人数で、数値は図から読み取った概算です。

使い方のパターン人数クイズの平均スコア
AIに丸ごと委任する4名39%（低スコア群：平均40%未満）
少しずつAIに頼っていく4名35%（低スコア群）
エラーをAIに繰り返し直させる4名24%（低スコア群）
生成後に理解を確認する2名86%（高スコア群：平均65%以上）
コードと解説を同時に依頼する3名68%（高スコア群）
概念的な質問に絞る7名65%（高スコア群）

使うか使わないかより、やり取りの型で理解度が分かれています。次の設計はここが根拠です。

国内の現場でも「理解していない」が最大の悩み

ジョブサポートの調査（2026年3月実施、n=1,004、@IT掲載）は、直近2年以内に新人・若手エンジニアのOJTを担当した人、つまり指導側に聞いたものです。若手本人の回答ではありません。

  • 新人・若手の生成AI業務利用は約9割（積極的に使う40.0%、必要に応じて50.0%）
  • AI生成コードの課題は「仕組みや根拠を本人が理解していない」が61.4%で最多
  • 次いで「要件を読み解けず曖昧な指示になる」が47.5%、「エラー原因を自力で特定・修正できない」が36.6%
  • バグが出たときは「再度AIに依頼する」が46.5%で最多

先の学習研究で低スコアだった「エラーをAIに繰り返し直させる」型と、現場の実態が重なります。若手が育たないのは、AIを使うからではなく、使い方に型がないからです。

どんな力を育てたいかは、次の4つに整理できます。

  1. 出力を読んで、動く理由を説明できる力
  2. 要件を読み解き、AIへの指示に落とす力
  3. エラーの原因を切り分ける力
  4. 判断の根拠を、設計メモやレビューコメントで言葉にする力

AIを使う練習と使わない練習を分けて設計する

育成の設計は、AIを使う場面と使わない場面を意図的に割り振ることから始まります。全面禁止も全面解禁も、型のないままでは学習研究で低スコアになった使い方に偏りかねません。

業務の種類ごとに使う・使わないを決める

下の表は、当協会が学習研究の使い方パターンを業務設計に翻訳した例です。公開されている実証データがあるわけではなく、自社に合わせて調整してください。

練習の種類AIねらい具体例
基礎の筋力づくり使わないデバッグや読解の土台を自力で作る小さなバグ修正、既存コードの読み解き、単体テストの手書き
AIとの協働訓練使う（型を指定）理解確認つきの使い方を身につける実装後に「なぜこの書き方か」をAIに質問させ、回答を要約する
検証の訓練使う（出力が題材）AI出力の欠陥を見つけるAIが書いたコードを、仕様と照らして読み、問題点を3つ挙げる
判断の訓練任意設計の根拠を言葉にする設計案の比較と、採用理由の記録

表の2行目の「型を指定」が肝です。たとえば次のような決まりを新人に配ります。

AIに実装を頼むときは、コードと解説を同時に出させる。生成後に、自分の言葉で処理の流れを3行で説明してから採用する。エラーが出たときは、原因の仮説を自分で1つ書いてからAIに聞く。

経験の浅い人ほど、使わない練習の比率を高めるのが基本です。ドクターズプライムはこの方針で、隔週の「No AI Day」を設け、「learnコマンド」で実装後に理解度チェックの問題を生成してPRに添付する運用を公開しています。No AI Dayによる生産性の低下は、思ったほど大きくなかったと同社は書いています。

新卒研修でAI利用を制限する例も報じられています。シンプレクスは、中身を理解しないまま成果物を出す事例が相次いだため、研修中は利用を制限し配属直前に解禁する形に切り替えたと労働新聞が伝えています。全文は購読者向けで、制限の具体的な範囲は確認できていません。

最初の90日で何を身につけたら合格か

到達目標は「AIなしでできる」ではなく「AIの出力を検証できる」で置きます。次は、そのままチェックリストに使える例です。

  1. 入社30日まで: 既存のコードを読み、処理の流れを自分の言葉で説明できる。AIを使わない小さなバグ修正を、自力で1件完了させる
  2. 入社60日まで: AI生成コードをレビューし、仕様との差分を3件以上指摘できる。エラーの原因仮説を、AIに聞く前に書く習慣がついている
  3. 入社90日まで: 小さな機能の設計メモを書き、採用しなかった案とその理由まで残せる。他の人のPRに、根拠つきのコメントを返せる

評価の観点は、速度や行数よりも「説明できるか」「疑えたか」に置いてください。個人ごとに到達基準を変えず、支援の厚さを変える考え方は、シンプレクスが自社のタイアップ記事で語っています（Business Insider Japan）。

この育成設計の考え方は、AI駆動開発研修の教育設計でも整理しています。

研修を外から導入するとき

社内でカリキュラムを一から作るのが難しい場合は、外部研修で型だけ先に入れる方法があります。AI駆動開発研修では、ハンズオンやディスカッションを通じて、AI駆動開発の基礎から実践、自社のリスク分析やルール検討までを学べます。

OJTはレビュー中心に組み替えて指導側の負担を抑える

OJTの中心は、先輩が隣で書き方を教える形から、若手の成果物を一緒に読むレビューへ移します。AIが実装を肩代わりする分、先輩が教えられる最大の機会はレビューの場になるからです。

若手がレビューを受ける側からレビューする側にも回る

従来のOJTでは、若手は小さな実装を任され、先輩のレビューで直されながら学びました。AIが小さな実装を担うと、この「小さな実装」という練習台が減ります。

代わりに、次の3つの場を意図して作ります。

場やり方先輩の役割
AI出力の読み合わせ若手がAI生成コードを事前に読み、疑問点を3つ書いて持ち寄る疑問の質を見て、足りない観点を足す
判断の言語化設計の選択肢と採用理由を短いメモで残す根拠の弱い箇所に質問する
モブレビュー先輩・若手の複数人で1つのPRを声に出して読む読む順番と疑う観点を実演する

レビュー時の質問は、答えを教えるより「なぜそう書いたのか」を引き出す形に寄せます。ペアプログラミングでも同じです。ドクターズプライムは、答えを与えず思考の言語化を促す質問をペアプロで使っています。

AIが生成したコードのレビューをどう分担するかは、AIコードレビュー導入ガイドで詳しく扱っています。

指導側の約8割が負担増を感じている

OJT担当者の負担は、すでに数字に出ています。先のジョブサポートの調査では、OJTの負担が増えたと答えた指導者が約8割（大幅に増加26.1%、やや増加51.8%）でした。

産業能率大学とHR総研の人事実態調査（2026年10月7日発表、n=320社）は、人事側の悩みを示しています。

  • 「本人がどこまで自分で考えたか確認しにくい」が76.2%で最多
  • 「活用指導が上司・先輩によってばらつく」が69.5%
  • 「生成AIを用いた成果物の妥当性を見極めにくい」が68.1%
  • 見直しの必要性は感じていても、実際に対応した企業は15.0〜19.4%にとどまる
  • 管理職向けの生成AI活用研修の実施は7.7%

詳細は発表資料にあります。調査期間は掲載ページに記載がなく、確認できていません。

悩みの最上位が「どこまで自分で考えたか確認しにくい」であることには納得がいきます。AIが書いた成果物は、見た目だけでは本人の理解度がわからないからです。

負担を増やさないための4つの工夫

指導者の時間は増えないので、レビューを増やすならほかの時間を減らすしかありません。

  • 確認の質問を固定する: 毎回「処理の流れを3行で」「他の案と比べた理由は」「壊れるとしたらどこか」の3問に絞り、先輩が即興で考える負担を減らす
  • AIに一次レビューをさせる: 形式的な指摘はAIに任せ、人間は設計と意図の確認に集中する
  • 理解確認をPRに添付させる: 若手が自分の理解度チェックを書いてから出す形にして、確認の手間を前倒しにする
  • 指導者側を先に教育する: 管理職向けの活用研修は7.7%しか実施されていません。ここを先に埋めると、「指導が先輩によってばらつく」問題を小さくしやすくなります

最後の項目は、地味ですが効きます。指導する側がAIの使い方を知らないまま、若手にだけ「ちゃんと使え」と言っても、基準が揃わないからです。AIが働く前提で、レビューや運用ルールを整える考え方はハーネスエンジニアリングの記事が参考になります。

採用は絞るかどうかより「育てる前提の設計」で決める

採用人数を機械的に減らす判断は、いまの根拠では支えきれません。判断軸は「育てる仕組みがあるか」と「面接で何を見るか」の2つです。

採用を減らす前に確認する3点

Anthropicのレポートでは、AIの影響で採用を減らした管理職は、MLチームで約3分の1、ソフトウェアエンジニアリングのチームで約5分の1でした（2026年4月の管理職調査）。つまり、大半はまだ減らしていません。

自社で採用を絞る前に、次の3点を確認してください。

  1. 数年後に中堅になる層が足りなくなる穴を、どう埋めるか。若手を採らなければ、その3〜5年後に経験者が足りなくなります
  2. 若手の仕事のうち、AIが肩代わりしたのは何か。実装なのか、調査なのか、テストなのか
  3. 残った仕事で、若手が判断の経験を積める設計になっているか

採用を絞った結果、若手が全く入らず、数年後に判断のできる中堅が育っていない。そんな将来は避けたいところです。

面接では経験年数より「説明できるか」を見る

採用基準も、AI前提で見直せます。ポイントは3つです。

  • コードの量ではなく、書かれたコードの意図を説明させる
  • AIを使った実績があるなら、どこで疑い、どう検証したかを聞く
  • 完成物ではなく、判断の分かれ目になった場面を深掘りする

HR総研の調査（2026年8月、人事担当202件、若手は新卒5年以内）では、企業が若手に重視する能力は専門知識・技術が43%、コミュニケーションが42%、課題解決が34%でした。AI活用力は2%、デジタルリテラシーは11%にとどまります。若手育成にAIを使う企業は4割を超えるものの、本格活用は1割に届きません（調査詳細）。AI活用力を能力として求める企業は、まだほとんどありません。

だからこそ、採用段階で「AIの出力を読む力」を見ている会社は差がつきます。人事が育成を設計する手順はAI人材育成を社内で始める手順、組織全体で教育を回す考え方はエンジニア組織のAI教育を6ヶ月で定着させる方法に整理してあります。

よくある質問

AIが書く時代でも、新人エンジニアを採用する意味はありますか？

あります。AIの出力を読み、検証し、判断する人の数がボトルネックになっているからです。ただし新人に任せる仕事は、実装中心から検証・レビュー中心へ変える必要があります。

新人にはAIを使わせない方がいいですか？

全面禁止も全面解禁もおすすめしません。基礎を自力で練る時間を残しつつ、AIを使うときは「解説も同時に出させる」「生成後に自分の言葉で説明する」といった型を指定してください。

Anthropicの「採用比率27%→9%」は日本企業にも当てはまりますか？

そのまま当てはまるとは言えません。同社内の数字で、若手の定義も比較期間も原文に明記がなく、原文自身が因果関係を示すものではないと留保しています。

OJT担当者の負担が増えて困っています。何から手をつけますか？

確認の質問を固定し、形式的なレビューはAIに任せるのが最初の一歩です。あわせて、指導者向けのAI活用研修を先に実施すると、指導のばらつきを抑えやすくなります。

若手の理解度は、どう測ればいいですか？

成果物ではなく説明を見ます。処理の流れを自分の言葉で話せるか、別の案と比べた理由を言えるかを、PRやレビューの場で確認してください。

まとめ

最初の一歩は、新人1名のOJTから「AIを使わない練習」と「理解確認つきでAIを使う練習」を週に1回ずつ割り当てることです。ルールは、コードと解説を同時に出させ、生成後に自分の言葉で3行説明させる、の2つで足ります。

次にやるのは、レビューの質問を3つに固定することです。指導者全員に同じ質問票を配ると、指導のばらつきを抑えやすくなります。採用の議論は、その運用が数カ月回ってから、若手の仕事のどこがAIに移ったかを見て決めても遅くありません。

この記事でも触れられなかったのは、AIエージェントが増える環境で、新人が「人間の注意」をどれだけ持ち込めるかという長期の問題です。測定方法がまだ定まっていないので、まずは説明できる力を指標にして観察を始めてください。

AIが書いた成果物を検証できる若手を育てたいなら、AI駆動開発研修で、基礎から実践までを学びながら社内の型づくりを始められます。

次に読みたい関連記事