AIを呼ぶ前に、回数と長さの上限を置く
AI機能をサービスに入れる際、今回の実装で優先したのは、利用が増えても予算の内側で動かせるようにすることだった。請求のアラートは反映が数時間遅れるため、その手前で呼び出し回数と入力・出力の長さを制限する方針を取った。
対象は、英語学習アプリの Words Admin と、資格の学習計画ツールの合格ロードマップ。どちらも Gemini API を呼ぶ機能がある。2026年10月8日から13日にかけて、それぞれに利用制限を実装し、上限に達した場合や回数を数えられない場合の動作を確かめた。
ここでいう「利用制限」は、主にサービスの中で自分たちが設けた上限を指す。Google側の上限も鍵の側の制限として使ったが、それだけに任せず、利用者ごと、サービス全体、入力の長さなど、呼び出し前に判断できる箇所で止める構成にした。
予算から決める上限と、実使用から決める上限
合格ロードマップでは、先に最悪の月額を見積もり、その内側で動かすための回数と長さを決めた。2026年10月8日の記録には、次の制限と確認方法が残っている。
| 歯止め | 値 | 確かめ方 |
|---|---|---|
| サイト全体 | 1日150回（サーバ側で強制。画面の申告は使わない。数えられなければ呼ばない＝503） | 151回目が止まるテスト |
| 1人 | 1日5回（ログイン必須・匿名は 401） | 6回目が止まるテスト |
| 実行環境 | 同時に1つ・30秒で打ち切り・出力は800トークンまで・本文500字・指示3,000字で切る | コードの定数 |
回数だけでなく、実行時間と文章の長さにも上限を置いた。サイト全体の回数はサーバ側で強制し、画面から申告された値は使わない。カウンタが読めない場合も、呼び出しを通さず停止する。
一方、Words Adminでは実使用を確認してから上限を決めた。直近7日の利用は、AI-Phraseが9回、翻訳などが18回、AI-Recallが7回。AI-Phraseの1回の実トークン数は181で、内訳は入力65、出力116だった。
この実測に加えて、入力と出力が大きい場合の月額も見積もり、利用者ごとの1日上限と、全利用者合計で1日300回の上限を置いた。実際に使われた量と、大きな入力を含む条件を分けて見たうえで、呼び出せる回数を決めた形だ。
断る条件だけでなく、枠を消費する順番も決める
Words Adminで見直したのは、上限の値だけではない。以前は回数を数え損ねた場合、上限なしで呼び出しを通す作りだった。これではデータベースが不調な日に、利用者ごとと全体の両方の上限が外れる。そのため、「数えられないときは実行しない」動作に変更した。
判定の順番も揃えた。まず利用者ごとの上限を確認し、そこを通った呼び出しだけが全体の枠を消費する。逆の順番では、自分の上限を超えた利用者の操作で、全体の枠まで消費してしまう。
入力の長さについては、抜き出し機能を8,000字まで、読解チェックを配列200件・合計600字までとした。上限を超えた入力は切り詰めずに断る。黙って文章を削ると答えが変わるためだ。件数の確認も切り詰める前に行い、長さを理由に断った回は1日の枠を消費しない。
連打への制限は60秒に3回までとし、断った回は数に入れず、残り秒数を返す。さらに、作成から24時間以内の無料口座は1日3回に制限した。通常の上限は抜き出し10回、読解チェック5回だが、作成直後は低い上限を適用する。有料口座にはこの制限を掛けず、作成時刻が分からない場合は低い方に倒した。
これらは、単に「上限超過なら断る」という処理ではない。どの条件を先に確認し、断った操作でどの枠を消費させないかまで含めて、利用制限として実装した。
上限の実装場所ではなく、呼び出し経路を確かめる
2026年10月13日、毎朝の通知を初めて送った日に、全体の上限を通らない経路が見つかった。通知の実例は次のとおりだ。
🤖 Words AI: Gemini 10回 ≒ $0.0037
・断り6回（連打2/新規口座2/長すぎ2）・全体の枠 18/300
これは初回送信時の利用と推定費用を示す記録であり、月額の保証値ではない。また、この日に「全体の枠」に含まれていない呼び出しが判明したため、表示された枠の数字だけで、すべての経路を数えられているとは判断できなかった。
全利用者合計の上限は、HTTPで呼ぶ入口にしか入っていなかった。アプリから直接呼ぶ読解チェック、単語の補強、例文の3つは全体の枠を通らず、その分は通知の集計にも入っていなかった。
修正では、3つの経路にも同じ順番で全体の上限を適用した。全体の上限で断った場合は利用者の枠を減らさず、払い戻しのなかった1か所には、断る時点で枠を戻す処理を加えた。また、別の部品を使う1か所は共通の計測箇所を通らなかったため、そこだけ直接数えるようにした。
本番では、関数からの呼び出しで全体の枠が19→20、別の部品の経路でも30→31になることを確認した。ローカルの模擬環境では上限を1に下げ、4/4で拒否され、全体と本人の枠が減らないことを確かめた。上限を大きくした対照では2/2で通った。
上限に達した状態を作るために、本番のカウンタへ300を書き込むことはしなかった。その間に来た実際の利用者まで断ることになるため、上限の値を下げる方法で試験した。利用制限の確認は、ローカルの模擬環境と本番で15/15。新規口座の制限も、口座の古さ以外を揃え、既存口座は通り、作成直後の口座は断られることを確認した。
合格ロードマップでは別の判断も行った。前払い未購入で、残高が0のため呼び出しが402で止まることを確認していた。10月12日時点では、画面からAIの欄を外して「準備中」と表示した。上限の仕組みは残し、前払い後にその内側で動かせる状態にした。
業務に置き換えると
社内チャットや問い合わせの一次返信にAIを入れる場合も、今回の記録から点検できるのは次の項目だ。
- 最悪の月額を先に計算し、その内側に収まる回数を、1人・全体・鍵の側で制限しているか。
- 回数を数えられないときに停止するか。また、断った操作で利用枠を減らしていないか。
- AIを呼ぶ経路をすべて挙げ、それぞれが上限の判定と集計を通ることを確かめたか。
- 毎日の回数と費用を確認できるか。取得できなかった日は0とせず、取得不可と理由を示しているか。
今回、上限の処理が存在することと、すべての呼び出しがその処理を通ることは別だった。制限を設けた後は、経路ごとに呼び出し、枠の増減と拒否時の動作まで確かめる。その確認が、設定した上限を実際の運用で働かせるために必要だった。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。