Cloudflare OS に生成AIをどう入れるか — Codex の定額枠は使えない
Cloudflare OS に生成AIをどう入れるか — Codex の定額枠は使えない
Cloudflare が 2026年8月4日に Cloudflare OS をオープンソースで公開した。社員全員にAIエージェントと作業場を配るための基盤で、Apache-2.0 ライセンス、GitHub からそのまま自社の Cloudflare アカウントへデプロイできる。
組織にAIエージェントを入れる土台としては筋がいい。権限の設計が「エージェントには最初から何も渡さない」から始まっていて、鍵を配って回る運用にならない。
ただ、導入を考えると最初に詰まるのがモデルの調達だ。ChatGPT のプランには Codex の利用枠が含まれている。あれを組織の共有バックエンドに流用できれば、推論代を月額に固定できる。そう考えたくなる。
結論から言うと、Cloudflare OS の推論のバックエンドとしては使えない。Codex の枠と Cloudflare OS の推論経路は、認証のしくみが別物になっている。
ただし「Codex がまったく使えない」という話ではない。Claude Code から codex exec を呼ぶような、手元の端末で自分のアカウントで動かす形なら定額枠は生きる。境目がどこにあるのかも含めて、順に見ていく。
なお筆者はまだ自社環境へのデプロイを完了していない。以下の手順は公開されているドキュメントとリポジトリの記載に基づくもので、実機で通したものではない。
Cloudflare OS は3つの部品でできている
まず対象の輪郭をはっきりさせておく。Cloudflare OS は3つの層からなる。
| 層 | 実体 | 役割 |
|---|---|---|
| ワークスペース | Durable Object | 会話・文書作成・コード実行の場。自社の用語や手順を文脈として持たせる |
| Gatekeeper | サービスごとの Worker | GitHub や Google などへの接続を仲介する。OAuth と認証情報を保持し、ポリシーを適用して読み取りを記録する |
| Gadget | Dynamic Worker | 社員が自分用に作る小さなアプリ。サンドボックスで動き、既定では何にもアクセスできない |
肝は真ん中の Gatekeeper だ。エージェントに API キーやデータベースの認証情報を直接渡さず、「この資源にこの条件で触れてよい」という権限だけを渡す。誰が何を読んだかは記録に残る。
Cloudflare 社内では2026年5月から全社員が使っていて、エンジニア以外の部署でも文書やスライドの作成に使われているという。
マネージド版はダッシュボードから提供される予定になっているが、時期は明示されていない。今すぐ試すなら自分のアカウントへデプロイする形になる。
推論はすべて AI Gateway を通る
ここが本題の入口になる。Cloudflare OS では、推論の呼び出しがすべて Cloudflare AI Gateway を経由する。迂回する設定はない。
これは制約であると同時に、組織で使うときの利点でもある。管理者は推論費用がどこで発生しているかを1か所で把握でき、予算の上限とレート制限をかけられる。全社員に配る基盤としては、この一元管理があるかないかで運用の重さが変わる。
設定は スターターリポジトリ の deployment.jsonc に集約されている。AI に関わる部分はここだ。
"aiGateway": {
"enabled": false,
"name": "<AI_GATEWAY_NAME>",
"accountId": "<AI_GATEWAY_ACCOUNT_ID>",
"providers": ["anthropic", "openai", "google", "cloudflare"],
"workersAi": { "mode": "gateway", "gateway": "<WORKERS_AI_GATEWAY_NAME>" }
}
既定は enabled: false。有効にしたうえで、providers に並んでいる提供元の認証情報を別途登録する。並んでいるのは Anthropic、OpenAI、Google、そして Cloudflare 自身の Workers AI である。
エージェントの中身には、Pi というコーディングエージェントのコア(pi-agent-core)が使われている。多数のモデル提供元を1つのインターフェースで扱えるライブラリで、Cloudflare OS が「好きなモデルを使える」と言えるのはこれが土台にあるからだ。この点は後で効いてくるので覚えておいてほしい。
Codex の定額枠が入らない理由
さて本題である。
OpenAI の Codex は、ChatGPT の Free / Plus / Pro / Business / Enterprise のいずれのプランにも含まれている。追加料金なしで、プランに含まれる枠の範囲で使える。公式ドキュメントにも、ChatGPT でサインインした場合は「枠を使い切るまでトークン単位の請求は発生しない」と明記されている。
一方、API キーで認証した場合は OpenAI Platform の標準料金で全トークンが課金され、プランの枠には一切触れない。
この2つは別勘定である。そして AI Gateway が扱えるのは後者、つまり API キーの方だけだ。
理由は経路にある。ChatGPT のプランに含まれる枠は OAuth でサインインして使う。Codex CLI、IDE 拡張、ブラウザ版といった「Codex のクライアント」から入ることを前提にした認証で、取得したトークンは端末の ~/.codex/auth.json に置かれる。AI Gateway は api.openai.com に対する中継役なので、この経路には接続点がない。
企業向けには Codex access token という仕組みがあり、CODEX_ACCESS_TOKEN を環境変数から渡してヘッドレスでログインできる。ただしこれも Codex CLI に食わせるためのもので、AI Gateway の OpenAI 経路に流し込めるものではない。一般的な API 呼び出しには Platform の API キーを使うよう案内されている。
規約の面でも成立しない
仮に技術的な回避策を見つけたとしても、運用に載せられない。OpenAI の規約はアカウントの共有を禁じている。複数の社員が同じ認証情報で同時にアクセスすれば、異常な利用として検知され、機能制限やアカウント停止につながる。
組織で使うなら席(seat)を人数分買うのが正しい形で、そのために ChatGPT Business や Enterprise がある。1人分の定額を全社で分け合う設計は、そもそも想定されていない。
Anthropic 側も同じ、というよりもっと明快
Claude で代替できないかとも考えたが、こちらはさらにはっきりしている。Pi のドキュメントには、Claude Pro / Max のサブスクリプション認証について「サードパーティのハーネスからの利用は追加利用分として扱われ、Claude のプラン上限ではなくトークン単位で課金される」と書かれている。
つまり Claude Code 以外のツールから使うと、定額枠から引かれずに従量課金になる。定額の枠を外部のエージェント基盤に流用する道は、OpenAI 側にも Anthropic 側にも用意されていない。
Pi の CLI なら使える、という紛らわしい事実
ここで最初に触れた Pi の話が効いてくる。
Pi の CLI 版は /login を実行すると、ChatGPT Plus / Pro の Codex 枠を OAuth で使える。ドキュメントには OpenAI から公式に認められた方式だと書かれている。GitHub Copilot、xAI、OpenRouter なども同様に扱える。
だからこう考えたくなる。「Cloudflare OS は Pi を使っているのだから、同じことができるのでは?」
できない。Pi の CLI は開発者の端末で動くプログラムで、OAuth トークンをそのローカルのファイルに置く。Cloudflare OS は Workers の上で動く共有ワークスペースで、推論は AI Gateway を通す。同じライブラリを土台にしていても、動く場所と認証の経路が違う。
Codex の定額枠を使いたいなら、それは各開発者が自分の端末で自分のアカウントで使うものであって、組織の共有基盤の燃料にはならない。ここを混同したまま導入を計画すると、後から前提が崩れる。
ツールとして呼べばいいのでは、という筋
ここで当然の疑問が出る。Claude Code は codex exec を子プロセスとして呼べる。これは OpenAI 公式のヘッドレス実行機能で、ChatGPT にログインした状態のままスクリプトから走らせられる。CI でも Docker の中でも SSH 越しでも動く。
だったら Cloudflare OS も、モデルを直接叩くのではなく codex CLI をツールとして呼べばいいのではないか。
筋としては通っている。技術的にも道はある。Cloudflare は2026年4月に Containers と Sandbox SDK を正式提供にした。Workers から隔離されたコンテナを起動し、その中で任意の Linux バイナリを走らせられる。codex CLI を置くこと自体はできる。
ただし壁が3つ残る。
壁1: Cloudflare OS の標準ランタイムはコンテナではない
公開されている資料を読む限り、Cloudflare OS のコード実行は Dynamic Workers、つまり V8 の isolate で動く。JavaScript の実行環境であって、Linux のバイナリを起動する場所ではない。
Sandbox を使いたければ、それを呼び出す Gadget なり Gatekeeper なりを自分で書くことになる。標準機能として用意されているものではない。
壁2: 誰のアカウントで動かすのか
これが本質的な問題になる。
Claude Code から codex を呼ぶ形が成り立つのは、開発者本人の端末で、本人がログインした認証情報を使っているからだ。1人が自分の枠を使っているだけなので、何も引っかからない。
サーバー側に持っていくと、この前提が崩れる。全社員のリクエストを1つのアカウントで処理すれば、それはアカウントの共有であって規約に反する。社員ごとのアカウントで動かすなら、1人ずつの認証情報をサーバー側に預かって出し入れする仕組みが要る。OpenAI 自身、認証情報のファイル(~/.codex/auth.json)はパスワードと同様に扱うこと、信頼できる実行環境でのみ使うことを求めている。
壁3: 公式が推奨していない
非対話モードのドキュメントには、自動化には API キーを使うのが既定だと書かれている。発行とローテーションが簡単だからだ。ChatGPT アカウントでの認証については「自分の Codex アカウントとして実行する必要が特にある場合にのみ、この道を使え」とある。
公式の想定は「自動化なら API キー」であって、定額枠をサーバーに持ち込む使い方は例外として扱われている。
まかなえる範囲も限られる
仮にこれらを越えて Sandbox で codex を動かしたとしても、定額枠でまかなえるのは codex に投げた作業だけになる。社員がワークスペースで交わす日常の会話、文書の作成、Gadget の生成といった Cloudflare OS 本体の推論は、これまでどおり AI Gateway を通って従量課金される。
推論費用を月額に固定したい、という当初の狙いには届かない。
では何を使うか — 3通りの入れ方
定額の道がないと分かったところで、現実的な選択肢を整理する。3通りある。
① 自分の API キーを預ける(BYOK)
OpenAI や Anthropic の API キーを Cloudflare のダッシュボードに登録し、ゲートウェイの設定から参照する方式。キーは Secrets Store に暗号化して保管される。リクエストごとにキーを載せる必要がなくなり、ローテーションも1か所で済む。
すでに各社と法人契約があるなら、これが最短で、いちばん素直だ。迷ったらここから始めるのがよい。
② 支払いを Cloudflare にまとめる(Unified Billing)
Cloudflare が提供元の認証情報を持ち、前払いのクレジットから引き落とす方式。手数料が 5% 乗るが、請求書が1本にまとまる。2026年8月7日からは Workers AI の推論費用も同じクレジットで払えるようになった。
経理の手間を減らしたい組織には向く。ただし対応している提供元は限られる。
③ Workers AI を使う
Cloudflare が管理する GPU 上で公開モデルを動かす。支払いは Cloudflare への従量課金に一本化される。deployment.jsonc の workersAi.mode を direct にすればゲートウェイを介さず直接呼ぶこともできる。
社内文書の要約や分類のように、最新の商用モデルを必要としない作業を安く回すのに向く。逆に、込み入った推論を任せたいなら①か②が要る。
上限は自分で決められる
3つとも従量課金だが、青天井ではない。AI Gateway に予算の上限とレート制限を設定でき、部署や用途ごとにリクエストの流し先を切り替える動的ルーティングもある(利用にはゲートウェイの認証を有効にし、BYOK でキーを保管しておく必要がある)。
定額プランは買えないが、使いすぎない仕組みは作れる。 組織導入で本当に必要なのは後者のはずで、そこは基盤側が引き受けてくれる。
セットアップの手順
ここからは実際に動かすまでの流れになる。スターターリポジトリの手順に沿って書く。
前提として要るもの
- Cloudflare アカウントと、有効なゾーン(独自ドメイン)
- Node.js 24 と pnpm 11
- Workers、KV、R2、Browser Rendering、Dynamic Worker Loaders が使えること
- AI 関連(Workers AI / AI Gateway)は任意
ドメインが要るのは、サインインに Cloudflare Access を使うためだ。
1. 手元で動かして中身を見る
デプロイの前に、ローカルで触っておくと判断が早い。
git clone https://github.com/cloudflare/cloudflare-os.git
cd cloudflare-os
pnpm install
pnpm run-local
http://localhost:8787 が立ち上がる。wrangler と workerd で動くので本番用ではないが、どういうものかは分かる。データは .wrangler 配下に置かれる。
開発しながら触るなら pnpm dev-server と pnpm dev-client を並行して起動し、http://localhost:3000 を開く。
2. 自社アカウントへの配置を準備する
スターターを使う。
git clone https://github.com/cloudflare/cloudflare-os-starter.git
cd cloudflare-os-starter
git submodule update --init
pnpm install
pnpm --dir cloudflare-os install
pnpm exec wrangler login
3. サインインの経路を作る
Cloudflare Access で self-hosted のアプリケーションを作り、ワークショップ用のホスト名(os.example.com のような、自社ゾーン内の名前)を割り当てる。作成後に表示される audience tag を控えておく。
Zero Trust は50ユーザーまで無料で、それを超えると1人あたり月額7ドル(年払い)になる。小さな組織なら当面は無料枠に収まる。
4. deployment.jsonc を埋める
設定はこのファイル1つに集約されている。
{
"accountId": "<CLOUDFLARE_ACCOUNT_ID>",
"workers": {
"workshop": { "name": "<WORKSHOP_WORKER_NAME>", "route": { "customDomain": "os.example.com" } },
"context": { "name": "<CONTEXT_WORKER_NAME>" },
"customGatekeeper": { "name": "<CUSTOM_GATEKEEPER_WORKER_NAME>" },
"errorReporter": { "name": "<ERROR_REPORTER_WORKER_NAME>" }
},
"access": {
"issuer": "https://<TEAM_NAME>.cloudflareaccess.com",
"audience": "<ACCESS_AUDIENCE>",
"admins": ["<ADMIN_EMAIL>"]
},
"aiGateway": { "enabled": true, "providers": ["anthropic", "openai"] },
"resources": {
"blueprintsKvNamespaceId": null,
"avatarsKvNamespaceId": null,
"blueprintContentBucket": null
}
}
ストレージの各 ID は null のままにしておくと Wrangler が作ってくれる。既存のものを使うなら ID を書く。
5. モデルの鍵を登録する
ダッシュボードで AI > AI Gateway を開き、対象のゲートウェイの Provider Keys から提供元の API キーを登録する。Secrets Store の秘密が自動で作られる。
API から作る場合は命名規則がある。
{gateway_id}_{provider_slug}_{alias}
たとえば my-gateway_anthropic_default となる。アプリケーション側からは、提供元のキーではなくゲートウェイのトークンを渡す形になる。
curl ... -H 'cf-aig-authorization: Bearer {CF_AIG_TOKEN}'
用途ごとに鍵を分けるなら cf-aig-byok-alias ヘッダで別名を指定する。ただし既定の別名が見つからない場合は Unified Billing 側にフォールバックする挙動になっているので、両方を有効にしているときは意図しない請求先に流れないか確認しておきたい。
6. 検証してデプロイする
pnpm check
pnpm deploy
デプロイ後の確認は3点。ホスト名にアクセスして Access の認証が要求されること、/admin を開いて自分のメールアドレスが管理者として認識されていること、Gatekeeper が動作すること。
費用の見積もり方
推論代のほかにかかるものを整理しておく。
- Zero Trust: 50ユーザーまで無料。超過分は1人あたり月額7ドル(年払い)
- Workers、KV、R2 ほか: 従量課金。開発者向け製品はまとめた「開発者プラン」がなく、それぞれの使用量で課金される
- AI Gateway 自体: すべてのプランで利用可能。無料枠がある
- 推論: 選んだ経路に応じて各提供元、または Cloudflare へ
読めないのは推論代だけで、それも上限を設定できる。まず小さな部署で回して単価を掴んでから広げるのが安全だろう。
まとめ
- Cloudflare OS の推論は例外なく AI Gateway を通る。モデルの差し込み口はここ1か所しかない
- ChatGPT のプランに含まれる Codex の枠は OAuth の別経路にあり、AI Gateway からは呼べない
- Claude Code から
codex execを呼ぶ形で定額枠が生きるのは、本人の端末で本人のアカウントを使っているからだ。ここをサーバーに持っていくと前提が崩れる - Sandbox SDK でコンテナを立てれば codex CLI を Cloudflare 上で動かすこと自体はできる。ただし Cloudflare OS の標準機能ではなく、認証と規約の壁が残り、公式も自動化には API キーを勧めている
- 仮に動かせても、定額でまかなえるのは codex に投げた作業だけで、ワークスペースの会話は従量課金のまま
- 実際の選択肢は、自分の API キーを預けるか、支払いを Cloudflare にまとめるか、Workers AI で済ませるかの3つ。すでに法人契約があるなら1つ目から始めるのが早い
- 定額にはできないが、予算の上限とレート制限で使いすぎは止められる。組織導入で本当に要るのはそちらのはずだ
Codex や Claude Code の定額枠は、開発者ひとりの生産性を上げる道具として設計されている。組織全員に配るエージェント基盤の燃料として使うものではない。手元で codex exec を呼ぶ運用はそのまま続ければよく、共有基盤の推論費用は基盤側の予算管理で締める。この2つを分けて考えるのが、いちばん摩擦が少ない。
出典
- Cloudflare OS: an open platform for agents, apps, and work(Cloudflare Blog)
- Cloudflare OS Is the First AI Workspace Built Around How Companies Actually Work(プレスリリース)
- cloudflare/cloudflare-os(GitHub)
- cloudflare/cloudflare-os-starter(GitHub)
- BYOK (Store Keys)(Cloudflare AI Gateway docs)
- Dynamic routing(Cloudflare AI Gateway docs)
- Workers AI and AI Gateway unify model access and billing(Changelog)
- Authentication(Codex ドキュメント)
- Non-interactive mode(Codex ドキュメント)
- Sandbox SDK Overview(Cloudflare docs)
- Containers and Sandboxes are now generally available(Changelog)
- Providers(Pi Coding Agent ドキュメント)