Cloudflare OSとは｜承認待ちで止まらないAIエージェント基盤の仕組みをソースで解説

Cloudflare OS（cloudflare/cloudflare-os・Apache-2.0・3,618★）は、AIエージェントに仕事を任せるときいちばん体験を壊す「承認待ちで止まること」を、設計そのもので外そうとしているOSSだ。作業を頼んで席を立ち、コーヒーを持って戻ってきたら、最初の1手の承認ダイアログでエージェントが固まったまま何も進んでいない——この体験を何度か味わうと、人はたいてい自動承認へ倒れる。Cloudflare社内で実際に日常業務に使われているAI業務環境を公開したこのリポジトリは、「止まる/雑に全許可する」の二択を捨てる方向に賭けている。この記事ではREADMEの主張をなぞるのではなく、simulation.ts と auto-approval.ts のソースを読み、手元でテストを走らせて、その仕組みがどこまで本当なのかを確かめる。

AIエージェントの枠組み全体の中でCloudflare OSがどの位置にあるかは、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証と併せて読むと掴みやすい。

Cloudflare OSとは——社内で使われているAI業務環境のOSS版

Cloudflare OSは、READMEの表現を借りれば「AI生産性のためのオペレーティングシステム」で、もともとCloudflare社内で開発され、エンジニアリングから営業まで幅広い職種の従業員が日々の業務に使っているとされる。この「社内で広く使われている」という部分はベンダーの自己申告であり、外部から検証できる数字ではない点は先に断っておく。

名前に反して、これは従来型のコンピュータOSではない。READMEはOSという語を2つの意味で使うと明示している。ひとつは「会社がAIで生産的に働くための、セキュリティチームが夜眠れる程度に安全な土台」としてのOS。もうひとつは「AIワークロードを管理する層」としてのOSだ。提供するものは3つに整理されている。会社の業務知識を前提に読み込んだエージェントのチャットUI、サンドボックス化されたアプリ開発環境、そしてエージェントとアプリの双方にガードレールを掛ける Gatekeepers と呼ばれるセキュリティ枠組みである。

リポジトリの基本情報を実測すると、公開は2026年4月15日、コミット626件、コントリビューター11人、TypeScriptとTSXで412,130行、ライセンスはApache-2.0だった。コミット数の内訳は偏っていて、上位は kentonv が377件、次いで jonesphillip 85件、bjesus 62件と続く。READMEは「Workers自体を作った当人たちが作っている」と書いており、Dynamic Workers や Facets といったランタイム機能はCloudflare OSを支えるために追加されたと説明している。

注意すべき点として、READMEは自ら現状を「early access」と宣言している。このリポジトリはv1の学びを新しい土台に載せ替えた完全な書き直しであるv2で、2026年8月のリリース時点で「非常に高機能だが荒削りな部分が多く残る」と明記されている。v1がどうだったかはこのリポジトリからは検証できないため、本記事はv2の実装だけを対象にする。

Gadget：ユーザーごとに実体が分かれる「自分専用のアプリ」

Cloudflare OSの中心にあるのは Gadget という概念だ。スライドデッキを作るとき、クラウド上のどこかで動くSaaSを呼び出すのではなく、システムが「あなた専用のスライドデッキソフトのインスタンス」を作る。それが Gadget であり、他人のスライドデッキとは別のサンドボックスで動く。

この設計から2つの帰結が生まれる、とREADMEは説明する。ひとつは、スライドデッキアプリにセキュリティバグがあってもあなたのスライドが攻撃者に漏れることが構造的に起きにくいこと。アクセスはすべてサンドボックスが仲介するためだ。もうひとつは、コードを自由に書き換えられること。機能が足りなければエージェントに頼んで足せばよく、しかも前者の理由からそれをやっても安全だ、という理屈になっている。

・Blueprint：Gadget そのものを共有したくない場合に、コード一式を共有して相手に自分専用のコピーを作らせる仕組み。オフィスソフトのテンプレートに相当するが、中身はコンテンツではなくアプリ全体
・リアルタイム共同編集：各 Gadget は Durable Object を土台にしているため、共同編集がほぼ自動的に付いてくる。READMEは「頼まなくてもコーディングエージェントが既定で実装してしまう」と書いている
・エージェント向けAPIが自動で付く：Gadget のクライアントとサーバーは Cap’n Web RPC で通信することが必須になっており、その結果サーバー側が理解しやすいAPIを必然的に晒す。MCPサーバーを別途書かなくてもエージェントがアプリの中で協働できる

サンドボックスの実装は2層になっている。サーバー側は Dynamic Worker として動き、インターネットへのアクセスが無効化されている。明示的に指定した外部資源にだけ Workers Bindings 経由で到達できる。クライアント側はサンドボックス化した iframe で動き、postMessage() 越しの Cap’n Web セッションでのみ自分のサーバーと話す。それ以外の通信は Content-Security-Policy と iframe の sandbox 属性で、ブラウザが許す範囲で最大限塞がれている。

エージェントの実行環境としてのサンドボックスという発想自体は他にもあり、Dockerコンテナ1つで実行環境を用意するAIO Sandbox入門：AIエージェント実行環境をDocker1つで構築する方法と比べると、Cloudflare OSは「実行環境を配る」のではなく「アプリの実体をユーザーごとに分ける」ところまで踏み込んでいる点が違う。

Gatekeeper：承認待ちでエージェントを止めない仕組み

ここがCloudflare OSでいちばん独自性のある部分だ。READMEはGatekeeperを「強化されたMCPサーバーのようなもの」と説明する。エージェントやGadgetを外部資源に引き合わせると、そのアクセスを管理するGatekeeperが作られる。GatekeeperはサービスごとにCap’n WebのきれいなAPIを提供し、OAuthを処理し、ユーザーが意図した資源だけに narrow なアクセスを強制し、すべての操作を記録し、副作用のある操作については人間に承認・拒否の機会を与える。

最後の点についてREADMEは「state of the art の重要な前進」と自称している。従来のhuman-in-the-loopは承認が同期的で、エージェントは承認が出るまで停止せざるを得ない。だから人は諦めて自動承認や --dangerously-skip-permissions に倒れる——という問題意識だ。Gatekeeperの答えは、承認が要る操作が来たら結果をローカルで予測してエージェントには「完了した」と伝え、エージェントを先へ進ませる。読み戻しに対しても予測した結果を返す。人間は後で都合のいいときに、まとめてでも1件ずつでも承認・却下できる。

「シミュレート」は作り話ではない——ソースで確かめた境界

READMEのこの説明だけ読むと「エージェントに嘘のデータを食わせている」ようにも読める。実際どうなのかは実装を読むしかない。packages/gatekeeper-homeassistant/src/simulation.ts（397行）の冒頭コメントが方式を明言している。

方式は overlay-at-read-time（読み取り時の重ね合わせ）だ。読み取りは実際の状態を起点にし、そこから時系列順に並んだ承認待ちアクションを走査して、それぞれの予測される効果を適用する。承認待ちのアクションはゲートキーパーのDurable Objectストレージの pending:* 行に置かれている。つまり返るのは「実状態＋未適用の変更を重ねた結果」であって、無から作った値ではない。

そして境界の引き方が誠実だ。ソースのコメントは、予測するのは最終状態だけで、アニメーションや遷移のタイミングは扱わないと明記する。さらに重要なのは次の一文で、script.turn_on や scene.activate、カスタムサービスのように結果が予測できない呼び出しは意図的にシミュレートせず、読み取りには承認前の素の状態が返る、と書かれている。コメントはこれを「which is honest」と表現している。実際にコード本体を見ると、対応表に無いサービス呼び出しや対象が解決できないケースでは return state（入力をそのまま返す）に落ちる分岐が並んでいる。

この意味論はテストで固定されている。packages/gatekeeper-confluence/__tests__/simulation.test.ts のテスト名がそのまま仕様の要約になっていた。

・returns the base title when no actions touch it（触っていなければ元の値）
・applies the latest setTitle（最後の変更が勝つ）
・applies setContent then appendContent in order（順序どおりに畳む）
・seeds the body from a provisional create（作成待ちのものを起点にする）
・appends pending comments after base comments（承認待ちを既存の後ろに足す）

手元で gatekeeper-confluence のテストを走らせたところ、7ファイル85件すべてが通り、うち simulation.test.ts が12件だった。リポジトリ直下の scripts 配下のテストも、依存を導入した状態で33件すべてが通っている。なお依存を入れずに実行すると typescript や jsonc-parser が見つからず3ファイルが落ちるが、これは環境の問題であって実装の不具合ではない。

自動承認はどこまで許されるか——2条件のAND評価

「承認を後回しにできる」と聞くと、では自動承認との違いは何かという疑問が出る。packages/workshop-backend/src/auto-approval.ts は95行と短く、全部読める。ここに書かれた規則は明快だった。

自動適用の資格は2つのシグナルを両方要求する。アクションに付いた autoApprovable の判定が真であること、そしてそのゲートキーパーのそのアクション種別（actionKind.tag）についてユーザーが有効化したルールが存在すること。コード上は record.description.autoApprovable !== true || rule === undefined で弾かれる。つまりユーザーがルールを1つも有効にしていなければ、自動適用は起きない。

さらに堅いのが順序の扱いだ。ドレイン処理は承認待ちを昇順に処理し、自動対象でないアクション（＝手動ゲート）に当たった時点で break する。コメントは「後続の自動承認可能なアクションへ飛び越すことは決してしない」と明記している。適用中に例外が出た場合も同様に、そのアクションを承認待ちのまま残して停止する。人間のゲートを超えて何かが黙って適用される事態を、順序の不変条件として排除している。

同時実行への配慮もある。ゲートキーパーごとに single-flight のガードを持ち、ドレインが走っている最中に別のドレインが要求されたら「もう一周する」フラグを立てるだけにして二重適用を防ぐ。適用直前にはストレージから状態を取り直し、他のドレインに取られていないか確認する。自動承認は、ルールを有効にしたユーザーの権限で実行されたものとして記録される。

工程やガバナンスを外側から縛るという発想は他のOSSにもあり、OWASP Agentic対応を掲げるAgent Governance Toolkit完全解説｜Microsoft発のOWASP Agentic 10/10対応・本番Agent監査や、遷移をYAMLの状態機械で統制するTAKTとは｜AIコーディングエージェントの工程をYAML状態機械で統制するCLIの仕組みと使い方を徹底解説と比べると、Cloudflare OSは「工程」ではなく「外部への副作用」に絞ってゲートを置いている点が異なる。

MCPとの関係——事前に全部つなぐのをやめる権限モデル

Cloudflare OSはMCPを否定しているわけではなく、MCP用のゲートキーパーを2つ持っている。ユーザーが自分でエンドポイントURLを貼る gatekeeper-mcp と、管理者が設定する単一のポータルである gatekeeper-mcp-portal だ。両者の実装は packages/mcp-shared が共有する。

信頼の境界は packages/mcp-shared/src/tools.ts にあり、ここが「サーバーの自己申告がポリシー判断に変わる唯一の場所」だとコメントに書かれている。定義されている信頼階層は2つだ。

判定ロジックは短く、readOnlyHint === true のツールだけが読み取り（observation）として即時実行され、それ以外はすべて承認キューに入る。自動適用の資格は !readOnly && trust === "vetted" && annotations.destructiveHint === false && annotations.idempotentHint === true の全成立を要求する。コメントは、すべての判定を真偽の厳密比較で書いてあるので注釈の無いツールはすべての条件を落ちて「決して自動適用されないアクション」になる、と設計意図を説明している。同時に、byo でも readOnlyHint を尊重するのは「無料の勝ちではなくトレードオフ」であり、サーバーがラベルを誤ればそのツールは承認なしで走ってしまうと自ら認めている。1エンドポイントから取り込むツールは200件が上限だ。

権限モデルそのものも一般的なエージェント構成と違う。エージェントもGadgetも既定では何にもアクセスできない。外部アカウントをワークスペースに設定済みであっても、自動的に使えるようにはならない。使わせたい資源は都度「紹介（introduce）」する必要があり、リポジトリのリンクを貼るかUIから選ぶ形になる。エージェントの側から「この資源が要る」と紹介を要求することもでき、人間はそれを与えるか拒否する。READMEはこれを、MCPサーバーを起動時に設定して全チャットで全サービスに常時到達できるようにする一般的な構成との対比として説明している。

エージェントがエージェントカタログとして受け取る発見用メタデータにも上限が掛かっている。エントリは25件、IDは256文字、タイトル100文字、説明400文字が上限で、コメントには「カタログは信頼できないデータとしてエージェントの文脈に注入されるので有界でなければならない」と書かれている。

Cloudflare OSのインストールと実行——ローカル起動から配備まで

いちばん手軽なのはローカル起動だ。pnpmを入れて次を実行すると、wrangler と workerd の上でスタック全体がローカルで立ち上がる。

# pnpm を入れてからリポジトリ直下で
pnpm run-local
# → http://localhost:8787 を開く。データは .wrangler 配下に保存される

READMEはこれを本番用途ではなく「何ができるか手早く見るための方法」と位置づけている。フロントとバックを分けて開発する場合は2つのターミナルで分けて起動し、http://localhost:3000 を開く。

pnpm dev-server   # ターミナル1：バックエンド（router が Vite へプロキシする）
pnpm dev-client   # ターミナル2：フロントエンド（Vite）

動作確認とテストは次のとおり。筆者の環境（Node 22.13.1・macOS）では、依存導入後にリポジトリ直下の scripts のテストが33件すべて通った。

pnpm install                  # 依存を入れないとテストは module not found で落ちる
node --test scripts/*.test.js # 33/33 pass を確認
pnpm lint                     # oxlint と再帰的な tsc --noEmit（CIが強制している内容）

自分のCloudflareアカウントへ配備する場合は https://os.cloudflare.app/deploy のオンラインフローが用意されており、ゲートキーパーやコード変更を伴うより本格的な配備には cloudflare/cloudflare-os-starter が案内されている。一方、workerd を使って自社サーバーへ丸ごと配備する手順はCOMING SOONの扱いで、ドキュメントとツールが未整備だと明記されている。「Cloudflareに縛られない」という主張自体は workerd がOSSである以上もっともだが、現時点で整った導線があるわけではない点は割り引いて読む必要がある。

外部サービスに接続するゲートキーパーの多くはOAuthのクライアント資格情報など個別の設定を要する。READMEはGitHub・Google・Cloudflare・Supabase・Notion・Confluence・Email Workers・Home Assistant・Slack・Spotify・ZoomInfoの11件について、各パッケージのREADMEに手順があると案内している。ただし実際の packages/ には gatekeeper-* が16個ある。差分はContext Library（gatekeeper-context）やScheduled Tasks（gatekeeper-scheduler）、MCP用の2つのように第三者OAuthを必要としないものが中心だが、gatekeeper-linear のように実在の外部サービス向けでありながら一覧にもパッケージ内READMEにも現れないものもある。数え方の違いで説明できる範囲を超えて、一覧が実装に追いついていない箇所があるということだ。

類似リポジトリとの比較——同じCloudflare製でも層が違う

Cloudflare は AI エージェント関連のOSSを複数公開しており、名前が似ていて混同しやすい。すべてGitHub APIで実測した値で並べる。

要するに、agents や sandbox-sdk が「自分でエージェント基盤を組み立てるための部品」なのに対し、Cloudflare OSは「組み上がった製品を丸ごとフォークして自社版にする」ことを想定している。READMEも「あなたの会社がCloudflare OSを使うのではなく、Your Company OS にしてほしい」と書いている。ライセンスがApache-2.0である点はこの用途と整合する。

導入前に知っておくべき制約とセキュリティ上の注意点

良い設計が見える一方で、採用判断に効く制約もはっきりしている。

外部からの貢献をほぼ受け付けない方針。CONTRIBUTING の記述は率直で、現時点では外部の貢献を求めていないとしている。理由も明記されていて、AIによってコードを書くのは容易になったが難しいのはレビューと品質・一貫性の維持であり、外部からのコード提供は「簡単な部分を寄付して難しい仕事を増やす」ことになる、という論だ。受け入れるのは小さく自明に検証できる修正のみで、誤字修正のような低価値のPRや十数行を超えるPRはこのガイドラインを参照して閉じるとまで書かれている。Apache-2.0のOSSでフォーク前提を掲げつつ、上流への還流は事実上閉じている。自社で改変して使うなら、その差分を自分で永久に保守する前提になる。

性能に関する公称値には裏付けが無い。READMEは「同じモデルを使っていても、Cloudflare OSのコーディングエージェントは汎用のコーディングエージェントより良く速く、より少ないトークンで動くことが多い」と主張している。リポジトリ全体を検索したが、この主張に対応するベンチマークの結果も測定条件もリポジトリ内には見つからなかった。ヒットしたのはREADMEのその一文だけである。設計上そうなりうる理由（統合されて単純化された環境、Code Modeによるツール呼び出し）は理解できるが、数字として検証できる材料は公開されていない。

セキュリティ設計で評価できる点も挙げておく。AGENTS.md によれば、認証・認可の設定（サインインプロバイダやパスワードログインの無効化）は管理画面の設定項目にあえて置かず、環境変数駆動のままにしてある。理由は「管理者セッションが乗っ取られた場合に変更されないようにするため」と明記されている。管理画面で変えられるのはエージェントの指示文やバナー、どのコネクタを提供するかといった「柔らかい」設定に限られる。また workshop-backend は kernel と位置づけられ、レビュアーが全行を読む前提で差分を小さく保つよう求められている。権限が「ambient（自動注入）」になるのはユーザーか管理者の設定によってのみで、ゲートキーパーが自分で自分の ambient 性を主張してはならない、という規則も明文化されている。

運用上の注意として、Gatekeeperのシミュレーションは承認待ちの状態を重ねた値をエージェントに見せる。予測できない操作については素の状態が返るため、エージェントが「自分の書き込みが反映されていない」と誤認して再試行する余地は残る。承認キューが長時間放置されると、エージェントが見ている世界と実世界の乖離が広がる点は、運用ルールで補う必要がある。

まとめ

Cloudflare OSは、名前から受ける印象とは違って「Cloudflare Workers上で動くAIエージェントのワークスペース製品」であり、AI関連OSSとしても、エージェントに与える権限とサンドボックスという意味でセキュリティの題材としても、実体のある対象だった。

いちばんの見どころは、human-in-the-loopを同期的な停止から解放するために「承認待ちの効果を読み取りに重ね合わせる」方式を選び、しかも予測できないものは重ねずに素の状態を返すという境界をソースとテストで明示していることだ。自動承認も2条件のAND評価と「手動ゲートを飛び越さない」順序保証で締められている。READMEの自己申告のうち、この設計に関する部分は実装で裏が取れた。一方で性能の公称値には裏付けが無く、外部貢献はほぼ閉じ、自社サーバーへの配備手順は未整備で、本人たちが early access と宣言している。フォークして自社版にするという用途を本気で検討するなら、この非対称性を踏まえて判断したい。

参照ソース

・cloudflare/cloudflare-os — 公式リポジトリ。README・AGENTS.md・CONTRIBUTING、および packages/gatekeeper-homeassistant/src/simulation.ts、packages/workshop-backend/src/auto-approval.ts、packages/mcp-shared/src/tools.ts、packages/workshop-shared/src/gatekeeper.ts（Apache-2.0）
・Cloudflare OS 公式サイト — 配備フローの導線
・Cap’n Web — Cloudflare OSがクライアント・サーバー間およびゲートキーパーAPIに全面採用しているRPC
・Dynamic Workers（Cloudflare公式ブログ） — Gadgetサーバーの実行単位
・Durable Object Facets and Dynamic Workers（Cloudflare公式ブログ） — 各Gadgetが載るFacetの解説
・Code Mode（Cloudflare公式ブログ） — エージェントがコードを書いて即実行する方式