AIで爆速開発した後、本当に怖いのは「完成した気になること」
AIにコードを書かせると、アプリはびっくりするほど早く形になる。
昨日まで「こんなゲームあったら面白くない？」だったものが、翌日には部屋を作れて、参加できて、投稿できて、投票までできる。ここで脳が言う。
できた。
サーバー「まだです。」
本当に怖いのは、通常操作が一回通るかではない。100人が同時に開いたらどうなるか。保存は成功したのに返事だけ消えたらどうなるか。締切と最後の投票が同時だったらどうなるか。決済通知が二回来たらどうなるか。障害から戻った瞬間に全員が再接続したらどうなるか。
ある小規模な多人数Webアプリをコードレビューしたところ、確認項目は324件まで増えた。ただし、これは「324個バグが見つかった」という意味ではない。324個とも、まだ実行していない試験項目だった。
ここが大事である。
設計図が立派でも、橋にまだトラックを走らせていないなら、耐荷重試験は0回だ。
1. DDoSだけ警戒しても足りない
DDoSというと、ものすごい台数から一気にアクセスされる絵を想像しやすい。
もちろん対策は必要だ。Cloudflareは全プランでDDoSの自動検知・緩和を提供している。一方、Cloudflare自身も、大きなDDoSを自動で緩和できてもアプリへの影響が残る場合があり、レート制限など追加の防御を勧めている。[1]
しかも個人開発で先に困るのは、悪意のある巨大攻撃とは限らない。
普通の利用者が普通に遊んだだけで、裏側の処理量が想像以上になる。
たとえば画面が3秒ごとに状態を確認するとする。単純計算ではこうなる。
| 同時端末 | 1時間の状態確認 |
|---|---|
| 10台 | 12,000回 |
| 30台 | 36,000回 |
| 100台 | 120,000回 |
| 1,000台 | 1,200,000回 |
これは実際の収容人数を示す数字ではない。待ち時間を伸ばす処理やキャッシュがあれば減るし、逆に投稿、画像、受信箱、複数タブ、定期処理が加われば増える。
しかし「100人しかいないから余裕でしょ」が危険なのは分かる。
Cloudflare Workers Freeは2026年10月5日時点で1日100,000リクエストが目安で、D1 Freeは1日500万行の読み取り、10万行の書き込み、1DB 500MB、1回のWorker呼び出しで50クエリという制限がある。[2][3]
さらにD1は1つのデータベース内ではクエリを1つずつ処理する。混雑すると待ち行列に入り、詰まり切ればoverloadedエラーになる。[3]
つまり敵は「100万人の攻撃者」だけではない。
100人の友達が全員ちゃんと遊んでくれることも、構成によっては負荷試験になる。
2. 324項目に増えた理由
チェック対象を「ボタンを押して動くか」だけにすると、だいたい平和である。
問題は、現実の利用者がボタンを一回だけ丁寧に押してくれるとは限らないことだ。
今回の確認項目は次の16分類に広がった。
| 分類 | 件数 |
|---|---|
| 入口・迷惑アクセス | 22 |
| 混雑・利用枠・容量 | 20 |
| 同時操作・途中停止・復旧 | 20 |
| 定期処理・通知・削除 | 24 |
| 作成・参加・本人・権限 | 22 |
| 写真・無料画像・共有 | 23 |
| 回答・割当・文字入力 | 18 |
| 投票・集計・結果 | 23 |
| 開始・締切・時刻 | 20 |
| 結果解放・休み・補充回答 | 16 |
| 公開ルームの人数・進行 | 24 |
| 公開ルームの常時接続 | 20 |
| 画面・端末・通信復帰 | 22 |
| アイコン・外部連携 | 12 |
| 課金・復元・広告なし | 22 |
| 公開・監視・修正後の再確認 | 16 |
| 合計 | 324 |
これだけ見ると「終わるの？」となる。
終わらせ方はある。全部を同じ重さで扱わない。
3. 公開前に先に殴る23項目
優先したいのは、見た目の小さな崩れより、データ・課金・権限・進行停止・利用枠に関わるところだ。
- 拒否するアクセスでも重いDB処理まで到達していないか。
- 自前の利用量カウンターが、本当の全アクセスを数えているか。
- 連打制限が1台のサーバー内だけの一時記録になっていないか。
- 数秒ごとの状態確認が、変更なしでもDBを大量に読んでいないか。
- 常時接続で、同じ席から何本でも接続できないか。
- HTTPと常時接続で、通報・投稿などの回数制限が同じか。
- 運営が停止した後、すでにつながっている端末も止まるか。
- 締切を過ぎた投稿や投票が、定期処理の遅れで通らないか。
- 一部の保存に失敗したのに、部屋だけ先へ進まないか。
- 修復処理を二回走らせて、統計だけ二重加算されないか。
- 開始予約だけ記録され、ゲーム本体を作る前に止まった場合に戻せるか。
- 保存成功後に通信だけ切れ、再送したとき同じ回答が二本にならないか。
- 全角・半角・空白違いなどで表示名の重複が起きないか。
- 「残り1枠」に複数人が同時参加して上限を超えないか。
- 定期処理に仕事を詰め込みすぎて、毎回途中で終わらないか。
- 画像以外のDBデータや索引も含め、容量を見ているか。
- 端末を失った人の席を、別人が横取りできないか。
- 画像の形式、画素数、位置情報などを安全に扱えているか。
- 過去結果をたくさん持つ人ほど、表示のための読み取りが爆増しないか。
- 障害復旧直後に全端末が一斉再接続して、もう一度障害にならないか。
- 課金は重複通知、遅延、解約、復元まで別系統で試したか。
- ローカルのテスト合格を、本番環境の合格と勘違いしていないか。
- DB自体が落ちたとき、異常を知らせる仕組みまで一緒に死なないか。
これを読むだけで「普通に遊べたので公開します」が急に怖くなる。
だが、それでいい。
怖くなった場所が、そのまま試す場所になる。
4. バグは単発より「組み合わせ」で出る
一番価値が高いのは、嫌な条件を重ねる試験だ。
たとえば、
100人が同時に投票する
→20人が更新ボタンを押す
→10人の通信が切れる
→何人かは保存成功の返事を受け取れず再送する。
ここで確認する。
投票数は増えすぎないか。締切後の票は混ざらないか。画面は古い状態へ巻き戻らないか。DBに保存されたのに「失敗」と見えた操作を、もう一度実行して二重にならないか。
単体テストでは全部通るのに、本番だけ壊れる原因はこういうところにいる。
OWASPも、同時セッションや異常入力、エラー処理を別々の確認対象として扱っている。[4]
5. 「保存できた」と「返事が届いた」は別事件
ネットワーク障害で地味に怖いのがこれだ。
サーバー側では保存成功。
でもスマホへの返事だけ消える。
利用者から見れば失敗に見えるので、もう一度押す。
サーバー「了解、2件目ですね！」
違う。
同じ操作を再送しても一回分として扱えるように、操作を識別する仕組みが必要になる。
これは回答だけではない。
部屋作成、投票、結果確定、通知、課金。お金か順位が絡むところで二重実行は笑えない。
6. 負荷試験は段階的にやる
いきなり本番へ1,000台相当を投げる必要はないし、やるべきでもない。
管理下の検証環境で、
10 → 30 → 100
と増やす。
さらに「100人」を一種類にしない。
- 100人が同じ部屋に集中
- 100人が多数の部屋に分散
- 全員が同時に参加
- 全員が同時に投票
- 一度切断して全員同時復帰
- 定期処理の時刻と重ねる
- 保存先を途中で一時失敗させる
ここまでやると、「人数に耐えた」の中身がかなり濃くなる。
他人のサービスや許可のない本番環境へ大量通信を送るのは負荷試験ではない。管理下の環境、承認した上限、止める条件を先に決める。
7. 合格条件は「落ちなかった」だけでは足りない
仮の目安なら、通常処理の95%が1秒以内、99%が3秒以内、意図しない500番台エラー0.1%未満、といった性能条件を置ける。
ただし、もっと厳しく0件で見るものがある。
- 他人のデータが見える
- 権限のない操作が通る
- 結果が二重集計される
- 保存済みデータが消える
- 二重課金される
ここは「1,000回に1回なら優秀！」ではない。
1回でも出たら止めて原因を見る。
8. 試験設計9点、実施0点という状態は普通にある
324項目も作り、優先23点も選び、負荷シナリオも組んだ。
かなりちゃんとしている。
ただし、その時点ではまだ試験計画がちゃんとしているだけだ。
点数で言えば、
- 試験設計：8.5〜9/10
- 実施結果：0/10
である。
厳しいようだが、悪い意味ではない。
「何を試せばいいか分からない」状態から、「ここを壊しに行けばいい」状態まで進んでいる。
あとは殴るだけだ。もちろん自分の検証環境を。
9. そして別のものが先にパンクした。AIの週間枠である
ここから話が急に人間側へ戻る。
AIでアプリを爆速開発し、コードを読み、修正し、また読み、長いエージェント作業を一日中回す。
するとサーバーより先に、
AIの利用枠が死ぬ。
Claude Max 20xは2026年10月5日時点でWeb契約なら月200ドル。Proの20倍という表現は「セッションごとの使用量」で、セッション枠は5時間ごとにリセットされる。一方で、全モデル共通の週間上限もある。[5]
つまり、
「20xを買った。これでもう無限だ！」
ではない。
「5時間枠はかなり大きい。でも週は週である。」
旅行中に一日ずっと大きなコードベースを読ませ、実装、修正、レビューを繰り返すような使い方なら、週間枠の大きな部分を短期間で使うことは仕組み上あり得る。正確な減り方はタスク、モデル、文脈量などで変わるので、Settings > Usageで見るのが一番確実だ。[5]
10. 「Fable高いわ」は、数字を見てもだいたい合っている
MaxではFable 5と5.1も標準対象だが、Fableに使えるのは週間上限の最大50%までで、AnthropicはFableが他モデルより速く週間枠を使うと案内している。[6]
従量課金の価格を見るとさらに分かりやすい。
| モデル | 入力100万トークン | 出力100万トークン |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Fable 5.1はOpus 5.5の2.5倍の入力・出力単価だ。Fable 5.1はキャッシュ読み取りが$0.25/100万トークンまで下がり、旧Fable 5より典型的な仕事で約25%、長いエージェント作業で最大約45%安くなったとAnthropicは説明している。それでも絶対額は高い。[6][7][8]
なお、このAPI単価をそのままMaxの週間枠へ換算できるわけではない。サブスクの内部的な使用量計算とAPI請求は別物だ。
でも「重いモデルを長時間回すと枠が溶ける」という方向は同じである。
11. AI開発は「全部最強モデル」が一番ぜいたく
実用上は仕事を分けた方がいい。
Sonnet 5.5
- 小さな修正
- よく分かっているバグ
- 繰り返し作業
- 文章や画面の整形
- 明確な指示どおりの実装
Opus 5.5
- 原因不明のバグ
- 大きな設計変更
- 複数ファイルをまたぐレビュー
- 仕様の矛盾探し
- 公開前の重要判断
Fable 5.1
- さらに重い仕事で、追加コストや週間枠消費を受け入れてでも能力差を取りに行く場面
これは「モデルの格付け」ではなく、1タスク当たりの費用と失敗コストを合わせる考え方だ。
100円のネジを締めるために毎回クレーン車を呼ぶ必要はない。
クレーン車はすごい。
でもネジはちょっと引いている。
12. AIで開発速度が上がると、ボトルネックが移動する
以前なら、
アイデア
→実装に数週間
→やっと試験
だった。
AI開発では、
アイデア
→実装が一気に進む
→試験、運用、サーバー枠、AI利用枠が一斉に追いついてくる
という形になる。
だから「AIで一日でアプリができた」は半分正しい。
正確には、
一日で“壊して確認できるところ”まで来た。
ここからが本番だ。
アプリの完成度を上げる最後の仕事は、もっとコードを書くことではないかもしれない。
同時に押す。途中で切る。もう一回送る。締切をまたぐ。保存先を止める。復旧直後に集中させる。課金通知を重複させる。
そして全部戻ってきたら、ようやく少し安心できる。
そのころ開発者のAI週間枠は、先に成仏しているかもしれない。
参考資料（9件）
- Cloudflare DDoS Protection / Proactive defense: / https://developers.cloudflare.com/ddos-protection/best-practices/proactive-defense/ developers.cloudflare.com
- Cloudflare Workers Limits / Pricing, 2026-10-05参照: / https://developers.cloudflare.com/workers/platform/pricing/ developers.cloudflare.com
- Cloudflare D1 Limits / Pricing, 2026-10-05参照: / https://developers.cloudflare.com/d1/platform/pricing/ developers.cloudflare.com
- OWASP Web Security Testing Guide wstg.owasp.org
- Anthropic, Max plan support.claude.com
- Anthropic, Claude Fable models on your plan support.claude.com
- Anthropic, Claude Opus 5.5 anthropic.com
- Anthropic, Claude Sonnet 5.5 anthropic.com
- Cloudflare Workers Rate Limiting API developers.cloudflare.com
