「Cloudflare Workersなら、月5ドルくらいで運用できそう」。そう考えてCodexでサービスを作っていたら、Cloudflareから予想外の利用額通知が届きました。
メールを見て驚いたのは、金額以上に「自分のサービスが、どこでそんなに使っているのか分からない」ことでした。調べてみると、あるサービスに生成AIを呼ぶ処理と、それを定期的に実行する設定が入っていました。正直な実感は、「勝手にAI利用設定が入っていた」です。ここでは、今回作られたサービスの実装についての話として、確認できた事実を整理します。
今回は、ITtripで運用するサービスを調べて分かった仕組みと、公開前に確認すべきだったことを書きます。
通知に表示されていたのは20.44ドル
2026年10月25日17時45分ごろ、日本時間で届いたCloudflareのメールには「Current total: $20.44」と表示されていました。対象の請求期間は2026年10月13日から11月13日です。
これは、その通知時点の表示額です。確定請求額ではなく、メールにも最終的な従量料金は請求期間の終了後に確定すること、利用データの反映に遅れがあることが書かれていました。「AIだけで20.44ドルの請求が確定した」という意味にはできません。
当時、公開カタログには49個のサービスがありました。最初は「どれかにアクセスが集中したのか」「ボットに大量に使われているのか」と考えました。そこで、サービス名と実際のWorkerを対応づけ、接続している機能や定期実行の設定を確認しました。
月5ドルは、アカウント全体の利用額を止める上限ではなかった
ここで、自分の認識を整理する必要がありました。
2026年10月26日に確認した公式料金表では、Workers Paidはアカウントあたり月額最低5米ドルです。月1,000万リクエスト、CPU時間3,000万ミリ秒などの利用枠が含まれますが、5ドルに達したらすべての処理が止まる契約ではありません。含まれる枠を超える利用などは追加料金の対象です。
さらに、Workers AIには別の利用枠と課金があります。1日10,000 Neuronsの無料枠があり、Workers Paidでその枠を超えた分は1,000 Neuronsあたり0.011米ドルです。NeuronsはAIの計算量を表す単位で、使うモデルや入出力によって消費量が変わります。以上は税別の米ドル表示で、料金や条件は変更される可能性があります。
「アプリを動かす費用」と「アプリが呼び出すAIの費用」を、同じ5ドルの箱に入れて考えていたのが誤りでした。
脆弱性ナビには「生成して、別のAI呼び出しで検証する」処理があった
調査で確認したのが、脆弱性の情報を扱う「脆弱性ナビ」です。当時の本番設定にはWorkers AIを使う接続設定があり、本番コードには公式資料をもとに日本語の解説を生成する処理がありました。
大まかな流れは、次のとおりです。
- 公式資料などの情報を取り込む
- AIに日本語の解説を生成させる
- 出力の形式や根拠をプログラムで検査する
- 別のAI呼び出しで、資料との対応や説明の内容を検証する
- 条件を満たさなければ再試行する
- 通過した結果を保存して表示に使う
生成と検証の既定モデルには、Workers AIの「@cf/openai/gpt-oss-120b」が指定されていました。同じモデルでも、生成と検証は別の呼び出しです。1件の解説を作るのにAIを1回だけ使うとは限らず、再試行が加われば回数は増えます。
これを動かす定期処理は5分間隔で、1回に処理する上限は40件でした。5分おきなら、実行機会は1日に288回あります。毎回必ずAIを呼ぶ、あるいは毎回すべての情報を生成し直すという意味ではありません。それでも、対象データが残っていれば、訪問者が操作しなくても処理が進む構成です。
さらに一部のデータでは、資料の「取得日時」だけが変わっても、保存済みの生成結果を再利用するための識別値が変わることを再現できました。内容の変更と取得し直した日時を区別できないと、不要な再処理につながります。ただし、これが通知額の何ドル分を占めたかまでは確定していません。
この調査で、外部からの攻撃が一切なかったとまで確認できたわけではありません。ただ、閲覧用のHTTP処理からAI生成を始める経路は見つからず、サービス内部の生成・検証・定期実行だけでも利用量が積み上がる構造でした。初期の一括生成や試験もあり、利用額のすべてを定期処理だけに割り当てることもできません。
「知らないうちにAIを使っていた」の中身
自分の感覚としては、「いつの間にかAIを使う設定になっていた」という出来事です。実際に確認できたのは、Codexで構築したサービスのコードとデプロイ設定に、AI呼び出しと定期実行が含まれ、それが本番で動く状態になっていたことでした。
今回の利用は、その公開サービスからCloudflare Workers AIを呼び出す仕組みによるものです。Codexを使えば必ず同じ設定になる、Codexの利用料金として追加請求された、という話ではありません。
公開前に「動くか」「説明は正確か」を確かめるだけでは足りませんでした。AIを使う機能を入れること、その機能が公開後も料金を発生させ続けること、上限をどう決めるかまで、明確な確認事項にする必要がありました。出力の品質を高めるための検証処理にも費用がかかります。
今回はAIの新規生成を止め、利用上限も入れた
まず、脆弱性ナビの新しいAI生成・検証を停止し、Workers側のAI接続設定とAI用の定期実行を外しました。公開は静的なデータを配信する構成へ変更しました。過去に生成済みの説明が残る場合はありますが、それを表示することと、新しくAIを実行することは分けて確認しています。
あわせて、回線測定を行う「くもダッシュ」と「渋滞メーター」にも、サービス全体の1日あたりの回数、同じ接続元からの開始回数、1回の測定で使える通信量などの制限を設けました。普通に使う人のために測定を残しつつ、繰り返し大量に使われた場合にはサーバー側で止めるためです。
これで月額5ドルが保証されたわけではありません。拒否したリクエストの処理や、ほかのサービスの利用もあるため、通知と実際の利用量の確認は引き続き必要です。
AIに開発を頼むとき、公開前に確認したいこと
次からは、機能を作る依頼と一緒に、次の条件も伝えるつもりです。
- 外部の生成AIや従量課金の機能を追加する前に、用途と料金を確認する
- 誰もアクセスしていない時間に動く処理と、その実行間隔を一覧にする
- 1回の操作でAIを何回呼ぶか、検証や再試行も含めて数える
- 月額の希望予算を、回数や通信量などの実際に止められる上限へ落とし込む
- 請求通知だけでなく、上限到達時に停止する処理を用意する
- 公開後、短い期間でサービスごとの利用量を確認する
Codexでサービスを作ると、公開まで進む速さには驚かされます。今回もう一つ学んだのは、公開されたコードは、その後も自分のアカウントで動き続けるということでした。「何ができるようになったか」に加えて、「何が、どれくらいの頻度で、いくら使って動くのか」まで確かめる。次の公開では、そこを外さないようにします。
コメント