はじめに — AIで生産性は上がった。レビューは地獄になった
AIコーディングの導入で、開発の生産性は確かに上がった。かつて1日かかった実装が数時間で終わる。ジュニアエンジニアでも、動くものが作れてしまう。
そして、レビューの負荷が跳ね上がった。
こんな場面に覚えはないだろうか。ジュニアから届いたプルリクエストは、一見それらしいコードで埋まっている。AIが書いたからだ。レビューを始めたシニアが「ここ、なぜこの書き方にしたの?」とコメントする。返ってきたのは「AIがこう出力したので……」。書いた本人との対話が成立しないコードのレビューは、自分でゼロから読み解くのと変わらない。自分のタスクを中断して読み解き、指摘し、修正版を待つ。修正版もまたAIの出力で、本人は差分を説明できない。3往復目でようやく気づく——そもそも仕様の解釈が最初から違っていた。本人がAIに渡した指示の時点で、誤解が混入していたのだ。生成の速度は数倍になったのに、レビューの労力はそれ以上の倍率で膨らんでいく。
一方のジュニアも、楽をしているわけではない。仕様の解釈に迷った瞬間は、実は彼にもあった。だが「これ、聞いていいことなのか? 先週も似たことを聞いた気がする」と15分迷い、結局聞かずにAIに実装させた。疑問は飲み込まれ、誤解はコードになり、数日後にレビューで発覚する。
責めるべきは誰でもない。ジュニアは、AIが書いたコードの裏にある思想を学ぶ機会を、まだ持っていない。なぜここで責務を分けるのか、なぜこの層にこのロジックを置くのか。AIの出力には無数の設計判断が織り込まれているが、それを読み解く目は、出力をコピーしても育たない。
いまシニアと呼ばれる人たちは、その目を長い時間をかけて手に入れてきた。設計の本を読み、資格を取り、先輩のレビューで打たれ、失敗したコードを保守する痛みから学んだ。だが同じ道をこれからのジュニアに求めるのは現実的だろうか。彼らの隣には、答えを一瞬で出す道具が最初からある。「AIがある時代のエンジニア育成」のベストプラクティスは、まだどこにもない。
本記事は、その設計を試みるものだ。鍵はAIを取り上げることではなく、AIに「答え」を出させない使わせ方にある。コピペで使える育成用AIレビュー・壁打ち・ペアプロのプロンプト集ではその構造と3つの設計原則を、続く実装編ではコピペで動くプロンプト・設定の全文を説明する。
先に、たどり着きたい風景を見せておく
同じチームが、AIを「育成の道具」として設計し直すと、こうなる。
ジュニアの午前10時。 仕様の解釈で手が止まる。今度は迷わずAIに聞く。「このケースのnullの扱い、自分は〜と解釈したが穴はあるか?」——聞いていい質問かどうかの判定は、もう要らない。対話の中で解釈が2つあり得ると分かり、シニアへの質問はこう変わる。「2つの解釈があり得ます。仕様としてはどちらですか?」。30秒で答えが返る。実装は自分の方針を先に決めてからAIと進め、提出前にAIレビューで書き方レベルの指摘を潰す。理由の分からない指摘は、その場でAIに聞いて理解してから直す。
シニアの午後3時。 届いたレビュー依頼に、書き方レベルの指摘は残っていない。「なぜこう書いたか」を聞けば、本人の言葉で答えが返ってくる。見るべきは責務の切り方と、半年後の変更への耐性——シニアにしか判断できないことだけだ。1往復で承認し、自分の設計作業に戻った。中断は、なかった。
使っているAIは同じだ。変わったのは使わせ方の設計だけ。ここから、その設計を順に組み立てていく。
As-Is / To-Be — ジュニアはどこから、どこへ向かうのか
本題に入る前に、この記事が想定する出発点と到達点を示しておく。
As-Is:チュートリアルは完走できる
ReactやVue.jsのチュートリアルWebアプリを作れる。構文は分かる、動くものは作れる。ただし「動く」と「良い」の区別は、まだついていない。
To-Be:実務のコードが書ける
書く力 — コードに現れ、AIレビューで測れるもの
- 読める — 他の人が見て理解できる、可読性の高いコードを書ける
- 壊れにくい — バグを組み込みにくい、シンプルで変更に強いコードを書ける。異常系を想定したエラーハンドリングができる
- 遅くしない — N+1クエリやループ内のクエリ・API呼び出し、不要な全件取得など、実装起因の性能劣化を作り込まない
- 守れる — SQLインジェクションなど、基本的な脆弱性を作り込まない
- チームの型で書ける — フレームワークの一般的な慣習(Laravelのファットコントローラー回避、Reactのロジックのフック切り出し、など)と、チーム固有のコーディング規約の両方に沿って書ける
- 同時実行に耐える — 同期/非同期の使い分け、トランザクションや排他制御など、複数のユーザー・処理が同時に動く実務環境を前提にコードを書ける
判断する力 — コードを書く前に決まるもの
- 選べる — ライブラリや実装方式を、メンテナンス状況・将来の仕様変更・チームの既存資産を踏まえて選定し、なぜそれを選んだかを説明できる
シンプルに見えるだろうか。だが正直に言えば、これらを言語化して説明できる人は、シニアを名乗る層にも決して多くない。長年の経験で「なんとなく」身につけたものだからだ。この記事は、その「なんとなく」を、AIを使って意図的に・最短で身につけさせる設計の話である。
可読性は「プログラマのこだわり」ではない
To-Beの筆頭に挙げた可読性は、プログラマの単なるこだわり——きれい好きの美学——と思われるかもしれない。実態は全く異なる。これは金額に直結する話だ。
可読性の高いコードと低いコードでは、機能改修やバグ調査の工数が大きく変わる。改修のたびに発生する仕様調査の時間、修正にかかる時間、そして実装後にバグを埋め込む確率——これらが天と地ほど変わってくる。読めないコードは、読み解くだけで工数を食い、理解が不完全なまま手を入れることになるから、バグも混入しやすい。
そしてシステムのEOL(寿命)は10年、20年に及ぶ。可読性の低いコードが一度書き込まれると、その寿命が尽きるまで、改修のたびに余分な工数とバグ混入リスクを発生させ続ける。技術的負債として累積する損害は、最終的に数百万円に及ぶこともある。そして埋め込まれたバグが致命的なものだった場合、その影響はもはや測定できない。
保守性以下の項目も、同じ構造を持っている。To-Beの各項目はコードの美しさの話ではなく、システムの生涯コストの話だ。だからこれらをジュニアのうちに身につけさせることには、投資として明確な意味がある。
なお1〜6の「書く力」は、実装編で紹介するAIレビューのカテゴリと、本記事の最後に述べる成長記録にそのまま対応している。7の「選べる」だけはコードのdiffに現れないため測り方が異なるが、これも後述する説明責任ルールが担う。
なぜジュニア育成は回らないのか
冒頭の光景を「ジュニアのスキル不足」や「シニアの教え方」の問題として捉えると、解決策は「頑張る」しかなくなる。そうではなく、構造として分解してみる。
エンジニアの成長は、フィードバックループの回転数で決まる
エンジニアが育つプロセスは、突き詰めればひとつのループだ。
設計する → 書く → フィードバックを受ける → 直す → 振り返る
このループを何周回せるかが成長速度を決める。写経や読書で得た知識も、このループを通って初めて「書けるスキル」に変わる。逆に言えば、どれだけ真面目なジュニアでも、ループが回らない環境では育たない。
そして従来の開発現場では、このループに3つの詰まりがある。どれも冒頭の光景に出てきたものだ。
ボトルネック①:フィードバックが「シニアの空き時間」に依存している
ジュニアへのフィードバック——質問への回答も、コードレビューも——の供給源はシニアしかいない。そしてシニアには自分のタスクがある。
結果、フィードバックは「シニアの手が空いたとき」にしか発生しない。質問の回答は数時間後、レビューは翌日、往復が重なれば本題にたどり着くまで数日。ジュニアはその間、確信のないまま実装を進めるか、手を止めて待つかの二択になる。どちらを選んでも、ループは回っていない。
さらに見落とされがちなのは、このボトルネックがシニア側の成果も同時に削っていることだ。質問対応もレビューも、シニアにとっては割り込みである。設計のような深い思考を要する作業は、中断されると再開に大きなコストがかかる。冒頭のシニアが失ったのは、レビューに使った時間だけではない。中断された設計思考を組み立て直す時間も一緒に失っている。つまりフィードバック待ちの構造は、ジュニアの成長速度とシニアの生産性を、同じ原因で両方削っている。
ボトルネック②:フィードバックの大半が「シニアでなくてもできる指摘」に費やされている
ジュニアのコードにシニアが書くコメントの内訳を思い出してほしい。命名、ネストの深さ、責務の詰め込み——その多くは、判断基準が明確で、コードだけを見れば指摘できるものだ。ビジネス文脈の理解も、チーム固有の歴史も要らない。
一方で、シニアにしかできない指摘も確かにある。「この責務の切り方は、来期の機能追加で破綻する」「この仕様解釈はエンドユーザーの業務フローと合わない」——文脈と経験がなければ出てこない判断だ。
問題は、この2種類が同じレビューの場で、同じシニアの時間を使って処理されていることだ。しかも順序が悪い。書き方レベルの指摘が大量にあると、レビューはまずそこで往復を消費し、本題である設計判断の議論は数往復先に押し出される。冒頭の光景で、仕様の誤解釈——最も重要な指摘——が発覚したのが3往復目だったのは、偶然ではない。
そしてAIコーディングの普及は、この浪費をさらに重くした。本人が理解しないままAIに書かせたコードは、指摘しても対話が成立しない。「なぜこう書いたの?」への答えが「AIが出力したので」では、指摘は学習に変換されず、シニアはコードの意図の解読までを一人で背負う。書き方レベルの指摘の山に、「本人不在のコードの読解」という新しい負荷が上乗せされたのが、いまの現場だ。
ボトルネック③:質問というフィードバック要求が、ジュニアの性格に依存して大きくばらつく
ここまでは供給側(シニア)の構造の話だった。しかし需要側(ジュニア)にも問題がある。
冒頭のジュニアは15分悩んで、結局聞かなかった。「そんなことも知らないのか」と思われる恐怖が、疑問を「たぶんこうだろう」に変換させ、その一部が誤実装として数日後に返ってくる。飲み込まれた疑問は、フィードバックの機会ごと消える。
一方で、物怖じせず何でも聞けるジュニアもいる。ただしこちらはこちらで、質問のたびにシニアの時間を消費する。遠慮がないぶん、自分で5分調べればわかることも割り込みで聞いてしまい、ボトルネック①を加速させる側に回る。
つまり従来の構造では、聞けないジュニアは成長機会を失い、聞けるジュニアはシニアの時間を削る。質問の量が「怖さを感じるかどうか」という性格で決まってしまい、どちらに転んでも構造的な損失が出る。本来必要なのは「遠慮なく聞けて、かつシニアの時間を消費しない」状態だが、質問の宛先が人間である限り、この両立は原理的に不可能だ。
三重構造は、精神論では解けない
まとめるとこうなる。ジュニア育成が回らないのは、誰かの怠慢ではない。フィードバックの供給がシニアの空き時間に律速され、その貴重な供給の大半が高度な判断を要しない指摘(と、本人不在のコードの解読)に消費され、需要側では質問の量と質が性格に依存してばらつく——この三重の構造が原因だ。
そしてこの3つは、精神論だけでは解決しない。「質問しやすい雰囲気を作ろう」は質問の心理コストの根本を消さないし、「レビューを丁寧にやろう」はシニアの時間を増やさない。必要なのは構造の変更だ。次章から、AIがこの構造をどう変えるかを見ていく。
AI導入で何が変わるのか — 2つの構造変化
前章の三重構造(供給の律速・供給の浪費・需要のばらつき)を、AIは精神論抜きで解消する。変化は大きく2つだ。
変化①:フィードバックの供給源が「シニアの空き時間」から解放される
AIをジュニアの一次フィードバック役に置くと、ループの回転速度が変わる。
質問は待ち時間ゼロで返ってくる。実装前の設計相談も、実装中の「この書き方でいいのか」も、書き終えたコードのセルフレビューも、シニアの手を止めずにその場で回る。ジュニアは1日に何十周でもループを回せるようになる。従来なら1週間かけて回していた「書く→指摘を受ける→直す」のサイクルが、1タスクの中で何度も回る。
ここで重要なのは、シニアのレビューがなくなるわけではないことだ。品質のゲートは人間のまま動かさない。変わるのは、ゲートに届くまでに何が済んでいるかだ。
命名、ネスト、責務の詰め込み——判断基準が明確でコードだけを見れば指摘できるもの——は、ジュニアがレビュー依頼前にAIとの往復で潰してくる。シニアのレビューに残るのは、ビジネス文脈の理解とチームの歴史を要する判断、つまりシニアにしかできない指摘だけになる。
これは「シニアの負荷軽減」という消極的な話ではない。シニアの時間の使い途が、誰でもできる指摘の量産から、経験がなければ出せない判断へ移る。削減ではなく再配置だ。レビューの往復回数が減るのは結果であって、本質は「シニアがシニアの仕事をする時間が戻ってくる」ことにある。
変化②:質問が性格から切り離される
前章で見たとおり、従来の構造では質問の量と質がジュニアの性格で決まっていた。聞けないジュニアは機会を失い、聞けるジュニアはシニアの時間を削る。AIはこの両側を同時に解く。
聞けなかったジュニアに起きること。
質問の宛先がAIになると、「そんなことも知らないのか」と思われるリスクが消える。同じことを3回聞いても呆れられない。評価に響かない。あの15分の逡巡が、ゼロになる。
私自身も、若い頃は「こんなことを聞いていいのだろうか」と迷うことが多かった。知識が体系化されて初めて、「これは聞くべきことだ」と判断できるようになった。逆に言えば、その基準を持たない時期のエンジニアは疑問の大半を飲み込んでいる。そしてその時期こそ、いちばん質問が必要な時期だ。
AIは、この「聞いていいかどうかの判断」そのものを不要にする。判断せずにとりあえず全部聞ける。さらに副産物として、聞き続けるうちに「これは基礎的なことだった」「これは意外と深い話だった」という感覚——知識の相場観——が、日々の対話の中で育っていく。
聞けるジュニアに起きること。
遠慮なく聞けるタイプのジュニアにとっても、宛先がAIに変わることで「割り込みでシニアの時間を消費する」という副作用が消える。5分調べればわかることをAIに聞くのは、誰の迷惑にもならない。むしろAIとの対話は検索より速い調べ方として機能する。
そしてシニアに届く質問が変わる。
どちらのタイプでも、AIとの対話を経ることで質問は変質する。「これってどうすればいいですか?」という丸投げが、「AIと整理して解釈が2つあり得ると分かりました。仕様としてはどちらですか?」という判断の依頼に変わる。冒頭のAfterの風景で、シニアの回答が30秒で済んだのはこのためだ。
つまり、シニアに届く質問の総量は減り、届く質問の精度は上がる。ジュニア側は疑問を無制限に発せられるようになり、シニア側は判断だけを求められるようになる。「遠慮なく聞ける」と「シニアの時間を消費しない」という、人間相手では原理的に両立しなかった2つが、宛先が変わるだけで両立する。
ただし、これは「AIに任せれば育つ」という話ではない
ここまで読むと、AIを導入しさえすればジュニアが勝手に育つように聞こえるかもしれない。そうではない。むしろ無設計で導入すると、逆のことが起きる。冒頭のBeforeの光景が、まさにそれだ。
AIは質問に答えるだけでなく、コードそのものを書けてしまう。ジュニアがAIに実装を丸投げし、出てきたコードを理解せずコピーする——これが常態化すると、フィードバックループの「書く」「直す」「振り返る」が全部スキップされ、動くものは増えるが書ける人は育たない、という最悪の形になる。
つまりAI導入の成否は、「使うかどうか」ではなく「答えを出す道具として使わせるか、フィードバックを早める道具として使わせるか」の設計で決まる。次章では、この設計をどう作るかを原則として整理する。
育成用AIの設計原則 — 「答えを出す道具」にさせない3つのルール
AI導入の成否は使わせ方の設計で決まる。プロダクティビティ向けのAI活用——とにかく速く成果物を出す使い方——をそのままジュニアに渡すと、育成としては失敗する。育成用のAIには、育成用の設計がいる。
原則は3つある。
原則1:AIに答えを出させない — 情報の出し方を制限する
育成用AIとプロダクション用AIの最大の違いはここだ。仕事を速く終わらせたいシニアにとって、修正済みコードまで出してくれるAIは正義だ。しかしジュニアに同じものを渡すと、「指摘を読む→なぜかを考える→自分で直す」という学習の中核プロセスが丸ごとスキップされる。
だから育成用AIには、修正コードを書かせない。指摘と理由だけを返させ、直すのは本人にやらせる。
具体的には、AIの応答を「ヒントの階段」として設計する。
- まず問いを返す——「このループ、テーブルに1万件あったらどうなる?」
- 次に理由を示す——「この関数は取得と整形と保存の3つをやっていて、テストが書きにくい」
- 最後まで修正コードは書かない——考えても分からないときは、擬似コードや方針レベルのヒントまで
答えまでの距離を保つことで、AIの即時性(いつでも聞ける)と学習効果(自分で考える)を両立させる。これは人間の優れたメンターがやっていることの再現でもある。良いメンターは正解を口にする前に、まず問いを投げる。AIにはそれをプロンプトで強制できる。しかも人間のメンターと違って、疲れないし、忙しさで「もういいから答え教えるわ」に崩れることもない。
原則2:品質ゲートは人間のまま動かさない
AIレビューを導入すると、いずれ「AIが承認したらマージしていいのでは」という話が出る。これはやらない。マージの可否を判断するのは、最後まで人間のレビュアーだ。
理由は2つある。ひとつは品質面。AIの指摘は書き方レベルでは強力だが、「この設計は来期の機能追加で破綻する」「この仕様解釈はエンドの業務と合わない」といった文脈依存の判断は、チームの歴史とビジネスを知る人間にしかできない。AIレビューはこの人間の判断を置き換えるのではなく、そこに届くまでの雑音を除去する前処理として位置づける。
もうひとつは育成面。人間のレビューが残っているからこそ、ジュニアには「AIの指摘を鵜呑みにせず、自分で咀嚼してから直す」動機が生まれる。最終的に人間に説明する場があるという緊張感が、AIとの対話を「作業」ではなく「準備」にする。
この原則は、導入を判断する立場の人への回答でもある。AI導入とは品質保証をAIに明け渡すことではない。品質ゲートの位置も担当も変えず、ゲート手前の工程だけを変える——だから既存のレビュー体制やブランチ運用はそのまま使える。
原則3:説明責任ルール — 「自分の言葉で説明できないコードは出さない」
原則1と2があっても、抜け道は残る。IDEの補完機能は指摘ではなくコードそのものを吐くし、チャットAIも聞き方次第で実装を丸ごと書く。これを運用ルールの禁止で塞ごうとすると、監視コストが際限なくなる上に、そもそもAIの生産性メリットまで殺してしまう。
そこで、禁止ではなく責任で縛る。ルールはひとつだけだ。
「レビューの場で、自分の書いた(受け入れた)コードの意図を、自分の言葉で説明できること」
AIが生成したコードを使うこと自体は構わない。ただし「なぜこう書いたのか」「他の書き方ではなくこれを選んだ理由は何か」を聞かれたら答えられなければならない。説明できないコードは、レビューで差し戻される。このルールの対象はコードの書き方に限らない。ライブラリや実装方式の選定——冒頭のTo-Beで挙げた「選べる」——も同じで、「なぜこのライブラリなのか」「メンテナンス状況や既存資産との整合は確認したか」に答えられることを求める。diffに現れない判断の質は、この説明の場でだけ検証できる。
このルールの利点は、検証コストがほぼゼロなことだ。レビューは既存プロセスとして存在するので、そこで一言「ここ、どういう意図?」と聞くだけでいい。AIの使用ログを監視する必要も、補完のオン・オフを管理する必要もない。ジュニア側から見ても、「AIを使うな」ではなく「使った結果に責任を持て」なので、萎縮せずに済む。
そして実はこのルールは、検証装置である以上に学習装置として働く。説明を求められると分かっていれば、ジュニアはAIの出力を受け入れる前に「これはなぜこう書くのか」をAIに聞くようになる。その問いこそが、原則1で作ろうとしていた学習ループそのものだ。ルールが行動を変え、行動が学習を生む。
3原則の関係
まとめると、3つの原則は同じ一点を別の角度から守っている。
- 原則1は、AIの側を設計する——答えを渡さない応答設計
- 原則2は、プロセスの側を設計する——品質判断は人間に残す
- 原則3は、ジュニアの側を設計する——出力への説明責任
守っているのは「ジュニアが自分の頭で考える機会」だ。AIはその機会を最速で供給する装置であって、代わりに考える装置ではない。この線引きさえ設計に落ちていれば、AIは安心して「使い放題」にできる。
この3原則を実際のプロンプトとツール設定に落とし込んだものは、実装編(別記事)にコピペで動く全文を載せている。本記事では最後に、この仕組みで成長を「どう見るか」の考え方を述べておく。
成長は「何が指摘されなくなったか」で見える
実装編で紹介するAIレビューは、すべての指摘に [可読性] [保守性] [パフォーマンス] [セキュリティ] [設計] [並行性] のカテゴリタグと件数サマリを付けて返す設計にしている。これは単なる整理ではない。指摘ログを蓄積すると、ジュニア本人の成長記録になるからだ。
セルフレビューを続けていると、カテゴリ別の指摘件数が毎回記録されていく。始めた頃は [可読性] の指摘が毎回数件。1〜2ヶ月後にはそれがほぼ消え、代わりに [保守性] が主戦場になる。さらに数ヶ月で [設計] や [並行性] が残る——「どのカテゴリの指摘がまだ出続けているか」が、いまの自分の現在地を示す。
目安として段階に名前を付けるなら、こうなる。気づいた読者もいるかもしれないが、これは冒頭のTo-Beで挙げた「書く力」の6項目そのものだ。到達目標と計測が、同じ物差しで繋がっている。
| 段階 | 目安 | 身についたこと |
|---|---|---|
| Lv1: 読める | [可読性] の指摘が出なくなってきた | 他人が読めるコードを書く習慣 |
| Lv2: 壊れにくい | [保守性] の指摘が出なくなってきた | 変更とテストに強い構造 |
| Lv3: 遅くしない | [パフォーマンス] の指摘が出なくなってきた | 実装起因の性能劣化を作り込まない習慣 |
| Lv4: 守れる | [セキュリティ] の指摘が出なくなってきた | 基本的な脆弱性を作り込まない |
| Lv5: チームの型で書ける | [設計] の指摘が出なくなってきた | フレームワークとチームの慣習 |
| Lv6: 同時実行に耐える | [並行性] の指摘が出なくなってきた | トランザクション・排他・非同期を前提にした実装 |
これは学習の順番ではなく、指摘が消えていく順番の傾向だ。6つのカテゴリは日々並行して指摘され、並行して学ばれる。ただ、可読性のような局所的なスキルから先に指摘が消え、設計や並行性のような、文脈と経験を要するスキルが最後まで残る傾向がある。とくに並行性は、問題の存在自体に気づく知識がないと自力では学べない領域で、AIレビューに指摘されて初めて世界の存在を知る、ということが起きやすい。だからこの表は「次にこれを学べ」という指示ではなく、「自分はここまで来た」を確認する現在地表示として使ってほしい。
「先月まで毎回あった可読性の指摘が、今月は一度も出ていない」——この実感は、「最近ちょっと成長した気がする」よりずっと強い。努力が形で返ってくる体験は、それ自体が続ける燃料になる。そして、いま一番指摘が多いカテゴリを見れば、次に伸びしろがある領域も自分で判断できる。シニアに「次は何を勉強すればいいですか」と聞かなくても、自分のログが教えてくれる。
絶対に守るルール:この数字を評価に使わない
ひとつだけ、絶対の条件がある。この記録は本人が自分のために使う道具であって、指摘件数を人事評価・査定・メンバー間の比較に一切使わないこと。チームで運用する場合は、導入時に明文で宣言することを強く勧める。
理由は単純で、数字が評価に繋がった瞬間、ジュニアの合理的な行動は「成長すること」から「指摘を減らすこと」に変わるからだ。そして指摘を減らす最短の方法は、挑戦しないことだ。書き慣れた形だけで書き、難しいタスクを避ける。数字はきれいになり、成長は止まる。
育成期に最も価値があるのは、きれいなコードを1本磨き上げることではなく、書いて、指摘されて、直して、また書く——このループの回転数だ。**指摘は失点ではなく、学習が起きた回数である。**むしろ「指摘が多い月は、それだけ新しい領域に踏み込んだ月だ」と読み替えるくらいでちょうどいい。
この数字は、自分の現在地を映す鏡だ。鏡は自分が見るためにある。他人が測るための物差しにした瞬間、鏡としても機能しなくなる。なお「人」ではなく「仕組み」——AIレビューという施策自体が機能しているか——を測るためにチーム集計をKPIとして使う方法はあり、その運用の詳細は実装編で述べる。
まとめ — シニアの時間と、飲み込まれていた疑問を取り戻す
本記事で述べたことを一枚に圧縮する。
ジュニア育成が回らないのは、誰の怠慢でもなく構造の問題だった。フィードバックの供給がシニアの空き時間に律速され、その供給の大半がシニアでなくてもできる指摘と本人不在のコードの解読に消え、需要側では質問が性格に依存してばらつく——この三重構造だ。
AIはこの構造を変える。フィードバックは待ち時間ゼロになり、シニアにはシニアにしかできない判断だけが届き、質問は性格から切り離されて、飲み込まれていた疑問がすべてフィードバックの機会に変わる。
ただし、無設計の導入は逆効果になる。AIを「答えを出す道具」ではなく「フィードバックを早める道具」として渡すこと。そのための3原則が、答えを出させない応答設計、人間のままの品質ゲート、そして説明責任ルールだった。
導入した先にあるのは、AIがジュニアを育てる未来ではない。シニアが本来の仕事に集中でき、ジュニアが遠慮なく試行錯誤できる、人間の時間の使い方が正しくなった現場だ。AIはそのための、疲れないメンターであり、雑音を消すフィルターであり、自分の成長を映す鏡である。
具体的な始め方——壁打ちプロンプト、レビュープロンプト、Copilot / Cursorの設定ファイルの全文——は実装編にまとめた。プロンプト1本をチームのwikiに貼るところから、今日始められる。