生成 AI が書いたコードを新人が理解しているかをどう確かめるか：各社の確かめ方と評価の物差し

来年 4 月に新卒が配属されるチームでは、AI コーディングツールを使わせることがもう前提になりつつあります。研修でどう使わせるかは、各社の方針を AI を新人に使わせるか、使わせないか で並べました。この記事はその次の問いを扱います。使わせると決めたあと、新人が書いたコードを本人が理解しているかを、何で確かめるかです。

「AI コーディング 新人 育成」などで検索すると（2026 年 10 月 10 日、編集部が確認）、上位には個人の意見と研修会社の宣伝が並びます。企業が確かめ方や評価の物差しをどう変えたかを並べたものは見つかりませんでした。

この記事では、各社が自分で公開した研修の記録から、確かめ方まで書かれていた 5 社を比べます。最初に断っておくと、5 社の記録はどれも研修期間中のものです。配属後にどう確かめているかを公開した記録は、調べた範囲（索引の 56 社と、この記事の出典）では見つかりませんでした。そこで、研修の型を配属後のレビューに移す部分は、編集部の提案として分けて書きます。

先に言葉を短く説明します。

• PR（プルリクエスト）は、書いたコードをチームの本流に入れる前に、ほかの人に読んでもらうための依頼です。ここでのやり取りがコードレビューです
• Claude Code・Cursor は、指示を受けてコードを書く AI コーディングツールです
• 口頭試問は、書いた答えについて、面と向かって質問して理解を確かめる試験です
• ルーブリックは、評価の段階（S・A・B・C など）ごとに、どんな状態ならその段階かを書いた表です
• EM（エンジニアリングマネージャー）は、エンジニアのチームを預かる管理職です
• 新人はこの媒体では入社 1 年目を指します

受け手の声

まず、新人を受け入れる側と、新人自身が何を書いているかを並べます。

ジョブサポートの調査は、外部研修を販売している会社が行ったものです。調査の対象は、直近 2 年以内に入社 1〜3 年目のエンジニアの OJT を担当したと答えたモニターで、PRIZMA のインターネット調査です。参考として読んでください。

DeNA の新卒チームは、レビューできる人が限られていたので、レビューが滞ったことも挙げています。

理解が見えなくなる理由

編集部の見立てでは、AI を使うと、書けたことと分かったことが、同じ成果物の上では区別できなくなります。動くコードは、本人が理解して書いても、理解しないまま生成させても、見た目は変わりません。TOKIUM の受講者も、AI に書かせたコードを「動いているからヨシ！」で流していると、メンターの口頭のチェックで見抜かれると書いています（TOKIUM）。

この差を測った実験があります。Anthropic が 2026 年 1 月に公開した無作為化実験です。

出典: Anthropic

AI を使うかどうかより、使い方で差が出ています。ただしこの実験は 52 人で、課題の直後のクイズだけを見ています。Anthropic 自身も、直後の成績が長い目で見た技能の伸びを予測するかは分からないと書いています。

エンジニア組織での違い

上の記録で理解の差が出た場所は、レビューと不具合の対応でした。DeNA では理解の差がレビューに出て、レビューが滞りました。ジョブサポートの調査で増加したという答えが多かったのは、指導とコードレビューにかかる時間です。Anthropic の実験で差がもっとも大きかったのは、デバッグでした。

ここからは編集部の見立てです。エンジニアの仕事では、コードが動いてテストが通れば、理解していないことはしばらく表に出ません。表に出るのは、レビューで「なぜ」を聞かれたときと、不具合が起きて自分で直すときです。ここから 2 つのことが言えます。理解は成果物を見ても確かめられず、本人の説明と、変えたら何が起きるかの予測で確かめるしかないこと。そして確かめる場所は、新人が毎日通るレビューに置くのがいちばん無理がないことです。

5 社の確かめ方

索引の 56 社の記述と原典を読み、理解の確かめ方まで原典で確かめられたのは次の 5 社でした。

「−」は、原典に書かれていないものです。書かれていないことは、やっていないことではありません。

TOKIUM はマイルストーンごとに口頭で聞く

TOKIUM の 2026 年度のプロダクト本部研修は、1 か月かけて Rails で Todo アプリを作ります。全 6 段階のマイルストーンがあり、段階をクリアするたびに、メンターと口頭で理解度をチェックします。受講者は、実際に聞かれた質問を 3 つの型に分けて紹介しています（TOKIUM、2026 年 6 月、26 卒の受講者が執筆）。

受講者は「1 問ずつ深掘りされるので、生半可な理解のまま AI に丸投げするのは、正直かなりリスキー」と書いています。そのため、ラーニングモードがあっても、自主的に AI でのコーディングを控える人が多かったそうです。

同じ記事には、経験者の同期 1 人が、変更の差分から「なぜそうしたか」を問う質問を作り、説明できるまでコミット（変更を記録として確定すること）させない Claude Code のスキルを作って配った話も出てきます（会社の決まりではありません）。

GMO ペパボは PR に問いを投げる

GMO ペパボ の 2026 年度の研修では、8 人の受講者が Rails チュートリアルを Claude Code とともに進め、PR を立てました。PR はまず受講者同士でレビューし、そのあと講師がレビューします。講師は、AI が書いて動いただけの状態にならないよう、「このパターンだったらどうなる？」「どうしてこの実装になっているんだろう？」と問いを投げました（GMO ペパボ、2026 年 8 月、講師陣が執筆）。

AI エージェントの開発研修でも、最終発表の評価軸の 1 つを、どんな入力になぜそのツールを使い、なぜその応答になるのかを説明できること（了解性）にしました。

ディップはテストを先に書かせ、配属先でもメンターに確かめる

ディップ の 26 卒研修は 2 週間で、新卒は 6 人です。1 週目の Day 4「ディップ流 AI-DLC 実践」（AI-DLC は、AI を前提にした開発の進め方の呼び名）で、テストを先に書き、AI に実装させ、テストが通るかを確かめ、通らなければ指示し直す演習をします。AI が生成したコードを本当に正しいかセルフレビューし、テスト付きの PR を出すところまでが目標です（ディップ、2026 年 5 月）。

目指す姿は「AI と一緒に開発する」のではなく「AI の出力に責任を持てる」エンジニアです。セルフレビューのチェックリストには、メモリリーク、SQL インジェクション（入力に細工をしてデータベースを不正に操作させる攻撃）、エッジケース（境目や想定外の入力）への対応が挙がっています。

2 週目は配属先のチームに入り、メンターの隣で実際のコードに触れます。5 社の記録のうち、配属先の実際のコードで理解を確かめているのはここだけです。

困ったときの決まりもあります。15 分考え、Slack で質問し、それでもだめならメンターに聞く。本配属は 5 月 1 日で、この 2 週間は研修の一部です。

Speee は説明できるかを自己評価の段階に入れる

Speee が 2026 年に GitHub で公開した研修教材は、AI を実装者ではなく解説者・壁打ち相手と位置づけ、コードの生成を禁じ、説明と理解の検証には使うよう勧めています。期待する状態には「コードを書いた理由を説明できる」「他人のコード（AI 含む）を評価できる」を挙げています（Speee の教材）。

最終課題は、発表・自己評価・相互レビューです。目標は「動くものを作った」状態から「説明できる・評価できる」状態へ進むことです。受講者が自分で付ける自己評価のルーブリックは、次の 4 段階です（表のトレードオフは、一方を取ると他方を諦める関係のこと。最終課題）。

自己評価の項目は、技術理解・設計力・実装品質・説明能力・トレードオフ理解の 5 つです。受講者同士の相互レビューは、これとは別のレビュー用チェックリストで行います。ルーブリックを合否に使うとは書かれていません。S〜C にかかわらず、安全上の必須評価（既知の脆弱性を説明できる、など）を満たさなければ提出を完了にしない、という決まりだけがあります。

フューチャーは書き換えたら何が起きるかを聞く

フューチャー の新人研修では、筆記試験に合格したあと、研修リーダーが試験官を務める口頭試問に合格して初めて、次のカリキュラムに進めます。狙いは「とりあえず書いたら当たった」ではなく、本質的な理解の確認です（フューチャー技術ブログ、2023 年 3 月）。新入社員は年間 100 名以上です（2023 年の記事の時点）。

口頭試問は 1 対 1 です。本人が正解したコーディングテストの一部を取り出し、「コーディングテストで◯◯と書かれていた部分を、△△に書き換えると、プログラムの動きはどう変わりますか？」と聞きます。プログラムを実行すること以外は、何を調べてもかまいません。基準は「相手に説明できるほど理解している」ことです（フューチャー公式 note、2020 年 4 月）。

この方法は AI が広まる前からのものです。いま新人に AI を使わせているかは公開されていません。それでもこの記事で取り上げたのは、調べてよい条件の下でも、動いただけの人は答えにたどり着けない問い方だからです。原典は、コーディングテストで「プログラムが動いちゃった」だけの人は、何を聞かれているのかが理解できず、どれだけ調べても正解にたどりつかないと書いています。

確かめ方の 4 つの型

5 社を、何に答えさせているかで分けると、次の 4 つになります（編集部の整理です）。

表の外に、答えさせる前に一緒に書いて理解をそろえる形もあります。DeNA の新卒チームは振り返りで、不慣れな技術は、知見のあるメンバーがモブプログラミング（全員で 1 つの画面を見ながら書く）やペアプログラミング（2 人で 1 つのコードを書く）を通じて実装しながら知識を共有し、理解の水準をそろえるのが効果的だったと書いています（DeNA Engineering）。会社の決まりではなく、新卒チーム自身の振り返りです。

何をできるようになったと見なすか

評価制度・等級・キャリアラダーを AI 前提で書き換えたと公開した会社は、調べた範囲では見つかりませんでした。物差しとして使えるのは、研修の目標に書かれた言葉までです。それを並べ、確かめるときの問いに変えたのが次の表です。問いの列は編集部の提案です。

出典: GMO ペパボ、ディップ、Speee、MIXI（2026 年 7 月）、サイバーエージェント（2026 年 6 月）

配属後のレビューに移す形

ここからは編集部の提案です。配属後に確かめた公開記録は無いので、効果を示す数字もありません。5 社の研修の型を、配属先のふだんの PR に移すとこうなる、という案です。

PR の説明欄に足す 3 問

新人の PR の説明欄に、次の 3 問を足します。3 問は PR ごとに毎回、本人が書きます。文言の修正や依存の更新だけの PR は省いてよく、時間の表の「週 5 本」もそれを除いた本数です。口頭の掘り下げは週に何本かを選んで行います（下の時間の表）。問いの型は上の 4 つから取っています。

AI に書かせた部分があっても、3 問に自分の言葉で答えられれば出してよいことにします。3 問の答えまで AI に書かせると書面では見分けられないので、週 2 本の口頭が抜き取りの確かめを兼ねます。

答えの判定の例

判定は PR ごとに 1 つです。レビューする人は 3 問それぞれの答えを「答えられた / 一部 / 答えられない」で見て、いちばん低いものをその PR の判定にします。次は編集部の架空の例です。PR は「注文の一覧に、期間で絞り込む機能を足す」、問いは「変えたらどうなるか」です。

「答えられない」PR は、マージ（PR を本流に取り込むこと）を止めて差し戻し、理由を「理解していない」として数えます。週の口頭の枠は待たず、その日のうちに 10 分取って一緒にコードを読み、本人が答えを書き直してからマージします。「一部」のときは口頭で 1 問だけ足して聞き、答えられれば進めます。

使う時間の見積もり

EM がいちばん気にするのは、自分とメンターの時間です。編集部の提案する線は、3 問は毎回書く、口頭は新人 1 人につき週 2 本・1 本 10 分までです。新卒の人数ごとの週の時間は次のとおりです。

前提は、新卒 1 人の PR が週 5 本、3 問を書くのが 1 本 10 分、口頭が 1 本 10 分であることです。「答えられない」が出た週は、その PR 1 本につき 10 分を足します。メンター 1 人が持つのは新卒 2 人分までと仮に置きました。3 問の答えを読む時間は、ふだんのレビューに含めています。自社の数に置き換えてください。

新卒 2 人・メンター 1 人のチームの回し方です。メンターは週に 1 回、新卒 1 人につき 20 分の枠を取り、その週の PR から 2 本を選んで口頭で聞きます。選ぶのは、AI に書かせた部分が多い PR と、その新卒が初めて触った種類の変更です。ふだんのレビューと判定は、メンター以外の人がしてもかまいません。

緩めてよい合図

GMO ペパボでは、必須にしていた受講者同士のレビューについて、受講者から「PRを通じて講師側が身につけてほしいと考えていたスキルはもう掴めたので、ここから先は進捗を優先してレビューを任意にしたい」という提案があり、講師陣と合意して任意に変えました。全員が、昨年の半分の 5.5 営業日でチュートリアルを完走しています。原典は、任意にしたことと日数の因果を書いていません。

編集部の提案する目安は次のとおりです。3 問を書いた PR のうち「答えられた」が 3 週続けて 8 割以上なら、口頭を週 2 本から週 1 本に減らします。さらに 3 週続けば、口頭をやめて書面の 3 問だけにします。逆に、ある週に「答えられない」の PR が 2 本出たら、週 2 本に戻します。3 週・8 割・2 本は編集部が仮に置いた目安で、根拠となる記録はありません。決めるのはメンターと新人の 2 人で、決めたことを EM に伝えます。

反対の根拠

確かめる手順を重くしすぎることには、反対の根拠もあります。Microsoft・Accenture などでの 3 つの実地の無作為化実験（開発者 4,867 人）では、AI のコード補完で完了したタスクが 26.08% 増え、経験の浅い開発者ほど使う率も生産性の伸びも大きくなりました（Cui ほか、2025 年 2 月のワーキングペーパー版）。

この実験は理解を測っていません。Anthropic の実験は理解を測りましたが、52 人と少なく、課題の直後しか見ていません。生産性の伸びと理解の遅れのどちらが長く効くかは、まだ分かりません。

編集部の見立てでは、だからこそ AI を止めるのではなく、確かめる手順を上で決めた線（3 問は毎回書く、口頭は週 2 本・1 本 10 分まで）にとどめ、身についたら緩めるのがよいと考えます。

うまくいっているかを測る

ここも編集部の提案です。最初の 3 か月は、次の 3 つを記録します。

3 つ目は、ジョブサポートの調査で新卒・若手（入社 1〜3 年目）に多かった反応（エラー文を読まずに AI に再質問を繰り返す、根拠を AI に丸投げする）の裏返しです。Anthropic の実験で差がもっとも大きかったのもデバッグでした。

半期の評価面談での使い方

ここも編集部の提案です。3 か月の記録（上の 3 つ）は、半期の評価面談に持っていき、何ができるようになったかを話す材料にします。「答えられた / 一部 / 答えられない」の判定は、そのまま査定の点数にはしません。

理由は 2 つあります。事実として、5 社の段階付けは研修の中のもので、Speee のルーブリックも受講者自身が付ける自己評価で、合否に使うとは書かれていません。評価制度に載せたと公開した会社も見つかっていません。そして編集部の見立てでは、点数にすると新人は答えを整えることに力を使い、「分からない」と言いにくくなります。それでは確かめる意味がなくなります。等級の要件に書くなら、「自分の PR の 3 問に、口頭の掘り下げも含めて答えられる」のように、できることの形で書き、達したかを面談でメンターと確かめるのがよいと考えます。

各社が配属後の記録を公開したら、この記事を更新します。

関連

• AI を新人に使わせるか、使わせないか
• 配属後の新人を誰が支えるか：メンター・OJT トレーナー・EM の分け方
• ジュニアエンジニアは不要か
• 索引の企業ページ: GMO ペパボ / ディップ / Speee / フューチャー / DeNA / MIXI / サイバーエージェント
• 企業が公開するエンジニア研修資料の索引