Cloudflare OSとは？社内AIエージェント基盤の権限設計とGatekeeperの仕組み

Cloudflare OSとは、社内の全員にAIエージェントと作業用ワークスペースを与え、自社の用語や手順を踏まえたまま基幹システムに接続して仕事を任せられるようにする、オープンソースのプラットフォームです。Cloudflareは自社で運用してきた社内基盤を作り直し、2026年8月5日にApache License 2.0でGitHubに公開しました（Cloudflare 公式ブログ、参照日2026年8月26日）。

結論を先に書くと、この製品の主張は「エージェントに社内システムを触らせるときの権限設計を、各アプリの実装者ではなくプラットフォーム側が引き受ける」という一点にあります。ただし公式が自ら「early access」相当と位置づけているため、現時点では全社展開よりも限定的な検証が現実的です。

本記事は、社内AI活用は始めたものの「基幹システムに触らせる」段階で足踏みしている情報システム部門・DX推進担当者に向けて、その権限設計の中身と、検討に値するかの判断軸を整理します。

Cloudflare OSは単体のAIチャットツールではなく、エージェント・セキュリティ・アプリの3つを1つにまとめた基盤です。構成要素と、既存の社内AIチャットとの違い、そしてCloudflare社内での実際の使われ方から押さえます。

公式ブログは、Cloudflare OSを次の3つの組み合わせとして説明しています。この分け方が以降の骨格になります。

要点は3列目、とくに2行目の「基盤側が負う」という設計で、これが後述するGatekeeperと観測記録につながります。ワークスペース自体は、会話、保存された状態、成果物、接続先へのアクセス権、コードを書いて実行できる隔離環境をひとまとめにしたものです。

すでに全社にAIチャットを配っている企業から見ると、Cloudflare OSの立ち位置は分かりにくいかもしれません。違いは3点です。

まず、エージェントが会社のコンテキストを最初から持っています。用語や手順、社内で確立された仕事のやり方を指示として蓄積するため、毎回同じ前提説明をモデルに書き直す作業が消えます。

次に、基幹システムへ到達する経路が最初から用意されています。統制された経路でアクセスさせるGatekeeper（サービスごとの門番。後述）を備え、既存のMCP（Model Context Protocol）サーバーもMCP Server Portals経由で接続できます。

そして、毎回モデルを呼ばずに済む道があります。定型業務の多くは、判断が必要な箇所は1〜2つで、あとは決まった手順の連続です。Cloudflare OSはそうした仕事を、予測できる部分をコードで処理する「ほぼ決定論的なワークフロー」に変換できます。起動は手動・スケジュール・接続先システムのイベントから選べます。

判断材料になるのは、Cloudflare自身が公開した社内運用の数字です。CIOのSam Rhea氏によると、数千人の社員が毎週このプラットフォームを使い、1日あたりの利用者は営業日ごとに増えています。直近1か月で営業チームだけでも1万時間超の手作業削減があったと同社は見積もり、同じ30日間で利用者が4,000を超えるアプリやツールを作成しました（Cloudflare CIOブログ、参照日2026年8月26日）。ただし1万時間は同社が「推定」と明記した値で、算出方法は非公開です。

使われ方は職種で異なります。営業ではテリトリープランニングと提案書作成が対象になりました。ITヘルプデスクの例はより具体的です。Rhea氏自身が毎朝CSVをダウンロードして表計算ソフトでグラフを作り、夜間に届いたチケットを1件ずつ手で開いていた——その運用を、エージェントが生成したダッシュボードとAIによる返信の下書きに置き換えたと書いています。調達では、以前は数日かけて表計算を追う必要があったボトルネック診断が、レポート1本で済むようになったといいます。

エンジニアリング側の数字も出ています。直近4か月でエージェント群が約25万件の潜在的問題を指摘し、16,000件のマージをブロックし、約600件の設計でコードを書く前に構造上の問題を検出しました。

Cloudflare OSは机上の設計から生まれた製品ではなく、社内で先に運用し、壊れた部分を作り直した結果です。同時公開されたRhea氏の記事に、その経緯が具体的に残っています。

Rhea氏は、問題が明確になった瞬間を書き残しています。記事公開の約6か月前、営業組織のメンバーが「APIキーをください。複数です」と依頼してきました。AIで市場開拓チームを一変させる「SuperApp」を作っており、必要なのは十数個の基幹システムへの本番アクセスとデプロイ権限だけだ、と。

同じ依頼は、社内AI活用が次の段階に入ればどの企業でも起こりえます。業務部門が自力でアプリを作れるようになれば、次に必要になるのは社内システムへのアクセス権だからです。しかしAPIキーを配る運用は、人数が増えるほど維持できません。キーは広範囲かつ長期間有効なことが多く、権限を絞ることも安全に共有することも、誰が何に使ったかを追うことも難しいためです。

同じ構図は公的文書でも指摘されています。OWASPのLLMアプリケーション向けTop 10（2025年版）のLLM06「Excessive Agency」は、その例として読み取りが目的の拡張機能がUPDATEやDELETEまで実行できるIDで接続する状態を挙げ、認可はLLMではなく下流システム側で実装すべきだとしています（OWASP Top 10 for LLM Applications 2025、参照日2026年8月26日）。なお総務省の「AIのセキュリティ確保のための技術的対策に係るガイドライン」（令和8年3月）はAIエージェントを対象外と明記しており、国内にはまだ準拠すべき公的基準がありません。

第1版が全社員へ配布されたのは2026年5月です。それでも作り直したのは、運用の中で限界が見えたからです。

技術面の限界は3つです。アプリが社内システムに接続した「動くソフトウェア」ではなく静止した出力にとどまっていたこと。決定論的な仕事にまで毎回推論が走り、ほぼ同じ日次レポートの再生成に毎朝数千トークンを浪費していたこと。そして最も本質的だったのが、共有時に露呈した問題です。MCPサーバーへのアクセス権は「どのツールを呼べるか」を教えてくれますが、「実際にどのリソースを見たか」は教えてくれません。MCPの仕様は認可を必須とせず、権限の強制をプロトコル層では行わないと明記しています（MCP公式仕様、参照日2026年8月26日）。観測したリソースを成果物に紐づけて追跡する枠組みも含まれていません。ワークスペースや出力を共有し始めた途端、見せてはいけない情報が成果物を経由して届く経路ができます。

組織側の失敗も率直です。非エンジニアにエンジニア向けツールをUIだけ親しみやすくして配ったのは初期の誤りだった、というのがRhea氏の総括で、コード生成が得意な道具を全員に配れば必要以上のコードが生まれるだけでした。そこで同社は「やりたくない仕事を送ると結果が返ってくる魔法のAIメールボット」を用意し、裏側は少人数がAIで手作業処理しました。本人は「みじめだった」と振り返りますが、数百から数千のセッションを通じて自動化すべき定型業務を特定できたといいます。なお公式記事は、第1版で実際の情報漏洩が起きたとは書いていません。

Cloudflare OSの中核は、チャット体験ではなく認可の設計にあります。最小権限（Least Privilege）でAIエージェントのツール実行権限を設計する実装ガイドで扱った考え方を、基盤側で強制する形です。

入口はCloudflare Accessが管理し、誰がCloudflare OSに入れるかを制御します。その内側では、すべてのエージェントとアプリが何にもアクセスできない状態で起動し、特定のリソースへのアクセスをエージェントが申請して人が許可または拒否する流れになります。

許可されたリソースは、生成コードに型付きのバインディングとして渡されます。次が公式ブログの例で、見てほしいのはコードのどこにも認証情報が現れない点です。

env.PROJECT は、決められたポリシーのもとで特定のリソースを使う権限そのものを表す「ケイパビリティ」です。認証情報はエージェントからも生成コードからも隔離されると公式は説明しています。

実行環境も閉じています。サーバー側のコードは外向き通信を無効にした実行単位（Dynamic Worker）で動き、クライアント側はブラウザ内の隔離フレームで動きます。明示的に与えたケイパビリティ以外ではインターネットに到達しない設計だとされています。いずれもベンダー側の説明であり、自社環境での実効性は検証したうえで評価してください。

Gatekeeperは、Cloudflare OSと外部サービスの間に立つ、そのサービス専用の小さなプログラムです。対象サービスのAPIと扱えるリソース、実行できる操作を把握したうえで要求を取り次ぎます。

GitHubアカウント全体へのアクセスを与えるのは、たいていの用途には広すぎます。Gatekeeperを挟めば、対象をリポジトリ1つに限定し、issueは読めるがソースコードは読めないようにし、特定のフィールドを伏せ、レート制限をかけ、プルリクエストのマージ前に人間の承認を要求できます。エージェント側に見えるのは小さなTypeScript APIだけで、OAuthの処理も認証情報の保持もポリシー適用も、Gatekeeperの側で完結します。

抽象論ではありません。coreリポジトリにはGitHub、Google、Slack、Notion、Supabase、Linear、メール、MCPなど16個のGatekeeperが同梱されています（cloudflare/cloudflare-os、参照日2026年8月26日）。

運用で効くのは、人間の承認が非同期な点です。承認が必要な操作に到達すると、Gatekeeperはその結果をローカルで擬似的に返してエージェントを先へ進ませ、承認待ちを積み上げます。承認1件ごとに全体が止まる詰まりを避ける設計です。

最初の読み取りを制御するだけでは足りない——これが第1版から得た最大の学びです。エージェントが機微なテーブルを読み、それをもとにダッシュボードを作ったとします。その共有が、元のテーブルを見られない相手に中身を渡す手段になってはいけません。

そこでCloudflare OSは、エージェントが観測したリソースをすべて記録します。記録は成果物に紐づいたまま残り、別の人がワークスペースを開く・対話する・生成物を見ようとするときに、Gatekeeperがその人自身の権限を観測済みリソースに対して検証します。作成者ではなく、見る人の権限が効くわけです。同じ記録は外向き通信の判断にも使われ、機微なデータを読んだ事実が外部への書き込みを止める根拠にもなります。

要点は下2行、「共有したあと」に効く統制の有無です。

MCPの位置づけはMCPとA2Aの違いとは？AIエージェントプロトコルの比較と使い分けを参照してください。

Cloudflare OSでは「ファイル」1つ1つが独立したアプリになり、作った本人も受け取った人も後から作り変えられます。ここでは、その実装の要点と、共有方法の使い分けを押さえます。

アプリを作らせると、エージェントは画面を描画するクライアント側のコードと、状態を保存して振る舞いを実装するサーバー側のコードの2つを書きます。サーバー側はアプリごとに独立した実行単位として起動し、そのアプリ専用のデータベースを持ちます。Cloudflare OS本体のデータとは分離される構造です。

判断に関わるのは、この分離が「常駐サーバーを増やさずに」実現される点です。軽量な実行単位を使うため、社員が思いつきで作ったアプリが数千個並んでも、専用サーバーやコンテナを立てる必要がありません。

作ったアプリは既定で非公開で、ドキュメントと同じ感覚で共有できます。共有方法は2通りあり、他部門への横展開なら原則は下段のブループリントです。

ブループリントで配ると、受け取った側は独立した状態とリソースからアプリを始めるため、元のデータや接続先が一緒に渡ることはないとされています。受け取った人は、機能追加を起票して作成者を待つ代わりに、自分の手元でAIに手を入れられます。

決定論的なワークフローも同じ延長にあります。判断が要る箇所だけモデルを使うため、実行のたびにトークンを消費しません。Rhea氏は第2版で自作したチケット用ダッシュボードについて「最初のレポートを読み込むたびに消費するトークンはちょうどゼロだ」と書いています。

Cloudflare OSはApache License 2.0で公開され、自社のCloudflareアカウントにデプロイして自社のAccessポリシー、AI Gateway設定、データ、連携先で動かせます。ただし前提条件と成熟度に制約があるため、そこから確認します。

starterリポジトリのREADMEは、必要なアカウント機能としてWorkers、KV、R2、Browser Rendering、Dynamic Worker Loadersを挙げ、既定のモデルカタログを使うならWorkers AIとAI Gatewayも必要としています。本番デプロイの手順もREADMEに1本化されています（cloudflare/cloudflare-os-starter、参照日2026年8月26日）。

成熟度には注意が要ります。coreのREADMEは、v2は粗い部分が多く残る「early access」相当だと明言し、外部貢献も積極的には募っていません（受理は十数行以内の明確なバグ修正のみ）。

判断軸は次の4つです。

Cloudflare OSは特定のモデルに縛られません。すべての推論呼び出しがCloudflare AI Gatewayを通るため、どのモデルを使えるようにするか、どの仕事をどのモデルに任せるかを一箇所で決められます。AI GatewayはWorkers AI、Amazon Bedrock、Anthropic、Azure OpenAI、Google Vertex AI、OpenAIなど複数プロバイダーに対応しています。リクエストは実行した人・チーム・ワークスペースに紐づけて記録されるため、管理者はコストの発生源を追え、予算とレート制限を設定できます。

必要性はRhea氏がたとえ話で書いています。「メールの受信箱を1時間おきに要約するのに20ドルを使わせるわけにはいかない」。だからロール別に使えるモデルを制限し、スケジュール実行のような自律度の高い用途は効率的なモデルへ誘導するわけです。コストが読みにくくなる構造はトークントラップとは？AIエージェントの隠れたコスト爆発を防ぐ消費管理の実践でも整理しています。

感触を掴むだけならローカル実行が最短です。pnpmを入れて pnpm run-local を実行し、http://localhost:8787 を開けば動きます（本番用途ではありません）。

社内検証は範囲を絞るのが現実的です。【想定例】として次の3段階が扱いやすいでしょう。まず「特定のリポジトリのissueだけを読んで週次サマリを作る」ように、書き込みの発生しない読み取り専用の業務を1つ選びます。次にその業務に必要なGatekeeperだけを有効にし、対象リソース・読めるフィールド・レート制限の絞り込みが意図どおり効くかを確かめます。最後に成果物を権限の異なる第三者へ共有し、閲覧者本人の権限で弾かれるかを試します。

3段階目が最も重要です。差別化要素は共有時の再検証であり、そこが自社の権限体系と噛み合うかが判断の分かれ目です。

技術検証と並行して決めたいのが責任の所在です。Cloudflareは社内原則として「成果物の責任は人間が持つ」「AIを使うことで基幹システムへの権限が増えてはならない」を明文化し、エージェントを配布した本人が出力に責任を負い、退職時は管理者が引き継ぐと定めています。内部監査や情報セキュリティ委員会では技術仕様より先に問われる部分です。監督体制の設計はAIエージェント・ガバナンスフレームワーク構築ガイドが参考になります。

Cloudflareアカウント以外での実行可否、既存のMCP資産の扱い、導入タイミングの3点に回答します。

公式には「できる」とされていますが、手順はまだ整っていません。READMEは、Workersランタイムであるworkerdがオープンソースであることを根拠に、Cloudflare上でしか動かせないわけではないと述べています。ただしその節は「COMING SOON」と表示され、ドキュメントもツールも未整備です。前提条件の節で挙げた各機能への依存もあり、現時点で確実な導線は自社のCloudflareアカウントへのデプロイです。

使えます。経路は2つあります。利用者主導の方式では、任意のMCPサーバーのURLを貼り付けると、GatekeeperがOAuthディスカバリを実行し、各ツールをセッション内の型付きメソッドへ変換します。組織主導の方式では、管理者がポータルURLを1つ設定すると、組織が承認したすべてのMCPサーバーへ全員がそこから到達します。後者の想定デプロイ先はCloudflareのMCP Server Portalsで、Accessが接続可否を判定し、Gatewayが通信をログに残して検査します。社内に散在するMCP接続を1つの監査点へ集約したい場合は、後者が設計意図に合致します。

待つ理由がある、というのが現時点の答えです。Cloudflareは今後の予定として、Cloudflareダッシュボード上でのフルマネージド製品としての提供、開発ワークフロー向けコンテナの追加、Slack等へのワークスペース統合を挙げています。とくにフルマネージド版は「向いていない」側の企業の前提を変えます。

一方、Cloudflareをすでに本番運用しており、社内AI活用が「システム接続の権限をどう渡すか」で止まっている企業なら、いま検証する価値はあります。権限設計まで含めた実装が丸ごと公開されている例は、調査時点では多くないためです。

Cloudflare OSが解いているのは「AIをどう賢くするか」ではなく、「エージェントに社内システムを触らせるとき、誰が何を見られるかを担保できるか」という運用の問題です。要点は4つです。

• エージェントとアプリは既定でアクセス権ゼロから始まり、認証情報はコードから隔離
• Gatekeeperがリソース・操作・フィールド単位まで権限を絞り、承認を非同期で挟める
• エージェントが観測したリソースを記録し、共有時には閲覧者本人の権限で再検証する
• Apache License 2.0で公開され自社のCloudflareアカウントで動かせるが、公式にearly access相当

権限設計を各アプリの実装者に委ねず、基盤側の責任として引き受ける。この発想は採用の可否に関わらず、社内AI基盤を評価する軸になります。まずは自社で「エージェントが見たものを、共有先で再検証できるか」を点検してみてください。

当社では、AIエージェントの業務適用と権限・ガバナンス設計を含む導入支援を行っています。社内システムとAIをどう接続するかの整理から、ご相談ください。