Cloudflare OSで社内AIワークスペースを運用する方法

Cloudflare OSは、チャットUIの新製品というより、社内システムへ安全に届くエージェント作業環境を「自社のCloudflareアカウント上」で動かすためのOSS基盤です。

📑目次

1. Cloudflare OSの3部品と公開の位置づけ
2. Gatekeeperとゼロトラスト権限モデル
3. GadgetとBlueprintの共有境界
4. 導入手順と前提条件
5. 汎用エージェント／MCP直結との比較
6. 導入判断チェックリストと次の一手
7. 筆者の観点
8. よくある質問（FAQ）
9. まとめ

2026年5月にCloudflare社内へ先行配布され、同年8月に再構築版がApache-2.0で公開されました。

本記事では、公式発表と独立報道・分析を突合せ、次を整理します。

• 3部品構成
• Gatekeeper型のゼロトラスト権限
• Gadget/Blueprintの共有境界
• 導入前提
• 汎用エージェントやMCP直結との差分
• PoC判断のチェックリスト

---

Cloudflare OSの3部品と公開の位置づけ

3部品の定義

結論から言うと、Cloudflare OSは「ブラウザで話すAI」単体ではありません。次の3部品で構成されるプラットフォームです。

1. エージェント作業空間
2. Gatekeeper（統治レイヤ）
3. 個人が改変できるフルスタックアプリ（Gadget）

公式ブログは、これを社内で実際に使っているエージェント作業環境を、他組織が自社アカウントへ展開できる形で公開した、と説明しています（Cloudflare Blog）。

再構築の背景

再公開の背景には、初版で見えた運用課題があります。

GIGAZINEの整理では、再構築の動機として次が挙げられています（GIGAZINE）。

• 静的でライブ接続しづらいアプリ
• 決定的ジョブがエージェント技能を再実行してトークンを浪費する問題
• 共同作業時に観測データが漏れるリスク

つまり公開物は「社内チャットの見た目コピー」ではなく、権限・共有・実行モデルを作り直した版です。

社内採用シグナルの読み方

公式と二次分析で挙がる社内シグナルは、次のように整理できます。

• 2026年5月に全従業員へ前バージョンが配布され、職種を問わず数千人が日常利用している、と公式が述べている
• 二次分析では、営業で1万時間超の削減や30日で4,000以上のアプリ、といったCIO報告由来の数字も引用される
• ただし公開ベンチマークではなく、社内採用の参考値として扱うのが妥当（Developers Digest）

読者にとっての含意は単純で、「話題のAI UI」ではなく、社内SoRに触る前提の基盤として評価対象を切り替える必要があります。

出典

リポジトリとライセンス

ソフトウェア実体は公開リポジトリにあります。

• コア: cloudflare/cloudflare-os
• 組織設定をコアにパッチせず載せる例: cloudflare-os-starter
• デモ: os.cloudflare.app

ライセンスはApache-2.0で、早期アクセス時点では正式GitHub Releasesが薄い状態も観測されています（GitHub cloudflare-os）。

---

Gatekeeperとゼロトラスト権限モデル

ゼロ起点の権限

運用者視点の差分は、ここがいちばん大きいです。

Cloudflare OSでは入場をCloudflare Accessが担い、エージェントやアプリは権限ゼロ起点です。

許可するリソースは env.PROJECT のような typed binding で渡し、資格情報はエージェント本体や生成コードへ渡しません（Cloudflare Blog）。

Gatekeeperの役割

Gatekeeperはサービス別のWorkerです。役割は次のとおりです。

• OAuthを保持する
• 狭いAPI面だけを公開する
• 読取をログする
• 副作用（書き込み・マージ等）は承認を挟んで仲介する

典型例として、GitHubで「特定リポジトリのIssueは読めるがソースは不可、merge前に人の承認」といった粒度が公式・報道で繰り返し示されています（PC Watch、Cyber Press）。

実行隔離と観測追従

実行面の隔離もセットです。

• サーバ側のDynamic Workerはglobal outboundを無効化
• ブラウザ側もsandbox
• 任意のインターネット到達を塞ぐ設計

加えて観測追従ポリシーがあり、次を行います。

• エージェントが見たリソースを成果物に紐づける
• 共有時に閲覧者の元データACLを再検査する

ダッシュボード経由で倉庫テーブル権限を密輸する、といった経路を塞ぐ意図です。

副作用の承認疲れ対策として、結果をシミュレーションしてキューし後から一括承認する simulated-commit パターンも独立分析で強調されています（Developers Digest）。

MCPとの関係

MCPは捨てられていません。

MCP Server Portals経由はサポートされますが、ambient MCP（広いツール公開を既定にする）をセキュリティ既定にはしない、というのが公式の立ち位置です。

既存のMCP資産を残しつつ、権限境界を足したい組織向けの設計です。

---

GadgetとBlueprintの共有境界

GadgetとBlueprintの違い

「ファイル」がドキュメントではなく、client + server + API + SQLite を持つフルスタックになる点が、もう一つの設計中心です。

• Gadget: 利用者ごとの private インスタンスとして Dynamic Worker Facet 上に載り、既定は非公開
• ライブ共有: 同一状態を共同編集できる
• Blueprint共有: コードのみ。SQLiteデータ、会話履歴、資格情報、接続済みリソースは引き継がない

出典: Cloudflare Blog、GIGAZINE。

運用上の含意

RPC面では Cap’n Web による object-capability が使われ、クライアントもエージェントも同じAPI面を呼べる、という説明があります。

読者への実務含意は明快です。

• テンプレ配布（Blueprint）と本番データ共有（ライブ共有）を運用ルールで分離しないと、便利さのまま権限が広がる
• 情シスが最初に決めるべきは機能一覧より、共有モードの許可範囲です

---

導入手順と前提条件

試せる手順

今日から試せる範囲と、まだ揃っていない前提を分けます。

公式は自社Cloudflareアカウントへの展開を前提にし、「数分でデプロイ」と案内しますが、実測は環境依存です。

1. cloudflare-os と cloudflare-os-starter を確認し、コアを直接patchせず starter 側で組織設定を載せる
2. 自社（または検証用）Cloudflareアカウントへ展開する
3. 導入時にCloudflare APIトークンを用意する（必須）。組み込みモデル利用料は自社Cloudflareアカウント請求になる
4. Anthropic / OpenAI キーは任意。導入時または後からモデル設定で追加できる
5. Accessポリシー、AI Gateway（モデル許可・予算・レート制限）、必要なGatekeeperのOAuthを接続する
6. 同梱Gatekeeper例として GitHub、Google、Notion、Confluence、Slack、Email Workers、Cloudflare API、Supabase などが報道で列挙される（PC Watch）
7. 足りない社内SoRは自前Gatekeeperを書く前提でPoC範囲を切る（Developers Digest）

早期アクセス時点の制限

制限も同じ重みで見てください。公式・JA報道で一致している点は次のとおりです。

• 早期アクセスで粗い部分がある
• managed dashboard の時期・料金は未公開
• Cloudflare外の本番セルフホスト向けdocs/toolingは未整備で、workerd は技術的言及に留まる

出典: Impress Watch、PC Watch。

「自社アカウント上で成果物を組織所有にする」設計はロックイン緩和には効きますが、Workers/Cloudflare依存そのものが消えるわけではありません。

出典

---

汎用エージェント／MCP直結との比較

選定軸の比較表

「すでに社内CopilotやMCP接続がある」読者向けに、選定軸を表にします。

人気度やブックマーク数ではなく、権限・資格情報・共有・統治・成熟度で並べます。

権限・資格情報・共有ACL

観点	Cloudflare OS（Gatekeeper型）	汎用チャット＋APIキー配布	MCPサーバ直結（ambient寄り）
初期権限	ゼロ起点、逐次許可	キー権限に依存し広いことが多い	ツール公開範囲に依存
資格情報の置き場	Gatekeeper内、エージェントから隔離	利用者/エージェント側に渡りやすい	MCPサーバ側保持が一般的
共有時の元データACL	観測追従で再検査	成果物共有で漏洩しやすい	観測追跡は実装次第

成果物・統治・導入コスト・成熟度

観点	Cloudflare OS（Gatekeeper型）	汎用チャット＋APIキー配布	MCPサーバ直結（ambient寄り）
アプリ成果物	Gadget（private DB付き）/Blueprint	主に文書・スクリプト	ツール呼び出し中心
モデル/コスト統治	AI Gatewayで一元	各ツール分散	分散しがち
導入コスト	CFアカウント＋Gatekeeper設計	低いが監査が難しい	中程度
成熟度	早期アクセスOSS	製品による	製品/内製による

比較表の出典（2026年8月時点）

• Cloudflare Blog
• SD Times
• Cyber Press
• Developers Digest

比較表の読み方

読み方のポイントは、「導入の楽さ」だけで勝敗を付けないことです。

• APIキー配布: 立ち上げは速い一方、監査と共有境界が後から効きにくい
• MCP直結: 既存資産を活かせるが、観測追従や副作用承認を自前で揃えないと ambient 権限に寄りやすい
• Cloudflare OS: 逆に、Gatekeeper設計が本体作業になる

---

導入判断チェックリストと次の一手

PoC／holdのチェックリスト

読後に残す実務アクションは、採用宣言ではなく「PoCする／holdする」を書き切ることです。

• ✓ 対象業務は社内SoRの読み書きを含むか（含むなら Gatekeeper 設計が本体）
• ✓ 既に Cloudflare Access / Workers / AI Gateway の運用があるか
• ✓ 最初のGatekeeperを1つに限定したPoC範囲を書けるか（例: GitHub Issuesの読み取りのみ）
• ✓ 成果物共有ルール（ライブ共有 vs Blueprint）を情シスと合意できるか
• ✓ 早期アクセスを許容できるか。本番SLA・監査証跡・CF外セルフホスト必須なら hold
• ✓ managed待ちか、starterで今すぐ検証用アカウントを切るか

推奨3段パス

推奨パスは次の3段です。

1. 低リスクな読み取りGatekeeperを1本だけ接続し、sandboxアカウントでPoCする
2. 1業務フローで観測ログと共有時ACLを試験する
3. AI Gatewayで予算・モデル階層を固定してから、非エンジニア展開を検討する

SD Timesが伝える製品フレーミングも、ここでの判断材料になります。

• ブラウザ作業空間は開発者必須ではない
• 一方で Zero Trust既定とGatekeeper統治が前提
• managed dashboard は今後の選択肢として残されている

出典: SD Times。

---

筆者の観点

評価の本丸

インフラ/情シスの評価軸で見ると、Cloudflare OSの本丸はモデル性能比較ではありません。

本丸は、「エージェントに何を見せ、何を書かせ、誰と共有するか」をプラットフォーム側で強制できるかです。

組織前提ごとの読み方

• 既にAccessとWorkersがある組織なら、検証コストは相対的に下がります。
• 一方で、社内SoRごとにGatekeeperを書く前提を軽く見ると、PoCがUI試用で終わり、権限設計だけが残ります。

本番一括移行を見送る材料

次の点は、本番一括移行の材料にはまだ足りません。

• 早期アクセスであること
• managedの時期・料金が未公開であること
• CF外セルフホストが未整備であること

まずは読み取り1系統のGatekeeper設計書を書くところから入るのが妥当です。

---

よくある質問（FAQ）

Q1. Cloudflare OSは今すぐ本番利用できるか？

OSSとして自社Cloudflareアカウントへ展開自体は可能です。ただし次の前提を同時に見てください。

• 公式・報道とも早期アクセス前提
• managedの時期・料金は未公開
• Cloudflare外セルフホストの本番toolingも未整備

まずPoCが適切です。

Q2. すでにMCPを使っている組織でも意味があるか？

あります。MCP Server Portalsはサポートされます。

ただし既定思想は ambient MCP ではなく capability / Gatekeeper です。既存MCPを残しつつ権限境界を足す用途が中心になります。

Q3. 非エンジニアでも使えるか？

主UIはブラウザ会話で、日常利用に開発者スキルは必須ではありません（公式・SD Times）。

一方、Gatekeeper / Access / AI Gateway の初期接続は基盤側の作業です。

Q4. データはベンダーにロックインされるか？

自社Cloudflareアカウント上で動かし、成果物を組織所有にする設計です（Impress Watch）。

ただし Workers / Cloudflare 依存は残るため、次を分けて評価してください。

• SaaSサイロ回避
• 実行基盤依存

Q5. 最初に接続すべきシステムは？

同梱Gatekeeperがある読み取り中心（例: GitHub Issues）からが無難です。

書き込み副作用は、承認フローと観測ログを試験してから広げます。

---

関連記事:

• Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
• MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
• エージェント向け検索の設計｜どう探させ、何を返すか

まとめ

Cloudflare OSは、社内AIチャットの見た目ではなく、権限ゼロ起点のエージェント基盤 + 個人アプリ実行環境です。

差分価値は次にあります。

• Gatekeeper
• 観測追従ACL
• Blueprint境界
• AI Gateway統治

今の読者アクションは、どちらかです。

1. 1 Gatekeeperに絞ったPoC設計を書く
2. 早期アクセスやセルフホスト要件が合わないなら managed/要件整理で hold する

人気シグナルではなく、自社のAccess運用成熟度とSoR接続範囲で決めてください。