Cloudflare OSとは？アーキテクチャや機能、料金を徹底解説

Cloudflareが米国時間2026年8月4日、2026年5月から社内展開した初期版の知見を基に全面的に再構築したAIエージェント用ワークスペース「Cloudflare OS」をApache 2.0ライセンスでオープンソース公開しました（公式リポジトリには「heavy development」「many rough edges」のEarly Access版と明記されています）。

従来型のオペレーティングシステムではなく、ブラウザからチャットしながら文書・スライド・業務アプリを作成できる、企業のための「AI版の社内Windows」に近い位置づけの基盤です。

本記事では、Cloudflare OSの中核アーキテクチャ、実際にできること、料金と運用コスト、Microsoft CopilotやSalesforce Agentforceとの差分、そして導入で見落とされやすい観点までを2026年8月時点の最新情報で体系的に解説します。

Cloudflare OSとは？企業向けにOSS公開されたAIエージェントワークスペース

Cloudflare OSは、Cloudflareが米国時間2026年8月4日にApache 2.0で完全オープンソース公開した、企業向けAIエージェント用ワークスペースです。名前に「OS」と入りますが従来型OSではなく、ブラウザ上のチャット画面から自然言語で文書・スライド・業務アプリまで作れる基盤を指します。

Cloudflare OSの公式発表blog記事ヒーロー画像（出典：Cloudflare Blog）

正体をひと言でいうと、AIエージェントが企業データや業務システムを触りに行くための統制付きの実行環境です。

Microsoft Copilot・Salesforce Agentforce・ChatGPT EnterpriseなどのSaaS型エージェント基盤に対し、Cloudflare OSは「自社のCloudflareアカウントにデプロイして運用するOSS基盤」というポジションを取ります。

---

Cloudflare OSがオープンソースで出た背景と狙い

Cloudflare OSの発表を単発ニュースとして見ると「Cloudflareもエンタープライズ向けAIエージェントに参入した」で終わってしまいますが、実際には2つの文脈が重なった上での公開です。

1つは、10年前のOSSプロジェクト「Sandstorm.io」の設計思想がCloudflare Workers上で再実装されたこと。
もう1つは、Cloudflare自身が2026年春以降に発表してきた「Agent Cloud」戦略の集大成として位置づけられていることです。

10年前のSandstorm.io設計をWorkers上に再実装したもの

Cloudflare OSの設計を主導したのは、Workersの創始者としても知られるKenton Varda氏です。

同氏は発表当日、Xの投稿で「これは10年前に立ち上げた自分のスタートアップ Sandstorm.io のリメイクだ。今回はCloudflare Workersの上で作った」と明言しました。

Sandstormは2010年代半ばに提唱された「per-user grain（ユーザーごとの粒）」型サーバー設計で、マルチテナントSaaSではなくアプリのインスタンスをユーザーごとに切り分けるという思想が特徴でした。

OSSプロジェクトとしては数千台で利用された一方、製品の未完成さとエンタープライズ販売の難しさから事業としては成功しませんでしたが、Cloudflare Workersの軽量isolate実行モデル＋Durable Objectsの登場によって、この設計思想を経済的に成立させられるようになったというのがVarda氏の見立てです。

つまりCloudflare OSは「新しい思いつき」ではなく、10年間温められていた設計哲学を、Workersという実行基盤の進化によって実装可能な形に落とし込んだ製品と言えます。

設計上の意思決定（後述のGadgets・Gatekeepersの分離）に、その系譜が色濃く残ります。

Agent Cloud戦略の集大成——「一人ひとりが自分のエージェントを持つ」前提

Cloudflareは2026年4月のAgents Week 2026で、AIエージェント向けのコンピュート・ストレージ・セキュリティ基盤を一斉刷新しました。次世代Agents SDKのプレビュー、AI Gateway経由の統一推論レイヤー、AI Searchなどのプリミティブがそれです。

Cloudflare OSは、これらのプリミティブを「エンドユーザーが直接触れるアプリケーション層」としてまとめ上げたものです。

同社はcontainer-basedのアプローチはコストが重すぎるとして、多数のエージェントをオンデマンドで実行する用途にはWorkers isolateの軽量実行モデルが合うと説明しています。

Cloudflare自身は2026年5月からこの基盤の初期版を数千人の全社員に展開し、非エンジニアも含めて文書作成・スライド生成・繰り返し業務の自動化に日常的に使ってきました。今回のOSS版は、その初期版の知見を基に全面的に書き直したv2です。

「まずは自社で回してから外に出す」という順序が、Cloudflareがこの製品にコミットしていることの裏付けになっています。

---

Cloudflare OSの中核アーキテクチャ——Gadgets・Gatekeepers・Blueprints

Cloudflare OSは3つのプリミティブで組み立てられています。それぞれが「per-user隔離」「外部連携の統制」「アプリの共有と再利用」という別々の課題を担当します。

以下の表で、3つのプリミティブの役割を整理しました。

プリミティブ	役割	実装
Gadgets	ユーザーごと専用のアプリインスタンス	Dynamic Worker＋Durable Object Facet＋SQLite
Gatekeepers	外部SaaS/APIとの仲介と統制	サービス固有のCloudflare Worker
Blueprints	Gadgetsのテンプレート化と共有	フォーク可能な公開レシピ

それぞれをもう少し具体的に見ていきます。

Gadgets——ユーザーごとに走る「自分専用アプリ」

Gadgetは、ユーザーがCloudflare OSでアプリを立ち上げた瞬間に生成される、その人だけのアプリインスタンスです。

エージェントが「スライド作成アプリを作って」と指示されたとき、共有SaaSのAPIを呼びに行くのではなく、そのユーザー専用のスライドアプリWorkerを新規に生成します。

Gadgetの内部構造：Agent session／Browser client → Cap'n Web RPC → Application API → APP SERVER（Dynamic Worker + Durable Object Facet + SQLite）＋型付きリソースバインディング（出典：Cloudflare Blog）

設計の核となる考え方が、図の中央に「ONE SURFACE — whatever the UI can do, the agent can do」と書かれた部分です。

UIとエージェントが同じApplication API（例：app.listIssues関数で完了済みIssueを取得）を利用するため、UIで行える操作をエージェントも実行できるように設計されています。

内部的にはCloudflare Workers上のDynamic WorkerとDurable Object Facetで実装され、各Gadgetは専用のSQLiteデータベースを持ちます。
デフォルトではアウトバウンドネットワークが無効化されており、外部インターネット・社内システムには一切アクセスできません。クライアント側はサンドボックスiframe内で動き、親フレームとはpostMessage APIとオープンソースRPCのCap'n Webで通信します。

この設計の実務的な意味は大きく2つあります。1つはバグや悪意あるコードが1つのGadgetに閉じ、他のユーザーや他のGadgetに波及しないこと。
もう1つは、各ユーザーが自分のGadgetを自由に改造しても他人に影響しないことです。

標準ではユーザー別のインスタンスですが、共有アプリでは同じ状態を複数人で共同利用することもできます。

Gatekeepers——外部API接続の「門番」

Gatekeeperは、Cloudflare OSと外部SaaS（GitHub・Notion・Slack・Confluence・Google・Supabase・Home Assistant等）の間に立つ、サービス固有のWorkerです。

OAuth認証情報を保持し、エージェントに渡すのは限定的なTypeScript APIのみで、認証キーそのものはエージェントコードには一切触れません。

Gatekeeper動作フロー：Agent or app → typed RPC capability → GATEKEEPER（Read／Action）→ System of record、Actionは人間の approve or reject を挟む（出典：Cloudflare Blog）

Gatekeeperの中身はRead側（authorize the resource／call the service／record an observation）とAction側（enforce policy／simulate the result／queue for approval／apply once approved）の2ブロックに明確に分かれます。読み取りは黙って通し、書き込みは人間承認を挟める——SaaSのSSO/RBACとは違う軸で、Read/Actionの粒度で権限を分割する設計です。

Gatekeeperの制御粒度は「アカウント全体への読み書き権限」ではなく、たとえば「特定リポジトリのIssueだけ読める」「ソースコードは触らせない」「特定フィールドをマスキング」「秒あたりN回に制限」「書き込みは人間承認が必要」といったレベルまで絞り込めます。全ての読み取り操作はGatekeeperがログに記録し、ダッシュボードや業務アプリが他のユーザーに共有されたときも、「その閲覧者は元データへのアクセス権を持つか？」を再検証する材料になります。

特徴的なのは書き込み系操作の扱い方です。

エージェントが承認を必要とするアクション（GitHubのマージ、Slackのメッセージ送信など）を実行すると、Gatekeeperは結果をローカルでシミュレーションし、エージェントには「完了した」と返答して次のタスクに進ませます。

エージェントが結果を再度読み取ろうとすれば、シミュレーション結果が返ります。全タスクが終わった後、ユーザーが実際の書き込みを一括承認・却下する運用です。

これは「1操作ごとに人間確認」でも「全自動承認」でもない中間の設計で、エージェントの実行スピードと人間側の統制の両立を狙ったものです。

Blueprints——他人のGadgetを「フォーク」して自分専用にする

Blueprintは、あるユーザーが作ったGadgetを他のユーザーが独立コピーとして受け取れる仕組みです。GitHubのforkに近い概念で、テンプレート化されたアプリを取り込み、自分の環境で自由に改造できます。

Blueprintの2つの共有モード：SHARE THE APP（ONE APP・ONE STATE：共有DBで共同編集）と SHARE A BLUEPRINT（code and structure only：Team A／Team Bで独立コピー）（出典：Cloudflare Blog）

Cloudflare OSには「同じアプリを複数人でライブ編集する」ルートと「設計だけ共有して各チームが独立コピーを持つ」ルートの2つが用意されています。左のSHARE THE APPは1つのSQLiteデータベースを共有してSaaS的に協働し、右のSHARE A BLUEPRINTはcode and structure onlyだけを渡してTeam A・Team Bが独立の状態とリソースを持ちGitHub forkのように分岐します。用途に応じてこの2軸を使い分ける前提です。

チームAが作った「議事録作成アプリ」を、チームBが自分たち仕様に改造して使う、といった運用が想定されます。共有SaaSと違い、Blueprint配布元がアップデートしても自分のフォーク版には影響しないため、勝手にUIが変わったり機能が消えたりしません。

ただしこの設計は同時にリスクも生みます。詳
細は後述の「導入で見落とされやすい観点」で扱いますが、フォーク版が組織内に散在すると「どのバージョンが正式版か分からない」というSharePoint的なガバナンス問題に発展しかねません。

設計思想としては「per-user freedom > 中央集権的統制」を優先しているため、運用側で意図的にBlueprintの棚卸しルールを設ける必要があります。

監査ログとCap'n Web——「エージェントが何を見たか」を追跡する土台

Cloudflare OSは、エージェントが読み取ったリソースを全て記録する監査ログを標準装備しています。

この記録は、エージェントが生成した成果物（ダッシュボード・スライドなど）がその後どこに流れても付いて回り、「別のユーザーがこの成果物を開いたとき、そのユーザーは元データへのアクセス権を持っているか」をGatekeeperが判定する材料になります。

エージェントの観測ログはワークスペースに付随し、成果物を別ユーザーが閲覧要求したときWarehouse／GitHub／Calendarの各Gatekeeperが「CAN THEY READ IT?」を再検証してAllow or denyを返す（出典：Cloudflare Blog）

たとえばAGENT WORKSPACEがrevenue table（Warehouse）・support tickets（GitHub）・team calendar（Calendar）の3つを読んで作った成果物を、別のユーザーが開こうとしたとします。

その瞬間、3つのGatekeeperが同時に「その人はこのリソースを読めるか？」を判定し、1つでもNoならAllow or denyの結果として拒否されます。観測はエージェントとその成果物に紐づいて残り続けるため、共有先が変わるたびに毎回再検証が入るのがこの仕組みの核です。

内部通信はCap'n Webというオープンソースのobject-capability RPCが担い、能力ベースアクセス制御（capability-based access control）を実現しています。

デフォルトで全アクセス拒否、明示的に渡された能力だけ使えるという原則が、GadgetとGatekeeperの両方で貫かれています。

---

Cloudflare OSでできることと使い方

Cloudflare OSはOSSなので、自社のCloudflareアカウントにデプロイして触るのが最短ルートです。試すだけならローカルPCでも動きます。

本セクションでは、実際にできる業務パターンとデプロイの流れを整理します。

Cloudflare OSでできる代表的な業務

エンジニア以外の従業員が非技術的な業務でも使えるよう設計されており、代表的なユースケースは以下の通りです。

Cloudflare OSのブラウザ画面：中央のチャット欄「What are we working on?」からタスクを依頼し、左サイドバーのWorkspaces・Blueprints・Outputs・Scheduled・Context & Skillsで作成物を管理する（出典：Cloudflare Blog）

画面右下のGet Startedには「Prep for a 1:1」「Find insights in my data」「Automate a workflow」「Build a quick tool」など、初回ユーザーが最初に触るためのタスクテンプレが並んでいます。「どこから触ればいいか」がテンプレとして提示されているので、非技術者でも自然言語で1行書けば動き出せる設計です。この画面から次のようなユースケースが展開されます。

• 文書・スライド・スプレッドシートの生成
  自然言語で「今月の売上サマリのスライドを作って」と指示すると、Gatekeeper経由で社内データを引き、その場でGadgetを生成する。
  
  

• 社内データの検索と要約
  社内ドキュメント全量をLLMに突っ込むのではなく、Gadget内でコード実行して必要な部分だけ絞り込む設計。トークン消費と機密漏洩の両方を抑える。
  
  

• 繰り返し業務の自動化
  スケジュール実行（毎朝9時に売上レポート）や社内システムのイベント（Slack投稿・GitHub PR）をトリガーにしたワークフロー。
  
  

• チーム向け小規模アプリの構築
  「案件進捗ボード」「顧客問合せ要約」など、SaaS導入するほどではない業務用ミニアプリをBlueprintで配布する。
  
  

• MCPサーバーとの接続
  Model Context Protocol対応のツール群をGadgetから呼び出せる。外部SaaSはGatekeeper経由、MCPはネイティブ対応、と役割が分かれる。

いずれも「1つの巨大なSaaSに全社の生産性を委ねる」のではなく、各ユーザーが小回りの効くアプリを組み立てて回すことが前提の運用です。

前提条件——Cloudflareアカウントとpnpm

Cloudflare OSを動かすには、以下のいずれかを準備します。

• Cloudflareアカウント経由でデプロイする場合：Cloudflare Workersが有効なアカウント（Paidプラン推奨、後述）
• 完全ローカルで試す場合：Node.js＋pnpm、Cloudflareのworkerdランタイム

公式スターターが有効化する主なリソースは、Workers・Durable Objects・Dynamic Worker Loaders・KV・R2・Browser Renderingです。

高度な機能（Dynamic Workers・Durable Object Facets等）はCloudflare Workersの有料プランが必要になるため、社内での本格利用を目指すならPaidプラン契約が現実的なスタートラインです。

デプロイ手順——1クリックとローカル実行の2ルート

Cloudflare OSの立ち上げは大きく2ルート用意されています。

以下の表で、それぞれの起動フローを整理しました。

ルート	コマンド／URL	所要時間の目安	用途
1クリックデプロイ	os.cloudflare.app/deploy	数分	自社Cloudflareアカウントに即時展開
スターターリポジトリ	cloudflare/cloudflare-os-starter	10〜30分	独自カスタマイズを前提とした展開
ローカル実行	pnpm run-local → localhost:8787	数分	個人検証・触ってみる用途
開発モード	pnpm dev-server ＋ pnpm dev-client → localhost:3000	数分	Gadgets・Gatekeepersを改造する開発用途

初回検証で機能感触を掴むなら、まずはローカル実行で動かしてみるのが軽量です。組織内での検証環境へのデプロイは1クリックデプロイでCloudflareのグローバルネットワーク上に立ち上げ、Gatekeeperを1本ずつ足しながら統合していく流れになります。

workerd上で完全ローカル運用も可能

Cloudflare OSは、Cloudflareのマネージド環境だけでなく、workerdというOSSランタイム上でも完全に動作するよう設計されています。理論上はCloudflareに依存せず、自社のオンプレミスサーバやKubernetes環境で運用することも可能です。

ただし現時点で「workerd上でのサーバ構築ガイド」は公式ドキュメントとして未整備で、READMEには「近日公開予定」と記載されています。

オンプレ運用を本気で検討するなら、ドキュメント整備を待つか実装パートナーと協業する現実的判断が必要です。

---

Cloudflare OSの料金と運用コスト構造

ソフトウェア本体は無料、実運用は5リソースの従量課金

Cloudflare OS自体はApache 2.0ライセンスのOSSなので、ソフトウェアライセンス料は0円です。ただし実運用時のインフラコストは別途発生します。

コスト構造の主なコスト項目は「Cloudflare Workers Paidプラン（固定）＋Dynamic Workers作成数＋Durable Objects＋KV／R2／Browser Rendering＋AI Gateway経由の推論コスト」に分かれます。

以下の表で、想定されるコスト項目と2026年8月時点の単価を整理しました。

コスト項目	単価（2026年8月時点）	備考
Cloudflare Workers Paid Plan	$5/月〜（アカウント最低料金）	10Mリクエスト＋30M CPUミリ秒/月を含む
Dynamic Workers 作成数	月1,000件まで無料、超過分は1 Dynamic Workerあたり$0.002/日	Worker IDとコードの組み合わせを日ごとにカウント。Blueprintフォーク多発で膨らむ
Durable Objects リクエスト	$0.15/M requests	有料プランは1M requests/月まで無料
Durable Objects 稼働時間	duration課金	有料プランは400K GB-s/月まで無料
Durable Objects SQLite ストレージ	従量課金	2026年1月より本格請求開始。無料枠あり
Workers KV	リクエスト・ストレージの従量課金（Free枠あり）	Gatekeeperやアプリ設定の永続化に使用
R2 ストレージ	保存量とオペレーション数の従量課金（Egressは無料）	生成成果物・添付ファイルの保管に使用
Browser Rendering	実行時間ベースの従量課金（Free枠あり）	Webページのスクリーンショット・HTML→PDF等の操作に使用
AI Gateway経由の推論	コア機能は無料、BYOKは各LLMプロバイダーへ直接支払い、Unified Billingはクレジット購入額に5%手数料	Guardrails・Logpushは条件付き別料金

この表から読み取れる実務的なポイントは、ソフトウェアは無料でも動かすなら最低月$5＋各リソースの利用量に応じた従量課金が発生するという構造です。

日ごとのユニークDynamic Worker数・Durable Objectsのリクエストと稼働時間・SQLiteストレージ・推論トークン量がそれぞれ独立して課金されるため、全社導入時はBlueprintフォーク多発による日次ユニークDynamic Workerの推移も含めて試算する必要があります。

AI Gatewayによる推論コスト制御

AI Gateway経由の推論コスト制御：全モデル呼び出しに identity check／budget apply／cache serve／model choose／error fallback を挟み、Frontier／Balanced／Smallの3階層モデルを使い分ける（出典：Cloudflare Blog）

AI Gatewayは、全モデル呼び出しに次の5段階のチェックを挟み込みます。

• check identity：誰が呼んだか
• apply the budget：予算内か
• serve from cache：前回結果を再利用できるか
• choose the model：Frontier／Balanced／Smallのどれを使うか
• fall back on error：別モデルへの切り替え

この5段階のうち「choose the model」で選ばれる3階層モデルは次のとおりです。

• Frontier model：最も難しい推論に投入する高精度モデル
• Balanced model：多くの日常業務を担う標準モデル
• Small model：高頻度・低コストで捌く軽量モデル

1つの入口から3階層を使い分けられるため、業務の難易度に応じて推論コストを最適化できます。

推論コストはAI Gateway経由で複数プロバイダー（OpenAI・Anthropic・Google等）を切り替え可能で、AI Gateway側でモデルルーティングを構成でき、管理者が予算上限・レート制限を設定できます。「エージェントがコスト意識なく高額モデルを回し続ける」問題への対策は、初期設計で組み込まれている点は評価ポイントです。

ユーザー数課金型SaaSとの棲み分け

Microsoft 365 Copilot（$30/user/月・年払いかつ対象M365ライセンス別要）やChatGPT Enterprise（要相談）と比べると、Cloudflare OSはユーザー数ではなく利用量課金に振れているため、少人数で重い処理を回す組織と、大人数で軽い処理を回す組織で有利不利が分かれます。次のセクションで、そのあたりの棲み分けを整理します。

---

主要エージェント基盤との比較

Cloudflare OSは、既存のエンタープライズAIエージェント基盤とはっきり違う戦略を取っています。

判断軸を整理しないと「なんとなくCloudflareで良さそう」で選んで後で困るので、代表3製品との差分を見ていきます。

Microsoft Copilot

Microsoft Copilot Studioは、Microsoft 365テナント・Microsoft Entra ID・SharePoint・Power Automate・TeamsといったMicrosoftエコシステム全体との深い統合を武器にしたエージェント基盤です。Ignite 2025で発表された「Agent 365」は、企業のエージェント群を一元管理するコントロールプレーンとして拡張が続いています。

Cloudflare OSは真逆で、Microsoft 365のような統合済み業務スイートは備えず、Cloudflareの各基盤（D1・KV・R2・Cloudflare Access等）とGatekeeperを組み合わせて構築する必要がある設計です。M365・SharePoint・Teamsの中で完結する会社なら、Copilot Studioの方が明らかに近道になります。

逆に言えば、Microsoft依存を避けたい・複数クラウドを混在させたい・OSSで中身を確認したい組織にとってはCloudflare OSが選択肢に入ってきます。両者は運用モデルが異なり単純な置き換えにはなりにくいため、並行運用で「M365領域はCopilot、それ以外の横断業務はCloudflare OS」という棲み分けが現実的です。

OpenAI ChatGPT Enterprise

ChatGPT Enterpriseは、OpenAIが直接運用するSaaS型AIワークスペースです。SSO・SCIM・利用分析ダッシュボード・Compliance APIといった運用機能は揃っていますが、OSSのCloudflare OSと比べると基盤内部の実装レベルの可視性や改変自由度は限定される位置づけになります。

Cloudflare OSは対照的に、Workers実行環境が自社Cloudflareアカウントにデプロイされる構造です（モデル推論はAI Gateway経由で外部プロバイダーを利用する場合があります）。

Gatekeeperが記録した読み取り内容や、エージェント／アプリが参照したリソースを自社側で追跡できます。監査要件が厳しい業界（金融・医療・公共）で、実装レベルまで踏み込んで内部挙動を確認したい組織にとってはCloudflare OSの透明性が魅力になります。

ただしトレードオフとして、Gatekeeper構成・アップデート追随・監視・Gadgetの棚卸しといった運用責任は自社側に来ます。Workers自体はCloudflareがマネージド提供しているのでインフラのスケーリング責任はありませんが、Cloudflare OSレイヤーの構築と運用は自前です。

「ChatGPT Enterpriseはお金で問題解決、Cloudflare OSは技術で問題解決」というのが実務的な整理で、専任SREがいる組織向けの選択肢と考えるのが自然です。

Salesforce Agentforce

Salesforce Agentforceは、Salesforce CRM・Data Cloudを起点にした業務エージェント基盤で、営業・カスタマーサポート・マーケティング領域の業務プロセスに特化しています。

Salesforceが持つ顧客データ・オブジェクトモデル・ワークフローエンジンをそのままエージェントに接続できる強みがあります。

Cloudflare OSはCRMや業務プロセスを持たない代わりに、APIやMCPで連携可能な多様な社内システムに繋ぐための汎用Gatekeeper基盤を提供します。

Agentforceが「Salesforce領域の縦の深さ」を取るなら、Cloudflare OSは「システム横断の広さ」を取る戦略です。Salesforce依存が強い会社はAgentforce、Salesforce・自社DB・Notion・GitHub等を横断したい会社はCloudflare OS、という切り分けになります。

Cloudflareが持たないもの——ハイパースケーラーとの差の正体

Cloudflareの強みは330都市以上に広がるエッジネットワークと軽量なWorker実行モデルですが、Cloudflare単体ではMicrosoft 365やGoogle Workspaceに相当する統合済み業務スイートを備えず、CloudflareのD1（マネージドDB）・KV・R2・Cloudflare AccessをGatekeeperと組み合わせて自社で組み立てる構成になります。

これは弱点ではなく戦略的な選択で、Cloudflareはcontainer型のエージェント実行は重すぎるという前提で、多数のエージェントをオンデマンドで実行する用途にWorkers isolate中心の設計を賭けています。

ただし、既存の重厚な業務システムをそのままエージェントに繋ぎたい組織にとっては、ハイパースケーラー系プラットフォームの方が導入摩擦が小さい場面が多いのが現実です。

---

Cloudflare OS導入で見落とされやすい観点

ここまでの機能・料金・比較を見て「良さそうだから試す」と決めた後、実運用で詰まりやすい論点が3つあります。導入判断の最終局面で押さえておくべき観点を整理します。

実質Cloudflareエコシステム前提のロックイン

Cloudflare OSはApache 2.0のOSSですが、実質的にはCloudflare WorkersのDynamic Workers・Durable Object Facetsといった独自プリミティブに強く依存しています。

理論上はworkerdランタイムで自己ホスト可能とはいえ、公式ドキュメントは未整備で、公式資料ではオンプレミス運用事例はまだ紹介されていません。

つまり「OSSだからベンダーロックインしない」という単純な結論にはならず、Cloudflareエコシステム内でのロックインは前提として受け入れる必要があります。AWS・Azure・GCPと横並びで「クラウドベンダー選定」の枠で議論すべき対象と捉えるのが正しい構えです。

ロックインを許容できるかは、既存のCDN・DNS・セキュリティ基盤がどのベンダーに寄っているかで決まります。Cloudflareに一元化する方針が既にある組織なら追加リスクは小さい一方、AWS中心の組織がCloudflare OSだけ導入する場合は運用チームのスキル分散にも注意が必要です。

Blueprintのfork散在が生む「SharePoint問題」

Blueprintは「他人のGadgetを自由にコピーして自分仕様に改造できる」ため、社内展開が進むと同じ目的のGadgetが複数バージョン並立する状況が発生します。「営業チームAの案件管理アプリ」「営業チームBが少し改造した版」「新人が触って壊した版」が同時に存在し、どれが公式版か分からなくなるパターンです。

これはSharePoint・共有Notion・Excel共有フォルダで長年繰り返されてきた問題と同型で、Cloudflare OSの設計思想（per-user freedom優先）がむしろこの問題を助長する方向に働きます。
技術で解決するのは難しく、組織側でBlueprint運用ルール（公式版のマーク・棚卸し頻度・改造版の命名規則）を設けることが実務的な対策です。

導入初期は「便利だから広げよう」の勢いで進みますが、6か月後・1年後に振り返って「うちのCloudflare OSに何個Gadgetがあるか誰も把握してない」状態に陥らないよう、統制の設計を最初から入れることを推奨します。

マネージド版待ちと実装パートナー活用の現実解

Cloudflareは「近い将来、Cloudflare OSのマネージド版オプションも提供予定」とプレスリリースで示唆していますが、現時点では自社運用が前提です。全社展開レベルで動かすには、Gatekeeperの追加開発・監査ログ設計・SSO統合・障害対応まで自社SREが引き受けることになります。

現実的な導入経路として、Cloudflareが公式実装パートナーに指名しているPresidio・Happy Cogといったグローバルパートナーの活用が視野に入ります。特に「まずPoCを回して価値検証したい」段階では、パートナー経由でGatekeeperのカスタム開発と初期構築を巻き取ってもらう方が、社内エンジニアリング工数を圧迫しません。

もう1つの現実解は「Cloudflare OSの立ち上げは待って、他のエージェント基盤で先に業務を回しておく」戦略です。

マネージド版の提供時期は公式には未発表（プレスリリースは「soon」とのみ記載）ですが、その間の空白をMicrosoft Copilot Studioや自社統合ダッシュボード型のAI Agent Hubで埋めておき、Cloudflare OSは正式マネージド版が出たタイミングで再評価する、というのがAI総研の支援現場で現実的に取られている選択肢です。

---

Cloudflare OS等の基盤選定と並行して業務Agentを立ち上げるなら

Cloudflare OS・Microsoft Copilot Studio・Salesforce AgentforceのようなAIエージェント基盤の選定・比較は数か月〜1年単位で続きますが、その間も業務側のAgent化は先に進められます。基盤本体の選定と並行して、既存の業務システムとつなぐAgent群を先に立ち上げておけば、基盤が確定した段階で実行層だけ差し替える構造にできます。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、複数のAI基盤・LLMを業務ワークフローに組み込む実行基盤として機能します。

• 基盤選定を待たず業務Agentを先行構築
  Cloudflare OS・Copilot Studio・Agentforceの評価が進行中でも、Teamsから使える業務Agentを先に立ち上げてROIを計測できます。
  
  
• 基盤世代交代を吸収する業務組み込み層
  将来Cloudflare OS等に基盤を切り替えても、業務Agent側の設計は不変。特定ベンダー依存のワークフロー陥落を回避できます。
  
  
• 使い慣れたMicrosoft環境をそのまま活用
  Teams・Excel・Outlookなど既存ツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  
• データは100%自社テナント内に保持
  Azure Managed Applicationsとして自社テナント内で動作が完結。エージェント基盤にどれを選ぶ場合も業務データの往来を管理レイヤーで制御できます。

AI総合研究所の専任チームが、AI基盤の選定支援からAIエージェント基盤の本番運用まで一貫して伴走支援します。AI Agent Hubのサービスページで、業務Agentを先行構築する実行基盤の全体像をご確認ください。

---

まとめ

本記事では、Cloudflare OSについて、中核アーキテクチャ・実際にできること・料金と運用コスト・Microsoft Copilot/Salesforce Agentforceとの違い・導入で見落とされやすい観点までを、2026年8月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• Cloudflare OSはCloudflare Workers上で動くOSSのAIエージェントワークスペースで、Gadgets（ユーザーごと専用アプリ）・Gatekeepers（外部API仲介）・Blueprints（フォーク可能なテンプレ）の3層構造で提供される
• OSS本体は無料、実運用はWorkers Paid $5/月〜+Dynamic Workers・Durable Objects・KV・R2・Browser Rendering+AI Gateway経由の推論コストが積み上がる従量モデル
• Microsoft Copilot Studio/ChatGPT Enterprise/Salesforce Agentforceとは「マネージド統合型基盤 vs OSS+エッジ実行」で戦略が異なり、マネージド版未提供のためPresidio・Happy Cog等の実装パートナー活用が現実解
  
  

Cloudflare OSは魅力的な設計思想を持ちますが、現時点では自社で立ち上げて回せるエンジニアリング体力がある組織向けの選択肢です。マネージド版が出るまでは、Copilot・自社統合基盤と組み合わせながら評価するのが現実的な進め方で、まずはPresidio等の実装パートナーと1業務のPoCから始めるのが失敗の少ないルートになります。