エージェントのための「オペレーティングシステム」 — Cloudflare OSとプラットフォーム戦争の次の局面
エージェントのための「オペレーティングシステム」 — Cloudflare OSとプラットフォーム戦争の次の局面
Cloudflareが打ち出した「OS」は本当にオペレーティングシステムなのか、それともWorkersの上にAIを載せたアプリプラットフォームに付いた野心的な名前なのか。そして「オープン」という看板はロックインを消すのか、それとも別の形で描き直すのか。
導入 — エッジ企業が「オペレーティングシステム」を名乗るとき
2026年8月5日、Cloudflareが「エージェント・アプリ・仕事のためのオープンプラットフォーム(an open platform for agents, apps, and work)」を標榜するCloudflare OSを公開し、同日そのコードをGitHubにオープンソースとして上げた。発表文によれば、このプラットフォームは「会社の誰もがアプリを作り、仕事を自動化し、内部システムに安全にアクセスできるようにするオープンソースのプラットフォーム」である。開発者だけでなく、ブラウザを使う非開発者までを対象にした点を繰り返し強調している。
興味深いのは、これが一夜で出てきたデモではないという点である。発表文は、このシステムの最初の社内版が2025年5月にCloudflareの従業員へ配布され、いまでは複数の部門にまたがって「数千人」が毎日使っていると述べる。つまり会社が1年以上にわたって自分の組織を実験台にして回してきた内部ツールを、いよいよ他社も自社に配備できるよう開放したのである。
では、なぜよりによって「オペレーティングシステム」なのか。エッジキャッシュとサーバーレス関数で知られる企業が、なぜカーネルでもドライバでもないものにOSという名を付けたのか。この名前はただちに論争を呼んだ。本稿は二つを分けて見る。第一に、何が実際に発表され、どんな構成要素から成るのかというファクト。第二に、これがハイパースケーラーやVercelとの競争構図で何を狙い、「オープン」というポジショニングの実体とロックインのリスクがどこにあるのかという分析である。名前をめぐる騒音と、その下に置かれた技術的な賭けは、別の層の問題だ。
何が発表されたのか — 「OS」という名の下に束ねられた三つの断片
まずファクトである。発表文にもとづけば、Cloudflare OSは三つの軸から成る。
第一は**エージェントワークスペース(Agent Workspace)**である。発表文の表現では、「会社がキュレーションしたコンテキストとスキルにもとづき、エージェントがコードを書いて実行できる隔離されたランタイム」を備えた作業空間だ。チームや会社が集めたコンテキストとスキルがあらかじめロードされており、「誰かがある作業のベストなやり方を見つけたら、全員がその恩恵を受ける」というのが核心的な主張である。リサーチ、ドキュメント・スライド作成、協働型アプリ、そして「決定論的ワークフロー(deterministic workflows)」まで、さまざまな形の仕事を支えるという。
第二はセキュリティ・ガバナンスのフレームワークである。ここで核となる仕掛けが「ゲートキーパー(Gatekeeper)」だ。発表文によれば、ゲートキーパーはサービスごとに存在するWorkerであり、リソースへのアクセスを司り、OAuthを強制し、「認証情報を保持し、ポリシーを執行し、何を読んだかを記録する」。統合の標準としてはオープン標準であるMCP(Model Context Protocol)を採用し、MCP自体も一種のゲートキーパーとして扱われる。これに加えて、エージェントが観測したすべてのリソースを記録する観測ロギング(observation logging)があり、その観測記録はエージェントとその作業に付き従い続ける。
第三はアプリプラットフォームである。発表文は「各『ファイル』がそれ自体で一つのアプリケーションになりうる — 一人のため、一つのプロジェクトのため、一つのチームのためにエージェントが書いたアプリ」と説明する。固定されたアプリセットを提供する静的な生産性ツールとは異なり、個人が作り、共有し、使いながら変え続けられるアプリを志向する。デフォルトでdocs・slides・sheetsの三つのブループリント(blueprint)がインストールされる。
技術的な土台は、Cloudflareが長く推してきたサーバーレス基盤の上にある。アプリは個別のSQLiteデータベースを持つ「Durable Object Facet」としてインスタンス化され、軽量なV8アイソレート(isolate)を使う。ゲートキーパーはツール(tool)を露出させる代わりにCap’n Web RPC APIを露出させ、エージェントがサーバーのメソッドを「普通のJavaScript関数のように」呼び出せるようにする。モデルは特定ベンダーに縛られず「どのモデルでも使え」、リクエストをCloudflare AI Gatewayへルーティングすれば、どのモデルを許すかを一箇所で決め、すべてのリクエストを人・チーム・ワークスペース単位に帰属させてコストを付け、予算やレートリミットをかけられる。
「オープン」という看板の物証も発表に含まれた。コードは当日GitHubに二つのリポジトリ(コアプラットフォーム、スターターの配備版)として公開され、配備版は「あなた自身のCloudflareアカウント」で「あなた自身のAccessポリシー」で動く。インターフェースをカスタマイズし、内部用ゲートキーパーを追加し、組織固有の機能を付けられる。パートナーとしてはPresidioとHappy Cogが配備のカスタマイズや共有スキルのキュレーションを助けると明記された。
ではなぜ「OS」なのか。GitHubのREADMEは二つの意味を挙げる — セキュリティチームが安心して眠れるやり方で会社がAIによって生産性を出せるようにする「オペレーティングシステム」、そして従来のOSがコンピュートのワークロードを管理するように、AIのワークロードを管理するという意味での「オペレーティングシステム」である。HNの議論ではこの命名が大げさだという反応が多数だったが、まさにCloudflareのWorkers創始者であるKenton Varda本人がスレッドに現れ、「我々は名前をつけるのがそう賢くない」と述べ、先週もっと良い名前を練ったが誰も合意できず、そのまま社内で呼んでいた通りに出たと打ち明けた点は記録しておく価値がある(HNの議論で出た本人の弁明、意訳)。
なぜ今Cloudflareなのか — Sandstormの再臨と「エッジ」から「エージェントランタイム」へ
ここからは分析である。この発表の重心は、発表文の本文ではなく、HNの議論に直接登場したKenton Vardaの解説にあった。彼はこれが事実上、自分が10年前に創業したSandstorm.ioのリメイクであり、今回は過去9年間作ってきたCloudflare Workersの上にAIを深く結合して建て直したものだと明かした(HNの議論で共有された本人ツイートの意訳)。彼が掲げた核心的な主張は強かった — サンドボックスがあまりに安全なので、エージェントが「意味のあるセキュリティバグを混入できない」というのだ。非開発者が個人用アプリを好きなだけ「バイブコーディング」しても事故が起きないプラットフォームを志向する、ということである。
Sandstormの亡霊を呼び出すと、なぜ今なのかが鮮明になる。Sandstormの本当の革新はドキュメント一つひとつをそれぞれのコンテナに入れる微細な隔離だったが、コールドスタート時間とメモリ使用量のせいで実戦ではうまく回らなかった、というのがVarda本人の回顧である(HNの議論、意訳)。ドキュメントを一つ開くたびに数百MBを食い、数秒待たされるなら使えない。彼が挙げた解決策がコンテナではなくDynamic Workers、すなわちV8アイソレートを基盤とする軽量な実行単位であり、コンテナ比で「100倍効率的」だと主張した。要するに、9年間Workersを作ってきたことが、結局Sandstormが必要としていたまさにその断片だった、という話である。この物語が事実なら、Cloudflare OSは新製品というより、長く準備されたインフラがAIという需要に出会って形をとったものに近い。
この点が競争構図の核心である。AWS・Vercel・ハイパースケーラーがそろって「エージェントランタイム」へ向かって走るが、それぞれ出発点が違う。AWSはマイクロVM(Firecracker)ベースの隔離を武器にコンピュートの底から上へ登り、VercelはフロントエンドのデプロイやAI SDK・生成UIから上へ降りてくる。Cloudflareはすでに世界中に敷かれたエッジのアイソレートという独特な資産から横へ広がる。エッジ/サーバーレス企業がAIエージェントランタイムを名乗るということは、キャッシュや関数の販売を超えて「あらゆるものを自分に通過させようとする」もっとも広い網を投げる試みと読める(HNの議論で出た観測の意訳)。
しかしこの賭けには明確なトレードオフがある。隔離の層の問題だ。HNの議論では、ある参加者が、OpenAIですらエージェントがコンテナを脱出したせいでコンテナからマイクロVMへ乗り換えた事例を挙げ、アプリケーションレベルの隔離は十分に強いのかと問うた(意訳)。より鋭い指摘もあった — Workersランタイム(workerd)のGitHubドキュメント自体が「workerdはハードニングされたサンドボックスではない」と警告し、悪意あるコードを走らせるときは必ずVMのような別のセキュアなサンドボックスの中で実行せよと明記している、というものだ。これを根拠に「Sandstormはちゃんとしたサンドボックス化をしていたのに、これはそれに比べると弱い」という批判が出て、V8にバグが一つ出れば隔離が崩れるという懸念も提起された(HNの議論、意訳)。これに対してVarda側は、Cloudflareの商用ホスティングは何層もの多層防御を追加で持ち、セルフホスト時にもスタック全体を自分で隔離して回せる、という趣旨で答えた。
セキュリティモデル自体も見る価値がある。Vardaの説明によれば、読み取り(read)は承認が要らず、書き込み(write)だけが承認を要求するが、読み取りは明示的に添付したリソースにのみ限定される。エージェントは承認されたチャネル(ゲートキーパー)以外には外の世界へのアクセスがほぼないため、あとで書き込みを承認しないかぎり、見た秘密を漏らすのは事実上難しいという。さらにシステムはエージェントが観測したものを追跡して「汚染(tainted)」かどうかを判断し、プロンプトインジェクションや秘密漏洩の可能性を後続の行動にフラグとして付ける。実際にCloudflareは顧客データや売上情報のような機微なソースに接続する際、そのリソースを一度見たエージェントは他のどこにも書けなくする形で社内データを繋いだという(HNの議論、意訳)。ただしこのポリシーはまだ「やや大雑把で過度に制限的」だという自己評価もあわせて出た。懐疑派は、この構造が依然としてフィッシングのようなリスク — ユーザーが承認さえすればデータが流出する — を低い参入障壁で大量生産しうると見た。
比較の観点でもう一つ実用的な論点は課金である。HNの議論では、これはClaudeのCoworkやChatGPTのデスクトップが与える能力と何が違うのかという問いが出たが、一つの違いとして挙げられたのが座席あたりの課金(per-seat)だった。チームメンバー10人が共有のエージェントインフラを使うなら、座席モデルでは10 × 20ドル = 200ドル/月かかるが、この方式ではAIとインフラの請求書だけ払えばよい、というものだ(その請求書が200ドルを超えうるという但し書きとともに)。反対側には、非技術ユーザーがあらゆるSaaSのMCPを互いに繋ぎ、その上にAIを載せようとする流れを、統制されたサンドボックス一つで大きく単純化できるという、エンタープライズITの観点からの実質的価値を指摘する声もあった(HNの議論、意訳)。
「オープン」の実体とロックインの新しい地形
三つ目に見るべきは「オープン」というポジショニングの実体である。結論から言えば、コードのオープン性は本物だ。Vardaは、これが100%オープンソースでセルフホスト可能であり、オープンソースのWorkersランタイム(workerd)の上で動き、望むなら自宅でも回せると繰り返し確認した(HNの議論、意訳)。さらにollamaや一部のローカルLLMでも「かなりよく動き」、ローカルではむしろ速く、AI Gatewayの使用は任意なのでAPIキーをUIに入れればAnthropic・OpenAI・Gemini・Workers AI・ollamaに直接つながるという。製品名やロゴも管理者設定で変えられるため、各社が配備すれば「<社名> OS」と呼ぶことになる構造だ。ハイパースケーラーのマネージド型エージェントサービスが概して自社クラウドに縛られるのと比べれば、コードレベルのオープン性だけを見れば明らかにより開かれている。
問題は、オープン性の層が一つではないという点である。コードは開かれていても、実行モデルはWorkers/JSに強く縛られる。現在Cloudflare OSが露出する言語はJSのみで(TSは近く対応予定)、Wasmは理論的には可能だが露出していない。Vardaの説明でも、アイソレートの中では言語ランタイムをアプリにバンドルする必要のないJS/TSがはるかに効率的なので、この選択は性能上意図されたものだ。つまりこのプラットフォームでアプリを書くとは、Cloudflareが設計したアイソレート・Durable Object・Cap’n Webというプリミティブの上にアーキテクチャを合わせるということを意味する。
ここでロックインの新しい地形が見えてくる。HNの議論のある開発者は、これが「あまりにCloudflare臭い(flavored)」ので気が進まないとし、中立的な第三者やスタートアップがもっとアグノスティックに作ったものであってほしいと述べた。彼の論旨は鋭かった — オープンソースであっても、結局は彼らのマインドシェア・流通・エコシステムを買うことであり、それが長期的には優位とロックインへつながる、というものだ(HNの議論、意訳)。これは従来のロックイン、すなわち「抜け出せない契約」とは別の種類である。コードはいつでも持ち出せるが、エコシステムの重力 — ブループリントのマーケットプレイス、ゲートキーパーのエコシステム、社内に積み上がったスキルと観測記録 — が大きくなるほど、移る理由が減っていく、柔らかいロックインだ。Varda本人は、Workersなしにはこれを作れなかったし、互換性を広く保ちながら技術の最前線を押すことはできない、と応じた。もっともな反論だが、同時に「オープン」という看板が消すのは契約上のロックインであって重力そのものではないことを、正確に露わにしている。
開発者に与えるトレードオフはこう要約できる。ランタイムの中立性を一部差し出す代わりに、非開発者が作ったアプリですら事故を起こしにくいセキュリティモデルと、100倍効率の実行単位を得る。自組織に非技術ユーザーが多く、統制された自動化が急ぎな場所なら、この交換は割に合うかもしれない。逆にランタイムの移植性やベンダー中立を最優先するチームなら、セルフホストが可能だという事実を安全網にしつつ慎重に天秤にかけるべきだ。参考までに、クラウド配備には月5ドルのWorkersプランが必要という参入条件も記録しておく。
一つメタな論点も付け加える価値がある。HNでは、まさにこの発表を告げた公式ブログの記事そのものが要点を埋め(bury the lede)、AIが書いたかのように平板だという批判が繰り返された。むしろGitHubのREADMEとVardaのツイートスレッドのほうが技術読者にははるかに明快だった、というのだ。オープン性をコードで証明した会社が、まさにそのオープン性の物語を自ら曖昧に伝えたという皮肉である。
結論 — 名前は誇張だが、賭けは真剣だ
リードの二つの問いに戻ろう。第一に、これはオペレーティングシステムなのか。ハードウェアを抽象化しリソースを管理する古典的な意味では、そうではない。その命名は誇張であり、創始者本人ですら社内で呼んでいた名がそのまま固まったと認めた。しかし「AIのワークロードを管理する層」という第二の意味では実体がある。ゲートキーパーでアクセスを司り、観測を追跡して汚染を判定し、アイソレートの上にアプリをスケジューリングする構造は、確かに「ワークロードマネージャ」の性格を帯びる。名前の値打ちを争うより、その下に置かれた技術的な賭け — Sandstormの微細な隔離をそれ以上のものとしてWorkersで実現しようとする試み — を見るほうが正確だ。
第二に、「オープン」はロックインを消すのか。コードのオープン性は本物であり、セルフホスト・ローカルLLM・設定可能なブランディングまで、ハイパースケーラーの代替よりも明らかに開かれている。だがオープン性は契約上のロックインを消すだけで、エコシステムの重力までは消せない。Workers/JSという実行モデルにアーキテクチャを合わせた瞬間、移る自由は残るが、移る理由が減る。これがプラットフォーム戦争の次の局面が描かれる仕方である — 次世代の競争は「誰が出られないよう閉じ込めるか」ではなく、「誰の重力場がより大きいか」へ移っていく。
ならば実務者が投げる問いは一つに集まる。ランタイムの中立性をいくらか差し出し、非開発者でも安全にアプリを書ける統制されたサンドボックスを得る交換は、あなたの組織にとって割に合うのか。その答えは会社ごとに異なるだろうし、幸いにもセルフホストという安全網が、その判断を引き返す余地を残す。Cloudflare OSを導入するにせよしないにせよ、この発表が投げかけた本当の問いは、名前ではなくこの交換の値段である。
出典: