レビューが開発の壁になる時代——AIエージェント企業が始めるべき『セルフレビュー』という仕組み

「レビューする時間」が「書く時間」を超えた

以前の記事「AIエージェントを並列実行する『エージェントマネージャー』という働き方」で、複数のAIエージェントを同時に走らせる働き方が広がっていること、そしてボトルネックが技術力からレビュー速度に移っていくことをお伝えしました。今回はその「壁」の内側を、もう一段深く掘っていきます。

ある2026年の調査記事によれば、開発者がAI生成コードのレビューに使う時間は週11.4時間に達しており、自分でコードを書く時間の9.8時間を上回っています。2024年はこの順序が逆だったことを考えると、たった2年で仕事の重心が入れ替わったことになります。私たちがFDEとして複数のクライアントの内製化を支援する中でも、まったく同じ現象を見てきました。実装のスピードは上がったのに、チーム全体の開発スピードはさほど上がっていない——その原因の大半が、レビューという工程に集約されているのです。

同じ調査では、「レビュー疲れ」が見落とされがちな生産性の落とし穴として指摘されています。AIが生成するコードの量が、人間がきちんとレビューできる量を上回ると、チームは「雑にマージする」か「PRキューが無限に積まれる」かのどちらかに陥る、というものです。正直に申し上げると、私たちも最初はこの構造を甘く見ていました。エージェントの台数を増やせば、単純にアウトプットが増えると考えていたのです。実際には、レビューという「一人にしかできない工程」がすぐに飽和し、量を増やすほど手戻りのリスクが上がっていきました。

なぜレビュー負荷は減らないのか——「コンテキストの壁」

ここで一つ疑問が生まれます。AIにレビューさせれば、人間のレビュー負荷は減るはずではないか、という疑問です。実際、複数のチームがAIによる一次レビューを導入しています。ですが、それでも負荷は思うように減っていません。

ある技術ブログの分析では、AIによるレビューを入れても負荷が減らない理由として「コンテキストという壁」が挙げられています。レビューをするAIエージェントは、実装をしたAIエージェントが持っていた背景情報——「なぜこの実装を選んだか」「他にどんな選択肢を検討して捨てたか」——を持っていません。差分だけを渡されたレビュアー(人間もAIも)は、実装者と同じ深さで判断できないのです。

さらに興味深いのは、同じ記事が指摘する逆説です。ドキュメントを整備するほどレビュー負荷が増える、という現象です。仕様を事前に細かく書けば書くほど、レビュアーは「実装が仕様と一致しているか」を1行ずつ照合する作業を強いられます。ドキュメントは品質を上げる目的で整備されたはずなのに、結果としてレビューという工程の負荷を増やしてしまう。これは私たちの実感とも一致します。ドキュメントの整備そのものは間違っていませんが、「整備すれば自動的にレビューが楽になる」という前提のほうが間違っているのです。

誤解のないように申し上げると、これはドキュメント不要論ではありません。仕様書自体は、実装者とAIエージェントの間の意図伝達には欠かせません。問題は、ドキュメントを「レビュー工数の削減策」として位置づけてしまうことにあります。ドキュメントの役割は実装前の意図合わせであり、実装後の照合作業をレビュアーに丸投げする免罪符ではない、と切り分けて考える必要があります。

打開策は「シフトレフト」——後で発見せず、前で解決する

この構造的な問題に対して、いくつかのチームが採用している打開策が「シフトレフト」という発想です。品質確認の工程を、後工程から前工程へ前倒しするという考え方です。

具体的には、実装者がPRを提出する前に、セルフレビュー専用のAIエージェントで自分のコードを一度レビューさせます。そこで見つかった問題は、人間のレビュアーに渡す前に実装者自身が解決します。「後ろで発見する」から「前で解決する」への転換です。

この転換が効くのは、実装者本人がまだコンテキストを完全に持っている段階だからです。実装した直後であれば、「なぜこの設計にしたか」を自分自身がまだ覚えています。差分だけを渡された後からのレビュアーが同じ問いに答え直すには、時間がかかります。同じ問題を、コンテキストを保持したまま本人が解決すれば、速さと正確さの両方が上がります。実際にこの仕組みを入れたチームでは、PRの初期品質が上がりました。レビュアーはコード規約の確認ではなく、設計の本質的な議論に集中できるようになったと報告されています。私たちの現場でも、この順序の入れ替えだけで、レビュー待ちのPRキューが目に見えて短くなった例がありました。

セルフレビューの仕組み——チェックリスト生成からAIレビューまで

「セルフレビュー AI エンジニア」と検索してみても、まだ具体的な実装例はそう多く出てきません。Findyのエンジニアブログが公開している仕組みは、その中でも非常に実践的な参考になります。

処理の流れはこうです。まず、開発者本人が過去数ヶ月に受けたレビューコメントを集めます。次にLLMがそのコメント群を分析します。「この開発者はどういう内容で指摘されやすいか」という個人専用のチェックリストができあがります。そのチェックリストをもとに、PRを出す前にClaude Codeでセルフレビューを実行します。見つかった問題を自動修正まで済ませてから、人間のレビュアーに渡す、という順序です。

ここで重要なのは、「AIが出力したコードの責任は人間にある」という前提を崩していない点です。セルフレビューは責任を放棄する仕組みではなく、責任を果たしやすくするための仕組みだと捉えるべきです。同じ発想は、私たちがVibeCoding支援で強調している「AIは壁打ち相手であり、判断は人間がする」という考え方とも重なります。AIに丸投げするのではなく、AIに一次チェックをさせたうえで、人間が最終判断を下す構造を保つ。これがセルフレビューの正しい位置づけです。

「PRでコメントをもらうな」という職業倫理の転換

技術的な仕組みの話だけでなく、エンジニア文化そのものの変化にも触れておきたいと思います。ある個人ブログの記事が、率直な言葉でこの変化を言語化しています。「一人前のエンジニアなら、PRでコメントをもらうな」という主張です。

この記事の核心は、「AIに聞けばPRを出す前に潰せた指摘を、人間からもらうな」という一文にあります。コメントをもらった時点で、その仕事をレビュー者に肩代わりさせている、という指摘は少し厳しく聞こえるかもしれません。ですが、AIがどんな観点でも即座に調べられる時代において、「知識不足だったので指摘してもらった」という言い訳は、以前より説得力を失っています。同記事はさらに、「足りない観点はSkillとHookで潰せ」とも述べています。一度受けた指摘を、二度目からは仕組みで自動的に検出できるようにする。これは私たちがクライアントの内製化を支援する際にも、優先度の高い提案として挙げていることです。指摘を「個人の反省」で終わらせず、「チームの仕組み」に埋め込むことで、同じ指摘の再発を構造的に防げます。

これは私たちの実感とも一致します。ただし、誤解のないように申し上げると、この考え方は「レビューをなくす」という意味ではありません。レビュアーの役割を、コード規約の確認から、設計判断や事業インパクトの議論という、より本質的な仕事へ移すということです。

私たちが中堅企業の現場で見た「レビューの壁」

私たちがFDEとして複数の中堅企業の内製化を支援する中で、この壁に最も早くぶつかるのは、意外にも大企業ではなく中堅企業です。理由は単純で、Findyのような自社専用のレビュー分析基盤を持つ余裕がないからです。エンジニアが数名から十数名という規模のチームでは、AIエージェントを2台、3台と増やした瞬間に、レビューできる人間が社内に1人か2人しかいないという現実にすぐ突き当たります。

代表の櫻井は、社内でもデスクトップに複数のツール(議事録要約・需要予測・スライド生成・マーケティング分析)を並行で走らせる「エージェントマネージャー」的な働き方を実践しています。ここで繰り返し語っているのが、「AIは信用するのではなく、こちらの考えをぶつけ、前提情報や意図を渡し続けることで深い対話が生まれる」という考え方です。AIは相手を見て会話するため、表向きの情報しか与えなければ表向きの回答しか返ってきません。これはコードレビューにおいても同じです。セルフレビュー用のAIエージェントに、実装の背景や制約を渡さずにレビューさせても、表面的な指摘しか返ってきません。

ある中堅の卸売業のクライアントでは、基幹システムからの脱却プロジェクトの中で、まさにこの壁に直面しました。実装のスピードが上がったことで、社内に1人しかいないベテランエンジニアがレビューのボトルネックになっていたのです。当初、そのクライアントは「レビュアーをもう1人増やす」ことを検討していましたが、採用には数ヶ月かかりますし、新しく入った人がすぐに同じ精度でレビューできるわけでもありません。私たちが提案したのは、大掛かりな基盤を作ることではなく、Claude CodeのHooksとSkillだけで組める最小限のセルフレビューの型でした。

Claude Code の Hooks / Skill だけで作る現実的な型

中堅企業がFindy規模の分析基盤をいきなり作るのは、正直に申し上げると現実的ではありません。ですが、Claude Codeが標準で備えているHooksとSkillの機能だけでも、同じ効果に近づけることができます。

私たちが実際に組んだ型は3段階です。1つ目は、PR提出前のセルフレビューを固定のSkillとして登録し、「このプロジェクトで過去に指摘された観点」をチェックリスト形式でSkillのプロンプトに書き込んでおくことです。過去のレビューコメントをLLMに要約させるだけでも、十分に使える一覧ができあがります。2つ目は、コミット前フックとして、テストの実行とセルフレビューのSkill呼び出しを自動化することです。実装者が「レビューを忘れる」余地を、仕組みでなくします。3つ目は、セルフレビューで検出した指摘のうち、実装者が「今回は対応しない」と判断したものだけをPRの説明文に明記するルールです。これにより、人間のレビュアーは「AIがすでに見た範囲」と「人間が判断すべき範囲」を一目で区別できるようになります。

具体的には、Skillのプロンプトには「命名規則」「エラーハンドリングの網羅性」「既存のテストパターンとの整合性」といった、そのプロジェクト固有の観点を並べます。汎用的なコーディング規約をそのまま貼るのではなく、実際に過去のレビューで指摘された内容から逆算して書くことが重要です。汎用のチェックリストは、どのプロジェクトにも当てはまるがゆえに、どのプロジェクトにも刺さりません。コミット前フックは、Claude CodeのHooks機能でgit commit実行前にSkillを呼び出すだけの短いスクリプトです。特別なインフラ投資は不要で、既存のリポジトリに数十行のフック設定を追加するだけで動きます。

この型を導入してから、そのクライアントではベテランエンジニアのレビュー時間が3割ほど短縮されました。もっとも、これは全ての現場に当てはまる数字ではありません。チームの規模やコードベースの複雑さによって効果の出方は変わります。ただし、共通して言えるのは、レビュアーが「規約違反を探す作業」から解放され、「この設計で本当に大丈夫か」という本質的な判断に時間を使えるようになったという変化です。

AI-Pathの見解——「エージェントマネージャー」とセルフレビュー文化はセットでなければ機能しない

私たちがFDEとして複数のクライアントの内製化を伴走してきた経験から言えば、AIエージェントを並列運用する働き方(エージェントマネージャー)と、セルフレビュー文化は、片方だけでは機能しません。エージェントの台数を増やすことだけに投資し、レビュー側の仕組みを整えないままでは、前回の記事で述べた「レビュー速度の壁」に高い確率でぶつかります。逆に、セルフレビューの仕組みだけを整えて、実装のスピードが従来通りのままでは、その投資対効果は限定的です。この2つは、常に同時に設計するべきものだと私たちは考えています。

もう一つ、私たちがクライアントに繰り返し伝えているのは、セルフレビューは「レビューを軽くする」ためのものではなく、「レビューを本質的な議論に集中させる」ためのものだという点です。AI-Pathでは、自社のAIPLAの開発においても、単体テスト(Vitest)とシナリオテスト(Playwright)の自動化に加えて、セルフレビューの工程を組み込んでいます。ただし、ユーザー受け入れテスト(UAT)のようにAIが苦手とするUX的な観点については、人間が実際に触って確認する工程を残しています。VibeCodingで起こりがちな「謎の項目が勝手に増える」といった事故は、この人間の工程で止めるべきだというのが私たちの立場です。技術を過信せず、AIが向いている領域と、人間でなければ判断できない領域を切り分けること。これがセルフレビュー文化を機能させるための、最も基本的な前提だと考えています。

よくある質問

Q1. セルフレビューを導入すれば、人間のレビューは不要になりますか？

いいえ。セルフレビューは人間のレビューを置き換えるものではなく、人間のレビュアーが本質的な判断に時間を使えるようにするための前工程です。最終的な責任は、AI-Pathの現場でも常に人間側に残しています。

Q2. 過去のレビューコメントが少ないチームでも導入できますか？

導入できます。過去のコメントが少ない場合は、コードレビューの一般的なチェック観点(命名、エラーハンドリング、テストの有無など)から始め、指摘が積み重なるごとにチェックリストを更新していく方法が現実的です。最初から完璧な精度を求める必要はありません。

Q3. セルフレビューを入れると、開発スピードはむしろ落ちませんか？

短期的にはセルフレビューの実行時間が増える分、わずかに遅く感じることがあります。ただし私たちの現場では、PRの手戻りが減ることで、チーム全体のリードタイムはむしろ短縮される例が多く見られました。レビュー待ちの時間そのものが減ることが大きいためです。

Q4. 「エージェントマネージャー」として複数のAIエージェントを動かしていない、1人で1台のAIエージェントを使うだけの場合でも意味がありますか？

意味があります。台数の多さよりも、実装から提出までの間にレビュアーの視点を一段挟むという構造そのものが効果を生みます。1台であっても、AIが書いたコードの量が増えれば増えるほど、人間のレビュー能力との差は開いていきます。台数を増やす前に、まず1つのSkillから試すのが現実的な入り口です。

まず試すなら

1. 直近1ヶ月分のPRレビューコメントを見返す——自分やチームが繰り返し受けている指摘のパターンを3つ書き出してみてください。それがセルフレビュー用チェックリストの最初の種になります。
2. Claude CodeのSkillとして、そのチェックリストを1つだけ登録する——完璧な仕組みを最初から目指さず、まず1個のSkillでPR提出前に自分のコードを見させてみてください。
3. 人間のレビュアーに「AIが確認済みの範囲」を明記する——PRの説明文に、セルフレビューで確認した観点を一言添えるだけで、レビュアーの負担は変わります。

自社のチームにどの粒度でこの仕組みを組み込むべきかは、コードベースの状態や体制によって変わります。私たちAI-Pathでは、無償の業務プロセス診断(BPR)を実施しており、開発体制の棚卸しから一緒に考えることができます。まずは無償の業務診断で、どこにボトルネックがあるかを明らかにしませんか。

参考リンク

• AIが書いたコードをレビューする時間が、自分で書く時間を超えた——2026年の開発者事情を整理する
• 【GitHub Copilot】AI活用しても「減らないレビュー負荷」。打開策は「シフトレフト」
• Findyの爆速開発を支えるAI×チェックリスト型セルフレビュー
• 一人前のエンジニアなら、PRでコメントをもらうな。