VercelのIP位置情報が高精度化──市区町村・郵便番号の取得率向上で見直すべき実装
Vercel は 2026 年 10 月 29 日、IP アドレスから訪問者の位置を判定する仕組みを更新しました。ほぼすべてのリクエストで都市レベル、トラフィックの 90% で郵便番号が返るようになり、全プロジェクトへ自動적용されます。コードや設定の変更は不要です。ただし地域による出し分けやアクセス制御を実装しているなら、一部の訪問者が以前と違う都市・国に解決される前提で挙動を確認してください。この記事では、変更点の整理と、確認すべき箇所・テスト方法を具体的にまとめます。
何が変わったのか
Vercel の案内によると、今回の変更は位置の導出方法そのものにあります。これまでのようにレジストリの登録情報だけに依拠するのではなく、観測されたネットワークの挙動からより細かい粒度で解決するようになりました。到達率は、都市レベルがほぼ全リクエスト、郵便番号がトラフィックの 90% とされています。
あわせて位置情報データの更新頻度も上がりました。IP レンジの再割り当てや経路変更に追従するため、同じ IP でも時間の経過とともに判定が変わり得ます。一方で、取得できるフィールド自体は変わりません。x-vercel-ip-country などの既存ヘッダーと @vercel/functions の geolocation() ヘルパーは、Vercel Functions でも Routing Middleware でも従来と同じ項目を返します。つまり「値の種類」ではなく「値の中身と埋まり具合」が変わる更新です。
判定が変わりやすいのはどのトラフィックか
Vercel は、差が出やすい例として VPN、ホスティング事業者、リースされた IP レンジからのトラフィックを挙げています。地域インターネットレジストリ（RIR、IP アドレスの割り当てを管理する組織）の記録とは別の国から広告されているサブネットは、トラフィックが実際に終端するデータセンターの位置に解決されるようになります。
実務への影響として想定されるのは、社内 VPN、外形監視サービス、海外 SaaS や API ゲートウェイを経由したアクセスです。これらは一般の家庭回線より「レジストリ上の国」と「実際の接続先」がずれやすく、国単位の許可リストや拒否リストを運用している場合に挙動が変わる可能性があります。逆に、一般的なモバイル回線・固定回線の訪問者については、国レベルの判定が大きく入れ替わる場面は限定的と考えられます。
優先して棚卸しすべき箇所
- 位置情報ヘッダーや
geolocation()を参照しているコードの洗い出し。ミドルウェア、API ルート、エッジでのリダイレクト処理が中心になります。 - 国による分岐。言語・通貨・価格表示、地域限定のキャンペーン、法令に関する表示の出し分け。
- アクセス制御。国単位のブロックや許可、限定公開中の環境への到達可否。社内 VPN が別の国として判定されると、意図せず弾かれる側に回ります。
- 郵便番号を使う処理。これまで値が取得できなかった訪問者にも値が入るようになるため、「空であること」を前提にした分岐やフォーム初期値の挙動が変わります。
- ログと分析。国別・都市別の集計は、更新日をまたいで連続性が崩れる可能性があります。2026 年 10 月 29 日に判定方法が変わったことを計測ドキュメントに注記しておくと、後から数値の段差を追跡できます。
実装時に踏みやすい落とし穴
第一に、geolocation() が返す region は訪問者の地域ではなく、リクエストを受け取った Vercel のリージョンを指します。訪問者側の第一次行政区分は countryRegion（ISO 3166-2 の地域部分）です。ここを取り違えたまま分岐を書くと、精度が上がっても結果は改善しません。
第二に、都市名ヘッダー x-vercel-ip-city の非 ASCII 文字は RFC3986 に従ってエンコードされます。画面に表示する場合はデコード処理が必要です。
第三に、各フィールドは文字列または未定義です。到達率が上がっても 100% ではないため、値が無い場合の既定値（既定言語・既定通貨・既定の配送先）は必ず残しておきます。
第四に、Vercel の前段に別のプロキシや CDN を置いている場合、Vercel は IP 偽装を防ぐために X-Forwarded-For を上書きし、外部の IP をそのまま転送しません（Enterprise プランでは Trusted Proxy の購入・有効化により自社の値を使えます）。この構成では位置判定がプロキシ基準になるため、今回の精度向上の恩恵も受けにくくなります。構成図を確認し、どの IP を見て判定しているかを把握してください。
精度をどこまで判断材料にしてよいか
Vercel は郵便番号ヘッダーを追加した際、この情報は正確な位置特定ではなく一般的な参考として使うべきで、重要な用途ではブラウザの Geolocation API など他のデータソースと併用することを推奨していました。今回の更新は到達率と鮮度を改善するものであり、この前提自体を覆すものではありません。
したがって、課税区分、年齢制限、ライセンス上の配信可否といった厳格な判定を IP 単独で行う設計は、精度が上がった今も避けるべきだと考えます。IP による判定は初期値の提案やコンテンツの出し分けに留め、最終的な根拠はユーザーの明示的な選択、アカウント情報、決済情報など別の手段で担保する方が安全です。
あわせて検討したいのが、取得した位置情報の保存範囲です。郵便番号や緯度経度が多くの訪問者で得られるようになるということは、ログに残る情報の粒度も自動的に細かくなるということです。分析に必要な粒度（多くの場合は国や都道府県レベル）を定め、それ以上の値を無期限に保存しない方針を決めておくと、後から見直す手間を減らせます。
テストの進め方
Vercel は、アクセスルールの検証を静的なレジストリ上の割り当てではなく、その IP が現在属しているネットワーク上の位置に対して行うよう案内しています。実務では次の順序が現実的です。
- プレビュー環境に、受け取った位置情報ヘッダーをそのまま JSON で返すデバッグ用ルートを用意する
- 社内 VPN、モバイル回線、海外リージョンの VPN など、経路の異なる複数の接続元から同じルートを叩き、判定結果を記録する
- WAF やミドルウェアの国別ルールは、実際に運用で使う接続元（社内 VPN、監視サービス、決済事業者のコールバック元）からアクセスして通過可否を確認する
- 自動テストではヘッダーをモックし、値が未定義のケースと想定外の国のケースを必ず含める
この更新は設定変更なしで適用されるため、気付かないまま挙動だけが変わるのが最大のリスクです。まずは位置情報を参照している箇所を洗い出し、未定義時のフォールバックと国別ルールの実アクセス確認までを一度通しておくことをおすすめします。ミドルウェアでの出し分けや WAF ルールの設計を含めて相談したい場合は、お問い合わせからご連絡ください。
