こんにちは、株式会社TIMEWELLの濱本です。
2026年8月5日、CloudflareがCloudflare OSを公開しました。社内で使っていたAIエージェントの基盤を、そのままオープンソースで出したという発表です1。
正直に書くと、最初に読んだときは身構えました。私たちもZEROCKで似た領域をやっているので、当事者として読むことになるからです。そのうえで結論から言うと、設計思想は借りる価値があります。ただし「オープンソースだからベンダーに縛られない」という説明は、そのまま受け取ると危ういところがあります。
順に見ていきます。
何が公開されたのか
事実から押さえます。
Cloudflare OSは公式に「社内の誰もがアプリを作り、業務を自動化し、社内システムへ安全にアクセスできるようにするオープンソースのプラットフォーム」と説明されています2。名前に「OS」とありますが、LinuxやWindowsのような意味のOSではありません。AIエージェントが動く土台という意味です。
重要なのは、これが実際に使われているものだという点です。同社は2026年5月に全社員へ最初の版を提供し、数千人が、エンジニア以外の職種も含めて、毎日使っているとされています。用途は文書やスライドの作成、繰り返し作業の自動化、社内データを扱う小さなアプリの開発です2。
社内で回してから出した、という順序は評価できると思います。作って出したのではなく、使ってから出している。
現在はGitHubのリポジトリで公開されており、近くCloudflareのダッシュボード経由のマネージド提供も予定されています。導入パートナーとしてPresidioやHappy Cogの名前が挙がっています1。
なぜオープンソースにしたのか
本人たちの言葉を見ます。共同創業者兼CEOのMatthew Prince氏のコメントです。
We built this because nothing else did what we needed. Now any company can start from where it took us years to get.1
必要なものが他に無かったから作った。いまやどんな企業も、我々が何年もかけて到達した地点から始められる。
プレスリリースでは、もう少し踏み込んだ説明もされています。
organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.1
その上に作ったものは組織が所有する。企業のプロセス、文脈、社内システムの接続が、ベンダーの閉じた製品に固定されない。
そしてモデルについて。
Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor.1
公式ブログでも「Cloudflare OSはどのモデルとも使える」とされ、すべてのリクエストがAI Gatewayを通る設計になっています。「すべてのタスクが最も高価なモデルを必要とするわけではない」という一文もあり、用途に応じてモデルを選べることが利点として挙げられています2。
つまり彼らの主張は明確です。AIの基盤は組織ごとに違うはずで、閉じた製品に載せると自社の業務がベンダーの形に合わせられてしまう。だから開ける。
同社は設計の意図もこう書いています。
Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.2
中核を書き換えずに、組織固有の機能を足せる形にしたということです。「Yours should reflect your organization（あなたの環境は、あなたの組織を反映すべきだ）」という一文もあります2。
自社のAI活用がどの段階にあるかを整理したい方は、AI活用レベル診断で現在地を確認しておくと、この先の話を当てはめやすくなります。
設計の中身が、いちばん学べる
ここが本題です。**思想として最も価値があるのは、公開の理由ではなく設計です。**3つ挙げます。
ひとつめ。エージェントは権限ゼロから始まる。
Cloudflare OSでは、すべてのエージェントとアプリがアクセス権を持たない状態で開始します3。何かを読むには、明示的に許可された経路を通る必要がある。
これは前に書いたテナント分離の話と同じ構造です。**既定で閉じているか、既定で開いているか。**新しいエージェントを足したとき、誰も何も設定しなければそれは何もできない。この一点の設計差が、運用を重ねたときの結果を分けます。同じ失敗の形はテナント分離はなぜ「あとから」壊れるのかに書きました。
ふたつめ。Gatekeeperが資格情報を握り、エージェントには渡さない。
Gatekeeperは、外部APIの手前に置かれるサービス専用の層です。役割はこうなっています3。
- OAuthの認証をGatekeeper側で完結させ、資格情報を保持する
- ポリシーを適用する
- 読み取りを記録する
GitHubを例にすると、単一のリポジトリだけにスコープを絞る、プルリクエストの承認を必須にするといった制御をここで実装します3。
私はこの設計がかなり良いと思っています。エージェントに認証トークンを渡してしまうと、そのエージェントが何をしようと止められません。**トークンを持たせず、行為ごとに手前で判断する。**先ほどのGlassWormのような、開発者の端末から認証情報が盗まれる攻撃を考えると、そもそもエージェントの手元にトークンが無いという設計の価値は分かりやすいはずです。関連する攻撃の実例は見えないコードが実行されるに書きました。
みっつめ。読んだものを全部記録し、それで書き込みを縛る。
ここがいちばん独特です。公式ブログの表現を引きます。
Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.2
エージェントが観測したすべてのリソースを記録する。その記録は、エージェントとその成果物に紐づいたまま残る。
そしてこの記録が、後から効きます。誰か別の人がその成果物を開くとき、プラットフォームはまず元データへのアクセス権を確認します3。さらに、機密データを読んだエージェントが、特定の宛先へ書き込むことや、共同編集者を招くことを遮断するという使い方もされています3。
権限が成果物を経由して漏れるのを止める、という発想です。
これは実務でよく起きる穴です。権限のある人がAIに機密資料を読ませ、要約を作り、それを権限のない人に共有する。**元データは守られているのに、要約経由で中身が流れる。**アクセス制御を入り口にしか置いていないと、これは防げません。読んだものを記録して出口側も縛る、というのは筋の良い解き方だと思います。
ただし「OSS＝ベンダー非依存」ではありません
ここは冷静に見たほうがいいところです。
公開された構成要素を並べます2。
| 要素 | 役割 |
|---|---|
| Agent Workspace | 文脈とスキルを持つ作業空間 |
| Gatekeepers | リソースアクセスを制御するサービス専用のWorker |
| Dynamic Workers | アプリのサーバーコードの実行環境 |
| Durable Object Facets | アプリの永続状態の管理 |
太字にした2つは、Cloudflare固有の実行基盤です。Workersも Durable Objectsも、同社のプラットフォームの上でしか動きません。そしてモデルの振り分けはCloudflare AI Gatewayを通ります。
つまり、ソースは読めるし変更もできるけれど、動かす場所は実質的にCloudflareです。
これは批判ではありません。筋の通った戦略です。中核を開けて採用の敷居を下げ、実行基盤で収益を得る。「何年もかけて到達した地点から始められる」という言葉と、「近くマネージド提供を予定」という告知を並べると、意図は素直に読めます。誠実なやり方だと思います。
ただ、受け取る側は言葉を分けて評価する必要があります。
「ベンダーの閉じた製品に固定されない」という主張は、モデル提供者については本当です。AI Gateway経由でどのモデルも使える。OpenAIにもAnthropicにもGrokにも縛られません。
一方で、**実行基盤については固定されます。**モデルの依存を外す代わりに、プラットフォームの依存が入る。依存が消えたのではなく、層を移動したというのが正確です。
この構造は、他の領域でも同じ形で現れます。測位・エネルギー・通信まで含めた依存の話はみちびき7号機と日本の依存構造に整理しました。依存そのものが悪いのではなく、どこに依存しているかを自覚していないことが問題という点は共通しています。
日本企業にはもう一つ論点があります。データの所在です。契約書に「データは国内に留まること」と書かれている案件では、実行基盤がどこのリージョンで動くかが、機能より先に効きます。オープンソースであることは、この問いには答えてくれません。
思想だけを借りるか、ソフトごと使うか
ご質問の核心に答えます。両方が正解になりうるのですが、判断軸ははっきりしています。
**思想は、今日から借りるべきです。**条件はありません。
具体的には、次の3つを自社のAI活用の設計に入れる。
- **エージェントは権限ゼロから始める。**必要な権限を明示的に足す形にする
- **資格情報をエージェントに持たせない。**手前に判断する層を置き、行為ごとに許可する
- **読んだものを記録し、それを使って出口を縛る。**入り口のアクセス制御だけで終わらせない
このうち3番目が、多くの組織で抜けています。**AIに何を読ませたかの記録が無いと、成果物経由の漏れを止める手段がありません。**まずはログを取るところからでも始められます。
**ソフトウェアそのものは、条件付きです。**私は次のように整理しています。
**使う価値が高い場合。**すでにCloudflareを主要な基盤として使っている。あるいは、社内向けの実験・小規模な自動化から始めたい。この場合、何年分かの設計を無料で受け取れるのは大きい。自前で作るより速く、しかも実運用されている設計です。
**慎重に見るべき場合。**データの所在に契約上の制約がある。既存のクラウド基盤が別にあり、そこに寄せている。この場合、**中核を採用すると実行基盤ごと移ることになります。**部分的に取り込むにしても、WorkersとDurable Objectsに依存しない部分がどこまでかを先に確認する必要があります。
**そして、どちらの場合でも読む価値はあります。**Apache系のライセンスで公開されている実運用の基盤は、それ自体が良質な設計資料です1。採用しないと決めた場合でも、Gatekeeperの粒度や観測ログの持ち方を読むだけで、自社の設計は良くなります。
当社がZEROCKを国内のAWSサーバーで運用し、誰がどのナレッジに触れられるかを統制しているのも、扱う問題は同じです。**エージェントに何を読ませ、その結果を誰に渡すか。**この問いに答える仕組みを、製品の内側に持っておきたいからです。
公開されたのは、思想か製品か
まとめます。
2026年8月5日、CloudflareがCloudflare OSを公開しました。社内で2026年5月から数千人が日常的に使っていたものを、そのまま出した形です。設計の要点は、権限ゼロから始まるエージェント、資格情報を握って読み取りを記録するGatekeeper、そしてエージェントが観測したすべてを記録し、それで書き込み先と共有先を縛る観測ログ。
オープンソース化の理由として同社が挙げるのは、企業のプロセスや社内システムの接続がベンダーの閉じた製品に固定されないこと、そしてAI Gateway経由でどのモデル提供者も使えることです。
ただし、実行基盤はCloudflare WorkersとDurable Objectsに依存します。モデルの依存は外れますが、プラットフォームの依存は入ります。「オープンソースだから自由」ではなく、どの層の自由を得て、どの層の依存を受け入れるのかという取引として見るのが正確です。
私の答えは、思想は全部借りる、ソフトは条件次第です。
そして最後にひとつ。この公開でいちばん重いのは、コードではなく「使ってから出した」という事実だと思っています。数千人が毎日使い、共有時の権限追跡でつまずいた経験を経て、観測ログという解き方に至っている3。**設計は、運用の失敗からしか出てきません。**その失敗の分だけ、読む価値があります。
社内ナレッジをAIに預けるときの設計について具体的に相談したい方は、ZEROCKの考え方が参考になるかもしれません。個別のご相談はこちらからどうぞ。
Footnotes
-
Cloudflare社プレスリリース「Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work」（2026年8月5日）。共同創業者兼CEO Matthew Prince氏のコメント「We built this because nothing else did what we needed. Now any company can start from where it took us years to get.」、「organizations own what they build on it. A company's processes, context, and internal system connections don't get locked into a vendor's closed product.」、「Through Cloudflare AI Gateway, organizations can use any AI model provider, and they're not locked into one vendor.」、現在はオープンソースリポジトリで利用可能でありCloudflareダッシュボード経由のマネージド展開が予定されていること、導入パートナーとしてPresidioおよびHappy Cogが挙げられていることは、いずれも同リリースによる。公開リポジトリは https://github.com/cloudflare/cloudflare-os 。https://www.cloudflare.com/press/press-releases/2026/cloudflare-os-is-the-first-ai-workspace-built-around-how-companies-actually-work/ ／ 報道ではApache 2.0ライセンスとされている。https://siliconangle.com/2026/08/05/cloudflare-launches-cloudflare-os-open-source-ai-agentic-workspace-enterprise/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Cloudflare公式ブログ「Cloudflare OS: an open platform for agents, apps, and work」（2026年8月5日）。Cloudflare OSの定義「an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems」、2026年5月に全社員へ最初の版を提供し数千人が毎日利用していること（文書やスライドの作成、繰り返し作業の自動化、小さなアプリの開発）、構成要素（Agent Workspace、Gatekeepers、Dynamic Workers、Durable Object Facets）、「Cloudflare OS records every resource agents observe. These observations remain attached to the agent and its work.」、「Cloudflare OS can be used with any model.」および全リクエストがAI Gatewayを通ること、「Not every task needs the most expensive model」、「Cloudflare OS is designed so you can customize the interface, add internal Gatekeepers, and build organization-specific features without changing the core product.」、「Yours should reflect your organization.」は、いずれも同ブログによる。https://blog.cloudflare.com/cloudflare-os/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Cloudflare OSのガバナンス機構に関する報道。Cloudflare OS内のすべてのエージェントとアプリケーションがアクセス権を持たない状態で開始すること、Gatekeeperが外部APIの手前に置かれるサービス専用のWorkerとしてOAuth認証を完結させ資格情報を保持しポリシーを適用して読み取りを記録すること、GitHubの場合に単一リポジトリへのスコープ制限やプルリクエスト承認の要求を実装できること、エージェントが読み込んだリソースの記録がエージェントと生成物の双方に付与され別の人物が成果物を開く際にプラットフォームが基礎データへのアクセス権を先に確認すること、観測ログが機密データを読んだエージェントの特定宛先への書き込みや共同編集者の招待を遮断する用途で機能すること、および社内でワークスペース共有時に権限追跡の課題が生じた経緯は、いずれも同記事による。https://www.helpnetsecurity.com/2026/08/06/cloudflare-os-open-source/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6
