目次
はじめに
こんにちは。 開発本部開発1部トモニテ開発部所属の庄司(@ktanonymous)です。
最近では、AI の性能向上や開発フレームワークの進化による開発スピードの向上に伴い、 これまで以上に大量のコードをレビューしていく中で、負荷が大きくなっていると感じています。 本記事では、どういった点で負担を感じているのか、それに対してどのようなアプローチができるのか、 自分なりに考えてみたことをまとめていきたいと思います。
AIの発展と開発スピードの変化
AIの性能向上という面では、CursorやClaude Codeをはじめとするコーディングエージェントやモデル自体の進化により、 AIにコンテキストを渡して実装を依頼するだけで、実装計画の策定からコーディング、テストの追加までを自律的に行わせることが現実的になっています。
さらに、こうしたAIの性能向上に加えて、ドキュメント駆動開発／仕様駆動開発のような実装以外のフェーズにもAIを組み込むフレームワークの発展も目覚ましいです。 以前の記事ではAI駆動開発を見据えたドキュメント運用について整理してみましたが、 弊社の別チームでもエンジニアが仕様書を主導して書くことでAIによる設計・実装を加速させる取り組みが紹介されています。
実装フェーズのスピードアップに加え、ドキュメント運用や仕様策定といった上流工程にもAIが入ることで、開発フロー全体が大きく加速しています。 こうした変化自体は非常にポジティブですが、一方で開発フローの中で人間が直接対応している部分がボトルネックとしてこれまで以上に顕在化しているように感じています。
PRレビューの負荷
レビューに要する時間の増加
レビュー対象には大きく分けると、以下の2種類に分類できます。
- 自分のアウトプット
- 他のメンバーのアウトプット
また、個人的に、AIの出力を100%信頼できる状況にはまだなっていないと思っていて、 その他にもレビュー活動は以下のような役割を担ってくれているのが現状なのではないかと考えています。
- コードの品質担保: バグや設計上の問題を早期に発見する
- チーム内の知識共有: 他のメンバーの変更を把握し、コードベースへの理解を深める機会になる
- コードベースの一貫性維持: チームとしてのコーディング方針や設計思想を保つ
- ビジネスロジックの妥当性判断: 仕様やドメイン知識に基づく判断は、プロジェクトの文脈を深く理解している人間でないと精度が出しにくい
実装速度の向上に伴い、PRの作成頻度は高まっていますし、適切にAIをコントロールしないと1回の変更量や粒度なども大きくなってしまいがちです。
実際に自分の業務の中でも、コーディングとレビューの比率が以前までは 7:3 程度だったのが、最近は 3:7 くらいになっているように感じています。
特に、自分のアウトプットに関しては、自分は指示役でAIがアウトプットするようになって他の人のアウトプットと近い感覚でレビューをするようになりました。
その結果、ここにかかる労力や時間も少なからず増えています。
そのような背景もあり、レビューがボトルネックになっているという感覚やレビューを通じての疲労感を以前にも増して感じています。
理想的にはPRレビューを全てAIに委譲できれば、レビュー待ちによるブロッキングはなくなります。 しかし、先ほども述べたように、現時点で人間のレビューを完全になくすのは難しいと感じています。
一方で、レビューの全てが人間にしかできないわけではないとも思っています。
「レビューをなくす」のではなく「レビューの負荷を分解して、適切に分担する」という考え方で、
機械的にチェックできる部分についてはツールやAIに委譲し、本質的なレビューに人間が集中できるようにする体制を多くの人が整備しているのではないかと思います。
レビューの何が負荷なのか
そもそもレビューのどういった部分に負荷を感じているのかを考えた時、 個人的には、最近レビューをしている中で、以下のような辛みポイントがあるかなと感じています。
- レビューするべきものが多い
- コンテキストの把握（PRの背景や仕様の確認）
- （以前より）レビューの優先度を考えないといけない
1つ目はシンプルで、レビューするべきものが多いほど負担が増えます。
2つ目に関しては、1つ目とも相まって、時間に対して把握する必要のあるコンテキストが多くなっているので、
これまで以上に負荷のある作業となっています。
3つ目に関しては、レビューするべきものが複数ある状況において、どれからレビューしていくのか、
その中でもどこからレビューしていくのか、優先度や効率を以前よりも意識しないといけないように感じています。
レビュー負荷への対処
ここで、仕組みの面での対処の例を挙げてみます。
仕組みでの対処
ルールやCIを整備することでレビュー負荷の軽減が見込めます。
コーディング規約・スタイル linterやformatterの導入・徹底はやはり重要で、CIでの強制など、 レビュー以前の段階で静的検査が完了していれば、レビュアーはその部分を気にする必要がなくなります。
テストの充実化 テストが要件を適切に表現できていれば、レビュアーとしても 実装が正しく動くか、要件を満たしているのかを判断しやすくなります。
AIレビューツールの活用 GitHub ActionsなどでAIによる自動レビューを組み込むことで、 人間のレビュアーが確認すべきポイントをある程度絞ることができます。
このように、ルールやCIの整備によって「本質的な判断」に集中できる状態に近づけられます。 （なお、レビュー対象の粒度や背景となる情報など、レビュアーに与えるコンテキストの調整によっても負荷の軽減は可能であり、 人間がAIをコントロールして、これらの仕組みがより効果的に働くように意識することも重要だと思います。）
Claude Code plugin を活用したレビューの効率化
個人的には先に挙げたような点がレビューをしていて辛いなと感じていたので、
仕組みでの対処とは別に、Claude CodeのカスタムPluginを利用してレビューの効率化を図っています。
Claude Codeには公式のcode-reviewプラグイン1が提供されています。
これの構成を踏襲しつつ、個人的に以前から利用しているレビューフォーマットやドキュメントなどの外部コンテキストの取り込みを含めたプラグインを作成して利用しています。
1次レビューをAIに任せるようにしたことで、自分の作業をブロックせずにレビューの基盤を整理しておくことができるようになり、
全体感や内容の把握、優先度の判断に要する負担がある程度減らせました。
エージェント構成の概要
プラグインの処理は、情報収集・外部コンテキスト取得から、専門エージェントによる並列レビュー、信頼度の再評価を経て、レポート生成に至る流れになっています。
レビュー結果の出力イメージ
プラグインは、レビュー結果をマークダウン形式のレポートとしてローカルに出力します。 GitHubにコメントを直接投稿しない設計にしており、レビュー結果を自分で確認・判断してからフィードバックを行うことを想定しています。
実際のレポートは以下のような構成で出力されます。
# PR Review: everytv/repo#123 — PRタイトル ## 変更の概要 ### 背景 / 変更内容 / 実現できる根拠 / メリット・デメリット ## 指摘事項 ### Critical — 信頼度 90-100 ### Important — 信頼度 80-89 ### Suggestion — 信頼度 60-79 ## 良い点 ## レビューガイド ### 推奨レビュー順序
以下では、このレポートの主要な部分がどのように生成されるかを簡単に紹介します。
仕組み
コンテキストの自動収集
レビュー時の「コンテキストの把握」の負荷を軽減するために、PRの基本情報（概要・コミット履歴・変更ファイル一覧）に加え、
PR本文に含まれるissueやConfluenceなどの関連リンクを解析して外部コンテキストを取得します。
指摘事項
指摘事項は、構成図に示した3つの専門エージェント（code-reviewer、test-analyzer、design-reviewer）が並列にレビューを行い、その結果を信頼度に基づいてフィルタリングすることで生成されます。
code-reviewerはバグ検出やセキュリティ、パフォーマンスの観点で、test-analyzerはテストカバレッジや設計品質の観点で、design-reviewerは設計原則や既存コードとの整合性の観点で、それぞれレビューを行います。 公式プラグインと同様に0-100の信頼度スコアを導入し、confidence-verifierというエージェントが各指摘を独立した視点で再検証します。 レビュー結果のレポートには、信頼度スコアおよびその判定理由を記述させています。
レビューガイド レポートの「レビューガイド」では、推奨レビュー順序と各ファイルの注目ポイントを示します。 どこからレビューすればよいかの判断をツールに任せることで、優先順位付けの負荷の軽減を狙っています。
複数PRの並列レビュー
レビューするべきものが多い場合に対応するため、batch-reviewスキルも用意しています。
複数のPR番号を指定すると、各PRを独立したエージェントが並列にレビューしてリポジトリごとのディレクトリに個別出力します。
まとまった数のPRをレビューする際に、事前にポイントを把握するための情報源として活用しています。
課題
プラグインはあくまでレビューの「補助」であり、完璧なレビューではありません。 そのため、ツールの出力をそのまま信頼してレビュー完了とはせず、内容を確認する必要があります。
おわりに
今回の記事では、PRレビューの負荷について自分が感じていることや、それに対して取り組んでいることを紹介しました。
AIの活用が進む中で、レビューの量やコンテキストの把握、優先順位付けといった部分に辛さを感じるようになりましたが、 仕組みの整備やプラグインの活用で少しずつ改善できている実感があります。 まだまだ試行錯誤の段階ではありますが、同じような課題感を持っている方の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました。
