Atsushi Nakatsugawa
May 18, 2026
2 min read
A Step-by-Step Agentic SDLC Workflow That Actually Worksの意訳です。
エージェント型開発をめぐる議論を追いかけている方なら、ボトルネックの位置がすでに移っていることはご存じでしょう。プランニングが新たな品質ゲートになっています。レビューは、コードが生成されるスピードに追いつかなければなりません。概念レベルの議論はひととおり語り尽くされた感があります。見つけにくいのは、それらの原則が実際にどうつながるのかを示す、具体的かつエンドツーエンドのワークフローです。つまり、使うツール、進める手順、そしてチームが実際に回してみたときに何が起きたかという結果まで揃ったもの、ということです。
概念的な土台が知りたい方は、まずエージェント型SDLCガイドから読んでみてください。本記事はそこから先を、ステップごとに、お客様の成果も交えて掘り下げていきます。
コーディングエージェントを導入した多くのチームが、同じ壁にぶつかります。
最初の数回のデモは非常に良く見えます。開発者がClaude Code、Codex、Cursor、あるいは別のエージェントにプロンプトを貼り付ければ、数分で動くコードが返ってきます。利点は誰の目にも明らかです。
そこに、本番環境の現実が押し寄せてきます。
チケットの仕様が曖昧だった。プロンプトが制約を捉えきれていなかった。エージェントは正しいファイルを、誤った形で変更した。プルリクエストは想定の範囲を超えて膨れ上がった。レビューのスレッドは、要件を確認するためのミーティングの場と化した。
モデルはコードを書けるようになりました。けれども、ワークフローのほうがまだ追いついていません。
エージェントは、曖昧さをそのままの形でコードの規模にまで増幅します。人間が自分のペースで少しずつ修正していくことを前提に組まれたワークフローでは、その圧力に耐えられません。だからこそ、機能するエージェント型SDLCには、実装前にズレを検出し、コンテキストがまだ手元に残っているうちに問題を浮き彫りにし、マージ前にチームの基準を確実に効かせる仕組みが必要です。
Abnormal AIは、これを身をもって学びました。サイバーセキュリティ企業として、250人のエンジニアにまたがるAI生成コードを加速させていく中で、人手によるレビューがボトルネックになっていったのです。アウトプットはスケールしました。一方で、何かを誤ったときのコストは、依然として高いままでした。Abnormal AIのVP of AI Strategyを務めるShrivu Shankar氏は、次のように語っています。「AIネイティブなツールを使えば、チームははるかに早く、はるかに多くのコード変更を生み出せます。けれども、間違えたときのペナルティが軽くなるわけではありません。ささいなバグ、セキュリティの問題、意図とズレた実装は、原因を突き止め、修正し、再テストし、場合によってはインシデント対応に動くために、相変わらず実際の時間を奪っていきます」
いまエージェントを使って成果を出しているチームは、まさにこの問いを軸にワークフローを組み立てています。そのCodeRabbitワークフローの中身は、次のようなものです。
うまくいかないエージェントワークフローの多くは、コードが書かれる前にすでに失敗しています。
曖昧なチケットを、実行可能な仕様書のように扱った時点で失敗するのです。
「ダークモードを追加して」「SSOに対応して」「認証まわりを整理して」「オンボーディングを改善して」
人間ならば、こうしたチケットが不完全だと分かります。けれどもエージェントは、そのまま実行を始めてしまいます。
だからこそ、現代のワークフローはプランニングから始まります。
CodeRabbit Planは、アイデアやチケット、ざっくりとしたプロンプトを、エージェントが実際に使える形に変換します。プランニングを軽い事務作業として扱うのではなく、エージェント型SDLC全体の制御レイヤーとして位置付けます。
良いプランには、実装を行う上で必要なコンテキストがひとまとめになっています。
エージェントを使った作業が、生産的に終わるか高コストに終わるかの差は、たいてい「タスクをどう切り出して伝えるか」の違いに行き着きます。つまり、エージェントが自信満々のまま間違いを犯さずに済むだけのコンテキストと具体性が、タスクに乗っているかどうか、という点です。
Abnormal AIのエンジニアリングワークフローは、それがなぜ重要かを示しています。同社のチームでは、スタンドアップでチケットを割り振るのではなく、詳細な仕様書を共同で書き、その仕様書をエージェントに委任して並行で実装させています。人間の注意は、上流の「明確な意図と制約を書くこと」と、下流の「検証」へと移っています。CodeRabbit Planは、意図と実装の橋渡しをどう設計するかをまだ模索しているチームにも、この規律を持ち込めるように作られています。
従来のチケットは、人間向けに書かれています。しかしエージェント型ワークフローでは、もっと構造化された情報が必要です。
意図、制約、順序を保ったままエージェントへ引き渡せる必要があります。機能の概要だけでは足りないのです。
ほとんどのチームは、ここで水面下の作業を引き受けています。誰かが課題を読み、コードベースを掘り、ドキュメントや古いスレッドから関連する判断を見つけ出し、システムの実際の動きを理解し、その内容をエージェント向けのより良いプロンプトに書き直す。この作業が手戻りを防いでいるのですが、地味ゆえに評価されにくいのです。
CodeRabbit Planは、その水面下の作業を仕組みとして明示的に扱います。1人の開発者が頭の中でコンテキストを組み直すのではなく、ワークフロー自体が段階別のタスク、設計の根拠、調査メモ、そして実行前にレビュー可能な「エージェント向けプロンプト」を生み出します。
エージェントへの引き渡しは、2つの意味で良くなります。1つは、プロンプトが実際のコードベースとワークフローのコンテキストに根ざしていること。もう1つは、プランが1人の開発者のコンテキストウィンドウに閉じこもらず、チームで共有・改善できるものになることです。
これがエージェント型SDLCにおける、1つ目の大きな転換です。従来の流れでは、コラボレーションは主に実装後、プルリクエストの中で行われていました。新しい流れでは、コードがまだ存在しないうちに、チームはプランで足並みを揃えます。
プランが固まれば、エージェントは得意なこと、つまり実行に専念できます。
ここは、開発者の好みに応じてワークフローが分岐するところです。ターミナル上で動くエージェントを使うチームもあれば、IDE組み込みのアシスタントを使うチームもあります。Codexの中で動かしているチームもあります。何を選ぶかそのものよりも、その後に何が起きるかのほうが重要です。
レビューは、作業のすぐそばに置いておきましょう。
だからこそローカルでのワークフローが効いてきます。CodeRabbit Skills、CodeRabbit CLI、そしてCodex向けCodeRabbitプラグインはいずれも、コードが書かれ、繰り返し練り上げられている、まさにその環境にレビューを持ち込みます。
レビューがセッションの中にとどまれば、開発者は実装のフルコンテキストがまだ新鮮なうちに問題に気付き、エージェントにその場で修正を頼み、ツールを切り替えずに再レビューを走らせられます。
Clerkのエンジニアたちは、この点に特に価値を感じていました。CodeRabbit導入前は、早めにフィードバックをもらうために、別のタイムゾーンにいる同僚が初期段階のコードをレビューしてくれるのを待つ必要があり、ときには一晩かかることもありました。セッション中のレビューが使えるようになった変化について、ClerkのSenior Staff EngineerであるBrandon Romano氏は、率直にこう語っています。「ファーストレビューまでの時間が今では数分単位になっているのが、個人的にすごくありがたいですね。時間を無駄にする前に、エディタの中で直せるんですから」
エージェント型ワークフローでは、コーディングのループを短くすることよりも、検証のループを短くすることのほうが重要です。コーディング自体はすでに速いのです。チームが時間を奪われるのは、「もっともらしいけれど間違ったコード」を直すフェーズです。
AI支援開発の最悪のパターンは、品質に確信の持てないコードが大量にプルリクエストに乗ってきて、そこで初めて本格的な検証が走るというものです。
それはレビューを、いわば後始末に変えてしまいます。
より良いワークフローは、明らかな問題はローカルレビューで早めにつぶし、プルリクエストレビューはチームでマージ可否を判断する場として使う、というものです。
CodeRabbitのPRレビュー層は、その次のステップを担います。コードがGitプラットフォームに上がった瞬間から、ワークフローは「1人の開発者を助ける」フェーズから、「チームでマージ可能な状態に収束させる」フェーズに切り替わります。問いも変わります。残っている本当のバグやリスクは何か。今すぐ直すべき指摘はどれか。スコープが広すぎる、あるいは仕様が足りていない箇所はどこか。
Common Appでは、この力学がはっきり見えています。CodeRabbit導入前は、プルリクエストごとに2人のレビュアーを手動でアサインし、社内の詳細なチェックリストに沿って確認していましたが、それでも重要な問題を見落としていました。CodeRabbit導入後は、コードレビュー時間が35%短縮され、PRあたりのレビュアー数は1人に減らせています。CodeRabbitが基本的な指摘を引き受けることで、レビュアーはビジネスロジックに集中できるようになりました。Principal Software DeveloperのAmit Kumar氏は具体的に、次のように語っています。「先日、CodeRabbitが競合状態(レースコンディション)を検出しました。競合状態は手動では捉えにくいのですが、CodeRabbitはすぐに気付いてくれました」
ここで重要な指標は「シグナルの高さ」です。つまり、マージ前にチームが対応すべき問題を、ノイズに埋もれさせずにきちんと拾い上げられているか、ということです。
レビューが良くても、その後の修正フローでもたつくことがあります。
有用なコメントが10件付いたプルリクエストでも、結局は開発者がそれを1件ずつエージェントに渡していく作業が必要になります。コピー、ペースト、実行、また繰り返し。レビューがクリーンな状態に戻るまで、これを延々と続けることになります。
問題を検出するだけでなく、修正までの道筋もセットになっていなければなりません。
CodeRabbitは、レビューで見つかった指摘からプロンプトを集め、エージェントが一度の作業で処理できる構造化された指示書にまとめます。ツール間でコメントを移し替える手間が減り、修正の取りこぼしも減り、レビューからマージへの収束が速くなります。
これがエージェント型SDLCにおける、2つ目の大きな転換です。レビューは「修正に入る前に開発者が一度抜ける診断フェーズ」ではなく、「修正と検証を繰り返すループの一部」になります。
プランが承認されてコードが生成され、PRがレビューされて問題が直されたあとでも、まだ1つだけ残っている失敗パターンがあります。
チームは、つい何かを忘れてしまうのです。
課題のリンクを貼り忘れる。PRの説明が埋まりきっていない。機微なデータがログに出てしまう。必須のdocstringが抜けている。技術的には動くものの、チームのマージ基準を満たしていない変更が紛れ込む。
エージェント支援によって変更量が増えるワークフローでは、こうした失敗が起きやすくなります。多くの変更が流れていく中で、人の頭の中にしか存在しない基準ではスケールしません。
Pre-Merge Checksは、最後の制御レイヤーとして機能します。チームの期待値を、プルリクエスト上で自動的に走り、強制力を持つルールへと変換するのです。標準で用意されているチェックもあれば、チーム固有の要件を反映するために、平易な文章で書けるものもあります。
「その日にレビュアーがチェックリストを思い出したかどうか」に左右されず、自動で動く強制チェックこそが、コード量が増えてもエージェント型SDLCを安定して回し続けるための鍵になります。
ここまでの内容をまとめると、シーケンスはこうなります。
曖昧なアイデアやチケットがシステムに入ってきます。CodeRabbit Planが、その意図を段階的でコンテキスト豊富なプランに変換します。プランは、関連するコードベース、課題、ナレッジのコンテキストを伴う「エージェント向けプロンプト」になります。コーディングエージェントは、開発者が好む環境で変更を実装します。CodeRabbitは、CLI、Skills、あるいはセッション内のプラグインフローを通じて、変更をローカルでレビューします。プルリクエストは、より良いコードで、明らかな問題は減った状態で開かれます。残っている問題はCodeRabbitが拾い上げ、重要なものを浮き上がらせて、開発者がレビューの指摘を1パスで修正できるよう支援します。Pre-Merge Checksが、チームにとって譲れないルールを強制します。プルリクエストは、やり取りが減り、ポリシーのブレも減った状態でマージされていきます。
各ステップは、コード生成が速くなったことで生まれる、それぞれ別の失敗パターンに照準を合わせています。プランニングは意図のズレを減らします。ローカルレビューはコンテキストの喪失を減らします。PRレビューは見落としを減らします。自動修正による対応は摩擦を減らします。マージ前の強制チェックは不整合を減らします。
ここを正しく押さえているチームこそが、自信を持ってコードを生成し、同じ自信のままそれをリリースまで持っていけているチームです。
