【2026年最新】コード生成エージェント×論文4選｜「レビューが追いつかない」「テストが薄い」を解く最前線

【2026年最新】コード生成エージェント×論文4選｜「レビューが追いつかない」「テストが薄い」を解く最前線 AIエージェント
2026.09.18

コードの一部を補完してくれるAIから、Issueを読んで修正し、プルリクエスト（PR）まで出してくれる「コード生成エージェント」の時代へと移りつつあります。リポジトリを読み、コードを直し、テストを走らせるところまで任せられる製品が各社から出ており、AIが自分でPRを作ること自体は珍しくなくなりました。

しかし、実際にチームへ導入すると「AIが出すPRのレビューに人間の時間が取られる」「テストが十分なのか分からない」「ベンチマークのスコアほど実務で役に立たない」といった悩みに直面します。この記事では、各社の公式ドキュメントと OWASP・OpenSSF の公開資料をもとに、コード生成エージェントの仕組みと、その中でレビューとテストがどこに置かれているかを整理します。そのうえで、レビュー・テスト・評価の3つの観点から論文4本を紹介します。結論を先に言うと、「完成の定義」をテストとして人が先に決め、PRは変更行が本当にテストされているかで確かめ、AIレビューは自分たちの規約に沿わせるのが基本です！

コード生成エージェントとは何か：Issue から PR までを自走する

隔離された環境で「読む・直す・試す」を繰り返す

コード生成エージェントは、指示を受けると自分でリポジトリを調べ、複数のファイルを書き換え、テストなどのコマンドを実行して結果を確かめます。各社の公式ドキュメントでは、次のように説明されています。

  • GitHub Copilot cloud agent: GitHub Actions を使った一時的な開発環境の中でコードを調べ、変更し、自動テストやリンターを実行して、ブランチ上の変更からPRを作ります。IDEの中で動く「エージェントモード」とは別の機能だと明記されています（GitHub「About GitHub Copilot cloud agent」）
  • Claude Code: コードベースを読み、ファイルを編集し、コマンドを実行するツールで、ブランチの作成からPRの作成までgitの操作も行えます。プロジェクトに置いた設定ファイル（CLAUDE.md）に、コーディング規約やレビューのチェックリストを書いておけます（Anthropic「Claude Code overview」）
  • Codex（クラウド）: タスクごとに独立した作業環境を用意し、利用者は変更とテスト結果を確かめてからコミットやPRの作成に進みます（OpenAI「Codex Cloud」）

どの製品も「エージェントが作業し、人が確かめて取り込む」分担が前提です。

歯止めは「人のレビュー」と「権限の絞り込み」

GitHub のドキュメントでは、Copilot cloud agent が作ったPRは人がレビューしてマージする必要があり、エージェント自身はPRを承認もマージもできないと説明しています。さらに、エージェントが書き込めるのは専用のブランチだけで、作業を頼んだ本人はそのPRを承認できません。CIのワークフローも、既定では書き込み権限のある人が承認するまで動きません（GitHub「Risks and mitigations」）。

Claude Code も、手動で承認するモードでは読み取り専用の権限から始まり、ファイルの編集やテストの実行の前に利用者へ確認します。承認前にコードとコマンドを確かめる責任は利用者にある、とも書かれています（Anthropic「Security」）。エージェントに渡す権限の話は、LLMエージェントのセキュリティの記事で詳しく扱っています。

レビューとテストは「省略できない工程」

OWASP は「AIが生成したコードへの不適切な信頼」を挙げた

OWASP Top 10 の2025年版は、本体の10項目とは別の「Next Steps」で、選外ながら取り組む価値がある問題を3つ挙げており、その X03 が「AIが生成したコードへの不適切な信頼（いわゆるバイブコーディング）」です。AIが生成したコードは人が書いたコードより脆弱性を含みやすいことがよく知られているとしたうえで、提出するコードはAIが書いたものでもすべて読んで理解し、責任を持つこと、AIの助けを借りたコードはできれば自分の目と静的解析などのツールの両方で徹底的にレビューすることを勧めています（OWASP「Top 10:2025 Next Steps」）。

OpenSSF は「レビューとテストの代わりにはならない」と明記

オープンソースのセキュリティに取り組む OpenSSF も、AIのコーディング支援向けのガイドで、AIが生成したコードはコードレビュー、テスト、静的解析といった工程を飛ばす近道ではないと述べています。AIはエラー処理を無視するなどの問題を持ち込むことがあるとして、AIへの指示ファイルに「重要な関数には、失敗すべきときに安全に失敗することを確かめるテストも作る」といった内容を書くことを勧めています（OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」）。

つまり、エージェントを入れてもレビューとテストは人の仕事として残ります。ここからは、それをどう回すかに取り組んだ論文を見ていきます。

研究で見る「レビュー」と「テスト」の回し方

📄 論文: チームの規約に沿わせると、AIレビューの指摘が採用されやすくなる

SGCR: A Specification-Grounded Framework for Trustworthy LLM Code Review（Kai Wang ほか、2025年12月投稿・2026年1月改訂、arXiv:2512.17540）は、ASE 2025 採録（abs のコメント欄の記載）です。

対象は、HiThink Research 社の本番の Java 開発プロジェクトです。経験のある開発者が業務に合わせて書いた140個のルールを用意し、自社で動かした32Bパラメータの言語モデルでレビューを行い、200人の参加者の開発の中で比べました。比較の相手は、同じモデルにルールを渡さずレビューさせた場合です。

LLMのレビューには、一般論的な指摘や業務の文脈に合わない指摘が混ざりがちです。この論文の仕組みは、規約から導いたルールをモデルに渡して確実に当てはめる経路と、モデルが自由に問題を探したあとで関連するルールを検索して本当に問題かを検証する経路を組み合わせます。指摘が最終的なコミットに反映された割合（採用率）は、ルールなしの22%に対して42%に上がりました。

現場にとっての意味は、少なくともこの環境では、同じモデルでも自分たちの規約を言葉にして渡すだけで指摘が採用されやすくなった、ということです。他の環境での効果は自分たちで確かめます。ルール集を保守する手間は課題として挙がっています。

📄 論文: 人がテストを書き、AIがそれを通す分業

TDFlow: Agentic Workflows for Test Driven Development（Kevin Han ほか、2025年10月投稿・2026年1月改訂、arXiv:2510.23761）は、EACL 2026 採録（abs のコメント欄の記載）です。

対象は、Django などの Python のオープンソースから集めた公開ベンチマーク SWE-Bench の問題です。通常は隠されている「人が書いた正解判定用のテスト」をあえてシステムに渡し、そのテストを通せるかを測りました。修正案の作成・デバッグ・修正案の手直しを別々のサブエージェントに分け（テストがなければテスト作成も別のサブエージェントが担当）、1つのエージェントが長い文脈を抱え込まないようにしたのが特徴です。

修正側に GPT-5 を使い、検証済みの500問（SWE-Bench Verified）で試した結果、人が書いたテストを渡すと94.3%の問題を解けた一方、テストもAIが自分で作る設定では68.0%にとどまりました。人が書いたテストを渡した実行（2つのベンチマークで計800件）を人手で調べたところ、テストを通すためだけの不正な修正が7件見つかり、これらは失敗として数えています。著者らは、自動修正の最大の壁は「バグを正しく再現するテストを書くこと」だと結論づけています。

現場にとっての意味は、何ができたら完成かをテストとして人が先に書けば、エージェントが成果を出しやすくなるということです。ただし、テストが間違っていても後から直す仕組みはないと著者ら自身が述べており、テストの正しさは人が担保する必要があります。

研究で見る「テストの薄さ」と「スコアの当てにならなさ」

📄 論文: AIが出したPRは、どこまでテストされているか

Test Coverage Analysis of Agentic Pull Requests（Atish Kumar Dipongkor ほか、2026年7月、arXiv:2607.18057）は、ICSME 2026 掲載予定（abs のコメント欄の記載）です。

対象は、5種類のコード生成エージェントが GitHub 上の実際のリポジトリに出したPRを集めた公開データセットのうち、Java 532件と Python 4,350件です。テストの変更を含むかはこの全件で調べ、網羅率（カバレッジ）は、マージ済みでビルドと計測ができた Java 213件・Python 1,664件のPRについて、研究者がリポジトリのテストを実行して測りました。

本体のコードを変えたPRのうち、テストも変更していたのは49.6%で、約半数はテストに手を付けていませんでした。既存のテストで実行された変更行の割合は、Java で61.5%、Python では27.0%にとどまり、Python では64.8%のPRで変更行が1行も既存のテストで実行されていませんでした。エージェント自身が書いたテストで網羅率が上がったPRも少数派です。また、try や catch のブロックなどのエラー処理は、両方の言語で共通して8割以上の行がテストで実行されていませんでした。

現場にとっての意味は、「CIが通った」は「変更がテストされた」と同じではない、ということです。OWASP Top 10:2025 でも「例外的な状況の不適切な処理」が10項目の1つに入っており（OWASP「Top 10:2025」）、エラー処理はレビューで重点的に見たい箇所です。

📄 論文: ベンチマークの高いスコアには「暗記」が混ざっている可能性

The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason（Shanchao Liang ほか、2025年6月投稿・2025年12月改訂、arXiv:2506.12286）は、査読前の論文（プレプリント）です。

対象は、OpenAI と Anthropic の10個のモデルで、各社のAPIを既定の設定で使いました。SWE-Bench Verified（12個の Python リポジトリから集めた500問）と、SWE-Bench に含まれない有名な7つのリポジトリから作った245問などを比べています。課題は、リポジトリの中身を見せずに Issue の文章だけからバグのあるファイルを当てるなど、「本来は解けないはずの」診断用の問題です。

ファイルを当てる課題では、正答率が SWE-Bench Verified で最大76%だったのに対し、SWE-Bench に含まれない7つのリポジトリの課題では最大53%にとどまりました。関数を書かせる課題でも、正解のコードと5トークン連続で一致する割合が SWE-Bench Verified で最大約35%と、同じリポジトリの新しい Issue や他のベンチマークの最大約18%より高くなりました。著者らは、学習データにベンチマークの問題や正解が含まれていた可能性を指摘しています。

現場にとっての意味は、公開ベンチマークのスコアは自社のコードでの実力をそのまま表すとは限らない、ということです。製品は自社のリポジトリで試して選びます。

現場でやること

「完成の定義」をテストとして先に書く

エージェントに任せる前に、何ができたら完了かを人がテストとして用意します。バグ修正なら、まずそのバグを再現するテストを書きます。テストはエージェントが書き換えられないように守りましょう。

PRは「CIが緑」ではなく「変更行が実行されたか」で見る

  • PRの差分ごとに、変更行がテストで実行されたかをカバレッジで確かめる
  • エージェントが追加したテストが変更行を実行しているかを見る
  • エラー処理の分岐は、失敗すべきときに安全に失敗するかをレビューで重点的に確かめる

AIレビューには自分たちの規約を渡す

コーディング規約やレビューの観点を短いルールにまとめ、エージェントやAIレビューの指示ファイルに書きます。規約を外部の資料と照らし合わせて使いたい場合は、RAG の記事も参考になります。ルールは採用されなかった指摘を見直しながら少しずつ増やします。

製品選びは自社のリポジトリで試す

公開ベンチマークのスコアは参考程度にとどめます。過去に人が直した自社のバグを修正前の状態から各製品に解かせ、正しく直せたか、テストを付けたか、レビューの手間を比べます。

コード生成エージェント導入の鍵は次の3点です

  1. 「完成の定義」をテストとして人が先に書く
    通すべきテストがあれば、エージェントが成果を出しやすくなります。バグ修正では再現テストを最初に用意し、テストの正しさは人が担保します。
  2. PRは「変更行がテストされているか」で確かめる
    差分のカバレッジを確認し、エラー処理のような手薄になりやすい箇所を重点的にレビューします。
  3. AIレビューは規約に沿わせ、製品選びは自社のコードで測る
    論文の環境では、規約に基づく指摘のほうが採用されやすくなりました。公開ベンチマークのスコアは参考にとどめ、自分たちのリポジトリで試して判断します。

まとめ：コード生成エージェントは「書かせる」から「検証の仕組みごと設計する」へ！

コード生成エージェントは、隔離された環境でリポジトリを読み、コードを直し、テストを走らせてPRを出すところまで来ました。一方で、各社の仕組みも OWASP や OpenSSF の資料も、最後に確かめて責任を持つのは人だという前提に立っています。論文からは、テストを人が先に決める、変更行のカバレッジを見る、規約に沿ってレビューさせる、という具体的な手がかりが見えてきました。

まずは直近のAIのPRを数件選び、変更行が既存のテストで実行されているかを確かめてみてください。どこから手を付けるべきかが見えてきます！

参考文献

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、GitHub Copilot のPRを作る機能の名称、ベンチマークの暗記を調べた論文の一致率の単位と比較対象、テストの網羅率を調べた論文のエラー処理の記述の誤りを修正しました

タイトルとURLをコピーしました