Cloudflareにエージェント開発ライフサイクルの時代が到来

エンジニアを束ねるマネージャーたちは、過去数十年にわたり、複数のプログラマーが1つのコードベースを共同で開発するための方法を模索してきました。この取り組みの歴史は、1975年にRANDが提唱した「Systems Development Lifecycle（システム開発ライフサイクル）」までさかのぼります。今現在では一般的に「Software Development Lifecycle（ソフトウェア開発ライフサイクル：SDLC）」と呼ばれており、以下のような開発工程を定義しています。

• プラン
• デザイン
• 実装
• テスト
• デプロイ
• 保守
• 廃止

AIによって、これまで最も時間とコストがかかっていた工程である「実装」が高速化・低コスト化した反面、SDLC（ソフトウェア開発ライフサイクル）の後続の工程の担当者に大きな負荷がかかるようになりました。これは、数千のプルリクエストや問題に圧倒されるオープンソースのメンテナンス担当者から、ソフトウェアの納品速度が飛躍的に高速化する中で、稼働中のシステムを維持しようとするプロダクションエンジニアにまで及びます。

私たちは皆、AIが雑に量産しただけの成果物（slop）の後工程であるシステムや顧客、そして自分自身を守ることに意識を向けています。

これを解決するための答えは一見すると逆説的ですが、エージェントにより多くのことを任せられるようにすることです。これは当然の流れと言えます。例えば、人間であればコードを書いたエンジニアに、検証、マージ、デプロイ、本番環境の監視、そして発生したバグ対応までを担当させるのに対し、現在、多くの企業ではエージェントはコーディングだけに徹して残り全部を人間が引き取る構造になっています。エージェントの性能は大きく向上し、より長時間稼働してはるかに大規模なタスクを処理できるようになっています。しかし現時点では、SDLC（ソフトウェア開発ライフサイクル）の中でのエージェントの活用状況には偏りがあります。

Cloudflareでは、エージェントもCloudflareサービスを利用する主体として扱っています。エージェントは、ドメインを購入したり、一時的なアカウントを作成したり、Cloudflare APIのすべての機能を利用する能力を備えています。私たちは、エージェントがお客様に代わってSDLC全体を管理できるようにするには、APIやツールが必要だと考えています。

そこで今回、エージェントが単なるコード生成にとどまらず、SDLCのより多くの工程を担えるようにする新しいツール群の提供を開始します。私たちは、この課題を自分たち自身で解決する中で構築してきたものや、そこから得た知見を共有します：

• @cloudflare/ci：Cloudflare Workflowsを基盤とした、数百万ものリポジトリでCI/CDを実行する新しい方法。自己修復機能を備え、エージェントを起動して、より複雑なタスクにも対応できます。
• ローカル開発環境でのOpenTelemetryトレース：本番環境と同じ可観測性をエージェントにも提供します。WranglerとCloudflare Viteプラグインに組み込まれています。
• Cloudflare AgentsとAgent Tracesの紹介：エージェントの状態を観測し、保守・改善するための新しい基盤です。エージェントから取得したOpenTelemetryトレースを中心に、エージェント管理のための環境を提供します。
• AIを活用してCloudflareがエンジニアリング標準を適用する方法：Cloudflare自身の経験として、すべての製品・システムのリポジトリや仕様に対して、ベストプラクティスを適用してきた取り組みを紹介します。
• AstroのGitHub Issueをゼロ件にするソフトウェアファクトリーの構築方法：大規模かつ成長を続けるオープンソースプロジェクトに対して、Issueの自動分類、再現、検証、修正を行うシステムを構築した経験を紹介します。

しかし、ここにはさらに大きな意味があります。SDLCを見直すと、どれほど優れた自動化を導入したとしても、その前提は、エージェントが生成できるコード量や、競争のためにソフトウェアチームが求められる開発スピードには対応できません。私たちは今こそ、SDLCをADLC（Agent Development Lifecycle：エージェント開発ライフサイクル）へ置き換える時期だと考えています。

SDLCはソフトウェアチームのためのもの。ADLCはソフトウェアファクトリーのためのもの。

現在、さまざまな人が「ソフトウェアファクトリー」の構築について話しています（参考記事1、2、3、4、5）。ソフトウェアファクトリーとは、エージェントを中心に動作し、入力された情報をもとに、ソフトウェアの構築、改善、デプロイ、管理までを自律的に行うシステムです。例えば、本番環境で発生したエラー、顧客からのバグ報告、新機能のアイデアなど、どのような入力であっても、それをエージェントに完全に任せることを想定しています。

しかし現在、エージェントを利用している場合でも、多くのソフトウェア開発プロジェクトは人間が間に入らなければいけない工程があると、そこで止まります。人間がエージェントに指示を出し、作業を続けるよう促し、コードレビューのフィードバックを適用するように指示し、多くのエージェントを常に監視しながら指示を与えています。多くのソフトウェアチームでは、依然として人間がSDLCの各工程を管理しています。変わったのは、各工程内の作業をエージェントに委任するようになったことだけです。

ソフトウェアファクトリーには「ソフトウェア製作工程すべての自動化は目指せるのか？」「人間の時間を、本当に人間にしかできない創造性、センス、判断が必要な作業へ、どのように振り向けられるか？」という考え方が背景にあります。これが実現できれば、私たちは設計に時間を使い、顧客と対話し、より大きなアイデアを追求できるようになります。

ソフトウェアファクトリーは、SDLCと同じ工程を管理する必要があります。しかし、それを支えるプラットフォームには、はるかに高度な要件が求められます。その理由は、エージェントにシステムの操作権限を渡し、運転を任せるのであれば、これまで人間が手作業で行っていたすべての工程を変える必要があるためです：

• プログラムから操作可能：「ClickOps（画面をクリックして行う手動操作）」は、人間にとっても煩わしい操作ですが、ましてやエージェントはこれを行うことはできません。すべての操作は、エージェントが呼び出し、デバッグし、信頼して利用できるAPIとして提供される必要があります。
• 水平方向にスケール可能：人間が画面を見ながら開発したり、本番投入前に問題を確認するためにステージング環境を手動で操作したりする場合、プレビュー環境は「あれば便利」という程度のものでした。しかし、エージェントが開発を主導する場合、すべてのエージェントが本番環境と一致する専用のプレビュー環境を保有している必要があります。
• 再現可能：例えば、iPhone 15で4G通信をシミュレーションした場合や、特定の国のIPアドレスからアクセスした場合にだけ発生するバグがある場合、一般的な単体テストや結合テストのツールでは対応することはできません。
• リアルタイムかつプッシュ型：人間がダッシュボードを確認してシステムが正常に動作しているか判断する方法は、以前から良い方法とは言えませんでした。しかし、エージェントの場合、この方法は完全に機能しません。必要なのは、イベントをきっかけにエージェントが作業を開始する仕組みです。
• 個別性：すべての変更は、関連しない部分へ影響を与えることなく、個別にテスト、リリース、観察が可能で、かつ元に戻せる必要があります。
• 許可制：現在、「必要性」ではなく「万が一に備えて」信頼できる数名のエンジニアに本番環境へのSSHアクセス権を与えている企業も多いと思いますが、エージェントにそのような権限を与えることはできません。しかし、必要に応じて権限を拡大し、より多くの操作を実行できる仕組みがなければ、エージェントが仕事を完遂することはできません。
• 自己改善性：人間は経験から学びます。入社直後の1週間や、初めてのオンコール対応では、人間は作業に時間がかかり、経験者について学ぶ必要があります。しかし、経験を積むことで、より速く、より正確に対応できるようになります。エージェントにも、経験から学習するための仕組みが必要です。

本番環境で実際に利用できる安全なソフトウェアファクトリーを実現するには、新しい仕組みが必要です。ソフトウェアファクトリーは、自動運転車のような他の自律システムと同様に、80%の確率で正常に動作する状態から、99%以上、さらに99.999%に近い信頼性へ到達するための課題に直面しています。

エージェントにSDLCを任せるなら、人間用に設計された仕組みも変える必要がある

例えば、自動運転車には、従来の車にはないセンサーや技術（Lidarセンサー、カメラ、推論を実行するための強力なコンピューティング環境、必要に応じて遠隔から介入できる中央指令システムとの接続）が搭載されています。

自動運転車が、人間の運転能力の80%程度まで到達するだけなら、おそらくこれらすべては必要ないでしょう。実際、自動運転技術は10年前にはすでに、人間の運転能力の約80%に近づいていました。しかし、目標はそこではありません。目指すべき基準は、人間のドライバーよりもはるかに優れ、安全であることです。国道101号線を時速約100kmで走行中に、安心して眠れるほど車に運転を任せるには、それだけの信頼性が必要です。だからこそ、自動運転車には、自動運転のために専用設計された技術が搭載されています。それが信頼を生み、事前にはすべて想定できない例外的な状況にも対応できるようにしているのです。

同じことは、自律的に動作するソフトウェア開発にも当てはまります。未だエージェントに自動承認とマージを許可して、本番サービス向けのPRを行わせていない理由を考えた場合、構築しているものの重要性に比例してその理由も多く出て来るでしょう。

開発工程中に起こりうる重大な問題だけでなく、顧客にとって本当に価値のあるものを作るために必要なすべての要素を考えると、その複雑さは驚くほど大きくなります。これは、GitHub ActionsのYAMLファイルに書けるような単純な直線的な手順には収まりません。また、従来の自動テストを実行するだけでは到底対応できません。例えば、ダッシュボードに対する小さな変更であっても、複数の役割、異なる専門分野、組織構造をまたぐ可能性があります。さらに、主観的な判断を伴う変更ほど、テストやエージェントへの委任が難しくなります。現在、これらの作業の多くは、おそらくCI/CDパイプラインには含まれていません。しかし、ソフトウェアファクトリーを動かすエージェントに完全な制御を任せたいのであれば、これらの工程も含める必要があります。

エージェントが工程全体を主導できるようにするためには、このような動的で複雑な一連の作業を制御する、より優れた仕組みが必要です。私たちは、それを実現するものがWorkflowだと考えています。コンテナ、エージェント、ブラウザを生成し、機能フラグの設定やテストユーザーへの公開、ログやトレースの調査、変更を段階にリリースしながら本番のメトリクスの監視など、リリースに向けて必要なすべての作業を安全に行うことができるものです。

CI/CDパイプラインは単なるWorkflowの一例です。しかし、WorkflowにはCI/CDパイプラインをはるかに超える可能性があります。

Cloudflare Workflowsは、複数の処理ステップを連結し、失敗したタスクを自動的に再試行し、数分、数時間、さらには数週間にわたって状態を保持する機能を備えています。Workflowは、複雑で動的なビジネスプロセスを、理解しやすい論理的なプログラムとして定義するために設計されています。このブログ記事では、WorkflowsとArtifactsを組み合わせることで、CI/CDパイプラインの定義や実行開始の方法が、根本的にどのようにシンプルになるのかを解説します。たとえば：

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = 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,
      },
    });

Workflowsは、単なる一連の直線的な処理手順にとどまりません。処理内容を状況に応じて動的に定義でき、エージェントや別のWorkflowを起動することもできます。この例では、過去1日分の新しいデータをレビューするWorkflowを示しています。このWorkflowは、エージェントにいつ、どのような指示（プロンプト）を送るかを完全に制御でき、さらに各処理ステップ間で必要なコンテキスト（情報）を引き継ぐことができます：

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

このパターンに気づき、CloudflareのようにWorkflowに目覚めると、「他にどんな作業をWorkflowに任せられるだろうか？」「人間がボトルネックになっているどのような工程をこのWorkflowとFlueエージェントの組み合わせに委任できるだろうか？」という考えが浮かんできます。

Cloudflareの技術スタックで実現する完全なADLC

Workflowによって複雑な処理ステップを制御でき、Artifactsによってコードを保存するための基盤が提供されます。この2つを組み合わせてSDLCの各工程を見てみると、エージェントがソフトウェアの構築、リリース、保守という一連のプロセス全体を担うために必要なすべての要素が、Cloudflare上に揃っています。

ソフトウェアファクトリーを構築するための基盤要素

現在、最先端を走る一部の人々は、未来のソフトウェアファクトリーを構築しています。最終的に、ソフトウェアファクトリーはエージェントやAIと同様に、ソフトウェアを構築する一般的な方法になるでしょう。しかし現時点では、大多数の人々や組織にとって、まだその段階には達していません。

それを変えたいと思います。

私たちは、その状況を変えたいと考えています。そして「このような大きな変革を、インターネット上のすべての人が利用できるようにするには、どうすればシンプルで使いやすいものにできるだろうか？」そして、「小さなスタートアップから世界最大級のプラットフォームまで、誰もが利用できるように公開すべき基盤要素とは何だろうか？」と自問してきました。

今回のケースでは、私たちは必要な基盤要素はすでに揃っていると考えています。もちろん、それらをさらに連携させたり、自分たち自身のソフトウェアファクトリーを構築し続け、そこから学んだりするためには、まだ取り組むべきことがあります。しかし、今この瞬間から、Cloudflare上で「機械を作る機械」を構築する準備は整っています。まずは@cloudflare/ciを使い、エージェントを構築し、SDLCのどこまでを自律化できるかあなたの手で試してみてください。