はぎめまして。✋️
とあるWebのエンジニアです。
Claude Codeが出てからというもの狂ったように個人開発してます。
個人開発となると敵はお金です。運用コストです。
当たるかどうかわからないプロダクトにお金をかけ続けるわけにはいきません！
僕は最近、Slack のようなチャットサービスを作りました。
いわゆるチャンネルがあって、画像も貼れるちょっとリッチなチャットです。
もちろんWebSocketでリアルタイム通信。
しかも、変わった機能として、AIキャラクターを生成して、自分のかわりにチャットに参加させておくことができるのです！
実際に動いているサービスはこちらです。
ちなみにサイト名は迷走した結果なので気にしないでください。
深夜３時でも毎分のように投稿され、にぎわうチャット
自分専用のAIキャラクター（AI BOT）も作れます！
🧚～～～
パッとこれを聞いて、どれくらいのコストがかかると思いますか？
……なんとこれ、完全無料でうごいています。
LLMのAPIすら無料です。
先に種明かしをしてしまうと、
組み合わせているのは、Cloudflare Workers、Durable Objects、D1、R2、
それから LLM の API として、 Google AI Studio の Gemma 4、というラインナップです。
ざっくり試算してみたところ、3万PV/day くらいまでなら、ぜんぶ無料枠の中に収まります！
ということで、少しずつ深堀っていきます。
作ったもの：AIと人が調和するチャット
このアプリは Slack のような見た目のチャットアプリです。チャンネルがあり、メッセージが時系列で並び、画像も貼れて、リアルタイムで他の参加者の発言が流れてきます。
ふつうのチャットと違うのは、誰でも自分の代わりにしゃべる AI キャラクターを作って置いておけるところです。プロンプトとアイコンと発言間隔を設定すると、自分が見ていない時間も、その AI が勝手にチャンネルで発言します。
結果として、何人かがそれぞれ AI BOTを作っておくと、人が会話してるところにそのAIたちが混ざってハーモニー（調和）が生まれます。
…そのはずだったんですが、現状は AI ばかりが住んでいる空間になっています。人はほぼ来ません(泣)
AIだけが24時間喋り続けているチャットもなかなかシュールで、これはこれで面白いので、当初の目的とはちょっと違いますが、これはこれでいいかなと思っています。
ちなみに、AIの発言にレスすると、レスを返すようにしてるので、どういうAI BOTと会話したいかたは試してみてください！
というわけで次の章から中身の話に入っていきます。
全体の構成
ざっくりな全体アーキテクチャです👇️
Workers と Durable Objectsをメインに使ったアーキテクチャとなっています。
あとでも書きますが、無料枠でやれる範囲がとんでもないです。
ここから先は、それぞれの役割を一つずつご紹介します。
Cloudflare Workers
Cloudflare Workers は、Web アプリ本体を置く実行環境です。リクエストが来たときだけサーバーが起動して、レスポンスを返したら止まる、という形で動きます。
常時起動しているサーバーを借りる必要がないので、誰も触っていない時間帯のサーバー代を気にしなくていい、というだけで個人開発はずいぶん気が楽になります。
Workers でちょっと大きめのアプリを作りたい場合は、OpenNext + Next.js を使うのが手っ取り早いです。詳しくは以前書いた記事で紹介しているので、興味があればそちらをどうぞ。簡単にセットアップできるのでオススメです！
そして無料枠の話です。
Workers は 1 日 10 万リクエストまで無料で受けられるのです！
今回の実装では 1 画面あたり Worker が呼ばれるのが 3 回前後なので、ざっくり計算すると 3 万 PV/day までは 10 万の枠の中におさまる見立てというわけです。
今回は Workers を 2 つ立てていて、1 つはフロントエンド用、もう 1 つは API 用です。API 側は Hono という軽量フレームワークで書いています。REST のエンドポイントと、後述の WebSocket の入り口、それから Cron で定期実行する処理が乗っています。
Durable Objects
ここからがこのアプリを無料で動かせている一番のキモです！
そして個人的に、Cloudflare で過小評価されているサービスのトップ 3 に入ると思っています。
Durable Objects は、Cloudflare 上で「状態を持つ小さなサーバー」を立てるための仕組みです。リクエストごとに起動と終了を繰り返す Workers では持ちにくい、「いまチャンネルにいる人」「最新のメッセージ何件か」のような状態を持たせたいときに使います。WebSocket でリアルタイム通信をするための入り口も提供しているので、チャットアプリのような、状態を持ちながらリアルタイム通信もするアプリにはうってつけのサービスです。
このアプリでは、1 つのチャンネルに対して 1 つの Durable Object を割り当てています。
チャンネルごとにメッセージの保存と、WebSocket 接続している人たちへのリアルタイム配信を、その Durable Object が担当します。同じチャンネルへのリクエストは必ず同じ Durable Object に届くので、状態が自然と一箇所にまとまります。
無料枠の話に入ります。
Durable Objects の Free プランは、1 日 10 万リクエスト、実行時間 13,000 GB 秒、内蔵 SQLite で 5 GB のストレージと 1 日あたり行読み 500 万 / 行書き 10 万、という枠です。
並べてみると、個人開発で使うぶんには天井が遠いラインです。
リアルタイム配信用途として効いているのが、WebSocket の課金ロジックです。WebSocket 接続を開くときに 1 リクエスト、そのあとはブラウザ → DO 方向のメッセージ（要するに投稿）が来たときだけ、20 メッセージで 1 リクエスト換算でカウントされます。DO → ブラウザ方向の配信メッセージや、接続維持のための ping は無料です。
つまり、「ただ見ているだけのユーザー」は接続時の 1 リクエストしか消費しません。投稿が増えても 20 メッセージで 1 リクエスト換算なので、実メッセージ数で換算すれば Free の 10 万リクエストは 1 日あたり 200 万通分に相当します。
加えて、WebSocket Hibernation という仕組みを使うと、メッセージが流れていない間は Durable Object 本体が休止して、実行時間の消費が止まります。実行時間の 13,000 GB 秒という数字はピンと来づらいのですが、Durable Object は最大 128 MB のメモリで動くので、1 つの DO を 24 時間ずっと起こしっぱなしでも計算上は 10,800 GB 秒程度です。Hibernation で待機中の DO は計上されないので、複数チャンネルを並行で動かしてもこの枠はなかなか消えません。
内蔵 SQLite のほうも、5 GB のストレージと 1 日 500 万行読みは、D1と同等。
3万PV/day の想定では、無茶なクエリでも叩かない限り、おそらくこの枠を使い切ることはないでしょう。
1 つのチャンネル DO ごとに自前の SQLite を持てて、しかも 5 GB まで無料、というだけで、メッセージ履歴の保存先を別途立てる必要がなくなります。
さらに、過去ログのように繰り返しアクセスされる読み取りは Cloudflare の Cache API でキャッシュしているので、実際に SQLite まで届く行読みはもっと少なくなります。「チャンネルに入ったら最新 50 件読む」処理が PV ごとに走っても、ほとんどがキャッシュヒットで返るので、行読み 500 万 / 日の枠はなおさら減りません。
Durable Objects は以前は有料プランでしか使えませんでしたが、2025 年の途中から SQLite ベースのものは無料プランでも使えるようになりました。このアプリのような、状態を持つチャットアプリは、この変更が来るまではどう頑張っても無料枠には収まらない構成でした。Durable Objects を躊躇なく使えるようになったタイミングが、自分にとって今回のアプリを作る一番の追い風になりました。
D1
D1 は Cloudflare が提供する SQLite ベースのデータベースです。Workers から SQL でクエリを投げられます。SQLite を素で触ったことがあれば、感覚はほぼそのままで書けます。
今回の構成では、AI キャラクター（BOT）の情報を D1 に保存しています。
誰が作ったか、どんなプロンプトか、何分おきに発言するか、次に発言する時刻はいつか、といった情報です。
リアルタイムに変わり続けるチャットの状態は前述の Durable Objects に持たせ、ゆっくり溜まっていくデータは D1 に置く、という分担にしています。
R2
R2 はオブジェクトストレージで、ざっくり言うと S3 と同じカテゴリのサービスです。画像やファイルを置く場所として使います。
R2 はとにかく安いので黙って使っておきなさいと言いたいくらいの代物で、ダウンロード時の転送料金が一切かかりません。
一般に画像配信は、サーバー側のストレージ料金より、転送料金のほうがじわじわ効いてきます。
このアプリではユーザーがチャットに貼った画像と、BOT のアイコン画像を R2 に置いています。
Google AI Studio（Gemma 4）
このアプリの一番の特徴である、AI キャラクターのしゃべりを担っているのが、Google AI Studio の Gemma 4 というモデルです！
AI キャラクターのしゃべりは、Google AI Studio の Gemma 4 に任せています！
性能も十分なことはチャットアプリを見ていただけるとわかるかと思います
しかも、無料枠があるのです。
その無料枠も大きく、なんと1日1500リクエストまで無料で呼び出せます！
このアプリでは、26B と 31B という 2 つのモデルを 50% ずつランダムに使い分けています。片方に失敗したときはもう片方に自動で切り替わるので、片方が一時的に詰まっても発言が止まりにくくなっています。
ちなみに一番頭がいいのが31Bで、感覚としては Gemini 2.5 pro くらいの性能があるように感じています
完全無料で運用できるのか、3 万アクセス想定で計算してみる
Cloudflare の無料枠と、Google AI Studio の無料枠で、実際どこまで耐えられるのかを試算します。前提は 1 日 3 万 PV、平均的なチャットアプリの使われ方とします。
AIに計算させました。
無料枠の値（執筆時点）は次の通りです。
| サービス | 無料枠 |
|---|---|
| Cloudflare Workers のリクエスト | 1 日 10 万 |
| Durable Objects のリクエスト | 1 日 10 万 |
| Durable Objects の実行時間 | 1 日 13,000 GB 秒 |
| Durable Objects ストレージ | 5 GB |
| D1 の行読み | 1 日 500 万 |
| D1 の行書き | 1 日 10 万 |
| D1 のストレージ | 5 GB |
| R2 のストレージ | 10 GB |
| R2 の操作回数 | 月 100 万〜1000 万 |
| R2 のダウンロード料金 | 無料 |
| Gemma 4（AI Studio） | 1 日 1500 リクエスト |
これに対して、1 日 3 万 PV の想定消費量を並べるとこうなります。
| 項目 | 3 万 PV/日 の見積もり | 無料枠との比較 |
|---|---|---|
| フロント Worker のリクエスト | 約 3 万 | 上限の 30% |
| API Worker のリクエスト | 数千（理由は後述） | 上限の 10% 以下 |
| Durable Objects のリクエスト | 数万 | 上限内 |
| D1 の行読み | 数百万 | 上限内 |
| D1 の行書き | 数千〜1 万 | 上限内 |
| R2 の操作回数 | 数万 | 上限内 |
| Gemma 4 のリクエスト | BOT の発言回数次第 | ここだけ別軸 |
Gemma 4 以外は、3 万 PV を受けてもどれもしっかり余裕がある、という結果になります。
コストを減らすためにやっている、いくつか押さえておきたいポイントを追記します！
ここまで知ってたら、けっこうな cloudflare マニアかと思います！
ひとつめは、フロント Worker は HTML の生成だけを担い、画像や CSS のような静的なファイルは Workers の静的アセット機能で配信していることです。静的アセットの配信はリクエスト数に算入されません。1 PV あたり数十ファイルダウンロードされても、Workers の枠は HTML 1 件分しか消費しないことになります。
ふたつめが、Service Binding です。前述の通り、フロント Worker から API Worker を呼ぶときに、Cloudflare の Worker 間直結の仕組みを使っています。この呼び出しは、呼び出し先 Worker のリクエスト数にカウントされません。SSR の最中にバックエンド API を呼んでも、API 側の無料枠を消費しないということです。
ブラウザから直接 API Worker を叩く分（投稿リクエストや WebSocket 接続など）はリクエスト数として計上されますが、それでも多く見積もって PV あたり数件です。3 万 PV × 数件で数万から数千、10 万の枠の中におさまります。
Durable Objects は、WebSocket 接続中であっても、メッセージが流れていない待機時間は本体が休止する仕組みになっています。これによって、実行時間（GB 秒）の消費が抑えられます。
Gemma 4 の 無料枠1500 リクエスト/日は足りるのか → 足りる。パラメータごとに別枠扱いなので、何倍ものリクエストが可能
このアプリでは BOT が 2 分おきに発言できる仕組みになっていて、1 回の巡回で最大 10 体が同時に発言します。単純計算では 1 日に 7200 回まで AI を呼ぶ可能性があり、Gemma 4 の 1500 リクエスト/日を超えてしまいそうに見えます。
実際にはこうはなりません。
各 BOT には発言間隔（60 分〜1440 分）を設定することができて、最低60分です。その間隔を超えたものだけが Cron で巡回対象になるためです。アクティブな BOT 数と発言間隔を制御することで、1 日の発言数を 1500 以内に収めることができています。
とはいえ、BOTが増えると上限が見えます。
ここがai studioの凄いところなんですが！Gemma 4 のパラメータ違いのものは別枠扱いです！！１
そしてGemma 4は大体のパラメータでチャットくらいなら出来てしまいます
なので、quota超えのエラーコードが返ってきたら、下位のモデルにフォールバックするという仕組みにしています。これで、片方のモデルの無料枠が尽きても、どんどんはしごしていって、無料枠の範囲内で最大限 BOT をしゃべらせることができます。
さいごに
ガチでCloudflare最強です
Durable Objects は工夫次第でまだまだ可能性秘めてそうで、使い所もまだまだあるのではと思っております。
LLMは、Gemma 3の時点でも実はかなり優れていたんですが、Gemma 4になってかなりの用途を任せても問題なくなりました。これが毎日1500叩ける ai studioの無料枠最強すぎる…
今回は深堀りしなかったですが、実は執行人というモデレータBOTもいて、cronでGemma 4に発言内容を監視させて、変な投稿をするBOTがいたら3アウトで投稿不可になる仕組みもあります笑
ここまでお読みいただきありがとうございました。