要約

  • Googleの公式料金説明では、Autocomplete（New）をPlace Details Essentials（IDs Only）で終えると、最後の詳細呼び出しは無料になる一方、それ以前のAutocompleteはすべて個別請求になる。
  • 通常のEssentialsで終える場合、最初の12回は個別請求、13回目以降は無料のセッション利用SKUに入る。詳細呼び出しには別の料金がかかる。

無料なのは出口だけ

店名を入力すると候補が次々に出る。アプリが最後に必要とするのは、選んだ場所のIDだけかもしれない。そこで開発者はPlace Details（New）の取得フィールドをIDs Onlyに絞る。返却データは少なく、詳細リクエストの価格はゼロ。API利用の最適化としては申し分なく見える。

ところがGoogleの料金表は、直前のAutocomplete呼び出しにも目を向ける。Essentials（IDs Only）で終わるセッションでは、それまでの全Autocompleteリクエストが「Autocomplete Requests」として一件ずつ課金される。Googleは、セッションを使わなかった場合と同じ扱いだと説明する。トークンを付けていても、最後に選んだフィールドがセッション料金の扱いを変える。

通常のEssentialsで詳細を取得して終えると、最初の12回のAutocompleteは個別課金、13回目以降は料金のかからない「Autocomplete Session Usage」に入る。ただし詳細リクエスト自体は別に請求される。ProやEnterpriseの詳細、あるいは住所検証で終えれば、Autocompleteの全件が無料のセッション利用に入り得るが、終端の呼び出しにはそれぞれの上位SKUの料金が付く。最後の一件だけで安い経路を決める計算は成り立たない。

価格を動かす権限はコードの中にある。開発者は必要なフィールドを減らし、購買担当は月々のAPI費用を見ている。「セッション」という集計単位だけでは、どの終端が請求を決めたか見えない。比較に必要なのは、補完の呼び出し回数、終端のSKU、契約で適用される価格だ。Googleの公開資料には個別顧客の通信量や請求書はない。

トークンの扱いも別の確認項目となる。Googleはセッションごとに新しいトークンを求め、同じCloudプロジェクトのAPIキーを使うよう指定する。LegacyとNewの混在、トークンの欠落や再利用では、リクエスト単位の請求になる。途中で放棄されたセッションも同様だ。正しくIDs Onlyで終えたケースと実装上の取り違えを混ぜてしまえば、対策を誤る。

無料のIDは確かに無料だ。そこへ着くまでの検索は、最後の選択によって一件ずつ値札を付け直される。

出典