Cloudflare OSを読んだ — ブラウザで動くエージェントの権限モデルが面白かった

Cloudflare OS：エージェント、アプリ、作業のためのオープンプラットフォーム（2026-08-10公開）を読みました。Cloudflareが社内で使っていたAIエージェント基盤をOSS公開したという発表記事なのですが、一番惹かれたのは「AIエージェントがブラウザの中でそのまま動く」という設計そのものでした。ターミナルもローカル環境も要らず、エージェントのセッション・実行環境・成果物が全部ブラウザ上に閉じています。中身を読むと、それを支えているのが結構丁寧に作られた権限モデルだったので、そこを中心にまとめておきます。
 Cloudflare OSとは何か社員一人ひとりに、その会社の業務知識・社内システムに合わせて動く専用のAIエージェントとワークスペースを提供するプラットフォームです。2024年5月から社内で使い始め、いまではエンジニア以外を含む数千人が日常的に使っているらしいです。ドキュメント作成、定型業務の自動化、社内アプリの作成などが主な用途で、今回そのコア部分と、Cloudflare社内の実運用構成を模したサンプルデプロイメントの2つをOSSとして公開しています。
最初のバージョンは各自のプライベートワークスペースでエージェントを使う形でしたが、運用してみて課題が出てきたそうです。アプリが社内システムとリアルタイム連携しておらず静的だったこと、同じ定型作業のたびにエージェントを再実行してトークンを浪費していたこと。そして一番根が深かったのが権限の問題で、「エージェントがどのツールを使えるか」は制御できても「実際にどのデータを見たか」までは追えず、ワークスペースやアプリを共有した拍子に権限のない情報が漏れる恐れがありました。この反省を踏まえて、セキュリティをプラットフォーム自体に組み込む形で作り直したのが今回のバージョンになります。
 核心はCapabilityモデルとGatekeeper一番よく設計されていると感じたのがここです。Cloudflare OSでは、エージェントもアプリも最初はどのアクセス権も持たない状態からスタートします。管理者が許可したリソースだけが、型付きバインディングとしてコードに渡されます。
const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});
env.PROJECTは特定のポリシーのもとで特定のリソースを扱う権限（capability）そのものであって、APIキーのような資格情報はエージェントや生成されたコードから完全に切り離されています。APIキーをそのままエージェントに渡す運用は、範囲が広く長期間有効なぶん監査もしづらく、大規模な運用には向かない、という問題意識が根っこにあります。
サーバー側のコードは外部通信が無効化されたDynamic Worker上で、クライアント側のコードはブラウザ内のサンドボックス化されたフレーム上で動きます。どちらも、明示的に許可されたcapability経由でなければインターネットに出られません。
外部サービスとの間に立つのがGatekeeperというサービス専用のWorkerで、対象サービスのAPI・リソース・実行可能な操作を理解しています。たとえばGitHub連携なら、アカウント全体ではなく単一リポジトリへのアクセス、Issueの読み取りのみ許可（ソースコードは不可）、特定フィールドのマスキング、レート制限、PRマージ前の承認要求といった細かい制御ができます。エージェント側から見えるのは小さなTypeScript APIだけで、OAuth認証・認証情報管理・アクセスルールの適用・アクセスログの記録はすべてGatekeeperの内側で処理されます。
面白いのは、この制御が「最初にデータを取得する瞬間」だけで終わらない点です。エージェントが参照したリソースはすべて記録され、その参照履歴は成果物にも紐づいたまま保持されます。別の人がその成果物を見ようとしたとき、Gatekeeperは「その人が元データを見る権限を持っているか」を改めてチェックします。機密データを参照したエージェントは、その後の外部送信やコラボレーター追加、別エージェントへの作業委任なども制限できます。取得時点の権限チェックだけでなく、そのデータが使われ続ける間ずっとガバナンスが効いている、という設計になっています。
 アプリも「ブラウザで完結」を貫いているCloudflare OSでは、ドキュメントやスプレッドシートで足りない場合、エージェントが独自のインターフェースとロジックを持つアプリそのものを作れます。これが単なるプロトタイプではなく、クライアントコード・サーバーコード・API・永続状態を備えたフルスタックアプリケーションだという点が意外でした。
サーバー側は必要なときにDynamic Workerとして読み込まれ、Cloudflareが今回のために新規開発したDurable Object Facetという仕組みの上で実行されます。これによってアプリごとに専用のSQLiteデータベースを持ちながら、専用サーバーやコンテナは要りません。Dynamic Workersが軽量なV8アイソレートを使っているぶん、アプリの数だけ分離された実行環境が作れる、という理屈らしいです。
クライアントとサーバーの通信には、Cloudflareが同じくOSS公開しているCap'n Webというobject-capability方式のRPCシステムを使います。
const issues = await app.listIssues({
  status: "done",
});
普通のJavaScript関数を呼ぶ感覚でサーバーのメソッドを呼べるのですが、ここで効いてくるのが「エージェント自身も同じメソッドを呼べる」という点です。つまり自分用に作ったツールをそのままエージェントにも使わせられます。人間が不在の間もエージェントが同じインターフェースで作業を代行できる、という発想で、ワークスペースがブラウザに閉じていることと地続きの設計に見えます。
アプリの共有方法も2種類用意されていて、状態ごと共有してリアルタイムに共同編集する方法と、コードだけを複製する「ブループリント」共有があります。ブループリントから作られたアプリは会話履歴も資格情報も接続済みリソースも引き継がず、まっさらな状態で始まります。チームでアプリを配っても、各自がAIを使って自分用に自由に改造できる、という運用を意図しているようです。
 そのほか軽く触れておくと推論リクエストはすべてAI Gateway経由になっていて、どの業務にどのモデルを使うかを一元管理できます。誰が/どのチームがどれだけ使ったかも記録されるので予算やレート制限が設定できます。公開リポジトリは「コア」と「Cloudflare社内の実運用構成を模したサンプルデプロイメント」の2つで、コアにパッチを当てずに拡張できる形になっています。PresidioとHappy Cogという2社が導入支援パートナーとして紹介されていました。今後はダッシュボードから使えるフルマネージド版や、開発ワークフロー向けのコンテナ対応、Slackなど既存チャットツールからの利用も計画しているそうです。
 まとめ読んでいて一番学びになったのは、「ツールを使えるかどうか」ではなく「そのツールで得た情報が後でどこに流れるか」まで含めて権限を設計している点でした。APIキーを直接渡さずcapabilityとして権限を渡す発想も、参照履歴に基づいて事後的にもアクセスを制限する発想も、社内向けにMCPサーバーを作るときの参考になりそうです。記事の結びにはこう書かれています。
これはまだ始まりにすぎません。
フルマネージド版やコンテナ対応、チャットツール連携も計画中とのことで、続報も追ってみたいです。原文はかなり具体的に書かれているので、興味があれば元記事もあわせて読んでみてください。