Cloudflare OSとは？オープンソースAIエージェント基盤の権限制御・料金・使い方【2026年8月最新】

Cloudflare OSは、Cloudflareが2026年8月5日（米国時間8月4日発表）にApache 2.0ライセンスでオープンソース公開した、AIエージェント向けの社内業務基盤です。全社員がブラウザ上でAIに文書・スライド・業務アプリ・自動化ワークフローを作らせながら、Gatekeeper（ゲートキーパー）という仕組みでエージェントに一切のAPIキーを渡さずに社内システムへのアクセスを制御できる点が最大の特徴です。

出典: GitHub cloudflare/cloudflare-os

この記事でわかること:

• Cloudflare OSが何であり、何ではないのか（「OS」と名乗る理由）
• Gatekeeperがどうやってエージェントの権限を制御しているのか
• 実際にいくらかかるのか（本体は無料でも運用コストは発生する）
• 導入手順と、2026年8月時点で「まだできないこと」
• Microsoft Agent 365やChatGPT workspace agentsなど、他のエンタープライズAI基盤との違い

想定読者は、社内へのAIエージェント導入を検討している情報システム部門・セキュリティ担当者・技術選定を担うエンジニア、そして「AIに社内データを触らせる怖さ」をどう解消するかを探している意思決定者です。

Cloudflare OSとは？押さえるべき3つの要点

Cloudflare OSは、次の3点で理解できます。

1. 「AIが社内の仕事をする場所」を丸ごとオープンソース化したもの
チャットUI、ドキュメント／スライド／スプレッドシートのエディタ、アプリのビルド環境、定期実行ワークフローまでが1つのプラットフォームに入っています。Cloudflareが自社の業務で実際に使っているものを、そのままApache 2.0で公開しました。

2. エージェントは「何もアクセスできない状態」から始まる
公式ブログの表現では「every agent and app starts with access to nothing」。社内システムへ接続するときも、エージェントにAPIキーやOAuthトークンは渡りません。Gatekeeperという中継レイヤーが認証情報を保持し、エージェントには「このチームのIssueを読む」といったスコープ済みの機能だけを渡します。

3. アプリは「みんなで使うSaaS」ではなく「1人1インスタンス」で生える
スライドを作るとき、共有のSaaSを呼ぶのではなく、自分専用のスライドアプリのインスタンス（Gadget）が生成されます。専用のSQLiteデータベースを持つ隔離環境なので、あるインスタンスの不具合が他人のデータを漏らす経路が構造的に存在しません。

一方で、公式READMEは2026年8月リリース版について「very capable, but still has many rough edges」「consider this an 'early access' release」と明記しています。現時点では検証・PoC向けの段階であり、無条件に全社展開できる完成品ではない、という前提で読み進めてください。

AIエージェントそのものの基礎から確認したい場合は、AIエージェントとはも併せて参照してください。

Cloudflare OSの基本情報（開発元・ライセンス・提供形態）

2026年8月7日時点の公式情報を整理すると次のとおりです。

Cloudflare CEOのMatthew Prince氏は公開時のコメントで「Cloudflare OS is how we run Cloudflare」「We built this because nothing else did what we needed」と述べています。社外向けに作った製品を公開したというより、自社の業務基盤をそのまま外に出したという性格が強いプロダクトです。

「OS」と名乗るが、LinuxやWindowsのようなOSではない

Cloudflare OSはハードウェアを制御する伝統的なオペレーティングシステムではありません。「会社の業務とAIエージェントを動かすための実行基盤」を、OSのメタファーで設計したものです。ここは最初に誤解を解いておくべき点になります。

日本語圏の解説記事で用いられている整理を借りると、次のような対応関係になります。

「エージェントが動くための実行環境・権限管理・プロセス隔離を一式そろえた層」と捉えると、名前の意図がつかみやすくなります。

10年前のSandstorm.ioを、AI時代に作り直したもの

開発の中心にいるのは、Cap'n ProtoとCloudflare Workersを設計したKenton Varda氏です。同氏は自身のX投稿で、Cloudflare OSを10年前に自身が立ち上げたスタートアップ「Sandstorm.io」のリメイクだと説明しています。

Sandstorm.ioは「アプリごとに隔離されたインスタンスをユーザーが自分で立てる」というセルフホスト型プラットフォームでした。当時は「アプリを自分で作る／改造する」部分の難易度が高すぎましたが、そこをAIエージェントが埋められるようになった、というのが今回の構想の背景にあたります。Gadgetという概念が唐突に見えるのは、こうした10年分の設計思想が背後にあるためです。

Cloudflare OSを構成する3つの要素

Cloudflare OSは、公式ブログの整理では次の3層で構成されています。

出典: Cloudflare 公式ブログ

エージェントワークスペース：AIが仕事をする作業場

エージェントワークスペースは、会話が終わっても状態が消えない作業環境です。組織固有のコンテキスト（社内ナレッジ、業務手順、スキルファイル）を読み込ませたうえで、次のような作業を行わせられます。

• 社内情報を使ったリサーチ
• ドキュメント・スライド・スプレッドシートの作成と編集
• チームで共同編集できるアプリの構築
• 毎週・毎日といった決まった手順の自動実行

会話ごとに使用するAIモデルを切り替えられるため、単純作業は小型モデル、難しい判断はフロンティアモデル、といった使い分けが利用者側でできます。複数のエージェントを役割分担させる考え方はマルチエージェントAIとはで整理しているので、設計思想の背景を押さえたい場合はそちらも参考になります。

Gadget：利用者ごとの専用アプリと、Blueprintによる配布

Gadgetは、Cloudflare OSで最も独特な概念です。アプリを「みんなで使う1つのシステム」ではなく、「利用者ごとに生えるプライベートなインスタンス」として扱います。

技術的には次のように隔離されています。

• クライアント側のコードは、ブラウザのサンドボックスiframe内で実行
• サーバ側のコードは、外向きネットワークがデフォルト無効のDynamic Workerで実行
• 両者の通信は postMessage() 上のCap'n Web RPC（Cloudflare製のオブジェクトケーパビリティRPC）のみ
• Content-Security-Policyとiframe sandbox属性でブラウザ側もさらに制限

公式READMEは「It's impossible for the slide deck app to have a security bug that leaks your slides to an attacker.」と表現しています。アプリの実装にバグがあっても、そのバグが他人のデータへ到達する経路自体が存在しない、という封じ込め方です。

そのうえで共有方法が2種類あります。

Blueprintの実務的な意味は大きく、「この機能を追加してほしい」と開発部門に依頼して順番待ちする代わりに、受け取った人がAIに指示して自分のインスタンスを改造できるという運用が成立します。

Gatekeeper：エージェントを「何もできない状態」から始めさせる門番

Gatekeeperは、Cloudflare OSのセキュリティ設計の中核です。エージェントと社内外のサービスの「間」に挟まる専用のWorkerとして動き、認証情報の保持からポリシー適用、ログ記録までを引き受けます。

Gatekeeperによる権限制御の仕組み

Gatekeeperが解こうとしているのは、AIエージェントに社内システムを触らせるときに最大の懸念となる「鍵を渡してしまう問題」です。運用ルールで縛るのではなく、構造から取り除くアプローチを取っています。

エージェントは「権限ゼロ」から始まる

Cloudflare OSでは、エージェントもGadgetもアクセス権をまったく持たない状態から始まります。使えるようにするには、管理者が対象サービスのGatekeeperを立て、そこにポリシーを書く必要があります。

Gatekeeperが担うのは次の役割です。

• OAuth認証情報の保持と管理（エージェント側からは完全に隔離）
• 「どのリソースに」「どの操作を」許すかのポリシー適用
• リソース読み取りの記録（観測ログ）
• 外部に影響を及ぼす書き込み操作の制御と承認要求
• 全アクションのログ記録

「便利にするために全部許可してしまい、あとで事故る」という失敗が起きにくい初期値になっている、という点が設計上の要です。エージェントに広すぎる権限を与えた結果どうなるかは、AIエージェントがデータを全削除した事故まとめで実例を整理しています。

APIキーではなく「ケーパビリティ」を渡す

従来のAIエージェント連携とCloudflare OSの決定的な違いはここです。

エージェント側のコードは、公式ブログの例のように書きます。

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT は「このチームのIssueを一覧する能力」だけを持つオブジェクトであり、その裏にあるトークンは見えません。公式ブログの表現では「The credential never touches the agent or its code.」です。

GitHub連携で何ができて何ができないか

抽象論だとイメージしづらいので、標準搭載のGitHub Gatekeeperで公式が挙げている制御例を見ます。

• アクセスを単一リポジトリのみに限定する
• Issueは読めるが、ソースコードは読めないようにする
• 特定のフィールドをマスクして返す
• レートリミットを適用する
• マージの前に人間の承認を必須にする

「GitHubに繋ぐ／繋がない」という粗い判断ではなく、リポジトリ単位・操作単位で線を引ける点が、既存の連携方式との違いになります。

読んだデータが、共有時に再チェックされる

Gatekeeperのもう一つの特徴が、公式ブログで「Policy follows what the agent has seen」と表現される仕組みです。

1. エージェントが読んだリソースをすべて記録する
2. その結果として生成された成果物に、観測履歴が紐付く
3. その成果物を誰かに共有しようとすると、Gatekeeperが共有相手自身のアクセス権を、エージェントが経由した全リソースについて再チェックする

これによって、「人事データへのアクセス権がない社員が、エージェントに要約させた資料を経由して中身を受け取る」という抜け道が塞がれます。機密データを読んだセッションでは、外向きリクエストや共有範囲の拡大も制限されます。

社内のAI活用で最も見落とされやすい情報経路のリスクを、プラットフォーム側で扱っている点は評価できるポイントです。エージェント運用全般のリスク対策はAIエージェントのセキュリティ対策で体系的にまとめています。

作業を止めない「非同期承認」

人間の承認を挟む仕組みは、たいてい「毎回確認ダイアログが出て作業が止まる」か「面倒なので全部自動承認にする」の二択に陥ります。Cloudflare OSのGatekeeperは、書き込み操作の結果をシミュレートしてエージェントに返し、エージェントは作業を続行、人間は後からまとめて承認するという設計を採っています。

「承認フローがあるから安全だが実用に耐えない」という典型的な失敗を避ける狙いがあり、実運用での使い勝手に直結する部分です。

MCPとの違いと関係

MCPを使ったことがある人ほど「Gatekeeperと何が違うのか」が気になるはずです。整理すると次のようになります。

両者は競合ではなく階層が違います。 MCPが「接続の共通言語」であるのに対し、Gatekeeperはその上に「誰に何をどこまで許すか」の統制を足す層です。MCPそのものの仕組みはMCPとはで解説しています。

Cloudflare OSでできること

利用者の立場ごとに整理します。

非エンジニアの業務担当者

• ブラウザ上のチャットから、会話単位でAIモデルを選んで作業を依頼する
• 社内ナレッジや業務手順を踏まえたリサーチ
• ドキュメント・スライド・スプレッドシートの生成と編集（Google Docs／Slides／Sheets風のエディタが内蔵。スプレッドシートには関数もある）
• 生成物をデータ構造レベルでエージェントに編集させる（「このスライドを全ページ日本語にして」といった一括変更が成立する）
• 指示文からその場でアプリを作る（「打ち合わせ用のスライドを作って」「共同編集できるホワイトボードアプリを作って」「このGitHubリポジトリのIssueダッシュボードを作って」など、READMEに例が挙がっています）
• 作ったアプリをGadgetとして共有、またはBlueprintとして配布
• 定期実行・バックグラウンドでの決まった手順の自動処理

出典: Cloudflare 公式ブログ

管理者・情報システム部門

• Cloudflare AccessによるZero Trust認証で、そもそも誰が入れるかを制御
• Gatekeeperで社内システムごとのポリシーを定義
• AI Gatewayでモデルの選定・ロギング・DLP・コスト按分を一括管理
• MCP Server Portals経由で既存のMCPサーバを取り込む
• 全操作ログと観測履歴の記録

開発者

• 内蔵のコーディングエージェントによるアプリのビルド・テスト・デバッグ
• Monaco Editorでのコード編集、Yjsによるクライアント／サーバ間のコード同期
• 独自の社内システム向けにGatekeeperを自作して接続

こうした「AIに開発工程そのものを任せる」流れ全体についてはエージェンティックエンジニアリングとはで整理しています。

Cloudflare OSでできないこと・2026年8月時点の制約

導入判断で重要なのはここです。公式が明示している制約を並べます。

とくに「無料プランでは本番稼働できない」点と「SLA・認証情報が公開されていない」点は、社内稟議で必ず論点になります。導入検討の初期段階で押さえておくべき事実です。

料金：本体は無料でも、運用コストは発生する

Cloudflare OSのソフトウェア本体はApache-2.0のOSSであり無料です。ただし「無料で使える」わけではありません。 稼働にはCloudflareの有償プランと従量課金、さらにAIモデルの利用料がかかります。運用コストの内訳は見落とされやすいため、公式価格ページの数値をもとに詳しく整理します。

※以下は2026年8月7日時点の公開情報に基づきます。価格改定の可能性があるため、実際の見積もり時は公式価格ページで確認してください。

無料プランでは本番稼働できない

Gadgetの実行基盤であるDynamic Workersは、Workers Paidプランでのみ利用可能です。したがって無料のWorkersプランでCloudflare OSを本番運用することはできません。この要件は公式ドキュメントで目立つ形では書かれておらず、複数の技術メディアが指摘している注意点です。

Workers Paidは最低$5/月（アカウント単位）で、Workers／Pages Functions／Workers KV／Hyperdrive／Durable Objectsの利用分を含みます。

Dynamic Workersの課金体系

Dynamic Workersは3つの軸で課金されます（2026年8月時点の公式価格ページに基づく）。

なお、安定したWorker IDとコードを使い回せば1日1件のカウントで済みますが、IDを指定せずに呼び出したり .load(code) を使ったりすると呼び出しごとの課金になります。Dynamic Workersの日次作成課金は2026年5月26日に開始されています。加えて、ワークスペース状態やGadgetの永続化にDurable Objects、デプロイ時に自動作成されるR2バケットとKV名前空間の従量課金が乗ります。

モデル利用料はAI Gateway経由で別途かかる

Cloudflare OSではすべての推論がCloudflare AI Gatewayを通ります。モデル利用料は各プロバイダの従量課金であり、Cloudflareのインフラ費用とは別枠で発生します。

裏を返せば、AI Gatewayに集約されているため次の統制が効きます。

• 組織として「どのモデルを使えるか」を決められる
• ジョブの種類に応じてモデルをルーティングできる
• 利用量を個人・チーム・ワークスペース単位で按分（attribution）できる
• 予算設定とレートリミットを設定できる
• BYOM（Bring Your Own Model）で14以上のプロバイダから選べるため、モデルのベンダーロックインを避けられる

50人規模で使った場合の概算（試算）

公式単価から積み上げた試算です。実際の費用は利用実態で大きく変動するため、あくまで桁感の把握に使ってください。

前提：利用者50人、月20営業日、1人が1日に新規Gadgetを2つ作成、1人が1日200リクエスト、モデルは中位クラス（入力$1／100万トークン、出力$5／100万トークンと仮定）、1人あたり1日に入力30万トークン・出力3万トークンを消費。

この試算から読み取れる要点は明確です。コストの9割以上はモデル推論であり、Cloudflareのインフラ費用は相対的に小さいということです。したがって費用管理の焦点は「Workersの料金」ではなく「どのモデルに何を投げるか」の設計になります。

なお、マネージド版（Cloudflareダッシュボード統合）の価格は2026年8月7日時点で未発表です。

コストを暴走させないための設定

OSS＝無料という理解のまま導入すると、請求で驚くことになります。最低限、次を先に決めておくべきです。

1. AI Gatewayでワークスペース単位・チーム単位の予算上限を設定する
2. 用途別のモデルルーティングを定義する（要約・分類は小型モデル、設計や分析はフロンティアモデル）
3. Gadgetの作成数をモニタリングする（コード変更のたびに別カウントになるため、開発中は作成数が伸びやすい）
4. Dynamic WorkersのCPU課金には起動時間が含まれることを前提に、短命なWorkerを大量生成する使い方を避ける

Cloudflareの従量課金モデル全般の考え方はCloudflare Pay Per Useでも触れています。

使い方・導入手順

用途に応じて4つの入口があります。

出典: Cloudflare 公式ブログ

最短で試す：デプロイボタン

1. https://os.cloudflare.app/deploy にアクセスする
2. Cloudflareアカウントとの接続を承認する
3. 必要なリソースが自動作成される（Workers、KV名前空間3種＝BLUEPRINTS／AVATARS／CONTEXT_COLLECTIONS、R2バケット、公開URL）
4. 使用するAIモデルとAPIキーを設定する
5. チャット画面へ進む

ローカル環境へのインストールは不要です。初回に迷いやすいポイントとして、画面右下のボタンでエージェントを選択する必要があります（初期値は「No Agent」のため、そのままだと期待した動作になりません）。

ローカルで試す（開発・検証用）

pnpmが前提です。

pnpm run-local
# → http://localhost:8787

内部でwranglerとworkerdを使います。本番用途を想定した構成ではありません。フロントエンドとバックエンドを分けて開発する場合は次のとおりです。

pnpm dev-server
pnpm dev-client
# → http://localhost:3000

実運用向け：Starterリポジトリを使う

独自ドメインで運用する、社内システム向けのGatekeeperを自作する、といった場合はgithub.com/cloudflare/cloudflare-os-starterを使います。Cloudflare社内での運用構成をベースにしたサンプルデプロイが含まれます。

各Gatekeeperの利用にはサービスごとのOAuth設定が必要で、設定手順は各gatekeeperパッケージ内に記載されています。

完全セルフホストは可能か

ここは評価が分かれる論点です。

• 公式の見解：Workersランタイムであるworkerd自体がOSSのため、自社サーバ上で完全稼働させることは可能。ただしドキュメントとツールは準備中とREADMEに明記。
• 一部メディアの指摘：現実の実行環境はCloudflareの管理下に残る、という批判的な見方もある。

したがって「Apache-2.0だから自社完結できる」と早合点しない方が安全です。2026年8月時点では実質的にCloudflare前提であり、完全な自前運用は将来の選択肢として見ておく、という整理が実態に近いと考えられます。

導入メリット：Cloudflare社内での実績

Cloudflareの発表によると、社内での運用実績は次のとおりです（出典は同社の公式ブログであり、第三者による検証値ではない点に留意してください）。

公開されている社内ユースケースは次のようなものです。

• セールスオペレーション：提案書生成、テリトリープランニングをスキルファイルで自動化
• ITヘルプデスク：チケットキューの自動レビュー、指標トラッキング、返信ドラフト生成
• 事業開発・IR：自然言語での指示によるエージェント作成と独自ワークフロー構築
• 調達：ボトルネックの自動診断（従来は手作業のスプレッドシート作業）

注目すべきは「30日で4,000アプリ」という数字の意味です。これは開発部門を通さずに現場が自分でツールを作れる状態を示しており、Blueprintによる配布モデルの効果を裏付けています。同時に、管理対象のツールが短期間で急増するということでもあり、統制の設計とセットで評価すべき数字です。

セキュリティ：守れることと、守れないこと

Cloudflare OSの評価はセキュリティ設計に集約されます。

守れること（設計上の強み）

守れないこと・要注意な論点

1. LLMプロバイダへの信頼は前提として残る：プロンプト内容がモデル提供元に渡ること自体は避けられません。ゼロデータリテンション設定やローカルモデルの利用で緩和はできますが、設計上の前提として残ります。
2. V8アイソレートのサンドボックスがコンテナより堅牢かは未決着：Kenton Varda氏は「サンドボックスが十分に安全だから自由にやってよい」という立場ですが、隔離を強めるほど有用性が下がるというトレードオフ指摘もあります。ここは業界的に結論が出ていません。
3. Gadget乱立（Gadget sprawl）というガバナンス課題：誰でも複製・改造できるため、社内に分岐した未保守ツールが大量に発生しえます。セキュリティ事故というより、かつてSharePointで起きたような統制不全のリスクです。生産性の高さと管理コストの増加が同時に来ることを織り込む必要があります。
4. コストの暴走リスク：Gadget生成数とトークン消費に比例して費用が伸びるため、予算設定とレートリミットの設計は導入前に必須です。
5. 公式ドキュメントの未整備：運用手順・トラブルシューティングの一次情報が乏しく、現時点では自力で読み解く体力が求められます。

エージェント権限の統制をOSSで行う類例としてはPerplexity Numbatもあり、アプローチの違いを比較すると設計思想の理解が深まります。

他のエンタープライズAI基盤との違い

同じ「社内AI基盤」でも、Cloudflare OSは前提がかなり異なります。2026年8月時点の公開情報にもとづく整理です（各社の仕様は更新が早いため、最終判断は各公式情報で確認してください）。

各製品の詳細はMicrosoft Agent 365とは、ChatGPT workspace agentsとは、Gemini Enterprise Agent Platformとはでそれぞれ整理しています。

Cloudflare OSの決定的な違いは3点に集約されます。

1. オープンソースであること（コードを読める／自分で拡張できる）
2. エージェントに認証情報を渡さない権限モデル
3. アプリを利用者ごとの個別インスタンスとして生やせること

逆に、SLA・コンプライアンス認証・サポート体制・日本語UIの完成度といった「エンタープライズ製品として当たり前に求められる要素」では、商用プラットフォームに現時点で及びません。技術的な優位と、製品としての成熟度は別軸で評価する必要があります。

なお、Cloudflareは自社サイトのエージェント対応度を測るAgent Readiness Scoreなども展開しており、エージェント関連プロダクト群の一部としてCloudflare OSを捉えると位置づけが理解しやすくなります。

こんな企業におすすめ／おすすめしない企業

おすすめできるケース

おすすめしないケース

導入を検討する場合の進め方

いきなり全社展開ではなく、次の順で判断材料を集めるのが現実的です。

1. 費用の上限を先に決める（AI Gatewayの予算設定・レートリミット）。金額の主因はモデル推論であり、インフラ費用ではない
2. デプロイボタンで小さく立てる。3〜5人程度の検証チームで2〜4週間
3. Gatekeeperを1つだけ繋ぐ。いきなり基幹システムではなく、GitHubやNotionなど影響範囲が限定的なものから
4. 書き込み系操作は必ず承認を必須にする。読み取りだけで価値が出るか先に確認する
5. 観測ログと共有時の権限再検証が期待どおり動くかを、意図的にテストする
6. Gadgetの棚卸しルールを先に決める（命名規則、所有者、90日未使用の扱い）
7. 本番判断は、マネージド版の提供とドキュメント整備の状況を見てから

このうち「書き込み操作の承認必須化」と「Gadgetの棚卸しルール」は、技術検証よりも先に社内で合意しておくべき運用ルールです。ここを決めずに広げると、便利さが先行して統制が後追いになります。

よくある質問

Q. 商用利用はできますか？
A. Apache-2.0ライセンスのため、商用利用・改変・再配布が可能です。ただし外部からのコード貢献は、十数行程度の検証しやすいバグ修正に限定されており、大きな提案はGitHub Discussionsに出す運用になっています。

Q. Google WorkspaceやMicrosoft 365を置き換えるものですか？
A. 現時点ではその位置づけではありません。ドキュメント・スライド・スプレッドシートのエディタは内蔵していますが、公式が早期アクセス段階と明言しており、既存のオフィススイートを代替する前提の完成度・互換性は公表されていません。むしろ「既存の社内システムにエージェントを安全に繋ぐ層」として評価する方が実態に合います。

Q. エンジニアがいなくても導入できますか？
A. デプロイボタンだけなら非エンジニアでも到達できますが、Gatekeeperのポリシー設計とOAuth設定、コスト統制の設計には技術判断が必要です。公式ドキュメントが未整備な現状では、READMEとブログを読み解ける担当者の確保が実質的な前提条件になります。

Q. Cloudflare以外のクラウドで動かせますか？
A. 公式にはランタイムのworkerdがOSSであるため可能とされていますが、その手順とツールは2026年8月時点で準備中です。Dynamic WorkersやDurable Object FacetsといったCloudflare固有のプリミティブに依存しているため、実務上は当面Cloudflare前提と考えるのが安全です。

Q. 日本語には対応していますか？
A. 日本語UIの正式対応は公式に明記されていません。エージェントとのやり取り自体は使用するモデルに依存するため日本語で行えますが、Mac環境の日本語入力で変換確定のEnterが送信として扱われるといった不具合報告が個人ブログで見られます（一次情報ではないため参考程度に）。

Q. マネージド版はいつ、いくらで提供されますか？
A. Cloudflareダッシュボードに統合されたマネージド製品は「近日提供予定」とされていますが、提供時期・価格ともに2026年8月7日時点で未発表です。導入支援のパートナーとしてPresidioとHappy Cogが挙がっています。

Q. 既存のMCPサーバは無駄になりますか？
A. なりません。MCP Server Portals経由で既存のMCPサーバを取り込めます。Gatekeeperはその上にリソース単位の統制を足す層であり、置き換えではなく併用が想定されています。

まとめ

Cloudflare OSは、Cloudflareが自社の業務基盤をそのままApache-2.0で公開した、AIエージェント向けの社内ワークスペースです。要点を整理します。

• 最大の価値はGatekeeper。エージェントに認証情報を渡さず、リソース単位・操作単位で権限を絞り、読んだデータが共有時に再検証される
• アプリは利用者ごとのプライベートインスタンス（Gadget）として生成され、コードだけをBlueprintとして配布できる
• 本体は無料だが運用は有償。Workers Paid（最低$5/月）が必須で、コストの大半はモデル推論に乗る
• 2026年8月時点では早期アクセス段階。公式ドキュメント未整備、マネージド版未提供、SLA・認証情報の公開なし
• 完全セルフホストは将来の選択肢。手順が準備中のため、現時点では実質Cloudflare前提

すでにCloudflareを使っていて、社内にエンジニアがいて、AIエージェントに社内システムを触らせる際の権限設計に悩んでいる組織であれば、いま検証を始める価値は十分にあります。一方で、SLAや日本語UIの完成度が調達要件に入る組織は、マネージド版の提供を待つ判断が合理的です。

次に読むなら、権限制御の前提となるMCPとは、実運用のリスク管理をまとめたAIエージェントのセキュリティ対策、他の選択肢を横並びで見たい場合はAIエージェントおすすめ比較が参考になります。

主な参照元

• Cloudflare公式ブログ「Cloudflare OS: an open platform for agents, apps, and work」https://blog.cloudflare.com/cloudflare-os/
• Cloudflare公式ブログ「How we're rethinking work at Cloudflare with Cloudflare OS」https://blog.cloudflare.com/how-we-use-ai-with-cloudflare-os/
• GitHub「cloudflare/cloudflare-os」https://github.com/cloudflare/cloudflare-os
• Cloudflare Developers「Dynamic Workers Pricing」https://developers.cloudflare.com/dynamic-workers/pricing/
• Cloudflare Developers「Workers Pricing」https://developers.cloudflare.com/workers/platform/pricing/