CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 16, 2026
1 min read
The engineer's guide to a coding agent workflowの意訳です。
コーディングエージェントワークフローとは、AIエージェントがコード作成を支援するときに、エンジニアリングチームが回すエンドツーエンドのループです。計画し、生成し、検証し、マージします。
コードを書くステップとコードを確認するステップの境界が、リスクを制御します。その境界を誤ると、壁に向かって速くリリースすることになります。正しく引ければ、エージェントの量が増えてもスケールする開発ループになります。
コーディングエージェントワークフローは、仕様、計画、実装、テスト、コードレビュー、マージの順に進みます。人間が担うステップは2つ残ります。エージェントがコードを書く前の計画承認と、マージ前のPRレビューです。この2つの間にあるものはすべて自動化です。
計画から始め、すべてが明確になるまで磨き込みます。計画が承認されてからコードを生成します。その後、まず自動Lintチェックが走り、プルリクエストを開く前により深いレビューが行われ、マージ前にチェックリストに照らした最終確認が行われます。
コードレビューのエージェントと、コードを書くエージェントは分けてください。コードを書くエージェントには、コンパイルできるものを作って先に進む理由がいくらでもあります。レビュアーの唯一の仕事は、問題を見つけることです。
両方の役割を1つのエージェントにまとめると、レビュー工程は機能しなくなります。コードを書いたのと同じエージェントがそれを承認するため、自分のミスをそのまま通しやすくなります。
エージェントが生み出すPRの量は、レビューキャパシティに圧力をかけます。
AI生成PRがレビュアーの処理能力を上回ると、レビュー時間は増えます。特にPRが大きくなり、読みづらくなるほど顕著です。チームは、十分なレビューをしないまま、より多くの変更をマージへ押し進めることになります。
freeeでは、AI搭載のコードレビューを追加したことで、過去6か月で32.8週分のレビュアー時間を節約しました。freeeで不足していたのはエンジニアリング時間ではなく、レビュアーの注意力でした。
約5,000件のアンケート回答に基づくDORA 2025レポート（DORA: DevOps Research and Assessment）は、AI導入がチームのリリース速度を高める一方で、デリバリーを不安定にすると示しました。導入度が高いほど、デプロイの不安定さが増え、その後の監査、テスト、検証の作業も増えました。DORAはAIを増幅器と呼んでいます。チームの既存の強みも、既存の弱みも拡大するからです。
State of AIレポートでは、CodeRabbitが470件のPRをレビューした結果、AIが共同作成したプルリクエストは平均10.83件の問題を含み、人間だけのPRでは6.45件でした。ただし、この平均値は最悪のケースを隠します。
90パーセンタイル、つまり最悪10%のPRでは、AIによるPRは26件の問題に達し、人間だけのPRは12.3件でした。差は2.11倍です。レビューキューは平均的なPRで壊れるのではありません。まれに現れる巨大なPRで壊れます。
午後5時に40ファイルのエージェントPRを開くレビュアーを想像してください。簡単なものはすでに片付いています。これは回帰を隠しているPRであり、注意力が尽きたタイミングでやってきます。
エージェントがPR量を増やし、各PRがより多くの問題を抱えるようになると、バグ率を上げないためだけでも、チームにははるかに多くのレビューキャパシティが必要になります。ほとんどのチームは、それほど速くレビュアーを増やせません。
AI生成コードの最大の死角は、可読性と保守性です。セキュリティスキャナーはこれをまったく見つけられません。
AI生成コードに静的解析をかけると、多くのコードスメル、つまり時間とともにコードを保守しにくくする命名や構造の問題が見つかります。セキュリティスキャナーは別種のツールです。静的アプリケーションセキュリティテスト（SAST）は脆弱性パターンを探すものであり、悪い名前や弱い構造を探すものではありません。そのため、こうした保守性の問題はすり抜けます。CodeRabbitがAI作成PRと人間だけのPRをレビューしたところ、AI作成PRは全体として問題が多く、特にセキュリティ問題も多いことがわかりました。AIの出力をセキュリティバグだけで見ていると、保守性コストを見逃し、それはPRのたびに積み上がります。
State of AIレポートでは、コード可読性の問題がAIによるPRで3倍以上多いこともわかりました。この種の負債は、セキュリティダッシュボードに表示されるよりも速く積み上がります。
理解負債とは、書き直す必要があるかどうかを判断できるほど理解できないコードです。通常の技術的負債は、書き直す必要があるとわかっているコードです。理解負債は、それすら判断できないコードです。
エージェントは30分で、人間が丁寧に読むにははるかに長い時間がかかるコードを書きます。その出力を信頼できるほど注意深く読むには、どれくらい時間がかかるでしょうか。ほとんどのレビュアーはその時間をかけないため、丁寧なレビューなら見つけられる命名や構造の問題がすり抜けます。
標準は、ある場所で規約を更新しても、エージェントが読むすべての場所で更新されないとずれていきます。その後、異なるツールが少しずつ違うルールでコードを生成します。どちらのバージョンもLintには通るかもしれません。
SASTはスタイルや規約のずれも検出しません。Common Appでは、AI搭載レビューがチームの従来ツールでは見逃していた競合状態を発見し、レビュー時間を35%削減しました。
CodeRabbitは、エージェントが読むのと同じ規約ファイルを読み、すべてのPRをそれに照らしてチェックします。チームが合意した標準は、静かにずれていくのではなく、レビュー時に適用されます。
AIエージェントは、人間の開発者と同じよくあるセキュリティバグを生み出します。ただし、その頻度が高いのです。だから重要な問いは、それをワークフローのどこで見つけるかです。
AI生成コードのセキュリティ研究では、OWASP Top 10、つまり一般的なWebアプリケーションのセキュリティリスク標準リストに載るような、おなじみの欠陥が繰り返し見つかっています。Cloud Security Allianceのリサーチノートでは、AI作成PRでセキュリティ問題の割合が高く、それらのPRは人間だけのPRより全体で約1.7倍多くの問題を含むと報告されています。
同じ470件のPRレビューでも、AIによるPRは人間だけのPRより多くのセキュリティ問題を含んでいました。
OWASPも同じ方向を示しています。同団体の過剰なエージェンシーに関するガイダンスは、モデルを信頼して任せるのではなく、アクセス制御のような制限を自分たちのアプリケーションコードで適用するようチームに求めています。
エージェントの本番ガバナンスは、1つのルールに集約されます。すべてのエージェントによる変更は、人間がすでに使っているのと同じPRゲートを通すということです。Intuit、FICOなどのエンジニアが参加したInfoQのパネルでも、同じアプローチが説明されています。各チーム向けに、セキュリティ、コンプライアンス、可観測性、モニタリングを扱う1つの共通プラットフォームを構築するというものです。見返りは速度です。どのチームも同じ制御を作り直す必要がないからです。そして監査可能性も得られます。規制当局は一貫した証拠を求めるからです。
制御はアイデンティティと境界から始まります。各エージェントにはタスクにスコープされた短命トークンを与え、境界ルールでmainへ直接コミットできないようにします。推論の分離はチェックポイントを追加します。エージェントがアクションを提案し、ポリシーレイヤーが実行前にそれを承認またはブロックします。
監査ログのガイダンスは、このループを閉じます。エージェントがたどった推論の各ステップと実行した各アクションを、それぞれタイムスタンプ付きで記録するよう求めています。
多くのリポジトリにまたがって標準を適用するなら、CodeRabbitのPath InstructionsとCode Guidelinesは、レビュー規則を人の頭の中ではなくコードベース自体に保持します。これは、コードがさまざまなツールからPRゲートへ到達しても、1つの標準を満たさなければならない場合に重要です。
自前のレビュースクリプトやCIゲートは、エージェント量が増えて大きなdiffにレビュアーが注意を払えなくなる水準に達すると、スケールしなくなります。
コード量が増えて差分は大きくなり、レビュー品質は下がります。最大級の変更では、レビュアーは詳しく見なくなります。従来の人間のペースに合わせたワークフローは壊れます。
社内でレビューエージェントを構築すると、隠れたコストが伴います。レビューのロジックそのものに加えて、コスト制御、リスク階層、コンテキストウィンドウ管理も維持することになります。専用のレビューエージェントは、そのすべてを代わりに処理します。まさにこの選択に直面したAIネイティブ企業のWriterは、自作ではなく購入を選び、レビュー時間を30%削減しました。
検証はもっと早い段階にも移す必要があります。PRゲートが最初の本格的なチェックになってはいけません。
コンテキストエンジニアリングとは、全体像を取り込むことです。レビューは変更行だけでなく、関連ファイル、リンクされたissue、Lintシグナルを読みます。自動コードレビューに関するarXiv論文は、レビュー自動化が成功する場所と失敗する場所を整理しています。差分だけを読むスクリプトは、他のファイルに依存するものを見逃し、その変更がアーキテクチャに合っているかも判断できません。
こうしたファイル横断のミスこそ、差分だけを見るスクリプトが見逃すものです。そのため、エージェント量が増えるほど、購入する理由は強くなります。自前のスクリプトでは、今の優れたレビューに必要なコンテキストエンジニアリングの深さに追いつけないからです。
CodeRabbitのコンテキストエンジニアリングは、事前PRレビューとPRレビューの両方でこれを行います。コードグラフ、各種連携、リンクされたissue、40以上のLinterを組み合わせ、差分だけのスクリプトでは作れないファイル横断の視点を構築します。
エージェントは、人間のチームが手作業でレビューできない速度でコードを書きます。その速度に耐えるワークフローは、計画承認とPRレビューという、動かしてはいけない2つの人間のゲートを維持します。その間で自動チェックを実行し、LinterやSASTツールが見つけるために作られていない問題を捕捉できる十分なコンテキストを持つレビューレイヤーを走らせます。
速度向上は本物です。不安定さというコストも本物です。私たちは、不安定さによってその速度が打ち消されることなく、速度を得たいのです。それが検証レイヤーの仕事です。
コードレビュー時間とバグを50%削減しましょう。 GitHubとGitLabで最もインストールされているAIアプリです。14日間の無料トライアル。始める。
