Cloudflare OSは仕事のOSになれるか？社員が自分用アプリを作り安全に共有する仕組みをコードから読み解く

2026年8月6日 12:52

「営業会議用のダッシュボードを作って」「このGoogleドキュメントとGitHubのIssueをつないで、毎週の報告を自動更新して」。そんな依頼を社員が自然な言葉で入力すると、AIがその人専用の小さな業務アプリを作る。しかも、外部サービスのパスワードをアプリへ直接渡さず、読み取りと書き込みを分け、危険な操作は人が承認する。

Cloudflare OSが目指しているのは、こうした働き方です。ただし、名前に「OS」と付いていても、WindowsやmacOSの代わりではありません。実態は、AIとの会話、アプリ生成、外部サービス接続、権限管理、共有、監査を一つにまとめる、ブラウザー上の仕事環境です。

Cloudflare OS is an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems, shaped around what your organization knows and how it operates. https://t.co/CCeYETILDN
— Cloudflare (@Cloudflare) August 5, 2026

Today we are releasing Cloudflare OS, a chatbot with connectors, just like every other tech company is doing.

Except actually, it's different. This is a remake of Sandstorm[.]io, my startup from 10 years ago, except this time built on Cloudflare Workers (the platform I've spent…
— Kenton Varda (@KentonVarda) August 5, 2026

結論から言えば、発想と基礎設計はかなり強いです。特に重要なのは、AIに完璧なコードを書かせるのではなく、生成コードを信用しなくても被害が広がりにくい構造を作ろうとしている点です。一方、公開版は早期公開版であり、管理画面、テスト、自己ホスト、本番運用の標準化には未完成な部分が残ります。現時点で妥当なのは、非機密データと限定メンバーによる隔離した試験導入です。

この記事では、公開リポジトリと公式資料をもとに、Cloudflare OSで何ができるのか、社員へどう配るのか、内部で何が動いているのか、どこまで安全なのか、費用はどこに発生するのか、Codexとどう使い分けるのかを、専門用語を日常の仕事へ置き換えながら整理します。

Cloudflare OSは全社導入より先に限定試験で確かめるべきである

評価を先に明確にします。Cloudflare OSは、今すぐ全社員へ配れる完成済みの企業製品ではありません。一方で、AIが作った小さな業務アプリを安全に実行し、必要な相手へ共有するための考え方はかなり先進的です。

Cloudflare OSが一つにまとめているのは、大きく三つです。

会社の言葉や手順を理解したAIへ仕事を頼む場所
AIが個人やチーム向けの小さなアプリを作り、その場で動かす場所
そのAIとアプリが、外部サービスの何を読めて、何を変更できるかを管理する場所

ここでいう小さなアプリがGadgetです。営業会議用の案件一覧、GitHubのIssueをまとめる画面、定期報告を作るツールなど、特定の仕事に合わせたソフトを指します。外部サービスへの接続を管理する門番がGatekeeperです。

最大の特徴は、AIへ「絶対に間違えないコード」を要求することではありません。AIが作ったコードを最初から全面的には信用せず、触れられるデータ、ネットワーク、外部操作を実行基盤側で狭くすることです。

一般的なAIエージェントでは、チャットへGoogle DriveやGitHub、Slackなどの接続権限を広く与えがちです。Cloudflare OSでは、AIとGadgetは最初には何も使えません。利用者が特定の文書、リポジトリ、会話などを明示して初めて、その対象に限った操作権限が渡されます。この「必要なものだけを紹介する」設計が、被害範囲を小さくする土台です。

ただし、安全になることと、事故がなくなることは同じではありません。Gadget内部の計算ミス、誤った送信や更新、Gatekeeper自体の実装不良、悪意ある指示をデータへ混ぜるプロンプトインジェクション、費用の急増、共有リンクの漏えい、管理者アカウントの侵害までは消せません。公開READMEが強く表現する「何も悪いことは起きない」という理想は、設計目標としては理解できますが、実運用の保証として受け取るべきではありません。

現時点の判断は次のとおりです。

個人が非機密情報で操作感を試すことは推奨できます。
小規模チームで、読み取り中心の業務を試すことは条件付きで推奨できます。
全社展開は、権限、ログ、費用、バックアップ、退職者対応まで整備した後です。
契約、決済、人事、医療、金融、本番環境の変更は、最初の試験対象から外すべきです。
企業が管理するCloudflareアカウントへStarterを使って固定版を配備する方法が、現在もっとも現実的です。
完全な自社サーバー運用は可能性こそありますが、公式の手順と運用道具がまだ整っていません。

つまり、導入判定は「使うか、使わないか」の二択ではありません。非機密データ、十名前後、四週間、読み取り中心という狭い条件で、価値と危険を同時に測るのが妥当です。この記事では、その判断に必要な機能、内部構造、導入手順、安全策、費用、Codexとの分担まで順に解説します。

確認できた事実と今後の判断を分けて考える

公開コードから直接確認できる事実と、そこから導く評価は分ける必要があります。ここを混ぜると、社内利用実績や将来構想を、現在の公開版の保証だと誤解してしまいます。

公開コードから確認できること

Cloudflare OSは2026年8月5日にオープンソース公開された。
v1はCloudflare社内で利用され、v2はGadgetとGatekeeperを中心に全面再構築された。
コアリポジトリと、固定版を自社用に設定・配備するStarterリポジトリが分離されている。
Gadgetはクライアントコード、サーバーコード、API、永続状態を持つフルスタックアプリである。
GadgetサーバーはDynamic Workerとして読み込まれ、Durable Objectの区画ごとに分離されたSQLiteの状態を持つ。
Gadgetクライアントは外部アクセスを制限したiframe内で動く。
AgentとGadgetは初期状態で外部リソースへのCapabilityを持たない。
Gatekeeperは外部サービスごとの独立Workerであり、OAuth、認可、観測ログ、操作承認を担う。
Blueprintはコードを共有する仕組みで、元GadgetのSQLiteデータ、会話履歴、資格情報、接続済みリソースを含めない。
対応コードにはAnthropic、OpenAI、Google、Cloudflare Workers AI、Ollamaのプロバイダー分岐がある。
ローカル実行は`pnpm run-local`で可能だが、公式READMEは本番用ではないと明記する。
`workerd`単体による自己サーバー本番運用は「COMING SOON」で、公式手順・ツールは未整備。
Dynamic Workersは2026年8月6日時点でWorkers Paidプラン限定である。
StarterはNode.js 24、pnpm 11、Wrangler、Workers、KV、R2、Browser Rendering、Dynamic Worker Loadersを前提とする。
AI機能はStarterではデフォルト無効であり、AI GatewayやWorkers AIは任意で有効化する。
公式READMEとStarterは早期公開版であること、固定版利用とアップグレード前レビューを明記している。
コアの`AGENTS.md`には「現時点では多くのpackageにテストがない」と記載されている。

コードから見える本当の狙い

Cloudflare OSの本質は「AIチャット」ではなく、AI時代の権限を中心に設計された仕事の実行環境である。
セキュリティ責任は各Gadgetから、Workshop backend、Gatekeeper、Cloudflare Runtime、認証設定へ集約される。
そのため、Gadgetの生成品質が多少低くても横断漏えいを抑えやすい反面、Trusted Computing Baseの不具合は広範囲へ影響する。
BlueprintはSaaSの中央集約モデルより、モバイルアプリやPCアプリの配布モデルに近い。
Gatekeeperの非同期承認は、エージェントの停止を避けながら人間確認を残す重要なUX改善である。
一方、シミュレーション結果と実際の適用結果がずれる「投機的実行」の整合性管理が、新しい運用課題になる。
企業導入の成否は、LLM性能よりも、Context、Skill、Gatekeeper、データ分類、共有ポリシー、承認設計の品質に依存する。

公開資料だけでは決められないこと

企業向けSLA、長期サポート方針、正式なSemVer互換性保証は公開資料から確認できない。
各Gatekeeperの全APIについて、独立したセキュリティ監査が完了しているかは確認できない。
GDPR、個人情報保護法、業界規制への適合は、導入組織の構成・データ・地域・LLMプロバイダー次第であり、OSSそのものだけでは判定できない。
完全自己ホスト時のバックアップ、アップグレード、HA、監視、秘密管理の標準運用は未確立。
Cloudflare社内v1の利用実績を、そのまま公開v2の品質実績として扱うことはできない。
「何千人が毎日使用」という実績はv1を含む社内運用の説明であり、公開直後のv2について同一の成熟度を保証するものではない。

Cloudflare OSをパソコンのOSと考えると本質を見失う

Cloudflare OSを理解する最短の方法は、「AIチャットに機能を足したもの」ではなく、「社員が自分用ソフトを作り、そのソフトへ必要な権限だけを渡す場所」と捉えることです。

Cloudflare OSが担う四つの役割

会社文脈を持つAgent Workspace

各Workspaceは、次を組み合わせる。

エージェント会話
永続状態
出力ファイル
接続済みリソース
会社固有のContext
Skill
コード実行環境
Gadget
監査履歴
承認キュー

そのため、毎回ゼロから会社用語、業務手順、判断基準を説明するのではなく、組織で整備したContextとSkillを再利用できる。

個人向けソフトウェア工房

ユーザーは自然言語で、次のようなGadgetを作れる。

会議用スライド
顧客向け資料
共同編集ホワイトボード
GitHub Issueダッシュボード
定期レポート
データ集計アプリ
社内申請補助
顧客・案件の可視化
小規模CRM
シミュレーター
チェックリスト
リアルタイム共同作業アプリ

生成後も、同じエージェントへ「列を追加」「承認フローを追加」「この指標を表示」と依頼して、自分のGadgetだけを改変できる。

外部サービス接続の統制層

Gatekeeperを通じて、次を制御する。

OAuth資格情報の保持
接続対象リソースの選択
読み取り範囲
書き込み範囲
フィールドマスキング
Rate Limit
操作前承認
操作ログ
観測履歴
共有相手の再認可
外部送信制限
取消・補償処理

AIが利用できるアプリとAPI生成基盤

GadgetのクライアントとサーバーはCap’n Web RPCで接続される。
GadgetがUIから呼ぶサーバーメソッドは、エージェントも同じAPIとして呼べる。

つまり、ユーザーが作ったGadgetは次の二つを同時に満たす。

人間が画面から利用できる
AIがAPIとして利用できる

これは「アプリを作る」と「AIツールを作る」を分離しない設計である。

名前から誤解しやすいこと

Windows、macOS、Linuxの代替ではない
会社全体の基幹システムを直ちに置換するものではない
生成コードの正しさを保証する形式検証環境ではない
あらゆる外部操作を自動承認してよい基盤ではない
すべてのMCPサーバーを安全化する魔法のラッパーではない
企業規制・法務・データ保護を自動的に満たす製品ではない
2026年8月時点で成熟したオンプレミス製品ではない
v1の社内実績と同等の公開v2安定性を保証するものではない

社員にはアプリではなく会社専用URLを配る

社員ごとにCloudflare OSをインストールするのではない。会社または運営主体が一つのCloudflare OS Deploymentを用意し、社員へ共通URLを配布する。

会社のCloudflare Account
└─ Cloudflare OS Deployment
   ├─ Router / Workshop
   ├─ Gatekeepers
   ├─ KV / R2 / Durable Objects
   ├─ AI Gateway / Model routes
   └─ 会社専用URL
        ├─ 社員AのUser DO・Workspace
        ├─ 社員BのUser DO・Workspace
        └─ 共有Gadget

社員はブラウザーからアクセスし、Cloudflare Access、Google、GitHub、Cloudflare Sign-in、または環境によりUsername/Passwordで認証する。

認証Gatekeeperを使う場合、Primary Account KeyはProviderが検証したEmailである。同じVerified Emailを返すGoogle、GitHub、CloudflareからSign-inしても、同じUser Durable Objectへ解決される。

Sign-inと外部Resource接続は別処理である。

Sign-in：Email確認に必要な最小Scopeだけを要求し、Grantは短時間で破棄
Connect：社員が明示的にGoogle、GitHub等を接続した時に、業務Resource用のFull/Granular Scopeを要求し、Connected Accountを保存

この分離により、「GoogleでログインしただけでDriveやGmailへアクセス可能になる」という状態を避ける。

ブラウザーで使えても処理はクラウド側で動く

社員から見れば、Chat、Gadget作成、Code Preview、Connections、Approval、Sharing、Blueprint、Profile、Usage確認をブラウザーで操作できる。

ただし、全処理がブラウザー内で完結するわけではない。

Workshop UI：ブラウザー
Gadget Client：外部アクセスを制限したiframe
Gadget Server：Cloudflare Dynamic Worker
Gadget State：Durable Object FacetのSQLite
User/Workspace State：Durable Objects
Blueprint Metadata：KV
Blueprint Code Snapshot：R2
OAuth Token：各Gatekeeper Durable Object
LLM inference：OpenAI、Anthropic、Google、Workers AI、Ollama等
Audit/Approval：Workshop + Gatekeeper

つまり、社員はローカル開発環境を構築せずブラウザーから利用できるが、実体はCloudflare Runtime上の分散Webシステムである。

社員が自分用Gadgetを作るまで

会社URLへSign-in
自分のWorkspaceを作成
会社共通Context、Format、Blueprintを利用
必要なGoogle Doc、GitHub Repo、Slack Conversation等を接続
Agentへ業務目的を自然言語で依頼
Agentが調査・処理またはGadgetを作成
社員がCode/Diff/画面を確認
提案中の変更をAcceptまたはRevert
外部WriteはApproval Queueで承認
自分で継続利用、Collaboratorへ共有、またはBlueprintとして配布

画面の裏では複数のCloudflare基盤が役割を分担する

画面では一つのサービスに見えますが、中では複数の部品が責任を分けています。難しく見える構成には理由があります。生成コード、認証情報、業務データ、承認処理を同じ場所へ詰め込まないためです。

利用者
  │
  ▼
Cloudflare Access / 認証
  │
  ▼
Router Worker
  ├─ Workshop Frontend（React/Vite SPA）
  │      └─ 外部アクセスを制限したiframe内のGadget Client
  │
  ├─ Workshop Backend「Kernel」
  │      ├─ User Durable Object
  │      ├─ Overseer Durable Object
  │      ├─ AdminSettings Durable Object
  │      ├─ PendingLogin Durable Object
  │      ├─ Agent / Code Mode
  │      ├─ Sharing / Observation / Approval
  │      └─ Dynamic Worker Loader
  │
  ├─ Gadget Server
  │      └─ Dynamic Worker + Durable Object Facet + 独立SQLite
  │
  └─ Gatekeeper Workers
         ├─ GitHub
         ├─ Google
         ├─ Slack
         ├─ Notion
         ├─ Linear
         ├─ Cloudflare
         ├─ Supabase
         ├─ Confluence
         ├─ Home Assistant
         ├─ MCP / MCP Portal
         ├─ Scheduler
         ├─ Context
         ├─ Email
         ├─ Spotify
         └─ ZoomInfo など

社員が触る画面はReactで作られている

`packages/workshop-frontend`

React / ViteのSPA
バックエンドとは永続WebSocket上のCap’n Web RPCで通信
Gadget Clientを外部アクセスを制限したiframeへ読み込む
チャット、ファイル、Gadget、Blueprint、接続、承認、管理画面を提供

中枢のKernelが会話とアプリと権限をまとめる

`packages/workshop-backend`

主要責務：

ユーザーとWorkspaceの管理
Agent実行
Code Mode
Gadgetコードの生成・更新・適用・差戻し
Dynamic Workerのロード
GadgetとGatekeeperのBinding
Action Queue
Observation
Sharing
Blueprint
AIモデルルーティング
添付ファイル
Web Fetch
管理設定
ログ・分析

プロジェクト自身がここを「kernel」と呼び、UIや個々のGatekeeperより高いレビュー水準を要求している。

共通の型が権限境界を支える

`packages/workshop-shared`

FrontendとBackendのRPC契約
Gatekeeper契約
Action、Observation、Sharing、Blueprint、AI、Gadget等の型定義
Capability境界の中心

Routerが画面と中枢と接続先を振り分ける

`packages/router`

静的Frontend配信
`/api/*`をWorkshop Backendへ転送
`/gatekeeper/<name>/*`を各Gatekeeper Workerへ転送
Dev時はViteへプロキシ

Gadgetは画面だけでなくサーバーと状態を持つ

Gadgetは次から構成される。

Client：ブラウザーUI
Server：Dynamic Worker
State：Facet単位のSQLite
API：Cap’n Web RPC
Binding：明示的に接続したGatekeeper / Gadget
Sharing：共同編集
Blueprint：コードのみ再配布

重要なInvariant：

Gadgetは資格情報そのものを受け取らない
Gadgetの外部通信は明示Capability経由に限定する
Blueprintへデータ・履歴・資格情報を混入させない
他Gadgetと状態を共有しない
Gadgetコードの不具合が、他のGadgetへ横断しないことを目標とする

Gatekeeperが外部サービスへの扉を管理する

各Gatekeeperは独立Workerであり、外部サービス固有の「Device Driver」に相当する。

標準責務：

OAuth
Account Capability
リソース選択
型付きRPC API
Read / Action分類
Observation認可
Action Queue
Approval
Apply / Reject / Revert
Audit
Resource Description
Sharing時の再認可

GatekeeperはCloudflare OSの安全性における最重要拡張点である。
カスタムGatekeeperの品質が低い場合、Gadget側のサンドボックスが強くても、誤った認可・誤送信・過大権限を防げない。

Gadgetを作るのはCloudflare独自モデルではない

Cloudflare OS専用の独自LLMが存在するわけではない。Cloudflare OS内蔵Agentが、選択した外部またはCloudflare上のLLMを推論エンジンとして使用し、Gadgetのソースコードを生成・修正する。

コード上で確認できるProviderは次のとおり。

Anthropic
OpenAI
Google
Cloudflare Workers AI
Ollama

モデル呼出しは`@earendil-works/pi-agent-core`と`pi-ai`を中心に構成され、ProviderごとのNative APIを使う。AI Gateway経由でも、統一OpenAI互換変換を常用するのではなく、Anthropic Messages、OpenAI Responses、Google Generative AI、Workers AI OpenAI-compatible endpointを個別に使う。これはThinking、Prompt Cache、Responses API等のProvider固有機能を失わないためである。

Agentが主に扱うGadgetの実装要素は次のとおり。

TypeScript / JavaScript
Client UI
Server-side WorkerEntrypoint
Cap'n Web RPC
SQLite-backed Durable Object Facet
YjsによるSource同期・変更履歴
BindingによるGatekeeper、AI Model、Agent Spawner接続
HookによるEmailやScheduler等のEvent処理

Cloudflare OSのAgentは一般的なRepository全体を自由に設計するCodexと異なり、Gadget Platformの狭く統合された規約へSourceを生成する。この制約が、必要Token、Build複雑性、権限面を小さくする。

AIの変更は提案として保存され人が採否を決める

Agentの変更は直ちに無条件で確定版へ入るわけではない。

`writeFile`、`editFile`等のTool CallはYjs上へ提案中の変更として反映
Streaming中の変更もUIへPreview可能
Gadget生成・Binding追加もChat単位のPending状態
会話履歴が変更の基準
UserがAcceptすると確定版化
Reject/Revertすると保留中のGadget、Binding、Code Updateを破棄
Compaction後もCheckpoint、Accepted/Proposed Update、Change IDを保持
AssistantのModel-facing messageはServer側だけに保存し、ClientへReasoning Snapshotを渡さない

エージェントの仕組みと推論モデルは別物である

役割：Cloudflare OS内蔵AgentはTool、Code Mode、History、Binding、Approval、Change管理、LLMは推論・コード生成
所在：Cloudflare OS内蔵AgentはWorkshop Backend、LLMはProviderまたはOllama
固有価値：Cloudflare OS内蔵AgentはGadget規約、Capability、実行、監査、LLMは言語理解・生成性能
交換可能性：Cloudflare OS内蔵AgentはPlatform固有、LLMは複数Providerから選択
課金：Cloudflare OS内蔵AgentはCloudflare Compute等、LLMはToken/Neuron/Local Compute

したがって「Cloudflare OSのAgentを使う」と「Cloudflareの独自LLMを使う」は同義ではありません。モデルは推論を担当し、Cloudflare OSは権限、状態、コード実行、共有、承認を担当します。この分離があるから、モデルを変えても仕事の仕組みを残せます。

CloudflareがAIエージェントのために整備している実行環境を、Workersや状態管理まで含めて読みたい方は、次の記事で周辺の発表を横断して整理しています。

データと権限を分けて持つことが安全性の中心になる

AIエージェントを安全にするうえで、モデルの賢さより重要なのが「何を持ち、何を読めて、何を変更できるか」です。Cloudflare OSは、この境界をデータと状態として管理します。

何がどこに保存されるのか

User：目的は利用者と設定、主な保存先はUser Durable Object、機密性はInternal / Personal
Workspace：目的は作業空間、主な保存先はOverseer Durable Object、機密性はConfidential
Chat：目的は会話・Agent実行履歴、主な保存先はOverseer、機密性はConfidential
Gadget：目的はアプリ本体とメタデータ、主な保存先はOverseer + Dynamic Worker、機密性はConfidential
Gadget State：目的はアプリ固有データ、主な保存先はDO Facet SQLite、機密性は内容次第
Blueprint：目的はGadgetコードの再利用、主な保存先はKV / R2、機密性はInternal / Public
Gatekeeper Account：目的は外部接続Capability、主な保存先はGatekeeper DO、機密性はCredential
Binding：目的はGadget/AgentからCapabilityへの辺、主な保存先はOverseer、機密性はSecurity
Observation：目的は何を読んだか、主な保存先はGatekeeper / Overseer、機密性はAudit / Sensitive
Action：目的は外部副作用候補、主な保存先はApproval Queue、機密性はAudit
Share Link：目的は共有用Bearer Capability、主な保存先はHashを保存、機密性はCredential相当
Admin Config：目的はBranding、Context、Connector方針、主な保存先はAdminSettings DO + KV mirror、機密性はInternal
AI Model Config：目的はモデル・経路・コスト、主な保存先はUser/Admin状態、機密性はCredential / Financial
Attachment：目的は会話添付、主な保存先はChat storage、機密性は内容次第

変更と外部操作は状態を持って進む

Gadgetの変更は提案と確定を分ける

Proposed / Pending
  ├─ Accept → 確定版へ適用
  └─ Reject / Revert → 破棄

コード、Gadget生成、Binding追加を、チャットの変更単位と同期して管理する設計が見られる。

外部操作は承認待ちの状態を持つ

Pending
  ├─ Manual Approval Required
  ├─ Auto-approvable + User Rule
  │      └─ Applied
  ├─ Rejected
  ├─ Failed
  └─ Applied → Reverted（実装されている場合）

自動承認ドレイナーはAction ID順に処理し、手動承認が必要な最初のActionまたは失敗で停止する。後続を飛ばさないため、依存順序を壊しにくい。

同じGadgetを共同利用する

Owner
  ├─ Direct Collaborator
  │      ├─ build：構築・編集可能
  │      └─ use：UI利用中心
  └─ Share Link

共有時、Gatekeeperは過去に観測した各リソースを、共有相手自身の接続アカウントで再検証する設計を持つ。

作り方を独立コピーとして配る

Gadget
  └─ Export Blueprint
         └─ Other User Creates Independent Gadget

コピーされるもの：

Client/Serverコード
Blueprintメタデータ
Binding要件の形

コピーされないもの：

SQLiteデータ
会話履歴
OAuth資格情報
接続済みリソース
元Gadgetの状態

最初は何も許さず必要な権限だけを渡す

初期状態では何も許可しない設計
どの場面でも使えてしまう広すぎる権限を最小化
Capability単位で権限を渡す
GadgetごとにBindingを分離
資格情報はGatekeeper内に保持
Admin Capabilityは管理者だけに発行
認証方式は環境変数側で固定し、管理画面侵害だけでは変更できない
無効化されたGatekeeperはCapability発行のChokepointで拒否
共有相手は自分の外部アカウントを用いて権限検証
Share LinkはBearer Secretとして扱う必要がある

同じGadgetを共有するとコードも状態も会話も共有する

同一Gadgetを共有した場合、CollaboratorはGadgetの独立コピーを持つのではない。同じGadgetのCode、SQLite State、AI Chat Historyを共有する。

Roleは主に二段階。

`build`：Code編集、AI Chat、Binding管理、Gadget UI利用
`use`：確定版 Gadget UIの描画・操作、限定Metadata・Presence

`use`向けCapabilityは初期状態では何も許可しない設計で、許可リスト外のOverseer Methodを拒否する。新しいMethodが追加されると、`UseOverseerInterface`側で意図的に許可判断しない限りCompileを通さない設計である。

`build` CollaboratorでもOwnerとの差がある。

Gadgetを削除できない
AIを使った本人の処理は本人側Model/Billingを使う
新規Gatekeeper Bindingは本人のConnected Accountで作る
自分が追加したPermission Edge以外のRevocation権限が限定される

共有はDirect AddまたはShare Linkで行う。Share LinkのRaw Keyは128-bit Randomで、ServerはHMACによるHashだけを保存する。ただしURL Fragment自体はBearer Secretなので、Clipboard、Screenshot、Chat転送、Browser Extension等から漏れる危険は残る。

Permissionは単純な一枚のACLではなく、OwnerをRootとするPermission Graphで計算される。CollaboratorやShare Linkを経由したTransitive Share、Role Downgrade、Lazy Revocation、Preview、`keepUsers`によるRe-rootingを扱う。

共有相手が元データを読めるかを再確認する

Gadgetが外部Resourceから読んだ情報をCollaboratorへ漏らさないため、Observer機構を持つ。

原則：

Collaboratorは対象Vendorの自分自身のConnected Accountを選ぶ
Gatekeeperが、そのAccountでGadgetが過去に読んだResourceを直接読めるか検証
検証を通過した場合だけOpen
新しいObservationが既存Observerの権限外なら、そのObservationを拒否
Gadgetを開くたび再検証

`build`は全Gatekeeper、`use`はGadget UIが呼べるNamed Bindingを主対象とする。

注意：

`docs/observers.md`は過去の実装計画であり、現在のCode/Testを優先する
Per-threadやPer-fieldの完全な情報フロー制御ではない
Gatekeeperが正しくObservationを記録し、Verifierを実装することが前提
MCP GatekeeperはRecord-level権限を検証できないため、現行ではOwner-only Sharing Policyを採る

Blueprintは中身を複製せず作り方だけを渡す

Collaborator共有：Codeは同じ、Stateは同じ、Chatは同じ、CredentialはBinding作成者のAccount単位、更新は同じGadgetへ反映
Blueprintから作成：Codeはコピー、Stateは新規、Chatは新規、Credentialは利用者が再接続、更新はExisting instanceへ自動反映なし

BlueprintはSource Snapshotだけでなく、Binding RequirementsとMetadataを含む。ただしCredential、Live Connection、SQLite、Chat/Edit Historyは含まない。

公開BlueprintのMetadataはBlueprint IDを知る者が未認証でも取得できる。Gadget作成にはSign-inが必要である。このため、Blueprint Title、Description、Author、Screenshot、Binding Summaryへ機密情報を入れてはならない。

Blueprint CodeはR2、Public Lookup MetadataはKV、Author管理用情報はGadget/User DOへ伝播する。Propagation失敗は`dirty` Flagで検知し、Retryできる。旧VersionはConcurrent InstantiationのRace回避のため保持される。

Cloudflare OSで実際にできる仕事

では、社員は具体的に何をできるのでしょうか。単に文章を生成するだけではなく、調査、資料作成、データ集計、専用画面、定期処理、共同作業までを一つの流れにできます。

調査と分析を一つの作業空間で進められる

Webページ、PDF、Office文書等の取得・Markdown変換
会社Contextと外部システム情報の統合
GitHub、Google、Slack、Notion等の検索
データの絞り込み・結合・集計
Agentがコードを書いて大規模データを処理し、モデルへ全件投入しない運用
調査結果の文書化

Built-in Web Fetchは、GET、公開HTTPS、タイムアウト、容量上限、SSRF対策を持つ。`Content-Signal: ai-input=no`も尊重する。

文書やスライドを外部データとつないで作れる

会議資料
顧客提案書
報告書
調査レポート
スライド
表計算
ライブデータ接続型資料
Google Drive等への出力

業務に合わせた小さなアプリをその場で作れる

専用ダッシュボード
データ可視化
チーム用共同作業画面
業務入力フォーム
小規模ワークフロー
チェック・審査補助
シミュレーター
進捗管理
顧客・案件ビュー
社内ツール

Gadgetは単なるHTMLモックではなく、Server/API/SQLite状態を持つ。

人が画面で使いAIが同じAPIを使う

Gadgetが持つCap’n Web APIをAgentも呼べるため、次が可能になる。

人間が画面で入力
AgentがAPIで追記・更新
双方の変更をリアルタイム表示
Agentが既存Gadgetを操作
Agentが不足機能をコードへ追加
Agentが定期的にGadget状態を更新

多くの接続先があるが成熟度は同じではない

公開リポジトリで確認できるGatekeeper群：

Cloudflare
Confluence
Context Library
Email
GitHub
Google
Home Assistant
Linear
MCP
MCP Portal
Notion
Scheduler
Slack
Spotify
Supabase
ZoomInfo

ただし、「packageが存在する」ことと、「全用途で成熟している」ことは同義ではない。利用前に各README、OAuth Scope、read/action分類、Revert対応、テスト範囲を個別監査する必要がある。

決まった時刻や外部イベントから処理を始められる

Scheduler Gatekeeperにより、Workspace callbackを永続登録し、定期実行する構造がある。公式説明では、オンデマンド、スケジュール、接続先イベントを起点としたワークフローを想定する。

用途に合わせて複数のモデルを選べる

コード上の主なプロバイダー：

Anthropic
OpenAI
Google
Cloudflare Workers AI
Ollama

AI Gateway経由では、リクエスト単位の帰属、予算、Rate Limit、コスト監視を設計できる。

注意：

「任意モデル対応」は、ネットワーク到達性、API互換、認証、添付対応、モデル能力まで自動保証する意味ではない。
OllamaをCloudflare上の本番Workerから利用するには、安全に到達可能なEndpoint設計が別途必要である。
ローカル実行時にローカルOllamaへ接続する場合も、開発環境を外部へ公開してはならない。

社員は自分の会話と接続と共有を管理できる

公開Frontendから確認できる主な社員向けSurfaceは次のとおり。

Home / Workspaces
AI Chat
Gadget UI
Gadget Editor / Code / Diff / Console
Connections / Connected Accounts
Pending Actions / Activity
Share Modal
Observer Account Configuration
Blueprints / Explore / Import / Export
Formats / Outputs
Profile / Avatar / Password
Usage & Billing（Cloudflare Limits有効時）
Context Library Management UI
Scheduled Tasks Management UI

ただし、GatekeeperごとにManagement UIの有無は異なる。`AccountDescription.providesUi`を宣言したAccountだけが、`/gatekeepers/<vendor>`の管理アプリを提供する。

管理者画面でできるのは全社監視ではなく基本設定である

現行`/admin`の主なTabとControlは次のとおり。

会社全体の表示と指示を設定する

Site Name
Logo
Accent Color
全画面Banner
Top-bar Notice
全Agent System Promptへ追加するInstance Instructions

利用できる接続先を制御する

Gatekeeper全体のEnabled/Disabled
Resource Type単位のEnabled/Disabled
Auto-provisioned Gatekeeperの`disabled` / `optional` / `enabled`

承認済みの出力形式を整える

標準Output Formatとして提供するBlueprintのCuration
表示順、Name、Icon等

新規利用者の入口を制御する

New Signupの可否

重要な制約：

Admin画面上のGatekeeper/Resource無効化はSoft Controlであり、既存Gadgetがすでに保持するCapabilityを直ちにRevokeしない。

緊急遮断には、Service Binding削除、OAuth Token失効、Gatekeeper側のPolicy、Deployment変更等の別Controlが必要である。

全社員を横断する監査画面は別途必要になる

公開コードからは、次を一画面で社員横断閲覧する完成済み管理コンソールは確認できない。

全社員のChat本文
全社員のGadget一覧とSource
全GadgetのSQLite内容
全社員が読んだGoogle/Slack等の具体的データ
全Approvalの横断キュー
社員別の詳細Token/Cost Ranking
Department別KPI
全Share Graph
全Prompt Injection Alert
Data Classification違反一覧
Employee LifecycleとGadget Ownership移管

Cloudflare OS担当者が横断管理する場合、次の追加層が必要になる。

Structured Logs / Traces
AI Gateway Metadata・Cost Logs
Cloudflare GraphQL Analytics
Logpush / SIEM
Connector Provider側Audit Log
組織横断Inventory用のCustom Admin API
利用状況・Cost・Risk Dashboard
Privacy Policy、閲覧権限、監査証跡

管理者が社員の本文まで閲覧する設計は、技術的可否だけでなく、目的限定、本人通知、職務分離、法務・労務確認が必要である。

仕事の現場ではチャットより小さな専用画面が価値を生む

Cloudflare OSの価値を「高性能なAIチャット」と捉えると、既存のChatGPT、Claude、Geminiとの違いが曖昧になります。重要なのは、会話の結果をその場限りの回答で終わらせず、繰り返し使える画面、状態、処理へ変えられることです。

営業では会議資料より案件判断の画面を作る

営業担当者が「来週の会議資料を作って」と依頼するだけなら、一般的な生成AIでも対応できます。Cloudflare OSで一段進められるのは、その資料を作るための作業自体をGadgetへ変えることです。

たとえば、担当する顧客、商談の次回予定、未返信のメール、GitHubやサポート窓口で起きている問題を、必要な範囲だけ接続します。Gadgetには、今日確認すべき案件、次に聞く質問、会議までに不足している資料を表示します。営業担当者は画面で判断し、AIは同じAPIを使って情報を整理します。

ただし、顧客へのメール送信やCRMの更新まで自動化すると危険度が上がります。最初は候補文と更新案を作るだけにし、宛先、金額、契約条件、次回予定は人が確認してから反映する方が安全です。Cloudflare OSの承認機構は、この「読む仕事」と「現実を変更する仕事」を分けるために使います。

経営会議では資料を作るより前提のずれを見つける

経営会議では、各部門が別々の形式で数字や進捗を持ち込みます。AIに資料を要約させても、定義や集計期間が違えば、見栄えのよい誤解が生まれます。

Gadgetを使うなら、売上、商談、開発、採用などを一画面へ詰め込む前に、指標の定義、対象期間、更新日時、責任者を状態として持たせます。数字が更新されていない、前月と定義が変わった、根拠ファイルへアクセスできないといった不一致を先に表示します。

ここでAIの役割は、経営判断そのものを代行することではありません。情報の欠落と矛盾を見つけ、確認すべき問いを並べることです。会議の質を上げるのは、きれいなスライドよりも、前提のずれへ早く気づける仕組みです。

開発ではIssue一覧より変更の影響を追う

GitHubへ接続すると、IssueやPull RequestをまとめるGadgetを作れます。単なる一覧画面なら既存の管理ツールでも十分です。Cloudflare OSらしい使い方は、特定リポジトリへ権限を限定し、変更の目的、関連Issue、未完了テスト、リリース条件を一つの作業画面へまとめることです。

AIはリポジトリの読み取り、差分の説明、テスト結果の整理を担当できます。書き込みを開く場合も、Issueへのコメント、ラベル変更、Pull Request作成、本番反映を同じ危険度で扱わないようにします。コメント案は低リスクでも、秘密情報の変更や本番デプロイは高リスクです。

Cloudflare OS内で試したGadgetが重要になったら、正式なリポジトリへ移し、Codexなどの開発エージェントを使ってテスト、レビュー、リリース工程を追加します。Gadgetは仮説を早く確かめる場所、正式システムは責任を持って保守する場所です。

バックオフィスでは入力補助から始める

経理、人事、法務、総務には定型作業が多く、Gadgetとの相性がよく見えます。しかし、個人情報、金額、契約、労務判断を扱うため、最初から自動処理へ進むのは危険です。

安全な入口は、情報の分類、必要書類の確認、入力候補の作成、期限の通知です。たとえば、申請内容から不足項目を示す、請求書の項目を読み取って候補として並べる、契約更新の確認事項を担当者へ提示するといった使い方です。

承認、送金、契約締結、従業員評価など、結果が人や会社へ直接影響する操作は、人間の判断と既存システムの正式な承認フローを残します。便利さのために責任の所在を曖昧にしないことが重要です。

調査では集める量より根拠へ戻れることを重視する

調査用Gadgetは、Webページ、PDF、社内文書、GitHub、Notionなどを横断し、論点ごとに整理できます。ここでも価値は要約の速さだけではありません。どの主張がどの資料に基づくか、資料の更新日はいつか、反対の証拠があるかを状態として残せることです。

AIは大量の資料から候補を探すのが得意ですが、古い仕様、広報上の表現、推測を混ぜることがあります。Gadget側で出典、確認日、確度、再確認が必要な項目を分ければ、調査結果を後から更新しやすくなります。

とくに制度、料金、製品仕様、医療、法務、金融では、最終判断をAIの文章だけで行わず、原典へ戻れる設計が必要です。Cloudflare OSの接続と状態管理は、その確認作業を仕組みに変えるために使えます。

一度きりの会話を繰り返すならGadgetへ変える

Cloudflare OSを使うべきか判断する簡単な基準があります。同じ依頼を何度もAIへ書き直しているなら、その仕事はGadget化の候補です。

ただし、毎回条件が大きく変わる仕事、正解が一つに定まらない経営判断、頻度が低い仕事は、無理にアプリへしない方がよい場合があります。Gadgetを作ること自体が目的になると、管理対象だけが増えます。

適した仕事には共通点があります。入力と出力がある程度決まっている。状態を保存する価値がある。誰が何を確認するかを決められる。失敗したときに戻せる。成果と費用を測れる。この条件がそろうほど、会話を専用画面へ変える価値が高まります。

この視点から見ると、Cloudflare OSの本質は「誰でもアプリを作れること」だけではありません。組織内で繰り返されるAIとの会話を、権限と責任を持った小さな業務システムへ変換することです。

組織の規模によって使い方は変わる

同じ仕組みでも、個人、スタートアップ、大企業、開発会社では価値と危険が変わります。規模が大きいほど、便利さより統制の追加が主な仕事になります。

個人では自分専用の仕事道具として使える

具体的に役立つ用途

自分専用の資料生成・調査環境
Home Assistant連携
GitHubプロジェクトの可視化
個人用ダッシュボード
ローカルLLMを利用した小規模アプリ生成
自分だけの定期レポート
データを持ち出さない個人ツール

この使い方で得られる価値

SaaSの機能追加待ちが不要
自分だけのコードを変更できる
Blueprintで再利用できる
Cloudflareまたはworkerdへ移行余地がある

スタートアップでは小さな社内ツールを素早く試せる

具体的に役立つ用途

社内業務の小さなツールを高速生成
GitHub、Google Workspace、Slack、Notionを横断した経営情報ビュー
営業・CS・開発の定期レポート
会議準備
調査から提案資料までの一貫作業
非エンジニアによる安全な社内アプリ試作
顧客別・案件別の専用Gadget

安全に始めるための方針

最初から全社員・全データへ接続しない
まずGitHubの特定repo、Google Driveの特定フォルダ等へ限定する
書き込みは最初の1か月すべて手動承認
外部送信・削除・権限変更は自動承認禁止
成功したGadgetだけBlueprint化・標準化する

大企業では統制の追加が導入条件になる

具体的に役立つ用途

部門別AI Workspace
会社固有Context / Skillライブラリ
データソース別Gatekeeper
非技術者向けの小規模業務アプリ生成
ガバナンス付きエージェント利用
既存MCPのPortal経由集約
AI利用コストの部門・人・Workspace別配賦
観測データに追随する共有制御

導入前に満たす条件

SSO/MFA
組織・グループベースAccess Policy
Gatekeeper認定制度
ConnectorごとのData Owner
OAuth Scopeレビュー
データ分類・保持・削除方針
SIEM連携
監査ログ
モデルAllowlist
Prompt Injection対策
インシデントRunbook
Upgrade Gate
試験導入から本番への昇格基準

開発会社の価値は安全な接続と運用設計にある

Cloudflare OSそのものを顧客へ売るより、次が価値になる。

顧客固有Gatekeeperの開発
顧客固有Context / Skillの設計
安全なBlueprintカタログ
部門用Gadgetテンプレート
Access/SSO/監査設計
AI Gatewayと予算管理
運用・評価・監査支援
Cloudflare依存を抑えた移行設計
セキュリティレビュー済みの導入パッケージ

ローカル検証は操作感を確かめるためだけに使う

最初に操作感を確かめるだけなら、ローカル実行が最も軽い方法です。ただし、開発環境は本番より内部ネットワークへ到達しやすく、社内サーバー代わりにはできません。

この方法で確かめたいこと

UIと操作感を確認
Gadget生成を試す
コード構造を理解
非機密データで検証
ローカルモデル接続を試す

ローカル検証はこの手順で始める

git clone <cloudflare-os repository>
cd cloudflare-os
pnpm run-local

その後、`http://localhost:8787`へアクセスする。

始める前に知っておく注意点

本番用ではない
データは`.wrangler`配下へ保存される
`wrangler dev`は開発上の都合でlocalhostやprivate addressへ接続できる
本番の`global_fetch_strictly_public`と同じSSRF制約ではない
公開IPへBindしない
社内共有サーバーとして使わない
実データ・本番OAuth資格情報を入れない
`.wrangler`をバックアップと誤認しない
初期公開直後のため、OS・pnpm・native dependencyによる導入不具合が起き得る

ローカル検証でも環境を分ける

専用MacユーザーまたはVM
専用ブラウザープロファイル
テスト用OAuth App
テスト用GitHub Organization / repo
ダミーGoogle Drive
ローカルLLM
Firewallで外部Inbound遮断
生成Gadgetの外部送信テスト
`.wrangler`削除による初期化手順確認

オンライン配備は最短だが統制には限界がある

ブラウザー中心で最短配備したい場合は、オンラインの配備フローが向きます。ブランド名や基本設定を変える程度なら、リポジトリを管理せずに試せます。

この方法が向く場合

最短で自分のCloudflareアカウントへ配備
Brandingと基本Connectorを試す
コアをForkせず評価
`workers.dev`で限定検証

この方法で得られること

ローカルBuild不要
Cloudflare Access設定
Admin email設定
`/admin`からBranding、Agent instructions、Blueprint、Connectorを変更
GitHubやGoogleは自分のOAuth資格情報を設定

この方法だけでは足りないこと

Dynamic Workersが必要なためWorkers Paidプランが前提
Custom Domain、独自Gatekeeper、細かなログ、固定版運用はStarterの方が適する
自動アップグレード方針をそのまま受け入れず、固定版・変更レビューを検討する

本番候補ではStarterで固定版を管理する

会社として検証するなら、最も現実的なのはStarterを使い、上流版を固定して配備する方法です。最新版へ自動追随するのではなく、差分を読み、検証し、戻せる状態で更新します。

本番候補として最も妥当な経路。

始めるために必要な前提

Node.js 24
pnpm 11
Wrangler認証
Cloudflare Workers Paid
KV
R2
Browser Rendering
Dynamic Worker Loaders
Cloudflare Access
AI製品は任意

配備までの主な手順

git submodule update --init
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login

`deployment.jsonc`で次を設定する。

Cloudflare Account ID
Worker名
Custom Domainまたはworkers.dev
Access issuer / audience
管理者メール
KV / R2
Gatekeeper bindings
AI設定
Observability
Error Reporter

検証・配備：

pnpm check
pnpm deploy

配備後の確認：

Accessで想定IDとしてログインできる
`/admin`の管理者Allowlistが正しい
Context / Gatekeeperのenabled / optional / disabledが正しい
ConnectorのReadがObservationとして記録される
Error Reporterログが取得できる
Workshop / Gatekeeper / Routerのログを確認
Rollback可能なDeploymentを確認
OAuth revokeと再接続を確認
高リスクActionがApproval Queueへ入ることを確認
Blueprintへデータ・資格情報が含まれないことを確認

完全自己ホストは将来の選択肢であり今の標準ではない

CloudflareのOSSランタイムであるworkerdを使い、完全自己ホストへ近づける余地はあります。ただし、公開時点では本番手順が完成していません。

公開時点で分かっていること

Runtime自体はオープンソース
ローカル実行も内部ではworkerdを使う
公式READMEでは本番自己ホスト手順は「COMING SOON」
実験的に構築できても、運用標準は未完成

自己ホストで追加しなければならないもの

Workerd config
Dynamic Worker loader相当
Router
Durable Object storage
KV/R2相当
Browser Rendering代替
Access/SSO代替
Secret Store
AI Gateway代替
Log / Trace
Backup / Restore
Upgrade / Migration
HA
TLS
OAuth callback
SSRF policy
Resource limits

ここまでを踏まえた判断

2026年8月時点では、完全自己ホストは「ロックイン回避の将来オプション」であって、標準的な企業本番経路ではない。

社員へ配る前に会社共通の土台を整える

社員へURLを配る前に、認証、接続先、モデル、ログ、緊急停止の責任を運営側で決めます。利用者が自由にGadgetを作れることと、会社が無秩序に権限を配ることは別です。

配布前に運営側の土台を作る

専用Cloudflare Account/Projectを決定
StarterでUpstream Commitを固定
Access Application、SSO、MFA、Admin Allowlist
Custom Domain
KV/R2/DO/Browser/Dynamic Worker Loader
Error Reporter、Logs、Trace、SIEM
LLM課金経路を決定
Google/GitHub等の専用OAuth App
GatekeeperごとのScope・Action・Revert審査
Incident、Backup、Rollback Runbook

全社員へ共通で渡すものを決める

Branding
Instance Instructions
Public Context Collections
承認済みFormats
Featured Blueprints
Allowed Gatekeepers
Signup Policy
Model Allowlist
Cost Cap

少人数へURLを配って検証する

社員へ配るものは基本的にURLとSign-in手順である。CloudflareやOAuthの設定を各社員へ行わせない。

社員側：

Company URLを開く
Company IdentityでSign-in
Profileを確認
必要なConnectorだけ明示接続
特定Resourceを選ぶ
承認済みBlueprintから開始
External WriteはManual Approval
Usage/Billingを確認

社員による新規Gadget作成を段階的に開く

新規Gadget生成を限定解放
Proposed Diff確認を必須化
Blueprint公開前Review
Data ClassificationごとのConnector制限
High-risk Actionの自動承認禁止
部門Ownerを設定

価値が出たGadgetを正式システムへ昇格する

利用価値が確認されたGadgetを、そのまま無期限に野放しにしない。

昇格基準：

Owner
Requirement
Test
Permission
Backup
Observability
Cost Budget
Runbook
Version
Deprecation
Data Retention

重要GadgetはCodex/Claude CodeでRepository管理された正式Applicationへ移す、または審査済みBundled Blueprintとして固定する。

安全性の中心は生成コードを信用しないことにある

Cloudflare OSの最大の見どころは、AI生成コードを安全だと仮定しない点です。アプリを隔離し、外部通信を閉じ、資格情報を別の部品へ置き、外部操作を承認キューへ送ります。

公開コードから確認できる十の安全設計

Gadgetごとの実行分離

ServerはDynamic Worker
Clientは外部アクセスを制限したiframe
StateはFacetごとのSQLite
他Gadgetと分離
外向き通信は初期状態では何も許可しない設計

これにより、AIが生成したコードへ広いCloudflare Env、API Key、ネットワークを直接与える構成より安全性が高い。

Capability-based Security

Agent/Gadgetは、アカウント全体の権限ではなく、特定リソースへ絞ったRPC Stubを受け取る。

例：

GitHub全体ではなく特定repo
Drive全体ではなく特定ファイル
Slack全体ではなく特定channel
DB全体ではなく特定query interface

資格情報の隔離

OAuth tokenやAPI credentialはGatekeeper側で保持し、Agent/Gadgetへ渡さない。

ReadとActionの分離

ReadはObservationとして記録
外部副作用はAction Queueへ送る
Actionは承認前に実行しない
自動承認は、Action側のautoApprovable判定と、ユーザーが有効化したRuleの両方が必要
Actionは順序通りに処理され、手動承認または失敗を飛ばさない

非同期人が途中で確認する仕組み

Gatekeeperは承認待ちActionをシミュレートし、Agentへ仮結果を返せる。
Agentは停止せず次工程へ進み、人間は最後にまとめて承認できます。ただし、承認ボタンを押す人が目的、影響、停止条件を理解していなければ、安全装置は形だけになります。AIへ任せる範囲と、人間が保持すべき責任の境界は、次の記事で詳しく整理しています。

Observation-aware Sharing

共有相手が、Agent/Gadgetが過去に読んだリソースへアクセス可能か再検証する。単に「MCP Toolを使えるか」ではなく、「どの具体的データを見たか」を共有ポリシーへ反映する。

SSRF対策

Built-in Web Fetchは次を実装する。

HTTPSのみ
GETのみ
URL内Credential禁止
30秒Timeout
1MiB default / 5MiB hard cap
DNS解決後のprivate IP拒否をRuntimeへ委任
`global_fetch_strictly_public`
`Content-Signal: ai-input=no`を尊重

添付検証

最大1MiB
MIME正規化
JPEG/PNG/WebP/PDFのMagic Number確認
Provider別対応形式の制限

管理設定の分離

認証方式等はenv側で固定し、管理画面だけを侵害しても変更できないようにする。
Admin APIは管理者にだけCapabilityを発行する。

Release と Deploymentの分離

StarterはCoreをSubmoduleで固定し、配備時に一時Wrangler設定を生成する。Secretsを追跡対象設定へ入れず、GatekeeperをWorkshopより先に配備する。

接続先ごとにできることと危険度が違う

Gatekeeper Packageの存在は、全機能・全企業用途が成熟していることを意味しない。v2ではREADME、Public Type、Approval/Simulation/Sharing方針を個別確認した。

Google：主な範囲はGmail、Docs、Sheets、Calendar、BigQuery、Writeはあり／Resource別、Simulationは実装別、共有上の注意はGranular Scope、DriveはPicker Metadata
GitHub：主な範囲はRepo、Issue、PR、Writeはあり、Simulationは実装別、共有上の注意はOAuth App Scope自体は`repo`で広い
Slack：主な範囲はWorkspace、Conversation、Thread、Search、Writeはなし、Simulationは不要、共有上の注意はUser Tokenで本人の見える範囲
Notion：主な範囲はWorkspace、Page、Database、Writeはあり、Simulationはあり、共有上の注意はPending WriteをReadへOverlay
Confluence Cloud：主な範囲はSite、Space、Page/Blog、Comments等、Writeはあり、Simulationはあり、共有上の注意はCloudのみ、Markdown変換はBest-effort
Supabase：主な範囲はProject/Organization、SQL等、Writeはあり、SimulationはMutating SQLはなし、共有上の注意はSQL WriteはApproval後のみ
Home Assistant：主な範囲はInstance/Area/Label/Device/Entity、Writeはあり、Simulationはあり、共有上の注意はLLATは長寿命、Public reachability注意
Spotify：主な範囲はAccount/Playlist/Playback、Writeはあり、SimulationはLibrary等あり、Playbackなし、共有上の注意はPlaybackはPremium要件
ZoomInfo：主な範囲はSearch/Enrich/Copilot/Usage、WriteはCredit消費Action、Simulationはなし、共有上の注意はEnrichはCost承認、awaitDecision
MCP：主な範囲はUser-supplied Server/Named Tools、Writeはあり、Simulationはなし、共有上の注意はOwner-only、BYO annotation tradeoff
MCP Portal：主な範囲はAdmin portal内の1 server/Named Tools、Writeはあり、Simulationはなし、共有上の注意はTrust annotationは明示Opt-in
Scheduler：主な範囲はInterval/Calendar/One-shot callback、Writeは登録・Hook、Simulationは該当せず、共有上の注意はRead-only管理UI、8 attempts
Email：主な範囲はInbound mailbox hook、WriteはInbound event、Simulationは該当せず、共有上の注意はCloudflare Email Routing必要
Context：主な範囲はPublic/Private Context Collection、WriteはContext編集、Simulationは該当せず、共有上の注意はPublicはAdmin編集、PrivateはOwner
Cloudflare：主な範囲はSign-in、AI Gateway Billing、WriteはBilling接続、Simulationは該当せず、共有上の注意はWorkers/R2管理Capabilityは未実装
Linear：主な範囲はPackage/Connectorあり、Writeは個別Code監査要、Simulationは個別、共有上の注意はREADME不在、Source/Typeを採用前確認
Others：主な範囲はPackageが存在、Writeは実装別、Simulationは実装別、共有上の注意はProduction前に個別Gate

Google Workspace全体を勝手に学習するわけではない

Cloudflare OSが社員のGoogle Workspace全体を自動学習・常時Indexするわけではない。

主な方法は二つ。

Google Gatekeeper

社員がGoogle Accountを接続し、Gmail、Doc、Spreadsheet、Calendar、BigQuery等のResourceを選ぶ。Agent/GadgetはBindingを通して、そのResourceへアクセスする。

Gmail：`gmail.modify`
Docs：Document Scope
Drive：Doc/Sheet Picker用のMetadata Read
Sheets：Read-only
Calendar：Calendar List Read + Events
BigQuery：Job実行に必要なScopeを取得するが、GatekeeperがRead-only SQLとResource Scopeを検査

Context Library

会社や社員がContext Documentを明示的に作成・管理する。

Public Collection：Deployment Adminだけが作成・編集、全社員がRead
Private Collection：各Account OwnerだけがRead/Write
WorkspaceへAmbient Bindingとして提供可能
Collection、User Library、Public Registryを別DOで管理
`sharingDomain`で複数Workshop間を分離

つまり、Google Resourceは外部System of Record、Context LibraryはAIへ与える整理済み知識層として使い分ける。

強い隔離があっても消えない危険がある

ここで「だから安全」と結論づけるのは危険です。境界を越えにくくしても、許可された範囲での誤操作、承認者の誤認、中枢部品の不具合、費用暴走は残ります。

生成コードの事故をゼロにはできない

Gadgetが次を起こす可能性は残る。

同じGadget内部の情報漏えい
誤ったUI表示
誤計算
データ破損
権限のある範囲での誤操作
利用者を誤認させるUI
大量処理によるDoS
高額モデルの反復呼び出し
承認者を騙す説明
機密情報を出力本文へ混ぜる
入力された機密情報を許可済み接続先へ送る
誤った共有対象の選択

プラットフォームが抑えるのは、主にGadget境界を越える権限行使である。

安全性が中枢へ集中するという別のリスクがある

安全性は次へ集中する。

`workshop-backend`
`workshop-shared`
Dynamic Worker Runtime
Router
Gatekeeper
Access設定
OAuth App
Sharing / Observer実装
Approval Queue
Release/Deploy Pipeline

この層のバグは多数のGadgetへ波及する。

持ち込みMCPの自己申告を信用しすぎてはいけない

コード上、ユーザーが直接追加した利用者が持ち込むMCPでも、サーバーが`readOnlyHint: true`と宣言するとReadとして扱われ、承認なしで実行される。

これは実装コメントでも明示的なトレードオフとされている。

リスク：

悪意あるMCP Serverが、実際には書き込みを行うToolをread-onlyと偽装
Toolが副作用を持つのにObservationとして即時実行
ユーザー承認を迂回

推奨：

企業環境では利用者が持ち込むMCPを初期無効化
Adminが管理するMCP Portalだけを許可
Portal Endpointをvettedとして審査
BYO ToolはすべてAction扱いへ変更するForkも検討
Tool Catalog fingerprint変化時は再審査
readOnly判定をServer自己申告だけに依存しない

仮の成功と実際の結果がずれる可能性がある

Gatekeeperのシミュレーションは強く推奨されるが、契約上すべての実装で必須ではない。

想定問題：

Agentが仮の成功結果を前提に後続Actionを作る
実際の適用時に最初のActionが失敗
後続Actionとの整合性が崩れる
Batch Approval中に一部だけ成功
Revert未実装
APIが冪等でない
外部状態がAgent実行中に変化

必要対策：

ActionごとのIdempotency Key
Apply順序
Failure Stop
Partial Success表示
Reconciliation
Revert/Compensating Action
再実行ポリシー
Agentへ仮結果であることを明示
最後に適用した変更状態の画面表示

読んだ情報の追跡はまだ完全ではない

Gatekeeper契約には`prohibitAllSharing`等がある一方、より詳細な情報フローポリシーは今後拡張する意図がコードコメントに見られる。

現状の課題：

Gadget/Workspace単位の粗い共有禁止になり得る
ThreadやField単位のきめ細かな再認可が不十分
過剰拒否が起きる可能性
Data Lineageの正確性がGatekeeper実装に依存
生成テキスト内の機密情報を完全追跡できるわけではない

狭い画面の裏で広い認証権限を持つ場合がある

GatekeeperがGadgetへ狭いCapabilityを提供しても、Gatekeeper自身が持つOAuth Tokenは広いScopeを持つ場合がある。

例：

GitHub OAuthの`repo`
Google APIの広いDrive Scope
Slack Workspace Scope

Gatekeeper侵害時のBlast Radiusは、Capability表面より大きい可能性がある。

必要対策：

専用OAuth App
最小Scope
Test/Production分離
Token Rotation
Revocation
接続アカウント削除
Provider側Audit Log
Gatekeeper Workerの独立監査
Secret Store
出力のField Masking

共有リンクはパスワードと同じように扱う

ServerがShare KeyのHashだけを保存していても、リンク自体はBearer Secretである。

漏えい経路：

Copy/Paste
Screenshot
Chat
Browser Extension
Clipboard History
URL保存
誤送信

必要対策：

短い有効期限
One-timeまたは回数制限
Domain/Identity制限
Ownerによる即時失効
Access認証との併用
Share Link作成・利用ログ
機密Gadgetでは無効化

ローカル検証は本番より内部ネットワークへ届きやすい

Production/workerdではprivate IP向けFetchを制限するが、`wrangler dev`はlocalhost接続を許可する。

したがってローカル実行を社内共有した場合、次のリスクがある。

localhost管理画面へのSSRF
開発端末の内部サービス探索
metadata endpointやLAN資源へのアクセス
開発者資格情報の窃取

ローカル環境は必ず単一利用者・非公開・非機密で使用する。

添付の形式確認だけでは安全にならない

Magic Number確認は、ファイルが安全であることを保証しない。

残るリスク：

悪意あるPDF
Parser脆弱性
巨大展開
Prompt Injectionを含む文書
埋め込みリンク
誤認させる画像
Model Providerへの外部送信

必要対策：

Malware Scan
Sandbox変換
Content Disarm
Prompt Injectionラベル
Data Classification
Provider送信前Consent
機密添付のモデル制限

統合テストがあっても未検証の部分は残る

リポジトリはIntegration Test Harnessを持つが、`AGENTS.md`は「多くのpackageにテストがない」と明記する。
実サービスのGatekeeper Vendor Testがすべてコアrepo内で網羅されているわけでもない。

企業本番では、次を追加する必要がある。

Gatekeeper Contract Test
OAuth Reconnect / Revoke
Tenant Isolation
Observer Reverification
Sharing Regression
Approval Ordering
Revert
Prompt Injection
SSRF
Cost Limit
Backup/Restore
Migration
Browser Sandbox
Supply Chain
UAT

早期公開版では自動追随より固定と差分確認が重要になる

公開直後であり、Starter自身が次を要求する。

Upstreamをpin
Production Upgrade前にTrust Boundaryを確認
変更履歴を確認
Rollbackを準備

本番で`main`を自動追従すべきではない。

優先して備えるべき脅威を影響と対策で整理する

実務では、危険を抽象語で語るだけでは足りません。何が起き、どの仕組みで抑え、何が残るのかを具体的に並べる必要があります。

AI生成Gadgetの外部データ流出：可能性は中、影響は高、現在の防御はOutbound無効、Capability、追加すべき対策はGatekeeper監査、DLP、対策後も残る危険は中
利用者が持ち込むMCPがWriteをReadと偽装：可能性は中、影響は高、現在の防御はAnnotation分類、追加すべき対策はBYO無効、全Action化、対策後も残る危険は低〜中
Gatekeeperの認可バグ：可能性は中、影響は高、現在の防御は型、独立Worker、追加すべき対策は2者レビュー、Contract Test、対策後も残る危険は中
OAuth Token過大Scope：可能性は中、影響は高、現在の防御はCredential隔離、追加すべき対策は最小Scope、専用App、Rotation、対策後も残る危険は中
Prompt Injectionで危険Action生成：可能性は高、影響は高、現在の防御はApproval Queue、追加すべき対策は高リスク強制手動、入力隔離、対策後も残る危険は中
承認者が説明を誤信：可能性は中、影響は高、現在の防御はAudit Description、追加すべき対策はDiff/Recipient/Scope強調、対策後も残る危険は中
非同期Simulationと実状態の乖離：可能性は中、影響は中〜高、現在の防御はQueue、順序制御、追加すべき対策はIdempotency、Reconciliation、対策後も残る危険は中
Share Link漏えい：可能性は中、影響は高、現在の防御はHash保存、Revocation、追加すべき対策はTTL、Identity制限、対策後も残る危険は低〜中
共有相手へのData Leak：可能性は低〜中、影響は高、現在の防御はObservation Recheck、追加すべき対策はE2E、Data Lineage検証、対策後も残る危険は中
Local Dev SSRF：可能性は中、影響は高、現在の防御は本番strict public、追加すべき対策はDev非公開、VM分離、対策後も残る危険は低
Gadget内データ破損：可能性は中、影響は中、現在の防御はGadget分離、追加すべき対策はVersion/Backup/Undo、対策後も残る危険は中
AI/Workerコスト暴走：可能性は中、影響は高、現在の防御はAI Gateway、Runtime limit、追加すべき対策はBudget、Rate Limit、Kill Switch、対策後も残る危険は低〜中
Dynamic Worker DoS：可能性は中、影響は中〜高、現在の防御はIsolate、追加すべき対策はCPU/Subrequest Limit、対策後も残る危険は中
Supply-chain侵害：可能性は低〜中、影響は高、現在の防御はLockfile、Pinned Starter、追加すべき対策はSBOM、署名、Diff review、対策後も残る危険は中
Admin Session侵害：可能性は低〜中、影響は高、現在の防御はAccess、env auth config、追加すべき対策はMFA、Admin最小化、監査、対策後も残る危険は中
Malicious Attachment：可能性は中、影響は中〜高、現在の防御はSize/MIME/Magic、追加すべき対策はAV/CDR/Sandbox、対策後も残る危険は中
Model Providerへの機密送信：可能性は中、影響は高、現在の防御はModel config、追加すべき対策はData policy、ZDR、local model、対策後も残る危険は中
Backup/Restore不備：可能性は中、影響は高、現在の防御は未成熟、追加すべき対策は定期Restore Test、対策後も残る危険は中
Upgrade regression：可能性は高、影響は高、現在の防御はPin/Rollback、追加すべき対策はCanary、Test、ADR、対策後も残る危険は中
自己ホスト運用不備：可能性は高、影響は高、現在の防御はworkerd runtime、追加すべき対策は公式tooling待ち/専門設計、対策後も残る危険は高

安全に使うには接続と書き込みを段階的に開く

安全運用の基本は、最初から全部をつながないことです。読み取り専用、限定リソース、テストアカウント、手動承認という順番で、権限を一段ずつ開きます。

導入前に分離と責任者を決める

専用Cloudflare Accountまたは最低でも専用Project/Zoneを使う
Productionと試験導入を分離
Cloudflare Access + SSO + MFA
Adminは2〜3名以下
Workers Paid費用とDynamic Workers課金を試算
Model Provider契約・データ利用条件を確認
Data Classificationを作る
接続候補ごとにData Ownerを決める
GatekeeperごとのRead/Write/Scope/Revertを表にする
利用者が持ち込むMCPを無効
Sourceを固定Commit/SubmoduleへPin
SBOMとDependency Scan
Incident Runbook
Rollback確認

最初はAIも接続先も閉じた状態から始める

AIは無効のまま基盤を先に配備
Access Loginを検証
`/admin` Allowlistを確認
Connectorはすべてdisabledまたはoptional
Contextは公開/非公開を分離
LogsへPrompt・Token・本文を出さない
Browser Reportingは無効
Custom Domain
Error Reporter
OTLP/SIEM
AI Gateway Budget
Dynamic Worker Usage Alert
KV/R2/DOのBackup方針
Share Linkを無効またはTTL付き

接続先は読み取りから段階的に解放する

順序：

Read-only Connector
特定Resourceのみ
Test Account
Observation確認
Sharing Recheck
Manual Approval付きWrite
Revert検証
Production Account
限定ユーザー
定期棚卸し

高リスクAction：

削除
Merge
External Send
Payment
Permission Change
Account Change
Production Deploy
Contract
HR
Customer Notification

これらはAuto-approve禁止。

モデルごとに機密度と費用の上限を決める

Model Allowlist
Provider別Data Retention確認
機密度別Model Route
Local / private endpointの利用条件
Token/Cost上限
Context Window上限
Attachment可否
Model変更時Regression
Prompt/Skill Version
Output Schema
Hallucination時Fallback
重大判断をAIへ委任しない

承認画面を読む力が最後の防波堤になる

承認画面で必ず確認する項目：

どのサービスか
どのResourceか
ReadかWriteか
Recipient
Branch / repo / file
差分
削除対象
共有範囲
外部送信データ
料金
Revert可否

禁止事項：

内容を読まずBatch Approve
本番Tokenをローカル環境へ入力
未審査MCP URLの追加
Share Linkをチャットへ貼付
機密データを任意モデルへ投入
AIの「成功しました」を実行証拠にする
Gadgetを基幹台帳の唯一の基準資料にする

異常を早く見つける監視項目を決める

最低限のAlert：

Login失敗増加
Admin変更
Connector追加
OAuth Expiry / Bad Credential
Approval Failure
Revert Failure
Observation Denial
Share Link作成
Collaborator追加
AI Cost急増
Dynamic Worker数急増
CPU/Request急増
Error Reporter増加
Repeated Prompt Injection
Unauthorized outbound attempt
Upgrade後Regression

四週間の試験で価値と危険を同時に測る

試験導入では、便利だったかだけを測ると判断を誤ります。価値、事故、費用、管理者負荷、復旧可能性を同時に測り、本番へ進む条件と停止条件を先に決めます。

最初の検証は十名前後に限定する

5〜20人
4週間
非機密または社内一般データ
2〜3個のConnector
3つ以下の標準Blueprint
書き込みは手動承認
利用者が持ち込むMCPなし
個人情報・顧客秘密・契約・決済なし

検証する業務は証拠が残る読み取り中心から選ぶ

GitHub特定repoのIssue可視化
Google Drive特定フォルダの会議準備
Slack特定channelの週次まとめ
社内Contextを使った資料下書き
既存レポートを更新するGadget
定期タスクのRead-only収集

便利さだけでなく事故と運用負荷も測る

初回価値到達時間
Gadget生成成功率
手動修正回数
Agent task完了率
Approval件数
Approval拒否率
Action失敗率
Revert成功率
Observation拒否件数
共有成功率
重大情報漏えい 0件
誤外部送信 0件
1人あたりAI費用
1GadgetあたりDynamic Worker費用
利用継続率
既存作業時間削減
管理者運用時間

本番へ進む条件を先に決める

重大または重要なセキュリティ事故が0件
対象ユースケースの70%以上で実務価値
高リスクActionが100%手動承認
OAuth revoke/reconnect成功
Restore Test成功
Upgrade/Rollback Test成功
Cost予算内
共有時の権限再検証成功
Gatekeeper Contract Test合格
利用者が承認内容を理解できる

価値はあるが仕組みが重い場合は範囲を狭める

Agent chatは有用だがGadget生成が不安定
Gadgetは有用だが共有・Observerが複雑
Gatekeeper開発コストが高い
非技術者の修正依頼が期待ほど成功しない
Model Costが高い
Context品質が低い

Pivot例：

Gadget生成を管理者だけへ限定
承認済みBlueprintのみ利用
Read-only Agent Workspaceへ縮小
Custom Gatekeeperを1〜2個へ限定
高性能モデルを構築時だけ利用
定常実行は通常コードへ置換

重大事故と統制不能を停止条件にする

Cross-user Data Leak
OAuth Token漏えい
利用者が持ち込むMCPによる承認迂回
重大な誤外部送信
共有再認可の破綻
Restore不能
Cost Kill Switch不動作
管理者負荷が削減効果を上回る
Gatekeeperの安全性を監査できない
法務・規制要件を満たせない

AIを配るだけでなく、業務の選定、権限設計、研修、開発、導入後の改善まで支援が必要な場合の相談内容は、次の記事にまとめています。

狙っているのは一人ひとりが自分用ソフトを持つ働き方である

機能一覧を離れて考えると、Cloudflare OSの狙いはより大きく見えます。既製SaaSを全員が同じ形で使うのではなく、一人ひとりが仕事に合わせて小さなソフトを持つ世界です。

SaaSの次には個人ごとのソフトウェアが増える

従来のSaaS：

1つの中央コード
全顧客が同じ機能
機能要望はVendorへ
Vendorが優先順位を決める
顧客は設定だけを変更

Cloudflare OS：

Gadgetごとに独立コード
利用者が自分のコピーを変更
Blueprintを配布
AIが変更を支援
RuntimeがSecurity Boundaryを担う

これは「ソフトウェアをサービスとして借りる」から、「安全な実行基盤上で自分専用ソフトウェアを持つ」への転換である。

MCPだけでは扱えない権限と責任まで設計する

MCPはToolを提供する。
Cloudflare OSはさらに次を扱おうとする。

具体的Resource Scope
Credential隔離
読み取ったデータの履歴
共有先の再認可
外部操作の承認
操作のシミュレーション
CapabilityのGadgetへのBinding
Agentと人間の同一API利用
Audit

したがって、Gatekeeperは単なるMCP互換レイヤーではなく、接続先の具体的なデータまで理解する認可の仲介層に近い。

会社の知識を再利用できる資産へ変える

ContextとSkillを共有すると、組織の暗黙知を次の形へ変換できる。

用語
手順
判断基準
テンプレート
基準資料
禁止事項
エスカレーション
評価基準

ただし、Contextの更新責任者、版管理、期限、廃止、矛盾解消が必要である。Contextを増やすだけでは、古い社内ルールをAIへ固定する危険がある。

毎回AIに考えさせず定型処理をコードへ戻せる

公式説明の重要点は、毎回Agentを動かすのではなく、定型処理をGadgetや通常コードへ変換できることにある。

理想的な変換：

初回：Agentが探索・設計・コード生成
  ↓
検証：人間が確認
  ↓
定常：通常コードで実行
  ↓
例外：判断部分だけModel

これにより、Token、Latency、再現性、監査、コストを改善できる。

導入後に増えるのはアプリだけではなく管理責任である

社員が自由にGadgetを作れるようになると、最初は生産性が上がります。しかし、数が増えるほど別の問題が現れます。誰が所有しているのか、元データへまだアクセスしてよいのか、退職者が作ったGadgetをどうするのか、同じ用途のGadgetが何個あるのか、どれが古いのかが分からなくなります。

これは従来のシャドーITと似ています。違うのは、AIによって作成速度が大幅に上がることです。月に数個ではなく、一日に何個も小さなアプリが生まれる可能性があります。生成を許可するだけでは、便利な道具と放置された資産が同時に増えます。

企業利用では、標準管理画面の外側に少なくとも次の台帳が必要です。

Gadgetの名前、目的、所有者、利用者
接続している外部サービスと具体的なデータ
読み取りと変更の権限
使用モデルと費用負担者
最終利用日と見直し期限
バックアップと復旧方法
重要度と正式システムへの昇格候補
退職、異動、組織変更時の移管先
廃止日とデータ削除の確認

すべてを中央管理すると、せっかくの個人カスタマイズが遅くなります。反対に、完全な自由へすると、費用と情報漏えいと保守不能が増えます。現実的なのは、危険度に応じて管理を変えることです。

公開情報だけを読む個人用Gadgetは、簡単な登録と自動期限でよいでしょう。顧客データへ接続するGadgetは、所有者、権限、利用期限、監査を必須にします。契約や決済へ影響するものは、個人Gadgetのまま運用せず、正式な開発工程へ移します。

Cloudflare OSの導入で本当に設計すべきなのは、Gadgetの作り方だけではありません。小さなソフトが大量に生まれた後、どれを残し、どれを育て、どれを止めるかというライフサイクルです。ここを準備しなければ、生成速度がそのまま管理負債の増加速度になります。

設計の独自性は高いが導入側の負担も大きい

Cloudflare OSは、発想の新しさだけを見れば非常に魅力的です。しかし、技術選定では「できること」と「自社が引き受ける運用」を同時に見る必要があります。

独自性はGadget単位の分離と権限管理にある

Gadgetごとにコードと状態を分離し、外部サービスへ接続するときはGatekeeperを通す構造は強いです。AI生成アプリへ認証情報を直接渡さず、読み取りと変更を分け、共有相手の権限も確認し直す。これらが一つの環境へ統合されている点は、単純なチャット画面やMCP接続集とは異なります。

開発速度も期待できます。一般的なWebアプリより実装対象が限定され、画面とサーバー間の通信方法、状態の置き場所、外部接続の経路が決まっているからです。AIにとって自由度が低いことが、ここではむしろ利点になります。

モデルは交換しやすいが実行基盤への依存は残る

OpenAI、Anthropic、Google、Workers AI、Ollamaを選べるため、特定の推論モデルだけへ固定されにくい設計です。モデルを変更しても、Gadget、Gatekeeper、共有、承認の仕組みは残せます。

一方、現在の実用的な配備方法はCloudflare Workers、Durable Objects、Dynamic Workers、KV、R2などへ深く依存します。`workerd`を使った自社サーバー運用の余地はありますが、公式READMEも本番向けの手順と道具が未完成だと明記しています。モデルの乗り換えやすさと、実行基盤の乗り換えやすさは分けて評価すべきです。

非技術者が使えても導入と保守は技術者の仕事になる

社員はブラウザーから自然な言葉でGadgetを作れます。しかし、その入口を用意する側には、Cloudflare Access、OAuthアプリ、秘密情報、Gatekeeper、ログ、費用、更新、障害対応の知識が必要です。

とくに企業独自のシステムへつなぐ場合、Gatekeeperは単なるAPIラッパーではありません。何を読めるか、何を変更できるか、どの操作を承認対象にするか、取り消し可能か、共有相手へ何を見せるかを実装するセキュリティ部品です。ここをレビューできる人材がいなければ、Cloudflare OSの安全設計を十分に生かせません。

現時点では完成品より先進的な開発基盤に近い

公開版は早期公開段階で、Cloudflare OS v2自体が全面的な再構築版です。Starterは固定した上流版を使い、変更を確認してから更新する運用を強く勧めています。これは成熟したSaaSのように自動更新へ任せる製品ではなく、自社で版を管理し、試験し、戻せる組織が使う基盤だということです。

したがって、独自性と将来性は高く評価できますが、現在の実装成熟度、自己ホスト、本番運用の容易さ、規制対応は慎重に見る必要があります。「今すぐ全社の仕事を置き換える製品」ではなく、「次の仕事環境を限定業務で検証するための基盤」と捉えるのが適切です。

Gadgetに向く業務かを五つの問いで見分ける

Cloudflare OSを導入すると、作れるものが多いため、何から始めるか迷います。最初の用途は、話題性や部門の声の大きさではなく、次の問いで選ぶと失敗を減らせます。

入力と成果物を具体的に説明できるか

「営業を効率化する」「経営判断を支援する」といった大きな目的だけでは、Gadgetの要件を決められません。何を入力し、どの情報を参照し、誰がどの画面を見て、最後に何を決めるのかを説明できる必要があります。

たとえば「毎週月曜日に、担当案件の更新状況をGitHubとCRMから読み、未更新の案件と次の確認事項を一覧にする」まで具体化できれば、必要な接続、状態、出力、評価を設計できます。反対に、目的が「売上を伸ばす」のままでは、AIがもっともらしい画面を作っても成果を測れません。

最初のGadgetは、完成状態を一文で説明できる業務を選びます。

読み取りだけでも価値を出せるか

安全な試験導入では、現実を変更する操作をできるだけ避けます。そこで重要なのが、読み取りだけでも価値があるかという問いです。

情報を集める、差分を見つける、期限を知らせる、候補を作る、確認事項を並べる。これらは外部サービスを書き換えなくても実行できます。読み取りで価値を確認してから、コメント投稿、更新、送信などを一つずつ開けば、事故原因を切り分けやすくなります。

最初から送信や削除が不可欠な業務は、試験対象としては難易度が高いです。既存の正式な承認フローを残せない場合は、Cloudflare OSで始める必要があるかを再検討します。

正しさを後から検証できるか

AIの出力が正しいかを、その場の印象だけで判断してはいけません。元資料、計算式、変更差分、実行ログなどへ戻れる業務を選ぶと、評価と改善ができます。

公開情報の調査なら出典URL、Issue集計なら対象リポジトリと検索条件、レポートなら元データと更新時刻が必要です。人によって正解が大きく変わる仕事でも、少なくとも何を見て判断したかを残せる必要があります。

検証できない仕事を自動化すると、間違いに気づく手段まで失います。Cloudflare OSの監査やObservationは、記録があるだけで価値を生むわけではありません。誰が、いつ、何を確認するかまで決めて初めて機能します。

失敗しても止めて戻せるか

試験導入では、成功方法より先に失敗時の処理を考えます。接続を切れるか、共有を失効できるか、前のGadgetコードへ戻せるか、誤って更新したデータを修復できるかを確認します。

読み取り専用のダッシュボードなら、停止は比較的簡単です。外部サービスへ大量の変更を行うGadgetは、取り消しや補償処理が難しくなります。GatekeeperにRevert機能があっても、外部サービスのすべての操作が完全に元へ戻るとは限りません。

戻せない操作が含まれる場合は、一件ずつ承認する、対象件数を制限する、テスト環境だけで実行するなど、影響範囲を先に狭めます。

繰り返し使う価値が管理負担を上回るか

Gadgetは簡単に作れても、作った後には所有者、権限、費用、更新、廃止の管理が必要です。一度しか使わない作業へ専用Gadgetを作ると、作成時間よりも後始末の方が大きくなる場合があります。

毎週、毎月、複数人が繰り返す仕事は候補になります。手作業の時間だけでなく、確認漏れ、形式のばらつき、引き継ぎ負担を減らせるかも見ます。一方、年に一度しか起きない例外処理や、毎回判断基準が変わる仕事は、通常のAI会話や人間の手順書の方が適しているかもしれません。

Gadget化の判断では「作れるか」ではなく、「残して管理する価値があるか」を問います。五つの問いに答えられない業務は、まず手作業とAI支援で流れを理解し、標準化できてからGadgetへ移す方が安全です。

導入すべき組織と見送るべき組織は分かれる

向いている組織は、Cloudflare基盤を理解し、接続先を絞り、セキュリティと運用へ人を割ける組織です。逆に、完成済みSaaSのような保証を求める場合は時期尚早です。

次の条件がそろう組織には向いている

Cloudflare Workersを既に利用
社内AI Workspaceを自社管理したい
非技術者に小規模アプリ生成を許可したい
MCPより細かなResource Scopeと監査が必要
自社Gatekeeperを開発できる
早期公開版を受け入れられる
小さく試験導入できる
Security/Platform Engineering担当がいる

次の条件では今は見送った方がよい

直ちに全社本番SLAが必要
オンプレミス必須
Cloudflare利用不可
Gatekeeperを監査する人材がいない
規制データを最初から扱う
自動承認を前提とする
Backup/Restore/HAの完成済み製品が必要
単純なChat/RAGだけで十分
Microsoft 365やGoogle Workspaceの標準Copilotで課題が解決する

推奨する導入形を一つに絞る

Cloudflare OSを、全社AI OSとして即時導入するのではなく、
**「非機密業務向け・承認済みBlueprint型の部門AIワークベンチ」**として限定導入する。

初期構成：

Cloudflare Starter
Access SSO/MFA
10ユーザー
GitHub・Google・Contextのみ
利用者が持ち込むMCP無効
自動承認無効
3つの審査済みBlueprint
4週間
AI Gateway Budget
OTLP/SIEM
Weekly Security Review
1回のUpgrade/Rollback演習

これが、価値とリスクの両方を最も低コストで検証できる。

本番運用では固定版と反復検証が欠かせない

一度のセキュリティ確認だけでは不十分です。Cloudflare OSは更新され、接続先のAPIも変わり、社員が作るGadgetも増えます。安全性を維持するには、同じ検査を変更のたびに繰り返せる仕組みが必要です。

プロジェクトの安全原則を文書へ固定する

リポジトリには、少なくとも次の方針を明文化します。

どのデータを扱ってよいか
Gatekeeperが負う責任
利用者が持ち込むMCPを許可する条件
必ず人が承認する操作
OAuthで要求してよい最大権限
読み取ったデータと共有権限を照合する原則
Blueprintへ含めてはいけない情報
ログから削除する秘密情報と個人情報
モデル、利用者、チームごとの費用上限
バックアップ、移行、復旧、ロールバックの手順

ファイル名は`AGENTS.md`でも、組織内の設計標準でも構いません。重要なのは、レビュー担当者とAIエージェントが同じ基準を参照できることです。

監査作業を再利用できる手順へする

Gatekeeperを追加するたびに、担当者の記憶だけで確認してはいけません。OAuth権限の確認、読み取りと変更の分類、共有境界、Blueprintの漏えい、プロンプトインジェクション、費用上限などを、再実行できる手順へします。

たとえば「新しいGatekeeperをレビューする」「共有相手の権限を検証する」「アップグレード前に差分を調べる」「障害時に前版へ戻す」といった作業を、チェックリスト、スクリプト、AI向けSkillとして用意します。人が判断すべき箇所は残しつつ、確認漏れを減らします。

自動テストで毎回同じ確認を行う

最低限、型検査、静的解析、単体テスト、統合テストに加え、Cloudflare OS固有の境界を検証します。

Gatekeeperの契約と権限表
外部URL取得時のSSRF対策
秘密情報と依存関係の検査
Blueprintへデータや資格情報が入らないこと
共有相手が権限外のデータを読めないこと
承認待ち操作の順序が崩れないこと
拒否、取り消し、再実行が正しく動くこと
モデルと利用者ごとの費用上限
データ移行、バックアップ復元、前版への切り戻し

Cloudflare OS本体に統合テストがあっても、自社のOAuth設定、独自Gatekeeper、ログ保存先、共有方針までは保証してくれません。自社構成を対象にした回帰テストが必要です。

変更の危険度に応じてレビューを変える

文言やブランド色の変更と、認証や共有の変更を同じ手続きで扱うべきではありません。

低い危険度には、表示文言、ブランド設定、説明文、読み取り専用画面などが含まれます。通常レビューと自動テストで進められます。

中程度の危険度には、Gadgetのひな型、読み取りAPI、会社Context、Scheduler、監視設定などが含まれます。影響範囲の確認と、限定環境での試験が必要です。

高い危険度には、Workshopの中枢、共通API、Gatekeeper、OAuth、共有、Observer、承認、自動承認、管理者権限、Dynamic Worker Loader、Blueprint出力、データ移行が含まれます。二人以上によるレビュー、独立テスト、少人数への先行配備、即時に戻せる手順を必須にします。

Starterが上流版を固定し、更新前のレビューを求めているのは、この運用を前提としているからです。公開直後の`main`へ自動追随するより、採用版を固定し、差分を読み、試験し、問題があれば戻す方が安全です。

無料のOSSでも運用費とモデル費は発生する

OSSだから無料、Cloudflareだから月五ドルだけ、ChatGPT Proを契約しているから追加のモデル料金は不要。この三つはいずれも誤解です。費用は複数の層に分かれます。

費用はCloudflare本体だけでは終わらない

Cloudflare OSのソースコードはApache 2.0で利用できるが、運用費がゼロになるわけではない。

Cloudflare Runtime：Workers Paid、Dynamic Workers、Durable Objects、KV、R2、Browser Rendering
LLM inference：OpenAI、Anthropic、Google、Workers AI等
AI Gateway：Coreは主に無料、Unified Billing Credit手数料、Guardrails等
External SaaS/API：Google Workspace、Slack、GitHub、Notion、ZoomInfo等
Observability/Security：Logs、Logpush、SIEM、Zero Trust、DLP
People/Operations：OAuth App、Gatekeeper監査、Support、Upgrade、Incident、Backup

一般向け月額プランをAPI料金へ充当することはできない

通常のProvider API接続では使えない。

ChatGPT Plus/Pro/Business等とOpenAI APIは別請求・別管理
Claude.ai Pro/Max/Team等とAnthropic API Consoleは別請求
Gemini APIはGoogle AI StudioまたはGoogle Cloudの請求で管理され、Geminiアプリの個人向けプランとは別に考える必要がある

したがって、Cloudflare OSのOpenAI/Anthropic/Google Model Routeは、原則としてAPIまたはCloudflare Unified Billingを利用する。

例外的に、Cloudflare OSへCodex SDKや別Consumer Product認証を独自統合することは理論上可能だが、標準実装ではなく、利用条件・認証・再配布・課金を別設計する必要がある。

モデル料金の払い方には複数の経路がある

各AI企業のAPIキーを直接使う

Cloudflare OS
  └─ AI Gateway（任意）
       └─ OpenAI / Anthropic / Google API

ProviderでAPI Accountを作成
API KeyまたはGateway Tokenを設定
Token量等に応じてProviderが請求
Chat Consumer Subscriptionとは別

Cloudflareへまとめて支払う

Cloudflare OS
  └─ Cloudflare AI Gateway
       ├─ OpenAI
       ├─ Anthropic
       └─ Google AI Studio

Cloudflare AccountへCreditを購入
Provider Keyを個別管理せず利用可能なRouteがある
Provider推論価格は原則Pass-through
Credit購入に5% Fee
Workers AIは別のWorkers AI Pricing
Credit残高が負になる可能性があり、翌月請求される場合がある

会社が社員利用分をまとめて負担する

Company DeploymentがAI Gateway/API Keyを持ち、社員利用分を会社が負担する。

必要Control：

Employee/Gadget/Workspace Metadata
Daily/Monthly Budget
Provider/Model Allowlist
Rate Limit
Cost Alert
Chargeback
Kill Switch

利用者自身のCloudflare残高を使う

公開コードには任意のBilling Flowがある。

`ENABLE_CLOUDFLARE_LIMITS=true`
Userごとの無料Call Allowance（Default 100 calls/UTC day）
UserがCloudflare Accountを接続
BalanceがDefault $2以上ならUser自身のDefault AI GatewayへRoute
User自身のCloudflare CreditからBilling
UserがFundedであれば、Free Allowanceが残っていてもUser Routeを優先
Allowance超過かつ未接続／残高不足ならBlock
TokenはCloudflare Gatekeeper側で保持
User DOには選択Account ID、Cached Balance、Daily Counterだけを保存

このFlowはCloudflare OSそのもののライセンス課金ではなく、Public Multi-user Service向けの利用者課金設計である。

Cloudflare上のモデルを使う

Cloudflare Account内のWorkers AIを利用
1日10,000 Neuronsの無料割当
Paidでは超過分が1,000 Neurons当たり$0.011
実際のToken換算はModelごとに異なる
AI Gateway経由またはDirect REST Route
Directの場合、Gateway Cost Logを取れない構成がある

自前の計算機で動くモデルを使う

Cloudflare OS Code上にOllama Provider分岐がある
Model LicenseとOllama Softwareに従う
一般にProvider Token Feeは不要
Hardware、電気、Memory、Storage、GPU Server、運用、Networkの費用が発生
Cloudflare-hosted WorkerからLocal Ollamaへは安全なReachability設計が必要
Local `localhost`を指定するだけではCloud Deploymentから到達しない
Public Endpoint化するとSecurity Riskが増えるため、Tunnel/VPC/Auth/Rate Limitが必要

Cloudflare側では基盤と生成アプリの利用量に費用が出る

2026年8月6日時点の主要条件。

Workersの有料プランが土台になる

Minimum $5 USD / Account / Month
Workers、KV、Durable Objects等のIncluded usageとOverage
Static Asset Requestは別扱い
Cloudflare OSはDynamic Workersを使うため、実質Workers Paidが必要

生成されたGadgetごとに利用量が増える

Workers Paid限定
1,000 Unique Dynamic Workers / Month included
Additional：$0.002 / Dynamic Worker / Day
10M Requests / Month included、超過$0.30/M
30M CPU ms / Month included、超過$0.02/M CPU ms
Worker IDまたはCodeが違うと別Unique Worker
Stable IDを使わず`.load(code)`するとInvocationごとに別Countとなり得る

Cloudflare OSではGadget数だけでなく、Code Versionと呼出し方がCost Driverになる。

会話や状態の保持にも費用が出る

主なCost Driver：

RPC/Request
Duration
SQLite rows read/written
Storage
Alarm
Point-in-time recovery/Backup運用

設定や軽量データの読み書きに費用が出る

Read
Write
Delete
List
Stored GB

Blueprintや画像の保管に費用が出る

Blueprint Snapshot
Screenshot
Object Storage
Read/Write Operation
Egress条件

PDF出力などブラウザー実行に費用が出る

Gadget PDF Export等
Browser Session/Executionに応じたCost

AI Gatewayは無料機能と有料推論を分けて考える

Core FeatureのAnalytics、Cache、Rate Limitは現時点で無料。

追加Costまたは条件：

Persistent Log上限
LogpushはWorkers Paid
GuardrailsはWorkers AI inferenceとして課金
Unified Billing Creditに5% Fee
DLP Full ProfileはZero Trust契約条件に依存
Cost表示は推定値であり、Provider Invoiceを最終基準資料とする

AI GatewayのSpend limitsでは、モデル、提供会社、利用者、チームなどの単位で金額上限を設定できます。ただし、費用の記録はリクエスト完了後に反映されるため、同時に大量のリクエストが走ると上限を一時的に超える可能性があります。上限設定だけへ依存せず、リクエスト数の制限、モデルの許可リスト、同時実行数の制限も組み合わせる必要があります。

接続先サービスの契約費用も残る

Gatekeeperで接続しても、元Serviceの契約は残る。

例：

Google Workspace Seat
Slack Plan
GitHub Team/Enterprise
Notion
Confluence
Supabase
Spotify Premium
ZoomInfo Entitlement/Credit
Email Routing
Provider API Rate/Quota
OAuth Verification/Review対応

ZoomInfo Enrichのように、Action自体がExternal Creditを消費する場合がある。GatekeeperはApproval前にCredit消費しない設計だが、承認時のCost説明とBudgetが必要である。

利用人数だけで月額を断定してはいけない

v1に記載した「5人で月25〜105ドル」「30人で月100〜1,000ドル超」は、Model、Prompt量、Gadget生成回数、Dynamic Worker数、外部SaaS、Log保持を固定していないため、意思決定用の見積りとしては精度不足だった。

v2では次の式で見積もる。

Monthly Total
= Workers base
+ Dynamic Worker unique/day
+ Worker requests/CPU
+ DO requests/duration/storage
+ KV/R2/Browser
+ LLM input/output/cache/reasoning
+ AI Gateway fee/guardrails
+ External API/SaaS
+ Logging/SIEM
+ Human operation

二週間の実測から一人一作業一Gadgetの単価を出す

Active Users
Agent Turns/User/Day
Input/Output/Reasoning Tokens
Model Mix
Gadget Created
Gadget Code Versions
Distinct Dynamic Workers
Dynamic Worker Requests/CPU
DO RPC/Duration/Rows
KV/R2 Operation
Browser Export
Approval Count
External API Call
ZoomInfo等のCredit
Log Volume
Admin Operation Hours

固定額を先に置くのではなく、二週間の試験結果から、一人、一作業、一Gadget当たりの単価を算出します。Workers AI、AI Gateway、外部モデル、ローカルAIをどう組み合わせるかは、次の記事でより詳しく解説しています。

Cloudflare OSとCodexは仕事の場所と開発工程を分担する

Cloudflare OSとCodexは、どちらもAIがコードを書くため似て見えます。しかし、Cloudflare OSは社員の日常業務の場所、Codexは正式なソフトウェアを開発するエージェントとして考えると役割が整理できます。

役割の違いを先に整理する

Cloudflare OSとCodexは、一部の「軽量アプリ生成」では重なりますが、中心となる責任が異なります。プロンプトだけでなく、情報、ツール、状態、権限、評価まで設計対象が広がった流れは、次の記事で整理しています。

主目的：Cloudflare OSは社員がAI・Gadget・Resourceを日常利用、CodexはRepositoryを開発・修正・検証
主利用者：Cloudflare OSは非技術者を含む社員、CodexはDeveloper、Technical Operator、Knowledge Worker
単位：Cloudflare OSはUser、Workspace、Gadget、Binding、CodexはRepository、Branch、Environment、Task
配布：Cloudflare OSは会社URLへSign-in、CodexはChatGPT/Codex App、CLI、IDE、Cloud Task
実行Sandbox：Cloudflare OSはGadgetごとのDynamic Worker/iframe、CodexはCoding Task用Sandbox/Environment
外部接続：Cloudflare OSはGatekeeper Capability、CodexはConnector/Tool/Network/Repo Permission
変更管理：Cloudflare OSはChat 提案中の変更、Accept/Revert、CodexはGit Diff、Commit、PR、Test
共有：Cloudflare OSは同一GadgetまたはBlueprint、CodexはRepository/Branch/PR/Artifact
本番化：Cloudflare OSは小規模業務Appを直接運用、Codexは正式Systemを開発・保守

Cloudflare OS上でCodexを使うのか

標準構成では使わない。

Cloudflare OS内蔵Agent
└─ pi-agent-core
   └─ OpenAI / Anthropic / Google / Workers AI / Ollama

OpenAI Providerを選ぶことと、Codex Product/Agentを埋め込むことは別である。

推奨関係：

Codex / Claude Code
├─ Cloudflare OSの固定版管理
├─ Custom Gatekeeper
├─ Security Test
├─ Bundled Blueprint
├─ Admin Dashboard追加
├─ CI/CD
└─ Upgrade/Rollback
       ↓
Cloudflare OS
└─ 社員がBrowserで日常利用

Codexでも同じものを作れるか

CodexはCloudflare OS相当のSystemを実装できるが、次を自社で作る必要がある。

Sign-in
Multi-user User State
Workspace/Gadget Isolation
Dynamic Worker Loader
Capability Binding
OAuth Token隔離
Resource Picker
Approval Queue
Simulation/Revert
Observer Sharing
Blueprint
Admin Control
Billing
Logs
Upgrade

したがって「CodexがあるからCloudflare OS不要」ではなく、既にCloudflare OSが提供するKernel/Runtime/Policyを使うか、Codexで独自Systemを構築・保守するかというBuild-vs-Adopt判断になる。

Codex SDKを組み込む案

OpenAIはCodex SDKによるWorkflow/App埋込を提供している。しかしCloudflare OS標準にCodex SDK Integrationは確認できない。

カスタム統合する場合の推奨境界：

Cloudflare OSからDevelopment Requestを作成
Codexは指定Repo/Branch/Directoryだけを変更
Test・Security Scan
Draft PRまで
Human Review
Merge/Deployは別承認
Audit/Correlation ID
Rollback

Cloudflare OSからCodexへProduction Merge、Secret変更、権限変更を直接Auto-approveする構成は推奨しない。

試作はCloudflare OSで正式開発はCodexへ渡す

Cloudflare OSで現場がGadgetを素早く試す
利用・価値・例外を計測
重要GadgetをCodexで正式Repositoryへ移す
Requirement、Test、Permission、Observabilityを追加
本番SystemとしてRelease
Cloudflare OSには探索・個人カスタマイズを残す

現時点の結論は限定された試験導入までである

ここまでの機能、権限、残る危険、費用、運用負荷を合わせると、推奨案は一つです。

Cloudflare OSを全社向けの完成済みAI基盤として導入するのではなく、非機密業務向けの部門ワークベンチとして固定版を限定配備する。

公開コードを確認した範囲では、小規模な試験を直ちに中止すべき致命的な問題は見つかりませんでした。Gadgetの分離、資格情報の隔離、必要な対象だけを紹介する権限モデル、変更操作の承認、共有時の再確認など、試す価値のある設計が実装されています。

一方、企業利用で先に対処すべき重要課題は残っています。

利用者が持ち込むMCPの自己申告を、そのまま読み取り専用と信用できない
Gatekeeperごとの実装品質が、全体の安全性を左右する
公開版は早期公開段階で、テストが十分でない領域がある
バックアップ、復旧、高可用性の標準運用が完成していない
`workerd`による自社サーバー本番運用の公式手順が未完成である
OAuthで取得する広い権限と、Gadgetへ渡す狭い権限の差を管理する必要がある
シミュレーションした結果と、後から本当に適用した結果がずれる可能性がある
標準管理画面だけでは、全社員のGadget、費用、危険度、所有者、廃止予定を横断管理できない

そのため、最初の環境では利用者が持ち込むMCPと自動承認を無効にします。GitHubやGoogleなどの接続も読み取り専用から始めます。Blueprintは誰でも公開できる状態ではなく、審査済みの少数カタログから使います。個人情報、顧客秘密、契約、決済、本番設定は対象外にします。

最初の四週間で行うこと

まず、会社専用のCloudflareアカウントまたは専用環境へStarterを使って固定版を配備します。Cloudflare Accessによる本人確認、多要素認証、管理者の許可リストを設定します。

次に、AIを無効にした状態でログイン、共有、権限取消、ログ、バックアップ、前版への切り戻しを確認します。基盤が戻せない状態でAI機能を開くべきではありません。

その後、会社の用語や手順を読むContextと、GitHubなど一つの読み取り専用接続だけを有効にします。十名前後へURLを配り、四週間、証拠が残る業務を試します。たとえば、Issueの集計、会議準備、公開情報の調査、定型レポートの下書きなどです。

期間中は、利用回数や作業時間だけでなく、誤り、承認件数、権限エラー、復旧時間、モデル費用、管理者の対応時間も測ります。便利でも、管理者が毎日トラブル対応へ追われるなら、全社展開する価値はありません。

本番へ進む前に満たす条件を決める

次の条件を満たした場合に限り、対象部門や書き込み操作を少しずつ広げます。

対象業務で時間短縮または品質改善が再現できた
重大な情報漏えいと誤送信がなかった
権限取消が想定時間内に反映された
バックアップから復元できた
アップグレード後の不具合を検知し前版へ戻せた
一人、一作業、一Gadget当たりの費用を説明できた
管理者負荷が削減効果を上回っていない
高リスク操作へ人の承認が残っている

価値はあるものの運用が重い場合は、全社展開ではなく、読み取り専用のAI作業空間や、審査済みGadgetだけへ範囲を狭めます。重大な漏えい、認証情報の流出、承認迂回、復元不能、費用停止機能の不動作が起きた場合は、試験を停止します。

Codexは外側の正式開発へ使う

Cloudflare OSとCodexを一つへ無理に統合する必要はありません。現場はCloudflare OSで小さなGadgetを素早く試し、価値と例外が分かったものだけを正式な開発案件へ昇格させます。

Codexは、その正式化に向いています。要件をリポジトリへ落とし、テスト、権限、ログ、障害対応を追加し、Pull Requestとして人がレビューする。重要な業務は、個人のGadgetのまま永続化するのではなく、所有者、保守担当、SLAを持つ正式システムへ移します。

Cloudflare OSの役割は、社員へAIチャットを配ることではありません。会社が本人確認、会社知識、外部接続、利用モデル、承認、実行環境を統制しながら、社員が自分の仕事に合う小さなソフトを作り、試し、共有できる場所を用意することです。

この構想はかなり魅力的です。ただし、魅力的だからこそ、完成品のように扱わないことが重要です。最初は狭く、読み取りから始め、測り、止められ、戻せる状態を作る。2026年8月時点では、それがCloudflare OSを最も正しく評価できる導入方法です。

AIエージェント、Cloudflare、モデル選択、組織導入を含む実務記事は、次のマガジンにまとめています。

導入前に確認する安全設定

最後に、試験導入前の確認事項を実務で使える形にまとめます。すべてを一度に実装するのではなく、対象データと操作の危険度に応じて優先順位を付けてください。

本人確認と管理者権限を固める

[ ] Cloudflare Accessなどのシングルサインオンを有効にする
[ ] 多要素認証を必須にする
[ ] 利用できる社員グループを限定する
[ ] 管理者を必要最小限にする
[ ] 通常の認証が使えない緊急時の手順を決める
[ ] ログイン履歴を監査できるようにする

外部サービスへの接続を最小限にする

[ ] Connectorは初期状態で無効にする
[ ] 接続先ごとに専用のOAuthアプリを用意する
[ ] OAuthの権限範囲を最小限にする
[ ] アカウント全体ではなく、文書やリポジトリなど対象リソースを限定する
[ ] 最初は読み取り専用で試す
[ ] 接続権限を取り消す試験を行う
[ ] 切断後に再接続できるか確認する
[ ] 認証情報を定期的に更新する
[ ] 接続先サービス側の監査ログも確認する

持ち込みMCPを原則として閉じる

[ ] 利用者が任意に追加するMCPサーバーは初期状態で無効にする
[ ] 承認済みMCPだけを掲載する社内ポータルを使う
[ ] 通信先をHTTPSに限定する
[ ] 社内ネットワークやメタデータへの不正アクセスを防ぐSSRF検査を行う
[ ] OAuthのリダイレクト先を検証する
[ ] 登録したMCPの構成変更を検知できるようにする
[ ] Toolの読み取りと書き込みの分類を人が確認する
[ ] 外部を変更する処理は承認対象のActionとして扱う
[ ] 自動承認は初期状態で無効にする

生成アプリの資源と通信を制限する

[ ] 利用者が明示していない権限をGadgetへ与えない
[ ] 無制限の外向き通信を許可しない
[ ] CPU使用量の上限を決める
[ ] リクエスト数の上限を決める
[ ] 保存容量の上限を決める
[ ] Gadgetの状態をバックアップする
[ ] コードと設定の版を記録する
[ ] 変更を元に戻せるようにする
[ ] Blueprintとして公開する前にコードと説明文を確認する

利用モデルと費用の上限を決める

[ ] 利用を許可するモデルを限定する
[ ] モデル提供者との契約とデータ利用条件を確認する
[ ] 入力と出力の保存期間を決める
[ ] 月額と日額の予算上限を決める
[ ] 呼び出し回数を制限する
[ ] 添付できるファイルと機密区分を決める
[ ] 悪意ある指示が文書へ混入した場合の試験を行う
[ ] 更新前後を比較する回帰テスト用データを用意する
[ ] モデル障害時の代替経路を用意する
[ ] 緊急時にAI呼び出しを停止できるようにする

共有方法と失効手順を決める

[ ] 不特定リンクより、相手を指定する直接共有を優先する
[ ] 共有リンクは無効にするか、有効期限を設定する
[ ] 編集できる人と利用だけできる人を分ける
[ ] 共有相手が外部リソースを読めるか再確認する
[ ] 退職や異動時に権限を取り消せるようにする
[ ] 共同利用者の追加と操作を監査する
[ ] 機密情報を扱うGadgetは共有を禁止する

ログと復旧と更新手順を用意する

[ ] 検索可能な構造化ログを残す
[ ] ログへ認証情報や個人情報を残さない
[ ] 必要に応じて社内の監視基盤へ送る
[ ] 事故、費用増加、権限拒否を通知する
[ ] Error Reporterの内容と閲覧権限を確認する
[ ] バックアップから復元する試験を行う
[ ] 直前の安全な版へ戻す手順を用意する
[ ] 更新前に差分と権限境界を確認する
[ ] 事故対応の責任者と連絡手順を決める
[ ] 利用者、モデル、Gadget別に費用を確認できるようにする

導入判断を短く整理する

判断だけを持ち帰る場合は、次の整理で十分です。

`pnpm run-local`：推奨度は高、用途は個人評価・開発
Hosted Deploy Wizard：推奨度は中〜高、用途は短期評価
Starter Repo：推奨度は高、用途は統制された試験導入・本番候補
Upstream main直追従：推奨度は低、用途は非推奨
workerd自己ホスト本番：推奨度は低、用途は公式Tooling待ち
全社一括導入：推奨度は低、用途は成熟度不足
10名限定試験導入：推奨度は高、用途は推奨
利用者が持ち込むMCP有効：推奨度は低、用途は企業では初期無効
Auto-approve有効：推奨度は低、用途は実績後にAction単位
Read-only Connector：推奨度は高、用途は最初の導入
機密データ：推奨度は低、用途は試験導入対象外

出典・参考資料

Cloudflare OS公式リポジトリ
https://github.com/cloudflare/cloudflare-os
Cloudflare OS Starter公式リポジトリ
https://github.com/cloudflare/cloudflare-os-starter
Cloudflare Dynamic Workers概要
https://developers.cloudflare.com/dynamic-workers/
Cloudflare Dynamic Workers料金
https://developers.cloudflare.com/dynamic-workers/pricing/
Cloudflare Workers料金
https://developers.cloudflare.com/workers/platform/pricing/
Cloudflare Workers AI料金
https://developers.cloudflare.com/workers-ai/platform/pricing/
Cloudflare AI Gateway料金
https://developers.cloudflare.com/ai-gateway/reference/pricing/
Cloudflare AI Gateway Unified Billing
https://developers.cloudflare.com/ai-gateway/features/unified-billing/
Cloudflare AI Gateway Spend limits
https://developers.cloudflare.com/ai-gateway/features/spend-limits/
OpenAI公式ヘルプ ChatGPTとAPIの請求分離
https://help.openai.com/en/articles/8156019-i-want-to-move-my-chatgpt-subscription-to-the-api
Anthropic公式ヘルプ Claudeの有料プランとAPI Consoleの請求分離
https://support.anthropic.com/ja/articles/9876003
Google AI for Developers Gemini APIの課金
https://ai.google.dev/gemini-api/docs/billing?hl=ja
調査と再確認の基準日は2026年8月6日です。Cloudflare OSは早期公開版であり、料金、対応モデル、提供条件、リポジトリの実装は変わる可能性があります。導入時には公式情報と採用する固定版を再確認してください。

いいなと思ったら応援しよう！

社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。