生成AIでコードを書くスピードは確かに上がりました。それなのに、リリースまでの期間はあまり縮まっていない――そんな違和感をお持ちのPM・開発リーダーの方は多いのではないでしょうか。原因の多くは、AIが生み出す大量のコードを「確かめる」工程、つまりレビューとテストに作業が滞留していることにあります。国内の調査では、コードレビュー担当者の約9割が、AI生成コードの普及で負担が増えたと答えています。本記事では、AI生成コード特有の欠陥パターンとレビュー観点、レビューを個人技から仕組みに変える運用設計、そして単体・結合・システム・受入の各テスト工程で確かめるべきポイントを、チームを率いる立場から整理します。
AI駆動開発で「レビュー・テスト」がボトルネックになる理由
「書く」速度に「確かめる」体制が追いついていない
AIコーディングツールの普及によって、1人のエンジニアが1日に生み出せるコードの量は大きく増えました。一方で、そのコードを読んで妥当性を判断できるレビュー担当者の数や時間は、ほとんど増えていません。海外の研究では、AI活用によってプルリクエストなどの生産量が20〜30%増えた一方で、レビューと統合にかかる時間は49%増えたと報告されています。また、GitLabが2026年6月に公表した調査（6カ国・1,528人）では、85%が「AIによってボトルネックがコードを書く工程から、レビュー・検証する工程に移った」と回答しています。
つまり、開発のボトルネックは「書く」から「確かめる」へ移っています。コーディングだけを速くしても、その後ろの工程が詰まっていれば、チーム全体のリードタイムは縮みません。
国内のレビュー担当者が抱える負担
国内でも状況は同じです。2026年2月にITエンジニア322人を対象に実施された調査では、レビュー担当者の約9割がAI生成コードの普及で負担が増えたと感じており、67.5%が1カ月あたり3時間以上、レビューや修正の時間が増えたと答えています。具体的な困りごとの上位は次のとおりです。
| 困りごと | 回答割合 |
|---|---|
| 提出者本人がコードの内容を説明できない | 49.5% |
| 動作するが、なぜそうなっているのか意図が分からない | 33.6% |
| エッジケースで正しく動かない | 31.8% |
| 冗長なコードがレビューに積み上がる | 24.5% |
| 既存コードベースとの整合性がとれていない | 20.9% |
| セキュリティリスクのあるコードが含まれている | 17.0% |
上位2つが「説明できない」「意図が分からない」であることに注目してください。コードの誤り以前に、コードの背景にある判断がレビュー担当者に伝わっていないことが、負担増の大きな原因になっています。
「信頼していないのに、毎回は確認していない」というギャップ
SonarSourceが2026年1月に公表した開発者調査（1,100人以上）では、96%がAI生成コードの機能的な正しさを完全には信頼していないと答えた一方で、コミット前に常に検証している人は48%にとどまりました。38%は、AI生成コードのレビューは同僚が書いたコードより手間がかかると答えています。不安は感じているのに、検証が追いつかないまま取り込まれているコードがあるのが実態です。
AI生成コード特有の欠陥パターンとレビュー観点
AIが生成するコードは、一見するともっともらしく、きれいに整っています。そのため、人が書いたコードと同じ感覚で読むと、問題を見落としやすくなります。AIは学習データの中でよく見られる「典型的な書き方」に寄せてコードを作るため、正常系はそれらしく書ける一方で、空の入力や上限値、タイムアウトといった異常系が手薄になりがちです。また、AIはプロンプトで渡された情報しか知らないため、既存システムの設計方針や過去の判断、運用上の制約とは無関係に、「それ単体では正しい」コードを出してくることがあります。こうした特徴を踏まえたレビュー観点を、次の表に整理しました。
| 観点 | チェック項目 |
|---|---|
| 要件・スコープ | 依頼した範囲を超えた変更や、頼んでいない機能追加・リファクタリングが混ざっていないか |
| 存在しないAPI・依存関係 | 呼び出しているメソッドやライブラリが実在し、プロジェクトで使っているバージョンと合っているか。新たに追加された依存パッケージに既知の脆弱性がないか |
| 異常系・境界値 | 空文字・null・0件・上限値、通信失敗やタイムアウト、同時実行などを考慮したエラー処理があるか |
| 既存設計・規約との整合 | 命名規則、エラー処理の方針、レイヤー構成、トランザクションの範囲など、既存コードの決まりごとに沿っているか |
| セキュリティ | 入力値の検証、権限の最小化、パスワードやAPIキーなど秘密情報のハードコードがないか |
| 冗長さ・保守性 | 同じ処理の重複や不要な抽象化がないか。差分が大きすぎてレビューしきれない状態になっていないか |
| 説明可能性 | 提出者が、変更の理由と動作を自分の言葉で説明できるか |
人が見るべきところ、ツールに任せるところ
上の観点をすべて人が目で確認しようとすると、レビュー担当者はすぐにパンクします。依存関係の実在確認や脆弱性、コーディング規約違反、重複コードなどは、静的解析ツールやスキャンツールで機械的に検出できる領域です。一方で、要件に照らして変更が妥当か、既存設計の意図と合っているか、提出者が中身を理解しているかは、人でなければ判断できません。
AIにレビューさせる方法も有効ですが、AIだけで承認を完結させるのは避けるべきです。コードを書いたAIと同じ前提・同じ盲点を共有していると、もっともらしい誤りをそのまま通してしまうおそれがあるからです。ツールとAIで機械的な指摘を先に片付け、人は「判断」が必要な観点に集中するという役割分担が、レビュー負担を減らす出発点になります。
レビューを「個人技」から「仕組み」に変える運用設計
レビュー負担の問題を、レビュー担当者の頑張りやスキルで解決しようとすると、特定のシニアエンジニアに負荷が集中し、その人が休めばチームが止まる状態になります。必要なのは、どのコードもまず同じ関門を通ってから人の目に届く、という流れをチームの仕組みとして作ることです。
3段階のレビューフロー
| 段階 | 内容 |
|---|---|
| 1. 自動チェック | ビルド、既存テスト、静的解析、依存関係・脆弱性スキャンをCIで自動実行する。通らないものは人のレビューに回さない |
| 2. AIによる一次レビュー | セキュリティ、性能、規約などの観点ごとにAIに指摘させ、提出者が修正してから提出する |
| 3. 人によるレビュー | 要件との整合、設計判断の妥当性、既存システムへの影響、提出者の理解度を確認する |
ポイントは、段階1と2を「人のレビューに入るための前提条件」として扱うことです。自動チェックが通っていないコードや、AIの指摘に対応していないコードがレビュー担当者に届く状態をなくすだけで、人が見るべきものはかなり絞り込まれます。
プルリクエストに書かせる4つの項目
「説明できない」「意図が分からない」という困りごとには、プルリクエスト（PR）の書式で対応できます。PRのテンプレートに、次の項目を必須として組み込みます。
- 1. 変更の目的と、対応する要件・チケット
- 2. AIに任せた範囲と、AIに与えた前提（プロンプトの要点）
- 3. 実施したテストの内容と結果（特に異常系・境界値）
- 4. 既存機能への影響範囲と、レビューで特に見てほしい箇所
あわせて、「提出者が説明できないコードはマージしない」をチームの原則として明文化しておくと効果的です。AIが書いたかどうかにかかわらず、コードの責任は提出者が持つという線引きがはっきりします。また、1つのPRの差分量に目安を設け、大きな変更は分割して出すルールにすると、レビューの待ち時間も短くなります。
ハーネスエンジニアリングとの関係
こうした自動チェックやルールを、AIが働く環境そのものに組み込んでいく考え方が「ハーネスエンジニアリング」です。設計品質、セキュリティ、テスト・納品という工程ごとに品質ゲートを置き、AIの出力を自動で検査して差し戻す仕組みを整えることで、人のレビューに届く前の品質を底上げできます。全体像はハーネスエンジニアリングの解説記事で詳しく紹介しています。
AI Dev Camp
AI駆動開発の「検証の仕組み」を、自社の型に
AI Dev Campは、ハーネスエンジニアリングとプロジェクトマネジメントの両面から、AI時代に成果を出せる開発組織づくりを支援する研修プログラムです。レビュー観点やPRルール、品質ゲートを、自社の開発実態に合わせて設計します。
テスト工程別に見るAI生成コードの確認ポイント
前提となる2つの原則
AI生成コードのテストで最初に押さえたいのは、コードとテストを同じAIに、同じ文脈で書かせないことです。同じ前提から作られたコードとテストは、同じ思い込みを共有します。その結果、テストは「仕様どおりに動くか」ではなく「コードが今どう動いているか」をなぞるだけになり、実装の誤りをそのまま正解として固定してしまいます。
もう1つの原則は、テストの期待値を仕様から先に決めることです。何をもって正しいとするかを、コードを生成する前に要件・仕様の側で定めておけば、AIの出力をその基準で判定できます。テストは欠陥があることを示せても、欠陥がないことは証明できません（ソフトウェアテストの7原則）。だからこそ、AIが苦手とする領域を狙ってテストを設計することが重要です。
工程ごとに確かめること
| テスト工程 | AI生成コードで特に確かめること |
|---|---|
| 単体テスト | 境界値・異常系のテストケースがそろっているか。AIが書いたテストが実装の動作をなぞるだけになっていないか（期待値の根拠が仕様にあるか） |
| 結合テスト | モジュール間のインターフェースの前提（データ形式、エラー時の戻り値、呼び出し順序）が食い違っていないか。AIが既存モジュールの仕様を推測で補っていないか |
| システムテスト | 性能・負荷、障害時の振る舞い、ログ出力など、単体のコードからは見えない非機能要件を満たしているか |
| 受入テスト | 業務の流れの中で要件どおりに使えるか。AIが曖昧な要件を「それらしく」解釈して作った箇所が、利用者の意図とずれていないか |
AIは個々の関数を書くのは得意ですが、システム全体の文脈を知らないまま部分を作るため、問題は工程が上がるほど「部品同士のつなぎ目」や「要件の解釈」に現れやすくなります。結合テストの観点やテストケースの作り方は結合テストの解説記事、受入テストの進め方は受入テストの解説記事も参考にしてください。
なお、回帰テストなど繰り返し実行するテストは自動化し、CIの自動チェックに組み込むのが基本です。どこから自動化するか、失敗しない進め方についてはテスト自動化の解説記事で整理しています。
検証体制を定着させるためにPM・リーダーがやること
レビューフローやPRのルールは、作っただけでは定着しません。現場が忙しくなるほど、「今回だけは」と省略されがちだからです。仕組みを回し続けるために、PM・リーダーが押さえておきたいのは次の3点です。
レビュー負荷を見える化する
PRが作られてからマージされるまでの時間、レビュー待ちの件数、差し戻しの回数、レビュー担当者ごとの担当件数を定期的に確認します。特定の人に負荷が偏っていないか、どの段階で滞留しているかが分かれば、自動チェックを強化すべきか、レビュー担当を増やすべきか、PRの粒度を見直すべきかを判断できます。感覚ではなく数字でボトルネックを捉えることが、経営層への説明材料にもなります。
「完了の定義」に検証を含める
AI駆動開発では、コードが書き上がった時点を「完了」と捉えると、進捗が実態以上に良く見えてしまいます。タスクの完了条件に「自動チェックの通過」「必要なテストの実施」「レビュー承認」を含め、見積もりにもレビュー・テストの工数を織り込んでおくことが大切です。見積もりや進捗報告の見直し方はAI駆動開発でPMの仕事はどう変わるかを解説した記事でも触れています。
レビューの指摘を観点・ルールに還元する
人のレビューで見つかった指摘は、その場で直して終わりにせず、観点リストやAIに守らせるルール、自動チェックの項目に反映していきます。同じ指摘を2回しないための改善を積み重ねると、人が見るべき範囲は徐々に狭まり、シニアエンジニアの暗黙知がチームの共有財産に変わります。若手メンバーにとっても、観点リストはAI生成コードを読む力を身につける教材になります。
導入イメージ ― AI Dev Campで自社の検証体制をつくる
AI Dev Campでは、汎用的なチェックリストを配布するのではなく、自社の実際の開発に合わせて検証の仕組みを設計します。
- 事前ヒアリング
- レビュー待ちや手戻り、リリース後の不具合など、自社で実際に起きた問題をリバースエンジニアリング（実例を分解して原因と構造を明らかにする手法）し、どの工程で何が見落とされているかを特定します。
- AIドリブン研修
- AI駆動開発の専門企業Hexabase社との技術アライアンスのもと、レビュー観点、PRルール、自動チェックの品質ゲートを、受講者自身がハーネスとして作り込みます。
- プロマネ研修・定着支援
- レビュー負荷の見える化や完了の定義の見直しなど、検証体制を回し続けるためのマネジメントを、SOLIZE HDからライセンス供与を受けたプログラムをもとに実践的に学びます。
よくある質問
Q. AI生成コードのレビューは、AIに任せてもよいですか？
A. 一次レビューをAIに任せるのは有効ですが、承認まですべてをAIに委ねるのは避けるべきです。コードを書いたAIと同じ盲点を共有するおそれがあるため、要件や設計判断の妥当性は人が確認する役割分担にします。
Q. AIにテストコードを書かせても問題ありませんか？
A. 書かせること自体は問題ありませんが、実装と同じ文脈で書かせるのは避けてください。テストの期待値は仕様から先に決め、AIが書いたテストが実装の動作をなぞるだけになっていないかを確認することが重要です。
Q. レビューの負荷はどう測ればよいですか？
A. PR作成からマージまでの時間、レビュー待ち件数、差し戻し回数、担当者ごとの件数が基本の指標です。どこで滞留しているかが分かれば、自動化・体制・PRの粒度のどこを見直すべきか判断できます。
Q. 小規模なチームでもできることはありますか？
A. PRテンプレートに「変更の目的」「AIに任せた範囲」「実施したテスト」を書く欄を設けるだけでも効果があります。CIでの静的解析と既存テストの自動実行を組み合わせれば、少人数でもレビューの質を保ちやすくなります。
まとめ
- AI駆動開発のボトルネックは「書く」から「確かめる」へ移っており、レビュー担当者の頑張りだけでは追いつきません。
- 自動チェック→AIの一次レビュー→人のレビューの3段階と、PRに目的・AIの担当範囲・テスト内容を書かせるルールで、検証を仕組みにします。
- コードとテストを同じAIに書かせず、単体・結合・システム・受入の各工程でAIが見落としやすい点を狙って確かめることが品質の鍵です。
お問い合わせ
AIで速くなった開発を、品質まで含めて成果に
「レビューが追いつかない」「AI生成コードの品質に不安がある」など、検討段階のご相談も歓迎しています。現状の課題整理からご一緒します。
出典：@IT「『なぜ動くか分からないコードが多過ぎ』 生成AI一般化でレビュワーの9割が直面する負担増の実態」（2026年6月）／GitLab「2026 AI Accountability Report」プレスリリース（2026年6月）／SonarSource「State of Code Developer Survey」（2026年1月）／TechRadar「AI agents are great at writing new code — but then the human bottleneck slows everything down」
