Node.jsとDenoを生んだRyan Dahl率いるDeno Landが、Cloudflare WorkersとDurable Objectsのコードを自前のサーバー群で動かすオープンソース基盤「celld」を公開した。2026年8月5日付のv0.1.0は、各オブジェクトにV8の実行環境とSQLiteを与え、複数ノード間の所有権移動まで扱う。これまでCloudflareのマネージド基盤と一体だった状態付き計算モデルが、Apache-2.0の実装として外へ出たことになる。ただし、celldが分散システムの難しさを消したわけではない。配置と耐久性を決める権限を、Cloudflareの内部基盤から利用者のオブジェクトストレージと運用体制へ移したのである。
workerdで残った穴を埋める
CloudflareはWorkersの実行系「workerd」をすでにオープンソース化している。workerdを使えば、Workers向けJavaScriptやWebAssemblyを自分のマシンで動かし、Durable Objectsもローカルディスク上で試せる。ところが公式READMEは、Durable Objectsが要求元と同じマシンで動く単一ノード実装にとどまり、同じ名前のオブジェクトを複数マシンのどこへ置くかという分散配置は未実装だと説明している。
celldが埋めるのは、この運用層である。アプリケーションはユーザーや文書、チャットルームとAIエージェントなどを「cell」という名前付き単位へ分ける。各cellは単一スレッドのV8 isolate（分離実行環境）でコードを実行し、専用のSQLiteデータベースを持つ。同じcellへの処理は一度に一つの所有ノードへ集まるため、アプリ側がロックや共有データベース上の競合を毎回組み立てる必要がない。
読み書きの速さと分散時の扱いやすさを、cellの境界で両立させる発想だ。稼働中のcellはSQLiteをローカルライブラリとして同期的に読み、休止中はメモリから外れる。公式の固定ホスト測定では、稼働中のcellへの要求は中央値約1.1ミリ秒、99パーセンタイル約7ミリ秒だった。一方、永続化した状態はLTX（Lite Transaction File）形式で共有バケットへ複製される。ノードを失っても、別のノードが同じcellを復元できる。
S3が所有権を決める
celldの設計で最も識別力が高いのは、専用の合意サービスや固定メンバー表を置かず、Amazon S3（Simple Storage Service）互換またはGoogle Cloud Storageのバケットを調整役にした点だ。cellごとに一つの所有権レコードを置き、レコードがなければ条件付き作成、存在すれば直前の値に対するCAS（compare-and-swap、比較交換）で取得する。条件を満たす書き込みは一つしか成功しないため、同じcellを二つのノードが同時に取得する事態を防ぐ。S3-compatibleという看板だけでは足りない。celldは条件付き作成と条件付き上書きに加え、書き込み直後の読み取りで同じ値を返す整合性をバケットへ要求する。公式文書が適格とするのはAmazon S3、Cloudflare R2、Google Cloud Storage、Azure Blob Storage、Tigrisである。MinIO CommunityとBackblaze B2、Hetzner Object Storage、DigitalOcean Spacesは条件付き書き込みを満たさず、分散構成には使えない。
所有権にはepoch（世代番号）が付く。cellが別ノードへ移るとepochが進み、新しい所有者は新しい接頭辞の下へLTXセグメントを書き込む。ネットワーク分断で古いノードが動き続けても、その書き込みは古いepochに残り、新しい系統を壊さない。さらに復元時にはepoch sealと呼ぶ印が、読み取り可能な最終トランザクションを固定し、所有権を失ったノードが後から追加した未承認データを復活させない。
クライアントへの応答にも柵がある。celldはSQLiteへの更新を共有バケットへ複製し、所有権レコードが同じノードとepochを指していると再確認してから成功応答を返す。この「output gate（出力ゲート）」が有効な既定設定で、前述の条件を満たすバケットを使う場合に、承認済み書き込みをノード障害で失わないRPO（Recovery Point Objective）=0を狙える。反面、永続書き込みの最低遅延はバケット一往復分になる。公式トップページが掲げるリージョン内の約90ミリ秒は、ローカルSQLiteの読み取りとは桁が違う。
Cloudflare本家も、SQLiteをローカルに置き、変更ログを遠隔へ逃がす。ただし耐久化の経路が異なる。CloudflareのStorage Relay Serviceは各トランザクションを5台の追随ノードへ送り、3台の受領後に応答を解放する。オブジェクトストレージへの転送は最大10秒または16MBでまとめる。celldはCloudflare規模の追随ノード網を使わず、利用者が選んだバケットへの到達を応答条件にする。運用を単純化した代価が、書き込み遅延とバケット品質への依存として現れる。
415ドル対48ドルの前提
celldは「規模が大きければ桁違いに安い」と訴える。比較の起点は、Cloudflareで100個のDurable Objectsを1カ月間ずっと稼働させる公式料金例だ。毎秒1件のWebSocketメッセージを受ける条件では月416.51ドルになる。celld側は月48ドルの8GB DigitalOceanノードに、軽量なcellを最大2,500個置けるという自社測定を使う。満杯なら1 cell当たり月約0.0192ドル、表示上は約0.02ドルだ。ただし公式トップページが2,500個とする一方、総合ドキュメントは同じ8GBノードについて1,000個、1 cell当たり月約0.05ドルと記す。プロジェクト自身の文書でも収容密度は一致していない。
| 条件 | Cloudflare Durable Objects | celld |
|---|---|---|
| 100個が月中ずっと稼働 | 月416.51ドル | 月48ドルのノードが基礎費 |
| 100個だけを8GBノードに常駐 | 該当例なし | 1 cell当たり月0.48ドル相当 |
| 2,500個で8GBノードを満杯にする | 実行時間に応じて課金 | 1 cell当たり月約0.0192ドル |
| 休止時にWebSocket Hibernationを使う公式例 | 100個、各100接続で月10.00ドル | 非稼働cellのバケット操作はほぼゼロと主張 |
この表から分かるのは、価格差が常駐率と利用密度で反転することだ。celldの月48ドルは100個でも2,500個でも先に発生し、通信、書き込み、バケット料金は別に加わる。CloudflareはThe Registerへの回答で、415ドルは全オブジェクトが常時稼働する場合に限り、休止させれば20.65ドルとの試算も示した。Cloudflareの公開料金表には、100個のオブジェクトが各100本の休止可能なWebSocketを持ち、各クライアントが毎分1回送信する別条件で月10.00ドルになる例もある。
したがって、celldが強いのは多数のcellを継続的にメモリへ置き、ノード容量を高い割合で使い切れる環境だ。アクセスが疎で休止時間が長いサービスでは、Cloudflareの従量課金とWebSocket hibernationが基礎サーバー費を下回り得る。さらにcelldの2,500 cellという密度は、Apple Mシリーズの端末上で軽量なcellを使った測定であり、アプリのメモリ使用量が増えれば収容数は下がる。公式文書内の1,000対2,500という差を見ても、収容数は保証値として扱えない。価格表より先に、実際の常駐率とcell当たりメモリを測る必要がある。
互換性より先に見る運用境界
celldはCloudflareプラットフォーム全体を複製する製品ではない。現時点ではModule Workersとfetchに加え、JavaScript RPCとservice bindingsが動く。Durable Object側は静的アセットやSQLite、alarm APIと休止可能な受信WebSocketに対応する。D1、Workflows、Queuesは計画段階だ。KVとR2 binding、Cache APIは対象外で、Workers AIやVectorize、Hyperdriveも含まれない。cronや独自ドメイン、TLS終端も自前で用意する。
API互換にも継ぎ目が残る。Response.redirect()やReadableStream.from()、setInterval、HTMLRewriterは未実装で、一部のNode.jsモジュールやTCP socketは読み込めても実処理をしないstub（代替実装）になる。Wrangler設定はJSONまたはJSONCに限られ、TOMLは受け付けない。公式文書は、未対応設定を原則として明示的なエラーで止める方針を掲げる一方、沈黙したまま動かない既知箇所も列挙している。既存コードを「そのまま」移せる範囲は、使用中のbindingと実行APIを照合して初めて確定する。
セキュリティ面で運用者が担う範囲も広い。celldはアルファ版で、敵対的なコードを同居させるマルチテナント用途には安全でない。ノード間通信はHMACと本文署名に加え、時刻制限と再送防止を備えるが、TLSを終端しない。内部リスナーには認証のない運用APIもあるため、閉域ネットワークかWireGuard、Tailscaleのような暗号化オーバーレイが前提になる。外部利用者の認証と公開TLS、入口となるプロキシも運用者が用意する。
共有バケットの認証情報は、バックアップ用の鍵より強い。そこにはデプロイ物とSQLite複製が置かれ、所有権やノードのリース、ピア認証の秘密鍵も集まる。認証情報を得た主体はクラスタ全体を制御できるため、celldは一つのクラスタに限った権限へ絞るよう求めている。また、一つのクラスタが動かすのは一つのアプリケーションであり、中央配置コントローラーも自動再配置もない。自前運用で得る主権は、そのまま容量設計と監視、鍵更新と復旧訓練の責任になる。
誰がcelldを選ぶのか
耐障害性について、celldは三段構えの試験を公開している。workerdとの同一入力・同一出力比較、時計ずれや競合を注入する決定論的シミュレーション、実機クラスタへの障害注入だ。公式試験では、4 vCPU・8GBのノード10台に10,000 cellと20,000 WebSocket接続を置き、2台を停止した後、予備容量がある条件で、最も遅いcellも約11秒後には別ノードから利用できたとしている。これは設計の筋を支える材料になるが、第三者が本番負荷で再現した保証値ではない。
celldがまず適するのは、データの所在と障害領域を自分で選び、SQLiteや所有権レコードまで直接調査したいチームだろう。すでに仮想マシンとオブジェクトストレージ、閉域ネットワークを運用し、多数の常駐AIエージェントやチャットルームを高密度に抱えるなら、Cloudflare互換コードを保ちながら費用と配置を制御できる。一方、アクセスが疎なサービスや、世界規模の入口とTLS、マルチテナント分離や監視を少人数で任せたい組織には、Cloudflareの管理されたDurable Objectsが依然として合理的である。
