Cloudflare OSとは何か — AIに鍵を渡さない「門番」アーキテクチャを図解で理解する
この記事でわかること
- Cloudflare OS が OS ではなく、ブラウザで開く Web アプリだということ
- 目玉は機能ではなく安全装置だという話（AI に鍵を渡さず、門番が代わりに叩く）
- Gadget / Gatekeeper / Skills / Blueprint の 4 つの登場人物
- エージェントが見たものを記録して成果物に付けることで、権限のすり抜けを防ぐ仕組み
- 個人で試すときの手順と、実質の入場料
特にありません。AI エージェントに仕事を任せるときの安全性に関心があれば読めます。手元で試す場合は Cloudflare アカウントが必要です。
2026年8月、Cloudflareが社内で使っていたAIツールをまるごとオープンソースで公開しました。名前は「Cloudflare OS」。中身はLinuxでもWindowsでもありません。
調べてみると、本当に新しいのは機能ではなく、AIを信用しないという前提で組まれた設計のほうでした。
この記事の要点
- 社内の全員がブラウザでAIに仕事を頼み、資料も小さな業務アプリもその場で作れる職場環境。Cloudflareが自社で3か月使い込んでから公開した
- 目玉は機能ではなく安全装置。AIには鍵を一切渡さず、「門番」役が代わりに外部サービスを叩く
- OSと名乗ってはいるが起動するOSではない。AIエージェントを「ユーザー」ではなく、権限を絞った新しい実行主体として扱うという主張の名前
まず、これはOSではない
発表直後のインターネットで最初に起きたのは「Linuxディストリビューションが出たのか？」という誤解と、それに対するツッコミでした。Hacker Newsのスレッドは数百コメントに膨れ上がり、その大半が「OSと呼んでいいのか」という言葉の議論に費やされています。
結論から言えば、これはブートしません。パソコンに入れるものではなく、ブラウザで開くWebアプリケーションです。Cloudflareのクラウド（Workers）の上で動きます。既存のOSを置き換えるものは何ひとつありません。
ただ、名前が悪いからといって中身まで凡庸だと決めつけると、いちばん面白いところを見逃します。Cloudflareが「OS」という言葉を選んだ理由は、後半で見るとおり案外筋が通っています。
何ができるのか
使い始めの体験は、ChatGPTのような対話画面に近いものです。違うのは、その画面が会社の事情をあらかじめ知っていて、会社のシステムに手を伸ばせること。公式リポジトリが「まず試してみて」と挙げている例がわかりやすいです。
- 「来週の顧客との打ち合わせ用にスライドを作って」
- 「みんなで書き込める共同ホワイトボードのアプリを作って」
- 「このGitHubリポジトリのイシュー一覧ダッシュボードを作って」
- 「このGoogleドキュメントの誤字を直しておいて」
3つ目と4つ目が肝心です。作った小さなアプリがそのまま動き続け、他人と共有でき、実データにつながる。スプレッドシートも、定期実行のワークフローも、同じ画面から生まれます。
Cloudflareは2026年5月に社内へ配り、8月の公開時点で「数千人の従業員が、エンジニアに限らず日常的に使っている」と説明しています。つまり売り文句は「AIで文章が書ける」ではなく、ひとりひとりが自分専用の業務ツールを口頭で作れる職場、ということです。
4つの登場人物
ドキュメントには耳慣れない造語が並びます。ここだけ押さえれば全体像がつかめます。
Gadget（ガジェット）
AIが作った小さなアプリの実体。ひとつひとつが隔離された箱の中で動き、専用のデータベースを持ちます。たとえるなら「書類ごとに用意された、鍵付きの作業部屋」。隣の部屋の中身は見えません。
Gatekeeper（ゲートキーパー）
GitHubやGoogle、Slackなど外部サービスごとに置かれる仲介役。認証情報を自分だけが持ち、AIの要求を検査して通したり止めたりします。たとえるなら「鍵束を持った門番」。AIは鍵を受け取れず、門番に頼むことしかできません。
Skills / Context（スキル・コンテキスト）
「うちの会社ではこの作業はこうやる」という手順書と、社内用語・規程・システムの知識。会話のたびに説明しなくて済むよう、あらかじめ読み込まれます。誰かが見つけた良いやり方が、そのまま全員の資産になります。
Blueprint（ブループリント）
作ったアプリを他人に配る形式。コードは複製されますが、中のデータ・会話履歴・認証情報・接続先はコピーされません。たとえるなら「レシピだけ渡して、冷蔵庫の中身は渡さない」。
核心は「AIに鍵を渡さない」
いまAIエージェントに社内システムを触らせようとすると、たいていはAPIキーやアクセストークンをエージェントに持たせることになります。これは家の鍵束をまるごと預けるのに等しい行為です。エージェントが勘違いしても、悪意ある文章を読み込まされて操られても（プロンプトインジェクション）、鍵は鍵として機能してしまいます。
Cloudflare OSはこの前提を捨てました。認証情報はGatekeeperの内側に閉じ込められ、エージェントからは触ることも読むこともできません。エージェントに与えられるのは鍵ではなく「この操作だけできる」という細い権限──専門用語でケイパビリティ（能力）です。
さらにGadgetが動く箱そのものにも制限がかかっています。サーバー側のコードはインターネットへの通信が最初から切られた環境で実行され、明示的に渡されたリソースにしか到達できません。ブラウザ側のコードはサンドボックス化されたiframeに閉じ込められます。
ここが効いてくるのは、AIが書いたコードの品質を信用しなくてよくなる点です。従来のセキュリティはアプリのコードが正しいことに依存していました。Cloudflare OSは安全性をプラットフォーム側に移しています。AIがどれだけ雑なコードを書いても、そもそも届かない場所には届きません。
「見たもの」が成果物に付いてくる
もうひとつ、地味だが賢い仕組みがあります。エージェントが読んだリソースをすべて記録し、その記録が成果物に付随するというものです。
これがないとどうなるか。Cloudflareは社内で実際にこの穴を踏んでいます。権限のある人がAIに機密テーブルを読ませてダッシュボードを作り、それを権限のない同僚に共有する──データはロンダリングされ、痕跡も残りません。よくある「権限のすり抜け」です。
ポリシーは読み取りの可否だけでは終わりません。機密データを読んだ後は、外部への書き込み・新しい共同編集者の招待・他のエージェントへの委譲・外向き通信を禁じる、といった設定ができます。利用者がこれを自分で実装する必要はなく、プラットフォームが面倒を見ます。
なぜ「OS」と名乗ったのか
ここまで来ると、命名の意図が見えてきます。リポジトリには対応表がそのまま書かれています。
| 従来のOS | Cloudflare OS | 役割 |
|---|---|---|
| カーネル | workshop-backend | 全体を統括し、資源を割り当てる |
| デバイスドライバ | gatekeeper-* | 外の世界とのやりとりを標準化する |
| シェル | workshop-frontend | 人間が命令を打ち込む場所 |
| プロセス | Gadget | 隔離されて動く実行単位 |
| 実行ファイル | Blueprint | 配布・複製できる形 |
| アクセス制御リスト | 共有パーミッション | 誰が何に触れるか |
そのうえでCloudflareはこう主張します。従来のOSに欠けている機能がひとつある。AIエージェントの管理だと。
言葉としては挑発的で、Hacker Newsが荒れたのも無理はありません。ただ主張の中身は空疎ではなく、「人間」と「プログラム」の二分法では足りない第三の実行主体が現れたという認識は、少なくとも議論に値すると思います。
「不信の建築」という読み方
公開当日、この設計を最もうまく言い当てた評があります。開発者Jamie Lordによる「Cloudflare OS is an architecture of distrust（不信の建築）」です。
彼の指摘はこうです。ほとんどのエージェント基盤は楽観的に作られている。モデルは賢い、指示に従う、そのうち賢くなる──という前提で。そして一か月以内に現実に殴られる。Cloudflare OSは違い、「モデルは自信満々に、定期的に間違える」という観測を設計の出発点に置いている。だから、間違いが現実世界に届かないように建物のほうを組み替えた、と。
書き込み操作がいきなり実行されず「仮の状態」で積まれ、人間の承認で初めて現実になるのも、この思想の一部です。
そして彼は、この設計が抱える根本的なジレンマも隠しません。
避けられないトレードオフ
最大の自律性と最大の封じ込めを、同時に設計することはできない。人間が常にループに入る構造は、エージェントが本来もたらすはずだった自動化の効果を、その分だけ削り取る。
さらに皮肉がひとつ。エージェントは信用されないが、その「信用しない仕組み」自体はCloudflareという単一の事業者に完全に依存しています。誰も信じない建物の、土台だけは一社に預けることになる。
冷静に見た現在地
評価できる点は、設計思想が一貫していることです。認証情報の隔離、通信の遮断、観測ログ、承認ゲート。どれも「AIは間違える」という同じ前提から導かれています。しかも自社で数千人が3か月使ってから公開された、実運用の裏付けがあります。
一方で割り引くべき点もあります。公式に「early access」「rough edgesが多い」と書かれている段階です。Cloudflareダッシュボードからのマネージド提供もSlack連携も未提供で、本気で導入するならパートナー企業の支援が前提になります。外部からのコントリビュートも原則受け付けていません（12行程度以下の軽微な修正のみ例外）。
技術的な土台も、公開のために新しく作られたものが多いです。各Gadgetに専用のSQLiteを与えるDurable Object Facets、AIが書いたコードをその場で読み込んで動かすDynamic Workers、ブラウザとサーバーの間でオブジェクトの能力ごと受け渡すCap'n Web、共同編集のYjs、外部ツール接続のMCP。裏を返せば、これらが揃っているCloudflareの上でしか、いまのところ成立しないということでもあります。
個人でも試せるのか
試せます。企業向けの触れ込みですが、リポジトリはApache 2.0で丸ごと公開されていて、手元で動かすところまでは数コマンドです。
git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm run-local # → http://localhost:8787ただし完全にオフラインでは動きません。AIの推論だけは外に出す必要があり、CloudflareのAI Gateway経由でAnthropic・OpenAI・Googleなどのモデルを指定するか、Workers AIを使います。どちらにせよCloudflareアカウントは要ります。データ自体は手元の .wrangler/ に置かれます。
本番として自分のCloudflareアカウントにデプロイする場合、Gadgetの心臓部であるDurable Object Facetsが有料プラン（Workers Paid・月5ドル）向けの機能である点に注意がいります。個人で常用するなら、この5ドルが実質的な入場料です。
連携先として最初から用意されている門番は、企業向けに限らない顔ぶれです。
| 分類 | 用意されているGatekeeper |
|---|---|
| 仕事系 | GitHub、Slack、Notion、Linear、Confluence、Google、Email |
| データ・基盤 | Supabase、Cloudflare、MCP／MCPポータル |
| 生活系 | Home Assistant（スマートホーム）、Spotify |
| 内部機能 | Context（社内知識）、Scheduler（定期実行） |
Home AssistantとSpotifyが公式リストに並んでいるあたりに、この製品の出自が透けて見えます。社内ツールとして作られたが、個人が家で回しても成立する構成になっています。難所はどちらかというとOAuthのクライアント認証情報の取得で、これは公式ドキュメントも「多くの事業者はこれを意図的に簡単にしていない」とぼやいています。
結局、何が新しかったのか
AIが資料を作る話でも、AIがアプリを書く話でもありません。それはもう珍しくない。
新しいのは、「AIに仕事を任せる」を、AIの賢さに賭けずに成立させようとしたことです。鍵は渡さない。通信は塞ぐ。見たものは記録する。取り返しのつかない操作は人間の承認を挟む。エージェントが優秀である必要はなく、間違えても壊れない場所に置く。
これは技術的な発明というより、態度の表明に近いものです。そしておそらく、企業がAIエージェントを本気で業務に入れるときに、遅かれ早かれ全員が向き合うことになる態度でもあります。名前が「OS」である必然性は最後までよくわかりませんが、中身のほうは真面目に見る価値があります。
参考リンク
更新履歴
- 公開。
