--- title: "Cloudflare OSとは：社内AIエージェント基盤の仕組みとローカル起動・デプロイ手順【2026年10月時点】" url: "https://www.issoh.co.jp/tech/details/18844/" published: 2026-10-24 updated: 2026-10-24 categories: ["AI"] publisher: "株式会社一創" --- # Cloudflare OSとは：社内AIエージェント基盤の仕組みとローカル起動・デプロイ手順【2026年10月時点】 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リポジトリ](https://github.com/cloudflare/cloudflare-os)のREADMEは、Cloudflare OSが提供するものを3つに絞っています。会社の業務知識を読み込んだエージェントのチャットUI、エージェントに作らせる小さなアプリ「Gadget」のサンドボックス、そしてエージェントとアプリの両方に権限の枠をはめる「Gatekeeper」です。 ### 8月5日のOSS公開から10月1日のマネージド版ウェイトリストまでの経緯 [Cloudflareの日本語版発表記事](https://blog.cloudflare.com/ja-jp/cloudflare-os/)によると、最初の版は2026年5月に全社員へ配られ、エンジニア以外も含む数千人が日常的に使っています。8月5日に公開されたのは、その経験をもとに作り直したバージョン2です。READMEは2026年8月のリリースを「多くの粗が残るearly access版」と位置づけています。 次の動きは10月1日です。[マネージド版の発表記事](https://blog.cloudflare.com/managed-cloudflare-os/)で、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](https://developers.cloudflare.com/durable-objects/)で、Gadgetは1つずつが[Dynamic Worker](https://developers.cloudflare.com/dynamic-workers/)のFacetとして動きます。Dynamic Workerはコードを実行時に読み込んで別のWorkerとして動かす仕組みで、READMEは「Cloudflare OSのためにWorkersのランタイムへ追加した機能」だと説明しています。 スライドを作ると、全員共通のスライドSaaSを呼ぶのではなく、その人専用のスライドアプリが1つ起動します。サーバー側はインターネットへの通信を切ったDynamic Workerで、クライアント側はサンドボックス化したiframeです。両者の通信は`postMessage()`越しのCap’n Web RPCに限られます。Workersの隔離単位そのものは[V8 Isolateの起動時間とCloudflareの分離設計](https://www.issoh.co.jp/tech/details/12608/)で、RPCの書き方は[Cap’n Webの仕組みと使い方](https://www.issoh.co.jp/tech/details/10194/)で詳しく扱っています。 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](https://github.com/cloudflare/cloudflare-os/blob/main/packages/gatekeeper-github/README.md)では、操作は`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`権限という切り替えが働きません。 1. GitHubの**Settings > Developer settings > OAuth Apps**で**New OAuth App**を選ぶ 2. Homepage URLに`http://localhost:3000`、Authorization callback URLに`http://localhost:8787/gatekeeper/github/oauth`を入れる 3. 登録後に**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リポジトリ](https://github.com/cloudflare/cloudflare-os-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の料金ページ](https://developers.cloudflare.com/dynamic-workers/pricing/)は「Workers Paidプランでのみ利用可能」としており、[Workersの料金ページ](https://developers.cloudflare.com/workers/platform/pricing/)ではWorkers Paidの最低料金がアカウントあたり月5ドルです。Dynamic Workersは月1,000件の一意なWorkerまで含まれ、超えると1件1日あたり0.002ドルが加わります。Gadgetの数と使われる日数が増えるほど、この部分が伸びます。 見積もりで一番大きくなりやすいのはモデルの推論費です。推論はすべて[AI Gateway](https://developers.cloudflare.com/ai-gateway/)を通るので、人・チーム・ワークスペース単位の使用量が見え、予算とレート制限をかけられます。軽い作業を安いモデルへ、難しい作業だけ高性能モデルへ振り分ける設定は、展開前に決めておく項目です。Workers Paidの料金体系の全体は[Cloudflare Workersの料金・無料枠・Workers Paidの中身](https://www.issoh.co.jp/tech/details/6760/)にまとめています。 ## Cloudflare OSを採用する組織の条件とearly access版で見送る場面 仕組みと費用を踏まえて、採用と見送りの線を引きます。 ### Cloudflare Accessで社内データをAIに安全につなぎたい組織の採用条件 次の条件がそろうなら、Cloudflare OSを試す価値があります。 - 社内システムの入口をすでに[Cloudflare Accessのポリシー](https://developers.cloudflare.com/cloudflare-one/access-controls/policies/)で守っている - GitHub・Google Workspace・Slack・Notionなど、Gatekeeperがある製品が業務の中心にある - 非エンジニアに小さな業務アプリを作らせたいが、データの持ち出しが怖くて止めている - 社内システム用のGatekeeperを書ける開発者を確保できる 最後の条件が分かれ目です。標準のGatekeeperで届かない基幹システムや自社APIは、starterの`packages/custom-gatekeeper`で自前に書きます。既存のMCPサーバーがあれば[MCP server portals](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/)経由でつなぐ方法も選択可能です。MCPサーバーをWorkersで立てる方法は[CloudflareでMCPサーバーを構築・公開する方法](https://www.issoh.co.jp/tech/details/6032/)で解説しています。社内システムとエージェントをどの権限でつなぐかから設計したい場合は、[AIエージェント開発](https://www.issoh.co.jp/service/ai/agent/)のページで対応範囲を確認できます。 ### 自社サーバー運用・Microsoft 365中心・本番SLAが要件なら見送る判断 次のどれかに当たるなら、2026年10月時点では採用しません。 - Cloudflareの外、自社サーバーで本番運用する必要がある（[workerd](https://github.com/cloudflare/workerd)での本番手順は「COMING SOON」） - Microsoft 365が業務の中心（専用Gatekeeperが無く、マネージド版の.docx・.pptx書き出しも「近日対応」） - 障害時の保証やサポート窓口を契約で求める（early access版でリリースタグも無い） - 社内システム用のGatekeeperを書いて保守する人がいない READMEは外部からの大きなプルリクエストを受け付けておらず、足りない機能は自社のコードで補う前提です。運用を任せたいならマネージド版の料金公表を待ち、[OpenAI Frontierのような企業向けエージェント基盤](https://www.issoh.co.jp/tech/details/10884/)と並べて比べるのが現実的です。 ## 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の中身と対応言語・使い方](https://www.issoh.co.jp/tech/details/6760/)：Cloudflare OSが載るWorkersの料金と基本の確認に。 - [CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル](https://www.issoh.co.jp/tech/details/6032/)：既存システムをMCP経由でつなぐときに。 - [Cap’n Web（capnweb）とは？CloudflareのJavaScript RPCの仕組みと使い方](https://www.issoh.co.jp/tech/details/10194/)：GadgetとGatekeeperが使うRPCの書き方に。 - [V8 Isolateとは？Contextとの違い・起動時間の実測とCloudflareの分離設計](https://www.issoh.co.jp/tech/details/12608/)：Gadgetを隔離する実行単位の理解に。 - [AIハーネスとは？LLMエージェントの制御基盤を構成する6部品とSDK別の実装](https://www.issoh.co.jp/tech/details/11616/)：エージェントの権限・承認の設計を一般化して考えるときに。 --- 出典: [Cloudflare OSとは：社内AIエージェント基盤の仕組みとローカル起動・デプロイ手順【2026年10月時点】]()（株式会社一創）