すべての「ファイル」が独立したアプリ、専用サンドボックス、専用データベース

従来のオフィススイートは、ドキュメント、スプレッドシート、スライドといった固定のファイル形式を提供します。Cloudflare OS はこの前提を覆し、すべての「ファイル」がそれぞれ完全なアプリになり得ます。Agent が個人、プロジェクト、チームのためにその場で書くものです。

リポジトリではこれを gadget（ガジェット）と呼びますが、公開ブログでは「app」と表現されており、同じものを指します。これはプロトタイプでも、どこかにデプロイし直さなければならない半成品でもありません。それぞれが完全なフルスタックアプリであり、フロントエンドコード、バックエンドコード、API、永続化できる状態を備えています。デフォルトは非公開で、ドキュメントのように共有できます。

「一人ひとりに専用のものを」をコストを掛けずに実現する仕組みは、3つのピースで構成されています。

最初の2つは、Cloudflare が今春 Workers ランタイムに追加した新機能です。リポジトリの README にはその由来が明記されています。これらの機能は、Cloudflare OS を作るためにランタイムに特別に追加されたものです。今後もさらに増える予定です。

Cap'n Web を選んだことで、おまけの能力も手に入った

3つ目のピースには副作用があり、これがこの設計の最も美しい点です。フロントエンドは規律正しいメソッドインターフェースを通じてバックエンドを呼ぶ必要があるため、このインターフェースは自然に Agent からも直接呼び出せます。

自分用に作った小さなツールを、Agent があなたのいない間に代わりに使って仕事をしてくれます。MCP サーバーを別途書いたり、Agent ループをもう一层接続したりする必要はありません。おまけです。公式アーキテクチャ図にはこの言葉が中央に書かれています。whatever the UI can do, the agent can do（UI ができることは Agent もできる）。

共有には2種類：同じアプリを一緒に使うか、コードごと相手が自分で変更できるようにするか

1つ目はアプリ自体の共有。全員が同じアプリ、同じ SQLite データベースにアクセスし、誰かが変更すれば他の人にもリアルタイムで見えます。Google Docs での共同作業と同じです。

2つ目はブループリントの共有。相手が受け取るのはコードのコピーで、自分で新しいアプリを生成します。元のアプリのデータ、会話履歴、認証情報、接続されたリソースは一切引き継がれません。以後、2人はそれぞれ別々のものを実行します。

2つ目こそが重要です。これは、相手があなたのアプリを受け取った後、自分で AI に変更させられることを意味します。あなたに要件を伝えて待ち行列に並ぶのではなく。

リポジトリの README はこの点をもっと高く評価しています。過去25年の SaaS の論理はこうです。ソフトウェアを自社サーバーで実行し、あなたは接続して使う。機能が足りなければ、こちらに来てスケジュール調整を頼む。ブループリントはスマホアプリや PC ソフトウェアに近く、各ユーザーが自分のコピーを実行し、足りないものは自分で AI に追加させる。README によると、AI は個人開発者がこれまでよりはるかに多くのものを生み出せるようにした一方で、個人がオンラインサービスを維持することは依然として難しい。ブループリントは「サービスの維持」という部分を方程式から消し去るのです。

Gatekeeper：Agent は最初は何にも触れない。承認されても受け取るのはキーではなく通行証

今年2月頃、Cloudflare の営業部門のある社員が CIO に API キーを要求しました。しかも複数本です。この人物は AI で市場チーム全体を変革すると自称する「スーパーアプリ」を作っており、あと一歩のところまで来ていました。会社の基幹業務システム十数件の本番環境権限と、デプロイパイプラインの管理者権限が必要だったのです。

これは、どの企業でも AI を推進する際にぶつかる壁です。AI が社内で実際に使われているシステムにアクセスできなければほとんど役に立ちません。しかしアクセスさせるにはキーを渡す必要があり、キーは一度付与すると範囲が広大で有効期限も長く、回収も監査も困难です。

MCP はすでに一歩前進しています。Agent はキーを直接保持せず、MCP サーバーが代わりに保持し、定義されたツール一式のみを公開します。しかしブログは MCP の盲点を正確に突いています。

MCP はこの Agent がどのツールを呼び出せるかを教えてくれるだけで、どの基盤リソースを実際に見たかは教えてくれません。

Cloudflare ブログ「Cloudflare OS：Agent、アプリ、そして仕事のためのオープンプラットフォーム」

Agent は複数のシステムの情報を組み合わせて、管理が緩い場所に送信したり、作成したアプリや成果物を通じて、元データを見る資格のない人に漏らしたりする可能性があります。したがって、承認は「入り口」だけでなく、データがその後どこへ流れるかも管理する必要があります。

Gatekeeper はこのために設計されました。これは Cloudflare OS と特定の外部サービスの間に挟まる Worker で、サービスごとに1つ用意され、そのサービスのインターフェース、リソース、実行可能な操作を理解しています。Gatekeeper は4つのことを行います。認証情報の保持、ポリシーの実行、読み取りの記録、外部に副作用を及ぼすすべての動作の遮断。

第一層：初期権限はゼロ、承認されても受け取るのは入館証だけ

Cloudflare OS への入り口は Cloudflare Access が管理します。入った後、すべての Agent、すべてのアプリの初期権限はゼロです。Agent は特定のリソースへのアクセスを申請でき、あなたが承認するかどうかを決めます。承認されると、Agent が書くコードが受け取るのは次のようなものです。

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

env.PROJECT は「特定のポリシーの下で特定のリソースを使用する」ための通行証原文では capability（ケイパビリティ）と呼ばれます。キーとの違いは、キーは誰でも使える文字列であるのに対し、通行証はオブジェクトであり、何ができるかがあらかじめ枠内に決められていて、コピーして他人に渡すこともできません。を表します。認証情報そのものは Agent とそれが書くコードから完全に分離されており、コードがキーに触れることは決してありません。

また、許可の範囲は非常に細かく設定できます。ブログの例では、GitHub アカウント全体を Agent に渡すのは明らかに広すぎるため、Gatekeeper はリポジトリ1つだけに制限したり、issue の読み取りのみ許可してソースコードは見せなかったり、一部のフィールドをマスクしたり、レート制限をかけたり、PR マージの前に手動承認を必須にしたりできます。

さらに下には2つの壁があります。アプリのサーバーサイドコードは Dynamic Worker 内で実行され、外部へのネットワークアクセスはグローバルに無効化されています。フロントエンドコードはブラウザのサンドボックス iframe 内で実行されます。どちらも、あなたが明示的に与えた通行証を通じてのみ外部に出られ、他の経路はありません。

Agent が読んだものを記録し、閲覧者が見る前に読む資格があるかチェック

最初の読み取りを管理するだけでは不十分です。ブログの例は一目瞭然です。Agent がデータウェアハウスの機密テーブルを読み、それを使ってリアルタイムダッシュボードを作りました。このダッシュボードの共有が、権限を迂回してテーブルを共有する経路になってはいけません。

Cloudflare OS のアプローチは、Agent が読んだすべてのリソースを記録することです。これらの「オブザベーションレコード」は Agent とその成果物に付随します。誰かがワークスペースを開こうとしたり、Agent と会話しようとしたり、成果物を見ようとしたりするとき、各 Gatekeeper が1つのことを確認します。その人が Agent が読んだものを直接読む資格があるかどうか。あれば許可、なければ遮断です。

リポジトリの実装はブログの説明より踏み込んでいる

ブログは「チェックする」とだけ述べています。オープンソースリポジトリの docs/observers.md には、このメカニズムの完全な形が記されており、ブログで触れられていない点が3つあります。

1つ目：相手は先に自分のアカウントを接続する必要がある。同僚にアプリを共有するとき、相手が開く際に、アプリが依存する各サービスについて自分のアカウント（自分の Google、自分の GitHub）を選択する必要があります。システムはその人の身元で Gatekeeper に問い合わせます。これらのものを読めるか？読めなければ、開くことは拒否されます。アカウントを選択しない場合も拒否です。

2つ目：承認されると「オブザーバー」として登録され、あなたのアプリの権限が抑制される。相手がオブザーバーになった瞬間から、このアプリがオブザーバーに見る資格のないものを読み取ろうとすると、その読み取りは即座に遮断され、例外が発生します。権限の低い同僚にアプリを共有した後は、あなた自身のアプリの読み取り範囲もその人と同じ幅に抑制されます。解除する方法はただ1つ、相手のアクセス権を取り消すことです。

3つ目：相手が開くたびに再チェックする。「先月は権限があったが、今月は異動した」といったケースを防ぐためです。

同じオブザベーションレコードには2つ目の用途があります。外部へのネットワークアクセスの管理です。機密データを読んだ後、Agent が特定の場所にデータを書き込んだり、新しいコラボレーターを招待したり、別の Agent にタスクを渡したり、外部へのリクエストを送信したりすることは、すべて禁止される可能性があります。何を読んだかが、次に何ができるかを決定します。

承認は後回しでいい：Gatekeeper が先に偽の issue を作り、Agent は最後まで走り切る

権限確認付きの Agent ツールを使ったことがある人なら、誰でも次のシナリオを知っています。

従来の「人間がループに入る」承認は同期型です。Agent が副作用のあることを行おうとすると、あなたが確認をクリックするまで停止します。タスクを任せてコーヒーを取りに行き、戻ってくると最初の承認ポップアップで止まっていて、一歩も進んでいません。そこで皆、全自動承認に設定するか、権限確認をスキップするパラメータを付けるかに投降します。README ではそのパラメータ名を直接指摘しています。--dangerously-skip-permissions。これは明らかに安全ではありませんが、ただ待つよりはましです。

Gatekeeper の解法はこれです。アクションは実際には実行しないが、実行したかのように振る舞う。

Agent が「issue を作成」と言ったとき、Gatekeeper は GitHub に作成せず、このアクションを承認キューに入れ、同時に一時的な偽の issue を Agent に返します。Agent は作成されたと思い込み、次の作業に進めます。この issue にラベルを付けたり、コメントを追加したり、他の場所で参照したりすることはすべて可能で、Agent は止まることなく最後まで実行します。あなたは都合の良いときに戻ってきて、この一連のアクションを一括承認するか、個別に承認するか、拒否することもできます。

ソースコードで検証：createIssue は確かにまずキューに入り、一時 ID を返す

リポジトリを落として GitHub Gatekeeper の実装を確認しました。createIssue メソッドは確かにまずアクションを submitActionForApproval にキューイングし、その後すぐに provisionalId（一時 ID）を持つ issue オブジェクトを呼び出し元に返します。コードには一時番号のレンダリング形式もあり、#~1 のようなチルダ付きの偽番号は、本物と一目で区別できます。

インターフェースのコメントには設計意図が明記されています。

Gatekeeper は未承認のアクションを「シミュレーション」することを推奨します。つまり、セッションインターフェースはすべてのアクションが有効になったかのように振る舞うべきです。これによりアプリは作業を続行し、それに依存するさらなるアクションを積み上げることができます。

cloudflare-os リポジトリ · packages/workshop-shared/src/gatekeeper.ts

代償もコメントに書かれている。3つ

1つ目：シミュレーションは「推奨」であり「強制」ではない。上記の直後に、コメントはこう続きます。Gatekeeper にシミュレーションを厳密に要求しているわけではなく、どのアクションがシミュレーションに値するかは、その Gatekeeper を書く人が判断します。したがって、サービスごとに体験は異なります。

2つ目：シミュレーション済みのアクションを拒否すると、アプリ全体の再起動が必要になる場合がある。状態が偽の結果に沿って先へ進んでいるため、ロールバックが不完全だと Agent が混乱します。インターフェースには専用の restart フラグが用意されています。コードには連鎖反応を処理するロジックもあります。「issue 作成」のステップを拒否すると、この issue に依存する後続のアクションもすべて一緒に拒否されます。

3つ目：取り消しは任意。Gatekeeper は取り消しを実装しなくてもよく、その場合システムは手動で取り消すよう促すだけです。コメントによると「高品質な Gatekeeper はほぼすべて実装すべき」とあり、逆に言えば現時点では必ずしも実装されているとは限りません。

どのモデルを使うか、誰がいくら使ったか、すべて同じゲートウェイを通過

すべての推論呼び出しは Cloudflare AI Gateway を経由します。利点は、どのモデルが利用可能か、どのタイプのタスクをどのモデルに割り当てるかを1か所で決定できることです。

理由は非常に現実的です。すべてのタスクが最高級モデルに値するわけではありません。毎朝未読メールを要約するのに、最先端モデルは不要です。CIO の記事はもっと率直で、従業員が毎時20ドルかけて受信トレイを要約するのは許されないと述べています。

すべてのリクエストは、誰が、どのチームが、どのワークスペースから発信したかが記録されます。管理者はお金の使われ方を確認でき、予算とレート上限を設定し、超過時の対応も規定できます。

リポジトリに標準搭載されている4社

さらにローカルの ollama 用の口も残されています。コード内の TODO コメントが興味深いです。Claude Fable も追加したいが、多くの企業がゼロデータ保持ポリシーのために使用を許可していないため、管理者スイッチを先に作る必要があると。そして「こんな小さなアプリに使うのは本来オーバーキルだ」とも付け加えています。

ホスティング版にはもう1つの課金設計があります。ユーザーごとに毎日無料枠があり、デフォルトでモデル呼び出し100回です。使い切ると、自分の Cloudflare アカウントに接続して自分の AI Gateway 残高で支払うか（残高は2ドル以上必要）、ブロックされます。セルフホストの場合、この層はデフォルトでオフになっており、制限はありません。

Cloudflare 社内のこの3カ月：直近30日で4000以上のアプリ作成、失敗作も多数

Cloudflare OS の最初のバージョンは2026年5月に全従業員へ公開されました。今日のオープンソース化まで、3カ月間運用されました。

削減された時間はもともと何に使われていたのか？CIO は、従来手作業だったセールスの仕事、具体的にはテリトリーの割り当てや提案書の作成といったものを挙げています。

まず失敗談から

当初、彼らは非技術職の同僚にも同じツールを配りましたが、インターフェースを少し使いやすくしただけでした。その結果を彼自身がこう総括しています。

誰にでもコードを書くのが得意なワークスペースを与えると、最終的には必要以上のコードが生まれることになる。

Sam Rhea、Cloudflare CIO

生まれたのは、「解決すべき問題が見つからない」vibe coding アプリの山でした。これが、第二版が確定的ワークフローの方向へ向かった理由でもあります。すべての仕事にコードを書ける Agent が必要なわけではありません。

CIO 自身の例：3世代のやり方を並べて見る

彼は毎朝、IT ヘルプデスクのチケットキューといくつかのサービス指標を確認します。

最後の「ゼロ」の前提を理解しておく必要があります。これは、ダッシュボードがコードとして書かれ、データは Gatekeeper 経由で直接取得され、読み込み時にモデルを経由しないから成立します。「Cloudflare OS を使えばトークンを消費しない」という意味ではありません。AI が必要な部分（新着チケットへの返信下書きなど）はアプリ内に組み込まれており、そこでは引き続きトークンを消費します。

何を自動化すべきかを見つける方法：全社に「やりたくない仕事」を魔法のメールボックスへ送らせる

この部分は製品自体とは関係ありませんが、今回もっとも直接的に真似できるものだと思います。

問題はこうです。会社でどの作業が自動化に値するかを知りたいとき、皆に「何を自動化したい？」と直接聞いても、答えはほとんど使い物になりません。Cloudflare のやり方は、質問の仕方を変えることです。彼らは全社にこう伝えました。「やりたくない仕事をこの『魔法の AI メールボックス』に送ってください。求めている結果を送り返します」と。

メールボックスの背後にあるのは自動システムではなく、AI ツールを使った少数の人間チームが1件ずつ処理しています。

巧妙なのは人間の心理です。CIO の言葉を借りると、理由は不明だが、人は自分の vibe coding アイデアを自動システムだと思われるものに送るのには消極的だが、やりたくない仕事を放り込むのには非常に積極的だということです。

数百回、やがて数千回のセッションを重ね、彼らはリクエストを手作業で分類し、傾向を見出しました。どのリクエストが繰り返し発生するか、どのデータに接続する必要があるか、最終的にどのような形式の成果物が求められているか。明確になったら、それをスキルファイルやコンテキストファイルにし、データソースを接続し、出力形式を固定しました。十分に蓄積されてから、プラットフォームをセルフサービスで開放しました。

この作業について、彼ら自身「非常に苦痛だった」と表現しており、ずっとやめたかったが、素材が十分にたまるまで我慢したそうです。

着手前に知っておくべきこと：これは初期バージョン、Gatekeeper は自分で書く必要がある

以下の点は、ほとんどがリリースブログではなくリポジトリからの情報ですが、今着手するかどうかを左右します。

1つ目：README 自体が「早期アクセス」の警告を出している。このリポジトリは実は第二版であり、第一版の教訓を踏まえた完全な書き直しです。原文はこうです。非常に機能的だが、まだ多くの粗さがある。認識しており、修正中です。

2つ目：サービスの Gatekeeper を書くのは、本格的な開発作業。リポジトリには16個が含まれており、Google、GitHub、Slack、Notion、Linear、Confluence、Supabase、Home Assistant など一般的なサービスをカバーしています。私がそれぞれのコード行数を数えてみました。

つまり、貴社の自社開発システムで既製の Gatekeeper がないものは、誰かが1つずつ書く必要があり、この規模感からすると、午後1つで終わるようなものではありません。良いニュースとして、リポジトリには MCP と MCP Portal の2つのブリッジパッケージがあり、既存の MCP サーバーを直接接続できます。ただしその場合、MCP の層の管理強度しかなく、Gatekeeper のきめ細かいポリシーは享受できません。

3つ目：外部からのコード貢献は受け付けていない。貢献ガイドの理由は一読の価値があります。

AI はコードを書くことを容易にした。今日、本当に難しいのはコードのレビュー、品質保証、プロダクトの一貫性の維持だ。そう考えると、外部からのコード貢献は、この仕事の中で簡単な半分を私たちに「寄付」し、同時に難しい半分を増やすことになる。

cloudflare-os リポジトリ · CONTRIBUTING.md

彼らが受け付けるのは、小さくて一目で検証できる修正のみ。10行を超えるものはこの規則を添えて即クローズされます。大きなアイデアがある場合は、ディスカッションスレッドを立ててください。

4つ目：workerd で自前サーバーにデプロイするのは、ドキュメントに「近日公開」と記載。技術的には動作し、ローカル開発モードでは workerd が使われていますが、ツールとドキュメントは未整備で、今やろうとすると低レベルの設定を自分で理解する必要があります。

公式の次のステップは3つ。Cloudflare コンソールでのマネージド製品化、開発ワークフローへのコンテナ追加、ワークスペースの Slack などのチャットツールへの接続です。

試し方：ローカルでコマンド1つ、または自分の Cloudflare アカウントへワンクリックデプロイ

一番手軽なのはローカルで試すことです。pnpm をインストールし、pnpm run-local を実行して、localhost:8787 を開きます。一式がお使いのマシンで起動し、データはローカルの .wrangler ディレクトリに置かれます。このモードは本番環境用ではありませんが、製品が何かを理解するには十分です。

自分の Cloudflare アカウントにデプロイするには、オンラインフローがあります。os.cloudflare.app/deploy。深くカスタマイズする予定があるなら、cloudflare-os-starter というサンプルリポジトリを使います。これは Cloudflare 社内のデプロイ方法に倣ったもので、コアを変更せずにコアを消費するという特徴があります。設定、カスタムUI、内部統合、データ分析、デプロイパイプラインはすべてこの層に置かれ、コアのアップグレード時に競合しません。

README に試し用のプロンプトがいくつかあるので、そのまま紹介します。

• 「明日の顧客訪問用のスライドを作って。」（内蔵のスライドブループリントを使用）
• 「共同作業用のホワイトボードアプリを作って。」（ゼロから新規作成）
• 「三目並べのゲームを作って。」 そして「私は X で、あなたは O ね。私が最初の手を打ったから、あなたの番よ。」
• 「この GitHub リポジトリ用の issue ボードを作って。」（先に GitHub の Gatekeeper を設定すること）
• 「この Google ドキュメントの誤字を修正して。」（先に Google の Gatekeeper を設定すること）

自分で設定したくない場合は、Cloudflare の2つの戦略パートナーである Presidio と Happy Cog が導入サービスを提供しており、社内システムの接続、会社のコンテキストとスキルライブラリの構築、セキュリティとコストポリシーの設定を支援します。

今年2月、Cloudflare の営業社員が AI で「スーパーアプリ」を作り、社の CIO に API キーを求めた。しかも複数本、中核業務システム十数件の本番環境権限も一緒に。AI が実務システムに触れなければ役に立たない。触れさせるには鍵を渡すしかなかった。

鍵は Gatekeeper（門番）という小さなプログラムが握る。サービスごとにひとつ割り当てられ、資格情報の取得、ポリシーの実行、Agent が何を読んだかの記録、外部に副作用のある動作の遮断を代行する。粒度は細かく、特定フィールドのマスキングや、マージ前の人の承認義務付けまで設定できる。

初回の読み取りを管理するだけでは不十分だ。Agent がデータ基盤の機密テーブルを読んでリアルタイムのダッシュボードを作ったとして、そのダッシュボードを共有するだけで、権限を迂回してテーブルそのものを渡す経路になりかねない。Cloudflare OS は Agent が読んだリソースをすべて記録し、その記録が成果物と一緒に移動する。

従来の承認は同期的だ。Agent が外部に本当の副作用を及ぼす行動をするとき、GitHub に issue を立てたりメッセージを送ったりして、確認を待って止まる。タスクを投げてコーヒーを取りに行き、戻ってきたら最初の一歩で止まっていた——そんな経験は誰にでもある。だから皆、全部自動承認にしてしまうか、--dangerously-skip-permissions で確認を飛ばしてしまう。Gatekeeper の解法はこうだ：動作は実際には実行しないが、実行したかのように装う。

第一版は 2026年5月に全従業員へ公開され、今回のオープンソース化まで3ヶ月の運用実績がある。以下のスケール数字はすべて Cloudflare の自己評価ベース。工数については「見積もり」と断り書きがある。今日公開されたばかりで、第三者の再現検証はまだない。

• README には「早期アクセス」の警告がある。このリポジトリは第一版の教訓を踏まえて完全に書き直した第二版で、原文の言葉を借りれば「かなり使えるが、まだ粗い部分が多く、認識して修正中」だ。
• 自社システム向けの Gatekeeper が未整備なら、誰かが一つずつ書く必要がある。リポジトリには MCP（AI が外部サービスに接続するための汎用インターフェース規格）ブリッジが同梱されており、既存の MCP サーバーをそのまま接続できる。ただし、その場合は MCP レイヤーぶんの管理強度しか得られない。
• 外部からのコード貢献は受け付けていない。理由は、AI のおかげでコードを書くのは簡単になり、いま難しいのはコードレビューと品質確保だから。受け付けるのは、小さく一目で検証可能な修正のみ。自前サーバーでの完結運用は、ドキュメントに「近日対応予定」とある。