SDLCからADLCへ｜Cloudflareが示した「エージェントに開発工程を任せる」7つの条件

Cloudflareが2026年8月4日、「The Agent Development Lifecycle has arrived on Cloudflare」という記事を公開しました。書き手は同社の Brendan Irvine-Broque 氏です。

主張は挑発的です。50年続いてきた SDLC（ソフトウェア開発ライフサイクル）はもう前提が崩れているので、エージェントが全工程を回す「ADLC（Agent Development Lifecycle）」に置き換わる ——そして、そのための道具を Cloudflare が一式そろえた、という発表でした。

この記事は、その発表を「何を言っているのか」「何が実際に出たのか」「Cloudflareを使わない人に何が残るのか」の順で解きほぐします。同時公開された関連記事（@cloudflare/ci、ローカルトレース、Cloudflare Agents／Agent Traces、社内標準の AI 強制、Astroのソフトウェア工場）も突合して、構想の部分と実測値がある部分を切り分けて書きます。

要点を先に3行で置きます。

• 診断：AIが実装を最速・最安にした結果、詰まる場所がレビュー・デプロイ・保守へ移った。ボトルネックが下流に移動しただけで、全体は速くなっていない
• 処方：エージェントを実装係に閉じ込めるのをやめ、検証・マージ・デプロイ・運用まで任せられる基盤を作る（＝ソフトウェア工場）。そのために基盤が満たすべき条件が7つある
• 実物：CI/CDをTypeScriptで書く @cloudflare/ci、ローカル開発のOpenTelemetryトレース、エージェント専用の可観測性 Agent Traces など。うち一部はプライベートベータで、誰でもすぐ全部使えるわけではない

1. 出発点：SDLCの経済性が反転した

記事はまず歴史から入ります。複数のプログラマが1つのコードベースで協働する方法を体系化したのが SDLC で、原型は 1975年のRANDの研究「Systems Development Lifecycle」 に遡ります。段階はおなじみのものです。

Plan（計画）→ Design（設計）→ Implement（実装）→ Test（テスト）→ Deploy（デプロイ）→ Maintain（保守）→ Retire（廃止）

ここでCloudflareが指摘するのは、AIが変えたのは「速さ」ではなく各段階のコスト比だという点です。

記事の言い方はこうです。「エージェントは、チームがレビューし、デプロイし、保守できるより速くコードを書ける」。そして「我々は皆、自分のシステムと顧客と自分自身を、slop（雑に量産された成果物）から守ろうとしている」。

つまり 一箇所を速くしたら、詰まりが下流へ移動しただけ、という診断です。ここは実務感覚と合う人が多いと思います。生成量が増えるほど、レビュー待ちのPRが並び、デプロイの判断が渋滞し、誰も全体像を把握していないコードが増える。速くなったのは実装であって、リリースではありません。

2. 主張の核：「書かせるだけ」は成立しない

では対処は「エージェントを絞る」なのか。記事は逆を取ります。もっと権限を渡せ、と。

根拠として置かれている比喩が分かりやすいので、そのまま紹介します。

チームのエンジニアに「コードは書いていい。ただし検証は別の人、マージも別の人、デプロイも別の人がやる」なんて絶対にやらせない。——だが、いま多くの企業がエージェントに対してやっているのは、まさにそれだ。

人間のエンジニアには、自分の変更を自分でテストし、自分でマージし、自分でデプロイし、壊れたら自分で直すところまで持たせます。にもかかわらず、エージェントには実装だけをやらせて、残り全部を人間が引き取っている。だから人間側が詰まる。 当たり前の話ですが、言われるまで気づきにくい構造です。

そこで記事が提示するのが「ソフトウェア工場（software factory）」という枠組みです。

「機械を作る機械（machine that builds the machine）を作れ」という締めの言葉が、この発想を端的に表しています。

関連：AIに1件ずつ指示するのをやめ、仕組み側に作業を見つけさせて回す考え方は、当社でも「ループエンジニアリング」として整理しています。ADLCはこれをSDLC全域に広げた話として読めます。 ・ループエンジニアリングは実際どう使われているか — 海外4事例を「原則」で読み解く ・ループエンジニアリングを支えるのはアーキテクチャ設計

3. なぜ「人間が使っている道具」では足りないのか

記事でいちばん納得したのはここです。エージェントに人間と同じ道具を渡せばいいのでは？ という当然の疑問に、比喩で答えています。

持ち出されるのは自動運転車です。

人間が車を運転するのに必要なのは、目と耳くらいです。ところが自動運転車には、レーザーセンサー（lidar）、カメラ、専用の計算装置と、人間なら要らないものが山ほど積まれています。 なぜかというと、狙っている安全性の水準が人間と同じではないからです。

自動運転車が「人間の8割くらいの運転」で良いなら、ここまでの装備は要らないだろう。だが目標はそこではない。人間よりはるかに安全であることが目標だ。だから自動運転車には、そのために専用設計された技術が載っている。

ソフトウェアも同じだ、というのが主張です。「10回に8回はうまくいく」から「ほとんど失敗しない」へ引き上げようとした瞬間、必要な装備が変わる。

というのも、人間はうまくいったかどうかを、かなりの部分「感覚」で確かめています。画面をざっと眺めて違和感を拾う。気になったらSlackで「これ大丈夫ですか」と聞く。経験から「まあ問題ないでしょう」と判断して進める。エージェントはこれが全部できません。 見て察する、聞いて確かめる、空気を読む——どれも使えないので、代わりに同じ情報が機械にも読める形で取れていなければならないわけです。

だから「人間の作業手順の一部をAIに差し替える」やり方では、成功率をある水準より上に持っていけない。この前提で読むと、次に出てくる7条件が「あると便利な機能一覧」ではなく、成功率を上げるために欠かせない計器類に見えてきます。

4. 中心：ソフトウェア工場の7条件

記事の実質的な中核はここです。エージェントがSDLC全域を安全に回すために、基盤（プラットフォーム）側が満たすべき性質が7つ挙げられています。自社基盤の点検リストとしてそのまま使える部分なので、原文の主張とあわせて、実務でどこに刺さるかを添えます。

補足として、原文の表現を引いておきます。

1. Programmatic ——「ClickOpsは人間にとっても悪い習慣だったが、エージェントにとっては論外（non-starter）だ」。管理画面をクリックして設定する運用は、エージェントには扱えません。ここは7条件の中でいちばん反論しづらいところです。

2. Horizontally scalable ——「すべてのエージェントが、本番と一致する自分専用のプレビューを持たなければならない」。人間のチームなら共有ステージングを順番待ちで使えますが、エージェントを何十体も並列で回すなら、環境が使い回せる前提が崩れます。

3. Reproducible ——例として挙がるのが「iPhone 15で4G回線をシミュレートする」。ユニットテストと結合テストの枠では届かない領域まで、機械が再現できる必要がある、という主張です。

4. Real-time, push based ——「正しいダッシュボードを人が見に行くことに頼るのは、もともと悪い方法だったが、エージェントでは完全に破綻する」。人が見に行く運用は、エージェントには「起動条件が存在しない」ことを意味します。

5. Atomic ——「すべての変更は、無関係な挙動に影響を与えずに、独立してテスト・リリース・観測・巻き戻しができる必要がある」。ここは基盤の話に見えて、実際にはアーキテクチャの話です。変更の単位が切り出せないコードベースでは、この条件は道具では埋まりません。

6. Permissioned ——エージェントが必要に応じて権限昇格を要求できる経路が必要。逆に言えば、その経路がないと「最初から強い権限を渡す」か「詰まったら人間が本番に手を入れる」の二択になります。

7. Self-improving ——「人は経験から学ぶ。……エージェントにも、経験から学ぶ手段が必要だ」。ここが後述の Agent Traces（全セッションの記録）につながります。

この7つを眺めると、Cloudflareの製品発表がなぜこの並びになったのかが読めます。7条件が要件定義で、製品群がその実装という構成です。

5. 何が実際に発表されたのか（5つ）

同日、5本の関連記事が同時公開されています。順に中身を見ます。

5-1. @cloudflare/ci ——CI/CDをYAMLではなくTypeScriptで書く

CI/CDパイプラインをCloudflare Workflows上で走らせるTypeScript SDK です。npmで配布され、GitHub上に cloudflare/ci として公開されています。

思想は「CI/CDパイプラインは単なるWorkflowだ。だが、Workflowはただのパイプラインよりずっと多くのことができる」という一文に集約されます。YAMLで書くと複雑さがすぐ限界に来る（YAML疲れ）ので、コードで書く。パイプラインの各ステップが Workflow の step.do() に対応します。

実際のコードはこう書けます。

// 依存インストール（package.json / bun.lock をキーにキャッシュ）
const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});

// 依存を引き継いだまま4つを並列実行
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' });

YAMLの needs: に相当する依存関係が、変数のスコープと Promise.all で表現されているのが要点です。deps から派生したステップは、インストール済み環境（R2に保存されたサンドボックスのスナップショット）を引き継ぐので、ステップごとに install を再実行しません。

Workflows上に載っていることの効き目は3つあります。

• 耐久実行：失敗ステップは状態を保持したまま自動リトライされ、進捗が失われない
• 特定ステップからの再開：全体を再実行せずに、途中から再開できる
• ステップ単位の可視化：入力・出力・実時間・CPU時間をダッシュボードで確認できる

そして自己修復（self-healing）。ステップの失敗を try/catch で受け、Durable Object を継承した HealingAgent に渡す構成が示されています。

const healer = await getAgentByName(this.env.HEALER, event.instanceId);
const result = await healer.heal({
  failure: enrichFailure({ failure, event, baseBranch }),
  prompt: 'Fix every observed failure without weakening validation.',
});

プロンプトが「検証を弱めずに、観測されたすべての失敗を直せ」になっている点は見どころです。CIを通すために「テストを削る」「アサーションを緩める」という近道を、明示的に禁じています。修正は自動でコミットされ、人間の承認待ちとして上がります。

ただし前提があります。トリガーは Cloudflare の Artifacts（「数百万リポジトリ規模にスケールするバージョン管理ストレージ」）への push イベント（cf.artifacts.repo.pushed）で、Artifacts はプライベートベータです。GitHubなど他のバージョン管理からのトリガーは、現時点ではロードマップ側（他にプレビュー／ステージングデプロイ、割合ベースのロールアウト、monorepo対応）。つまり今日から自社のGitHubリポジトリに載せ替えられる、という段階ではありません。

5-2. ローカル開発のOpenTelemetryトレース

wrangler dev と vite dev が、ローカル実行の Worker について OpenTelemetry のトレースを自動で収集するようになりました。SDKの導入も設定も不要で、fetch呼び出し、各バインディング（KV・D1・R2・Durable Objects・Queues）、ハンドラのライフサイクルが記録されます。

仕組みは3層です。

1. ランタイム（workerd）が全操作のスパンを自動で取る
2. Wrangler／Viteプラグインが Miniflare 経由でイベントを集め、ローカルのSQLiteバックドなDurable Objectにトレースとして保存する
3. 開発サーバがエージェントのセッションを検知すると、Local Explorer API（http://localhost:8787/cdn-cgi/explorer/api）へのヒントを自動で出力する

これが効く理由は、エージェントのデバッグの仕方が変わるからです。従来は「仮のログを足す → リクエストを投げ直す → ログを読む → ログを消す」を何往復もしていました。トレースがあると、エラーを1回再現して、読み取り専用の観測エンドポイントに問い合わせるだけで、どの操作が失敗したかが分かります。

記事の例は「POST /api/orders が500を返している。原因を見つけて、直して、ローカルで検証しろ」という1行の指示です。エージェントはトレースを引いて、欠けているDBのカラムを特定し、直して、再テストする——デプロイ前に、ローカルで完結する。

7条件の3（再現性）と4（プッシュ型）を、ローカルまで引き下ろした発表と言えます。

5-3. Cloudflare Agents と Agent Traces

エージェントのホスティングと、その可観測性の製品です。狙いは7条件の7番目（自己改善）です。

問題設定が的確なので引きます。従来のアプリ監視はエージェントには効きません。APIは HTTP 200 を返しているのに、エージェントとしては失敗している——間違ったツールを選んだ、古いコンテキストを渡した、リトライループでトークンを溶かした。ステータスコードでは何も分かりません。

Agent Traces は OpenTelemetry の生成AI向けセマンティック規約に沿って、モデル呼び出し・ツール実行・トークン使用量を丸ごと記録します。

答えたい問いは「時間はどこに消えたのか：モデルか、ツールか、インフラか」「エージェントは正しいツールを選んだのか」。ここが構造化データとして溜まるから、評価（eval）や改善のループに回せる、という設計です。

料金は現時点ではベータで無料。2026年10月1日から Workers Observability の課金に統合されます（Freeは1日20万イベント・保持3日、Paidは月2,000万イベント込みで超過100万あたり$0.60・保持7日）。OTLP互換の外部プロバイダへのエクスポートも Wrangler の設定で可能です。

5-4. 社内標準をAIに守らせる「Cloudflare Codex」

これは製品ではなくCloudflare自身の社内運用の開示で、今回の発表群のなかでいちばん具体的な数字が出ている記事です。

仕組みはこうです。散在していたエンジニアリング標準を、RFC形式（RFC 2119 の SHOULD / MUST を使う）で1つのリポジトリに集約する。ドメイン（フロントエンド、コントロールプレーン、セキュリティ、信頼性、TypeScript、Rust……）ごとにオーナーを置き、マージリクエストで提案→複数段のレビュー→オーナー承認→社内サイトに公開。さらに「enforced（強制）への昇格」を別ステップにして、ブロックする標準とそうでない標準を分けています。現在 60本以上のRFCがあります。

技術的な工夫として、コーパス全体をLLMに食わせない点が挙げられています。専用エージェントが SHOULD / MUST の文だけをメタデータ付きのJSON構造に抽出し、各文に安定したslug識別子を振る。エージェントは必要なときだけ本文全体を読み込みます。コンテキストウィンドウの制約と精度を、構造化で両取りする設計です。

これを3種のエージェントが使います。

機械的に検証できるものはリンタ設定パッケージへ寄せ（TypeScriptは oxlint で実装済み、Rustは開発中、Goは計画）、CIを待たずにローカルでAIレビューを回すCLIも用意されています（CIと同じ OpenCode ベースのエージェント）。

同社の結論は「AIは、正しいガイダンスを作業の現場に持ってくるときにいちばん役に立つ」。ガイダンスを検索させるのではなく、判断の場所に届ける、という方向です。

5-5. Astroのソフトウェア工場：OSSのissueをゼロへ

唯一の「これが動いている」実例です。OSSフレームワーク Astro の GitHub issue を自動でトリアージ・再現・検証・修正する仕組みです。

ワークフローは issue のラベルで駆動する状態機械で、triage needed から fix verified へ進みます。中身は人間の解決手順をそのまま4フェーズに割ったものです。

1. Reproduce（再現）：報告に添えられたリポジトリをクローンし、サンドボックスで問題を再現する
2. Diagnose（診断）：コードにログを差し込み、根本原因を特定する
3. Verify（検証）：テストスイート・コメント・ドキュメントを読み、バグなのか仕様通りなのかを確定する
4. Fix（修正）：再現を失敗するテストに変換し、解決策を出す

設計上重要なのは、各フェーズを隔離したサブエージェントとして走らせ、発見を report.md に書き出して次へ渡す点です。理由は明快で、1体に通しでやらせると「バグではないかもしれない」場合でも解決策をひねり出そうとするバイアスがかかるためです。フェーズを切り、証拠をファイルに落として引き継ぐことで、これを抑えています。

結果：

• オープンissueが 200件超 → 約30件（約85%削減）
• 1か月以内にゼロに到達する見込み（5年以上の歴史で初）
• 自動クローズや報告の無視によるものではない

そして、エージェントが失敗した箇所がコードベースの欠陥を指し示したという副産物が報告されています。

HMR（Hot Module Replacement）のバグは繰り返し失敗していたのが、開発者が**「その処理が何をしているか」を説明するコメントを1つ足した**ら明らかに改善した、という例が挙がっています。エージェントの失敗率が、コードベースの説明可能性のセンサーとして働いているわけです。

人間の関与点は残っています。修正を検証するのは元の報告者で、プレビューリリースを自分のプロジェクトで試す。動いたと確認されたら、自動でPRが開かれる。メンテナはトリアージの事務から離れ、フレームワーク開発とコミュニティ（Discord・RFC・機能要望）へ時間を移した、と書かれています。

6. SDLC各段階に、どの製品が当たるのか

記事の後半は、SDLCの各段階に Cloudflare の道具を割り当てた対応表になっています。整理すると次のとおりです。

いくつか補足します。

Flagship は Workers・Durable Objects・KV の上に作られたフィーチャーフラグで、サブミリ秒での評価をうたっています。Gradual Deployments が「別バージョン間でトラフィックを割る」のに対し、Flagship は「100%流れている単一バージョンの内部で挙動を切り替える」。エージェント運用での意味は明確で、フラグOFFのままコードをデプロイし、本番で安全に検証し、自律的にロールアウトを進められる。人間は各ステップを細かく承認するのではなく、境界（どこまで上げていいか）を決める側に回ります。ただしこれもプライベートベータです。

Browser Run は旧 Browser Rendering で、2026年5月に Cloudflare Containers 上へ載せ替えられ、同時実行4倍・応答50%高速化が報告されています。Puppeteer・Playwright・CDP・Stagehand から制御でき、Markdown・スクリーンショット・PDF・スナップショット・リンクを取得できます。

7. 冷静に見る：どこまでが実物か

ここは記事側が書いていない部分なので、突合した結果を書きます。この発表は「今日から全部動く」ではありません。

読み方としては、こうなります。

• 診断（実装が最速になり下流が詰まる） は、多くの現場の実感と合う
• 7条件 は、Cloudflareを使うかどうかと無関係に転用できる。ここがこの発表のいちばん再利用価値の高い部分
• 製品群 は、垂直統合の途上。ベータが複数あり、CI/CDの移行は Artifacts への移行を含むので、現時点の乗り換えコストは小さくない
• 数値の裏付け があるのは Astro（85%削減）と社内Codex（23万件指摘・1.6万件ブロック・600仕様・200インシデント）。逆に、@cloudflare/ci 自体のビルド時間・成功率・スケールの数値は記事に一切ありません

もう1点。「エージェントに全工程を任せる」という主張と、実際の設計がきちんと食い違っていないことは評価できます。自己修復エージェントの修正は自動マージではなく人間の承認待ち、Astroの修正検証は元の報告者、社内Codexの MUST 違反はマージをブロックする。権限は渡すが、確定は人間側に残すという線が引かれています。7条件の6番目（Permissioned＝段階的な権限昇格）が、この線引きに対応しています。

8. Cloudflareを使わない場合に、何が残るか

自社基盤でこの発想を取るなら、7条件を点検表に落とすのが一番効きます。実務で詰まりやすい順に並べ替えました。

そして、Astroの事例から取れる最も安価な学びを1つ。エージェントが繰り返し失敗する箇所は、コードベースの説明が足りない箇所です。ツールを増やす前に、失敗したタスクのログを見て「なぜ分からなかったのか」を潰す。コメント1行で改善する例が実際に報告されているので、着手コストはほぼゼロです。

まとめ

• Cloudflareが2026年8月4日、SDLCをADLC（Agent Development Lifecycle）へ置き換えるという主張と、そのための道具群を発表した
• 診断は「AIが実装を最速・最安にしたので、詰まりがレビュー・デプロイ・保守へ移った」。処方は「エージェントを実装係に閉じ込めず、全工程を任せる（＝ソフトウェア工場）」
• 根拠の比喩は自動運転。「10回に8回うまくいく」水準なら人間用の道具で足りるが、ほとんど失敗しない水準を狙うなら専用設計が必要
• 基盤が満たすべき条件は7つ：Programmatic / Horizontally scalable / Reproducible / Real-time, push based / Atomic / Permissioned / Self-improving。ベンダーを問わず自社の点検表に転用できる
• 実物は、CI/CDをTypeScriptで書く @cloudflare/ci（自己修復エージェント込み）、ローカル開発のOpenTelemetryトレース、エージェント専用の可観測性 Agent Traces、社内標準をAIに守らせる Cloudflare Codex、Astroのソフトウェア工場
• 数値の裏付けがあるのは Astro（オープンissue 200件超 → 約30件・85%削減） と 社内Codex（約23万件の違反指摘・約1.6万件のマージブロック・約600仕様の事前レビュー・200件超のインシデントレポート評価）
• ただし Artifacts と Flagship はプライベートベータ、Agent Traces は2026年10月1日から課金。@cloudflare/ci は現状 Artifacts へのpushが前提で、乗り換えコストは小さくない
• 設計上の一貫性として、権限は渡すが確定は人間に残す線が引かれている（自己修復の修正は承認待ち、Astroの検証は報告者、MUST違反はマージブロック）

参考にした一次情報

• The Agent Development Lifecycle has arrived on Cloudflare: https://blog.cloudflare.com/agent-development-lifecycle/
• Why Workflows and Artifacts simplify CI/CD pipelines（@cloudflare/ci）: https://blog.cloudflare.com/ci-workflows
• OpenTelemetry traces in local dev: https://blog.cloudflare.com/local-tracing
• Introducing: Cloudflare Agents and Agent Traces: https://blog.cloudflare.com/agents-on-cloudflare
• How Cloudflare enforces engineering standards using AI: https://blog.cloudflare.com/engineering-standards-enforcement
• How we built a software factory to drive Astro's GitHub issue count to zero: https://blog.cloudflare.com/astro-issue-triage
• Flagship（フィーチャーフラグ）: https://blog.cloudflare.com/flagship/
• Browser Run: now running on Cloudflare Containers: https://blog.cloudflare.com/browser-run-containers/
• Systems Development Lifecycle（RAND, 1975）: https://www.rand.org/pubs/reports/R1855.html