ハバーサイン距離（Haversine）完全ガイド — 実務で「正しく」「速く」距離を出すための判断基準
ハバーサイン距離の定義・数式・実装から、誤差の大きさ、Vincenty・GeographicLibとの比較、PostGISやモバイル実装での実務的な選び方までを、具体例と最新情報を交えて丁寧に解説します。現場で使える判断基準とコード例を提供。
目次
はじめに：ハバーサイン距離とは（直観と数式）
ポイント：ハバーサイン公式は「地球を球と仮定した上で、緯度経度から大円（最短経路）距離を安定して計算する」ための式です。基本式は以下。
a=sin2(Δφ2)+cosφ1cosφ2sin2(Δλ2)a = \sin^2\left(\frac{\Delta\varphi}{2}\right) + \cos\varphi_1\cos\varphi_2\sin^2\left(\frac{\Delta\lambda}{2}\right)
a=sin2(2Δφ)+cosφ1cosφ2sin2(2Δλ)
c=2⋅atan2(a,1−a)c = 2\cdot\operatorname{atan2}(\sqrt{a},\sqrt{1-a})
c=2⋅atan2(a,1−a)
d=R⋅cd = R \cdot c
d=R⋅c
ここで RRR は地球の半径（多くの場合 6371 km を用いることが多い）。ハバーサインの利点は「小角での丸め誤差に強い」点です（定義・解説参照）。
なぜ「ハバーサイン」を使うのか — 数値安定性の話
古典的な球面余弦則（law of cosines）は直感的で短い式ですが、2点が非常に近い（Δが小さい）場合に丸め誤差で不安定になります。ハバーサインは sin2(Δ/2)\sin^2(\Delta/2)sin2(Δ/2) を使うことで小角領域での精度低下を抑え、実務で安心して使える点が大きな魅力です。実務記事やハンズオンでもこの理由でハバーサインが推奨されることが多いです。
実践パート：コード・SQL・注意点（東京−大阪の比較）
Python 実装（推奨テンプレ）
import math
def haversine(lat1, lon1, lat2, lon2, R=6371000.0):
phi1, phi2 = math.radians(lat1), math.radians(lat2)
dphi = math.radians(lat2 - lat1)
dlambda = math.radians(lon2 - lon1)
a = math.sin(dphi/2)**2 + math.cos(phi1)*math.cos(phi2)*math.sin(dlambda/2)**2
c = 2*math.atan2(math.sqrt(a), math.sqrt(1-a))
return R * c # メートル
# 例: 東京駅(35.681236,139.767125) - 大阪駅(34.702485,135.495951)
実務で重要なのは「入力単位（度かラジアン）」「戻り単位（m/km）」「使うRの定義」をチームで統一することです。公開されている実測コード例も多数あり、東京−大阪での比較では球面モデル同士は一致するが楕円体モデルと差が出ることが観察されています（約0.7 km 程度の差の報告あり）。
PostGIS / SQL（現場でよく使う）
- 簡易（球面近似）:
ST_DistanceSphere(geom1, geom2)— 高速・十分精度 - 精密（楕円体）:
ST_Distance(geography(geom1), geography(geom2))— 高精度（楕円体考慮）
実運用では、まず ST_DistanceSphere で高速フィルタ（例：半径○m以内候補抽出）、絞り込んだ候補に対して楕円体距離を計算する二段階が定石です。
どの距離アルゴリズムをいつ選ぶか（意思決定フローチャート）
- 短距離（数m〜数km）・地域限定（市町村内）
→ 地図投影（UTM / 日本なら平面直角座標系）を使い、ユークリッド距離を採用。道路距離が必要ならルーティングエンジンへ。 - 汎用ウェブアプリ（半径検索、近傍検索）
→ ハバーサイン（またはST_DistanceSphere）で十分。計算コストと実用精度のバランスが良好。 - 長距離（大陸間、極付近、反対側に近いケース）・高精度が要求される場合
→ 楕円体モデル（Vincenty、さらに推奨は GeographicLib のアルゴリズム）。Vincentyは高精度だが「ほぼ反対側に近い」点で収束しない問題が知られているため、GeographicLib が実務的に推奨されています。
誤差の見積もりと実例：いつ楕円体モデルが必要か
- 地球半径の扱い：平均半径 6371 km はよく使われますが、WGS84 では赤道半径 6,378,137 m、極半径 6,356,752.3 m と定義されています。どの半径を使うかで誤差は数 km 単位で変わり得ます。
- 実務目安：
- 数m〜数10m 精度 が必要 → 投影座標系（平面）＋高精度測地（楕円体補正）
- 数十m〜数百m 精度（都市間の概算） → ハバーサインで十分
- ミリメートル〜数mm 精度（測量・海洋測地） → GeographicLib 等の楕円体アルゴリズム
Karney の研究では、GeographicLib の実装は楕円体に対して丸め誤差レベル（nm〜mm）まで高精度で解けることが示されています。一方で Vincenty はほとんどのケースで高精度ながら、特定条件（ほぼ antipodal）で解が得られないことがあります。現場ではこの点を踏まえ、GeographicLib を最終手段の「高精度モード」として組み込むのが堅実です。
パフォーマンス最適化（大規模データ向け）
- インデックスで予選：緯度経度に対して地理的ヒューリング（geohash）や S2、H3 等の空間インデックスで候補を絞る → 絞った候補にハバーサイン/厳密距離を適用。
- ベクトル化：Python で大量計算する場合は NumPy ベースでベクトル化して trig 関数の呼び出し回数を削減。
- オンデバイス vs サーバ：モバイル端末では計算コストが限られるためハバーサインを使い、必要に応じてサーバ側で楕円体精度を当てる運用が良い。
- キャッシュ：静的ポイント（店舗・拠点等）は事前に距離表を作成しておくことでレスポンス向上。
よくある落とし穴とチェックリスト
- 経度・緯度を度とラジアンで混同している。
- 使用する R（地球半径） をチームで統一していない（6371km vs 6378137mなど）。
- 極付近・反対側近傍を扱うユースケースで Vincenty を使い続けている（GeographicLib へのフォールバック推奨）。
- 道路距離（ルーティング）と「球面距離」を混同している（徒歩/車での現実距離はネットワーク次第）。
導入チェックリスト（短縮版）
- 精度要件（m単位かkm単位か）を明文化
- 予算（計算コスト・レスポンス）を確認
- インデックス（S2/H3/Geohash）で予選を組む設計を用意
- 楕円体実装（GeographicLib等）をフォールバックとして準備
まとめと現場への推奨設定
- Webアプリ／LBS（一般）：まずはハバーサイン（R=6371km など統一）で実装 → 候補絞り込み後に必要なら
ST_Distance(geography)等で楕円体距離を算出。 - 高精度／広域（長距離・測量）：GeographicLib（Karney のアルゴリズム）を採用。Vincenty は便利だが反対側近傍での収束問題があるため注意。
- 地域限定の高精度：投影座標系（平面）＋測地補正で最も効率的。
