はじめに

😇「Google Maps Platform には月 $200 の無料枠があるし、個人開発なら収まるでしょ」
🤔「店名と住所くらいしか取らないから、安い階層で済むはず…」
😱「……ユーザーが 5,000 人になったら、月いくら？」

従量課金の API を組み込むとき、最初の見積もりはだいたい楽観的です。

自分が個人開発している食の口コミサービス「あじぴた」でも、まさにこれが起きました。
店舗検索に Google Places API を入れたところ、試算は MAU 5,000 で月 $1,440。
サーバーとデータベースにかかっている月額（約 $45）の 32 倍です💸

この記事では、そこから8 層の防壁を組み立てて、
課金の上振れを構造的に起こらないようにした設計をまとめます🛡️

Places API の話ですが、LLM API や決済 API など、従量課金の API 全般にそのまま持ち帰れる内容にしています。

あじぴた全体の構成は、こちらの記事にまとめています。
「低評価を公開しない」口コミサービスを個人開発した話 — 4,300コミット・6リポジトリの全体像

結論：単価は下げられない。呼ぶ回数を減らすしかない💡

先に結論です👇

従量課金 API のコストは「安く使う」では抑えられない。「呼ばない」設計にするしかない。

単価は提供元が決めるもので、こちらからは動かせません。🙅
動かせるのは呼ぶ回数だけです。💡

そこで、外部 API を呼ぶまでに 8 つの関門を置きました。🚧

#	防壁	効き方
①	外部 API を使わない経路を用意する	そもそも呼ばない
②	Places を呼ぶ条件を絞る	必要なときしか呼ばない
③	キャッシュする	同じ検索で 2 回呼ばない
④	回数の上限を設ける	呼べる回数に天井を作る
⑤	回数の記録を消させない	天井を外させない
⑥	取得する項目を最小にする	1 回あたりの単価を上げない
⑦	サーバー側で実測する	実際に何回呼んだかを知る
⑧	検索結果で返した ID だけ受け付ける	でたらめな ID で呼ばせない

一つずつ説明する前に、なぜ Places API を入れることになったのかから書きます。
ここが一番の「つまずいたポイント」でした😅

つまずいたポイント：HotPepper だけで行けると思っていた

① リリースしたら、口コミを書きたい店が出てこない

あじぴたは、もともとPlaces API を使わない方針でした。🙅
店舗検索は HotPepper グルメサーチ API（無料）だけで組み、
Google Maps は地図の表示だけに限定していました。従量課金を避けるためです。🗺️

ところがリリースして運用してみると、
口コミを投稿しようとして検索しても、店が出てこないケースが多発しました😢

原因は HotPepper 側にありました。🔍
HotPepper グルメサーチ API に載っているのは、ホットペッパーに掲載しているお店です。
個人店やチェーンの一部は、構造的に抜けています。🏮

検索条件や設定をいくら変えても、載っていない店は出てきません。
口コミ投稿というサービスの中核の、入口が塞がっている状態でした。🚪

② 「店舗申請」はユーザーの負担が大きすぎた

この時点での救済策は、店舗申請でした。📝
検索で出てこない店は、ユーザーが Google マップのリンクを貼って申請し、登録してから口コミを書く。

ただ、これは口コミを書きたいだけのユーザーに、店舗の登録作業を求めることになります。

ユーザーがやりたいこと: この一皿の口コミを書きたい
実際に求めていたこと:   ① 店を検索 → ② 出てこない → ③ Google マップでリンクを取る
                        → ④ 申請 → ⑤ ようやく口コミを書く

**手間が多すぎて、中核の体験として成立していませんでした。**😩

③ 慌てて Places を入れたら、コストが想像以上に重かった

そこで、検索そのものに Places API を入れることにしました。
Google マップにある店なら、検索で出てくるようにする。🔎

ところが、改めてコストを見積もると想像以上に重かったんです💦

ここから先は、「なるべくお金をかけずに、出てこない店を出す」ための設計の話になります。💪

前提が 2 つ崩れていた😇

コストを見積もりし直したとき、それまでの前提が 2 つとも成り立っていないことが分かりました。😲

月 $200 の無料クレジットは、もう無い

以前の設計判断の記録（ADR）には、こう書いてありました。

無料クレジット（月 $200）の範囲内で運用する

ところが Google は 2025 年 3 月 1 日に、月 $200 のクレジットを廃止しています。
代わりに、SKU（課金単位）ごとの無料コール数に変わりました。📋

階層	無料コール数（月）
Essentials	10,000 件
Pro	5,000 件
Enterprise	1,000 件

「クレジットの範囲に収める」という考え方自体が、成立しなくなっていました😇

店名を取った時点で Pro 階層になる

もう 1 つは、課金階層の認識です。
「安い階層のフィールドだけに絞れば、コストを抑えられる」と考えていました。🤔

しかし Places API (New) の課金は、リクエストで要求したフィールドのうち、最も高い階層で決まります。
そして店名（displayName）は Pro 階層です。

店名を取らない店舗検索はあり得ないので、Pro 階層の課金は避けられません。💸

用途	無料枠を超えた後の単価
店舗検索（Text Search Pro）	$32 / 1,000 件
店舗詳細（Place Details Pro）	$17 / 1,000 件
エリア名 → 座標（Geocoding）	$5 / 1,000 件

試算したら MAU 5,000 で月 $1,440

前提を直したうえで、「1 ユーザーあたり月 10 回検索する」と仮定して試算しました📊

MAU	月間リクエスト	月額
500	5,000	$0（無料枠内）
1,000	10,000	$160
2,000	20,000	$480
5,000	50,000	$1,440

あじぴたの固定費は、Vercel と Supabase を合わせて月 $45 程度です。
MAU 5,000 で、外部 API だけで固定費の 32 倍になります。🤯

しかもこれは、サービスが成功するほど死ぬ構造です。
ユーザーが増えて嬉しいはずの状況が、そのまま請求に直結する😱

個人開発なので、払えない額になった時点でサービスは続けられません。
だから呼ぶ回数そのものを減らす設計に振り切りました。✂️

8 層の防壁🛡️

全体の流れはこうなっています👇

外部 API に到達して課金が発生するのは、右下の赤い 1 箇所だけです。
それ以外のすべての分岐は、無料で結果を返します。🆓

① 外部 API を使わない経路を用意する

「あじぴた登録店のみ」という検索モードを用意しています。
これは自前のデータベースだけを引くので、外部 API を一切呼びません。🏠

この経路の利用比率が上がるほど、コストは下がります📉

② Places を呼ぶ条件を絞る

Places は常に呼ぶわけではありません。☝️

主経路は HotPepper（無料）
HotPepper が 0 件のときだけ、Places でも検索する（フォールバック）
それも1 ページ目だけ

この条件は、純粋関数として切り出してテストで固定しています👇

// 課金額に直結する契約なので、関数として独立させてテストで固定する
export const shouldFallbackToPlaces = (params: {
  registeredOnly: boolean;
  hotpepperCount: number;
  isFirstPage: boolean;
}): boolean =>
  !params.registeredOnly && params.isFirstPage && params.hotpepperCount === 0;

ここで大事なのは、「件数が少ないときも Places で検索する」をあえて入れなかったことです。⚠️

「3 件以下なら Places も呼ぶ」のようなしきい値は、課金額を直接左右します。
実測データがない状態で決める数字ではないので、
まずは 0 件のときだけに限定しました。これなら、上振れが構造的に起こりません👍

課金に直結する条件は、関数として独立させてテストで固定するのがおすすめです。
条件式がルートハンドラの中に埋もれていると、何気ないリファクタリングで課金額が変わります。

③ キャッシュする

同じ検索で 2 回課金しないように、検索結果をキャッシュしています。🗃️
有効期間は 7 日です（最初は 3 日でしたが、課金の抑止を優先して延ばしました）。

ここで工夫が要ったのは、キャッシュキーの設計です。🔑

キー = 検索クエリ + 座標グリッド + 半径 + 件数

座標をそのままキーにすると、1 メートルずれただけで別のキーになり、キャッシュが効きません。
かといって、座標を決まった幅のマス目（グリッド）に丸めると、今度は別の問題が出ます。😵

方式	問題
座標そのまま	少しずれるだけで別キーになり、ヒットしない
固定幅のグリッド	半径 100m の狭い検索が、離れた場所の結果を拾う
半径からグリッド幅を決める	狭い検索は細かく、広い検索は粗く丸められる

そこで、グリッド幅を検索半径から決めるようにしました👇

// グリッド幅 = 検索半径の半分（ただし上限あり）
const MAX_GRID_DEGREES = 0.01; // 約 1.1km
const KM_PER_DEGREE = 111;

export const gridDegreesForRadius = (radiusKm: number): number =>
  Math.min(radiusKm / 2 / KM_PER_DEGREE, MAX_GRID_DEGREES);

// floor だと常に南西へ寄るので、round でグリッドの中心へ寄せる
const snapToGrid = (value: number, grid: number): number =>
  Math.round(value / grid) * grid;

もう 1 つ、キャッシュに含めないものも決めています。

「この店は非表示」という判定は、キャッシュに入れない。

キャッシュには外部 API から返ってきた結果をそのまま保存し、
非表示の除外は毎回データベースを見て行います。

逆にすると、キャッシュした後で非表示にした店が、
有効期間の 7 日間ずっと表示され続けます👀

④ 回数の上限を設ける

キャッシュだけでは防げないケースがあります。
**毎回違うクエリを投げられると、キャッシュは 1 回もヒットしません。**😇

そこで、外部 API を呼ぶ直前に、データベース側で上限を消費するようにしました。🚦

経路	1 分 / 1 時間（IP ごと）	1 日（全体）
店舗検索	5 回 / 30 回	500 回
エリア名 → 座標	10 回 / 60 回	1,000 回

設計で気をつけたのは 4 点です。✍️

1. 「1 分・1 時間あたり」と「1 日あたり」の 2 種類の上限を持つ。
1 分・1 時間の上限だけでは、1 日の合計が際限なく増えます。
1 日の上限だけでは、1 人が短時間で使い切ると、その日は全員が使えなくなります。⚖️

2. 生の IP アドレスは保持しない。
ハッシュ化した値だけを記録し、24 時間で消します。🧹

3. 回数に数えるのは、キャッシュに無かったときだけ。
守りたいのは課金であって、リクエスト数ではありません。
キャッシュから返せた（課金されない）検索まで数えると、普通に検索を繰り返しているだけのユーザーが先に止まってしまいます。🚶

4. 上限を確認できないときは「呼ばない」側に倒す（fail closed）。 ここが一番重要です🔒

// Before（fail open）: 上限を確認できなければ、とりあえず呼ぶ
const allowed = await consumeQuota(ipHash).catch(() => true);

// After（fail closed）: 上限を確認できなければ、呼ばない
const allowed = await consumeQuota(ipHash).catch(() => false);
if (!allowed) return hotpepperResults; // Places は呼ばず、HotPepper の結果だけ返す

逆の「確認できなければ呼ぶ」（fail open）にすると、守るための仕組みが壊れているときだけ無防備になるという、
一番まずい壊れ方をします。DB のエラーや想定外の戻り値のときこそ、止めるべきです。🛑

上限に達したときの振る舞いは、経路ごとに変えています。

経路	上限に達したとき	理由
エリア名 → 座標	エラー（429）を返す	代わりの手段がない
店舗検索	Places を呼ばず、HotPepper の結果を返す	Places は補完なので、無くても検索は成立する

店舗検索でエラーを返すと、「HotPepper が 0 件のときだけ、検索全体が失敗する」という
ユーザーから見て意味の分からない壊れ方になります。
こちらはエラーにせず、HotPepper の結果だけを返すほうが適切でした。

⑤ 回数の記録を消させない

上限の判定は、「呼び出しを記録したテーブル（以下、台帳）に何行あるか」で行っています。

ということは、行を消せる権限 = 上限をリセットできる権限です😇

そのため、この台帳テーブルの権限は誰にも配っていません。管理者用のロールも含めてです。🔐
上限を判定する関数そのものが特別な権限で動くので、呼び出し側にテーブルの権限は要りません。

「数を数えるテーブル」は、消せる権限を持つ人が上限を外せる、という視点は見落としがちです。
レート制限や利用回数の台帳を作るときは、書き込み・削除の権限を誰が持つかまで確認しておくと安心です。

⑥ 取得する項目を最小にする

店名を取る以上 Pro 階層は避けられませんが、
さらに上の Enterprise 階層（評価・レビュー・営業時間など）は使わないように、
取得する項目の指定（フィールドマスク）を固定しています。🎯

// 店舗検索で要求するフィールド（Enterprise 階層のものは含めない）
const STORE_SEARCH_FIELD_MASK = [
  "places.id",
  "places.displayName", // ← これで Pro 階層になる（店名は必須なので避けられない）
  "places.location",
  "places.formattedAddress",
  "places.addressComponents",
  "places.primaryType",
  "places.primaryTypeDisplayName",
  "places.types",
].join(",");

あじぴたは自前の口コミで評価するサービスなので、Google の評価やレビューはそもそも要らない、というのもあります🙅

⑦ サーバー側で実測する

コストを管理するには、実際に何回呼んだかを知る必要があります。🔢

GA4 は導入済みですが、課金の試算には使えません。🙅

理由	内容
同意で欠損する	分析 Cookie に同意したユーザーしか計測できない
ブロックで欠損する	ブラウザのトラッキング防止や拡張機能に遮られる
PV から逆算できない	検索画面は条件を変えるたびにリクエストが飛ぶ。1 PV あたり 3〜10 リクエストと幅が大きい

サーバー側で数えれば、同意にもブロッカーにも左右されず、課金対象と 1 対 1 で対応します📊

数え方にもルールを決めました。📏

数えるのは、HTTP リクエストを出す直前。API キー未設定などで手前で止まった場合は、課金されないので数えない
リクエストを出した後は、成否で分けない。タイムアウトやエラーでも提供元の枠は消費されうるので、成功だけ数えると試算が小さく出る
キャッシュヒットは別枠で数える。ヒット率を実測するため
経路ごとに分けて数える（HotPepper / 登録店のみ / Places）。①の比率を見るため

記録はレスポンスを返した後に非同期で行うので、検索の応答時間には乗りません。
記録に失敗しても、検索は成功します。✅

また、この計測テーブルは個人を特定できる情報を一切持たない設計にしていて、
「その列が存在しないこと」をデータベースのテストで固定しています🧪

⑧ 検索結果で返した ID だけ受け付ける

ここまでは店舗「検索」の話でした。
店舗の詳細ページは別の経路で、別の料金区分で課金されます。

店舗詳細ページは SEO のためにログインなしで公開しています。
つまり、URL に任意の IDを入れてアクセスできます。⚠️

素朴に実装すると、でたらめな ID を投げ続けるだけで、課金を無制限に発生させられます😱
キャッシュも上限も、検索の経路にしか掛かっていないからです。

しかも店舗詳細は、ページ本体・メタデータ・OGP 画像で1 ページあたり複数回呼ばれます。
ID が毎回違えば CDN のキャッシュも効かないので、呼び出し回数はさらに膨らみます。📈

そこで、検索結果として一度でも返した ID だけを受け付けるようにしました。🎫
いわゆる許可リスト（allowlist）です。

// 店舗詳細: 台帳にない ID では外部 API を叩かない
const issued = await isIssuedPlaceId(placeId); // 検索結果として返したことがある ID か
if (!issued) notFound(); // 外部 API を呼ばずに 404

const place = await fetchPlaceDetails(placeId); // ここで初めて課金

検索結果として返した ID を台帳に記録しておき、
台帳にない ID は外部 API を呼ばずに 404 を返します。

8 つの中で、悪意のあるアクセスで課金を膨らませる経路を塞ぐ、いちばん守りの要になる防壁です🛡️

無料の API にも許可リストが要る！

⑧の許可リストは、無料の HotPepper API にも入れています。

「無料なら関係ないのでは？」と思うかもしれませんが、守っているのはお金ではなく、サービスが止まらないことです。🤔

でたらめな ID で店舗詳細を叩き続ける
  → HotPepper への実リクエストが発生する
  → 1 日あたりの利用上限を使い切られる
  → 検索も店舗詳細も、全ユーザーで止まる

無料の API でも、利用回数の上限がある時点で、それは有限の資源です。
ログインなしで任意の ID を受け付けるページがあるなら、同じように塞いでおく必要があります💡

これは、Places の移行をリリースする前の監査で検出したものです。
Places 側は台帳で塞いでいた一方、HotPepper 側には同じガードが無いことが分かり、
リリース前に同じ設計で塞ぎました🔍

守るべきは「課金」だけではなく「枠」。
無料 API の日次上限も、使い切られればサービスが止まります。

機能を止める・戻れる形にしておく

役目を終えた機能を閉じる

防壁を積むだけでなく、課金が発生する機能そのものを閉じる判断もしました。🚫

つまずいたポイント②の店舗申請です。
申請では、ユーザーが貼った Google マップのリンクから店舗情報を取得するため、Places API を呼びます。

ところが Places で検索できるようになったことで、申請で登録できる店は、検索で拾えるようになりました。🔁

申請に必要なのは Google マップのリンク
  → 申請できる店 = Google マップにある店
  → Google マップにある店は、Places の検索で拾える

機能として存在する理由がなくなったので、申請フローは停止しました。この機能による課金はゼロです。🎉

ただしコードは消さず、設定 1 つで戻せる状態で残しています。♻️
万が一、コストの都合で検索を HotPepper だけに戻すことになっても、すぐに申請フローを復活できるようにするためです。

使われていない機能は、コストだけを生みます。
消すのではなく止める、という選択肢を持っておくと判断が軽くなります。

いつでも HotPepper に戻せるようにしておく

もう 1 つ効いたのが、以前から決めていたデータの持ち方です。

店舗の外部 ID を、店舗テーブルに直接持たせず、別テーブルで複数ソース分を保持しています。🗂️

stores（内部 ID）
  └── store_external_refs
        ├── HotPepper の ID
        └── Google の place_id

ユーザーの口コミは内部 IDに紐づいているので、外部のソースを切り替えても無傷です。🛟
つまり、コストが見合わなければ、すぐ HotPepper に戻せます🔙

この形にしたのは、Places を入れるかどうかも決めていなかった頃です。
それでも戻れる形にしたのは、単純にコストが怖かったからでした。
乗り換えた先が値上げしたときに戻れなければ、「払えるかどうか」の一択になります。😨

現在は HotPepper を主経路、Places を 0 件のときだけ使う構成で運用しています。
全面移行は、ユーザーが増えてコストをカバーできる収益が立ってから検討します。📈

他の従量課金 API に持ち帰れるチェックリスト✅

ここまでの話を、Places 以外の API にも使える形にまとめます📝
LLM API でも、決済 API でも、地図 API でも、構造は同じです。🤖

観点	確認すること
試算	MAU を増やしたときの月額を、実装より先に出しているか
前提	料金体系の前提（無料枠・課金階層）を公式の料金ページで確認しているか
呼ばない経路	外部 API を使わずに済む経路を用意しているか
呼ぶ条件	呼ぶ条件を純粋関数にしてテストで固定しているか
キャッシュ	キーの細かさは適切か。後から変わる情報をキャッシュに含めていないか
上限	短時間と 1 日の2 種類があるか。数えるのは課金されるときだけか
確認できない時	上限を確認できないとき、呼ばない側に倒れるか
上限到達時	エラーを返すか、代わりの結果を返すかを経路ごとに決めたか
記録の権限	回数を記録するテーブルを消せる人がいないか
単価	要求するパラメータ・フィールドで階層が上がっていないか
計測	リクエストを出す直前にサーバー側で数えているか
任意の ID	ログインなしのページで、返していない IDを受け付けていないか
無料 API	日次上限を使い切られる経路が残っていないか
可逆性	コストが見合わないとき、元に戻せるデータの持ち方か

まとめ

従量課金 API は単価を下げられない。呼ぶ回数を減らすしかない
実装より先に試算する。あじぴたは MAU 5,000 で月 $1,440 という数字から防壁を組み立てた📊
料金体系の前提は変わる。無料クレジットの廃止と課金階層は公式の料金ページで確認する
防壁は多層で。呼ばない経路・呼ぶ条件・キャッシュ・上限・権限・取得項目・計測・許可リスト🛡️
上限を確認できないときは呼ばない（fail closed）。守る仕組みが壊れているときこそ止める🔒
無料 API にも許可リストが要る。守るべきは課金だけでなく「枠」
使わない経路は止める。データは戻せる形で持っておく🔙

「HotPepper だけで行ける」と思っていたところから始まって、
結果的には外部 API を呼ぶ前提をすべて疑う設計になりました。🧐

従量課金の API を組み込む予定がある方の、設計の叩き台になれば幸いです💡

シリーズの他の記事も、よろしければ📚

このシリーズでは、個人開発サービス「あじぴた」の設計をテーマごとに書いています。
サービスの全体像や、ほかの記事の一覧はハブ記事にまとめています👇

🔗 「低評価を公開しない」口コミサービスを個人開発した話 — 4,300コミット・6リポジトリの全体像

次回は、Next.js 16 で Web Vitals を測って直した話を書く予定です。
loading.tsx を足したら LCP が倍になった、という罠の話です🪤

設計の中身を通して読みたい方には、解剖ドキュメントも公開しています🔬
🔗 あじぴたの内側（ajipita-inside）

参考になれば幸いです🙏