Cloudflare OSとは 全社員にAIエージェントを配るための基盤
名前を聞いて、サーバー用の新しいOSかと思った方。私もです。違いました。
Cloudflareが2026年8月5日、Cloudflare OSを発表しました。中身は、社内の文脈と社内システムに繋がったAIの作業場を、全社員に配るためのプラットフォームです。しかもApache 2.0のオープンソースとして公開されていて、GitHubのリポジトリは公開直後から5,000を超えるスターが付いています。
面白いのは、これがCloudflare自身がここ数か月、社内で実際に使いながら育ててきたものの作り直しだ、という点です。同日に公開されたCIOによる社内展開記には、うまくいかなかった話まで正直に書かれています。中小企業が読んでも学べる部分が多い。そこも含めて見ていきます。
名前に反して、これはサーバーのOSではない
Cloudflare OSは3つの部品でできています。
- エージェントの作業場。ブラウザで会話を始めるところは他のAIツールと同じですが、会話が最初から自社の文脈とスキルに接続されている。開発者でなくても、ターミナルを触れなくても使える設計です
- セキュリティとガバナンスの枠組み。社内データや社内システムに安全に触らせるための仕組み
- 個人が作って共有できるアプリの基盤
「文脈とスキル」というのが分かりにくいので補足します。会社には、独自の用語、手順、うまくいくやり方の型があります。それを人に引き継ぐのが教育で、AIに引き継ぐのがこの部分です。誰かひとりが良いやり方を見つけたら、それをスキルとして置いておけば全員が使える。同じ説明をモデルに毎回やり直さなくてよくなる、という発想です。
Cloudflareは今年5月に第1版を全社員に配り、エンジニア以外を含む数千人が毎日使っていたそうです。今回はそれを作り直して、誰でも自社に展開できる形にした、という流れになります。
Cloudflare OSでできる4つのこと
具体的に何ができるのか。公式ブログが挙げているものを、業務の言葉に置き換えます。
- 調べる: 社内の文脈と、許可した社内リソースを使って調査する。データセット全体をモデルに読み込ませるのではなく、エージェントが検索・絞り込み・結合・分析のコードを自分で書いて処理する
- 作る: 調査結果をドキュメント、スライド、表計算にする。ここが独特で、出来上がりは静的なファイルとは限りません。元データに接続したまま、ソースが変われば中身も更新される資料が作れます。もちろん普通のファイルとして書き出すこともできます
- チームで使うアプリにする: ドキュメントで足りなくなったら、そのままアプリにできる。1つ1つがクライアントとサーバーとデータベースを持つ独立したアプリで、既定では非公開、ドキュメントのように共有もできる
- 回す: 毎回エージェントを丸ごと動かす必要のない仕事は、決まった手順の部分はコードで、判断が要る部分だけモデルでという形の作業手順にできる。手動実行のほか、スケジュール実行、連携システムでのイベント発生時の実行に対応します
4つ目が地味に効きそうだと思っています。AIに任せる業務の多くは、実は9割が決まった手順で、判断が必要なのは1か所か2か所。そこだけモデルを使えば、速度も費用も安定します。
MCPだけでは足りない 見た情報が成果物に付いて回る
この記事でいちばん紹介したいのが、権限設計の考え方です。公式ブログがMCPだけでは足りないとはっきり書いています。
MCP(AIが外部のツールと話すための共通規格。前の記事で解説しました)を使えば、APIキーをエージェントに直接渡さずに、決められた道具だけを使わせられます。ただし、それで分かるのはどの道具を呼べるかまでです。エージェントが実際にどの情報を見たかは分からない。
ここに穴があります。エージェントが複数のシステムから情報を組み合わせ、制限の緩い場所へ送ったり、作ったアプリや資料を通じて、本来その情報を見られない人に見せてしまったりする可能性がある。権限は「最初に読めるかどうか」だけでなく、そのデータが次にどこへ行くかまで面倒を見ないといけない、というわけです。
Cloudflare OSの答えは3層でした。
エージェントは、アクセス権ゼロから始まります。 何かを使いたければ、その資源への許可を個別に求める。承認して初めて、生成されるコードがその資源を扱えるようになります。
Gatekeeperが資源ごとに権限を絞ります。 公式の例が具体的で分かりやすい。GitHubアカウント全体へのアクセスは広すぎるので、Gatekeeperで1つのリポジトリだけに限定し、Issueは読めるがソースコードは読めないようにし、特定のフィールドは伏せ、利用回数に上限をかけ、プルリクエストのマージ前には承認を必須にする。認証情報を持つのも、ポリシーを適用するのも、何が読まれたかを記録するのもGatekeeper側です。
そして、エージェントが見たものが成果物に付いて回ります。 例として挙がっているのが、機微なテーブルを読んで作ったダッシュボードです。そのダッシュボードを共有することが、元のテーブルを共有することになってはいけない。だからCloudflare OSはエージェントが観測した資源を記録し、他の人がその作業場や生成物を開こうとしたときに、元の資源への権限があるかを確認します。
モデルは選べるが、サブスクの席は持ち込めない
ここで、費用に直結する前提をはっきりさせておきます。
Cloudflare OSは、CloudflareのWorkers AIや、OpenAI・Anthropic・Googleといった外部モデルを、AI Gateway経由で使う仕組みです。ChatGPTやClaudeの月額プラン、TeamやEnterpriseの席をそのまま持ち込んで動かせるわけではありません。ここは最初に押さえておきたい点です。
推論はすべてCloudflareのAI Gatewayを通ります。AI Gatewayのドキュメントによれば、支払い方は自社で用意したプロバイダのAPIキーをCloudflareに預ける方式、リクエストのたびに自分でAPIキーを渡す方式、そしてAI Gatewayのクレジットを前払いする方式から選べます。
ここで大事なのは、ClaudeやGPTを使うことが必須ではないという点です。AI Gatewayは、Cloudflare自身のGPU基盤で動くWorkers AIのモデルと、外部プロバイダのモデルを同じ経路で呼べます。Workers AIのカタログには80を超えるモデルが並んでいて、KimiやLlama、Gemmaといったオープンモデルが含まれます。料金はNeuronという単位の従量課金で、1日1万Neuronまでの無料枠もあります。
つまり、OpenAIやAnthropicと別途契約しなくても、Cloudflareの中だけで完結する構成が組めます。外部の最上位モデルを使うか、Cloudflare上のオープンモデルで済ませるか、仕事ごとに混ぜるか。そこを選べるのがこの設計の要点です。
つまり費用は、席数で決まる固定費ではなく、使った分だけの変動費になります。ここは中小企業にとって、判断が分かれるところだと思います。10人分の月額を払えば上限まで使い放題、という読み方ができない。
だからこそ、モデルの出し分けと予算管理が最初から作り込まれているのでしょう。すべての推論がAI Gateway経由なので、どのモデルを使えるようにするかを一か所で決められ、誰が・どのチームが・どの作業場でいくら使ったかが分かる。予算や上限、上限に達したときの挙動も設定できます。毎朝のメール要約に最上位モデルを使う必要はない、という当たり前の判断を、仕組みとして効かせられるということです。
社内展開記のほうにも、同じ問題意識が出てきます。全員が最新の最上位モデルの最大思考モードを使う必要はないし、メール受信箱の要約に何十ドルも溶かされては困る。だから役割ごとに使えるモデルを絞り、自動実行される仕事は安いモデルへ寄せる、と書かれています。
全員にコードを書かせると、問題を探すアプリが増える
ここからはCIOの社内展開記の話です。読んでいて唸ったのが、失敗をそのまま書いている点でした。
最初の失敗は、エンジニア以外にも同じ道具を、少し親切な見た目にして配ったことだったそうです。コードを書くのが得意な作業環境を全員に配ると何が起きるか。必要以上のコードができあがる。結果として生まれたのは、解決すべき問題を探してさまよう大量のアプリだった、と。バイブコーディングの記事で触れた話の、組織規模での実例だと思います。
エンジニア側にも別の問題が出ています。AIによって開発が速くなった結果、レビューが追いつかなくなった。誰でも悪いコードを、より速く書けるようになってしまった、という表現がされています。
対策として作られたのがCloudflare Engineering Codexという文脈の層でした。ポリシーが「やってはいけないこと」を示すのに対し、Codexは「こうするのが良い」を示す。意図的に主張を持たせた文書で、コードベースの各領域には「良い状態とは何か」に責任を持つ担当者を置いたそうです。
そしてこれをAIに渡した。設計レビュー、マージリクエストのレビュー、インシデントレポートのレビューをエージェントが担当した結果、直近4か月で25万件近い問題を指摘し、16,000件のマージを止め、600近い設計で着工前に構造的な問題を見つけたと書かれています。
この構図は、規模が小さくても同じだと思います。私たちも自社のリポジトリに、AIが最初に読む前提の指示ファイルを置いています。書き方の作法、使ってはいけない表現、確認すべき手順。人に説明するのと同じ内容を、人が読む場所ではなくAIが読む場所に置いておく。社内AIガイドラインの記事で書いた話を、AI向けにもう1枚作るイメージです。
真似できるのは「やりたくない仕事を集める」ところから
CIOの記事で、いちばん中小企業向きだと感じたのがこの話です。
Cloudflareは全社員に対して、やりたくない仕事を送ると結果が返ってくる魔法のAIメールアドレスを用意したそうです。裏側では少人数のチームがAIツールを使って処理していました。
結果が興味深い。人は、自分のアプリのアイデアは自動処理っぽいものに送りたがらないのに、やりたくない仕事はどんどん送ってくる。数百、数千のやり取りを通じて、社内の「面倒な作業」の実態が見えてきた、という話です。
これは10人の会社でも今日から真似できます。社内チャットに1つチャンネルを作って、「やりたくないけど誰かがやっている作業」を投げてもらう。それだけです。最初は人が手で処理していい。何が集まるかを見てから、自動化するものを決める。
AI導入の相談を受けていて、いちばん多いのは「何を自動化すればいいか分からない」という状態です。ツールの比較から入ると、たいていここで止まります。先に仕事を集めてから道具を決めるという順番は、規模を問わず効きます。
今すぐ全社導入、とはいかない 押さえておく注意点
期待は高まりますが、現時点での制約は正確に押さえておきたいところです。
- 現時点ではEarly Accessです。GitHubのREADMEにCloudflare自身が警告を掲げていて、今回公開したv2はv1を全面的に作り直したものであること、開発が活発に続いていること、非常に高機能だが粗い部分がまだ多いことを明記しています。本番の全社基盤としてそのまま載せるより、まず検証環境で試す段階と考えたほうがよさそうです
- 今は自分でデプロイする前提です。自社のCloudflareアカウントに載せる形で、Cloudflareの管理画面から使えるマネージド製品としての提供は「開発中」と書かれています。Slackなどのチャットツールへの対応も今後の予定です
- 本体はソースコードではなく、その先の作業です。公式自身が、ソースコードは出発点に過ぎず、文脈・スキル・業務手順・社内システムとの接続・ポリシーこそが価値を決めると書いています。提携パートナー2社による導入支援が案内されているのは、そこが本番だからでしょう
- 費用が席数で固定できません。前述のとおりモデルの利用は従量課金になるので、全社員に配るという性質と組み合わせると、想定より膨らむ可能性があります。モデルの出し分けと予算上限は、配る前に決めておきたいところです
- 導入の前に、原則を決めたほうがよさそうです。Cloudflareは展開前に、CTOとCIOが原則を書き、各部門のリーダーに意見をもらってから配ったと書いています。最初の原則が「AIを使うこと自体を目的にしない」でした。ここを飛ばすと、さまようアプリが増える側に倒れます
自社に合うかどうかの判断軸は、たぶんひとつです。社内システムにAIを触らせたいが、権限の設計で止まっている。この状態にいる会社にとっては、考え方だけでも読む価値があります。逆に、まだ個人がChatGPTを使い始めた段階なら、順番としては早い。
まとめ 権限設計こそが、社内AI活用の本丸
Cloudflare OSを追いかけて残ったのは、機能の話ではありませんでした。AIに社内システムを触らせるとき、難しいのは接続ではなく権限だという指摘のほうです。
道具を制限するだけでは足りない。何を見たかを記録し、その記録が成果物に付いて回る設計まで要る。大企業の話に聞こえますが、規模が小さいほど「とりあえず全部見せる」になりがちなので、むしろ他人事ではありません。
自社に置き換えるなら、まず1つだけ確かめてみてください。いま社内でAIに渡している認証情報は、どこまでの範囲が見えるものか。全社共有の管理者アカウントを渡していたなら、そこが最初に絞るべき場所です。