はじめに
前編では「3ヶ月の見積もりが1ヶ月で完了した」という体験をもとに、AIレバレッジモデルのフローを紹介しました。
ただ、正直に言います。このモデルには落とし穴があります。
うまく機能するチームとうまくいかないチームの差は、ツールの使い方よりも「懸念点をどう手当てするか」にあります。後編では、世界のエンジニアリングリーダーの知見と照らし合わせながら、5つの懸念点と具体的な対策を掘り下げます。
懸念点1：仕様理解の浅さが蓄積する
なぜ起きるのか
Copilotにアサインすればコードが生成され、ローカルで動作確認してPRが出る——このサイクルが快適すぎるがゆえに、「なぜこのコードになるのか」を理解しないまま実装が積み上がっていきます。
Addy Osmaniが最も強調する懸念点です。
プロンプトは書けるがデバッグできない、コードは生成できるが理由を説明できない——そんな開発者の世代を生み出す危機だと、複数のエンジニアリングリーダーが警鐘を鳴らしている。
半年後、「このコードがなぜこう書かれているのか誰も知らない」という状況は、AIがいなかった時代より深刻です。少なくとも以前は書いた本人が知っていたからです。
対策①：実装レポートで言語化を習慣にする
前編で紹介した「実装レポートをIssueに貼り付ける」ステップは、ただの共有手段ではありません。AIが生成したコードを初級エンジニア自身が言葉で説明するプロセスとして機能します。
レポートを書かせるとき、以下の問いを意識させると効果的です。
- このコードで一番理解が怪しい部分はどこか？
- エッジケースとして何を考慮したか？
- ベテランに「なぜこの実装か」と聞かれたら答えられるか？
答えられない部分があれば、それが打ち合わせで聞くべき「なぜ」です。
対策②：週1回のコードリーディング会
チームで週1回、実装済みのコードをランダムに選んで読む会を設けます。
進め方の例：
1. 先週マージされたPRから1つをランダムに選ぶ
2. 実装した初級エンジニアがコードを説明する（AIへの質問は事前に禁止）
3. ベテランが「なぜこの設計か」の背景を補足する
4. 次のIssueに活かせることをメモする
「説明できる」ことと「生成できる」ことは別のスキルです。このサイクルが、AIに頼ったコードを自分の知識として消化する機会になります。
懸念点2：AI依存によるスキル停滞
なぜ起きるのか
初級エンジニアがAIを使い続けることで、「AIなしでは書けないエンジニア」になるリスクがあります。
長く活躍するエンジニアは、AIを使って経験を加速させる人だ。AIを使って経験を省略しようとする人ではない。
— Addy Osmani, The 80% Problem in Agentic Coding
「経験を加速させる」と「経験を省略する」は、日常の使い方の中では区別しにくいのが難しいところです。
対策①：「自力デー」を定期的に設ける
月に1〜2回、小さな機能を意図的にAIなしで実装する日を作ります。
自力デーのルール例：
- GitHub CopilotのサジェストをOFFにする
- AIチャットへの質問を禁止する（ドキュメント・Stack Overflowは可）
- 詰まったらベテランに聞く（これが打ち合わせの質を上げる）
目的はAIを禁止することではなく、「AIがいなくても考えられる筋肉」を維持することです。
対策②：PRレビューで「理解度」を問う
前編でも触れたAddy Osmaniの「Trio Programming」の概念において、PRレビューは「コードが正しいか」だけでなく「エンジニアが理解しているか」を確認する場として機能します。
レビュー時に一言添えるだけで効果があります。
「このトランザクション処理、なぜここで使ったか教えて」
「このエラーハンドリング、他の方法と比べてなぜこっちを選んだ？」
答えられなければ、それはAIが決めたことをそのまま使った部分です。そこをベテランが補足することで、知識の移転が起きます。
対策③：成長の可視化
初級エンジニアが「自分は成長しているのか」を実感できる仕組みを作ることも重要です。
- 月次で「自力で書いたコード量」と「AIを使ったコード量」を振り返る
- 3ヶ月前には書けなかったコードを今は書けるかチェックする
- 学んだことをドキュメントやZennの記事にアウトプットする
アウトプットの習慣は、理解の浅さを自分でも気づく契機になります。
懸念点3：Issueの品質がボトルネックになる
なぜ起きるのか
AIレバレッジモデルはIssueの質に全体の品質が依存します。Issueが曖昧なら実装も曖昧になり、Issueが間違っていれば実装も間違います。
AIはあなたの開発プラクティスの増幅器だ。良いプロセスはより良くなり、悪いプロセスはかつてないスピードで悪化する。
— DORA Report 2025
ベテランがIssue作成を後回しにしたり、「なんとなくわかるだろう」と省略したりすることが、モデル全体を機能不全にします。
対策①：Issueテンプレートの整備
GitHubのIssueテンプレートを用意して、書くべき項目を構造化します。
<!-- .github/ISSUE_TEMPLATE/feature.md -->
## 概要
（この機能が何のために存在するか、1〜2文で）
## 仕様
- （入出力・使用するテーブル・APIの名前）
## 完了の定義
- [ ] （受け入れ条件1）
- [ ] （受け入れ条件2）
## 注意・エッジケース
- （セキュリティ・パフォーマンス・例外処理で気をつけること）
## 実装方針のヒント
- （既存の似た実装へのリンクや参考になるコード）
「完了の定義」を書く習慣は特に重要です。Copilotも人間も、ゴールが明確なほど精度が上がります。
対策②：Issueレトロスペクティブ
実装完了後、元のIssueを振り返る「Issueレトロ」を月1回行います。
振り返りの観点：
- Copilotが迷った（コードに変なパターンが混じった）Issueはどれか？
- レビューで大きく修正が入ったIssueに共通点はあるか？
- 初級エンジニアが「仕様がわからなかった」と言ったIssueはどこが足りなかったか？
悪いIssueのパターンが蓄積されると、テンプレートを改善するヒントになります。
対策③：Issueをレビューする習慣
実装前に、初級エンジニアがIssueを読んで疑問点をコメントする「Issueレビュー」のステップを挟むと、品質の問題を早期発見できます。
「このIssueを読んで実装イメージが持てますか？
わからない部分があれば実装前にコメントしてください」
初級エンジニアが「仕様がわからない」と言いやすい環境を作ることも、Issueの質を上げる一手です。
懸念点4：セキュリティ・設計の見落とし
なぜ起きるのか
AIは「動くコード」を生成することは得意ですが、「安全なコード」「長期的に保守できるコード」を保証しません。
アーキテクチャ・コンプライアンス・セキュリティにまつわる難しい判断は、AIには下せない。ビジネスロジックや倫理的な含意を完全に理解することもできない。その監督と最終判断は、依然として経験豊富なエンジニアの仕事だ。
— Chirag Agrawal, Senior Software Engineer (CIO Magazine, 2025)
特に初級エンジニアは「AIが書いたのだから大丈夫だろう」という過信が生まれやすく、セキュリティの問題を見落とすリスクがあります。
対策①：セキュリティ実装はベテランが必ずレビュー
以下の実装が含まれるPRは、ベテランエンジニアが必ずレビューするルールを設けます。
セキュリティレビュー必須の実装：
- 認証・認可のロジック変更
- ユーザーの個人情報を扱うAPI
- 外部サービスとの連携（支払い・メール等）
- SQLを直接書く箇所
- ファイルアップロード・ダウンロード
PRのラベルで「security-review-required」を付けるなど、ルール化すると見落としを防げます。
対策②：セキュリティチェックリストをIssueテンプレートに組み込む
前述のIssueテンプレートに、セキュリティ観点のチェックリストを追加します。
## セキュリティチェック（該当するものに✅）
- [ ] 認証・認可が必要な処理か
- [ ] ユーザー入力をそのままDBに渡していないか
- [ ] エラーメッセージに内部情報が含まれないか
- [ ] レートリミットが必要か
Copilotへのプロンプトにセキュリティの文脈が入ることで、生成コードの品質も上がります。
対策③：設計レビューを実装前に行う
複雑な機能は、実装前にベテランと「設計レビュー」の場を設けます。Copilotに渡す前の段階で、アーキテクチャのリスクを洗い出しておくことで、後から大きく書き直す手間を防げます。
懸念点5：AIの幻覚コードの混入
なぜ起きるのか
AIは人間よりも速く、壊れたコードを本番に送り出せる。それを止めるのがあなたの仕事だ。
— builder.io, The AI Software Engineer in 2026
2025年のFinal Round AIの調査では、18人のCTOのうち16人が本番環境でAI生成コードによるインシデントを経験したと報告しています。
AIが生成するコードには以下のパターンで問題が混入しやすいです。
よくある幻覚コードのパターン：
- 存在しないメソッドや引数を使う
- 古いバージョンのAPIを使う
- エッジケースで意図しない挙動をする
- 見た目は正しいが微妙にロジックが間違っている
対策①：ローカル動作確認を必須にする
「Copilotが生成したからOK」ではなく、必ずローカルで動作確認してからPRを出すルールを徹底します。
ローカル確認のチェックリスト：
- [ ] 正常系が動作する
- [ ] 異常系（バリデーションエラー等）が正しく動作する
- [ ] ブラウザのコンソールにエラーが出ていない
- [ ] 既存の機能が壊れていない（簡単な目視確認）
対策②：Copilotのコードレビューを必ず通す
PRを作る前に、GitHub Copilotのコードレビュー機能を通します。AIが生成したコードをAIで再確認する「AIのダブルチェック」は、幻覚コードの第一の防衛ラインになります。
Copilotレビューで特に注目すべき指摘：
-
null/undefinedチェック漏れ - 非同期処理の
await忘れ - 例外処理の欠落
- 命名の一貫性のズレ
対策③：テストを先に書いてもらう（TDD的アプローチ）
Copilotに実装を依頼する前に、まずテストを書いてもらう方法も有効です。
「この仕様のユニットテストを先に書いてください。
テストが通ることを確認してから実装してください。」
テストが先にあることで、幻覚コードが実装に混入してもすぐに検知できます。
懸念点を乗り越えた先にあるもの
5つの懸念点を並べると「このモデルは難しい」と感じるかもしれません。しかし、これらの懸念点はAIレバレッジモデル固有の問題ではありません。多くはAIを使わない開発でも潜在的に存在していた問題です。
AIは単にそれを加速・可視化しているだけです。
AIは人間の判断を助けるツールであり、代わりに判断するものではない。アウトカムの責任は、今もエンジニアが負っている。
— Stack Overflow Blog (2026)
懸念点への対策を一度に全部やる必要はありません。チームの状況に合わせて、一つずつ取り入れていくことをお勧めします。
まとめ：懸念点と対策の一覧
| 懸念点 | 主な対策 | 優先度 |
|---|---|---|
| 仕様理解の浅さが蓄積 | 実装レポート＋コードリーディング会 | 高 |
| AI依存によるスキル停滞 | 自力デー＋PRレビューでの理解度確認 | 高 |
| Issueの品質がボトルネック | テンプレート整備＋Issueレトロ | 高 |
| セキュリティ・設計の見落とし | ベテランによるセキュリティレビュー必須化 | 最高 |
| AIの幻覚コードの混入 | ローカル確認必須＋Copilotレビュー | 高 |
AIレバレッジモデルは、IT土方を量産するモデルではありません。
懸念点に向き合い、対策を重ねることで初めて、ベテランの知識と初級エンジニアの行動が同じ方向を向いて動き始めます。
優れた開発者とは、AIで最も多くのコードを生成した人ではない。AIをいつ信頼し、いつ疑い、どう責任を持って使うかを知っている人だ。
— DEV Community, AI Coding Best Practices in 2025
ベテランの知識 × 初級エンジニアの行動 × AIのスピード——この三つが噛み合ったとき、このモデルはより良いプロダクトを作る仕組みになります。
参考文献・引用元
- Addy Osmani, Agentic Engineering (2026)
- Addy Osmani, The 80% Problem in Agentic Coding (2026)
- builder.io, The AI software engineer in 2026 (2025)
- CIO Magazine, Demand for junior developers softens as AI takes over (2025)
- Stack Overflow Blog, Closing the developer AI trust gap (2026)
- DEV Community, AI Coding Best Practices in 2025 (2025)
- Jellyfish Engineering Blog, Will AI Replace Software Engineers? (2025)
- getbeam.dev, The Junior Developer Crisis: How AI Agents Are Reshaping the Talent Pipeline (2026)
- DORA Report 2025
Discussion