Cloudflare Agents Week 2026分析 — AIエージェントがクラウドインフラを自律的にプロビジョニングする

去年の今ごろ、AIエージェントインフラの話をすればKubernetes + LangGraphの組み合わせが定番だった。ところがCloudflareが4月のAgents Weekで見せた絵は少し違った。エージェントが単にAPIを呼ぶだけでなく、Cloudflareアカウントを自分で作り、ドメインを購入して、コードをデプロイする。「エージェントがクラウドの顧客になる」という言葉が誇張に聞こえるかもしれないが、今回は本当にそういう作りにした。

全体の発表を見渡して、私が最も印象を受けた点と半信半疑な点を合わせてまとめる。

Agents Week 2026とは

Cloudflareが2026年4月に「エージェント専用の一週間」を宣言し、毎日複数件の発表を繰り出したイベントだ。最終集計で20件以上の新機能とGA移行が発表された。会社全体が「エージェントがインターネットの主要なアクターになる」という前提のもとでインフラ全域を再編した印象がある。

発表リストは膨大なので、実際の開発に影響を与える項目を中心に絞った。

最も挑発的な発表 — エージェントがCloudflareアカウントを直接作る

正直、最初に読んだとき「これ本当?」と思った。内容はこうだ。ユーザーがCloudflareの利用規約に最初に同意しておけば、以後はエージェントが自律的にCloudflareアカウントの作成、有料サブスクリプションの開始、ドメイン登録、APIトークン発行、コードデプロイまで完了する。Stripeとのパートナーシップで決済トークン化が可能になり、OAuth + OIDCでエージェントを「信頼できるアクター」として認証する。

これが意味するところはかなり大きい。これまでAIエージェントの役割は「人間がアカウントを作っておいたインフラで作業する」ことだった。今回はエージェント自身がインフラをプロビジョニングする主体となる。SaaSを作るチームなら「エージェントが新規顧客のオンボーディングを代わりに処理する」シナリオが現実的に可能になる。

ただし、私が不安に思う点がある。エージェントが決済まで紐づいたアカウントを作るということは、コスト制御の仕組みが明確でなければリスクが大きい。Cloudflareの新しいtask_budget概念と組み合わせる必要がありそうだが、まだこの組み合わせの実践パターンはほとんどない。また、エージェントが作ったアカウントの法的責任の帰属も先例がない。利用規約にユーザーが同意していても、エージェントが誤ったドメインを登録した場合の責任が誰にあるのかは依然として曖昧だ。

開発者が実際に使える3つの発表

華やかな発表より、私にとってより実用的に見えたものがある。

Sandboxes GA: 2025年6月のベータから9ヶ月でGAになった。エージェント専用の隔離Linux环境だ。シェル、ファイルシステム、バックグラウンドプロセスがあり、on-demandで起動する。注目すべき点は「picks up exactly where it left off」という動作 — エージェントが中断後に再開するとき、同じ環境の状態を引き継ぐ。コンテナのスピンアップがミリ秒単位という点も利点だ。コード生成エージェントが実際にコードを実行してテストするサイクルが可能になる。

LangGraphやCrewAIのようなフレームワークでエージェントのコード実行環境を別途構成していたなら、Sandboxesはその部分をCloudflareが管理してくれる方式だ。フレームワークを選ぶよりもインフラ層を選ぶ決断に近い。

Artifacts: Git互換バージョン管理ストレージだ。数千万のリポジトリを作成でき、リモートソースからフォークもでき、標準のGitクライアントでアクセス可能だ。Private betaから5月初めにpublic betaになった。エージェントが作ったコードを永続的に保存してバージョン管理する用途だ。コンテキストが消えても成果物が残る。

Dynamic Workers: AIが生成したコードを実行する隔離ランタイムだ。既存のコンテナ比でミリ秒単位のスピンアップが可能だという。エージェントがコードを生成して、すぐに実行結果を受け取り次のステップに進むループが可能になる。

@cloudflare/agents SDKを実際に入れてみた

理論は十分なので実際に動かしてみた。

mkdir cloudflare-agent-demo && cd cloudflare-agent-demo
npm init -y
npm install @cloudflare/agents

インストールはすぐできる。@cloudflare/agents@0.0.16時点での主要なexportはAgent、AIChatAgent、routeAgentRequestの三つだ。

基本的なエージェントコードを書いた:

// src/index.ts
import { Agent, routeAgentRequest } from "@cloudflare/agents";

interface TaskState {
  processedCount: number;
  lastHeartbeat: string;
}

interface Env {
  TASK_AGENT: DurableObjectNamespace<TaskAgent>;
}

export class TaskAgent extends Agent<Env, TaskState> {
  async onStart() {
    this.setState({ processedCount: 0, lastHeartbeat: new Date().toISOString() });
    await this.schedule("0 * * * *", "heartbeat", {});
  }

  async heartbeat() {
    const count = this.sql<{ n: number }>`SELECT COUNT(*) as n FROM tasks`;
    this.setState({
      processedCount: count[0]?.n ?? 0,
      lastHeartbeat: new Date().toISOString()
    });
  }

  async onRequest(request: Request): Promise<Response> {
    return Response.json({ state: this.state });
  }

  async onEmail(email: ForwardableEmailMessage) {
    this.sql`
      INSERT INTO tasks (id, content, created_at)
      VALUES (${crypto.randomUUID()}, ${email.from}, ${Date.now()})
    `;
  }
}

export default {
  fetch: async (req: Request, env: Env): Promise<Response> => {
    const routed = await routeAgentRequest(req, env);
    return routed ?? new Response("OK", { status: 200 });
  }
};

wrangler devを実行するとローカルですぐに動く:

⛅️ wrangler 4.91.0
Your Worker has access to the following bindings:
  env.TASK_AGENT (TaskAgent)   Durable Object   local

⎔ Starting local server...
[wrangler:info] Ready on http://localhost:9998
[wrangler:info] GET / 200 OK (7ms)

Cloudflareのアカウントなしでもローカル開発はできる。重要な点が一つ: @cloudflare/agentsはcloudflare:workersランタイム専用なので通常のNode.jsでは実行できない。ERR_UNSUPPORTED_ESM_URL_SCHEMEエラーが出る。Wrangler経由でのみ実行可能だ。Claude Agent SDKのようにPython/Node.jsから直接importする方式に慣れた開発者には最初は戸惑うかもしれない。

アーキテクチャ的に興味深い設計選択

コードを見ていてCloudflareの設計意図がいくつか見えてきた。

SQLite内蔵: new_sqlite_classes一つ宣言するだけでAgentインスタンスごとにSQLiteが付く。別途DB設定なしでthis.sqlでクエリできる。Durable Objectの隔離性のおかげでマルチテナンシー構造が自然にできる。Agentインスタンスごとに独立したDBを持つのは最初は無駄に見えるが、状態隔離の面ではかなりすっきりしている。

スケジューリング内蔵: cron形式のスケジュールをエージェント内部から直接登録する。外部のcronサービスが不要だ。Durable Objectのアラームアピを薄くラップしたもので、エージェントコード内でスケジュールと状態管理が一緒になっているので凝集度が高い。

メールハンドラー: onEmailメソッド一つでメールを直接処理できる。Workers Email Routingとの連携だ。エージェントがメールを受け取ってタスクにするパターンが自然に書ける。

DaprエージェントがKubernetesでサイドカーパターンで状態とメッセージを管理する方式と比べると、Cloudflareのアプローチはインフラをあまり触らずにコードに集中する方向性だ。どちらもトレードオフがある。

正直な評価

良いところから言う。エージェントのためのインフラ層を最初から新しく設計したという点が一貫していて見える。Durable Objectの上に状態、スケジュール、メール、SQLite、スケジューリングを乗せた構造が「エージェントに何が必要かを理解して設計した」という感じを与える。ローカル開発環境がすぐ立ち上がるのも利点だ。

不安な点が二つある。

一つ目はベンダーロックインが強いこと。cloudflare:workersでしか動かず、Durable Objectの設計をそのまま踏まえる。後でプラットフォームを変えたいとなるとエージェントコードをかなり書き直す必要がある。MCPサーバーをKubernetesに乗せる方式のようにコンテナベースで行けばこの問題はないが、その代わりインフラの複雑度が上がる。

二つ目はエージェント間通信のパターンがまだ薄いこと。発表内容を見ると単一エージェントが大幅に強化されたが、複数エージェントが複雑に協力するパターンはSDKレベルでまだ薄い。マルチエージェントオーケストレーションを本格的に作るには追加の構造が必要だ。この部分はProject Thinkフレームワークで改善中とのことだが、まだ初期段階だ。

どんな場合にCloudflareを選ぶべきか

私の整理はこうだ。

合うケース: エッジのレスポンス速度が重要なエージェント、Cloudflare Workersベースで既に何かを運用しているチーム、「デプロイはできる限りシンプルに、コードに集中したい」という方向性、多数の独立したエージェントがそれぞれ状態を持つマルチテナンシー構造。

合わないケース: 複雑なマルチエージェントオーケストレーション（すでにLangGraphチームなら）、特定クラウドインフラ（AWS、GCP）に縛られているチーム、Node.jsやPythonランタイムで直接実行する必要がある要件。

Agents Weekの全体的な方向性は明確だ。CloudflareはAIエージェントインフラの標準の座を狙っている。KubernetesがコンテナerみたいにエージェントJidaの基盤になろうという意図だ。SDKがまだv0レベルなのでプロダクション適用には慎重さが必要だが、方向性に一貫性はある。直接試してみる価値はある。

Signed Agents：エージェントトラフィックへの暗号学的アイデンティティ

あまり注目されなかった発表だが、私には興味深かった：Signed Agentsだ。エージェントが送るHTTPリクエストに暗号学的な署名を付け、「これはエージェントが送ったもの」であることを証明できる仕組みだ。

現在、インターネットではエージェントのトラフィックと人間のトラフィックを区別する標準的な方法がない。User-Agentの文字列やIPパターンはあくまで推測だ。Signed Agentsはサーバー側が検証できるシグナルを提供する。署名を確認してエージェント専用のレート制限、課金、アクセス制御を適用できる。まだ初期段階の仕組みだが、方向性は正しい。エージェントが一般的なトラフィックとして扱われる時代になれば、暗号学的なアイデンティティはフィーチャーではなくインフラになる。

メールサービス パブリックベータ

Workers Email ServiceがAgents Weekでパブリックベータに移行した。SendGridやAWS SESのようなサードパーティのメールサービスを使わずに、エージェントが直接メールを送信できるようになった。

SDKに既に含まれているonEmailハンドラーと組み合わせることで、受信と送信の両方をCloudflareのスタック内だけで処理できる。顧客サポートエージェント、通知パイプライン、メールベースのタスク管理に直接活用できる。

まとめ

Agents Weekを全体として見ると、機能リリースというよりもポジショニング宣言に近い。20件以上の発表がすべて同じ方向を向いている：CloudflareはエージェントのためのKubernetesになろうとしている。

このWeekから実際に作るとしたら、まずSandboxesを選ぶ。「エージェントがアカウントを作る」というヘッドラインよりも、エージェントのコード実行に使える永続的な隔離Linux環境の方が、今すぐ使える実用価値が高い。

@cloudflare/agents@0.0.16はプロダクション適用の余地をまだ問う必要がある段階だ。しかし、エージェントインフラの選択肢を真剣に評価しているなら、ローカル環境を立ち上げて実際に確認してみることを勧める。20分、アカウント不要で試せる。

---

テスト環境: @cloudflare/agents@0.0.16、wrangler@4.91.0、Node.js v22.22.0、macOS 14
備考: エージェント自律アカウント作成機能は実際のCloudflareアカウントとStripe連携が必要でありローカルテストの範囲外だ。
原発表: Cloudflare Agents Week 2026