Dynamic WorkersにおけるDurable Objects：各AI生成アプリに独自のデータベースを提供

数週間前、私たちはDynamic Workersを発表しました。これはWorkersプラットフォームの新機能で、Workerコードを安全なサンドボックスに動的にロードできます。Dynamic Worker Loader APIは本質的に、Workersが当初から基盤としてきた基本的なコンピュート分離のプリミティブ、すなわちコンテナではなく**アイソレート**への直接アクセスを提供します。アイソレートはコンテナよりもはるかに軽量で、その結果、1/10のメモリ使用量で100倍高速にロードできます。非常に効率的であるため、「使い捨て」として扱うことが可能です。数行のコードを実行するために起動し、その後破棄します。セキュア版のeval()のようなものです。 Dynamic Workersには多くの用途があります。最初の発表では、ツール呼び出しの代替としてAIエージェントが生成したコードを実行する方法に焦点を当てました。このユースケースでは、AIエージェントがユーザーの要求に応じて数行のコードを記述し、それを実行することでアクションを実行します。このコードは単回使用を意図しており、一度だけタスクを実行し、実行後すぐに破棄されます。 しかし、AIにより永続性の高いコードを生成させたい場合はどうでしょうか？AIにカスタムUIを持つ小さなアプリケーションを構築させ、ユーザーが操作できるようにしたい場合は？そのアプリケーションに長寿命の状態を持たせたい場合は？ただし、もちろん、それは安全なサンドボックス内で実行させたいでしょう。 これを実現する一つの方法は、Dynamic Workersを使用し、そのWorkerにストレージへのアクセス権を与えるRPC APIを単純に提供することです。バインディングを使用すれば、Dynamic WorkerにリモートのSQLデータベース（Cloudflare D1でバックアップされているものや、Hyperdriveを介してアクセスするPostgresデータベースなど、選択は自由です）を指し示すAPIを与えることができます。 しかし、Workersにはこのユースケースに完璧に適合する、独特で極めて高速なストレージタイプも存在します：**Durable Objects**です。Durable Objectは特殊な種類のWorkerで、一意の名前を持ち、名前ごとにグローバルに一つのインスタンスが存在します。そのインスタンスにはSQLiteデータベースが接続されており、Durable Objectが実行されるマシンのローカルディスク上に存在します。これにより、ストレージアクセスは驚異的に高速になります：実質的にレイテンシはゼロです。 おそらく、あなたが本当に望んでいるのは、AIにDurable Object用のコードを書かせ、そのコードをDynamic Worker内で実行することでしょう。 しかし、どうすればよいのでしょうか？ これは奇妙な問題を提起します。通常、Durable Objectsを使用するには以下を行う必要があります： 1. DurableObjectを拡張するクラスを記述する。 2. Workerのメインモジュールからそれをエクスポートする。 3. Wrangler設定で、このクラスに対してストレージをプロビジョニングするよう指定する。これにより、受信リクエストを処理するためのあなたのクラスを指すDurable Objectネームスペースが作成される。 4. あなたのネームスペースを指すDurable Objectネームスペースバインディングを宣言する（または`ctx.exports`を使用する）、そしてそれを使用してあなたのDurable Objectにリクエストを行う。 これは自然にはDynamic Workersに拡張できません。まず、明白な問題があります：コードが動的です。Cloudflare APIを一切呼び出さずに実行します。しかし、Durable ObjectストレージはAPIを通じてプロビジョニングされる必要があり、ネームスペースは実装クラスを指している必要があります。あなたのDynamic Workerを指すことはできません。 しかし、より深い問題があります：仮にどうにかしてDurable ObjectネームスペースをDynamic Workerに直接指し示すように設定できたとして、そうしたいでしょうか？あなたのエージェント（またはユーザー）が、Durable Objectsでいっぱいのネームスペース全体を作成できるようにしたいですか？世界中に広がる無制限のストレージを使用できるようにしたいですか？ おそらく望まないでしょう。ある程度の制御を望むはずです。作成するオブジェクトの数を制限したり、少なくとも追跡したりしたいかもしれません。おそらく単一のオブジェクトに制限したいでしょう（「バイブコーディング」された個人用アプリにはおそらく十分です）。ロギングやその他のオブザーバビリティ、メトリクス、課金などを追加したいかもしれません。 これらすべてを行うために、あなたが本当に望むのは、これらのDurable Objectsへのリクエストが最初にあなたのコードに送られ、そこで全ての「物流管理」を行った後、リクエストをエージェントのコードに転送することです。すべてのDurable Objectの一部として実行されるスーパーバイザーを書きたいのです。 **解決策: Durable Object Facets** 本日、この問題を解決する機能をオープンベータとしてリリースします。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/mUUk7svflWvIp5Ff3npbG/cd2ec9a7111681657c37e3560fd9af58/BLOG-3211_2.png) **Durable Object Facets**を使用すると、Durable Objectクラスを動的にロードしてインスタンス化し、ストレージとして使用するSQLiteデータベースを提供できます。Facetsでは： 1. まず、あなたが記述したクラスを指す通常のDurable Objectネームスペースを作成します。 2. そのクラス内で、エージェントのコードをDynamic Workerとしてロードし、それを呼び出します。 3. Dynamic Workerのコードは、直接Durable Objectクラスを実装できます。つまり、文字通り`extends DurableObject`と宣言されたクラスをエクスポートします。 4. あなたはそのクラスを、自身のDurable Objectの「ファセット」としてインスタンス化します。 ファセットは独自のSQLiteデータベースを取得し、通常のDurable ObjectストレージAPIを使用してそれを利用できます。このデータベースはスーパーバイザーのデータベースとは別ですが、両者は同じDurable Object全体の一部として一緒に保存されます。 **仕組み** 以下は、Durable Objectクラスを動的にロードして実行するアプリケーションプラットフォームの、シンプルで完全な実装例です。 ```javascript import { DurableObject } from "cloudflare:workers"; // この例では、静的なアプリケーションコードを使用しますが、 // 実際にはこれはAI（あるいは人間のユーザーさえも）によって // 生成される可能性があります。 const AGENT_CODE = ` import { DurableObject } from "cloudflare:workers"; // 呼び出された回数を記憶して返すシンプルなアプリ export class App extends DurableObject { fetch(request) { // ここでは簡略化のためstorage.kvを使用していますが、 // storage.sqlも利用可能です。どちらもSQLiteでバックアップされています。 let counter = this.ctx.storage.kv.get("counter") || 0; ++counter; this.ctx.storage.kv.put("counter", counter); return new Response("You've made " + counter + " requests.\\n"); } } `; // Ap ``` **Facets**はDynamic Workersの機能であり、**Workers Paidプラン**のユーザーはベータ版をすぐに利用できます。 Dynamic WorkersとFacetsについて詳しくは、ドキュメントをご覧ください。

Dynamic WorkersにおけるDurable Objects：各AI生成アプリに独自のデータベースを提供

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト