育成用AIレビュー・壁打ち・ペアプロの実装 — コピペで動くプロンプトと設定全文(実装編)
この記事について
本記事は、ジュニアエンジニア育成にAIを組み込むための実装リファレンスだ。壁打ちプロンプト、レビュープロンプト、GitHub Copilot / Cursorの設定ファイルを、すべてコピペで動く全文で載せる。
なぜこの設計なのか——構造の分析と設計思想は別記事に書いた。要点だけ圧縮すると、こうだ。
- AIは「答えを出す道具」ではなく「フィードバックを早める道具」としてジュニアに渡す。丸投げを許すと、動くものは増えるが書ける人は育たない
- 原則1:AIに答えを出させない — 修正コードは書かせず、指摘と理由と問いだけを返させる
- 原則2:品質ゲートは人間のまま — マージ可否の判断は最後まで人間のレビュアー。AIはそこに届くまでの雑音を除去する前処理
- 原則3:説明責任ルール — AIの出力を使うのは自由。ただし「自分の言葉で意図を説明できないコードは出さない」
→ 概念編:AIに「答え」を出させないジュニア育成(公開後にリンクを挿入)
実装は導入の手軽さ順に3ステップで構成した。ステップ1は今日から、ステップ2は今週から、ステップ3はチームの合意が取れてから、というイメージだ。
対象はジュニアだけではない
なお「育成用」と銘打っているが、この仕組みが効くのはジュニアだけではない。経験豊富なエンジニアが未経験の技術に初めて触れるとき——たとえばバックエンド一筋の人が初めてVue.jsやReactを書くとき——にも、そのまま使える。
言語の文法は調べれば分かる。だが「そのフレームワークではこう書くのが普通」という慣習は、明文化されていないことが多く、コードを書いて指摘されるまで気づけない。
しかも経験者には、ジュニアにはない厄介さがある。聞かなくても実装できてしまうことだ。別のプロジェクトで確立した自分のやり方があるので、FWが用意している機能を知らなくても、大抵のものは素の言語機能と汎用的な書き方で作れてしまう。動くし、本人の中では品質も担保されている。だがそれは、そのFWの一般的な書き方とは異なる実装方式であり、FWの慣習を前提にコードを読む他のメンバーにとっては保守しにくいコードになる。ジュニアの「動くけど良くない」とは別の形で、「動くし本人基準では良いが、チームでは保守しにくい」が生まれるのだ。しかも本人は困っていないので疑問が湧かず、質問も発生しない。「シニアがこんなことを聞くのか」という心理的な聞きにくさ以前に、聞く必要を感じる機会そのものがない。
このレビュープロンプトは [設計] カテゴリでフレームワークの慣習からの逸脱を指摘するので、「動くが、そのFWらしくない」コードを誰にも聞かずに矯正できる。カテゴリ別サマリには「可読性・保守性は指摘なし、設計だけ数件」という分布が出るはずで、それは「基礎はできている、足りないのはこのFWの型だけ」という診断そのものだ。経験の絶対量と、特定技術の経験量は別物であり、後者が足りないとき、人は誰でも一時的にジュニアになる。この仕組みは、その一時的なジュニア状態を最短で抜けるための道具でもある。
そう考えると、「React経験3年以上」「Laravel経験5年以上」といった募集要項は、将来的に意味を失っていくのかもしれない。特定FWの経験年数が担保していたものの少なくない部分は「そのFWの慣習や、あまり知られていない機能を知っているか」だ。だが前者は、もう年数をかけずに習得できるようになりつつある。そして後者は、実は年数でも担保されていない——長年そのFWを使っていても、業務で使わなかった機能は知らないままなのが普通で、5年目のエンジニアが「そんな機能あったのか」とAIに教わる場面は珍しくない。年数は習得の近道でも、網羅の証明でもなかったわけだ。エンジニアの経験として本当に問うべきは何年触ったかではなく、新しい技術の型をどれだけ速く身につけられるか——その転換を、この小さなプロンプトは先取りしている。
ステップ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(説明責任)とセット |
どこから始めてもいいが、推奨は①→②→③の順だ。①と②は個人の運用だけで始められ、目に見える変化(質問の質、レビュー往復の減少)が出る。その実績が③のチーム合意を取る材料になる。
成長記録の運用 — サマリの残し方と、仕組みのKPI
ステップ2のカテゴリタグと件数サマリは、蓄積するとジュニア本人の成長記録になる。「先月まで毎回あった [可読性] の指摘が今月は出ていない」という形で、自分の現在地が見える(この考え方の詳細と、カテゴリとレベルの対応表は概念編を参照)。
記録は最小限でいい
仕組みを作り込む必要はまったくない。セルフレビューのたびに出る件数サマリを、自分のメモ(手元のテキストファイルでもNotionでも何でもいい)に日付付きで貼っておく。それだけだ。月に一度、並べて眺める。集計したければ、そのメモごとAIに投げれば数分で傾向が出る。
この数字を個人の評価に使わない
概念編で述べた絶対のルールを、運用の観点から繰り返しておく。**指摘件数を人事評価・査定・メンバー間の比較に一切使わないこと。**数字が評価に繋がった瞬間、ジュニアの合理的な行動は「挑戦して指摘され、学ぶ」から「挑戦せず指摘を減らす」に変わり、記録は成長の鏡として機能しなくなる。チームで共有する運用(PR説明文にサマリを貼るなど)を始めるなら、導入時にこの不使用を明文で宣言することを強く勧める。
「人」ではなく「仕組み」を測るKPIとしては使える
このAIレビューの仕組み自体、導入して終わりではなく、状況に応じて改善していく必要がある。プロンプトのチェック項目は自分たちの現場に合っているか、指摘の粒度は適切か、貼っている規約は古びていないか。その改善サイクルを回すための定量的なKPIのひとつとして、チーム全体の指摘傾向の集計を位置付けることは可能だ。
このKPIは、成果の報告だけでなく改善策の立案まで繋がる。カテゴリ別に集計すると「減りやすい項目」と「減りにくい項目」の傾向が見えるからだ。たとえばチーム全体で [並行性] の指摘だけがいつまでも減らないなら、それは個々の努力不足ではなく、指摘を読むだけでは身につかない前提知識の領域だというサインで、ステップ1の壁打ちプロンプトにトランザクションの解説を厚くさせる、参考実装を規約と一緒に貼る、といった打ち手に繋げられる。[可読性] が減らないなら、指摘が抽象的すぎて行動に変換できていない可能性を疑い、プロンプトの「考えるヒント」の具体度を上げる。どのカテゴリが詰まっているかが、仕組みのどこを直すべきかを教えてくれる。
さらに、運用を続けると貼っている規約そのものの不備も見えてくる。同じような箇所でAIの指摘が揺れる、規約と一般慣習が食い違う指摘が出る——そういう場所は、規約の記述が曖昧か、状況によって正解が分かれるのに条件が書かれていないか、そもそも規定が抜けているかのどれかだ。人間同士なら「空気」で補えてしまう曖昧さは、文字通りにしか読まないAIには通用しない。だからAIレビューは、規約の欠陥を炙り出すテストとしても働く。指摘の揺れは、規約を明文化し直す好機だ。
いずれにせよ、「導入から3ヶ月で、チーム全体の可読性カテゴリの指摘が大きく減った」という報告材料になると同時に、減らない項目や揺れる指摘は誰かの能力の問題ではなく、プロンプト・運用・規約の改善対象なのだ。
ただしこの場合も、集計は必ず個人が特定できない粒度で行うこと。数人のチームでは「全体集計」でも実質誰の話か分かってしまう。その場合は件数の増減ではなく、「セルフレビューが習慣として続いているか」「レビュー往復が減った実感があるか」といった定性的な確認に留める方が安全だ。測っていいのは施策の効果であって、人の優劣ではない——この線さえ守れば、数字は導入の説得力にもなる。
おわりに
3ステップのどれも、特別なツールの購入もレビュー体制の変更も要らない。まずはステップ1のプロンプトを、チームのwikiに貼るところから。
なぜこの設計なのか——ジュニア育成が回らない三重構造、「そんなことも知らないのか」の恐怖が消える理由、AIに答えを出させない3原則——は別記事に書いた。運用の背景を押さえたい方、チームへの導入を説得する立場の方は、そちらから読んでほしい。
→ AI時代のジュニアエンジニア育成論 ― 「答えを出させないAI」で、レビューと成長を両立する
本記事のプロンプト・設定例は2026年7月時点の各ツールの公式仕様に基づいています。GitHub Copilot / Cursorの設定ファイルの仕様は変わることがあるため、導入時は各公式ドキュメントをご確認ください。