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サーバーを作るときの参考になりそう。記事の結びにはこう書かれている。
これはまだ始まりにすぎません。
フルマネージド版やコンテナ対応、チャットツール連携も計画中とのことで、続報も追ってみたい。原文はかなり具体的に書かれているので、興味があれば元記事もあわせて読んでみてほしい。