従量課金APIの費用事故から学ぶ、キー制限と呼び出し設計｜実務知識｜東京・渋谷のホームページ制作・Web制作会社フライング・ハイ・ワークス

自社の公開検証環境で起きた従量課金APIの費用事故について、請求の確認、Googleの事後調査、自社で行った対策を整理します。キーの不正利用対策と、公開画面からの呼び出し設計は、分けて確認する必要がありました。

請求の数字と、原因の判断を分ける

自社の公開検証環境で、従量課金APIの利用料金が急増しました。Googleからの請求確認の回答では、2026年7月12日から31日までの対象API利用は99,174回、費用は487,068円でした。この金額は対象APIの費用であり、関連サービスや税を含めた総額とは分けて扱っています。

調査では、何回使われたかという請求の事実と、なぜ使われたかという原因を分ける必要がありました。API利用回数だけから、自社サイトの閲覧数やアクセス元を特定することはできません。

当社では、設定ファイルへのAPIキーの直接記載と、公開詳細ページの表示をきっかけにサーバー側で有料APIを実行する構造を確認しました。キーの管理と、公開アクセスが有料処理につながる設計の両方が見直し対象になりました。

その後、2026年8月18日のGoogleサポートの調査回答では、露出したAPIキーを第三者が不正利用したと判断されました。一方、当社では、キーがどの経路で取得され、具体的にどのように利用されたかまでは特定できていません。

そのため、この事故を「公開ページを大量に巡回されたことだけが原因」とは説明しません。確認できた設計上のリスクと、Googleの調査見解、未特定の経路を区別して記録しています。

対策では、問題となったキーを交換し、ブラウザ用とサーバー用の用途を分け、利用できるAPIや送信元を制限しました。キーを設定ファイルへ直接記載する管理方法も見直しました。

公開画面については、表示のたびに有料APIを実行する構造から、管理された処理で事前に取得したデータを参照する構造へ変更しました。保存・再利用は、利用するAPIの規約やデータの保持条件を満たすことが前提です。

また、アプリケーション側の実行回数制限と、サービス側の日次クォータを設けました。前者は自社の処理の過剰実行に備えるものであり、自社アプリを経由しないキーの不正利用まで止めるものではありません。キーの利用制限、呼び出し構造、サービス側の上限を別々に確認しました。

2026年8月18日のやり取りでは、Googleから制限のないキーが残っているとの指摘を受け、追加対応を行いました。その後、有効なキーへのアプリケーション制限と日次クォータの適用をGoogleが確認しています。

対策後には、当社の監視でもリクエスト頻度の低下を確認し、当時のサポートへの連絡に記録しました。ただし、ここでは同一条件で比較した削減率を提示していません。設定が反映されたこと、観測値が下がったこと、長期的な再発防止を確認することは、それぞれ別の確認事項です。

従量課金APIの確認では、キーを誰がどこから使えるか、1回の画面操作が何回の有料処理になるか、異常時にどの範囲で実行を制限できるかを分けます。公開画面を軽くする対応だけでも、キーの交換だけでも、すべての利用経路を確認したことにはなりません。

予算アラートは通知のための仕組みで、設定額に達した時点で利用や請求を自動停止するものではありません。APIごとのクォータと、アプリ側の実行回数制限を別に確認します。クォータと請求の集計には差があり得るため、設定したクォータを厳密な金額保証とは扱いません。

クォータを低くしすぎると利用者向け機能が停止する場合もあります。制限に達した場合の表示や代替手段まで確認します。予算通知・クォータ・保存条件については、Google Maps Platformの費用管理も参照してください。

費用の数字だけで原因を決めず、請求の範囲、調査で判明したこと、自社で実施した対応、残る不確実性まで記録する。それが、同じ問題を次の実装へ持ち込まないための判断材料になります。