こんにちは。健ちゃんです。
Cloudflareが「Cloudflare OS」というものを公開しました。社内で数千人の従業員が使っているAIの作業場を、そのままオープンソースにしたものです。
ニュースとしては「へえ」で終わる話かもしれません。ですが中身を読んでいくうちに、これは他人事ではないなと思いました。そこで実際に、自分のドメインに Cloudflare OS を建ててみました。
Cloudflareへ払うのは月5ドルです。作業は半日でした。
この記事では、何ができたのか、どこで詰まったのか、そして建ててみて初めて分かったことを書きます。建ててみたい方には手順の勘所を、そうでない方にも持ち帰れるものを用意しました。
---
そもそも、これは何なのか
先に、Cloudflare OS が何者なのかをはっきりさせておきます。
一言でいうと、自分の会社の事情を知っていて、自分の会社のシステムを安全に触れるAIの（クラウド上の）作業場です。
ChatGPT や Claude との違いは2つあります。
1つ目は、会社の文脈を最初から持っていることです。社内用語や業務手順を「スキル」として登録しておくと、AIがそれを前提に動きます。毎回説明し直す必要がありません。
2つ目は、社内システムに手が届くことです。GitHub、Notion、Slack、Googleドライブ。こうしたサービスに繋いで、AIが直接読み書きできます。
ここで当然、こう思われるはずです。「AIに社内システムを触らせるなんて怖い」と。
その怖さにどう答えるかが、この製品の全部です。以下の図が、その答えの形です。
利用者とAIの間に、そして AI と社内システムの間に、それぞれ関所が置かれています。手前が Cloudflare Access（誰が入れるか）、奥が Gatekeeper（AIが何を触れるか）です。AIは社内システムに直接繋がりません。必ず門番を経由します。
特徴はもう1つあります。この作業場では、一人ひとりが自分専用のアプリを作れます。 「経費精算の一覧を出すツール」のようなものを、AIに作らせてその場で使えます。そのアプリは利用者ごとに完全に隔離された状態で動きます。
なぜそんな面倒な作りにするのか。その理由は、10年前に遡ります。
---
10年早すぎた人が、戻ってきた
先に背景を1つだけ。ここを知っていると、Cloudflare OS という製品が全く違って見えます。
Cloudflare OSを設計したのは Kenton Varda という技術者です。いまCloudflare OSが動いている基盤、Cloudflare Workers そのものを作った人でもあります。
その人が2015年に、Sandstorm.io というスタートアップをやっていました。掲げていた思想は「アプリを、利用者ごと・文書ごとに完全に隔離した状態で動かす」というものでした。
その会社は成功しませんでした。理由は単純で、当時の技術では隔離のコストが高すぎたからです。一人ひとりに専用の実行環境を配るなど、贅沢すぎて割に合いませんでした。
そして10年が経ち。
Cloudflare Workers が使っているV8アイソレートという仕組みによって、隔離のコストはおよそ100分の1になりました。ブラウザがタブごとにJavaScriptを隔離しているのと同じ技術を、サーバー側で使うやり方です。専用のサーバーを一人ずつ立てるのに比べれば、桁が違います。
安くなっただけではありません。当時は存在しなかったものが現れました。AIエージェントです。
そしてAIエージェントには、人間の従業員にはない性質があります。指示を取り違えます。読んではいけないものを読みます。「直しました」と報告しながら直っていないことがあります。 悪意があるわけではありません。ただ、確実ではないのです。
Cloudflare はこれを欠陥として扱いませんでした。前提として扱うことにしたんです。エージェントは信用できない。ならば、間違えても被害が出ない作りにすればいい、と。
ここが Cloudflare OS の設計の出発点です。この「信用しない」がどう形になっているかは、記事の後半でGatekeeperの仕組みとして詳しく見ていきます。
さて、AIが信用できない働き手だとすると、隔離は贅沢品ではなく必需品になります。10年前に早すぎたアイデアが、前提条件の変化によって復活したわけです。Cloudflare OSは、その再挑戦として作られています。
---
Gatekeeper — 鍵ではなく、リードを渡す
ここがCloudflare OSの心臓部です。全体を貫く原則は、公式ブログのこの一文に表れています。
> agents start with access to nothing
エージェントは、権限ゼロから始まる。何も触れない状態が初期値で、許したものだけが触れるようになります。
僕たちが普段やっていることを思い出してください。AIに GitHub を触らせたいとき、どうするか。アクセストークンを発行して、そのまま渡します。
このとき何が起きているか。トークンは、それを持つ人の権限そのものです。渡した瞬間から、AIはあなたと同じことが全部できます。issue を読むだけのつもりでも、リポジトリを消す権限まで一緒に渡っています。
Gatekeeper は、これをやりません。
Gatekeeper は、サービスごとに立てる小さな中継役です。トークンはGatekeeperが握ったまま、AIには渡しません。AIが受け取るのは「この操作だけができる」という権限の束です。
具体的にはこうなります。
| 項目 | 従来のやり方 | Gatekeeper | |---|---|---| | AIが持つもの | アクセストークン本体 | 「issue一覧を読む」という能力 | | できることの範囲 | トークンの権限すべて | 許可した操作だけ | | 対象の絞り込み | 基本できない | このリポジトリだけ、と指定できる | | 危険な操作 | そのまま実行される | 人間の承認を挟める | | 何を読んだか | 分からない | 全部記録される |
たとえばGitHubなら、「ENGチームのオープンなissueを読む」ことだけを許して、プルリクエストのマージには人間の承認を必須にする、といった設定ができます。AIはトークンの文字列を一度も見ません。
鍵は、持ち主の権限そのものです。能力は、繋いだリードです。 犬にリードを付けて散歩するのと、家の鍵束ごと渡して「散歩してきて」と言うのとの違いです。
さらに、読んだものが記録されて回る
Gatekeeper にはもう1つ、Observation Log という仕組みがあります。
エージェントが読んだリソースを全部記録して、その記録が成果物にくっついて回ります。 誰かがその成果物を開こうとしたとき、門番が「この人は元データを見る権限を持っているか」を確認してから表示します。
これは、いま多くの組織が気づきはじめている問題への回答です。AIは複数のシステムを横断してデータを結合できます。すると、それぞれ別々に権限管理していたはずの情報が、AIの出力という形で一箇所に集まります。そしてその出力が、元データを見る権限のない人へ渡ってしまいます。AIが権限の抜け道になるわけです。
Observation Log は、成果物のほうに出自を持たせることで、この抜け道を塞ぎます。
情報を成果物につける。 なかなか面白い発想ですね。
---
建ててみます
ここからは実際の作業です。
僕はすでにCloudflareでドメインを1つ運用していたので、そこのサブドメインに建てることにしました。この記事で書くのは、そちらの手順です。使うリポジトリはこちらです。
https://github.com/cloudflare/cloudflare-os-starter
ドメインを持っていない場合は、ワンクリックで workers.dev のアドレスに建てる道もあります。
https://os.cloudflare.app/deploy
ただしこちらは僕が試していないので、動きを保証できません。 サインインの設定がどうなるかを、建てた直後に必ず自分の目で確認してください。理由は「建てる前に確認してほしいこと」の節に書きます。
必要だったもの
| 項目 | 内容 | |---|---| | Workers Paid | 月5ドル。これは必須でした | | Zero Trust | 無料プランで足ります | | R2 | 有効化が必要。すでに使っていれば不要 | | ドメイン | Cloudflareで運用中のもの1つ | | Node.js 24 と pnpm 11 | 手元の環境 |
Workers Paidが必須なのは、Dynamic Worker Loader という機能を使うためです。AIが作ったアプリを、その場で読み込んで隔離した状態で動かす部分にあたります。この製品の土台にあたるので、ここを外すことはできません。無料プランのままデプロイしようとすると失敗します。
手順の骨格
1. Workers Paid にアップグレードする
2. Zero Trust を有効にする
3. Access のアプリケーションを作る
4. リポジトリを取得して依存関係を入れる
5. deployment.jsonc に値を埋める
6. pnpm check で検証して pnpm deploy
デプロイが通ると、Worker が4本、KVが3本、R2バケットが1つ、そしてDNSレコードとTLS証明書が自動で作られます。僕の場合、デプロイ自体は3分ほどで終わりました。
---
詰まったところ
ここが本題です。全部で18か所つまずきました。ただ、全部を並べても読むほうが疲れるだけです。あとから建てる方がつまずきやすく、知っておくと時間が浮く5つに絞って書きます。
なお、Cloudflare側の設定を実際の画面で追う手順書は、別記事にまとめました。 建てながら横に置いて使ってください。
https://note.com/kenhfp/n/n94cfd0ba8242
無料なのに、カードの同意を求められる
Zero Trust の無料プランを選ぶと、決済画面に飛ばされます。本日支払額は0ドルと表示されているのに、次の2つにチェックを入れろと言われます。
利用規約とプライバシーポリシーに同意します
このカードに対し、無料枠を超える使用量を毎月課金することを許可します
「無料と書いてあったのにカードの話が出てきた」と手が止まる方は多いと思います。ここは仕様です。無料枠は50ユーザーまでなので、一人で使う分には超えません。
チーム名は世界中で早い者勝ち
Zero Trust を有効にすると、チーム名が自動生成されます。僕の場合は summer-scene-fcd1 という文字列でした。
これは変更できます。ただし 〇〇.cloudflareaccess.com というアドレスになるため、同じ名前はCloudflare全体で1つしか使えません。 短い一般的な名前はまず取れないと思ってください。僕も希望した名前は既に使われていて、別の名前にしました。
さらに、変更するなら一番最初にやってください。後から変えるとログイン画面の表示が古いままになったり、連携済みの設定をやり直すことになります。
AUDタグという、奥に隠れている値
設定ファイルに書き込む値の1つに「AUDタグ」があります。これは Access のアプリケーション1つ1つに割り当てられる64文字の識別子です。
役割はこうです。Access は認証を通った人に署名付きのトークンを渡します。そのトークンには「これはどのアプリ向けか」が書き込まれていて、Cloudflare OS 側はそれが自分宛てかどうかを検証します。これがないと、同じ組織の別のサイト用に発行されたトークンを、そのまま使われてしまいます。
問題は、この値が見つけにくいことです。アプリの一覧にも、詳細タブにも出てきません。「追加設定」タブに移動して、そこを下にたどってようやく現れます。 初見で必ず迷う場所でした。
ネット上の手順書が、もう古い
Zero Trust のダッシュボードは最近URLの構造が変わっています。検索で出てくる手順書の多くが古いパスを指していて、そのまま開くと404になります。
対処は単純で、URLを直接打たず、左メニューをたどってください。 「Access コントロール」から「アプリケーション」へ進みます。
検証コマンドが親切だった
これは褒めるところです。設定ファイルの穴埋めを1つ忘れたまま pnpm check を実行したところ、こう返ってきました。
Deploy failed. deployment.jsonc: Replace deployment placeholder <ACCESS_AUDIENCE>.デプロイしてから失敗するのではなく、手前で止めてくれます。地味ですが、この手のツールでは大事なところです。
---
建ててから分かったこと
ここからが、実際に動かさないと書けない部分です。
デプロイしただけでは、AIは喋りません
設定ファイルにも管理画面にも、AIの設定項目はありません。サインインしたあと、アプリの中で設定します。 左下のアイコンから「Providers」を開き、モデルを選んでAPIキーを登録します。
そしてこのキーは、Cloudflareのものではありません。自分のOpenAIやAnthropicのアカウントのものです。つまり、推論の費用は自分持ちです。
選べる先はこうなっていました。
| プロバイダー | 例 | |---|---| | Cloudflare Workers AI | Kimi K2.7 Code、GLM 5.2 | | Anthropic | Claude Opus 5、Sonnet 5、Haiku 4.5 | | OpenAI | GPT 5.6 Sol、Luna、Terra | | Google | Gemini 3.6 Flash | | Ollama | ローカルで動かしているモデル |
最後のOllamaがあるのは見逃せません。手元で動かしているモデルを繋げば、API課金なしで回せます。
1往復で、4円
キーを入れて、試しに一言だけ聞いてみました。「あなたはどのモデルですか。1行で答えてください」と。
返ってきたのは1行です。そして画面の下にこう表示されました。
5,116 tokens $0.02611行の返事に、5,116トークン。日本円でおよそ4円です。
会話の中身が短くても、システムプロンプトと会社の文脈が毎回積まれるため、この単価になります。画面の右上には、そのワークスペースの累計金額が表示され続けます。
この数字を見た瞬間に、公式ブログの記述が別の意味を持ちはじめました。
Cloudflareは、すべての推論をAI Gatewayという中継点に通す設計にしています。そして人ごと・チームごと・ワークスペースごとに費用を追跡できるようにしています。ブログにはこう書かれています。高価なモデルは、最も難しい仕事にだけ使われるようにする、と。
読んだときは、大企業向けの管理機能という程度に思っていました。ですが自分の画面で4円を見ると、話が変わります。これは全社員に配る製品です。一人が一日に何十往復もして、それが何千人分になったらどうなるか。コストの追跡は、あれば便利な機能ではなく、この製品が成立するための前提だったわけです。
---
工房に、仕事をさせてみます
建てただけでは、ただの空き家です。せっかくなので働かせました。
頼んだのは記事のネタ帳です。日本語で3文だけ書きました。
> 記事のネタ帳アプリを作ってください。記録する項目は、タイトル、狙い、状態（未着手・執筆中・公開済み）、公開先アドレスの四つです。一覧表示と、新しいネタの追加ができるようにしてください。状態で絞り込めると助かります。画面の文言は日本語でお願いします。
1分ほどで、server.js と client.js と README.md の3つが出てきました。消費は9,721トークン、$0.2150です。
ここで面白いのが、すぐには反映されないことでした。画面に「Pending changes」と出て、「Accept changes」を押すまで待たされます。AIが書いたコードが、人間の承認を挟んでから初めて動く。Gatekeeperの節で見た「危険な操作には人間を挟む」という思想が、コードの反映にもそのまま効いているわけです。
承認すると、その場でアプリが立ち上がりました。入力フォーム、一覧、状態での絞り込み。頼んだとおりの画面です。
ChatGPTにコードを書かせるのと、何が違うのか
ChatGPTに「こういうアプリを作って」と頼んでも、コードは出てきます。ですがそこから先が自分の仕事です。ファイルに保存して、実行環境を用意して、保存先を繋いで、どこかへデプロイする。
Cloudflare OSでは、その全部が済んだ状態で出てきます。アプリはもう動いていて、アドレスがあって、データも保存されます。 保存先はこのアプリ専用に割り当てられたDurable Objectで、他のアプリからも、他の利用者からも見えません。
出てくるのはコードではなく、動いているアプリです。ここが決定的に違うところでした。
そして、バグを踏みました
ネタを入力して「ネタを追加する」を押しました。
何も起きません。
一覧は0件のまま。リロードしても保存されていません。キーボードで押しても同じでした。エラーメッセージすら出ません。うんともすんとも言わないという、一番たちの悪い壊れ方です。
症状だけを日本語で投げると、エージェントは自分の書いたコードを読み直し、原因を挙げてきました。ただし最初の答えは外れです。承認して試しても、まだ動きません。もう一度突き返して、ようやく真因に届きました。
> 原因は、ボタン押下が form の submit イベントに依存していたことです。Gadget の iframe 環境では通常のフォーム送信が期待通りに発火しない／ブロックされるケースがあり、その場合はアプリ側の追加処理まで到達しません。
このアプリはサンドボックスの中で動いています。そのサンドボックスはフォーム送信を許可していないので、送信そのものが黙って落ちていたわけです。ボタンを普通のボタンに変え、クリックから直接処理を呼ぶように書き換えて、動くようになりました。
3件登録して、状態のバッジも絞り込みも効いています。note.com/kenchan/cloudflare-os と略して入れたアドレスが、https:// 付きに直してリンクになっているのも、直したついでの仕事です。
ここから持ち帰ったこと
作った当人が、動作確認をしていませんでした。そして一度目は「直しました」と報告しながら、直っていませんでした。
記事の前半でこう書きました。エージェントは指示を取り違える、読んではいけないものを読む、「直しました」と報告しながら直っていないことがある、と。その3つ目を、自分の画面で踏んだわけです。
これは製品の欠陥というより、AIエージェントというものの性質でしょう。だからこそ Cloudflare OS は、コードの反映に人間の承認を挟みます。承認なしで即反映される作りだったら、壊れたアプリが壊れたまま増えていくだけです。
信用しないけれど、使う。 その距離の取り方が、製品の作りそのものに現れていました。作らせて、壊れて、直させて、動くまで。かかったのは合計でおよそ130円です。
安い授業料だったと思っています。
---
建てる前に確認してほしいこと
ここは飛ばさないでください。お金の話です。
Cloudflare OS は、建てた人のCloudflareアカウントの上で動きます。ということは、そこで動いたWorkerの実行時間も、保存したデータの容量も、全部あなたへの請求になります。
誰がここに入れるのかを、必ず自分で確認してください。
守りは二重になっています。
1つ目は、Cloudflare Access です。 誰がサインインできるかを、メールアドレス単位で指定します。僕は自分1人だけを許可しました。それ以外の人はアプリの手前で止まります。
2つ目は、`/admin` の Access タブにある「Allow new sign-ups」です。 これがオンだと、新しいアカウントが作られます。説明文にはこう書かれています。
> When off, existing users can still log in but no new accounts can be created.
僕の環境では、初期状態でオンになっていました。 Accessで1人しか通れないので実害はありませんが、Accessのポリシーを広く取るなら、真っ先に切るべき設定です。
AIの利用料については、少し事情が違います。デプロイ時に aiGateway.enabled: false としている場合、デプロイ側が費用を持つモデルは1つも配られません。 公式ドキュメントにこう書かれています。
> Deploys without an AI secret; no funded model catalog is advertised
APIキーはサインインした人が各自で登録する作りなので、他人が入ってきても、その人が自分のキーを持ち込まないとAIは動きません。AI費用の垂れ流しは起きにくい構造です。
ただし繰り返しますが、Cloudflare側の利用料は所有者持ちです。 入口を絞る。これだけは最初にやってください。
なお、ワンクリックでデプロイする方式については、何で認証をかけるのかを僕は確認していません。使う場合は、建てた直後にサインイン設定を必ず自分の目で確認してください。
---
建てない人が持ち帰れること
ここまで読んで「自分は建てないな」と思われた方へ。むしろ、こちらが本題かもしれません。
Gatekeeperの考え方は、そのまま自分の環境に持ち込めます。
いま、お手元の `.env` に何が入っているでしょうか。 MCPサーバーに、必要以上の権限を持つトークンを丸ごと渡していないでしょうか。AIに「このリポジトリを見て」と頼んだとき、そのAIは他のリポジトリも消せる権限を持っていないでしょうか。
Cloudflare OS を建てなくても、明日からできることが3つあります。
用途ごとにトークンを分けて発行すること。 1本のトークンを使い回さない。
読み取り専用と書き込みを別のキーにすること。 調べものをさせるだけなら、書き込み権限は要りません。
AIが何を読んだかのログを残すこと。 何かあったときに追えるようにしておく。
どれも地味です。ですが、Cloudflare が数千人規模で運用するために作った仕組みを、一人分に縮めると、だいたいこの3つになります。
---
誰が建てるべきか
正直なところを書きます。
建てる価値があるのは、次のような方です。 自分のドメインを持っていて、複数のサービスをAIから触らせたくて、権限管理を自分で設計したい方。あるいは、この設計思想を手を動かして理解したい方。
やめておいたほうがいいのは、次のような方です。 単にAIと会話したいだけの方。それなら既存のサービスを使うほうが速くて安いです。それから、ターミナル作業に抵抗がある方。前半と後半はブラウザ操作ですが、真ん中はコマンドを打ちます。
なお現時点では、公式ドキュメントが整備途中で、マネージド版もまだ提供されていません。早期アクセスの製品だと思って触るのが正しい距離感です。
限界もはっきりしています。「AIは重大なセキュリティバグを作れない」という主張が成り立つのは、アプリが箱の外に影響しない間だけです。役に立つアプリは、いずれ必ず外に触ります。人間が承認のループに入り続ける構造は、自律性とのトレードオフでもあります。
それでも、エージェントを信用しないという前提から出発して製品を作ったという事実は、記録しておく価値があると思っています。いまの業界は、AIに権限を渡す方向へどんどん進んでいます。その逆を行く設計が、どこまで実用に耐えるのか。手元で動かしながら見ていけるのは、贅沢な状況です。
---
まとめ
月5ドルで、自分のドメインにAIの工房が建ちました。
半日かかりましたが、詰まりどころを全部避けられれば1時間ほどで終わる作業だと思います。この記事に書いた落とし穴が、その助けになれば幸いです。
そして何より、建ててみて良かったのは、読んだだけでは分からなかったことが分かったという点です。1往復4円という数字を自分の画面で見なければ、コスト追跡機能の意味を理解することはなかったはずです。AIが作ったアプリが動かず、一度目の修正でも直らない。あの手触りも、記事を読んでいるだけでは絶対に得られません。
「エージェントは信用できない」という設計思想を、ここまで実感つきで納得できるとは思っていませんでした。
新しいものが出たとき、記事を読んで分かった気になるのは簡単です。ですが5ドル払って半日使うと、その先が見えます。今回はそれが確認できただけでも収穫でした。
みなさんもぜひ、自分の工房を建ててみてください！