Cloudflare OSは、Cloudflareが社内で使ってきたAIエージェントの作業環境を、2026年8月5日にApache 2.0のオープンソースとして公開したものです。名前はOSですが、PCにインストールするOSではありません。Cloudflare Workersの上で動き、社員がブラウザからエージェントに資料作成や小さな業務アプリの作成を頼み、GitHubやGoogle Workspaceなどの社内データに許可した範囲だけでつなげる基盤です。この記事では、Gadget・Gatekeeperという2つの仕組み、ローカルでの起動とGitHub連携の設定、自社アカウントへのデプロイ経路と費用、10月1日に受付が始まったマネージド版までを、公式のブログとGitHubのREADMEをもとに整理します。
まとめ：Cloudflare OSはWorkers上で自社用に作り替える社内AIエージェント基盤
結論から書きます。Cloudflare OSは、完成品のSaaSではなく「自社用のAI作業環境を組み立てるための土台」です。READMEにも、目指すのはCloudflare OSを使うことではなく「Your Company OS」にすることだと書かれています。
試すだけならpnpmで1コマンドです。本番に出すなら、Cloudflare Access・Workers Paid・AI Gatewayを前提に、starterリポジトリで版を固定してデプロイします。2026年10月時点ではearly access版の扱いで、自社サーバーでの本番運用手順は「COMING SOON」のままです。
向いているのは、すでにCloudflareで社内システムを守っていて、AIに社内データを触らせる権限設計で悩んでいる組織です。Microsoft 365が業務の中心で、本番のSLAを求めるなら、2026年10月時点では見送りが妥当です。
Cloudflare OSの正体とGadget・Gatekeeperの構成要素
公式のGitHubリポジトリのREADMEは、Cloudflare OSが提供するものを3つに絞っています。会社の業務知識を読み込んだエージェントのチャットUI、エージェントに作らせる小さなアプリ「Gadget」のサンドボックス、そしてエージェントとアプリの両方に権限の枠をはめる「Gatekeeper」です。
8月5日のOSS公開から10月1日のマネージド版ウェイトリストまでの経緯
Cloudflareの日本語版発表記事によると、最初の版は2026年5月に全社員へ配られ、エンジニア以外も含む数千人が日常的に使っています。8月5日に公開されたのは、その経験をもとに作り直したバージョン2です。READMEは2026年8月のリリースを「多くの粗が残るearly access版」と位置づけています。
次の動きは10月1日です。マネージド版の発表記事で、Cloudflareが運用まで引き受ける版のウェイトリストが始まりました。カスタムドメイン、Cloudflare Accessのポリシー、AI Gatewayを指定すれば残りはCloudflareが用意する、という説明です。料金は2026年10月24日時点で公表されていません。
10月24日時点でGitHubのスターは約1.16万、リリースタグは0件です。版はコミットで固定します。
チャットUI・Gadget・Gatekeeperを通常のOSの部品に対応させた構成表
READMEには、Cloudflare OSのパッケージを通常のOSの部品に対応させた表があります。リポジトリを読むときの地図になるので、主要な行を抜き出します。
| 通常のOS | Cloudflare OS | 役割 |
|---|---|---|
| カーネル | workshop-backend | 隔離と権限の管理 |
| デバイスドライバ | gatekeeper-* | 外部サービスとの接続口 |
| シェル | workshop-frontend | ブラウザの操作画面 |
| プロセス | Gadget | 利用者ごとのアプリの実体 |
| 実行ファイル | Blueprint | Gadgetを複製する設計図 |
表の2列目はpackages配下のディレクトリ名です。10月24日時点でpackagesには33個のディレクトリがあり、そのうちgatekeeper-で始まるものが20個です。GitHub・GitLab・Google・Slack・Notion・Confluence・Linear・Supabaseのほか、汎用のgatekeeper-mcpとgatekeeper-mcp-portalがあります。Microsoft 365専用のものはありません。
Dynamic Workerで利用者ごとにGadgetを隔離する実行の仕組み
READMEによると、ワークスペースは1つずつがDurable Objectで、Gadgetは1つずつがDynamic WorkerのFacetとして動きます。Dynamic Workerはコードを実行時に読み込んで別のWorkerとして動かす仕組みで、READMEは「Cloudflare OSのためにWorkersのランタイムへ追加した機能」だと説明しています。
スライドを作ると、全員共通のスライドSaaSを呼ぶのではなく、その人専用のスライドアプリが1つ起動します。サーバー側はインターネットへの通信を切ったDynamic Workerで、クライアント側はサンドボックス化したiframeです。両者の通信はpostMessage()越しのCap’n Web RPCに限られます。Workersの隔離単位そのものはV8 Isolateの起動時間とCloudflareの分離設計で、RPCの書き方はCap’n Webの仕組みと使い方で詳しく扱っています。
Gadgetのサーバーに定義したメソッドは、そのままエージェントから呼べるAPIになります。アプリごとにMCPサーバーを書く必要はありません。
Gatekeeperで認証情報を隔離し副作用のある操作を後から承認する権限設計
Cloudflare OSの中心はGatekeeperです。READMEは「強化版のMCPサーバー」と表現しています。外部サービスごとに1つのWorkerとして動き、OAuthの処理、許可したリソースだけへの絞り込み、全操作の記録、副作用のある操作の承認を受け持ちます。
能力ベースのアクセス制御でエージェントの初期権限をゼロにする設計
エージェントとGadgetは、作られた時点で何にもアクセスできません。管理者がGitHubとの接続を設定していても同じです。使わせたいリポジトリのURLを貼るか、画面の「add resource」で選んで、そのチャットに対して個別に「紹介」します。エージェントの側から必要なリソースを求め、人が許可や拒否を返す流れもあります。
MCPサーバーを最初に登録して全チャットから使える状態にする一般的なエージェント環境とは、ここが逆です。認証情報はGatekeeperの中に残り、エージェントが書いたコードには型付きのバインディングとしてリソースだけが渡ります。発表記事は、機密データを読んだ作業について、外部への送信や別エージェントへの引き継ぎを止めるポリシーも紹介しています。
承認待ちで止めずに結果を模擬して後でまとめて承認する非同期の仕組み
人の承認を挟むエージェントは、承認待ちで作業が止まりがちです。それを嫌って自動承認にしてしまう運用は珍しくありません。
Gatekeeperは止めません。承認が要る操作が来ると、結果を手元で模擬してエージェントに「完了した」と返し、作業を先へ進めます。エージェントが結果を読み返した際に見せるのは、手元で模擬した結果です。人は作業が終わってから、溜まった操作を一括または1件ずつ承認・却下します。
裏を返すと、承認するまで外部には何も起きていません。承認を後回しにするとPRもメールも出ないままなので、運用ルールとして「作業後に承認キューを確認する」を決めておく必要があります。
GitHub Gatekeeperで常に人の承認が残るマージと承認レビューの扱い
操作ごとの自動承認は設定できます。GitHub GatekeeperのREADMEでは、操作はgithub.pushのような種類名を持ち、接続ごとに種類単位で自動承認をオンにできます。
ただし例外が2つあります。プルリクエストのマージと、承認（Approve）のレビューです。この2つはどの設定でも自動承認にならず、必ず人が承認します。force pushはgithub.forcePushという別の種類なので、通常のpushを自動承認にしても履歴の書き換えまでは許されません。
エージェントにコードを書かせる組織で一番怖いのは、レビューを経ずに本番ブランチへ入ることです。その経路が設定ミスでも開かない作りになっている点は、導入判断で評価してよい部分です。
Cloudflare OSをローカルで起動しGitHub連携を設定する作業手順
まずは手元で画面と動きを確かめます。ローカル実行はREADMEが「本番用ではない」と明記している試用の方法です。
pnpm run-localでlocalhost:8787に全体を立ち上げるコマンド
リポジトリのpackage.jsonはパッケージマネージャをpnpm 11.17.0に指定しています。starterリポジトリのREADMEはNode.js 24.19以上を前提にしているので、Node.jsは24系をそろえておくと止まりません。
git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm install
pnpm run-local
# ブラウザで http://localhost:8787 を開くrun-localはwranglerとworkerdで全体を動かし、データはリポジトリ直下の.wranglerに保存されます。画面を開いたら、READMEの例にある「顧客との打ち合わせ用のスライドを作って」や「共同編集できるホワイトボードのアプリを作って」を頼むと、Gadgetが作られる流れを確認できます。
GitHubのOAuth Appを作り.envに認証情報を書くGatekeeper設定
GitHubのリポジトリを扱わせるには、GitHub Gatekeeper用のOAuthの認証情報が要ります。READMEが強調している注意点は、作るのが「GitHub App」ではなく「OAuth App」だということです。GitHub Appはscopeを無視するため、ログイン時は最小権限、接続時にrepo権限という切り替えが働きません。
- GitHubのSettings > Developer settings > OAuth AppsでNew OAuth Appを選ぶ
- Homepage URLに
http://localhost:3000、Authorization callback URLにhttp://localhost:8787/gatekeeper/github/oauthを入れる - 登録後にGenerate a new client secretでシークレットを発行し、Client IDと一緒に控える
控えた値はpackages/gatekeeper-github/.envに書きます。このファイルはgitの管理から外れています。
# packages/gatekeeper-github/.env
CLIENT_ID=your-client-id-here
CLIENT_SECRET=your-client-secret-here本番環境ではコールバックURLのホスト部分を自社の公開URLに置き換えます。GitHubが2026年8月以降に登録したOAuth Appは既定で有効期限付きのトークンになり、Gatekeeperは8時間の期限が切れる前に自動で更新します。GoogleやConfluenceについても、同じ形の手順の掲載先は各パッケージのREADMEです。
自社のCloudflareアカウントへ本番デプロイする3つの経路と必要な製品
社内に配るときの経路は3つあります。どこまで自社で触るかで選びます。
ホスト型デプロイ・starterリポジトリ・マネージド版の違いと選び方
| 経路 | 中身 | 向いている場面 |
|---|---|---|
| ホスト型デプロイ | 画面の案内で自社アカウントへ配置 | 部署単位の評価 |
| starterリポジトリ | 版を固定し自社のコードで管理 | 全社展開・独自Gatekeeper |
| マネージド版 | 運用と更新をCloudflareが担う | 運用要員を置けない組織 |
ホスト型はos.cloudflare.app/deployから始め、URLはworkers.devのアドレスになります。独自ドメインや社内向けGatekeeperが要るならstarterリポジトリです。ホスト型から移る際にWorker名やストレージIDを引き継がないと、中身が空の環境ができるとREADMEは注意しています。
npx cf-os initからcf-os deployまでのstarterの手順
starterは、上流のCloudflare OSを書き換えずに、版の固定・サインイン・ルーティング・Gatekeeperの追加を受け持つリポジトリです。デプロイされるWorkerは最大7個で、外部に公開されるのはrouterの1個だけです。
# Node.js 24.19以上とpnpm 11.17を入れておく
npx cf-os init my-os # 複製・インストール後、サインイン・Worker名・ホスト名・AI Gatewayを対話で設定
cd my-os
pnpm cf-os check # deployment.jsonc の内容をアカウントと照合し、ビルドと全デプロイを空実行
pnpm cf-os deploy # 確認なしで本番デプロイ
npx cf-os@latest update # starterの更新と固定版の取り込み（上げる前に変更点を確認）initは設定をdeployment.jsoncに書き出し、Cloudflare Accessのセルフホスト型アプリケーションを探すか作ります。アカウント側には、Workers・KV・R2・Browser Rendering・Dynamic Worker Loaders・Workers AI・AI Gatewayが要ります。WebSearchのGatekeeperは無料のWorkers AI枠では動かず、AI Gatewayのクレジットが別に必要です。
Workers Paid月5ドルとDynamic Workers従量課金の費用
Cloudflare OS自体のライセンス料はかかりません。費用はCloudflareの各製品と、AIモデルの推論に移ります。
前提になるのがWorkers Paidです。Dynamic Workersの料金ページは「Workers Paidプランでのみ利用可能」としており、Workersの料金ページではWorkers Paidの最低料金がアカウントあたり月5ドルです。Dynamic Workersは月1,000件の一意なWorkerまで含まれ、超えると1件1日あたり0.002ドルが加わります。Gadgetの数と使われる日数が増えるほど、この部分が伸びます。
見積もりで一番大きくなりやすいのはモデルの推論費です。推論はすべてAI Gatewayを通るので、人・チーム・ワークスペース単位の使用量が見え、予算とレート制限をかけられます。軽い作業を安いモデルへ、難しい作業だけ高性能モデルへ振り分ける設定は、展開前に決めておく項目です。Workers Paidの料金体系の全体はCloudflare Workersの料金・無料枠・Workers Paidの中身にまとめています。
Cloudflare OSを採用する組織の条件とearly access版で見送る場面
仕組みと費用を踏まえて、採用と見送りの線を引きます。
Cloudflare Accessで社内データをAIに安全につなぎたい組織の採用条件
次の条件がそろうなら、Cloudflare OSを試す価値があります。
- 社内システムの入口をすでにCloudflare Accessのポリシーで守っている
- GitHub・Google Workspace・Slack・Notionなど、Gatekeeperがある製品が業務の中心にある
- 非エンジニアに小さな業務アプリを作らせたいが、データの持ち出しが怖くて止めている
- 社内システム用のGatekeeperを書ける開発者を確保できる
最後の条件が分かれ目です。標準のGatekeeperで届かない基幹システムや自社APIは、starterのpackages/custom-gatekeeperで自前に書きます。既存のMCPサーバーがあればMCP server portals経由でつなぐ方法も選択可能です。MCPサーバーをWorkersで立てる方法はCloudflareでMCPサーバーを構築・公開する方法で解説しています。社内システムとエージェントをどの権限でつなぐかから設計したい場合は、AIエージェント開発のページで対応範囲を確認できます。
自社サーバー運用・Microsoft 365中心・本番SLAが要件なら見送る判断
次のどれかに当たるなら、2026年10月時点では採用しません。
- Cloudflareの外、自社サーバーで本番運用する必要がある（workerdでの本番手順は「COMING SOON」）
- Microsoft 365が業務の中心（専用Gatekeeperが無く、マネージド版の.docx・.pptx書き出しも「近日対応」）
- 障害時の保証やサポート窓口を契約で求める（early access版でリリースタグも無い）
- 社内システム用のGatekeeperを書いて保守する人がいない
READMEは外部からの大きなプルリクエストを受け付けておらず、足りない機能は自社のコードで補う前提です。運用を任せたいならマネージド版の料金公表を待ち、OpenAI Frontierのような企業向けエージェント基盤と並べて比べるのが現実的です。
Cloudflare OSの料金・日本語・自社サーバーについてよくある質問
検索されることの多い疑問に、2026年10月24日時点の公式情報で答えます。
Cloudflare OSは無料で使えますか？
ソフトウェアはApache 2.0のオープンソースで、ライセンス料はかかりません。Cloudflareのアカウントで動かす場合は、GadgetがDynamic Workersで動くためWorkers Paid（アカウントあたり月5ドルから）が必要で、ほかにAIモデルの推論費がかかります。マネージド版の料金は公表されていません。
Cloudflare OSはパソコンのOSの代わりになりますか？
なりません。WindowsやmacOSの代わりではなく、ブラウザから使うAIエージェントの作業環境です。OSと呼ぶ理由について、READMEでは2つの意味を挙げています。会社がAIを安全に使うための土台であること、そしてカーネル・ドライバ・プロセスに当たる部品でAIの処理を管理する作りであることです。
マネージド版のCloudflare OSはいつから使えますか？
2026年10月1日にウェイトリストの受付が始まった段階で、提供開始日と料金は公表されていません。発表記事によると、カスタムドメイン、Cloudflare Accessのポリシー、AI Gatewayを指定すれば、残りの構築と運用をCloudflareが引き受けます。待たずに始めるなら、ホスト型デプロイかstarterリポジトリで自社アカウントに置く方法があります。
Cloudflare OSで日本語のやり取りはできますか？
READMEと発表記事には、画面の日本語対応や日本語での精度についての記載がありません。エージェントの受け答えの質は、AI Gateway経由でつなぐモデルの日本語の力にほぼ左右されます。日本語に強いモデルを選び、社内の用語集や手順書を共有の文脈として登録したうえで、実際の業務文書で確かめてから展開範囲を決めてください。
Cloudflare OSを自社のサーバーで動かせますか？
技術的にはCloudflareのランタイムであるworkerdの上で動く作りで、ローカル実行も内部ではworkerdを使っています。ただし、自社サーバーでの本番運用の手順とツールはREADMEで「COMING SOON」とされ、2026年10月24日時点で公式の手順はありません。本番はCloudflareのアカウント上に置き、自社サーバーでの運用は手順の公開を待つのが安全です。
関連記事
- Cloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方：Cloudflare OSが載るWorkersの料金と基本の確認に。
- CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル：既存システムをMCP経由でつなぐときに。
- Cap’n Web（capnweb）とは？CloudflareのJavaScript RPCの仕組みと使い方：GadgetとGatekeeperが使うRPCの書き方に。
- V8 Isolateとは？Contextとの違い・起動時間の実測とCloudflareの分離設計：Gadgetを隔離する実行単位の理解に。
- AIハーネスとは？LLMエージェントの制御基盤を構成する6部品とSDK別の実装：エージェントの権限・承認の設計を一般化して考えるときに。
