なぜ Cloudflare Agents は AI プロダクトに向いているのか

Cloudflare の公式ドキュメントによると、各 Agent は Durable Object 上で動作する。Durable Object は状態を持つマイクロサーバーで、独自の SQL データベース、WebSocket 接続、スケジューリングを備えている。つまり、AI エージェントに必要な基礎要素である記憶、リアルタイム接続、長時間の処理、エージェント単位の状態管理が、最初からプラットフォームに組み込まれている。

この構成が魅力的なのは、多くの AI アプリがまだ stateless なリクエスト応答モデルから出発しているのに対し、実際のエージェント製品はそれだけでは足りないからだ。会話を覚える必要があり、ツールを呼び出し、承認を待ち、あとで再開し、処理中も接続を維持する必要がある。Cloudflare Agents は、そうした動作を後付けではなく、自然な構成として扱えるようにしている。

Cloudflare は Agents をグローバルネットワーク上で実行し、数千万規模のインスタンスへスケールできると案内している。これは単なるスケールの話ではない。ユーザー単位、チケット単位、ワークフロー単位で Agent を設計できるという意味だ。

Durable Object ベースの Agent とは何か

この構成は、stateless function というよりも「状態を持つマイクロサーバー」と考えると分かりやすい。違いは次のとおりだ。

この違いは、プロダクトの自然な単位が継続的な状態であるときに特に効く。サポートボット、業務補助エージェント、承認システム、リサーチアシスタント、ライブ共同作業ツールは、実行と記憶を近くに置けるほど扱いやすい。

Agents API の docs でも、Agents は Durable Objects を必要とし、各 Agent が多数のインスタンスを持てると説明されている。ユーザーやケースごとに分離したい用途と相性が良い。

重要なパターン

Cloudflare の starter パターンは、実際の AI プロダクトで役立つものときれいに重なる。特に重要なのは次の四つだ。

1. ストリーミング AI チャット
2. サーバーサイドとクライアントサイドのツール
3. human-in-the-loop 承認
4. タスクスケジューリング

この組み合わせで、よくある Agent の動きのほとんどをカバーできる。チャットはストリーミングが必要で、アクションにはツールが必要で、危険な操作には人の承認が必要で、後処理や再試行にはスケジュールが必要だからだ。

import { Agent } from "agents";

export class SupportAgent extends Agent {
  async onRequest(request) {
    const payload = await request.json();
    // 状態を保存し、必要なら承認待ちで再開する。
    return new Response(JSON.stringify({ ok: true, payload }));
  }
}

モデル選択の自由度が高い

Cloudflare Agents は 1 つのモデル事業者に固定されない。公式 docs によると、Workers AI は標準で利用でき、OpenAI、Anthropic、Google Gemini、そして OpenAI 互換 API を持つサービスも呼び出せる。

この柔軟さは、プロダクト設計でかなり重要だ。Agent の状態と実行は Cloudflare に置きつつ、タスクごとに最適なモデルを選べるからだ。たとえば次のように考えられる。

• 速い応答は軽量モデル
• 構造化抽出は指示追従の強いモデル
• 長い推論は高性能モデル
• コストを抑えたい経路は Workers AI 優先

つまり、Agent アーキテクチャとモデルアーキテクチャを分離できる。この分離は、ロールアウトや A/B テストにも有利だ。

メモリと状態は最初から中心に置く

AI プロダクトで壊れやすいのは、記憶を後回しにする設計だ。会話履歴が増え、セッションのつなぎ込みが複雑になり、全体の見通しが悪くなる。Cloudflare Agents は、状態を Agent 単位の機能として扱いやすくしている。

公式 docs では、各 Agent インスタンスが同じコンテキスト内で動く独自の SQL データベースを持つと説明されている。実務では、次のような整理がしやすい。

• ユーザーの好みやプロフィール
• 最近の会話要約
• 進行中のタスク状態
• 承認フラグと期限
• 外部ツールの短期キャッシュ

大事なのは、記憶をプロンプトだけに押し込まなくてよいことだ。構造化された状態を分けて持てるので、何を覚え、何を要約し、何を捨てるかを整理しやすい。

長時間処理と human-in-the-loop

Agent 製品は 1 回のやり取りで完結しないことが多い。文書レビュー、外部 API の確認、承認待ち、再試行ループは時間がかかる。Cloudflare Agents は、こうした処理を通常のリクエストハンドラより自然に扱える。

human-in-the-loop は、特に危険または元に戻しにくい操作で重要だ。

• 返金、支払い、削除
• 外部システムに影響する変更
• 機密データを扱う操作
• ポリシー上、人の確認が必要な処理

良い流れは単純だ。Agent が提案し、人が限定範囲を承認し、その後に Agent が実行する。これで自動化と統制を両立できる。

提案:
- 要件を要約する
- 影響範囲を示す
- 承認を求める

承認後:
- 承認された範囲だけ実行する
- 決定を Agent state に保存する
- 必要ならフォローアップを予約する

観測可能性は静かに始まる

Cloudflare の observability docs によると、Agents は重要な操作に対して構造化イベントを出力し、誰も購読していないときはデフォルトで静かで、hot path にゼロオーバーヘッドである。

これは運用上かなりありがたい。最初からログを盛り込みすぎなくても、RPC 呼び出し、状態変化、スケジュール実行、ワークフロー遷移、MCP 接続などを構造化イベントとして追える。

状態を持つシステムはデバッグが難しくなりやすいが、意味のあるイベントが最初からあると原因追跡がずっと楽になる。

MCP デプロイにも合う

Cloudflare の MCP client docs では、接続が Agent の SQL storage に残り、Agent が MCP server に接続するとその server の tool が自動的に利用可能になると説明されている。

これは MCP が単なる tool call ではなく、永続的な関係だからだ。どの server に接続しているか、どの tool が使えるか、どう再接続するかを覚えておく必要がある。Durable Object の state と SQL があれば、その管理がかなり簡単になる。

配備の観点では、単純な serve path が魅力的だ。1 つの経路でリクエストを受け、state を保持し、MCP 接続を維持し、必要に応じて tool を呼び出せる。この単純さが、後の保守コストを大きく下げる。

stateless serverless より向く場面

次の条件に当てはまるなら、この構成はかなり強い。

• ユーザーが戻ったときに前回の状態を覚えていてほしい
• WebSocket のようなリアルタイム接続が重要
• ワークフローに承認が含まれる
• スケジューリングや再試行が必要
• ユーザー単位やケース単位で状態を分けたい
• MCP や tool connection を持続させたい

逆に、単発のテキスト変換だけなら、通常の Worker や別の stateless function で十分なことも多い。要点は、状態と接続がプロダクトの本質かどうかを先に見ることだ。

ロールアウトのチェックリスト

本番導入なら、まず次を確認したい。

1. Agent の境界を 1 文で定義する。ユーザー単位か、チケット単位か、ワークフロー単位かを決める。
2. state を分ける。記憶、進捗、承認状態、一時キャッシュを混ぜない。
3. model path を決める。Workers AI、OpenAI、Anthropic、Gemini のどれをデフォルトにするかを決める。
4. 承認が必要なアクションを先に洗い出す。
5. バックグラウンドのスケジュール処理を列挙する。
6. observability イベントをどこで購読するか決める。
7. MCP を使うなら、永続化と再接続の設計を先に固める。
8. 障害時の復旧と再試行を決める。

まとめ

Cloudflare Agents と Durable Objects は、AI アプリを「関数の連なり」ではなく 状態を持つプロダクト単位として設計しやすくしてくれる。これが最大の魅力だ。メモリ、リアルタイム接続、承認、スケジューリング、MCP の持続状態、構造化 observability を、別々のサービスに散らさず Agent の近くに置ける。

stateless serverless は今も有用だが、Agent 製品では state と connection を毎回外へ押し出すと複雑さが増える。Cloudflare のモデルは、その複雑さを platform 側へ寄せながら、グローバルスケールも維持できるのが強い。

References

• Cloudflare Agents overview
• Agents API overview
• Agent class internals
• Store and sync state
• Using AI Models
• Observability
• Human-in-the-loop patterns
• McpClient
• Cloudflare Durable Objects overview