Vercelとは違うアプローチ — Cloudflareの「Project Think」が永続実行でAIエージェントの寿命を変える

AIエージェントのフレームワークはもう何十個もある。では、なぜCDN企業のCloudflareがわざわざ独自のランタイムを作ったのか？

答えは「時間」にある。現在の主要フレームワーク——LangChain、CrewAI、Mastra——はどれもリクエスト・レスポンス型の設計だ。ユーザーの入力を受け取り、処理し、結果を返す。数秒から数分の「寿命」が前提になっている。しかし本当に役立つエージェントは、数時間、ときには数日にわたって動き続ける必要がある。「明日の朝もう一度確認して」が通じなければ、エージェントはただの高機能チャットボットでしかない。

Cloudflareが4月に公開したProject Thinkは、その「長く生きるエージェント」を実現するための永続実行ランタイムだ。@cloudflare/thinkパッケージとしてCloudflare Agents SDKに統合されている。

Fibers——クラッシュしても死なない実行単位

Project Thinkの中核が「Fibers」と呼ばれる実行モデルである。

通常のサーバーレス関数は、プロセスがクラッシュすれば状態もろとも消える。Fibersはそうならない。実行中の状態を自動的にチェックポイントし、障害が起きても直前の状態から再開できる。いわばDurable Objectsの上に構築された「壊れないスレッド」だ。

これにより、エージェントは「データベースからレポートを取得 → 分析 → 3時間後に再チェック → 異常があればSlack通知」といった長時間ワークフローを、途中で止まることなく実行できる。タイマーやスケジューラを外部で管理する必要がなく、Fiber自体が「いつ再開するか」を知っている。

Sub-agents——隔離された子エージェント

もう1つの重要な概念がSub-agentsだ。

親エージェントが複雑なタスクを分解し、各サブタスクを独立した子エージェントに委任できる。ここでCloudflareらしいのは、各Sub-agentが専用のSQLiteデータベースと型付きRPCインターフェースを持つ点だ。Durable Objectsの1対1マッピングで管理されるため、子エージェント同士が干渉しない。

たとえば「競合3社のWebサイトを調査して比較レポートを作れ」というタスクなら、親エージェントが3つのSub-agentを生成し、それぞれが独立してブラウジング・分析を行い、結果を親に返す。1つの子エージェントがエラーを起こしても、他の子エージェントには影響しない。

これは単なるマルチエージェントの並列実行ではない。各Sub-agentが独自の永続ストレージを持つことで、「途中まで調べた結果」が消えないのが大きい。

サンドボックス実行とPersistent Sessions

Project Thinkには、LLMが生成したコードを安全に実行するためのサンドボックスも組み込まれている。Dynamic Workersと呼ばれる仕組みで、隔離環境内でコードを走らせ、ホスト環境を汚染しない。

Persistent Sessionsも見逃せない。会話履歴をツリー構造で管理し、分岐（フォーク）、圧縮、全文検索に対応する。チャットの文脈が100ターンを超えても、必要な情報を効率的に参照できる設計だ。

Vercelとの設計思想の違い

同じ「エージェントインフラ」でも、VercelのWorkflowsとProject Thinkは方向性がかなり異なる。

Vercelは既存のNext.jsエコシステムの延長線上にエージェント機能を載せている。AI SDKとVercel Workflowsの組み合わせで、フロントエンド開発者が慣れた環境のままエージェントを組めるのが強みだ。UIとの統合がスムーズで、プロトタイピングが速い。

一方、Project Thinkはインフラ側から設計している。Durable Objects、Workers、R2といったCloudflareの分散基盤の上に、エージェント専用の抽象レイヤーを重ねた形だ。UIは開発者が自分で用意する前提で、その代わりに永続実行・障害復旧・Sub-agentの隔離といった「本番運用で必要になる機能」が最初から入っている。

雑に言えば、Vercelは「エージェントを素早く作る」ためのもの、Project Thinkは「エージェントを落ちずに動かし続ける」ためのものだ。どちらが優れているという話ではなく、レイヤーが違う。

気になる点

まだ設計が若い。ドキュメントは充実してきているが、プロダクション事例が公開されている数は少なく、大規模運用での安定性は未知数だ。

Cloudflareエコシステムへのロックインも無視できない。FibersはDurable Objects前提の設計であり、AWSやGCPへの移植は事実上不可能だろう。「とりあえず試す」には向いているが、基盤として採用するなら長期的なベンダー依存を覚悟する必要がある。

LangGraphやCrewAIほどのコミュニティの厚みもまだない。ツール連携やプラグインの充実は今後の開発者の反応次第だ。

誰が使うべきか

Project Thinkが刺さるのは、「エージェントを作る」フェーズを過ぎて「エージェントを安定運用する」段階に入った開発者だ。プロトタイプならLangChainやMastraで十分。しかし、障害復旧、長時間実行、Sub-agentの隔離管理が必要になった時点で、Project Thinkの設計思想が効いてくる。

AIエージェントの競争が「誰が賢いか」から「誰が落ちないか」に移りつつある。Cloudflareは、その次のフェーズに先回りしたように見える。