Cloudflareは8月5日、社内で展開してきたAI作業環境「Cloudflare OS」の新バージョンをオープンソース化した。ブラウザ上の会話から文書やスライドを作ることに加え、社内のコンテキストとシステムを使うアプリを生成し、オンデマンド、スケジュール、イベントを契機に動かせる。
発表の要点は、AIチャットの入口を増やしたことではない。エージェントがどのリソースを見たかを記録し、その後の共有、アプリ操作、外部サービスへの書き込みにも認可を持ち越す仕組みを、アプリ実行基盤に組み込んだことにある。
Cloudflare OSという名前でも、従来型のコンピューターOSではない。企業の用語、手順、システムをエージェントの前提にし、非エンジニアを含む社員が自分の仕事に合わせた小さなアプリを作るための環境である。
社内AIを、誰でも改造できる作業基盤へ
Cloudflareは5月、全社員にCloudflare OSの初期版へのアクセスを与えた。公式ブログによると、エンジニアリング以外も含む数千人が、文書やスライドの作成、反復作業の自動化、データを可視化する小さなアプリの作成に日常的に使っている。
初期版は個人の非公開ワークスペースを中心に、静的なアプリとスキルをエージェントで実行する構成だった。定型処理でも、実行するたびにエージェントへ同じ仕事をさせるため、同じようなレポートを作るだけで推論トークンを消費する。Cloudflareは、MCPサーバーがエージェントの使える道具は示しても、エージェントが実際に観測したリソースまでは示さないと説明する。共有の認可を保つには、別の記録が要る。
v2はそこを作り直した。Cloudflareの公式説明では、構成要素はエージェント作業場、セキュリティとガバナンスの枠組み、個人単位で変更できるアプリの3つである。会話を起点に、ライブデータと接続した文書や表計算、複数人で使うアプリ、決まった処理をコード中心で動かすワークフローへ進める。
社内での利用結果も、単なるデモの域を越えている。CloudflareのCIOは、直近30日で営業部門が手作業から10,000時間超を節約したと推定し、その期間に4,000超のアプリやツールを作ったと報告している。これは同社による推定・自己申告であり、一般企業で同じ効果が出ることを示す測定ではない。それでも、利用者が決められた機能を使うSaaSではなく、各部署が仕事の単位でアプリを増やす設計を採った理由は見える。
観測記録に追随する認可
Cloudflare OSでは、エージェントも生成アプリも最初は何にもアクセスできない。Cloudflare Accessが利用者の入口を制御し、内部では特定のリソースを一つずつ導入する。与えられたリソースは型付きのbindingとしてコードに渡され、資格情報そのものはエージェントや生成コードから隔離される。
外部サービスとの間に置くのが「Gatekeeper」だ。サービスごとのWorkerがOAuthを処理し、GitHubなら特定のリポジトリだけ、課題だけ読み取る、といった狭い接続を用意する。必要に応じてフィールドを隠し、レートを制限し、読み取りと外部に副作用を起こす操作を記録する。エージェントにサービス全体のAPIキーを渡す設計とは、責任の置き場所が違う。
認可の範囲は、最初の読み取りで止まらない。エージェントが機微な表を読んでダッシュボードを生成した場合、そのダッシュボードを共有する人にも元データの権限が必要になる。Cloudflare OSはエージェントが観測したリソースを記録し、別の利用者がワークスペース、エージェント、出力を開くときに、その観測記録を使ってアクセスを再確認する。
この設計なら、アプリを作った人の権限をそのまま共同利用者へ渡さずに済む。観測したデータの性質によっては、別のデータソースへの書き込み、共同利用、外部リクエストを止める判断にもつなげられる。認可の単位を「誰がエージェントを起動したか」から「エージェントが何を見たか」まで広げたところに、Cloudflare OSの技術的な違いがある。
Gadgetを増やすWorker基盤
Cloudflare OSで作るアプリは、ファイルとして出力して別の場所へデプロイする試作品ではない。ブラウザで動くクライアント、状態を持つサーバー、API、永続データを備えたフルスタックアプリとして作られる。
サーバー側はDynamic Workerとして必要なときに読み込まれ、Durable Object Facetとして個別の実行単位を持つ。各アプリには分離されたSQLiteデータベースが割り当てられ、他のアプリの状態と混ざらない。クライアントとサーバーはCap'n Web RPCで接続し、ブラウザに加えてエージェントも同じAPIを呼び出せる。
この構成は、アプリを増やすときに専用サーバーを常時立てる前提を外す。しかも、アプリのコードをAIに変更させても、実行環境と外部アクセスの境界はプラットフォーム側で管理できる。AIに作らせた社内ツールを、個別の開発チームが保守するサービスへ昇格させる前に、限定された仕事の範囲で使える。
共有方法も二つに分かれる。アプリそのものを共有すれば同じ状態を複数人で扱い、Blueprintを共有すればコードだけを元に各自のコピーを作る。コピーはSQLiteのデータや会話履歴を引き継がず、資格情報と接続済みリソースも分離される。テンプレートを配ることに加え、利用者が自分の権限とデータで改造できる仕組みだ。
AI Gatewayが担うモデル選択と予算管理
推論はCloudflare AI Gatewayを通る。Cloudflare OSは特定のモデル提供者に固定されず、利用可能なモデルを組織側で決め、仕事ごとに適したモデルへ振り分けられる。単純な要約や定期処理まで最も高価なモデルへ送らない、という判断を運用の設定にできる。
AI Gatewayはリクエストを行った人物、チーム、ワークスペースにひも付けて、どの利用者のどの仕事に費用が出たかを確認できる。管理者は予算やレート制限を設定し、上限に達したときの扱いを決められる。Cloudflareが同日公開した説明では、Access認証をAI Gatewayへ持ち込み、利用者IDをリクエストに付与する構成も示されている。
ここでも、v1からの変更はAIを増やすことではない。Cloudflareの社内利用では、定型レポートの作成を毎回エージェントに任せる代わりに、エージェントがコードを書いてアプリに処理を埋め込む。決まった手順はコードで処理し、判断が必要な箇所だけモデルを呼ぶことで、同じ仕事を繰り返すコストを下げる考え方である。
オープンソースでも、導入は運用設計から始まる
CloudflareはCloudflare OSのコアリポジトリと、社内での構成を参考にした導入用のstarterリポジトリを公開した。コアのトップレベルLICENSEはApache License 2.0である。自社の画面やコンテキストは、Gatekeeperと接続先の設定、モデル設定、デプロイパイプラインとともに、コアを直接書き換えずに重ねられる。
一方、公開コードは完成品として売り出されたわけではない。GitHubのREADMEは2026年8月版をearly accessとし、開発が活発でrough edgesが残ると明記する。ローカル実行は試用向けで、本番用途ではない。
Cloudflareアカウントへ展開する場合も、Node.js 24とpnpm 11が必要で、Workers関連サービスを導入する。starterはKVとR2を使い、Browser RenderingとDynamic Worker Loadersも条件に含める。AI製品は任意だが、Accessによるサインインや外部サービスのOAuthを設定し、Gatekeeper、ログ、データ保持方針を用意する作業は残る。コードを取得しただけで企業の権限モデルや社内の正規コンテキストが自動で整うわけではない。
自社サーバーでの運用については、さらに注意が要る。Cloudflare OSはオープンソースのWorkersランタイムであるworkerdの上で動かせる設計だが、リポジトリはそのための文書とツールを「Coming Soon」としている。現時点で整備された導入経路は、Cloudflareアカウントへのデプロイとローカル試用である。
Cloudflareは今後、ダッシュボードから使える完全管理型の提供、開発ワークフロー向けコンテナ、Slackなどのチャット連携を計画している。Cloudflare OSの成否は、アプリの数よりも、各社が自分たちのデータ境界をGatekeeperと観測記録へ落とし込み、early accessの実装を運用できるかどうかで決まる。
