AIが読んだ資料から新しいアプリを作ったなら、そのアプリを見られるのは誰でしょうか？
社内AIにGitHubリポジトリや顧客データを接続するときは、最初の権限だけを絞れば十分に思えます。しかし、エージェントがその資料を読んでダッシュボードを作り、同僚と共有したり外部サービスに送信したりすると、話は変わります。元データを見られない人でも、加工された結果から内容を見られる可能性があるためです。
Cloudflare OSが興味深いのは、エージェントからAPIキーを隠すだけで終わらない点です。エージェントが実際に観察したリソースを記録し、その記録を後から作られたワークスペース・アプリ・出力の閲覧および転送ポリシーにも使います。最初の呼び出しではなく、データの移動経路に権限を紐づける設計です。
Sandstormは「ユーザーがコーディングできなかったから」失敗したのではありません
Cloudflare OSの系譜は、Kenton Vardaが作ったSandstormへとつながります。Sandstormは、文書やアプリを小さな独立インスタンスとして実行し、インスタンスごとにアクセス権を分けるセルフホスティングプラットフォームでした。
ただし、2017年の事業終了時に公式の振り返りが明らかにした直接的な失敗原因は、アイデアが時代遅れだったことではありません。製品は依然としてアルファ段階の粗さがあり、エンタープライズ営業は想定以上に難しく、製品と営業を安定させるための資金と時間が不足していました。数百件の企業トライアルと関心が、実際の購入にはほとんど結び付かなかったとも説明しています。
Vardaは2026年の公開記事で、Cloudflare OSをWorkersとAIを使ったSandstormのリメイクと表現しました。Sandstormの「Grain」のようにアプリのインスタンスを細かく隔離しつつ、今回はユーザーがエージェントに依頼して必要なアプリを直接変更できる、という位置づけです。
Cloudflareは2026年5月に最初のバージョンを全従業員に提供しました。会社説明によると、さまざまな職種の数千人が、文書やスライドの作成、反復作業の自動化、小さなアプリの制作に利用しました。ただし、正確なアクティブユーザーの算定方法や導入前後の生産性の変化は公開していません。
Gatekeeperはアクセス・観察・その後の移動をつなげます
公開されたCloudflare OS v2は、会社のコンテキストを扱うエージェントワークスペース、セキュリティ・ガバナンス層、パーソナライズされたアプリプラットフォームで構成されています。社内導入を検討するチームがまず見るべきなのは、そのセキュリティ層にあるGatekeeperです。
| 時点 | Gatekeeperが制御するもの | 確認すべき質問 |
|---|---|---|
| アクセス前 | 認証情報をエージェントと生成コードから隔離し、特定のリポジトリ・Issue・操作といった限定的なcapabilityを提供 | エージェントはトークンの原文を見たり、範囲外のリソースを呼び出したりできますか？ |
| データ利用中 | エージェントが実際に観察したリソースを記録 | ツール呼び出しの記録だけでなく、読み取った元のリソースまで追跡されますか？ |
| 結果利用後 | 観察記録を、結果の閲覧、共同作業者の招待、外部リクエスト、他エージェントへの受け渡しのポリシーに反映 | 元データへの権限がないユーザーが、派生結果を開いたりエクスポートしたりできますか？ |
たとえば、機密性の高いテーブルを読んでダッシュボードを作った場合、別のユーザーがそのダッシュボードを開くときに、元のリソースへのアクセス権を再確認できます。エージェントがすでに読んだという理由だけで、派生結果が自動的に公開されないようにする仕組みです。
この違いを「MCPは危険でGatekeeperは安全」と単純化するのは適切ではありません。MCPサーバーも認証情報を保管できます。Cloudflare OSがさらに進めた点は、ツール呼び出しの許可を超え、観察したリソースと、そのデータがその後どこへ移動するかまでポリシーに結び付けたことです。
導入検討時に聞くべき3つのこと
- エージェントと生成コードはOAuthトークンを直接読み取れますか？
- どのツールを呼んだかだけでなく、どの行・ファイル・リポジトリを観察したかが残りますか？
- 元データから派生したアプリと出力にも、同じ共有・外部転送の制限が継続しますか？
Gadgetはアプリコードとユーザーデータを分けて扱います
Cloudflare OSでは、エージェントが作ったパーソナライズされたアプリをGadgetと呼びます。各Gadgetは独自のDynamic WorkerランタイムとSQLite状態を持ち、アプリごとに実行環境と状態を分ける構造です。
同僚に同じアプリを作ってあげたい場合は、Blueprintを共有できます。このときコピーされるのはコードであり、元のユーザーのデータ、会話履歴、認証情報、接続済みリソースは含まれません。完成したアプリをそのまま共同利用することと、空のコピーを渡すことを区別しているわけです。
外部への副作用がある操作もGatekeeperが仲介できます。承認待ちの間は結果をシミュレーションしてエージェントが次の作業を続けられるようにし、ユーザーが後から個別または一括で承認するフローをサポートします。ただし、すべての書き込み操作が常に人の承認を通るわけではありません。どの操作に承認を求めるかは、接続されたGatekeeperと組織ポリシーに依存します。
外部データなしで最初のGadgetを作ってみましょう
構造を確認する最初の実習では、GitHubやGoogle OAuthから接続しないほうが簡単です。必要なのはCloudflareアカウント、管理者メールアドレス、workers.devアドレスに使うインスタンス名です。最初のホワイトボードを作る時点でモデル推論が実行されることも、あらかじめ知っておきましょう。
実行前に請求と利用上限を確認してください。公式デプロイ画面のデフォルトモデルは、別途APIキーなしでAI Gateway経由で利用できますが、利用量はデプロイ者のCloudflareアカウントに請求される場合があります。AnthropicまたはOpenAIのAPIキー入力は任意で、後から追加できます。
- 公式デプロイページでCloudflareにログインします。 Cloudflare OSデプロイページを開き、Cloudflareアカウントでログインした後、自分のアカウントへデプロイできるよう、求められるダッシュボードアクセス権を承認してください。
- インスタンス名と管理者メールアドレスを入力してデプロイします。インスタンス名は、デプロイされる
workers.devアドレスに使われます。管理者として使うメールアドレスも入力し、デプロイを開始してください。このホスティング経路では、ローカルビルドなしで自分のCloudflareアカウントへデプロイします。 - 管理者メールアドレスでログインします。デプロイされた
workers.devアドレスを開き、管理者メールアドレスを入力してから、Cloudflare Accessが送信したワンタイムPINでログインしてください。アクセス後は、/adminで同じメールアドレスが管理者として認識されているかも確認します。 - デフォルトワークスペースに最初のリクエストを入力します。外部サービスを接続していない状態で、Make a collaborative whiteboard app.と依頼してください。これはリポジトリが案内する例示プロンプトであり、このリクエストからモデル利用量が発生する可能性があります。
- 成功の基準は生成ではなく実行です。作られたホワイトボードGadgetが開き、自分で要素を追加したり動かしたりできるか確認してください。社内資料が本当に必要になる次の段階でのみ、該当するGatekeeperとOAuth認証情報を設定します。
プロダクションへの全面導入はまだ早すぎます。2026年8月時点の公開版はアーリーアクセスであり、自前サーバーでworkerdを運用するためのプロダクションデプロイ文書とツールもまだ完成していません。Apache-2.0のオープンソースであることは、運用費が無料という意味でもありません。パイロット段階で、実際のWorkers・ストレージ・AI利用量、固定バージョン、信頼境界をあわせて検討する必要があります。
持ち帰るべきなのは「AIオペレーティングシステム」という名前より、権限の寿命です
Cloudflare OSは、従来のコンピューターOSというより、エージェント作業空間とアプリ隔離層をOSになぞらえた製品です。したがって、名前や社内利用の規模より先に確認すべきなのは、権限がどれだけ長く、どこまで維持されるかです。
現在公開されている資料だけでは、Gatekeeperの安全性を独立して証明することはできません。外部セキュリティ監査の結果、組織規模別の運用費、公開v2の実際のアクティブユーザー数と生産性の変化も確認されていません。それでも、社内AIプラットフォームを設計するチームには明確な問いを残します。「誰がこのツールを呼び出せるか？」で止まらず、「そのツールが読んだデータから作られた結果を誰が見られ、どこへ送れるか？」まで権限モデルに含めているかという問いです。
さらに深く掘り下げたいなら
Cloudflare OS: an open platform for agents, apps, and work 3つの構成要素、Gatekeeperの観察記録、Gadgetの共有ポリシーを公式事例で確認できます。 blog.cloudflare.com
cloudflare/cloudflare-os ライセンス、例示プロンプト、ローカル実行方法、アーリーアクセスの制限を確認するのに適した公式リポジトリです。 github.com
Deploy Cloudflare OS to Cloudflare 現在のホスティングデプロイに必要なインスタンス名・管理者メールアドレスと、デフォルトモデルの課金案内を実行前に確認できます。 os.cloudflare.app
Sandstorm is returning to its community roots Sandstormの事業終了時における製品完成度・企業営業・資金の問題を、創業者自身が整理した振り返りです。 sandstorm.io
