なぜWireはCloudflare Durable Objectsから移行するのか

なぜWireはCloudflare Durable Objectsから移行するのか JP · 2026年7月7日 · 4 分で読めます WireはAIエージェントのためのコンテキストコンテナです。これは、MCP経由でクエリされる、処理された知識（エントリー、埋め込み、知識グラフ、プロビナンスグラフ）の隔離されたストアです。初日から、すべてのコンテナはCloudflare Durable Objectでした。それが変わろうとしています。私たちはコンテナランタイムを一から再構築し、同一データ（同じコンテナ、同じ質問、同じジャッジ）で旧ランタイムと比較ベンチマークを行い、最初のワークスペースは自社で構築したデータプレーンに移行しました。これがベンチマークの背景にあるストーリーです。 これは「Cloudflareを離れた」という投稿ではありません。私はCloudflareを愛しており、Wireは可能な限りCloudflare上に留まります。API、フロントエンド、コントロールプレーン、そしてすべての処理は引き続きWorkers上で実行されます。Durable Objectsは、数千の小さく、ほとんどアイドル状態のステートフルユニットにほぼ完璧に適合し、構築する上でこれほど速いものを見たことがありません。信頼性の問題ではなく、4つの構造的な限界のために離れることにしました。 1. ベクトルインデックスがオブジェクトの外に存在した コンテナが行う最も重要なことは検索であり、埋め込みは別のサービスであるVectorizeにありました。これは最も頻繁にアクセスされるパス上でのネットワークホップであり、ドリフトする可能性のある状態の2番目のコピーです。DO SQLiteは拡張機能をロードできないため、インデックスをオブジェクト内に配置することはできませんでした。 2. データの隣にコンピューティングを置きたかった 検索はマルチステージのパイプラインです。ハイブリッド候補生成、フュージョン、クエリ拡張、そして広範なリランクです。Durable Objects上では、そのごく一部しかデータが存在する場所で実行できず、残りはオブジェクトの周りのサービスにエクスポートされていました。エージェントはツールループ内でコンテナを呼び出し、各ホップの変動がクリティカルパスに影響します。 3. 配置は作成時のみで、コンピューティングは常に共有されていた 配置のヒントは作成時に存在しますが、オブジェクトはその後移動しないため、ロンドンで作成されたコンテナはバージニア州のフリートのエージェントに永遠にサービスを提供します。また、テナントごとに専用のキャパシティを購入することもできません。私たちは、呼び出し元に追従する配置と、製品ティアとしての分離を望んでいました。有料ワークスペースは、独自のプロセスとマシンを得られます。 4. Durable Objectをセルフホストできない 規制対象のチームは、自身が管理するインフラストラクチャ上でコンテナを実行できるように求めています。Cloudflare上にのみ存在するランタイムではそれができません。 私たちが構築したもの 各組織は、すべてのコンテナに対してFly Machines上のホストプロセス（Bun）を1つ持ちます。コンテナは、sqlite-vecを介してベクトルインデックスが埋め込まれた1つのSQLiteファイルであり、候補検索はインプロセスで実行されます。モデルの呼び出し、クエリ埋め込み、リランクは依然として推論サービスに送信されます。スナップショットはオブジェクトストレージに保存されるため、コンテナはどこでもバイト単位で再構築されます。リージョンごとのルーターが呼び出し元の近くにコンテナを配置し、コントロールプレーンは署名付きリクエストを介してデータプレーンと通信し、コンテナの内容には一切触れません。 ウォームなツール呼び出しは、以前の2秒を超えるスパイクに対して約0.3秒で安定していますが、以前は約0.4秒でした。アイドル状態のコンテナは、以前の3.7秒に対して、エンドツーエンドで約1.4秒で起動します。最後の数値について正確に言うと、「Durable Objectのコールドスタート」ではなく、アイソレートはミリ秒単位で起動します。3.7秒は、私たち自身のスタックが再構築されるのにかかった時間でした。 表面上は何も変わりませんでした。同じコンテナURL、同じ5つのMCPツール、同じREST API、同じレスポンス形状です。エージェントは同じアドレスを呼び出し続け、移行されたコンテナへのリクエストは新しいランタイムによって応答されます。 耐久性の買い戻し Durable Objectsは、耐久性と単一ライターの一貫性を無料で提供しますが、離れるということはそれらを買い戻すことを意味します。Cloudflareは、DOのストレージ書き込みをすべて確認する前にレプリケートします。私たちの最初の試みは「次のチェックポイントで耐久性がある」というものでしたが、負荷の下でマシンを停止させるストレステストは、それが何を意味するかを正確に示しました。確認された書き込みの一部が失われました。本当の修正は、継続的なWAL（Write-Ahead Log）の出荷です。書き込みは、WALフレームがオブジェクトストレージに入るまで確認されません。グループコミットにより、これは約100ミリ秒に抑えられ、ダウンしたマシンは確認された書き込みを持ち去ることはできません。 もし上記の4つの機能が必要ないのであれば、プラットフォーム上に留まってください。 数字の正直な読み方 検索の改善（リコール@5が78.1%から89.1%へ）は、すべてアーキテクチャによるものではありません。より新しい埋め込みモデルに移行したこともあります。アーキテクチャが行うことは、高価な部分を安価にすることです。インプロセス検索により、過剰にフェッチして幅広くリランクすることができ、コンテナごとのインデックスは、正確な最近傍検索を行うのに十分な小ささです。完全な前後比較表と方法は、ベンチマークの書き込みで確認できます。 現状 新しいランタイムはベータ版です。プレビュー環境と、オプトインした本番ワークスペースで今日から利用可能であり、耐久性チェックがすべて緑になった後、本番環境への完全な移行が続きます。カットオーバーが完了したら、コンテナランタイムをオープンソース化する予定です。実際に実行しているコードを出荷すべきです。 AIエージェントに、より良いコンテキストを提供する準備はできていますか？Wireは、ドキュメントを構造化されたAI最適化コンテキストコンテナに変換します。ファイルをアップロードし、MCPツールを即座に入手してください。最初のコンテナを作成する