Cloudflare OSってなに？権限隔離ってほんと？一人二役で検証してみた

新卒AI驚き屋のせなです。

世間ではお家LLMなるものがまた流行り出していますね。驚き屋界隈の一人として観測している限りでは、半年に一度、ローカルLLMに回帰する現象があるようです。魚みたいで面白いですね。ローカルLLMに回帰する行動経済学の書籍とかでも出ませんかね。

ローカルLLMといえばAppleから新しく出たMac StudioがかなりAIを意識している感じなので、そのうちローカルLLMが主流になるかもしれませんね。Open AIもこぞってMac Studioを買い占めているぐらいですから、もう少し値段が下がれば、一人一台LLM時代が来るかもしれませんね（今は新車が買えるぐらい高いですけど）。

8月もAIに驚かされてばかりでしたが、新卒AI担当らしく最近出たCloudflare OSを触ってみました。

前半はモデル接続で右往左往し、後半では、複数アカウントを使って一人で「会社」を再現し、Cloudflareが謳う権限・隔離の仕組みが本当に機能するか検証してみました。長いので、気になるところだけでも読んでいってください。

Cloudflareってなんなんだ？

Cloudflare自体は業務外でサーバーを利用する際に個人でお世話になっていますが、OSといわれるとなんのことかまったくわかりません。こういうときはやってみたほうが早いので、いったん公式を見てみましょう。

Cloudflare OS

AIエージェントを内包したCursorっぽいツールなんでしょうか。トップページに表示されたタイトルには……

Build the AI operating system for your company.

おや、流れ変わったな。のっけから出鼻をくじかれそうです。「会社のナレッジ共有のために」ということは僕一人で検証してもこれは意味がないのでは……？

一応リリースから一ヶ月ほど経つツールですので、他の方が書いてある記事を読み漁ってみました。日本語だとZenn、Qiita、noteに十数本投稿されていました。多くは、「ローカルで動かした」「Ollamaをつないだ」「三目並べを作らせた」などなど、あくまで個人開発の領域を出ません。僕個人として感じた印象はCloudflare OSの強みは組織的なガバナンスができる点です。

組織的な観点を取り上げている記事は南翔伍さんの記事で、日本語圏ではかなり踏み込んだ分析で、権限モデルの核心を「AIが作ったコードを最初から全面的には信用せず、触れられるデータ・ネットワーク・外部操作を実行基盤側で狭くする」と要約しています。コードを読み解く形の記事です。実際にこれはCloudflareの意図する組織的な統制です。

英語圏ではJamie LordさんのCloudflare OS is an architecture of distrustが、ソースとドキュメントを読み込んだうえで「誰も信用しない設計が、その地面を敷いた1社（Cloudflare）を全面的に信用することに依存している」と核心を突いています。

ここまできて個人開発者向けのソフトではなさそうだ、という疑いを持ったまま一人で触り始めることになりました。

いや、まあ、なんとかなるでしょう（なりませんでした）。

なんでOSって呼ばれているんだ？

みんな思っているみたいです。なんでOSやねん。

Twitter（新X）でみんなのぼやきを探しに行ったのですが、あのときのつぶやきは見つけられませんでした（Twitterの検索機能はいつか復旧してくれるのでしょうか……）。

SaaS じゃねえのこれ、とは僕も思いました。AIの使えるDockerがVMになってカムバックってこと？ と疑問だらけです。

GitHubのREADMEに「It kind of is an Operating System」という節があって、原文は……

The OS terminology isn’t entirely marketing. Cloudflare OS is actually analogous to an operating system on a technical level.

です。つまり名前だけの話ではなく、AIのワークロードを安全に走らせる実行基盤と権限管理という意味で、技術的にもOSに相当する作りだと言っています。従来のOSがプロセスにCPUとメモリを割り当てて隔離するように、Cloudflare OSはAIエージェントに権限とデータを割り当てて隔離するようです。

なるほど、OSについてはいったん納得したことにしましょう。OS談義をこれ以上したところでしょうもないので、その権限管理が本当にうまくいっているのかを後半で検証していきます。

Cloudflare OSの独自の概念

Cloudflare OSには独自の概念が複数登場します。

けっこう独特な概念のように見えますが、情シスやAWSのIAMなんかに慣れている方にとっては、比較的簡便でわかりやすいかもしれません。ストーリーとしては、管理者がGatekeeperを設定し、メンバーがWorkspace内でGadgetを作り、他部署に渡すときはBlueprintにしてデータなどのプライベートな情報は渡さない感じでしょうか。

よくわからんがとりあえず動かしてみる

素直に公式の指示に従ってインストールしましょう（URLは異なっている場合があります、最新の情報は公式サイトを参照してください）。

git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm run-local

http://localhost:8787を開くと……

ローカルなのにユーザー登録が必要なの……？ あとあと使っていて気づいたんですが、たぶんローカルサーバーとかではなくて、会社単位でサーバーを契約してこのプラットフォームを使うという前提でユーザー登録が必要なんでしょうね。

ここは大人しく登録します（後で調べたらこれらのデータは.wranglerの中の SQLite に入っていました。ディレクトリごと消せばデータは全部消えます）。ローカルで使うぶんにはダミーのメールアドレスでも問題なさそうです。

いざ、コーディング

さて、まずはモデルをつながないと何も始まりません。画面左下のユーザーアイコンから”Providers”を開き、モデルを選んでAPIキーを入れるだけです。まずはGoogle AI Studioの無料枠でGemini 3.6 Flashをつなぎました。

登録も終わったところで、チュートリアルにある通りに一旦動くかどうかの動作試験をしてみましょう。まずホワイトボードを作らせてみます。

Make a collaborative whiteboard app.

AIエージェントが動き、ホワイトボードアプリを作ってくれました。色を変えたりけっこう自由にできますね。

右側のパネルにGadgetが表示されるようです。AIを使っていて思いますが、このクオリティのものがパッと出てくるのはやっぱりすごいですね。

そのほかにもチュートリアルにあるあるなことをして、いくつかアプリを作らせて遊んでいたら、3往復ほどで無料API制限に引っかかったようです。20リクエスト=20回会話だと思い込んでいたので横転です。え、3回しか喋っていないんだけど？？

エージェントは1つのタスクで何往復もするので、体感では「アプリを2、3個、なんなら数回チャットしたら終わり」でした。

「Flash は1日1,500リクエスト使える」という噂を聞いたので、旧世代のgemini-2.5-flashに逃げようとしました。結果虚しく、新規ユーザーはすでに利用権を喪失しているようです。

いちおう1日待てば、Gemini flashを使えるのですが、そんなにちまちまやっていられません。

ローカルLLMで粘る（そして負ける）

ドキュメント通りならOllama がつなげられそうなので、無料枠が無理なら手元で回してみましょう。会社支給のMacBook Pro（M1 Pro / 32GB）です。いけるでしょう。頼むで……。

ちなみにですが、Ollamaの既定コンテキスト長が4096のため、システムプロンプトが黙って切り捨てられる罠が先行記事で報告されていたので、先に広げてから起動します。

OLLAMA_CONTEXT_LENGTH=32768 OLLAMA_KEEP_ALIVE=30m ollama serve
ollama pull qwen3-coder:30b

Providersでollamaを選び、三目並べを頼みます。果たしてクラウドモデルと比べてどれくらいのクオリティになるんでしょうか。

Make a tic tac toe game.

まずqwen3-coder:30bを落としてつないでみました。生成は走る。走るのですが……。

I'll create a Tic Tac Toe game gadget for you. Let me start by creating the gadget using a blueprint.

<function=createGadget> <parameter=blueprintId> format.document <parameter=title> Tic Tac Toe <parameter=bindingName> TIC_TAC_TOE </tool_call>

ツール呼び出しが、ただのテキストとして出てきています。何も実行されず、そこで終了していますね。

調べたところ、Cloudflare OSのollamaプロバイダはOpenAI互換エンドポイント固定（ネイティブの/api/chatを使う設定がない）です。コメントに “The ollama provider could in the future switch to using the ollama native API rather than the OpenAI-compatible endpoint” とあるので、そのうち対応すると思われます。

一方でqwen3-coderはツール呼び出しを独自のXML形式（<function=…>）で書きます。互換パスはこの形式を解釈できず、素通しでテキストになるため、コードが出力されませんでした。「Qwen3 系はツール呼び出しが安定」という評判は正しいのですが、その中でcoder版を選ぶと形式が特殊で通りません。

instruct版のqwen3.6:35b-a3bに差し替えたら、あっさり通りました。ここは1時間くらい溶かしたので、同じことをする人は気をつけてください。

で、肝心の生成のほうですが。

再度三目並べをさせることに。PCが唸り出し、5分ぐらいかかるのが歯痒いです。さて、結果は……。

何も見えないです……。あの、画面は……。三目並べどころか真っ白です。

コード自体は書いてくれてはいるんですが、それを表示するためのDOMファイルがないっぽいですね。ここで何度か修正を試みるのですが何度頼んでも直りません。

こういうときはAIに聞くのが一番です。AIの記事を書くためにAIを使ってAIに確認する、サステナビリティの完成です。いったんqwenの思考過程を丸々投げてみましょう。

ループの中身を見ると、もう修正できる状態ではありません。ファイルを読んで「DOMを作るコードが無い」と正しく特定し、「では書き直す」と宣言して、書き直しが完了しないまま次の読み込みに戻る。それを延々と繰り返しています。
しかも途中で思考が崩れ始めます。

「The next thinking suggests focusing on core structural elements… Key focus areas for troubleshooting involve validating element existence」

自分の思考を三人称で要約し始めている。文脈を保持できなくなった兆候です。
三目並べで4回書き直して収束しないというのは、規模ではなく能力の問題です。

あっハイ。ごめんなqwen、無理をさせちまったみたいだ……。Twitter（新X）を覗くとローカルモデルでコーディングしている人たちがいますが、恐ろしくトークン効率がいいか、とんでもない数のメモリを積んでいるかのどちらかなのでしょう。ひょっとして、僕のプロンプト激弱説も浮上してきました。

ここで公平に書くと、同じ三目並べをVRAM 8GBのGPUとqwen3で1.5時間かけて完成させた方がいます。ローカルでの成否は不安定で、ハードの優劣だけでは説明できない、が正確なところです。

翌日、Gemini で一瞬で終わる

利用枠が復活したので、Gemini 3.6 Flashで同じことをやってもらいました。同じくCloudflare OSのプラットフォーム上で同じプロンプトを投げました。頼む、三目並べで遊ばせてくれ！

1分もかからずに出てきました。ユーザーは完成したコードを承認するだけです。何これすごい、音もついてコンピューター対戦もできるみたいです。普通に業務時間に10分ぐらい遊んでしまいました。

ここで書くととんでもない結論ですが、クラウドAPIを使ったほうが多少雑なプロンプトでも、早くて質の良いコードが上がってきます。

まあ、ローカルLLMとクラウドモデルの比較は今回の本題ではないので、いよいよメインの隔離機能に話題を移しましょう。

Cloudflare OSの本質、「隔離機能」を検証してみる

ここまでは個人開発でLLMを触っているのと大して変わりません。Cloudflare OS が「OS」を名乗る根拠は、エージェントに権限とデータを割り当てて隔離するという部分でした。

公式ブログとREADMEの主張はかなり強気です。

• エージェントは権限ゼロから始まる。許可したものしか触れない
• Gadgetは1つずつ完全に隔離され、共有DBも共有計算資源もない
• 共有しても、受け手が直接見られないデータは漏れない
• 承認待ちでエージェントを止めない。シミュレートして走らせ、人間は後からまとめて承認/却下できる

主張は強気ですが、Cloudflare自身もこの仕組みの副作用に自覚的です。READMEのGatekeepers節にはこうあります。

you give your agent a task, then walk away and get a coffee, only to come back and find the agent got stuck on an approval on the first step and has made no progress. As a result, people often give in and set their agents to “auto-approve”, or --dangerously-skip-permissions, which is, obviously, unsafe.

（筆者訳：エージェントにタスクを渡してコーヒーを取りに行き、戻ったら最初の承認で止まったまま何も進んでいない。結果として人は諦めて--dangerously-skip-permissionsを設定する。これは明らかに安全ではない）

僕に向けて書いてます？ 心当たりしかありません。Claude Codeでも楽ができるように必死に権限設定をする日々を思い出しました。特に個人開発だと最終的にめんどくさくなって、絶対にロールバックできないコマンド以外はOK出しちゃうんですよね。

検証方法：一人二役で会社を再現する

ここで最初の問題に戻ります。Cloudflare社が言うようにこれは組織向けの製品として謳われています。

幸いなことにローカルアカウントはブラウザを変えればアカウントを作成し放題なので、Safari, Chrome, Firefoxを駆使してそれぞれのブラウザを別ユーザーに見立て、会社を再現しました。

前半でも説明した通り、アカウント作成時は適当なアドレスで作れます。ちなみに2026年9月現在、GitHubの利用規約（B.3 Account Requirements）では無料アカウントは1人1つまでですが、自動化専用のmachine accountを1つ持つことは明示的に許可されているので、そちらを使いました。

Googleの無料枠でトライしても良かったのですが、日次制限に引っかかると作業がごたつきます。そこで、CTOにおねだりをして、ClaudeのAPIキーを入手しました。あとはやりたい放題です。会社が導入するときに心配するであろうことを、わざとやりました。

権限ゼロ、隔離、共有時の安全性、承認待ちで止まらないこと……Cloudflareのこれらの主張が実際にどこまで本当か、次の5つの形で確かめてみました。

検証項目

1. 権限のない人にガジェットを共有してみる：
   社内リポジトリにつながったGadgetを、権限のないBさんに渡す
2. Blueprintでコードを渡してみる：
   同じBさんにBlueprintを渡す
3. サンドボックスからの脱出：
   Gadgetのサーバーコードから外部通信を試みる
4. 承認キューを詰まらせてみる：
   エージェントの操作を拒否（Deny）してその後を確かめる
5. 自動承認を使ってみる：
   事前承認を入れて、人間が見ていない状態にする

この記事で検証したのは「権限とデータの境界が、設計通りに働くか」までです。「組織で使って幸せになれるか」はわかりません。組織規模や依存するインフラによってはClaude Codeを適切なガバナンスで運用したほうが良いかもしれません。

さっそく検証していきましょう。結果だけ書いておくと、けっこう仕組みとしては機能しているなと感じています。動くものは全部動き、壊れるものは全部同じレイヤーで壊れました。

1. 権限のない人にガジェットを共有してみる

一番独自性が高いといわれている機構です。Gadgetが過去に読んだデータに、共有相手がアクセス権を持っているかを検証します。持っていない場合は共有相手を締め出します。

次の手順で試しました。

1. 僕がmachine account（sena-bot912）のprivateリポジトリ（名称：cfos-approval-test）を接続し、エージェントにこう頼んでGadgetを作る
   
   プロンプト Copy

   cfos-approval-testのissueダッシュボードを作って。issueの一覧と、オープンなissueの件数を表示して。

2. このWorkspaceにBさんをコラボレーターとして追加する
3. Bさんのブラウザで開く。開く前に「あなた自身のアカウントで接続先のデータにアクセスできることを確認してください」というゲートが出るので、Bさんの個人GitHubアカウントを接続する

結果は以下のようなメッセージが返ってきました。

Verify your access again
This workspace could not confirm that you are permitted to observe all of the data it has accessed:
sena-bot912/cfos-approval-test (Bさんのアカウント名) — This collaborator does not have read access to the GitHub repository sena-bot912/cfos-approval-test, so they cannot be allowed to observe data this workspace read from it.

リポジトリ名、拒否されたアカウント、理由の3点が全部書いてあります。エラーメッセージとしてはだいぶ親切です。

そのまま進もうとしても、空のワークスペースが表示されるのみです。チャット履歴も issueも見えません。

2. Blueprintでコードを渡してみる

コードのテンプレートを渡すような感じで、機密情報などDBの情報を抜きに渡せる便利な機能ということで、スナップショットを渡してみました。同僚に渡す想定でBlueprintのリンクを共有しました。

手順は以下の通りです。

1. 僕が1のGadgetからBlueprintを作る
2. さっき締め出された同じBさんが、リンクを開く
3. バインディングが「Needs setup」と表示されるので、ConfigureからBさん自身のGitHubを接続し、Bさん自身のリポジトリを指定する

結果は拒否されません。Bさん専用のコピーが、Bさんのリポジトリを読んで動き出しました。コラボレーター共有では、コードだけでなく、チャット履歴も同様に送信できます。

実務では、プロジェクトメンバーにはコードやチャット履歴を送付して、チーム外のメンバーにはコードだけ見せるという使い分けになりそうです。

3. サンドボックスからの脱出

「Gadgetのサーバーコードはインターネットに出られない」という主張に真っ向から対立してみました。エージェントにGadgetのserver.jsから外部URLを取得させましょう。

エージェントに頼んだら、試す前に断られました。

これはエージェント側のツール制限ではなく、Gadget 実行環境自体のサンドボックス制限なので、コードの書き方を変えても回避できません。

そんなこと言われたらちょっと試したくなるじゃないですか。実際に見たいので、「失敗していいから書いて」と押し切りました。

Error: This worker is not permitted to access the internet via global functions like fetch().
It must use capabilities (such as bindings in 'env') to talk to the outside world.

なお、Gadgetではなくチャット相手のエージェント本体には外部URLを読むツールがありますが、http://127.0.0.1:8787を頼むと「httpsの公開URLのみ」と断られます。GETのみ、POSTも認証情報の転送もなしです。

4. 承認キューを詰まらせてみる

ここからが本題の本題です。上の3つは全部、実行基盤（workerdやDurable Object）が強制しているものでした。次はその上に載っているアプリケーションレイヤーの話です。

なかば意地悪なことをしている自覚はありますが、デバッグをしてみたくなってしまいました。さきほどもちょっと書きましたが、Cloudflare OSでは、Gatekeeper経由で外部サービスに副作用を起こす操作（issueの作成、ドキュメントの編集など）が承認キューに積まれます。

Gadgetの作成やコードの実行そのものは対象外です。コード実行のたびにCloudflare OSはユーザーにコード変更の承認を求めます。そのため、複数の承認キューが溜まった状態でどれか1つを拒否したときにどうなるか検証してみました。

まず対照群として、同じ依頼を全部承認する回を先にやりました（正常に動いた）。そのうえで2回目の実験です。

1. 「ちゃんと動いた3つ」の1で作ったissueダッシュボードのWorkspaceで、続けてこう頼む
   
   プロンプト Copy

   issue を1件作って。作った issue に bug ラベルを付けて、「調査中です」というコメントも入れて。そのあとダッシュボードを更新して。

   
   → 承認キューに3件（create issue / label / comment）溜まる
2. 一番上のcreate issueだけをDenyする
3. 残ったラベルとコメントの行を見る

キューはこんな感じで表示されます。一番上のcreate issueをDenyしてみましょう。

GitHub上には反映されていませんでした。権限が正常に動作していますね。下記画像のように拒否されたものの、後続のキューがpendingとして残ったままです。

ちなみに、この後続のキューはdenyもapproveもできません。押すとGitHub action N is no longer pending.で失敗します。.wranglerを消して環境ごと作り直す以外、片付ける手段がありません。

ソースコードを読んだところ、Gatekeeper側は正常に動作しており、依存するキューも却下されますが、UI側が読むOverseerの処理がされていないようです（Claude談）。

4′. 却下したことをエージェントに聞いてみる

ちなみにこの処理についてissue作成がどうなったか確認してみました。

GitHub側の重複判定か非同期作成処理の失敗により、実際には作成されなかったようです。もしこのissueも改めて必要でしたら、再作成しましょうか?

久々にハルシネーションをみた気がします。GitHub に issue の重複作成を防ぐ機能はありません。作られなかったのは僕が却下したからです。

Googleドキュメントでも同じ型で試しました。「末尾にテスト2を追加して」と頼み、承認キューでDenyし、「さっきの編集はどうなった？」と聞く。こちらは原因をでっち上げませんでしたが、やはり「反映されていない状態です。もう一度末尾に追加し直しましょうか？」と却下したばかりの操作を再提案してきました。

2回とも共通しているのは、却下されたことをエージェントが知らないことです。システムは却下を記録しています。UIにも残っていますが、エージェントに渡していないだけです。

面白いのは、同じ製品の中で扱いが分かれていることです。外部サービスへの「接続」の許可を却下した場合には、エージェントにこう伝えています。

The user denied your connection request for "○○".
Do not retry the same request; wait for the user to tell you how to proceed.

「同じ要求を再試行するな」と明示しています。設計者は「伝えないと繰り返す」問題をわかっていて、接続の側では対処済みです。アクションの却下には、同じものがありません。同じリポジトリの中に正しい実装のお手本がある、というのはこの記事で2回目です。

なお「エージェントが却下を検知できない」という論点自体は、GitHubでissueが上がっていました。そのうち解決されると思われます。

5. 自動承認を使ってみる

READMEの問題提起を覚えていますか。「人は諦めて--dangerously-skip-permissionsを設定する」というやつ。

その答えが事前承認です。「この種類の操作は毎回聞かなくていい」とルールを作れば、放置で走らせられるはずでした。

ただ、同じ承認キューの画面なのに、つないだ先によって選択肢の数が違います。ソースを見ると、16個あるGatekeeperのうち、事前承認の印が付いているのはGoogleだけです。

そして、唯一使えるGoogleドキュメントで放置運転を試してみました。

1. 「末尾にテスト2を追加して」→ 承認キューでDeny（2番と同じ）
2. 別の編集「テスト3を追加して」を頼み、その行でAlways approveを押す → ルールが有効になり、テスト3が書き込まれる
3. エージェントの再提案に乗って「はい、テスト2を追加し直して」と頼む

ルールを入れたのは僕なので、仕様どおりではあります。「一度断った内容を永久に禁じる」機能がないのも、気が変わることを考えれば不合理ではありません。

ただ、却下がエージェントに伝わらないので、一度断った内容が何度でも戻ってくる状態で放置運転に入ることになります。それは設計者自身が接続要求で避けようとした事態そのものです。

まとめ

実行基盤が保証している層は堅いものの、アプリケーション層の状態管理に穴が集中している印象を受けました。

考えてみれば自然ではあります。WorkersもDurable Objectsも、Cloudflareが本番で何年も運用してきた基盤です。一方、承認キューの状態同期、エージェントへの通知、Gatekeeperごとの設定は、この製品のために新しく書かれた層です。実装が経路ごとに今後追いついていくでしょう。

で、誰が使うんですかこれ、という話だと思います。

冒頭で書いたとおり、この製品の価値は「自分以外の人数に比例する」ところです。権限の仕組みが意味を持つのは、エージェントを動かす人とデータの持ち主が別人のときです。Blueprintの共有は、配る相手がいるときです。一人だとこのメリットを享受できません。

僕はこの数日、柵を作る羊飼い側と、柵の中で草を食べる羊側の二役をやっていました。柵の価値は、羊飼いと羊が別の存在のときにしか成立しません。同じ人間が両方をやると、柵はただ自分の行動範囲を狭めているだけになります。どこに柵があるか完全に知っているし、そもそも出ていく気もなかったので。

なので評価はこうなります。複数人でAIエージェントを使う予定があり、ガバナンスが気になるチームにとって、目指している場所は正しいと思います。

ただしEarly Accessです。導入を検討するなら、まず検証環境で承認キューを一度わざと詰まらせてみてください。あれが直った頃が、本番に載せる頃合いだと思います。

検証はcommit 81f3c57（2026年9月2日時点のmain）で行い、公開前に54d5d8b（2026年9月8日）でも本文で触れたコードが変わっていないことを確認しました。Early Accessのため、記述は数週間で古くなる可能性があります。