「Cloudflare OS」徹底解説｜全社員に自社仕様のエージェントと作業場を配るオープンソース基盤

Cloudflareが2026年8月5日、Cloudflare OS をオープンソース（Apache-2.0）で公開しました。エンジニア向けのコーディングエージェントではなく、経理も営業も人事も含めた「社員全員」に、自社の文脈と社内システムにつながったエージェントと作業場（ワークスペース）を配るための基盤です。

Cloudflare自身が5月から社内で先行運用しており、公式ブログによれば「あらゆる部門の数千人、その多くは開発以外の職種」が日常的に使っているとされています。今回の公開は、その社内版を作り直したうえで、他社が自分たちのCloudflareアカウントへ展開できる形にしたものです。

この記事では、公式ブログの発表内容に加えて、公開されたGitHubリポジトリの中身（ドキュメント・パッケージ構成・設計方針）まで踏み込んで、実際に何がどう作られているのかを整理します。ブログだけでは分からない「承認待ちで作業を止めない仕組み」や「共有相手の権限をどう検証しているか」といった実装上の工夫が、この製品のいちばん面白い部分だからです。

発表の要点

まず全体像を3行でまとめます。

• 社員一人ひとりに、自社の用語・手順・システムに接続されたエージェントと作業場を配る基盤を、Cloudflareがオープンソースで公開した
• 中核は 「エージェントは権限ゼロから始まる」 というセキュリティ設計。資格情報はエージェントのコードから完全に隔離され、外部サービスへのアクセスは Gatekeeper という中継役のWorkerがすべて仲介する
• ワークスペース上の「ファイル」は、実際にはクライアントコード・サーバコード・API・永続状態を持つフルスタックアプリ。エージェントがその場で作り、共有し、受け取った側が勝手に改造できる

先に用語をそろえる：ブログと実装で名前が違う

読み進める前に、ひとつ整理しておくと理解が速くなります。公式ブログの用語と、GitHubリポジトリ内の用語が一部食い違っています。 対応はこうです。

以降は、実装に踏み込む箇所ではGadgetという呼び方を使います。リポジトリを読みに行くときも、この対応表が頭にあると迷いません。

なぜ作ったか：エージェントの恩恵が開発者で止まっている

出発点は、Cloudflareが自社で感じていた偏りです。エージェントはコードを書く仕事ではすでに実用段階に入りましたが、組織の残り全部にとっては、まだ同じ効き方をしていない——というのが発表の前提認識です。

理由ははっきりしています。組織は、ミッションだけでなく「用語・手順・システム・基準・仕事のやり方」を人に引き継ぐことで動いています。開発以外の仕事でエージェントが役に立つには、この会社固有の文脈を理解した上で、社員が日常的に触っている社内システムへ実際に手を伸ばせる必要があります。汎用のチャットボットに社内事情を毎回説明し直す構図では、いつまでも「下書き作成の相棒」から先へ行けません。

Cloudflare OSは、この「文脈」と「システム接続」の2つを、個人の工夫ではなくプラットフォーム側で用意する、という発想の製品です。

第1版の反省：MCPでは「何を見たか」が分からなかった

興味深いのは、5月から動いている社内第1版の課題が正直に書かれている点です。大きく2つ挙げられています。

1つ目は、アプリが「静的」だったこと。 第1版は個人のプライベートなワークスペースでのエージェント対話が中心で、生成される成果物は社内システムと生きた接続を持たない静的なものでした。加えて、決まりきった定型処理でさえ、実行のたびにエージェントのスキルを走らせてモデルのトークンを消費していました。判断の要らない作業にまで毎回モデルを呼んでいた、ということです。

2つ目は、共同作業で露呈したセキュリティの穴です。 原文の表現を借りると、「MCPサーバへのアクセスは、エージェントがどのツールを呼べるかは教えてくれたが、エージェントがどの実データを実際に見たかは分からなかった」。

これは共有の場面で効いてきます。あるエージェントが人事データを参照して作った集計アプリを同僚に共有したとき、ツール権限しか記録されていないと、その同僚が本来見てはいけないデータが成果物経由で漏れるのを止められません。

そこで作り直した第2版（リポジトリ上も「v2は完全な書き直し」と明記）では、方針をこう定めています——「セキュリティはプラットフォームの一部でなければならず、アプリを作る人・エージェントを使う人が各自で正しく実装するものであってはならない」。

全体像：3つの層と、その間に立つ仲介役

リポジトリのパッケージ構成から見ると、システムはおおむねこの流れで動いています。

ブラウザ（React SPA）
   │  Cap'n Web RPC over WebSocket
   ▼
router（公開エントリポイント：アセット配信と振り分け）
   ▼
workshop-backend（カーネル：セッション・権限・Gadget管理）
   ├─▶ Gadget（Dynamic Worker ＋ Durable Object Facet ＝ 専用SQLite）
   └─▶ gatekeeper-github / -google / -slack / …（外部サービスごとの仲介役）
                                   ▼
                             外部サービスのAPI

ポイントは、Gadgetから外部サービスへの直通経路が存在しないことです。外へ出る通信は必ずGatekeeperを通ります。ここが設計の背骨なので、順に見ていきます。

エージェントワークスペース：ブラウザだけで完結する作業場

ワークスペースは、エージェントとの対話セッション、永続的な状態、生成ファイル、リソースへのアクセス権、そして隔離された実行ランタイムをひとまとめにしたものです。ブラウザから使え、開発者としての知識もターミナルの操作も要りません。

できることとして4つが挙げられています。

調査・分析。 社内リソースを使って調べ物をします。特徴的なのは、エージェントが検索・絞り込み・結合・集計のコードを書いて処理する点です。データセット全体をコンテキストウィンドウに読み込ませる必要がなく、大きなデータでも扱えます。

成果物の作成。 ドキュメント・プレゼン資料・表計算を生成します。これらは生きたデータに接続されたままで、参照元が変われば追随して更新されます。標準形式へのエクスポートにも対応します。

共同利用アプリ。 UI・ロジック・状態を備えたアプリをエージェントが構築し、社内リソースにつないだまま複数人で使えます。

定型ワークフロー。 手順が確定している処理はコードで自動化し、判断が要る箇所にだけモデルを使う構成にできます。オンデマンド実行・スケジュール実行・接続システムのイベント起動に対応します。第1版の「定型処理でもトークンを食う」という反省が、そのままここに反映されています。

Gadget：「ファイル」の正体はフルスタックアプリ

Cloudflare OSは、固定のアプリケーション群（文書ソフト・表計算ソフト……）を提供しません。代わりに、**ワークスペース上の「ファイル」ひとつひとつが、それ自体で完結したフルスタックアプリ（Gadget）**になっています。クライアントコード、サーバコード、API、永続状態を持ち、既定は非公開、ドキュメントのように共有できます。

エージェントがGadgetを作るとき書くのは2つです。

• クライアントコード：ブラウザでUIを描画する
• サーバコード：状態を保持し、振る舞いを実装する

サーバは必要になった時点で Dynamic Workers としてロードされ、Durable Object Facets としてインスタンス化されます。これによりGadgetごとに専用のSQLiteデータベースが割り当てられます。Dynamic Workersは軽量なV8アイソレートなので、アプリごとに専用サーバを立てずに隔離ランタイムを持たせられる、という構成です（実行基盤はオープンソースのworkerdランタイム）。

ブラウザのクライアントとサーバの通信には、Cloudflareがオープンソースで公開している能力ベースのRPC Cap'n Web を使います。サーバのメソッドは、クライアントからは普通のJavaScript関数に見えます。

const issues = await app.listIssues({
  status: "done",
});

リポジトリのREADMEは、この構成の狙いをかなり直截に書いています——「スライド作成アプリのセキュリティバグがあなたのスライドを攻撃者に漏らす、ということは起こり得ない」。アプリはユーザーごとのプライベートなインスタンスとして生成され、外部アクセスはサンドボックスが全面的に握っているからです。「みんなが使う1つの巨大なアプリ」ではなく「一人ひとりの手元にある小さなアプリ」にすることで、漏洩の影響範囲そのものを消しにいく設計です。

そしてブログには、この層の狙いを言い切った一文が置かれています——「自分の仕事のための道具を自分で作れるなら、自分がいない間はエージェントがその道具を使って仕事をこなせる」。人が使うUIと、エージェントが叩くAPIが、同じGadgetの表と裏になっているわけです。

セキュリティ設計①：権限ゼロから始め、資格情報はコードに触れさせない

ここからが本題です。原文は明快で、「エージェントは何のアクセス権も持たない状態から始まる（Agents start with no access）」。必要になった時点で個別のリソースへアクセスを要求し、承認されると、そのリソースを**特定のポリシー下の能力（capability）として表す「型付きバインディング」**を受け取ります。

コードからはこう見えます。

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

APIキーもトークンも出てきません。資格情報はエージェントのコードから完全に隔離されており、エージェント側にあるのは「ENGチームのopenなissueを一覧する」という限定された能力だけです。

実行環境も締められています。サーバ側コードは外向きネットワークを無効化したDynamic Workerで動き、クライアント側コードはサンドボックス化されたブラウザフレームで動きます。どちらも、明示的に付与された能力を通す以外にインターネットへは出られません。

セキュリティ設計②：Gatekeeper——外部サービスごとに置く「窓口役」

Gatekeeper は、Cloudflare OSと外部サービスの間に立つ、サービス固有のWorkerです。ブログでは「GitHubアカウント全体ではなく特定の1リポジトリだけに限定する」「issueの読み取りは許可しソースコードの読み取りは禁止する」「PR作成には人間の承認を必須にする」といった例が挙げられていますが、リポジトリ側にはこれをどう書くかの手引き（.agents/skills/write-gatekeeper/）まで入っています。中身を見ると、設計の芯がよく分かります。

3階層のモデル

「誰の接続で、どのリソースに対して、どのGadgetが」という3点が型で分離されているのが要点です。バインディングがGadget単位で切られるので、権限の付け替えや剥奪が個別に効きます。

Gatekeeperが負う7つの責務

1. 認証管理 — OAuthトークンの保管・更新・失効をUserAccount Durable Objectで扱う
2. API設計 — サービスのAPIを、能力ベースのオブジェクト指向TypeScriptラッパーに包み直す
3. 細粒度の付与 — サービス全体／プロジェクト／特定ドキュメント、といった意味のある粒度で許可する
4. ログと承認 — 全操作をApprovalQueueに記録し、外部から見える副作用には承認を要求する
5. キャッシュ — 取得内容をDOストレージに持ち、性能と扱いやすいAPI形状を両立する
6. シミュレーション — 承認待ちの操作を「もう通ったこと」として見せる
7. オブザーバ検証 — 共有相手が、そのGadgetが過去に読んだ情報を自力で読める権限を持つか確かめる

実装の作法として、「1つの巨大な神オブジェクトを作らず、論理的なリソース種別ごとにインターフェースを分ける」「エージェント向けのJSDocに承認やキャッシュといった内部事情を書かない（エージェントには小さく素直なAPIだけを見せる）」といった指示まで明文化されています。

いちばん実務的な工夫：「シミュレーション」

6番目のシミュレーションは、エージェント運用の現実的な壁をうまく回避しています。

人間の承認を挟む設計は安全ですが、素直に作るとエージェントが承認待ちで固まります。承認者が席を外していれば、その間ずっと処理は進みません。Cloudflare OSのGatekeeperは、承認待ちの操作をキューに積んだうえで、以降のAPI応答では「その操作がすでに適用された世界」を返します。エージェントは処理を続けられ、人間は後からまとめて承認できます。

「同期的な承認を求めるのではなく、後で人間が承認できるようアクションをキューに入れる」——READMEはこれを、GatekeeperがただのMCPサーバではない理由のひとつとして挙げています。

発表時点で実装済みのGatekeeper

リポジトリのpackages/には、すでに次のGatekeeperが入っています。「何と繋がるか」がそのまま実装として存在するのが、オープンソース公開の分かりやすい価値です。

gatekeeper-mcp が並んでいる通り、既存のMCPサーバを捨てる必要はありません。MCPサーバをGatekeeper配下に置き、その上から承認・ログ・オブザーバ検証を被せる、という位置づけです。

セキュリティ設計③：ポリシーは「エージェントが見たもの」に追随する

もっとも独特なのがこの発想です。ブログいわく、「最初の読み取りを制御するだけでは足りない（Controlling the initial read is not enough）」。

プラットフォームは、エージェントが観測したリソースをすべて記録します。この観測記録はエージェントとその成果物に貼り付いて回り、他の人がそのワークスペースや成果物にアクセスしようとしたとき、Gatekeeperが**「この人は、そこで観測されたリソースを見る権限があるか」を検証**します。

リポジトリの設計ドキュメント（docs/observers.md）では、この原則がこう言語化されています——「あるGadgetが制限された情報を読めるなら、その情報を読めないユーザーはそのGadgetを操作することもできない」。実装としては、非オーナーがGadgetを開くとensureObserver()が走り、関係するGatekeeperごとに自分の接続アカウントを提示させ、各Gatekeeperが「そのGadgetがこれまでに読んだ情報を、この人は直接読めるか」を検証します。検証は初回だけでなく開くたびに再実行されます。

さらに、オブザーバが設定された後にGadgetが新しいデータを読もうとして、そのオブザーバに権限がなければ、GatekeeperはexcludeObserversにそのIDを載せて読み取り自体をブロックできます。共有された後で機微データを読み足して漏らす、という抜け道を塞ぐ作りです。

検証のやり方は、サービスの性質で4通り

一律のルールにせず、リソースの性質ごとに戦略を分けているのが現実的です。

「個人のメールボックスは共有相手に絶対見せない（A）」「リポジトリ単位なら1回の権限確認で足りる（B）」「テーブル単位で読み散らかすものは1つずつ突き合わせる（C）」——という判断の分け方は、自社で同種の統制を組むときにもそのまま参考にできます。

共有のしくみ：権限グラフと、2種類の共有

Gadgetの共有には2通りあります。

① コラボレーター（直接共有）。 状態を共有したまま、リアルタイムで一緒に使います。役割は2つで、順序関係があります（build > use）。

アクセス権の管理は単純なフラグではなく、「どうやってアクセス権を得たか」を辺として持つ有向グラフです。誰かが直接追加した辺と、共有リンクを使って得た辺が区別され、**有効な役割は「オーナーから辿り着ける最大の役割」**として計算されます。

この形にしている利点は失効処理に出ます。権限を剥奪するときも連鎖削除はせず、該当の辺だけを切って、到達可能かどうかを都度計算します（遅延失効）。権限を失った人はアクセス時点で弾かれ、記録自体は残るので、取り消しをやり直せるわけです。剥奪や降格が起きた場合は、対象GadgetのDurable Objectを再起動してセッションを切り、再接続時に新しい権限グラフで再判定させます。

共有リンクの鍵は生のまま保存せず、HMAC-SHA-256でハッシュ化して保持します。データベースが漏れても、そこから有効なリンクは復元できません。

② ブループリント（設計図の共有）。 受け取った側が独立したコピーを作ります。何がコピーされて何がされないかは明確に定義されています。

新しいGadgetは、自分のストレージ・自分の会話履歴・自分で選んだ接続先を持って動き始めます。これがあることで、共有されたアプリに不満があるとき「作った人に機能追加を依頼する」のではなく、自分のコピーを自分で改造するという進み方ができます。社内ツールが「作った人の異動とともに塩漬けになる」問題への、ひとつの答えでもあります。

モデル選択とコスト管理

Cloudflare OSは特定のモデルに固定されず、あらゆるモデルと組み合わせられます。そのうえで、すべての推論呼び出しをCloudflare AI Gateway経由に通す設計になっており、「どのモデルを使えるようにするか」「どのタスクにどのモデルを割り当てるか」を中央で制御できます。

強調されているのは、すべての仕事に高価なフロンティアモデルは要らないという点です。難しい作業には高性能モデルを温存し、毎朝のメール要約のような定型作業には安価なモデルを充てる、という使い分けを前提にしています。

さらに、すべてのリクエストが「誰が・どのチームが・どのワークスペースが」要求したものかに紐づけられます。管理者は推論コストの内訳を見て、予算やレート制限を設定し、上限超過時の挙動まで定義できます。

なお、オープンソース版には個人単位の課金モードも用意されています（ENABLE_CLOUDFLARE_LIMITS=trueで有効化）。この場合、ユーザーごとにUTC日単位の無料枠（既定は1日100コール）が与えられ、使い切ったユーザーは自分のCloudflareアカウントのクレジットで動かす形に切り替わります。日次カウンタはユーザーのDurable Objectが持ち、OAuthトークンはCloudflare用Gatekeeperに置かれる、という分離です。全社導入の前に社内で試験公開する、といった局面で「誰かが青天井に使う」事故を防ぐ実装が最初から入っている、と捉えると分かりやすいでしょう。

触ってみるには

リポジトリは公開直後で5,000スター超と反応が大きく、ライセンスはApache-2.0、主要言語はTypeScriptです。ローカル起動は数コマンドで済みます。

# 前提：pnpm を入れておく（npm ではなく pnpm を使う）
pnpm run-local
# → http://localhost:8787

開発時はサーバとクライアントを分けて起動します。

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

実環境へのデプロイは、ブラウザからのデプロイ導線（https://os.cloudflare.app/deploy）か、スターターリポジトリ経由になります。

分け方の意図は明快で、本体にパッチを当てずに自社仕様を積むためです。本体の更新を取り込み続けながらカスタマイズできます。

ただし、リポジトリ自身が現状を 「アーリーアクセスであり、粗い部分が残っていて、活発に開発中」 と明言しています。v2は完全な書き直しであり、本番の全社展開を今すぐ前提にするより、設計を読み、限定範囲で試す段階と考えるのが妥当です。

導入支援の戦略パートナーとして Presidio と Happy Cog が挙げられています。パートナー側は、共有スキルと文脈の整備、独自インターフェースの構築、GatekeeperやMCPサーバポータル経由でのシステム接続、セキュリティ・モデル・コスト制御の設定までを担当します。今後については、ダッシュボードに統合したフルマネージド版、開発ワークフロー向けのコンテナ対応、ワークスペースのSlack等チャットへの統合が予告されています。

実務への示唆

社内でAIエージェントの展開を検討する立場から見ると、この設計から持ち帰れる論点は4つあります。

1. 「ツール権限」と「観測記録」は別物である。 MCPで接続先を絞れば安全、という理解は不十分です。エージェントが実際に何を読んだかを記録し、成果物を共有する相手の権限と突き合わせる仕組みがなければ、共有の瞬間に統制が抜けます。しかも検証は初回だけでは足りず、開くたびの再検証と、共有後に読み足すデータのブロックまで要ります。

2. 承認は「同期で待たせない」設計にする。 人間の承認を挟むと安全性は上がりますが、素直に実装するとエージェントが止まります。キューに積んで、以降は適用済みとして扱うというシミュレーション方式は、安全性と実用性を両立させる具体的な答えとして参考になります。

3. 定型処理にモデルを使わない。 Cloudflare自身が第1版の反省として挙げた点です。手順が確定している処理はコードで書き、判断が要る箇所にだけモデルを呼ぶ。エージェント運用のコストは、この線引きの精度でかなり変わります。

4. コストの按分単位を先に決める。 全社展開では「誰がいくら使ったか」が見えないと予算管理が成立しません。人・チーム・ワークスペース単位での紐づけと上限設定は、導入検討の初期に決めておくべき項目です。

一方で、留意点もあります。オープンソース公開といっても実体はCloudflareアカウント上での運用が前提で、Workers・Durable Objects・Dynamic Workers・AI Gatewayといった同社プラットフォームに深く依存します。フルマネージド版はこれからで、現時点では自社デプロイと運用の体力が必要です。「オープンソースだから軽く試せる」よりは、基盤としてどこに乗るかを決める種類の選択と捉えるのが実態に近いでしょう。

まとめ

• Cloudflare OSは、社員一人ひとりに自社の文脈と社内システムに接続されたエージェントと作業場を配るためのオープンソース基盤（Apache-2.0）。2026年8月5日公開
• 社内第1版（5月〜、数千人が利用）の反省は2つ。アプリが静的だったことと、MCPでは「呼べるツール」は分かっても「実際に見たリソース」が分からず、共有時の漏洩を防げなかったこと
• セキュリティは権限ゼロ起点。資格情報はエージェントのコードから隔離され、外部サービスへはGatekeeper（サービス固有のWorker）が仲介する。Gatekeeperは Vendor / User / Instance の3階層で、認証・API設計・粒度・ログと承認・キャッシュ・シミュレーション・オブザーバ検証の7つの責務を負う
• **承認待ちでエージェントを止めない「シミュレーション」**が実装されている。操作はキューに積まれ、以降のAPI応答は適用済みの世界を返す
• ポリシーは「エージェントが見たもの」に追随する。 共有相手には開くたびに検証が走り、検証方法はリソースの性質ごとにA〜Dの4戦略で分けられている
• ワークスペース上の「ファイル」＝Gadgetはフルスタックアプリ。Dynamic Workers＋Durable Object Facets（Gadgetごとの専用SQLite）で動き、通信はCap'n Web。共有はコラボレーター（権限グラフ＋遅延失効）とブループリント（独立コピー）の2通り
• 全推論はAI Gateway経由。人・チーム単位のコスト按分と予算・上限が可能で、OSS版には1日100コールの個人無料枠モードも同梱
• 配布は cloudflare-os（本体）と cloudflare-os-starter（自社仕様の出発点）の2リポジトリ。pnpm run-local でローカル起動できるが、アーリーアクセスで粗い部分が残ると明記されている

エージェントを「開発者の道具」から「全社員の道具」へ広げようとすると、最初にぶつかるのは性能ではなく権限と統制です。Cloudflare OSで参照する価値がいちばん高いのは、まさにその部分——権限ゼロから始め、見たものにポリシーを追随させ、承認では待たせないという3点でしょう。自社で同種の仕組みを組む場合でも、点検すべき観点の一覧として使えます。

参考資料

• Cloudflare OS: an open platform for agents, apps, and work（Cloudflare公式ブログ・2026年8月5日）
• cloudflare/cloudflare-os（GitHub）
• cloudflare/cloudflare-os-starter（GitHub）