はじめに — AIで生産性は上がった。レビューは地獄になった
AIコーディングの導入で、開発の生産性は確かに上がった。かつて1日かかった実装が数時間で終わる。ジュニアエンジニアでも、動くものが作れてしまう。
そして、レビューの負荷が跳ね上がった。
こんな場面に覚えはないだろうか。ジュニアから届いたプルリクエストは、一見それらしいコードで埋まっている。AIが書いたからだ。レビューを始めたシニアが「ここ、なぜこの書き方にしたの?」とコメントする。返ってきたのは「AIがこう出力したので……」。書いた本人との対話が成立しないコードのレビューは、自分でゼロから読み解くのと変わらない。自分のタスクを中断して読み解き、指摘し、修正版を待つ。修正版もまたAIの出力で、本人は差分を説明できない。3往復目でようやく気づく——そもそも仕様の解釈が最初から違っていた。本人がAIに渡した指示の時点で、誤解が混入していたのだ。生成の速度は数倍になったのに、レビューの労力はそれ以上の倍率で膨らんでいく。
一方のジュニアも、楽をしているわけではない。仕様の解釈に迷った瞬間は、実は彼にもあった。だが「これ、聞いていいことなのか? 先週も似たことを聞いた気がする」と15分迷い、結局聞かずにAIに実装させた。疑問は飲み込まれ、誤解はコードになり、数日後にレビューで発覚する。
責めるべきは誰でもない。ジュニアは、AIが書いたコードの裏にある思想を学ぶ機会を、まだ持っていない。なぜここで責務を分けるのか、なぜこの層にこのロジックを置くのか。AIの出力には無数の設計判断が織り込まれているが、それを読み解く目は、出力をコピーしても育たない。
いまシニアと呼ばれる人たちは、その目を長い時間をかけて手に入れてきた。設計の本を読み、資格を取り、先輩のレビューで打たれ、失敗したコードを保守する痛みから学んだ。だが同じ道をこれからのジュニアに求めるのは現実的だろうか。彼らの隣には、答えを一瞬で出す道具が最初からある。「AIがある時代のエンジニア育成」のベストプラクティスは、まだどこにもない。
本記事は、その設計を試みるものだ。鍵はAIを取り上げることではなく、AIに「答え」を出させない使わせ方にある。フィードバックを最速にしながら、考える機会を奪わない——そのための3原則と、コピペで動く実装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を使って意図的に・最短で身につけさせる設計の話である。
なお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分の逡巡が、ゼロになる。
少し私自身の話をしたい。私は13年この仕事をしているが、「自分が知らないことは、聞いても恥ずかしくないことだ」と思えるようになったのは、応用情報やセキュリティスペシャリスト、Java Goldといった資格を取ったあとだった。体系的に学んだはずの自分が知らないのだから、これは聞いていい知識だ——そう判断できる基準が、資格によってようやくできた。逆に言えば、その基準を持たなかった時期の私は、疑問の大半を飲み込んでいた。そしてその時期こそ、いちばん質問が必要な時期だった。
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原則を実際のツール設定とプロンプトに落とし込む。今日からコピペで使える形で。
実装編 — 今日から始める3ステップ
ここからは、前章の3原則を実際の設定とプロンプトに落とす。導入の手軽さ順に3ステップで構成した。ステップ1は今日から、ステップ2は今週から、ステップ3はチームの合意が取れてから、というイメージだ。すべてコピペで動く形で載せる。
ステップ1:質問・壁打ち窓口 — チャットAIにプロンプトを1本貼るだけ
最初の一歩は、ジュニアが「何でも聞ける相手」を持つことだ。ChatGPT、Claude、Gemini、何でもいい。会話の最初に以下のプロンプトを貼る(あるいはカスタム指示/Projectとして登録する)だけで、育成用に調整されたメンターになる。
あなたはジュニアエンジニアの学習を支援するメンターです。
私はジュニアエンジニアで、あなたに技術的な質問や設計の相談をします。
## あなたの行動ルール
1. どんな初歩的な質問にも、呆れたり評価したりせず答えてください。
私が同じことを何度質問しても、初回と同じ丁寧さで答えてください。
2. 私が実装方法を聞いたとき、いきなりコードを書かないでください。
まず「あなたはどう作るつもりですか?」と私の方針を聞いてください。
3. 私の方針が妥当なら、承認して背中を押してください。
問題があるなら、答えを言う前に、問いの形で気づかせてください。
(例:「そのループ、データが1万件あったらどうなりますか?」)
4. 私が自分の理解を説明したときは、合っている部分と
誤解している部分を明確に分けてフィードバックしてください。
誤解は遠慮なく指摘してください。私は訂正されるためにここにいます。
5. ヒントは段階的に出してください。
問い → 考え方の方向 → 擬似コード の順で、
完成したコードは私が明示的に求めない限り書かないでください。
6. 会話の最後に、今日の疑問が「基礎的な知識」だったのか
「経験者でも迷う話」だったのかを一言添えてください。
私は自分の知識の相場観を育てたいと思っています。
## 禁止事項
- 私の代わりにタスクの実装コードを丸ごと書くこと
- 私が考える前に答えを提示すること
ポイントは3つある。ルール4が「誤解の訂正」を明示的に依頼していること——人間相手では気を使って流されがちな「理解のズレの指摘」を、AIには堂々と要求できる。ルール6は前章までに述べた「知識の相場観」を日々の対話で育てるための仕掛けだ。そして禁止事項が原則1(答えを出させない)の実装になっている。
チーム導入の際は、このプロンプトをチームのwikiに置いて「質問はまずこれに聞いてからでOK。それでも分からなければ遠慮なく人間へ」という一文を添えるだけでいい。ジュニアに「AIに先に聞くのはサボりではなく推奨行動だ」と明言することが、運用上いちばん重要な一歩になる。
ステップ2:レビュー前セルフレビュー — diffを貼る運用から始める
次は、人間レビューの前にAIレビューを挟む。最初はCI連携もツール導入も不要で、レビュー依頼前にdiffをチャットに貼るという運用だけで始められる。
あなたはコードレビュアーです。教育目的のレビューなので、
以下のルールを厳守してください。
## レビューのルール
1. 修正後のコードは絶対に書かないでください。
指摘と「なぜ問題か」の説明だけを返してください。
修正方法は、問いかけやヒントの形に留めてください。
2. 指摘には必ず以下のカテゴリタグを付けてください。
[可読性] 命名、関数の長さ、ネストの深さ、マジックナンバー
[保守性] 責務の詰め込み、重複、依存の向き、テストの書きにくさ、
異常系の考慮漏れ(エラーハンドリング、null・空・失敗時の挙動)
[パフォーマンス] N+1クエリ、ループ内のクエリ/API呼び出し、
不要な全件取得、無駄な再計算・再レンダリング
[セキュリティ] インジェクション、XSS、認可漏れ、入力検証、秘匿情報
[設計] フレームワークの慣習からの逸脱、レイヤの混在、
チームのコーディング規約への違反(規約が提供された場合)
[並行性] トランザクションの欠落、チェックと更新の分離
(check-then-act)、排他制御の漏れ、非同期処理の待ち漏れ
3. 指摘の形式:
- 場所(ファイル名と該当箇所)
- [カテゴリ] 指摘内容
- なぜ問題か(将来このコードを読む人・変更する人の視点で)
- 考えるヒント(答えではなく問いの形で)
4. 重要な指摘から順に、最大7件まで。
些末な指摘を網羅するより、学びの大きい指摘を優先してください。
5. 指摘すべき点がないカテゴリは「指摘なし」と明記してください。
無理に指摘を作らないでください。褒めるべき点があれば
1つだけ、理由付きで褒めてください。
6. 指摘同士がトレードオフになる場合(例:可読性と
パフォーマンス)は、どちらかに肩入れせず、トレードオフで
あることを明示してください。その上で、計測による根拠が
ない限り可読性を優先するのが一般原則であることを
添えてください。最終判断はチームと人間のレビュアーに
委ねてください。
## 最後に必ず出力すること
カテゴリ別の指摘件数サマリ(例:可読性2件、保守性1件、
パフォーマンス1件、セキュリティ0件、設計0件、並行性0件)
---
以下がレビュー対象のdiffです:
(ここにdiffを貼る)
設計判断がいくつか埋まっている。上限7件は、AIレビュー最大の失敗パターンである「過剰指摘でジュニアが溺れる」ことへの対策だ。「指摘なし」を許可するのも同じで、AIは頼まれると無理にでも指摘を生成するので、明示的に「作るな」と縛らないと「指摘が出なくなった」ことが成長の証明として機能しない。褒めを1つに絞っているのは、AIの褒めすぎ傾向で肝心の指摘が薄まるのを防ぐためだ。1つだけ・理由付きに縛ると、AIは褒める対象を選別せざるを得なくなり、「今回いちばん良かった点はどこか」という選択自体が情報になる。そしてカテゴリタグと件数サマリが、後の章で述べる成長記録の入力になる。
運用フローはこうだ。
- ジュニアが実装を終える
- レビュー依頼を出す前に、このプロンプトでAIレビューを実施
- 指摘を読み、理由を理解してから自分で修正(分からなければステップ1の窓口で深掘り)
- 人間レビューへ
慣れてきたらCIへの組み込み(PR作成時に自動実行)に発展させられるが、最初からCIを組む必要はない。手動で貼る運用でも効果は同じで、むしろ「自分でAIレビューを回してから依頼する」という習慣づけの面では手動の方が教育的ですらある。
もうひとつ、効果の大きい応用がある。チームにコーディング規約があるなら、diffの前に規約も一緒に貼る。それだけで、AIは規約違反も [設計] として指摘するようになる。規約の指摘は判断基準が完全に明文化されている、機械的なチェックの最たるものだ。そして人間のシニアにとって、細かい規約指摘は最も心が折れるレビュー作業でもある。指摘する側もされる側も消耗する仕事を、AIは疲れずに淡々とこなす。ここはAIに任せる価値が最も高い領域のひとつだ。
カテゴリ同士が衝突したら誰が裁くのか
鋭い読者は気づいたかもしれない。6つのカテゴリは、常に同じ方向を向いているわけではない。読みやすく素直に書いたループが [パフォーマンス] で指摘され、速度のために最適化したコードが [可読性] で指摘される——トレードオフは普通に起きる。
プロンプトのルール6は、このときAIに審判をさせないための設計だ。AIはトレードオフの存在を明示し、一般原則——計測による根拠がない限り、可読性を優先する(いわゆる早すぎる最適化を避ける)——を添えるところまでで止まる。この一般原則自体は好みの問題ではなく、ジュニアがまずデフォルトとして身につけるべき土台だ。
だが、デフォルトを覆す判断は別だ。「この処理はホットパスだから速度を取る」「このバッチは夜間実行だから素直さを取る」——これはトラフィックやSLA、データ量の見込みという文脈を知らなければ下せない。つまりトレードオフの裁定こそ、原則2で人間に残した品質ゲートの中身そのものだ。AIが機械的な指摘と一般原則までを引き受けるからこそ、人間のレビューは「どちらを取るか」という判断の議論から始められる。
なおチームとして「うちはこの方針」という基準があるなら、それも規約に書いてdiffと一緒に貼ればいい。レビュアー個人の好みで裁定が揺れる問題は、方針を明文化した瞬間に「規約チェック」に変わり、AIが引き受けられる仕事になる。
ステップ3:IDE内ペアプロ — Copilot / Cursorに教育用の性格を与える
最後が実装中のリアルタイム支援だ。ここはGitHub CopilotやCursorといったIDE内のAIが主戦場になる。ただし前章で述べたとおり、実装中のAIは最も「答えを出す道具」に転びやすい。補完をそのまま受け入れ続けるだけの使い方を防ぐため、リポジトリに教育用の指示ファイルを置く。
GitHub Copilotの場合(リポジトリ直下に .github/copilot-instructions.md):
# このリポジトリでのAI支援の方針
このチームはAIを「フィードバックを早める道具」として使い、
「答えを出す道具」としては使いません。チャットで応答する際は
以下に従ってください。
## チャットでの応答ルール
- 実装方法を聞かれたら、まず質問者の方針を確認してから答える
- コードを提示する前に、考え方と選択肢を先に説明する
- 提示するコードは最小限の骨格に留め、完成品を渡さない
- 質問者の理解が誤っていそうな場合は、遠慮なく指摘する
## コードの説明責任
このチームでは「自分の言葉で説明できないコードは
コミットしない」ルールを採用しています。コードを提案する際は、
そのコードが何をしているか・なぜその書き方なのかを
必ず添えてください。
Cursorの場合(リポジトリ直下に .cursor/rules/education.mdc など):
---
description: ジュニア育成方針。全チャット応答に適用。
alwaysApply: true
---
- 実装の質問には、コードより先に考え方を答える
- 完成コードの生成を求められたら、まず質問者自身の方針を聞く
- 生成したコードには「なぜこう書くか」の説明を必ず添える
- 質問者の前提や理解に誤りがあれば、作業を進める前に指摘する
ひとつ注意点がある。.cursor/rules 内のファイルは .mdc 拡張子が必須で、素の .md で保存するとフロントマターを持たないためルールとして認識されず、エラーも出ずに黙って無視される。「ルールを書いたのに効かない」の典型的な原因なので、拡張子を確認してほしい。
なお、特定ツールに縛られない書き方として、リポジトリ直下に AGENTS.md を置くというツール横断の共通形式もある。2026年時点で対応ツールが広がっており、CopilotとCursorのどちらからも読める。チームで使うツールが混在している、あるいは今後変わる可能性があるなら、こちらに寄せる手もある。
正直に書くと、インライン補完(タイプ中に灰色で出る候補)そのものは、この指示では制御しきれない。補完はチャットと違って指示ファイルの影響が限定的だからだ。ここを技術で塞ごうとするのが筋の悪い戦いで、だからこそ原則3の説明責任ルールが効く。補完を受け入れるのは自由、ただしレビューで「ここ、どういう意図?」に答えられなければ差し戻し——技術で縛れない部分を、既存のレビュープロセスが受け止める。指示ファイルとレビュー運用は、この意味でセットだ。
なおチーム内にシニアもいる場合、この指示ファイルがシニアの生産性を落とす懸念があるかもしれない。実際にはチャットで「骨格でなく完成形で」と一言添えれば済む話で、デフォルトを教育寄りに倒しておく方が、ジュニアを守る設計として合理的だ。
3ステップの全体像
| 導入コスト | 効くタイミング | 3原則との対応 | |
|---|---|---|---|
| ①質問・壁打ち窓口 | プロンプト1本、今日から | 実装前・実装中の疑問 | 原則1(答えを出させない) |
| ②セルフレビュー | diffを貼る運用、今週から | 人間レビューの前 | 原則1+2(ゲートは人間) |
| ③IDE内ペアプロ | 指示ファイル+チーム合意 | 実装中 | 原則3(説明責任)とセット |
どこから始めてもいいが、推奨は①→②→③の順だ。①と②は個人の運用だけで始められ、目に見える変化(質問の質、レビュー往復の減少)が出る。その実績が③のチーム合意を取る材料になる。
成長の見える化 — 指摘カテゴリの推移は「自分だけの成長記録」
ステップ2のセルフレビューで、指摘にカテゴリタグと件数サマリを付けさせた。あれは整理のためではなく、この章のための布石だ。AIレビューの指摘ログは、蓄積するとジュニア本人の成長記録になる。
先に一番大事なことを言っておく。これは本人が自分のために使う道具であって、チームや上司が本人を測る道具ではない。理由は後述する。
「何が指摘されなくなったか」で現在地がわかる
セルフレビューを続けていると、カテゴリ別の指摘件数が毎回記録されていく。これを時系列で眺めるだけで、自分の変化が構造として見える。
- 始めた頃:[可読性] の指摘が毎回数件。命名とネストで集中的に指摘される
- 1〜2ヶ月後:[可読性] がほぼ出なくなり、代わりに [保守性] ——責務の詰め込み、テストの書きにくさ——が主戦場になる
- さらに数ヶ月:[保守性] が減り、[設計] ——レイヤの混在、フレームワークの慣習——が残る
つまり「どのカテゴリの指摘がまだ出続けているか」が、いまの自分の現在地を示す。目安として段階に名前を付けるなら、こうなる。気づいた読者もいるかもしれないが、これは冒頭のTo-Beで挙げた「書く力」の6項目そのものだ。到達目標と計測が、同じ物差しで繋がっている。
| 段階 | 目安 | 身についたこと |
|---|---|---|
| Lv1: 読める | [可読性] の指摘が出なくなってきた | 他人が読めるコードを書く習慣 |
| Lv2: 壊れにくい | [保守性] の指摘が出なくなってきた | 変更とテストに強い構造 |
| Lv3: 遅くしない | [パフォーマンス] の指摘が出なくなってきた | 実装起因の性能劣化を作り込まない習慣 |
| Lv4: 守れる | [セキュリティ] の指摘が出なくなってきた | 基本的な脆弱性を作り込まない |
| Lv5: チームの型で書ける | [設計] の指摘が出なくなってきた | フレームワークとチームの慣習 |
| Lv6: 同時実行に耐える | [並行性] の指摘が出なくなってきた | トランザクション・排他・非同期を前提にした実装 |
これは学習の順番ではなく、指摘が消えていく順番の傾向だ。6つのカテゴリは日々並行して指摘され、並行して学ばれる。ただ、可読性のような局所的なスキルから先に指摘が消え、設計や並行性のような、文脈と経験を要するスキルが最後まで残る傾向がある。とくに並行性は、問題の存在自体に気づく知識がないと自力では学べない領域で、AIレビューに指摘されて初めて世界の存在を知る、ということが起きやすい。だからこの表は「次にこれを学べ」という指示ではなく、「自分はここまで来た」を確認する現在地表示として使ってほしい。
「先月まで毎回あった可読性の指摘が、今月は一度も出ていない」——この実感は、「最近ちょっと成長した気がする」よりずっと強い。努力が形で返ってくる体験は、それ自体が続ける燃料になる。そして、いま一番指摘が多いカテゴリを見れば、次に伸びしろがある領域も自分で判断できる。シニアに「次は何を勉強すればいいですか」と聞かなくても、自分のログが教えてくれる。
運用は最小限でいい
仕組みを作り込む必要はまったくない。セルフレビューのたびに出る件数サマリを、自分のメモ(手元のテキストファイルでもNotionでも何でもいい)に日付付きで貼っておく。それだけだ。月に一度、並べて眺める。集計したければ、そのメモごとAIに投げれば数分で傾向が出る。
絶対に守るルール:この数字を評価に使わない
もしこの記録をチームで共有する運用を考えるなら——たとえばPR説明文にサマリを貼るなど——ひとつだけ絶対の条件がある。**指摘件数を人事評価・査定・メンバー間の比較に一切使わないこと。**導入時に明文で宣言することを強く勧める。
理由は単純で、数字が評価に繋がった瞬間、ジュニアの合理的な行動は「成長すること」から「指摘を減らすこと」に変わるからだ。そして指摘を減らす最短の方法は、挑戦しないことだ。書き慣れた形だけで書き、難しいタスクを避ける。数字はきれいになり、成長は止まる。
育成期に最も価値があるのは、きれいなコードを1本磨き上げることではなく、書いて、指摘されて、直して、また書く——このループの回転数だ。**指摘は失点ではなく、学習が起きた回数である。**むしろ「指摘が多い月は、それだけ新しい領域に踏み込んだ月だ」と読み替えるくらいでちょうどいい。
この数字は、自分の現在地を映す鏡だ。鏡は自分が見るためにある。他人が測るための物差しにした瞬間、鏡としても機能しなくなる。
**唯一の例外は、「人」ではなく「仕組み」を測る場合だ。**このAIレビューの仕組み自体、導入して終わりではなく、状況に応じて改善していく必要がある。プロンプトのチェック項目は自分たちの現場に合っているか、指摘の粒度は適切か、貼っている規約は古びていないか。その改善サイクルを回すための定量的なKPIのひとつとして、チーム全体の指摘傾向の集計を位置付けることは可能だ。
このKPIは、成果の報告だけでなく改善策の立案まで繋がる。カテゴリ別に集計すると「減りやすい項目」と「減りにくい項目」の傾向が見えるからだ。たとえばチーム全体で [並行性] の指摘だけがいつまでも減らないなら、それは個々の努力不足ではなく、指摘を読むだけでは身につかない前提知識の領域だというサインで、ステップ1の壁打ちプロンプトにトランザクションの解説を厚くさせる、参考実装を規約と一緒に貼る、といった打ち手に繋げられる。[可読性] が減らないなら、指摘が抽象的すぎて行動に変換できていない可能性を疑い、プロンプトの「考えるヒント」の具体度を上げる。どのカテゴリが詰まっているかが、仕組みのどこを直すべきかを教えてくれる。
さらに、運用を続けると貼っている規約そのものの不備も見えてくる。同じような箇所でAIの指摘が揺れる、規約と一般慣習が食い違う指摘が出る——そういう場所は、規約の記述が曖昧か、状況によって正解が分かれるのに条件が書かれていないか、そもそも規定が抜けているかのどれかだ。人間同士なら「空気」で補えてしまう曖昧さは、文字通りにしか読まないAIには通用しない。だからAIレビューは、規約の欠陥を炙り出すテストとしても働く。指摘の揺れは、規約を明文化し直す好機だ。
いずれにせよ、「導入から3ヶ月で、チーム全体の可読性カテゴリの指摘が大きく減った」という報告材料になると同時に、減らない項目や揺れる指摘は誰かの能力の問題ではなく、プロンプト・運用・規約の改善対象なのだ。
ただしこの場合も、集計は必ず個人が特定できない粒度で行うこと。数人のチームでは「全体集計」でも実質誰の話か分かってしまう。その場合は件数の増減ではなく、「セルフレビューが習慣として続いているか」「レビュー往復が減った実感があるか」といった定性的な確認に留める方が安全だ。測っていいのは施策の効果であって、人の優劣ではない——この線さえ守れば、数字は導入の説得力にもなる。
まとめ — シニアの時間と、飲み込まれていた疑問を取り戻す
本記事で述べたことを一枚に圧縮する。
ジュニア育成が回らないのは、誰の怠慢でもなく構造の問題だった。フィードバックの供給がシニアの空き時間に律速され、その供給の大半がシニアでなくてもできる指摘と本人不在のコードの解読に消え、需要側では質問が性格に依存してばらつく——この三重構造だ。
AIはこの構造を変える。フィードバックは待ち時間ゼロになり、シニアにはシニアにしかできない判断だけが届き、質問は性格から切り離されて、飲み込まれていた疑問がすべてフィードバックの機会に変わる。
ただし、無設計の導入は逆効果になる。AIを「答えを出す道具」ではなく「フィードバックを早める道具」として渡すこと。そのための3原則が、答えを出させない応答設計、人間のままの品質ゲート、そして説明責任ルールだった。実装は、プロンプト1本の質問窓口から始められる。
導入した先にあるのは、AIがジュニアを育てる未来ではない。シニアが本来の仕事に集中でき、ジュニアが遠慮なく試行錯誤できる、人間の時間の使い方が正しくなった現場だ。AIはそのための、疲れないメンターであり、雑音を消すフィルターであり、自分の成長を映す鏡である。
まずはステップ1のプロンプトを、チームのwikiに貼るところから。
本記事のプロンプト・設定例は2026年7月時点の各ツールの公式仕様に基づいています。GitHub Copilot / Cursorの設定ファイルの仕様は変わることがあるため、導入時は各公式ドキュメントをご確認ください。