Google Places API のキーの守り方(ブラウザ露出 vs サーバ中継)

調査時点: 2026-08。ある PWA で場所検索(Autocomplete)を組み込んだときの検討。

ウィジェットかデータ API か#

部品	キーの所在	UI の自由度
`PlaceAutocompleteElement`(Maps JavaScript API のウィジェット)	ブラウザに必ず出る	入力欄と候補リストを Google が描画。候補リストに自前の行を差し込めない
`AutocompleteSuggestion.fetchAutocompleteSuggestions()`(JS SDK のデータ API)	ブラウザに出る	データだけ返るので候補リストは自前で描ける
Places API (New) の REST をサーバで中継	サーバのシークレット	自前描画。Maps JavaScript API の読み込み自体が不要

ウィジェットを使うと決めた時点でプロキシは成立しない。どちらかしか選べない。候補リストに「入力文字列をそのまま場所として採用する」行を足すような要件があるなら、ウィジェットでは機能として失われる。

ブラウザにキーを出す場合の守り#

Google が案内する標準運用は、HTTP リファラー制限 / API の制限 / 予算アラートの 3 つ。ただしリファラーは偽装できるので、リファラー制限だけでは直接呼び出しを防ぎきれない。守りたいのが料金の暴走なら、「気づくための予算アラート」と「止めるための割り当て上限(クォータ)」をセットで置く。通知より先に止まるのは割り当て上限だけなので省かない。

サーバで中継する場合#

静的配信のために Cloudflare Workers などのサーバがすでにあるなら、/api/places/* を中継して Places API (New) を叩き、キーは Worker のシークレットにだけ置く。

中継は薄くする。Google のレスポンスをそのまま返し、整形はクライアントに残す(整形を Worker に置くと表示を直すたびに Worker を触ることになる)。
セッショントークンはクライアントが UUID を生成し、プロキシは素通しする。候補取得と詳細取得を同じトークンで通し、詳細を取ったら捨てる。トークンを使い回すと課金が個別に落ちる。
アプリケーション制限(リファラー)はサーバからの呼び出しには効かない(リファラーが付かない)ので外す。代わりに秘匿で守る。
一度バンドルに入ったキーは使い回さず、作り直す。
GCP 側で有効化が要るのは Places API (New) だけ。Maps JavaScript API は無効化できる。

位置情報の許可を求めるタイミング#

ブラウザの位置情報の許可は、起動時ではなく場所検索を開いた瞬間に求める。文脈のない許可要求は拒否されやすく、一度拒否されるとアプリ側から復帰できない。拒否されたときのために、navigator.permissions.query で許可状態を表示し、OS 設定への誘導文を置く場所を用意しておく。

更新履歴#

2026-08-29: 初版(ローカル調査ノート)
2026-10-17: Wiki へ移植、概念ページとして再構成