Project Think: Cloudflareで次世代AIエージェントを構築する

• CloudflareがAgents SDKの次世代版であるProject Thinkを発表し、長時間実行エージェント向けに耐久的実行・サブエージェント・サンドボックス化されたコード実行・永続セッションなどの新しい中核プリミティブを提供
• 既存のコーディングエージェントはローカルノートPC上でしか動作せず、アイドル時にもコストが発生し、手動設定と管理が必要という限界があった
• エージェントは従来のアプリケーションと異なり1:1モデル（1ユーザー・1タスクごとに1インスタンス）で動作するため、数千万の同時セッションを支えるにはコンテナベースのコスト構造では持続不可能
• Durable Objectsベースのアクターモデルを活用し、エージェントが休眠中は計算コストゼロ、メッセージ受信時に自動的に起動する方式で大規模拡張の経済性を確保
• AIエージェントの第3の波としてインフラとしてのエージェント（耐久性・分散・サーバーレス・構造的セキュリティ）を目指し、あらゆる開発者が数十億ユーザー向けのエージェントを構築・デプロイできるプラットフォームを目標とする

---

Project Think 概要

• Cloudflare Agents SDKの次世代版で、長時間実行エージェント構築のための新しいプリミティブ群と、それらを統合するベースクラスを提供
• 主なプリミティブ: 耐久的実行(fibers)、サブエージェント、永続セッション、サンドボックス化されたコード実行、実行ラダー、自己記述拡張
• プリミティブを個別に利用することも、Thinkベースクラスを通じて素早く始めることも可能

コーディングエージェントの現状の限界

• Pi、OpenClaw、Claude Code、Codexのようなツールは、LLMにファイル読み取り・コード作成・実行・学習能力を与えると汎用アシスタントのように動作することを証明した
• こうしたコーディングエージェントは、コードだけでなくカレンダー管理、データセット分析、購買交渉、税務申告、ビジネスワークフロー自動化などにも活用される
• パターンは常に同じで、エージェントがコンテキストを読み、推論し、コードを書いて行動し、結果を観察して繰り返す → コードが行動の普遍的な媒体
• 現在の限界:
  • ノートPCや高価なVPSでしか実行できない: 共有・共同作業・デバイス間の切り替えができない
  • アイドル時にもコストが発生: 固定の月額コストがチーム・企業単位への拡大で急増
  • 手動インストール・管理が必要: 依存関係のインストール、アップデート管理、認証とシークレットの設定

エージェントの構造的問題: 1:1モデル

• 従来のアプリケーションは1つのインスタンスで多数のユーザーを処理するが、エージェントは1:1 — 各エージェントが固有のインスタンスとして1ユーザー・1タスクを担当する
• 1億人の知識労働者がそれぞれエージェントアシスタントを使うなら、数千万の同時セッションが必要
• 現在のコンテナ単位のコスト構造では持続不可能であり、別の基盤が必要

長時間実行エージェント

• 現在のエージェントは**一時的(ephemeral)**で、セッション終了時に消え、ノートPCがスリープすると中断される
• Agents SDKはDurable Objectsベースで、すべてのエージェントにアイデンティティ、永続状態、メッセージ受信時の自動起動機能を与える
• アクターモデル: 各エージェントはアドレス指定可能なエンティティとして独自のSQLiteデータベースを持ち、休眠中の計算コストはゼロ
• HTTPリクエスト、WebSocketメッセージ、スケジュールアラーム、受信メールなどのイベントが発生すると、プラットフォームがエージェントを起こして状態をロードする
• VM/コンテナとDurable Objectsの比較:
  • アイドルコスト: VMは常に計算コスト全額 vs DOはゼロ(休眠)
  • スケーリング: VMは手動プロビジョニング vs DOはエージェントごとに自動スケール
  • 状態: VMは外部DBが必要 vs DOは組み込みSQLite
  • 復旧: VMは自前で構築 vs DOはプラットフォームが自動再起動し、状態を保持
  • ルーティング: VMはロードバランサーやスティッキーセッションを自前構築 vs DOは名前→エージェントの組み込みマッピング
  • 10,000個のエージェント（各1%がアクティブ）: VMは10,000個の常時稼働インスタンス vs DOは約100個のみがアクティブ
• 新しいエージェント作成の限界コストは事実上ゼロ → 「ユーザーごとに1つ」「タスクごとに1つ」「メールスレッドごとに1つ」のエージェントモデルが可能

耐久的実行: Fibers

• LLM呼び出しは30秒、マルチターンのエージェントループはそれ以上実行され得るが、その間に実行環境が消える可能性がある（デプロイ、プラットフォーム再起動、リソース制限）
• runFiber(): 実行開始前にSQLiteへ登録される耐久的関数呼び出しで、stash()でチェックポイントを作成し、onFiberRecoveredで再起動時に復旧できる
• SDKがfiber実行中のエージェントを自動的に維持するため、特別な設定は不要
• 分単位の作業にはkeepAlive() / keepAliveWhile()で退避を防止
• CIパイプライン、デザインレビュー、動画生成のようなさらに長い作業は、作業開始後にjob IDを保存して休眠し、コールバック時に起動する

サブエージェント: Facets

• 単一のエージェントがすべての作業を行う必要はない
• サブエージェントは親と共同配置される子Durable Objectsで、それぞれ分離されたSQLiteと実行コンテキストを持つ
• Facetsベースで親エージェントとともに配置され、サブエージェント間でデータが暗黙に共有されることはない
• サブエージェントRPCの遅延は関数呼び出しレベルで、TypeScriptがコンパイル時に誤用を検出する

永続セッション: Session API

• 日・週単位で動作するエージェントには、通常のフラットなメッセージリスト以上のものが必要
• 実験的なSession APIは対話をツリー構造としてモデル化し、各メッセージにparent_idを付与
  • フォーク: 元の経路を失わずに代替案を探索
  • 非破壊圧縮: 古いメッセージを削除する代わりに要約
  • 全文検索: FTS5ベースで対話履歴全体を全文検索
• Agentベースクラスから直接利用でき、Thinkベースクラスの保存レイヤーとして機能

ツール呼び出しからコード実行へ

• 既存のツール呼び出し方式: モデルがツールを呼び出す → 結果をコンテキストウィンドウへ戻す → 繰り返す、ツールが増えるほどコストと非効率が増大
• ファイル100個 = モデルとの100回の往復
• モデルはツール呼び出しゲームよりもシステム利用のためのコード記述に優れている — これが**@cloudflare/codemode**の中核的洞察
• 順次ツール呼び出しの代わりに、LLMがタスク全体を処理する単一のプログラムを書く
• Cloudflare API MCPサーバーの例: ツール2個(search(), execute())のみを公開し約1,000トークン消費 vs エンドポイントごとにツールを用意する方式では約117万トークン → 99.9%削減

安全なサンドボックス: Dynamic Workers

• モデルがユーザーの代わりにコードを書くなら、そのコードの実行環境が核心的な問いになる
• Dynamic Workers: 実行時にミリ秒単位で生成される新しいV8分離環境で、数MBのメモリ
  • コンテナと比べて約100倍高速で、最大100倍メモリ効率が高い
  • リクエストごとに新規生成され、コード実行後に破棄できる
• 中核設計: ケイパビリティモデル — 汎用マシンを制限するのではなく、ほぼ無権限の状態から開始(globalOutbound: null、ネットワークアクセスなし)し、開発者がバインディングを通じてリソースごとに明示的な権限付与を行う
• 「これがやりすぎるのをどう防ぐか？」から**「これに正確に何をできるようにするか？」**への転換

実行ラダー(Execution Ladder)

• エージェントが必要に応じて段階的に上位の計算環境へエスカレーションするスペクトラム:
  • Tier 0 — Workspace: SQLite + R2ベースの耐久的仮想ファイルシステムで、読み取り・書き込み・編集・検索・grep・diffをサポートし、@cloudflare/shellを実行
  • Tier 1 — Dynamic Worker: LLM生成JavaScriptをネットワークアクセスのないサンドボックス分離環境で実行し、@cloudflare/codemodeを実行
  • Tier 2 — npm追加: @cloudflare/worker-bundlerがレジストリからパッケージを取得しesbuildでバンドルしてDynamic Workerへロード、import { z } from "zod"がそのまま動作
  • Tier 3 — ヘッドレスブラウザ: Cloudflare Browser Runでナビゲーション、クリック、抽出、スクリーンショットを実行し、MCPやAPIをサポートしないサービスに有用
  • Tier 4 — Cloudflare Sandbox: ツールチェーン、リポジトリ、依存関係が構成された環境でgit clone、npm test、cargo buildなどを実行し、Workspaceと双方向同期
• 中核設計原則: Tier 0だけでもエージェントは有用であるべきで、各ティアは追加的なもの

ビルディングブロックであり、フレームワークではない

• すべてのプリミティブは独立パッケージとして提供: Dynamic Workers、@cloudflare/codemode、@cloudflare/worker-bundler、@cloudflare/shell
• Agentベースクラスと直接組み合わせて、ワークスペース、コード実行、ランタイムパッケージ解決機能を独自フレームワークの導入なしで利用可能

プラットフォーム全体スタック

• エージェントごとの分離: Durable Objects — すべてのエージェントが独自の世界を持つ
• アイドル時コストゼロ: DO Hibernation — エージェントが起きるまで$0
• 永続状態: DO SQLite — クエリ・トランザクション可能なストレージ
• 耐久的ファイルシステム: Workspace(SQLite + R2)
• サンドボックス化されたコード実行: Dynamic Workers + @cloudflare/codemode
• ランタイム依存関係: @cloudflare/worker-bundler — import * from reactがそのまま動作
• Web自動化: Browser Run
• フルOSアクセス: Sandboxes — git、コンパイラ、テストランナー
• スケジュール実行: DO Alarms + Fibers
• リアルタイムストリーミング: WebSockets
• 外部ツール接続: MCP
• エージェント間オーケストレーション: サブエージェント(Facets) — 型付きRPC
• モデルアクセス: AI Gateway + Workers AI（または独自モデル）

Thinkベースクラス

• エージェントループ、メッセージ永続化、ストリーミング、ツール実行、ストリーム再開、拡張などチャットのライフサイクル全体を処理する統合ハーネス
• 最小のサブクラス: getModel()メソッドだけを実装すれば、ストリーミング、永続化、中断/キャンセル、エラー処理、再開可能なストリーム、組み込みWorkspaceファイルシステムを備えたチャットエージェントとして動作
• npx wrangler deployでデプロイ
• オーバーライド可能な項目: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• 各ターンごとに完全なエージェンティックループを実行: コンテキスト組み立て（基本命令 + ツール説明 + スキル + メモリ + 会話履歴）→ streamText呼び出し → ツール呼び出し実行（コンテキスト爆発を防ぐため出力を切り詰め）→ 結果を追加 → モデル完了またはステップ上限到達まで繰り返す

ライフサイクルフック

• Thinkはパイプライン全体を所有しなくても、チャットターンのすべての段階でフックを提供:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• 後続ターンで低コストモデルへ切り替え、ツール制限、クライアントコンテキストの受け渡し、すべてのツール呼び出しの分析ログ、後続ターンの自動トリガーなどをonChatMessageの置き換えなしで実現可能

永続メモリと長い対話

• ThinkはSession APIの上に構築され、ツリー構造メッセージと分岐を内蔵
• コンテキストブロックによる永続メモリ: システムプロンプト内の構造化セクションとして、モデルが読み取り時間とともに更新可能で、休眠をまたいで保持される
• モデルは"MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]"のような形で確認し、能動的に記憶できる
• エージェントごとに複数の対話を実行可能で、フォークにより元の会話を失わずに別方向を探索できる
• コンテキスト増大時の非破壊圧縮: 古いメッセージを削除する代わりに要約し、全履歴はSQLiteに保存
• FTS5ベース検索: セッション内または全セッションをまたいで対話履歴をクエリでき、エージェント自身もsearch_contextツールで自らの過去を検索できる

実行ラダー全体の統合

• ThinkはgetTools()の返り値ひとつで実行ラダー全体を統合: ワークスペースツール、実行ツール、ブラウザツール、サンドボックスツール、拡張ツールを一括で構成

自己記述拡張(Self-authored Extensions)

• エージェントが自分で拡張機能を直接記述できる: Dynamic Workers上で動作するTypeScriptプログラムとして、ネットワークアクセスとWorkspace作業権限を宣言
• ThinkのExtensionManagerが拡張をバンドルし（npm依存関係を含められる）、Dynamic Workerへロードして新しいツールを登録
• 拡張はDOストレージに永続化され、休眠中でも存続する
• 例: ユーザーがPRに関する質問をすると、30秒前には存在しなかったgithub_create_prツールが生成される
• ファインチューニングやRLHFではなく、コードによる自己改善ループ — サンドボックス化され、監査可能で、取り消し可能なTypeScript

サブエージェントRPC

• Thinkは親から**chat() over RPC**で呼び出されるサブエージェントとしても動作し、コールバックによるストリーミングイベントをサポート
• 各子が独自の会話ツリー、メモリ、ツール、モデルを持ち、親は詳細を知る必要がない

はじめに

• Project Thinkは**実験的(experimental)**な状態で、API表面は安定しているが今後も進化を続ける予定
• Cloudflare内部で自社のバックグラウンドエージェント基盤構築にすでに使用中
• Thinkは@cloudflare/ai-chatと同じWebSocketプロトコルを使うため、既存のUIコンポーネントがそのまま動作
• AIChatAgentベースで構築している場合、クライアントコードの変更は不要

AIエージェントの3つの波

• 第1の波 — チャットボット: 状態なし、反応的、脆弱、会話のたびに最初から始まり、メモリ・ツール・行動能力がなく、質問応答にしか有用でない
• 第2の波 — コーディングエージェント: 状態を維持し、ツールを使い、Pi・Claude Code・OpenClaw・Codexのようなツールとして、コードベースを読み、コードを書き、実行し、反復できる。適切なツールを持つLLMが汎用マシンであることを証明したが、ノートPC上で1ユーザー向けにしか動作せず、耐久性の保証がない
• 第3の波 — インフラとしてのエージェント: 耐久的で、分散され、構造的に安全で、サーバーレスで、インターネット上で動作し、障害を生き延び、アイドル時コストゼロで、行動ではなくアーキテクチャによってセキュリティを強制する