Cloudflare OSとは|オープンソースのAIエージェント・ワークスペースを徹底解説【仕組み・Gatekeeper・自社ホスト・料金】
Cloudflareが2026年8月5日にオープンソース公開したAIエージェント・ワークスペース「Cloudflare OS」を解説。ゼロ権限から始まるGatekeeperセキュリティ、AI Gatewayによるモデル選択とコスト管理、Gadget(小さな自作アプリ)、自社のCloudflareアカウントへのデプロイ手順、料金までを公式ブログとGitHubの記載にもとづいてまとめました。

図の引用元: Cloudflare Blog「Cloudflare OS: an open platform for agents, apps, and work」。本記事に掲載した図・画面はすべて Cloudflare 公式サイトより引用しています。
Cloudflare は2026年8月5日、同社の年次イベント「Agents Week」に合わせて、AIエージェントのための業務ワークスペース Cloudflare OS を オープンソース(Apache License 2.0)で公開しました。ChatGPT のような汎用チャットとは異なり、「自社の業務・用語・社内システムを前提に動く」ことを目的に設計されており、しかも 自社の Cloudflare アカウントの中で丸ごと動かせる(自社ホストできる)のが最大の特徴です。
もともとは Cloudflare が自社の全社員向けに作った社内ツールでした。2026年5月に社内へ初版を配布し、8月時点ではエンジニアに限らず数千人の従業員が毎日、ドキュメント作成・スライド作成・定型業務の自動化・小さな社内アプリづくりに使っているといいます。それをそのまま外部へ開放したのが Cloudflare OS です。
本記事では、Cloudflare OS とは何か、3つの構成要素(エージェント・ワークスペース/Gadget/Gatekeeper)、「ゼロ権限」から始まるセキュリティモデル、AI Gateway によるモデル選択とコスト管理、そして自社の Cloudflare アカウントにデプロイする手順と料金までを、公式ブログと GitHub リポジトリの記載にもとづいて解説します。
Cloudflare OSとは
Cloudflare OS は、「社内の誰もがアプリを作り、仕事を自動化し、社内システムへ安全にアクセスできる」ことを掲げた、オープンソースのAIエージェント・ワークスペースです。エンジニアでなくてもブラウザから使え、開発チームやIT部門を待たずに、調査・資料作成・ワークフロー自動化・簡単な業務アプリづくりまでを自分で完結できます。
ポイントは、単なるチャットボットではなく「会社の文脈」と「社内システムへのアクセス」を組み込んだ実行基盤である点です。汎用AIのように毎回コンテキストを説明し直す必要がなく、自社の手順・データ・権限の上でエージェントが動きます。
- ブラウザだけで完結: ターミナルや開発知識は不要。非エンジニアでも研究・文書化・自動化ができます。
- 成果物がそのままアプリになる: 出力した資料やダッシュボードを、UI・ロジック・状態を持つ本物のアプリ(Gadget)に昇格できます。
- ゼロ権限から始まる安全設計: エージェントもアプリも「最初は何にもアクセスできない」状態から始まり、必要な範囲だけを明示的に付与します。
- モデル非依存: どのAIモデルを使うかは組織が選べます。特定ベンダーへのロックインを避けられます。
- 自社ホスト・オープンソース: 自社の Cloudflare アカウント上で動くため、業務プロセスや社内連携がベンダー製品に閉じ込められません。
「OS」を名乗るのは比喩ではありません。 Cloudflare OS はソフトウェアの構造そのものをOSになぞらえて作られています。中核ロジック(workshop-backend)がカーネル、画面(workshop-frontend)がシェル、外部サービスへの接続部(gatekeeper-*)がデバイスドライバーにあたる、という設計です。後述の Gatekeeper は、まさに「社内システムというハードウェアを安全に叩くためのドライバー」として理解すると分かりやすくなります。
Cloudflare OSの3つの構成要素
Cloudflare OS は、大きく3つの要素で成り立っています。
- エージェント・ワークスペース — 会社の文脈とスキルを前提に動くチャットUI
- Gadget(ガジェット) — エージェントが作る「小さな自作アプリ」と、その共有の仕組み
- Gatekeeper(ゲートキーパー) — エージェントとアプリの両方に効くセキュリティの枠組み
順に見ていきます。
1. エージェント・ワークスペース

引用元: Cloudflare Blog「Cloudflare OS」 のデモより
会話UIから、自社の文脈にもとづいて次のような作業を指示できます。
- 調査・分析: エージェントがコードを書いて検索・絞り込み・集計を行うため、巨大なデータセットをまるごとコンテキストに読み込ませる必要がありません。
- 資料作成: ドキュメント・スライド・スプレッドシートを、ライブデータに接続したまま生成し、Google Drive などへ書き出せます。
- チームで使えるアプリ化: UI・ロジック・状態を備えたフルスタックのアプリをその場で立ち上げられます。
- 決め打ちのワークフロー: 手順が決まっている部分はコードで確定的に実行し、判断が要る部分だけAIに任せる、といった組み合わせができます。
画面右下ではタスクごとに使用モデルを切り替えられ、消費トークンと概算コストがその場で表示されます。これは後述の AI Gateway と連動した仕組みです。
2. Gadget(小さな自作アプリ)
Cloudflare OS では、エージェントの出力ひとつひとつがアプリになり得ます。エージェントが生成するアプリは、UIを描画するクライアントコードと、状態や振る舞いを持つサーバーコードの両方を含むフルスタック構成です。これを Cloudflare では Gadget と呼びます。
共有のしかたは2通りあります。
- アプリそのものを共有: 状態を共有したまま、リアルタイムに共同作業できます(マルチプレイヤー)。
- ブループリント(設計図)として共有: 受け取った人が、自分専用の状態と認証情報を持つ独立したコピーを作れます。
機能追加を「要望として起票して待つ」のではなく、その場でAIに頼んで改造できるのがGadgetの発想です。エンジニアでない人が作った小さな業務アプリを、同僚がコピーして自分用に手直しする、といった使い方が想定されています。
3. Gatekeeper(セキュリティの枠組み)
Gatekeeper は Cloudflare OS の心臓部です。詳しくは次章で解説します。
Gatekeeper|「ゼロ権限」から始まるセキュリティ
Cloudflare OS のセキュリティ思想は、ひと言でいえば 「すべてのエージェントとアプリは、最初は何にもアクセスできない(access to nothing)」です。必要なアクセスだけを、あとから明示的に、しかも細かく渡していきます。
その要となるのが Gatekeeper — Cloudflare OS と外部サービスのあいだに挟まる、サービスごとの Cloudflare Workerです。エージェントに認証情報を直接渡すのではなく、Gatekeeper が代わりに認証情報(OAuthトークンなど)を保持し、エージェントには限定されたTypeScript APIだけを見せます。
Gatekeeperで何ができるか
たとえば GitHub との連携でも、アカウント全体を渡すのではなく、次のように絞り込めます。
| やりたいこと | Gatekeeper での制御例 |
|---|---|
| リポジトリの限定 | 特定の1リポジトリにだけアクセスを許可 |
| 読み取り範囲の限定 | Issue は読めるがソースコードは読めない、など |
| 項目のマスキング | 特定フィールド(個人情報など)を隠して渡す |
| 流量の制限 | レート制限をかける |
| 人間による承認 | Pull Request の作成には人の承認を必須にする |
エージェントから見えるのは「生のAPIキー」ではなく、次のようなタイプ付きの能力(capability)です。アクセスは環境に暗黙的に存在するのではなく、明示的に「渡された」ものだけが使えます。
// エージェント/アプリに渡されるのは、生の認証情報ではなく
// Gatekeeper が公開する限定APIだけ
const issues = await env.PROJECT.listIssues({
teamId: "ENG",
state: "open",
});
「見たもの」に応じてふるまいを縛る(観測ログ)
Gatekeeper のもう一つの特徴が 観測ログ(observation log)にもとづくポリシーです。エージェントが「何を見たか」を記録し、それに応じて後続の操作を制限します。
公式が挙げる例では、機微なデータを一度でも読むと、そのエージェントは特定の宛先へのデータ書き込み・新しい共同編集者の招待・別エージェントへの作業引き継ぎ・外部へのリクエスト送信ができなくなる、といった制御がかかります。たとえば「機密のデータウェアハウス表を読んでライブ・ダッシュボードを作った」場合、そのダッシュボードを権限のない相手へ共有しようとすると、観測ログにもとづいてブロックされます。最終成果物に機密が「書いてあるか」ではなく、エージェントが「何を見たか」で判断されるのがポイントです。
ネットワークも既定で閉じています。 サーバーコードは global outbound networking disabled(外向き通信オフ)の Dynamic Workers 上で動き、クライアントコードはサンドボックス化されたブラウザのフレーム内で動きます。どちらも、明示的に付与された能力(capability)を通してしか外部へ到達できません。「うっかり社外へデータを送ってしまう」経路自体が塞がれている、という設計です。
なぜ「OS」なのか|アーキテクチャ
Cloudflare OS は、Cloudflare 自身のインフラ(Workers)の上に構築されています。名前のとおり、構造がOSになぞらえられています。
- ワークスペース = Durable Object: 各ワークスペースは1つの Durable Object として動きます。
- Gadget = Dynamic Worker の Facet: 各アプリは Dynamic Worker の「Facet」として起動し、Cloudflare OS 本体とは分離された、自分専用の SQLite データベースを持ちます。サーバーを立てずに、独立したアプリのインスタンスをいくつも動かせます。
- クライアントとサーバーの通信 = Cap'n Web: Cloudflare がオープンソースで公開している、ケーパビリティ・ベースのRPC(Cap'n Web)を使います。ブラウザからでもエージェントからでも同じメソッド呼び出しで扱えるのが特徴です。
// ブラウザからでもエージェントからでも、同じ書き方で呼べる
const issues = await app.listIssues({
status: "done",
});
リポジトリ上の構成も、OSのメタファーで整理されています。
| パッケージ | OSでの役割 | 内容 |
|---|---|---|
workshop-backend | カーネル | 中核ロジック |
workshop-frontend | シェル | 画面(UI) |
gatekeeper-* | デバイスドライバー | 外部サービスごとの接続部 |
ランタイムには Cloudflare のオープンソース Workers ランタイム workerd が使われており、自前のサーバー上で動かす(完全自己ホスト)ことも視野に入っています(ただし後述のとおり、この経路は現時点では実験的です)。エディタ表示に Monaco、クライアントとエージェントの同期・履歴再生に Yjs を使うなど、既存のオープンソース資産の上に組み上げられています。
AI Gateway|モデル選択とコスト管理

引用元: Cloudflare Blog「Cloudflare OS」 のデモより
Cloudflare OS のAI推論はすべて Cloudflare AI Gateway を経由します。これにより「どのモデルを使うか」を組織側で完全にコントロールできます。
- Bring Your Own Model: どのモデルプロバイダーを使うかを組織が選べます。特定ベンダーへのロックインがありません。
- タスクに応じたルーティング: メールの要約のような軽い作業は安価な軽量モデルへ、複雑な分析はフロンティアモデルへ、と使い分けられます。
- コストの帰属: すべてのリクエストを、個人・チーム・ワークスペース単位で計上できます。
- 予算とレート制限: 管理者は予算・レート制限を設定し、上限超過時の挙動まで定義できます。
上のデモ画面のように、ワークスペースごとに Claude Opus 5 / GPT 5.6 Sol / GLM 5.2 / Kimi K2.7 といった異なるモデルを選び、それぞれの消費トークンと概算コストがその場で可視化されます。「誰が・どのアプリで・いくら使ったか」が最初から見える設計です。
この「単一ベンダーに縛られずモデルを選ぶ」という発想は、複数モデルを束ねて提供する Sakana Fugu の解説記事 や、主要フロンティアモデルの比較記事 とも通じるテーマです。
使い方|自社のCloudflareアカウントにデプロイする
Cloudflare OS はオープンソースで、GitHub の cloudflare/cloudflare-os で公開されています。関連して、Cloudflare 社内の構成を反映したサンプル cloudflare-os-starter も提供されています。
ローカルで動かす
前提は pnpm が入っていることだけです。次の1コマンドでローカル起動できます。
pnpm run-local
# → http://localhost:8787 で起動
フロントエンドとバックエンドを分けて開発したい場合は、2つのターミナルで起動します。
# ターミナル1(サーバー)
pnpm dev-server
# ターミナル2(クライアント)
pnpm dev-client
# → http://localhost:3000
ローカル実行時のデータは .wrangler/ 配下に保存されます。
自社のCloudflareアカウントへデプロイする
本番導入は、自分の Cloudflare アカウントに乗せる形になります。
- ガイド付きセットアップ:
https://os.cloudflare.app/deployから数分でデプロイできます。 - Starter リポジトリ: Gatekeeper 込みで独自にカスタマイズしたい場合は
cloudflare-os-starterを使います。Access ポリシー・AI Gateway 設定・データ・連携先をここで構成します。
完全な自己ホスト(workerd 単体で自前サーバーに載せる経路)は現時点で実験的で、ドキュメントは準備中とされています。まずは自社の Cloudflare アカウントへのデプロイ、あるいはローカル実行から始めるのが現実的です。
また本リポジトリは外部からのコントリビューションを基本的に受け付けていません(約12行以下の自明なバグ修正PRを除く)。大きめの機能提案は Discussion 経由で歓迎、という運用です。
Gatekeeperを設定する(連携先)
Gatekeeper は連携先ごとにパッケージが用意されており、それぞれ OAuth などの認証情報を設定して使います。公開時点で用意されている主な連携先は次のとおりです。
| カテゴリ | 対応する連携先(Gatekeeper) |
|---|---|
| 開発 | GitHub API、Cloudflare API、Supabase API |
| ドキュメント/ナレッジ | Google API、Notion API、Confluence API |
| コミュニケーション | Slack API、Email(Email Workers) |
| その他 | Home Assistant、Spotify、ZoomInfo API |
加えて、Model Context Protocol(MCP)にも対応しており、既存の MCP サーバーを MCP Server Portal 経由で取り込めます。この場合もエージェントが受け取るのは「生の認証情報」ではなく「定義済みのツール群」です。各 Gatekeeper パッケージの README にセットアップ手順が記載されています。
Cloudflare OSの料金|無料で使えるのか
Cloudflare OS のソフトウェア自体はオープンソース(Apache 2.0)で、ライセンス費用はかかりません。自社の Cloudflare アカウントにデプロイして自由に使えます。
ただし「完全無料で運用できる」という意味ではありません。実際にかかるのは次の2つです。
- Cloudflare の利用料: Workers・Durable Objects・AI Gateway など、動かした分の Cloudflare プラットフォーム利用料
- モデルの利用料: AI Gateway 経由で呼び出す各AIモデルのトークン課金(どのモデルを使うかは組織が選択)
言い換えると、「基盤ソフトは無料、動かすインフラとAIの実費は自社持ち」という構造です。前述のとおり、そのAIコストは個人・チーム・アプリ単位で可視化・上限設定できます。
なお、Cloudflare のダッシュボードから使えるフルマネージド版(自分で運用しなくてよい提供形態)は「近日提供」とされています。マネージド版の価格は本記事執筆時点(2026年8月)では公表されていません。開発ワークフロー向けの Containers 対応や、Slack など他チャットツールへの統合も今後の予定として挙げられています。
他のAIワークスペースとの違い・なぜ注目されるのか
ChatGPT Enterprise や各種「社内AIアシスタント」と Cloudflare OS の最大の違いは、「信頼しないこと(distrust)」を出発点に置いたアーキテクチャである点です。
汎用のAIアシスタントは、便利さと引き換えに「広い権限をまとめて渡す」方向に流れがちです。対して Cloudflare OS は、エージェントをゼロ権限から始め、Gatekeeper で1つずつ能力を渡し、見たものに応じて縛るという逆向きの発想を取ります。「自律エージェントを社内に放つなら、セキュリティとガバナンスは後付けにできない」という問題意識が根底にあります。
さらに、オープンソースかつ自社ホストである点も大きな差別化です。業務プロセスや社内連携がベンダーのSaaSに閉じ込められず、モデル選択も自由——これは、特定ベンダー依存のリスクを避けたいという近年の「AI主権(AI sovereignty)」の潮流と一致します。同じ問題意識から生まれた Sakana Fugu が「モデルの供給」を束ねて主権を確保するアプローチだとすれば、Cloudflare OS は「エージェントの実行環境」を自社に取り戻すアプローチ、と整理できます。
Cloudflare OSに関するよくある質問(FAQ)
Cloudflare OSは無料ですか?
ソフトウェア自体はオープンソース(Apache 2.0)でライセンス費用はかかりません。ただし実運用では、Cloudflare プラットフォームの利用料と、AI Gateway 経由で呼び出すモデルのトークン課金が別途かかります。「基盤は無料、インフラとAIの実費は自社負担」と考えるのが正確です。
エンジニアでなくても使えますか?
使えます。ブラウザから使える会話UIが中心で、ターミナルや開発知識は不要です。調査・資料作成・業務自動化・簡単なアプリづくりまでを、非エンジニアが自分で完結できることを目指して作られています。
どのAIモデルが使えますか?
Cloudflare AI Gateway 経由で、組織が選んだモデルを使えます(Bring Your Own Model)。公式デモでは Claude Opus 5・GPT 5.6 Sol・GLM 5.2・Kimi K2.7 などが選択されており、タスクに応じて軽量モデルとフロンティアモデルを使い分けられます。特定ベンダーへのロックインはありません。
Gatekeeperとは何ですか?
Cloudflare OS と外部サービスのあいだに挟まる、サービスごとの Cloudflare Worker です。エージェントに生の認証情報を渡す代わりに、Gatekeeper が認証情報を保持し、限定されたAPIだけを見せます。「Issueは読めるがソースコードは読めない」「特定フィールドを隠す」「PR作成には人の承認を必須にする」といった細かい制御ができます。
自社ホスト(オンプレ)できますか?
自社の Cloudflare アカウントへのデプロイが基本の提供形態です。workerd を使った完全な自己ホストも視野に入っていますが、現時点では実験的でドキュメントは準備中です。運用不要のフルマネージド版は「近日提供」とされています。
社内データが外部に漏れませんか?
Cloudflare OS は「すべてのエージェント・アプリはゼロ権限から始まる」という前提で設計されています。サーバーコードは外向き通信を無効化した環境で動き、外部到達は明示的に付与した能力(capability)経由に限られます。加えて観測ログにより、機微なデータを読んだエージェントは外部送信や共有が制限されます。
既存のMCPサーバーは使えますか?
使えます。Model Context Protocol に対応しており、既存の MCP サーバーを MCP Server Portal 経由で取り込めます。この場合もエージェントが受け取るのは生の認証情報ではなく、定義済みのツール群です。
まとめ
- Cloudflare OS は、Cloudflare が2026年8月5日にオープンソース公開したAIエージェント・ワークスペース。自社の Cloudflare アカウント上で動かせる(Apache 2.0)
- 構成は3つ。エージェント・ワークスペース(会社の文脈で動くチャットUI)/Gadget(成果物がそのまま小さな自作アプリになる)/Gatekeeper(サービスごとの安全な接続部)
- セキュリティは「ゼロ権限から始める」のが原則。Gatekeeper で能力を1つずつ渡し、観測ログで「見たもの」に応じて操作を縛る。サーバーコードは外向き通信オフ
- 「OS」は比喩ではなく設計思想。Workers/Durable Objects/Facet/Cap'n Web の上に、カーネル(backend)・シェル(frontend)・ドライバー(gatekeeper)として構築されている
- AI推論は AI Gateway 経由。モデルは自由に選べ、コストは個人・チーム・アプリ単位で可視化・上限設定できる
- ソフトは無料だが、Cloudflare 利用料とモデルのトークン課金は自社負担。フルマネージド版は近日提供
「AIを社内に安全に放つ」ための土台として、ゼロ権限とオープンソース自社ホストを選んだのが Cloudflare OS です。まずは pnpm run-local で手元で触ってみるところから始めてみてください。