アプリを作ったら1日でGoogleの無料上限に引っかかった話 ――AIエージェントと一緒にエラーの迷宮をさまよった記録――
あの日、何度コードを直しても、同じエラーが消えなかった。
本番の4日前。前回書いた現場での緊急対応より、さらに前の出来事だ。
私はエラーの迷宮に迷い込んでいた。
開発に使ったのは、Googleの「Google Antigravity」というIDEツールだ。「こんなアプリが作りたい」「ここを直してほしい」。そんな普通の言葉をAIエージェントに伝えるだけで、コードが出来上がっていく。ただ、このエージェントにはトークンという上限があり、やり取りを重ねるとある時点で会話も作業もできなくなる。「続けるには課金しますか？」という画面が出てきて、手が止まる。そんなときはブラウザ版のGeminiを開き、「スキャンしたときに音を鳴らしたい」「複数人が同時に使ったらデータはどうなる？」と壁打ちしながら次の指示を温めておく。トークンが回復したら、固まったアイデアをエージェントに渡して実装する。その繰り返しで、少しずつアプリを育てていった。
最初は画面すら表示されなかったアプリが、バーコードで音を鳴らすようになり、複数人が同時に使えるようになった。複数人対応のために、Googleの「Firebase」というサービスを使い、データをクラウドに保存する仕組みを組み込んだ。気づけば本番運用まであと少しというところまで来ていた。あとはGoogleスプレッドシートとの連携を仕上げるだけ。そう思って作業を始めたときのことだ。
アプリを動かした瞬間、画面にこんな文字が現れた。
Firestore API Error (429: Quota exceeded)
エラーコード429。プログラミング初心者の私には意味がわからない。とりあえずスクリーンショットを撮ってエージェントに送った。「エラーが出ました」という一言を添えて。
最初の診断は「GASライブラリが重すぎるのでは？」だった。GASとはGoogleスプレッドシートを自動で操作するプログラムのことだ。なるほど、と思い指示通りにコードを全面改修した。動かしてみる。
「やはりエラーになります」
今度は別の仮説が返ってきた。「秘密鍵が古くなっているかもしれない」。確かに鍵は新しくなっていた。更新して再実行する。
「ずっとロード中です」
止まった。今度は違う症状だ。鍵を元に戻してライブラリも元に戻す。もう一度動かす。
「エラーが出ます」
同じエラーが返ってきた。この時点で私たちは、1時間以上「エラー→修正→別のエラー→また修正」を繰り返していた。
そのうちAIが言い方を変えた。「プログラムや鍵の問題ではなく、Google Cloud側で制限がかかっているかもしれない。APIの管理画面を確認してほしい」。
そこでふと不安がよぎった。
「APIを有効にすると料金がかかりませんか」
お金の話になると怖い。返ってきた答えはこうだった。「無料枠を超えるとリクエストは拒否される。まずは課金設定と上限設定を管理画面で確認しよう」。少し安心してGoogle Cloud Platformを開き、画面のスクリーンショットを貼り付ける。
返答が来た。
「犯人はこれです！1日の読み取り無料枠（5万回）を完全に使い切っています！」
画面に視線を落とす。赤いゲージが目に入った。
Free daily read：50,369 / 50,000。
並んだ数字を見ても、頭の中は「？」ばかりだった。何の数字なのかさえ、わからない。
AIが教えてくれた。Firebaseの中のデータベース「Firestore」からデータを取り出す操作を「読み取り」と呼ぶ。無料で使える読み取りの回数を、私は丸ごと使い切っているのだ、と。
そのときの私は、上限が「1日」でリセットされることすら知らなかった。完全に使い切った＝もう課金しないとアプリは動かない。目の前の赤いゲージを前にすると、さっきの説明はどこかへ吹き飛んでいた。
ではなぜ5万回に達したのか。AIがコードを調べると、原因はすぐわかった。アプリを起動するたびに、商品マスタのデータを全件取得していたのだ。商品マスタとは、商品名・バーコード・単価などが登録された商品情報の一覧のことだ。
うちの棚卸アプリには2,000件近い商品マスタが入っている。私はその日、本番に向けた動作確認のためにアプリを5回ほど開き直していた。たったそれだけで、エラーが出始めたのだ。
そして本番では現場で5台のスマホを同時に使う予定だった。棚卸し中は休憩や場所移動でアプリを何度も開き直すことになる。「1回起動ごとに全件再取得する」設計のままだと、1台あたり1日5回として、こんな計算になる：
2,000件 × 5台 × 5回 = 50,000回
本番展開すれば、一発で上限に到達する計算だった。「全件取得」という設計の一言が、5万回のデータ読み込みを引き起こす仕組みになっていたのだ。
ここで私は恐る恐る聞いた。
「質問ですが、アプリ自体は動くのですか？」
明日が棚卸の本番に近い日だった。もしアプリが止まっていたら大変だ。返ってきた答えは予想外だった。「端末内のキャッシュを優先する設計なので、読み取り制限がかかってもスキャン・保存・送信の基本動作は全く止まりません」
動く。問題なく動く。ほっとした。
原因がわかれば対策は早かった。AIの指示に従い、商品マスタのデータに「24時間キャッシュ」を導入した。キャッシュとは一度取得したデータを端末に一時保存しておく仕組みのことで、同じデータを何度もクラウドから取り直さなくて済むようになる。一度取得したデータは24時間は再取得しない。履歴データも5分間はキャッシュする。さらに、スマホ端末側での不要なマスタ同期を強制カットした。
この改修で、5万回の読み込みは劇的に減った。翌日からは上限を気にする必要がなくなった。
エラーと向き合ったあの日を振り返ると、「エラーが出た→原因がわかった→直った」ではなかった。「エラーが出た→直した→別のエラー→また直した→また別のエラー→本当の原因がわかった→直った」だった。
それでも怖くなかったのは、AIが一緒に考えてくれたからだと思う。私一人だったら、最初のエラーコードを見た時点で手が止まっていた。プログラミング初心者でも、エラーの迷宮から出てこられる。あなたがいま「自分には無理」と思っていることも、AIと一緒なら、案外できてしまうかもしれない。
次回は、この棚卸アプリが本番当日にiPhoneでカメラが起動しないという緊急事態に見舞われた話を書く予定です。
同じように試行錯誤している方、ぜひコメントで教えてください。フォローも歓迎です。
