こんにちは。ACS事業部 SAT室の竹江です。
2026年4月現在、弊チームでは、GitHub Copilot を導入しており、PR（プルリクエスト）レビュー用のエージェント(Custom agents for GitHub Copilot)を作成して実際のコードレビューで活用しています。
「定型的な指摘はAIに任せれば、人間は本質的な設計議論に集中できるはず」——そんな期待を胸に始めたのですが、いざ運用してみると「レビュー負荷が思うように減らない」という壁にぶつかりました。
原因を調べていくと、AIによるコードレビューの運用設計に根本的な見直しが必要なことに気づきました。この記事では、そこから得た気づきを共有します。
- なぜAIレビューを入れてもレビュー負荷は減らないのか
- なぜコンテキストを整備するとレビュー負荷が増えるのか
- どうすれば実際に効果が出るのか
試行錯誤の記録として、同じ悩みを持つ方の参考になれば幸いです。
- AIによるレビューを入れても負荷が減らない理由
- ドキュメントを整備するほどレビュー負荷が増えるという逆説
- 解決策：AI活用のシフトレフトという発想
- 似ているようで違う「2つのエージェント」の役割分担
- セルフレビューフローの追加で何が変わったか
- まとめ：【後ろで発見する】から【前で解決する】への視点の転換
- ACS 事業部のご紹介
AIによるレビューを入れても負荷が減らない理由
コンテキストという壁
AIはコードの表面的な問題——スタイル違反、typo、よく知られたバグパターン——を指摘するのは得意です。一方で、「なぜこの実装になったのか」という背景情報（コンテキスト）には、まだ弱さがあります。
- 仕様変更の経緯
- チーム内で過去に下した決定とその背景
- 「技術的負債と知りつつも、このタイミングではやむを得ない」という判断
こうしたコンテキストは、そもそもドキュメントとして整備してAIに渡すこと自体が難しく、弊チームでも十分にカバーできていません。
そのためAIのレビュー指摘に対して「この指摘は本当に正しいのか？」「仕様と矛盾していないか？」を人間のレビュアーが毎回確認する——いわば「正誤判定（ファクトチェック）」という中間工程が新たに生まれます。
AIレビューの導入によって、コードの表面的な問題を素早く洗い出せるようになり、その点では確かに時短になります。
しかし、AIが出したコメントを読み、コンテキストを踏まえて承認・却下する「ファクトチェック」プロセスが残り続けるため、結果的にレビュアーの負荷があまり減らないという状況が生まれていました。
ドキュメントを整備するほどレビュー負荷が増えるという逆説
「それならAIに提供するコンテキストをもっと充実させよう」という発想は自然かと思います。ところがこれが、思わぬ逆効果をもたらしました。
弊チームでは、コンテキストの充実のためコーディング規約やテスト戦略等をカスタム指示ファイル(GitHub Copilotリポジトリカスタム指示)として整備し、PRレビュー用エージェントにはそれらを読み込むよう指示しました。
その結果、確かにAIの指摘の精度とより多くの問題を網羅できるようになりました。しかし問題は、人間のレビュー負荷も同時に増えることです。
AIに提供するコンテキストを充実させる
→ 指摘が増える
→ レビュアーの「これは対応すべきか？」の判断回数が増える
→ レビュー負荷が増える
レビュアーは、AIが出した指摘の一つひとつについて「本当に対応が必要か」「優先度はどのくらいか」を判断しなければなりません。「AIを賢くするほど、人間がやることも増える」という構造が生まれてしまいます。
これは完全に意図しない副作用でした。
解決策：AI活用のシフトレフトという発想
行き詰まったとき、視点を変えてみました。
「なぜレビュー負荷が減らないのか？」を突き詰めると、根本的な問題が見えてきます。PRが提出された時点で、すでにコードに問題が多く含まれているからです。
そこで着目したのが「シフトレフト」という考え方です。これは、テストやレビューといった品質確認の工程を、後工程（右側）から、実装などのより早い段階（左側）へ「前倒し」することを指します。
それならば、問題を「後ろで発見する（レビュー工程）」のではなく「前で解決する（実装工程）」発想に切り替えられないか、と考えました。
そこで実装者が、PRを出す直前に変更点をセルフレビューするフローを追加しました。
具体的には、セルフレビュー用のエージェントを作成し、カスタム指示ファイルを参照してコードをレビューするように指示しました。
結果、PR提出前の段階で多くの問題を解消することができPRの初期品質が向上。その結果、レビュアーの負荷を大幅に減らすことができました。
似ているようで違う「2つのエージェント」の役割分担
ここで、「セルフレビューもPRレビューも、AIがやることは同じではないか？」と思われるかもしれません。しかし、弊チームではあえて役割を明確に分けています。
| 項目 | 実装者用（セルフレビュー） | レビュアー用（PRレビュー） |
|---|---|---|
| レビュー対象 | ブランチ内のコード変更点そのもの | コード変更点 ＋ PRの周辺情報 |
| チェック内容 | 規約違反、バグ、テストの不足など | セルフレビューと共通内容 ＋ 「PR概要説明と実装に矛盾がないか」、「前回の指摘に対応しているか」 |
セルフレビュー用のエージェントは、いわば「磨き上げ」担当です。一方で、レビュアー用のエージェントは、コードそのものだけでなく「PRの整合性」までチェックする「ゲートキーパー」の役割を担わせています。
セルフレビューフローの追加で何が変わったか
実際にこのフローに切り替えてみた結果を共有します。
PRの初期品質が上がった
実装者がセルフレビューを行ってからPRを出すため、提出時点でのコード品質が格段に向上しました。スタイル違反や単純な規約違反はほぼゼロの状態でPRが届くようになりました。
レビュアーが本質的な議論に集中できるようになった
コード規約違反などのコードの表面的な問題が解消された状態のPRが届くため、レビュアーはすぐに「設計の意図はこれで正しいか」「ユーザー体験の観点で問題はないか」といった、本来人間が議論すべき話題に入れるようになりました。
これは当初の目論見——「人間は本質的な議論に集中できる」——が、ようやく実現した形です。
まとめ：【後ろで発見する】から【前で解決する】への視点の転換
「AIを入れたのにレビュー負荷が減らない」と感じているなら、それはAIの精度の問題ではなく、AIレビューを実施する工程の問題かもしれません。
レビュー工程にAIを置くかぎり、ファクトチェックと判断回数からは逃げられません。でも、ほんの少し視点を変えて「実装工程に前倒しする」だけで、レビュー負荷は大きく変わります。
弊チームの経験をまとめると、AIを活用してレビュー負荷を減らすためのステップは以下の通りです。
- コーディング規約やテスト戦略等をカスタム指示ファイルとして整備する （ここを共通の『正解』とする）
- そのファイルを、セルフレビュー用・レビュアー用のエージェントの両方に参照させる
- チームのルールとして「PR提出前にセルフレビューを実施する」を追加する
「AIをもっと賢くする」より「AIを一工程、前に置く」——その発想の転換が、ボトルネックとなっていたレビュー負荷を軽減する最初の一手になるはずです。
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。 ※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
