TL;DR 概要
- エージェント中心の開発サイクル（AC/DC）は、AIエージェントが自律的にコードを書き、スキャンし、修正するソフトウェア開発ライフサイクルの次の進化を示すSonarのビジョンを説明します。このプロセスはSonarQubeの検証によって管理される連続ループ内で行われます。
- このモデルでは、AIコーディングエージェント（Claude CodeやCursorなど）がSonarQube MCPサーバーを使用して品質ゲートの状態や問題データを照会し、人間の開発者がプルリクエストをレビューする前に自らの出力を修正します。
- AC/DCは、開発者の役割を主要なコード作成者からエージェントの監督者および品質管理者に再定義します。つまり、手動でコードのすべての行を書くのではなく、自動化されたエージェントが満たすべき基準を設定します。
- SonarのMCPサーバー、エージェンティック分析ベータ、およびAIコード保証機能は、企業の開発環境内でAC/DCワークフローを大規模に実装するために必要なツールインフラストラクチャを提供します。
このトピックについてさらに知りたい方は、Sonar SummitでのTariqのディスカッション「より良いソフトウェアを構築する: エージェンティックSDLCの新しい設計図」をご覧ください。
おなじみのプロセスとワークフローを持つ継続的インテグレーションの時代は急速に終わりを迎えつつあります。従来のCIは、開発者が小さく頻繁で反復的なコミットを行うことに依存しています。今日、「継続的」という部分が変わりつつあります。エージェントはそのように動作しません。彼らは非同期バッチで動作し、しばしば何時間も作業してから大量で複雑なコードのペイロードをドロップします。私たちは、ソフトウェアの作成方法を根本的に再構築する新しいパラダイムの出現を目の当たりにしています。それがエージェント中心の開発です。
コード生成ツールやエージェントの採用と議論が多いのは当然のことです。彼らは開発者の仕事のやり方を変革する否定できない強みを持っています。開発者が設計、アーキテクチャ、計画により多くの焦点を当て、その後に監視、検証、レビューを行うというコンセンサスが高まっています。
あまり議論されていないのは、ソフトウェア開発エージェントが信頼性、一貫性、透明性、責任を持って動作することを保証するために必要な変更です。最良の手にあっても、AIの不正確さは広がっています。私たちの研究は示していますが、チェックされないままでは、コーディングモデルは冗長で複雑でバグが多く、安全でないコードを生成します。
エージェンティック開発には、強力で意図的な実践とよく構築されたツールセットが必要です。これらは、世界クラスのソフトウェアを構築するために必要なガードレール、透明性、保証、検証を提供します。これをエージェント中心の開発サイクル（AC/DC）と呼びます。
そう、それは電撃的です！
この新しいモデルは、従来のCIモデルとは異なる一連のステップで動作します。継続的な人間のリズムがなくなったため、エージェントはコードをコミットする準備が整うまで長時間作業します。プルリクエストは非常に大きく、より複雑です。エージェントがプロセスの初期に犯した小さなエラーが積み重なり、プロセスを本質的に不安定にします。
すべては慎重で詳細で具体的な計画から始めるべきです。仕様は何ですか？望ましい結果は何ですか？ソリューションがどのように使用されることを期待していますか？どの程度スケーラブルである必要がありますか？よく作られた計画はソフトウェア開発において常に重要でしたが、今ではエージェントと共に、それらはサイクル全体を駆動する必須の前提条件です。
その計画に基づいて、エージェント中心の開発サイクルを4つの明確なステージとして定義します：
- ガイド: エージェントは、開発者と組織が求める出力に合うように、作成を求められているキャンバスを理解する必要があります。
- 生成: LLMベースのコード生成ツールが、望ましい結果を達成するために必要なコードを適切なコンテキストで生成します。
- 検証: エージェントは、必要な基準を満たしているかどうかを確認するために、特に意図的にコードをチェックする必要があります。これには、望ましい結果を本当に達成しているかどうか、信頼性、保守性、安全性が含まれます。
- 解決: 特定された問題は、コード修正エージェントに提供されて修正されます。
このプロセスは続き、解決と検証のステージからの教訓がガイドにフィードバックされ、次のエージェンティックステップが前のループから学習します。
開発キャンバスは進化しています
4段階のAC/DCは従来のツールでは動作しません。IDEはあまり関連性がなく、プルリクエストは前述のように頻繁には行われません。高レベルでは、AC/DCモデルで一般的になる3つの主要な環境変化があります。
まず、AC/DCのステップ、ガイド-生成-検証-解決はサンドボックス環境で行われます。エージェンティックな推論ループはしばらく続き、より大きな問題を解決します。彼らはメインのコードベースにコードをコミットする前にこれを行います。実際、小さなコードベースの場合、コードベースのコピーを作成し、それを完全に反復することもあります。（複雑な企業のマイクロサービスやデータ状態は完全に隔離されたサンドボックス化をより困難にしますが、原則は変わりません：集中的な検証は隔離された状態で行われます。）開発者はそのサンドボックスを管理し、監視します。高品質な製品が検証された場合にのみ、メインのコードベースが変更されます。
これは多くの影響を伴う大きな変化です。コードベースに加えられる変更を理解するのが非常に難しくなり、長期的なリスクと課題を提示します。たとえば、セキュリティの問題は、40,000行のコードが書かれている場合には気づかれずに忍び込む可能性があります。さらに、このモデルでは、開発者は単にコードを出荷するのではなく、動作する何かを出荷する責任があります。CI/CDのビルドステージ後に行われていた活動、たとえば動的テストはサンドボックス内で行われ、開発者の責任となります。これは通常の「シフトレフト」ではありません。それはむしろマトリックスの中にいるようなものです：伝統的なパイプラインの中には「右」はありません。継続的なマイクロコミットが死んでいるため、プロダクショングレードの検証はエージェンティックなサンドボックス環境で行われ、大量のコードペイロードが提出される前に行われます。
2つ目の大きな変化は、これらのステップ、ガイド-生成-検証-解決がこのプロセスの2つの異なるレベルで行われることです：内側のループと外側のループ。
- 内側のループ: ガイド-生成-検証-解決は、各エージェンティックな推論ループで行われ、エージェントが計画を達成するために着実に作業していることを確認します。これらは基本的に「マイクロ」調整であり、ガードレール、プロンプトトレース、迅速な検証分析を使用して継続的に行われます。
- 外側のループ: ガイド-生成-検証-解決は、エージェントが作業を「完了」した後に行われます。ここでは、より包括的な検証が行われ、しばしばエージェントは特定された大規模な問題を修正する必要があります。
最後に、エージェンティック開発ツールチェーンには、開発者が特定のユースケースに最適なプラットフォームと信じるものに応じて、多くのコード生成ツールが含まれることが一般的です：あるケースではCursor、他のケースではClaude Code、Devin、Codex、GitHub Copilotなどです。ただし、ガイド-検証-解決のステージは、会社内で標準があるとより効果的です：すべてのツールに対する一貫した検証アプローチと、すべての生成ツールをガイドするための共通のエンジンです。
ガイド-検証-解決: 問題の核心
多くの人がコード生成について話しています。ガイド-検証-解決は、それと同じくらい、あるいはそれ以上に習得が重要です。
- ガイド: ガイドは単にコードベースを指し示すことではありません。それはプレイングフィールドを定義し、エンゲージメントのルールを設定することです。エージェントは、彼らの作業を形作るコンテキストと制約を伝えられる必要があります。これは、グリーンフィールド環境でもブラウンフィールド環境でも重要です。エージェントはもちろん、仕様が何であるかを知る必要があります。しかし、それは始まりに過ぎません。彼らは、あなたがコードベースに対して設定した基準、規制、ガイドライン、ガードレール、現在および望ましいアーキテクチャを理解する必要があります。
- 検証: AIは間違いを犯します。たくさんの間違いを。開発者とは異なり、彼らは基本的な間違いをあまり犯しません。代わりに、非常に複雑で見つけにくい間違いを犯します。そして、モデル自体はその確率的な性質のために予測不可能であり、トレーニングデータや環境の変化に非常に敏感です。昨日うまくいったプロンプトが今日もうまくいく保証はありません。これらの厳しい現実を考えると、検証は徹底的で透明性があり、一貫している必要があります。上記のように、推論プロセス自体の中でエージェントにフィードバックを提供し、最終結果に責任を持つ開発者にもフィードバックを提供する必要があります。
- 内側のループでは、主な目的はエージェントが自己検証を行い、どのように進んでいるかを継続的に評価し、迅速にコースを修正できるようにすることです。通常、これらのテストは、生成されたコードの頻繁な分析、問題の有無の確認、プロンプトトレースの評価、AIを使用したビジネスロジックの即時検証で構成されます。目標は、エージェントが自己修正できるように高信号・低ノイズのフィードバックを提供することです。
- 外側のループでは、エージェントが良い解決策を構築したと信じた後、エージェントの作業が意図した機能的および非機能的な結果を達成しているかどうかを検証する必要があります。これには、内部基準やコンプライアンス要件が含まれることがあります。ここで、コード検証やコードレビューのようなプロセスが重要になりますが、エージェント駆動の世界では、これが伝統的なSDLCの「右」が消え、サンドボックス内に再出現することになると考えています。開発者は、動作する何かを出荷する責任と義務があります。
- 解決: 内側と外側のループの両方で、問題は避けられません。「解決」フェーズは、検証フィードバックに基づく自動デバッグと修正フェーズです。アプリケーションの構造に関する深い理解と検証フェーズの結果を武器に、修正が行われます。そして、ほとんどの従来のプロセスとは異なり、失敗は単なるバグの修正ではなく、次の反復を洗練する教訓であり、システム全体をより強靭にします。問題とその解決策は、次のラウンドのガイドプロセスにフィードバックされます。
エージェント中心の開発サイクル（AC/DC）：ツールチェーン
多くの従来のSDLCソリューションは、迅速に進化する必要があるか、エージェントが開発プロセスを引き継ぐにつれてますます無関係になるでしょう。新しいAC/DCサイクルの重要なコンポーネントには以下が含まれます：
- エージェンティック開発サンドボックス: ガイド-生成-検証-解決のループが、使用するエージェントやコード生成パートナーに関係なく、すべてのエージェントで機能する環境。
- 動的コンテキストエンジン: 動的コンテキストエンジンには2つの重要な部分があります。まず、有用なコンテキストを提供できるツールが必要です。たとえば、コードベースのアーキテクチャの徹底的な評価や、基準とガードレールの明確で透明性のある具体的な表現です。次に、各状況でどのコンテキストを提供するべきかを決定する必要があります。コンテキストが多すぎる、少なすぎる、または不正確なコンテキストは、パフォーマンスを向上させるのではなく、低下させる可能性があります。
- 信頼と検証プラットフォーム: ソフトウェア開発は、一般的に言って、企業が開発者を信頼して良いコードを書き、そのコードをレビューすることに依存していました。検証は重要でしたが、多くの人は信頼が非常に高いため、オプションと見なしていました。
エージェント中心の開発はこの契約を破ります。AI支援およびエージェンティックなワークフローは、過去の10倍以上の大きさのプルリクエストを作成します。新しいコードを真に理解することはほぼ不可能であり、モデル自体はブラックボックスであり、出力は入力に非常に敏感です。AC/DCでは検証は必須であり、オプションではありません。
コンテキストと同様に、検証はすぐに問題になる可能性があります。LLMを使用して自分の作業をチェックするような「簡単な」検証アプローチは、多くの誤検知を生成し、説明可能でも一貫性もありません。これらは役立つことがありますが、これらの本質的に不正確なアプローチは、信号を最大化し、企業基準を満たすために、決定論的で包括的で透明性のある分析に基づく必要があります。開発者に、何がチェックされ、何が機能し、何が機能しなかったかを明確にする必要があります。
検証データの貴重なソースはたくさんあります。信頼性、保守性、複雑性、安全性をカバーする決定論的なコード分析（SonarQubeが提供するものなど）は重要なコンポーネントです。LLMベースのAIコードレビューもその一つです。エージェンティックサンドボックス内では、コードをテストし、観測可能性トレースを生成して追加情報を提供することができます。包括的な検証プラットフォームは、これらの信号を集約し、仲介し、最終的に結果を判断します。
これに加えて、全体的なエージェンティックパフォーマンスを明らかに向上させるいくつかの新しいベストプラクティスがあります：
- 埋め込みコンテキスト: モデルはそのトレーニングデータと技術の反映であり、基盤モデル企業はトレーニングデータを継続的に更新していますが、トレーニングデータの大部分はオープンソースコードに基づいています。これらのオープンソースデータセットに使用される品質、スタイル、基準は非常に多様であり、おそらく最も重要なのは、あなたやあなたの会社が過去に使用したものとは異なることです。モデルプロバイダーが許可する場合、モデルの微調整は、絶対的な品質とセキュリティを向上させるだけでなく、コードベースに埋め込まれたコンテキストをよりよく反映させるのに役立ちます。エージェント中心の開発が進むにつれて、これらの微調整された企業モデルの必要性がますます認識されるようになると考えています。これは、動的コンテキストエンジンからのより一時的でタスク固有のコンテキストと競合するものではなく、補完的なものです。
- 特定目的エージェント: 今日、基盤となるモデルは多くの興奮を生み出しています。しかし、ソフトウェア開発における特定の問題に対処するには、おそらく目的に合わせてカスタムビルドされた小さなモデルやエージェントが必要です。カスタムワークフローと検証コンテキストの理解を持つコード修正エージェントは、AC/DCの解決部分によりよく対処できます。プルリクエスト情報でトレーニングされたコードレビューエージェントは、一般的なレビューエージェントよりも開発者により良い情報を提供する可能性があります。この分野は進化しており、注目し、実験する価値があります。
AC/DCの始め方
ほとんどの企業は、現在のCIプロセスからAC/DCに一夜にして移行することはできません。しかし、始めるために取ることができる具体的なステップがあります。
- [検証] 検証プラクティスを強化する。AC/DCにおける検証は必須であり、オプションではなく、意図的な設計と計画が必要です。それは「良いとは何か」を定義することから始まります。これらの品質プロファイルは、アプリケーションによって異なるかもしれません。AC/DCへの移行を進めているある主要な金融機関は、低/中/高の品質プロファイル定義を持ち、すべてのプロジェクトがこれに対して分類されています。彼らは、AIエージェントによって書かれたすべてのコード行が決定論的なコード分析を使用して品質プロファイルに対して検証される必要があると義務付けています。同様に、あるグローバルな通信会社は、従来のCIプロセスでAIコーディングエージェントを使用しようとしましたが、健全なガバナンスの欠如により中止を余儀なくされました。必須の決定論的なコード分析を展開することで、このプロセスが解放され、AIコーディングツールをどこでも展開できるようになりました。
- [解決] 修正エージェントに投資する。 検証が整ったら、修正エージェントを使用して既存の問題のバックログを解消することで、実際の影響を与えることができます。エージェント中心の開発サイクルでは、技術的負債はもはや速度の妨げではなく、幻覚の引き金です。複雑さは殺し、エラーは積み重なり、エージェントを論理のウサギの穴に導きます。クリーンなコードベースを確立し維持することは、エージェンティックな世界での開発を加速し、トークン消費を削減します。より速く、より安く！修正エージェントの作業も検証が必要ですが、彼らも完璧ではありませんが、現在の能力は強力であり、常に改善されています。
- [ガイドと検証] アーキテクチャを管理する。 ほとんどの企業は、コードベースのアーキテクチャを非常に理解していません。アーキテクチャの知識はしばしば部族的であり、数人の主要なアーキテクトの頭の中にあり、手作業で維持されています。AC/DCは、ソフトウェアアーキテクチャの深く構造化された理解を必要とします。これを超えて、エージェントが作業中にアーキテクチャを維持または改善するようにガイドするための積極的なステップを取る必要があります。アーキテクチャを静的なドキュメントではなく、アクティブで構造化されたコンテキストとして扱うことで、エージェントがガードレール内で構築し、周りを回避しないようにします。
これらの3つのステップは、Claude Code、Codex、Github Copilot、Cursor、またはその他のコーディングアシスタントを使用しているかどうかに関係なく、成功への道を歩むためのスタートを切ることができます。もちろん、エージェンティックサンドボックスを確立し、セキュリティリサーチプログラムを強化するためのハンティングエージェントを採用するなど、より高度なステップを取ることもできます。
AC/DCへの移行は単なるシフトレフトではなく、工場の床を根本的に再構築することです。古いプラクティスは成功のための準備を整えません。AC/DCを開発フレームワークとして受け入れ、ガイド-検証-解決がコーディングエージェントの実装を補完することで、生産性を向上させながらリスクとコストを削減するのに役立ちます。
