個人開発者がAI APIを安全に運用するための多層防御設計の原則
本記事は、個人開発者が画像からシリアルナンバーを読み取るWebツール「シリトル」を公開するにあたり、従量課金型の外部API（Google Gemini OCR）を利用する際のコスト暴走リスクを防ぐための「多層防御」設計について詳細に解説している。筆者は、悪意ある大量リクエストや不正利用による予期せぬ高額請求から個人開発のサービスを守ることを最優先課題としている。
この防御システムは、単一の対策ではなく、性質の異なる複数の防御層を重ねることで構築されている。具体的な防御層は以下の通りである：
1. **認証（層0）**: ログイン必須化により、匿名での無制限利用という最も安易な濫用を防ぐ土台とする。
2. **レートリミット（層1）**: Upstashを使用し、ユーザーID単位で「直近N秒間」の集中リクエストを制限する。IPアドレスによる制限時には、偽装対策として信頼性の高い`x-real-ip`ヘッダを利用している点を指摘。
3. **ユーザー単位の日次上限（層2）**: 1ユーザーあたりの日次利用回数に「濫用ライン」を設定する。この上限は正規利用を縛るものではなく、全試行（成功・失敗問わず）をカウントすることで、抜け道を塞ぐ設計が特徴である。
4. **全体の日次予算ガード（層3）**: 全ユーザー合計のOCR回数にサービス全体の天井を設け、大規模な攻撃や非常事態における「最終防波堤」とする。これは正規利用には到達しない水準に設定されている。
5. **濫用検知（層4）**: 上記すべての防御をすり抜ける異常な使い方を、課金データとは独立した統計テーブルで事後的に監視し、管理者へ通知する仕組みである。
さらに設計の核心として、「fail-open」と「fail-closed」という振る舞いの使い分けが述べられている。守りの層（レートリミットなど）は障害時にサービス停止を避けるため`fail-open`を採用し、課金整合性に関わる処理のみ`fail-closed`とすることで、不正な利用の可能性を排除している。最後に、防御判定を重いOCR呼び出しの前に行う「順序の工夫」や、自前のコード防御に加えGoogle側のプラットフォーム支出上限（スペンドキャップ）という外部の最終砦を設けるなど、多角的な安全設計が徹底されている。
背景
個人開発者がAIなどの従量課金APIを利用する際、予期せぬコスト暴走は最大の経営リスクとなる。特に資金力の限られる個人にとって、悪意ある大量リクエストによる請求超過は致命的であるため、技術的な防御設計が極めて重要になる。
重要用語解説
- 多層防御: 単一の対策に頼らず、性質の異なる複数の防御策を重ねること。一つの防御層が破られても、次の層が機能することでシステム全体の安全性を高める考え方。
- レートリミット: 一定時間内に許容されるリクエスト回数を制限する仕組み。短時間の集中攻撃や過剰な利用を防ぎ、サービスの安定稼働を維持する目的がある。
- fail-open/fail-closed: システムの障害発生時の振る舞いの設計原則。「fail-open」は判定不能時にサービスを継続させる（通す）こと、「fail-closed」は判定不能時にサービスを停止させる（止める）ことを指す。
今後の影響
本記事で示された多層防御の考え方は、AIや外部APIを利用する全ての個人・小規模開発者にとって必須の知見となる。単なる機能実装に留まらず、「いかに安全に運用し続けるか」という視点が加わることで、サービスの持続可能性と信頼性が飛躍的に向上すると予想される。