2026年8月5日（米国時間）、Cloudflare が「Agents Week」と位置づける発表週の中で、社内基盤「Cloudflare OS」に関する記事を2本同時に公開しました。1本目はプラットフォームそのものの発表「Cloudflare OS: an open platform for agents, apps, and work」（Phillip Jones 氏・Dan Carter 氏）、2本目は同社 CIO の Sam Rhea 氏が社内導入の経緯を振り返る「How we’re rethinking work at Cloudflare with Cloudflare OS」です。弊社のサイトも Cloudflare 上で運用しており、また「全社員に生成 AI をどう配るか」という問いは規模を問わず組織に共通するため、2本をあわせて原文に基づいて整理します。

発表の概要 — 社内向け基盤を作り直してオープンソース化

発表の骨子は次のとおりです。Cloudflare は2026年5月に最初のバージョンの Cloudflare OS を全従業員に提供し、エンジニア以外を多く含む数千人が、文書やスライドの作成、繰り返し作業の自動化、データ可視化のための小さなアプリ作りに日常的に使ってきました。そこで得た教訓（後述）をもとに基盤を作り直し、今回その新バージョンをオープンソースとして公開した、という流れです。どの組織でも自分の Cloudflare アカウントにデプロイし、社内システムにつないで使えるとしています。

Cloudflare OS が何であるかについて、発表記事は冒頭で次のように述べています。

That’s why we created Cloudflare OS. It gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

（だからこそ私たちは Cloudflare OS を作りました。すべての人に、その会社を中心に組み立てられたエージェントと作業空間——会社がどう動いているか、何を知っているか、どのシステムに依存しているか——を与えるものです）

プラットフォームは3つの部品の組み合わせと説明されています。

  1. エージェントの作業空間: 会社が蓄積した文脈（コンテキスト）とスキルに接地し、エージェントがコードを書いて実行できる隔離された実行環境を持つ
  2. セキュリティとガバナンスの枠組み: 社内データ・サービスへの安全なアクセスを基盤側で保証する
  3. アプリの実行基盤: 個人が作り、共有し、その後も変更し続けられる「自分用の」アプリを支える

ブラウザーで会話を始め、それが文書になり、アプリになり、あるいは自分がいない間も動き続けるワークフローになる、という使い方が想定されています。ターミナルや開発ツールの知識は前提とされていません。

Cloudflare OS の作業空間の画面。ブラウザー上の会話から、会社のコンテキストとスキルを使って調査や文書作成が進む様子

図1: 作業空間はブラウザー上の会話から始まる。会話は会社が蓄積したコンテキストとスキルに接地している（出典: The Cloudflare Blog）

できることとして挙げられているのは、会社の文脈を使った調査（データセット全体をモデルのコンテキストに流し込むのではなく、エージェントがコードを書いて検索・絞り込み・結合・分析する）、文書・スライド・スプレッドシートの作成（静的ファイルではなく元データに接続したまま更新でき、Google Drive などへの書き出しも可能）、チームで共同編集できるアプリの構築、そして決定的（deterministic）なワークフローの実行です。最後の点は後述の v2 の要でもあり、「多くの仕事は既知の手順の連なりであり、判断が要る箇所は一、二か所しかない。予測可能な部分はコードで、モデルは価値を生む場面でだけ使う」という考え方が貫かれています。

セキュリティ — エージェントは「何も持たずに」始まる

この発表で最も紙幅が割かれているのがアクセス制御です。出発点にあるのは、職場で AI を使い始めた人がまず求めるものが社内システムの API キーだ、という観察です。キーは広範で長命な権限を与えがちで、絞ることも安全に共有することも監査することも難しい——そこで MCP（Model Context Protocol）サーバーに資格情報を持たせてツールだけを公開するのが現在の定石ですが、Cloudflare はそれでも足りないと述べます。MCP が教えてくれるのは「エージェントがどのツールを呼べるか」までであり、「エージェントがどのデータを実際に見たか」ではありません。エージェントは複数システムの情報を組み合わせ、より制限の緩い場所へ送り、アプリや成果物を通じて、元のデータを見る権限のない人に露出させうる——認可は「そのデータが次にどこへ行けるか」まで考慮しなければならない、という問題設定です。

これに対する Cloudflare OS の設計は3段構えです。

第一に、エージェントとアプリは一切のアクセス権を持たない状態から始まります。入口は Cloudflare Access（同社のゼロトラスト認証）が守り、その内側で、エージェントは特定のリソースへのアクセスを求め、人がそれを許可または拒否します。許可されたリソースは、生成されたコードに型付きのバインディングとして渡されます。

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

env.PROJECT は「特定のポリシーの下で特定のリソースを使う許可」を表す能力（capability）であり、資格情報そのものはエージェントからも生成コードからも完全に隔離されています。サーバー側のコードは外向きの通信を全面的に無効化した Dynamic Worker で動き、クライアント側のコードはブラウザー内のサンドボックス化されたフレームで動きます。明示的に与えられた能力を通じてしか、どちらもインターネットに到達できません。

第二に、Gatekeeper（ゲートキーパー） です。外部サービスごとに用意される Worker で、そのサービスの API・リソース・操作を理解し、Cloudflare OS とサービスの間に立ちます。GitHub アカウント全体ではなく単一リポジトリだけを見せる、Issue は読めるがソースコードは読めない、特定フィールドを伏せる、レート制限をかける、Pull Request のマージには人の承認を要求する——といった粒度の制御を担い、OAuth の処理と資格情報の保持、読み取りの記録、外部に影響が及ぶ操作の仲介をすべて引き受けます。エージェント側から見えるのは小さな TypeScript の API だけです。

Gatekeeper の構成図。エージェントと外部サービスの間に Gatekeeper が立ち、資格情報の保持・ポリシーの適用・読み取りの記録を担う

図2: Gatekeeper は外部サービスごとの Worker として、資格情報の隔離とポリシーの適用を一手に担う（出典: The Cloudflare Blog）

第三に、ポリシーが「エージェントが見たもの」に追従します。ここがこの発表の設計上の中核です。たとえばエージェントがデータウェアハウスの機微なテーブルを読んでダッシュボードを作ったとき、そのダッシュボードの共有が、テーブルを直接見られない人への共有経路になってはなりません。Cloudflare OS はエージェントが観測したすべてのリソースを記録し、その観測はエージェントとその成果物に付随し続けます。別の人が作業空間を開く、エージェントと対話する、成果物を見る——そのたびに Gatekeeper が「その人自身が、観測されたリソースを見る権限を持つか」を検証します。同じ観測ログは外向きのリクエストの可否判断にも使われ、機微データを読んだエージェントは、特定の宛先への書き込みや新しい共同編集者の招待、他のエージェントへの作業の引き継ぎ、外部リクエストを制限されえます。

観測ログに基づくアクセス検証の図。エージェントが見たリソースの記録が成果物に付随し、閲覧者の権限がその記録と照合される

図3: 「誰が何を見られるか」は成果物の時点ではなく、エージェントが何を観測したかの記録に基づいて検証される（出典: The Cloudflare Blog）

これらをアプリ作者や利用者が個別に実装するのではなく、基盤が肩代わりする——「セキュリティはプラットフォームの一部でなければならず、アプリを作る人やエージェントを使う人の各自が正しく実装しなければならないものであってはならない」というのが、v1 の運用から得た結論だったと説明されています。

アプリはすべて Worker — 「ファイル」が自分用のフルスタックアプリになる

もう一つの特徴は、アプリの扱いです。従来の生産性スイートが文書・表計算・プレゼンテーションという固定のアプリケーション群を提供するのに対し、Cloudflare OS では各「ファイル」がそれ自体一つのアプリケーションになりえます。エージェントがクライアントコード（ブラウザーで UI を描画）とサーバーコード(状態の保存と挙動の実装)を書き、サーバー側はオンデマンドに Dynamic Worker として読み込まれ、Durable Object Facet としてインスタンス化されます（どちらも今回のために作られた Cloudflare の基盤機能です）。各アプリは自分専用の SQLite データベースを持ち、軽量な V8 アイソレートで動くため、専用サーバーやコンテナを常駐させる必要がありません。

アプリの構造図。クライアントコードとサーバーコードからなり、サーバーは Dynamic Worker + Durable Object Facet として動き、専用の SQLite を持つ

図4: 各アプリはクライアント・サーバー・API・永続状態を持つフルスタックアプリとして、それぞれ隔離された実行環境で動く（出典: The Cloudflare Blog）

ブラウザーとサーバーの間の通信には、Cloudflare がオープンソースで公開しているオブジェクト・ケーパビリティ型の RPC システム Cap’n Web が使われ、サーバーのメソッドを通常の JavaScript 関数のように呼べます。

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

重要なのは、同じメソッドをエージェントも呼べることです。発表記事はこれを「自分で仕事を片づける道具を作れるなら、自分がいないときはエージェントがその道具を使って仕事を片づけられる」と表現しています。共有の方法は2通りあり、アプリそのものを共有すれば同じ状態をリアルタイムに共同利用でき、設計図（blueprint）を共有すれば相手は自分のコピーを作れます。設計図から作られたアプリは元のコードを含みますが、SQLite のデータ・会話履歴・資格情報・接続済みリソースは含まず、独立した状態から始まります。

モデルはどれでも使え、すべての推論は Cloudflare AI Gateway を経由します。組織はどのモデルを利用可能にするか、どの仕事をどのモデルに担わせるかを一元管理でき、リクエストは人・チーム・作業空間に帰属して記録されるため、推論コストの行き先の把握、予算とレート制限の設定、上限到達時の挙動の決定ができます。

CIO が語る導入の記録 — API キーの要求から始まった

2本目の記事は、CIO の Sam Rhea 氏による社内導入の顛末です。書き出しは象徴的で、約半年前、営業部門のメンバーから「AI で作った『SuperApp』を動かすために、社内十数システムの本番 API キーとデプロイパイプラインの管理者権限がほしい」という依頼が届いたことが「問題を抱えている」と気づいたきっかけだったとされています。2025年の同社は情報提供型のチャットや定型コードの補助といった慎重な導入にとどめていましたが、昨年末の数日間で「より良いモデルとより強力なハーネスがその計算を変えた」——エージェントが実際に仕事をこなせるようになり、年末年始の静かな時期に技術職・非技術職を問わず数百人が新しいツールの実験を始めた、という経緯です。

同社はまず原則を定めました。要約すると次の5つです。

  1. AI は顧客との時間を増やし、顧客の問題をより多く解決するために使う（「AI を使うための AI 利用」はしない。まず「片づけるべき仕事」を定義してから道具を選ぶ）
  2. 全員が「超能力」を持つに値する（開発者ツールを使わない従業員を置き去りにしない）
  3. 成果物の責任は人間が持つ
  4. モデルよりも組織のコンテキストが重要
  5. AI を使うときに、記録システムに対して通常より多い権限を持ってはならない（エージェントを共有された人がそこから得られるアクセスは、共有した人ではなくその人自身の権限を反映する）

3番目の原則について、原文は次のように述べています。

We view AI as a tool and toolmaker, not a team member. We expect humans to take responsibility for defining the quality, testing, and workflows that rely on AI output.

（私たちは AI を道具であり道具職人であるとみなし、チームの一員とはみなしません。AI の出力に依存する品質・テスト・ワークフローの定義には、人間が責任を持つことを求めます）

エンジニア向けには、「Cloudflare Engineering Codex」と呼ぶ文脈レイヤーを整備しました。禁止事項を並べるポリシーではなく「何をすべきか」を示す、意図的に意見の強い（opinionated）ガイドで、コードベースの各領域に責任者を置いています。この Codex を開発ライフサイクル全体に組み込み、すべての Merge Request・実装前の技術設計・インシデントレポートをエージェントがレビューする体制にした結果、直近4か月で約25万件の潜在的問題を検出し、1万6,000件のマージをブロックし、コードが書かれる前の設計段階で約600件のアーキテクチャ上の問題を捕捉した、と同社は報告しています。

「魔法のメールアドレス」— 人力で始めた自動化の種まき

非エンジニア向けの試行錯誤は、この記事で最も率直な部分です。最初の失敗は「エンジニアと同じツールに少し親切な UI を被せて配る」ことでした。コードを書くのが得意なハーネスの作業空間を全員に配れば、必要以上のコードが生まれる——結果は「解くべき問題を探してさまよう、雰囲気で作られた（vibe coded）アプリの洪水」だったと振り返られています。

そこで同社は逆から始めました。全社に「やりたくない仕事を送れば、必要な成果物が返ってくる魔法の AI メールアドレス」を案内したのです。実際には舞台裏で少人数のチームが AI ツールを使って人力で応対していました。人は「自動システムだと思っている相手」には思いつきのアプリ案を送りにくく、代わりに本当にやりたくない仕事を送る——数百から数千のセッションを人力で捌くうちに、部門を横断して自動化需要のある定型業務のパターンが見え、スキルファイルと文脈ファイル、データ接続、必要な成果物の形が揃っていった、という経緯です。原文は「私たちはこのサービスの人力運用を止めたい一心だった。惨めな仕事だった」と率直に書いています。

魔法のメールアドレスの仕組みの図。ユーザーがやりたくない仕事をメールで送ると、舞台裏では人間のチームが AI ツールで応対していた

図5: 「魔法のメールアドレス」の裏側。自動化に見える窓口を人力で運用し、本当に需要のある定型業務を洗い出した（出典: The Cloudflare Blog）

v1 から v2 へ — トークンを燃やす仕事を、コードに変える

その蓄積を実行に移す場所として作られた v1 は、Cloudflare のインフラ上のコンテナで動くシンプルなハーネスでした。ブラウザーからアクセスし、Cloudflare Zero Trust で認証すれば、ローカル設定なしで即座に使えます。クラウド側の一時的な環境はユーザーがセッションに持ち込んだデータにしかアクセスできず、セキュリティチームは環境への監査可視性と、接続先を絞るネットワーク制御を持ちます。データ接続は MCP Portal 経由で、ユーザーのセッションが持つアクセスは各記録システムでの本人の既存権限に絞られます。推論は AI Gateway を通り、Secure Web Gateway の DLP（情報漏えい防止）ルールを再利用して特定のデータセットが外部プロバイダーに送られること自体を遮断できます。

Cloudflare OS v1 のランディングページのスクリーンショット

図6: 社内版 Cloudflare OS v1 の画面。ブラウザーだけで使え、蓄積されたスキルファイルをワンクリックで実行できた（出典: The Cloudflare Blog）

ただし v1 には構造的な無駄がありました。スキルファイルの実行はそのたびにトークンを大量に消費する推論セッションを起動します。Rhea 氏自身の例が具体的です。IT ヘルプデスクのチケットキューを毎朝確認する業務は、v1 ではチケットシステムの MCP サーバーにつないだスキルファイルで実行していましたが、「ほぼ同じレポートを再生成するために毎朝数千トークンを燃やしていた」と書かれています。今回公開された v2 では、ワークフローを自然言語で説明するとエージェントがそれを動かすコードを書き、オンデマンド・スケジュール・イベント起点で実行できます。同じ朝のレポートはコードとして動くため、初回表示のトークン消費はゼロになり、判断が要る場面（届いたチケットへの返信案の作成など)にだけ推論を埋め込む形に変わりました。作ったアプリを共有しても、相手は同じ Gatekeeper を通じて本人の権限で認証されるため、データの境界をまたぎません。

チケットキューのダッシュボードアプリの画面。チャートとチケット一覧が表示されている

図7: v2 で作られたチケットキューのダッシュボード。毎朝の定型レポートはコードが担い、推論は返信案の作成など判断が要る箇所にだけ使われる（出典: The Cloudflare Blog）

展開にあたっては専任の AI チームを新設せず、各職種の早期採用者を「チャンピオン」として組織し（ロンドンの営業責任者、テキサスのソリューションエンジニア、ポルトガルの IR 責任者、日本の事業開発メンバーなど）、また「配属チームを AI ツールでオールスターにする」ことを目標に多数のインターン（今年の受け入れ目標は1,111人）を各部門に埋め込んだとされています。成果として同社が挙げる数値は、毎週数千人が利用し1日あたりのアクティブユーザーが毎営業日増え続けていること、直近1か月で営業チームがテリトリープランニングや提案書作成などの手作業から1万時間超を節約したという推計、30日間で4,000超のアプリ・ツールが作られたこと、です。いずれも同社自身の報告・推計であり、第三者による検証を経た数値ではない点は留意が必要です。

位置づけと留意点

  • オープンソースの範囲: 公開されたのはコア（cloudflare/cloudflare-os）と、同社の社内運用に基づくデプロイ例（スターター、cloudflare/cloudflare-os-starter）の2リポジトリです。デプロイ側リポジトリはコアにパッチを当てずに設定・カスタム UI・社内統合・分析・デプロイパイプラインを載せる構成で、os.cloudflare.app でデモも公開されています
  • 動作の前提: 自分の Cloudflare アカウントへのデプロイが前提で、Access のポリシー、AI Gateway の設定、データや統合は各組織が用意します。Dynamic Worker や Durable Object Facet といった今回のために作られた基盤機能は Cloudflare のプラットフォーム機能として提供されるものです
  • ソースコードは出発点にすぎない: 発表自身が「コンテキスト、スキル、ワークフロー、社内システム、ポリシーこそが Cloudflare OS を有用にする」と明言しています。導入支援のパートナーとして Presidio と Happy Cog の2社が挙げられており、コードの公開と商用の導入支援を組み合わせるモデルです
  • 今後の計画: Cloudflare ダッシュボードへのフルマネージド製品としての統合、開発ワークフロー向けコンテナの追加、Slack などチャットツールへの作業空間の展開が予告されています
  • 数値の扱い: 本文中の導入成果（25万件の検出、1万時間の節約など）はすべて同社の自己報告です。一方で、失敗（アプリの洪水、メール窓口の人力運用の苦労）まで含めて記録されている点は、導入事例の読み物として誠実な部類に入ると考えます

まとめ

  • 2026年8月5日、Cloudflare は社内の全従業員に提供してきた AI エージェント基盤 Cloudflare OS をオープンソース化しました。作業空間・セキュリティとガバナンス・アプリ実行基盤の3層構成です
  • 設計の中核はアクセス制御にあります。エージェントは一切の権限なしで始まり、リソースは資格情報を隔離した型付きバインディングとして渡され、サービスごとの Gatekeeper がポリシーを適用します。さらに「エージェントが何を観測したか」が記録され、成果物の共有時にも閲覧者本人の権限が観測ログと照合されます
  • アプリはそれぞれがクライアント・サーバー・API・SQLite を持つフルスタックの Worker として隔離実行され、人が使うメソッドをエージェントも呼べます。推論はすべて AI Gateway を経由し、モデルの選択とコストを組織が一元管理します
  • CIO の記事は、API キーの一括要求という危機感から始まり、5つの原則、エンジニア向けの Codex とレビューエージェント、人力で運用した「魔法のメールアドレス」による業務の洗い出し、トークン消費の多い v1 から決定的なワークフロー中心の v2 への作り直しまでを、失敗を含めて記録しています
  • 公開されたコードは出発点であり、各組織のコンテキストとスキルの整備、Gatekeeper による社内システム接続が本体です。導入成果の数値は同社の自己報告である点には留意が必要です

参考