各エージェントには、SQLiteを基盤とする永続的な仮想ファイルシステムが用意されます。ファイルの読み書きや編集、シェルコマンドの実行に加え、ファイルシステム操作、コード実行、環境構築を1つのワークスペースで扱えます 。

従来であれば、計算資源、ストレージ、サンドボックスを開発者自身が組み合わせ、ファイルの受け渡しや実行環境の管理まで行う必要がありました。「@cloudflare/computer」は、こうした違いをエージェントから隠し、複数の実行基盤を1台のコンピューターのように扱えるようにする試みです。

なお、現時点では早期プレビューであり、Cloudflareはスケールの大きいエージェント運用に取り組む利用者とともに設計を検証するため、オープンソースで提供しています 。

PythonとJavaScriptのWorkerが直接呼び出し可能に

同じ8月3日には、Python WorkersとJavaScript／TypeScript Workersの間で、Workers RPCを利用した相互呼び出しにも対応しました 。

Service bindingsを使うこの仕組みでは、別の言語で動くWorkerのメソッドを、通常の関数呼び出しに近い形で実行できます。追加の依存関係、スキーマ定義、Protocol Buffers、手動のシリアライズ処理は必要ありません 。

PyodideのForeign Function Interface（FFI）が言語間の型変換を処理するため、構造化クローンに対応したデータを引数や戻り値として渡せます。例外は呼び出し元まで伝播し、オブジェクト、関数、ストリームといった要素も言語の境界を越えて扱えるとされています 。

これにより、Pythonで構築したエージェントがJavaScriptのデータ処理Workerを呼び出す、あるいはその逆といった構成を、複雑な通信レイヤーを追加せずに組み立てられます。

Spectrum経由のインバウンドTCPとgRPCに対応

Cloudflareはさらに、WorkersとContainersでインバウンドTCP接続を受け付けられるようにしました。Cloudflareの非HTTPトラフィック向けイン​​グレスプロキシであるSpectrumを通じて、ソケットをDurable ObjectsやContainersへ直接転送できます 。

Workersランタイムには、新たに connect(socket) ハンドラーが追加されます。これにより、WorkerがSpectrumから渡されたインバウンドTCPソケットを直接受け取れるようになります 。

この機能を利用すれば、双方向通信を行うgRPCアプリケーションを実行できます。また、Workers上でgRPCからgRPC-Webへの自動変換を利用する構成も可能です 。HTTPリクエストを基本としてきたWorkersに、ストリーミングや低遅延の双方向通信を必要とするサービスを組み込みやすくするアップデートと言えます。

3つの発表が示す「エージェント向けクラウド」の方向性

今回の発表は、個別の機能追加というより、AIエージェントを動かすための基盤を一つのプラットフォームにまとめる方向性を示しています。

• @cloudflare/computerは、「エージェントはどこで作業するのか」という問題に対応します。コンテナやサーバーレス関数のどちらかに一律で押し込むのではなく、永続的なファイルシステムと、タスクに応じた実行基盤を提供します 。
• クロス言語RPCは、PythonとJavaScriptを組み合わせたシステムの構築を簡単にします。異なる言語で書かれたWorkerを、1つのエッジランタイム上の部品として組み合わせられます 。
• インバウンドTCPとgRPCは、エージェントや周辺サービスをHTTPだけに限定しません。リアルタイム処理で重要になるストリーミング、双方向通信、低遅延のプロトコルを利用できる範囲が広がります 。

Cloudflareが今回打ち出したメッセージは明確です。AIエージェントにはコンテナだけでなく「コンピューター」が必要であり、開発言語の違いは連携の障壁にならず、通信プロトコルもHTTPに限られない——という考え方です。

この3つの機能が組み合わさることで、開発者はサーバーやコンテナの細かな管理、言語間の変換処理、プロトコル用の中継基盤を個別に用意せず、エージェントを構築・デプロイし、エッジ上で相互接続するための環境を整えやすくなります。Cloudflareは、エージェント経済を支えるインフラ層をWorkersの周辺に広げようとしています。

各エージェントには、SQLiteを基盤とする永続的な仮想ファイルシステムが用意されます。ファイルの読み書きや編集、シェルコマンドの実行に加え、ファイルシステム操作、コード実行、環境構築を1つのワークスペースで扱えます 。

従来であれば、計算資源、ストレージ、サンドボックスを開発者自身が組み合わせ、ファイルの受け渡しや実行環境の管理まで行う必要がありました。「@cloudflare/computer」は、こうした違いをエージェントから隠し、複数の実行基盤を1台のコンピューターのように扱えるようにする試みです。

なお、現時点では早期プレビューであり、Cloudflareはスケールの大きいエージェント運用に取り組む利用者とともに設計を検証するため、オープンソースで提供しています 。

PythonとJavaScriptのWorkerが直接呼び出し可能に

同じ8月3日には、Python WorkersとJavaScript／TypeScript Workersの間で、Workers RPCを利用した相互呼び出しにも対応しました 。

Service bindingsを使うこの仕組みでは、別の言語で動くWorkerのメソッドを、通常の関数呼び出しに近い形で実行できます。追加の依存関係、スキーマ定義、Protocol Buffers、手動のシリアライズ処理は必要ありません 。

PyodideのForeign Function Interface（FFI）が言語間の型変換を処理するため、構造化クローンに対応したデータを引数や戻り値として渡せます。例外は呼び出し元まで伝播し、オブジェクト、関数、ストリームといった要素も言語の境界を越えて扱えるとされています 。

これにより、Pythonで構築したエージェントがJavaScriptのデータ処理Workerを呼び出す、あるいはその逆といった構成を、複雑な通信レイヤーを追加せずに組み立てられます。

Spectrum経由のインバウンドTCPとgRPCに対応

Cloudflareはさらに、WorkersとContainersでインバウンドTCP接続を受け付けられるようにしました。Cloudflareの非HTTPトラフィック向けイン​​グレスプロキシであるSpectrumを通じて、ソケットをDurable ObjectsやContainersへ直接転送できます 。

Workersランタイムには、新たに connect(socket) ハンドラーが追加されます。これにより、WorkerがSpectrumから渡されたインバウンドTCPソケットを直接受け取れるようになります 。

この機能を利用すれば、双方向通信を行うgRPCアプリケーションを実行できます。また、Workers上でgRPCからgRPC-Webへの自動変換を利用する構成も可能です 。HTTPリクエストを基本としてきたWorkersに、ストリーミングや低遅延の双方向通信を必要とするサービスを組み込みやすくするアップデートと言えます。

3つの発表が示す「エージェント向けクラウド」の方向性

今回の発表は、個別の機能追加というより、AIエージェントを動かすための基盤を一つのプラットフォームにまとめる方向性を示しています。

• @cloudflare/computerは、「エージェントはどこで作業するのか」という問題に対応します。コンテナやサーバーレス関数のどちらかに一律で押し込むのではなく、永続的なファイルシステムと、タスクに応じた実行基盤を提供します 。
• クロス言語RPCは、PythonとJavaScriptを組み合わせたシステムの構築を簡単にします。異なる言語で書かれたWorkerを、1つのエッジランタイム上の部品として組み合わせられます 。
• インバウンドTCPとgRPCは、エージェントや周辺サービスをHTTPだけに限定しません。リアルタイム処理で重要になるストリーミング、双方向通信、低遅延のプロトコルを利用できる範囲が広がります 。

Cloudflareが今回打ち出したメッセージは明確です。AIエージェントにはコンテナだけでなく「コンピューター」が必要であり、開発言語の違いは連携の障壁にならず、通信プロトコルもHTTPに限られない——という考え方です。

この3つの機能が組み合わさることで、開発者はサーバーやコンテナの細かな管理、言語間の変換処理、プロトコル用の中継基盤を個別に用意せず、エージェントを構築・デプロイし、エッジ上で相互接続するための環境を整えやすくなります。Cloudflareは、エージェント経済を支えるインフラ層をWorkersの周辺に広げようとしています。