タグアーカイブ ソフトウェア開発

エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

ソフトウェア開発のライフサイクル(SDLC)が、AIエージェントの登場によって根本から再定義されようとしている。Cloudflareは2026年8月4日、エージェント中心の新たな開発モデル「Agent Development Lifecycle(ADLC)」の構想と、それを支える具体的なツールセットを発表した。

従来のSDLCは「計画→設計→実装→テスト→デプロイ→保守」という人間中心の工程だった。しかしAIエージェントがコード生成の速度を劇的に高めた結果、周辺の工程がボトルネック化している。ADLCはこの課題を解決し、エージェントがライフサイクル全体を自律的に管理できる環境を提供する。

ADLC(エージェント開発ライフサイクル)とは何か

ADLC(エージェント開発ライフサイクル)とは何か

ADLCは、従来のSDLC(Software Development Lifecycle)をエージェント時代に合わせて再設計した概念だ。SDLCは1975年にランド研究所が提唱した「Systems Development Lifecycle」を起源とし、長年にわたりソフトウェア開発プロセスの標準だった。しかし、AIエージェントがコードを実装する速度は人間の比ではなく、テストやレビュー、デプロイといった他の工程が追いつかなくなっている。

Cloudflare Blogの著者Carlo Daniele氏によると、AIによって「実装」が最速かつ最安になった一方で、他の工程に携わる人々が膨大なプルリクエストやイシューに圧倒されるという逆説的な状況が生まれている。オープンソースメンテナの疲弊や本番環境の不安定化は、まさにこの非対称性の表れだ。

ADLCは、エージェントが実装だけでなく、テスト・デプロイ・監視・改善までを一貫して担うことを前提とする。そのために必要な要件は、プログラムによる操作が可能(Programmatic)、水平スケーラブル、再現可能、リアルタイムのプッシュ型イベント対応、アトミックな変更管理、適切な権限制御、そして自己改善能力の7つに整理されている。

従来のSDLC(人間主導)
計画 設計 実装(人間) テスト デプロイ 保守
ボトルネック: 実装だけが高速化し、他工程が逼迫
ADLC(エージェント主導)
計画 設計 実装 テスト デプロイ 保守・改善
全工程をエージェントが自律的に駆動。人間は監視と方針決定に集中

ADLCへの移行は、単にエージェントにタスクを委譲するだけでは実現しない。Cloudflareが提唱する7要件は、いずれも人間向けに設計された既存の開発基盤では満たせないものだ。次のセクションでは、なぜこのタイミングでパラダイムシフトが必要なのかを掘り下げる。

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

エージェント時代の「人間ボトルネック」

ChatGPTやClaude、GitHub CopilotといったAIツールの普及により、コード生成のスピードは飛躍的に向上した。ところが開発現場の実態を見ると、生成されたコードのレビューやテスト、本番デプロイは依然として人間が担っている。結果として、プルリクエストの滞留が慢性化し、オープンソースプロジェクトではメンテナが数千件のイシューに対処しきれずに疲弊する事例が相次いでいる。

Cloudflareの見解では、これは「エージェントを部分的にしか使えていない」ことに起因する。実装だけをエージェントに任せ、他の工程を人間が管理するという中途半端な状態が、かえって現場の負荷を増大させているのだ。

自律走行車に学ぶ「全体最適」の視点

Cloudflare Blogの記事では、ADLCの必要性を自律走行車に例えて説明している。人間向けの車にAIを載せただけでは、80%の性能は出せても、残りの20%が致命的な事故を引き起こす。安全に走行するには、LiDARや高性能コンピュータ、遠隔制御システムといった専用設計の技術が必要だ。

ソフトウェア開発でも同じで、エージェントが安全にコードをマージし、本番にデプロイするには、人間向けのCI/CDパイプラインでは不十分だ。エージェント専用のインフラ、トレーシング、権限管理、自己修復の仕組みが求められる。

ここで鍵となるのが、Cloudflare Workflowsとエージェントの組み合わせだ。従来のGitHub Actionsのような線形のパイプラインではなく、動的に分岐し、コンテナやブラウザを立ち上げ、ログを解析しながら自律的にソフトウェアを出荷する「ワークフロー」がADLCの中核を担う。

自律走行車とソフトウェアファクトリーの比較
人間用の車+AI
80%の走行は可能だが、緊急時の判断に限界。専用センサーなしでは安全性を担保できない。
自律走行専用車
LiDARや遠隔制御で99%以上の安全性を実現。専用設計が信頼を生む。
ソフトウェア開発も同じ。人間用パイプライン+AIでは限界があり、ADLC専用基盤が必要。

Cloudflareが提供するADLC基盤の全容

Cloudflareが提供するADLC基盤の全容

Workflowsが実現する動的なCI/CD

Cloudflare Workflowsは、複数のステップをチェーンし、失敗したタスクを自動リトライし、数時間から数週間にわたって状態を保持できるサービスだ。従来のCI/CDパイプラインが静的なYAML定義だったのに対し、WorkflowsはTypeScriptで動的にワークフローを定義できる。

さらにWorkflowsは、エージェントや別のWorkflowを子プロセスとして起動できる。たとえば、毎晩収集したデータをエージェントにレビューさせ、その結果を元に次のステップを動的に決定する、といった高度なオーケストレーションが可能だ。

import { CIWorkflow } from '@cloudflare/ci'

// CIパイプラインの例: 依存関係インストール後、lint/test/typecheck/buildを並列実行
const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});
await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);
await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID },
});

このコードは、依存関係のインストールをキャッシュしつつ、後続のlintやテスト、ビルドを並列で実行するパイプラインを簡潔に表現している。Workflowsによって、エージェントが生成したコードを安全に検証し、本番へデプロイするまでの一連の流れを自動化できる。

エージェントの可観測性と自己改善

ADLCにおいて、エージェントの動作を監視し、改善につなげる仕組みは欠かせない。Cloudflareは、OpenTelemetryベースのトレーシングをローカル開発環境(WranglerやViteプラグイン)に組み込み、本番環境と同等の可観測性を提供する。また、Agent Tracesによってエージェントのセッション全体をキャプチャし、パフォーマンス向上に活用できる。

さらに、Feature Flag管理のFlagshipや、段階的デプロイメント(Gradual Deployments)、Browser Runによるヘッドレスブラウザのプログラム操作など、エージェントが自律的にソフトウェアをテストし、リリースするためのプリミティブが一通り揃っている。

ADLCを支えるCloudflareの主要プリミティブ
Workflows 動的なオーケストレーションとエージェント起動
Agent Traces エージェントセッションの完全な記録と分析
Browser Run ヘッドレスブラウザを用いたE2Eテストのプログラム実行
Gradual Deployments トラフィックを徐々に切り替える安全なリリース
Cloudflare MCP Server API駆動のインフラ管理。エージェントが直接リソースを操作可能

エージェントが主導するソフトウェアファクトリーの実践例

エージェントが主導するソフトウェアファクトリーの実践例

Cloudflare自身のエンジニアリング標準化

Cloudflareは自社の全プロダクトとシステムリポジトリにわたり、AIを用いてエンジニアリング標準の遵守を強制している。具体的には、コードレビューや仕様チェックをエージェントが補助し、人間のレビュアーの負荷を軽減する仕組みだ。

これにより、コーディング規約の違反やセキュリティパターンの逸脱を自動検出し、修正案まで提示できる。人間はより創造的な設計判断や顧客との対話に時間を割けるようになったという。

Astroプロジェクトにおけるイシューゼロへの挑戦

また、CloudflareはAstroというオープンソースプロジェクトにおいて、イシューの自動トリアージ、再現、修正を行うシステムを構築した。この「ソフトウェアファクトリー」により、GitHub上のイシュー件数をゼロに近づける試みが行われている。

エージェントがバグレポートを受け取り、自動で再現環境をセットアップし、修正PRを作成する。Workflowsがこれらのステップをオーケストレーションし、テストと検証を経てマージする流れだ。この事例は、ADLCが現実のプロジェクトで有効に機能することを示している。

STEP 1 ユーザーがGitHubにバグレポートを作成
STEP 2 エージェントがイシューをトリアージし、再現環境をセットアップ
STEP 3 修正コードを生成し、PRを作成
STEP 4 Workflowsがテスト・検証を実行し、安全にマージ
Astroプロジェクトにおけるイシュー解決フロー。エージェントとWorkflowsの連携で、手動プロセスを大幅に削減している。

ADLCがもたらす開発現場の未来と課題

ADLCがもたらす開発現場の未来と課題

ソフトウェアファクトリーの民主化

現在、最先端の企業だけがソフトウェアファクトリーを構築できているのが実情だ。Cloudflareは、WorkflowsやAgent Traces、Browser Runといったプリミティブを誰でも使える形で提供することで、この格差を埋めようとしている。小規模なスタートアップでも、ADLCの恩恵を受けられるようにする狙いだ。

具体的には、@cloudflare/ciパッケージによるCI/CDの簡素化や、Flueエージェントフレームワークとの統合によって、複雑なオーケストレーションを少ないコードで実装できるようになっている。

残る課題と人間の役割

ただし、ADLCへの移行には越えるべきハードルもある。エージェントが本番環境に直接変更を加えることへの心理的な抵抗感は依然として強い。Cloudflare自身も、権限の段階的な委譲(エスカレーション)の仕組みや、監査証跡の確保が不可欠だと認識している。

また、エージェントが生成するコードの品質をどう担保するか、未知のエッジケースにどう対応するかは、自律走行車と同じく「99%の壁」をどう突破するかの問題だ。CloudflareはAgent Tracesを通じてエージェントの経験値を蓄積し、時間とともにパフォーマンスが向上する仕組みを描いているが、実運用でのデータ蓄積がこれから本格化する。

それでも、コードを書くだけのエージェントから、ソフトウェアのライフサイクル全体を駆動するエージェントへの進化は、もはや避けられない流れだろう。ADLCは、そのための地図と道路を提供するものだ。

この記事のポイント

  • ADLC(Agent Development Lifecycle)は、従来のSDLCをエージェント中心に再設計した新しい開発モデルである。
  • AIエージェントの実装速度に他の工程が追いつかない「人間ボトルネック」の解決を目指す。
  • Cloudflare Workflowsを中核に、動的でスケーラブルなCI/CDとエージェントオーケストレーションを実現する。
  • Agent TracesやBrowser Runなどのプリミティブが、エージェントの自己改善と安全な本番運用を支える。
  • ソフトウェアファクトリーの民主化により、スタートアップから大企業までADLCの恩恵を受けられる時代が近づいている。
Google Antigravity 2.0リリース、IDE不要のエージェント体験を実現

Google Antigravity 2.0リリース、IDE不要のエージェント体験を実現

Google DeepMindは2026年5月17日、AIエージェントを中核に据えたデスクトップアプリケーション「Google Antigravity 2.0」を発表した。従来のIDE(統合開発環境)を廃し、エージェントとの同期・非同期の対話に完全に最適化された独立アプリケーションとして再設計されている点が最大の特徴だ。

この新バージョンは、2025年11月にリリースされた初代Antigravity IDEの「Agent Manager」を発展させたもので、ソフトウェア開発だけでなく、より広範な知識作業をエージェントと協働するための基盤として位置づけられている。macOS、Linux、Windowsに対応し、最新のGeminiモデルを活用する。

開発者だけでなく、コードやIDEに馴染みのないユーザーにとっても直感的なエージェント体験を提供することが、この2.0の大きな狙いだ。

エージェントファーストの新設計

エージェントファーストの新設計
従来のAntigravity IDE(Before)
IDEとAgent Managerが同一アプリ内に混在
コードエディタ エージェント ターミナル
IDEの概念が常に付随、非開発者には不慣れ
Antigravity 2.0(After)
エージェントとの対話と成果物に集中
会話 成果物 フィードバック
コード不要、誰でもすぐに使える

Antigravity 2.0の最大の転換点は、IDEという概念を完全に取り除いたことにある。従来のAntigravity IDEでは、コードエディタとエージェント管理画面が同居していた。この設計は開発者には便利だが、エージェント本来の可能性を制限する側面もあった。

IDEを捨てた理由

Google DeepMindの記事によれば、開発チームは当初から「コーディングの高速化だけでは、ユーザーに提供できる価値に限界がある」と認識していたという。モデル性能が向上するにつれ、エージェントの活躍領域は自然とコード以外の知識作業へと拡大した。

実際、初代Antigravity IDEのAgent Managerは、開発以外のタスクにも広く使われていた。だが、IDEの枠組みの中でそれを行うのは、非開発者にとっては直感的とは言えなかった。Antigravity 2.0は、その制約を解消し、エージェントとの協働を主役に据えた設計へと舵を切った。

プロジェクトベースの管理方式

もう一つの大きな設計変更が、リポジトリとの密結合の解除だ。Antigravity 2.0では、エージェントの会話は「ワークスペース(リポジトリ)」単位ではなく、「プロジェクト」単位でグループ化される。一つのプロジェクトが複数のフォルダを参照でき、プロジェクトごとにエージェントの設定や権限を個別に定義できる。

これにより、エージェントがより多くの情報源にアクセスし、複雑なタスクに取り組めるようになりつつ、適切なガードレールも維持される。

強化されたエージェント機能群

強化されたエージェント機能群
STEP 1 ユーザーがメインエージェントにタスクを指示
STEP 2 メインエージェントがサブエージェントを動的に生成
STEP 3 サブエージェントが部分タスクを並列実行、非同期で結果を返す
メインエージェント  サブエージェント生成  非同期タスク完了

Antigravity 2.0では、エージェントの能力が大幅に強化された。中核となるのは「動的サブエージェント」「非同期タスク管理」「JSONフック」の3つだ。

動的サブエージェント

メインエージェントがタスクを実行する際、必要に応じてサブエージェントを動的に定義し、呼び出せるようになった。サブエージェントは焦点を絞った部分タスクを担当する。これにより、メインエージェントのコンテキストウィンドウが汚染されず、複数のサブタスクを並列に処理できる。

コンテキストウィンドウとは、エージェントが一度に把握できる会話や情報の範囲のことだ。長大なタスクではここがすぐに一杯になり、エージェントの応答品質が落ちる原因になっていた。サブエージェントへの委譲は、この問題への有効な対策となる。

非同期タスク管理

タスクやコマンドを非同期で実行できるようになった点も大きい。メインエージェントが処理をブロックされることなく、バックグラウンドで複数の作業を進められる。たとえば、コードのビルドを走らせながら次の機能の設計について対話を続ける、といった並行作業が可能になる。

JSONフック

JSONフックは、エージェントの動作を外部から制御する仕組みだ。シンプルなJSON形式でフックを定義し、エージェントの特定の挙動をインターセプトして制御できる。柔軟なカスタマイズを可能にしつつ、設定の複雑さを抑えている。

スケジュールタスクとプロジェクト管理

スケジュールタスクとプロジェクト管理
スケジュールタスクの流れ
ユーザー /schedule コマンドで指示 Antigravity cron式で定期実行を登録
Antigravity 設定時刻にエージェントを自動起動 エージェント タスク実行、結果を通知

Antigravity 2.0では、エージェントとの新しい関わり方として「スケジュールタスク」が導入された。cron式を使ってエージェントの起動スケジュールを事前に定義できる。日次レポートの生成、定期的なデータ収集、ナイトリービルドの監視など、手動で毎回指示を出す必要がなくなる。

スラッシュコマンド「/schedule」を使うか、専用のスケジュールタスク画面から設定する。一度だけのタイマー実行と、繰り返しの定期実行の両方に対応している。

新しいスラッシュコマンドと音声入力

/goal
指定タスクを完了まで実行、中間確認なし
/grill-me
実装前に計画の詳細を質問で確認
/schedule
タイマーまたは定期実行のスケジュールを設定
/browser
ブラウザ操作を明示的に指示、使用しない時は無視

Antigravity 2.0には、エージェントとの対話をより精密に制御するための新しいスラッシュコマンドが追加された。

4つの新コマンド

/goalは、指定したタスクを完了まで実行させ、途中でユーザーに入力を求めない。長時間の作業を任せきりにしたい場面で有効だ。/grill-meは実装開始前に、エージェントが逆に質問を投げかけて計画の詳細を詰める。見落としを事前に洗い出すのに役立つ。/scheduleは前述のとおり、タスクのスケジュール実行を指示する。/browserは、エージェントにブラウザ操作を明示的に許可するかどうかを制御する。

音声入力のライブ文字起こし

テキスト入力欄の横にあるマイクアイコンを使った音声入力が、ライブ文字起こしに対応した。従来は生の音声ファイルをモデルに渡していたが、2.0では発話と同時にテキスト化が進む。音声の遅延を感じさせず、より自然な対話が可能になった。

Antigravity IDEとの関係と今後の展望

Antigravity IDEとの関係と今後の展望

Antigravity 2.0は独立したアプリケーションとして提供されるが、従来のAntigravity IDEがすぐに置き換わるわけではない。IDE側のAgent Managerも当面は維持され、今後のアップデートでIDEからAgent Managerが分離される予定だ。IDEは純粋なエージェント駆動型IDEとして残る。

すでにAntigravity IDEをインストールしているユーザーは、次回のアップデートで自動的にAntigravity 2.0に更新される。その際、IDEを残すかどうかを選択できる。両アプリはドック上でアイコン背景が異なり、2.0は白背景、IDEは黒グリッド背景で区別される。

Google DeepMindの記事によれば、社内のGooglerたちはすでにAntigravity 2.0と各種IDEを併用しているという。今後、主要なIDE向けの互換拡張機能やプラグインも提供される予定だ。

今後のロードマップ

Antigravity 2.0と同時に、CLI、SDK、APIも発表された。他のGoogle製品や技術スタックとの統合も進められており、エージェントハーネスとモデル層の共同最適化が継続される。記事では、リモートコントロール機能、さらなる製品統合、クラウドデプロイエージェントなどが今後の展開として示唆されている。

この記事のポイント

  • Antigravity 2.0はIDEを廃した完全エージェントファーストの独立アプリケーション
  • 動的サブエージェントと非同期タスク管理で複雑な作業を効率的に処理
  • スケジュールタスクにより、エージェントの定期実行が自動化可能
  • 音声入力がライブ文字起こしに対応し、対話のテンポが向上
  • 従来のIDEも維持され、開発者は両方を併用できる