各エージェントには、SQLiteを基盤とする永続的な仮想ファイルシステムが用意されます。ファイルの読み書きや編集、シェルコマンドの実行に加え、ファイルシステム操作、コード実行、環境構築を1つのワークスペースで扱えます 。
従来であれば、計算資源、ストレージ、サンドボックスを開発者自身が組み合わせ、ファイルの受け渡しや実行環境の管理まで行う必要がありました。「@cloudflare/computer」は、こうした違いをエージェントから隠し、複数の実行基盤を1台のコンピューターのように扱えるようにする試みです。
なお、現時点では早期プレビューであり、Cloudflareはスケールの大きいエージェント運用に取り組む利用者とともに設計を検証するため、オープンソースで提供しています 。
同じ8月3日には、Python WorkersとJavaScript/TypeScript Workersの間で、Workers RPCを利用した相互呼び出しにも対応しました 。
Service bindingsを使うこの仕組みでは、別の言語で動くWorkerのメソッドを、通常の関数呼び出しに近い形で実行できます。追加の依存関係、スキーマ定義、Protocol Buffers、手動のシリアライズ処理は必要ありません 。
PyodideのForeign Function Interface(FFI)が言語間の型変換を処理するため、構造化クローンに対応したデータを引数や戻り値として渡せます。例外は呼び出し元まで伝播し、オブジェクト、関数、ストリームといった要素も言語の境界を越えて扱えるとされています 。
これにより、Pythonで構築したエージェントがJavaScriptのデータ処理Workerを呼び出す、あるいはその逆といった構成を、複雑な通信レイヤーを追加せずに組み立てられます。
Cloudflareはさらに、WorkersとContainersでインバウンドTCP接続を受け付けられるようにしました。Cloudflareの非HTTPトラフィック向けイングレスプロキシであるSpectrumを通じて、ソケットをDurable ObjectsやContainersへ直接転送できます 。
Workersランタイムには、新たに connect(socket) ハンドラーが追加されます。これにより、WorkerがSpectrumから渡されたインバウンドTCPソケットを直接受け取れるようになります 。
この機能を利用すれば、双方向通信を行うgRPCアプリケーションを実行できます。また、Workers上でgRPCからgRPC-Webへの自動変換を利用する構成も可能です 。HTTPリクエストを基本としてきたWorkersに、ストリーミングや低遅延の双方向通信を必要とするサービスを組み込みやすくするアップデートと言えます。
今回の発表は、個別の機能追加というより、AIエージェントを動かすための基盤を一つのプラットフォームにまとめる方向性を示しています。
Cloudflareが今回打ち出したメッセージは明確です。AIエージェントにはコンテナだけでなく「コンピューター」が必要であり、開発言語の違いは連携の障壁にならず、通信プロトコルもHTTPに限られない——という考え方です。
この3つの機能が組み合わさることで、開発者はサーバーやコンテナの細かな管理、言語間の変換処理、プロトコル用の中継基盤を個別に用意せず、エージェントを構築・デプロイし、エッジ上で相互接続するための環境を整えやすくなります。Cloudflareは、エージェント経済を支えるインフラ層をWorkersの周辺に広げようとしています。