コンテンツにスキップ

Cloudflare OSの設計を読む：全社員へAIエージェントを配る前の導入判断

導入検討で先に決めること

組織の要件現時点の判断
社内文脈と業務システムをエージェントへ安全につなぎたい限定部門で検証する
観測したデータまで追跡して共有を制御したいGatekeepersを評価する
完成済みのマネージド製品をすぐ全社展開したい正式提供を待つ
Cloudflare以外へ容易に移せることが必須移植性を先に実証する

従業員がAIエージェントを使い始めると、APIキー、社内文脈、生成物の共有を一つの権限モデルで守る必要が生じる。 Cloudflare OSは、ワークスペース、Gatekeepers、Gadgetsを一つの基盤にまとめるOSSである。 全社導入の判断軸は、観測履歴に追従する権限モデルと、early accessおよびCloudflare依存の許容度にある。

Cloudflare OSがワークスペース、Gatekeepers、Gadgetsを接続する全体像

Cloudflare OSは従業員向けAI作業基盤として公開された

Cloudflareは2026年8月5日、社内で使ってきたAI生産性基盤Cloudflare OSの新しい版をオープンソースとして公開した。1 名称にOSとあるが、WindowsやLinuxの代替ではない。 ブラウザ上の会話を起点に、企業が整備した用語、手順、スキル、社内システムへの接続を使い、文書、分析、アプリ、定型ワークフローを作る実行基盤である。

社内運用の課題が会話、権限、個人アプリケーションの統合を促した

Cloudflareは同年5月に最初の版を全社員へ提供し、エンジニア以外を含む数千人が日常的に使ったと説明している。1 その運用では、決定論的な処理でもエージェントを再実行してモデル費用が発生すること、共有した成果物から権限外の情報が見える可能性があることが課題になった。 公開版はこの経験を基に作り直された新基盤であり、リポジトリ自身も「early access」と位置付けている。2

基盤は次の三つを組み合わせる。

  • エージェントワークスペース：会話、永続状態、成果物、リソース権限、隔離されたコード実行環境をまとめる
  • Gatekeepers：外部サービスの認証、リソース単位の許可、読み取り記録、副作用の承認を仲介する
  • Gadgets：利用者またはチームごとに状態とコードを持ち、AIで変更できる小さなフルスタックアプリケーションを動かす

Gatekeepersは認証情報と観測履歴をエージェントから分離する

一般的なMCPサーバーは、エージェントが呼べるツールを限定し、認証情報をサーバー側へ置ける。 しかしCloudflareが第一版で直面した問題は、ツールの許可だけでは「エージェントがどの基礎リソースを読んだか」を表現できないことだった。1 機密テーブルを読んで作ったダッシュボードを共有すれば、元のテーブルへアクセスできない人にも内容が渡る可能性がある。

Cloudflare OSでは、エージェントとアプリケーションは何にもアクセスできない状態で始まる。 利用者が特定のリポジトリやデータへアクセスを許可すると、生成コードは認証情報ではなく型付きのcapabilityを受け取る。

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

env.PROJECTは、特定のポリシー下で特定リソースを使う権限を表す。 OAuth処理と認証情報はGatekeeper側に残り、エージェントと生成コードから分離される。1

GatekeeperはサービスごとのWorkerとして、APIとリソースの意味を理解した上でアクセスを仲介する。 GitHubなら、アカウント全体ではなく単一リポジトリだけを許可し、issueは読めるがソースコードは読めないようにし、マージ前には人の承認を要求できる。 承認が必要な操作では、Gatekeeperが結果をローカルでシミュレートし、エージェントを停止させずに後続処理を進める。 利用者はタスク終了後に操作をまとめて、または一件ずつ承認か拒否する。2 導入検証では、拒否した操作のシミュレーション結果に依存する後続操作をどう取り消し、整合させるかも確認する必要がある。

サーバーコードはglobalOutbound: nullを指定したDynamic Workerで動き、外向き通信を無効にする。 クライアントコードはsandboxed iframeで動き、CSPとiframe sandboxによって、ブラウザが許す範囲で外向き通信を遮断する。2

さらにCloudflare OSは、エージェントが観測したリソースを記録し、その履歴をワークスペースと成果物へ結び付ける。 別の利用者が成果物を開く場合、Gatekeepersはその人が元リソースへアクセスできるかを検証する。 同じ観測履歴は、外部への書き込み、共同編集者の追加、別エージェントへの引き渡し、外向き通信を許可するかの判断にも使われる。1

この設計は権限外の経路を狭めるが、許可済み権限の範囲内で起きる業務ロジックの誤りやプロンプトインジェクションまで自動的に防ぐわけではない。 導入側は読み取り権限だけでなく、書き込みの承認、操作ログ、取り消し手順をGatekeeperごとに設計する必要がある。

Gadgetsはファイルごとに実行環境と状態を持つ

Gadgetsでは、各ファイルが専用のアプリケーションとして動く。 アプリケーションはブラウザUIを担うクライアントコードと、状態と振る舞いを持つサーバーコードで構成される。 サーバーはオンデマンドでDynamic Workerへ読み込まれ、Durable Object Facetとしてインスタンス化される。 そのため、アプリケーションごとに独立したSQLiteデータベースと軽量なV8実行環境を持てる。1

Dynamic Workersは一般的なコンテナと比べて約100倍速く起動するとCloudflareは説明している。4 この値はCloudflareによる一般的なDynamic Workersの比較であり、Cloudflare OS全体の処理速度を保証するベンチマークではない。

クライアントとサーバーの通信には、Cloudflareが公開するRPCシステムCap'n Webを使う。 サーバーメソッドは利用者のクライアントからもエージェントからも同じ形で呼べるため、人が使うために作ったツールがエージェントの操作面にもなる。1

共有には、同じ状態を共同編集するアプリケーション共有と、コードだけを複製するBlueprint共有がある。 Blueprintから作られたアプリケーションには、元のSQLiteデータ、会話履歴、認証情報、接続済みリソースが含まれない。1 Kenton Varda氏は、この個人専用アプリケーションの考え方を、自身が以前開発したSandstorm.ioのリメイクだと説明している。5

導入コストはライセンス以外へ移る

コア実装はApache 2.0で公開されており、Cloudflareは社内構成を基にしたデプロイ用リポジトリも別に提供している。23 デプロイ用リポジトリはコアへ直接パッチを当てず、固定した上流版、ブランド、認証、連携、ルート、更新を自社側で管理する構成になっている。

ソフトウェアの利用許諾料が不要でも、運用費用はなくならない。 現在案内されている本番導入は、自社のCloudflareアカウントを使う。 Workers、Durable Objects、AI Gateway、モデル推論、連携開発、権限ポリシー、監査の費用は導入企業が負担する。 全ての推論呼び出しはAI Gatewayを通り、利用者、チーム、ワークスペース単位で費用を把握し、モデル、予算、レート制限、上限到達時の挙動を決められる。1

公開資料だけでは、選択した外部モデル事業者に送るデータの保持期間、学習利用、処理地域までは確認できない。 導入企業は、AI Gatewayの設定だけで判断せず、採用モデルごとの契約とデータ処理条件を別に確認する必要がある。

これは定額SaaSとの単純な価格比較ではない。 組織固有の文脈と連携をどこまで内製するか、Gadgetsが増えた後に誰が保守するか、Gatekeepersの承認規則を誰が所有するかが総費用を左右する。

オープンソースでもCloudflare依存とearly accessの制約は残る

移植性は実行基盤まで含めて実証する

ソースコードを読めることと、別の実行基盤へ容易に移せることは同じではない。 Cloudflare OSはDynamic Workers、Durable Object Facets、Workers Bindingsを前提に組み立てられている。 AI GatewayとCloudflare Accessも基盤の一部である。

コアリポジトリは、オープンソースのWorkersランタイムworkerd上でも動かせるとしている。 ただし、自社サーバー向けの本番デプロイ手順は「COMING SOON」の状態である。2 現時点でクラウド非依存を必須要件にする企業は、ライセンスだけを見て移植可能と判断せず、認証、状態管理、隔離実行、Gatekeepersを別環境で再現できるか実証する必要がある。

検証範囲は一つの業務へ絞る

公開版は開発途上である。 Cloudflareは、ダッシュボード上のマネージド製品、開発向けコンテナ、Slackなどとの統合を今後の予定として挙げている。1 企業がすぐ全社員へ配る段階ではない。

最初の検証では、読み取り中心で機密度を限定した一つの業務を選ぶ。 評価対象は回答品質だけでなく、capabilityの付与単位、観測履歴による共有拒否、外向き通信の遮断、副作用の承認、費用帰属、Gadgetの廃止手順まで含める。 この境界を再現できた場合にだけ、接続サービスと利用部門を一つずつ増やす。

導入判断は四つの条件で決められる

  1. 情報システム部門は、対象業務と接続リソースを一つに限定し、権限ゼロからの付与と剥奪を検証する。
  2. セキュリティ部門は、観測済みデータを含む成果物の共有と外向き通信がポリシーどおり拒否されるか確認する。
  3. AI基盤チームは、モデル費用、Workers費用、Gadget保守、Gatekeeper開発を同じ試算へ入れる。
  4. 導入責任者は、early accessの変更頻度とCloudflare依存を許容できない場合、全社展開を保留する。

この記事をポスト リンクをコピー

関連記事

出典

  1. Cloudflare, Cloudflare OS: an open platform for agents, apps, and work, 2026-08-05。 社内利用、三つの構成要素、Gatekeepers、Gadgets、AI Gateway、公開時点の予定を参照した。 ↩↩↩↩↩↩↩↩↩↩

  2. Cloudflare, cloudflare-os, 2026-08-10参照。 early access、Apache 2.0、対応ランタイム、セルフホスト手順、Gatekeeperの遅延承認、実行環境の通信境界を参照した。 ↩↩↩↩↩

  3. Cloudflare, cloudflare-os-starter, 2026-08-10参照。 コアを固定して組織固有の設定と更新を管理するデプロイ構成を参照した。 ↩

  4. Cloudflare, Sandboxing AI agents, 100x faster, 2026-03-24。 V8 isolateの起動時間とコンテナとの比較を参照した。 ↩

  5. Kenton Varda, Cloudflare OSをSandstorm.ioのリメイクと説明した投稿, 2026-08-05。 設計思想の出自だけに使用し、製品機能の根拠には使用していない。 ↩