8語で作らせたアプリを、同じAIが操作して対局した。Cloudflare OSを無料で試した記録

Cloudflareが社内で使っているAI基盤「Cloudflare OS」を、2026年8月5日にOSS公開した。ブラウザでAIに仕事を頼むと、回答ではなくGadgetと呼ばれる業務アプリを作って返す、という仕組みだ。AIを毎回使う道具ではなく、道具の作り手として使う。

面白そうだったので、手元のWindows機で動かした。立てた問いは1つで、「これを自分のFree枠で本番まで持っていけるのか」だ。私がこのブログを載せているCloudflareのアカウントはFreeプランなので、そのまま実験台にできるつもりでいた。

結論から書くと、ローカルで動かすところまでは無料で完走できた。ただしその範囲ではCloudflareのアカウント自体が要らず、本番として自分のドメインに載せる段になると有料プランが必要になる。そして一番書きたいのは、その途中で起きたことのほうだ。8語で作らせたばかりのアプリを、同じAIに操作させて、私と1局対戦させた。

動かすまでに4回落ちた

対象はコミット 8b08672(2026年8月10日時点)。リポジトリ本体は6.3MBと軽い。手順は pnpm run-local を叩くだけ、のはずだった。

Windowsでは完走しない。spawnSync pnpm ENOENT で落ちる。Windowsの pnpm は実体が pnpm.cmd で、Nodeの execFileSync は shell オプションなしに .cmd を起動できないためだ。厄介だったのは、落ちる箇所が1つではなかったこと。1箇所直すと次で落ちる、を3回繰り返して、最終的に4箇所だった。ローカル起動スクリプト本体、開発サーバの起動処理、そしてGatekeeperという仲介コンポーネント2つのビルドスクリプトだ。

当てたパッチは4箇所とも同じ1行で、子プロセスの起動オプションに shell: process.platform === "win32" を足しただけだった。shell: true にするとNodeがDEP0190(引数がエスケープされない)を警告するが、渡している引数は固定文字列だけなので実害はない。macOSとLinuxの挙動を変えないようにプラットフォームで限定した。

READMEには「very capable, but still has many rough edges」と書いてある。誇張ではなかった。裏を返せば、開発チームがWindowsで動作確認していないことがそのまま出ているだけで、直し方に迷う類の問題ではない。

動いてしまえば速い。実測はこうだった。

• pnpm install: 51.7秒
• フロントエンドのビルド: 13〜20秒
• 起動後の最初のアクセス: 32秒。2回目以降は10ms

これで http://localhost:8787 にCloudflare OSのサインイン画面が出る。ここまでCloudflareのアカウントは要らない。

訂正:AIは同梱されていない

ここで前提を1つ訂正することになった。私は「Cloudflareが公開したAI基盤」という言葉から、動かせばAIも付いてくると思っていた。付いてこない。

モデルのAPIキーは自前だ。Pi(pi-agent-core)経由で複数のプロバイダに対応していて、モデルはユーザーが設定したものから選ぶ建て付けになっている。つまり無料で手に入るのは器の部分——Workers、Durable Objects、サンドボックス——までで、エージェントを動かした瞬間からモデル側の従量課金が発生する。

課金なしで完走する道がないか、先に試した。

ローカルLLMという抜け道は成立しなかった

手元にOllama 0.32.8が入っていたので、これを繋いだ。設定画面の Other Ollama... からモデルIDとURLを入れるだけで、APIトークンは空でよかった(空文字のときはAuthorizationヘッダ自体を送らない実装になっている)。接続そのものは成功した。

使えたのは qwen3:4b のほうだけだった。もう1つ持っていた gemma3:4b は、Ollamaが返す能力情報がテキスト補完のみでツール呼び出しに対応していない。Cloudflare OSのエージェントはコードを書いて即実行する方式なので、ツール呼び出しができないと話にならない。

そして qwen3:4b に「2+2は?」と1回聞いた。結果はこうだ。

エラーは出ていない。ただ遅い。数値はOllama側のサーバーログから取った。

速度以上に効いたのはコンテキスト長だった。Ollamaの既定値は4,096トークンで、そのうち3,106トークンをエージェントのシステムプロンプトが占めている。残りは約990トークンしかない。コードを書いて実行する方式は、ツール定義とコードの往復で消費するので、Gadget生成に進めば即座に溢れる。設定でコンテキスト長を上げれば緩和はできるが、CPU推論ではプロンプト処理の時間が伸びるだけで根本解決にはならない。

ここで打ち切った。GPUのない4Bクラスでは、無料で回す抜け道は成立しない。これは私の環境での実測であって、GPUがある機械やもっと大きいモデルで同じ結論になるかは試していない。

8語で作らせた

ホスト型のAPIに切り替えた。設定画面にプリセットが並んでいるので、Claude Sonnet 5を選んでAPIキーを貼るだけで済んだ。

入力したのは「Make a tic tac toe game.」の8語。

事前の見積もりは1桁外れていた。エージェントが数十回モデルを呼んで履歴を積み上げながら再送する前提で$1前後と計算していたが、実際は$0.09だった。コードを書いて即実行する方式は往復が少なく、コンテキストがほとんど膨らまない。

ただしこれはtic tac toe 1件の実測なので、この数字を一般化して「Cloudflare OSは安い」と言うつもりはない。単価の前提も書いておく。計測時のClaude Sonnet 5は入力$2/出力$10 per MTokだった。これは当初、2026年8月31日までの導入価格として発表されていたものだが、公式ドキュメントによると現在はこれが標準価格で、9月1日に予定されていた$3/$15への引き上げは行われないとされている(2026年8月12日参照)。

出てきたものは、8語の指示に対して過剰だった。Durable Objectsのsubscriptionを使ったリアルタイム同期のマルチプレイヤーで、別のタブや別の端末から同時に遊べる。X・O・観戦の3つの役割が選べて、勝利ラインがハイライトされ、打てないマスは無効化され、New Gameでリセットできる。私が指示していない機能が大半だ。実際に遊べることは確認した。

AIが盤面を読んで、打ってきた

READMEが次に薦めているプロンプトを、そのまま実行した。「I'll be X and you be O. I've made my first move. Your turn.」

起きたことを順に書く。

まずAIが盤面を読み取った。そして、「Xが3・4・5のマスで勝っている完成状態になっていて、first moveと一致しない」と気づいた。前段で私が遊んだ勝敗が残っていたからだ。

ここが良かった。黙って辻褄を合わせず、「食い違っていたのでリセットした」と報告したうえで盤面を空にした。そこから私がXを打ち、「打った」と伝えるたびに、AIが盤面を読みに行ってOを打つ。最後まで対局が成立して、引き分けだった。AIは埋まった盤面をテキストで再現して報告してきた。

会話のログに残っている実行痕跡は Used the gadget と Ran code export default async function(self, env,...) の2つ。AIがコードを書いて、Gadget側のAPIを叩いている。

私はMCPサーバーを1行も書いていない。 8語の指示で作らせたばかりのアプリを、同じAIが読んで、書いて、操作した。「すべてのGadgetは自動でエージェント向けのAPIを持つ」というREADMEの主張は、少なくともこの1件では本当だった。Gadgetのクライアントとサーバーの通信をCap'n Web RPCに強制している設計が効いているのだと思う。サーバー側が必ず機械に理解しやすいAPIを露出することになるからだ。

自動ではない部分も書いておく。AIは私のクリックを直接観測できないので、「打った」という合図は人間側から出す必要があった。

対局を含むセッション全体のコストは$0.22、19,049トークンだった。

本番に出す段で有料になる

ここまで無料だ。器の部分はローカルで動くので、Cloudflareに1円も払っていない。払ったのはモデル代の$0.22だけだった。

自分のドメインに載せる段は別だ。スターターリポジトリが要求しているのは、Workers・KV・R2・Browser Rendering・Dynamic Worker Loaders・Cloudflare Accessの6つ。それぞれの無料枠を公式ドキュメントで確認した結果がこうなる。

詰まるのはDynamic Workersの1点だけだった。2026年3月24日にオープンベータになり、順番待ちのリストは廃止されているが、対象は有料プランの利用者に限られている。これはGadgetを隔離して実行する中核の仕組みなので、避けて通る道がない。したがって最低ラインはWorkers Paidの月$5になる。

その$5を払ったあとの従量課金は、Dynamic Workers側だけ見れば当面ほとんど発生しない見込みだ。作成1,000個/月、リクエスト1,000万件/月、CPU 3,000万ミリ秒/月までが無料枠に含まれていて、個人が試す水準では踏み抜かない。むしろ先に効いてくるのはモデル側で、私の実測でもGadget 1本$0.09、セッション$0.22だった。

ここは正直に書いておく。私はFreeアカウントで実際にデプロイして弾かれるところまでは試していない。 上の表は公式ドキュメントの記述から出した答えで、エラーがデプロイの時点で出るのか、実行時に「Worker Loaderのbindingがない」と言われるのかは分かっていない。

同じことをする人へのポイント

• Windowsで試すなら、pnpm run-local が4箇所で落ちる前提で始めるといい。原因は全部同じ(.cmd を直接起動できない)なので、1箇所直せば残りも同じ直し方で通る
• 止め方に癖がある。pnpm run-local は30個以上の子プロセスを起動していて、シェルを閉じただけでは全部生き残る。個別に止めても親が作り直すので、頂点のプロセスIDを調べて taskkill /PID <PID> /T /F のようにツリーごと落とす必要があった
• 無料で全部済ませたいならローカル実行に留める。本番デプロイはWorkers Paid(月$5)からで、これはDynamic Workersが有料プラン限定であることに起因する
• ローカルLLMでモデル代を浮かせるのは、私の環境(GPUなし・4Bモデル)では成立しなかった。試すなら、システムプロンプトだけで3,000トークン超を消費する前提でコンテキスト長を先に確認したほうがいい
• 最初に触るなら、アプリを作らせたあとで「一緒に使ってみて」と頼むところまでやると、この仕組みが何をしようとしているのかが一番早く分かる。私にとっての山場もそこだった

この記事は、運営者自身の実践記録に基づいています。