📚 中国旅行で見えてきたITの違いシリーズ
2026年9月の中国・ハルビン旅行で感じた疑問や発見をもとに、現地のIT事情を技術者目線で掘り下げた全5回のシリーズです。
検索・通信・認証・決済・地図サービスなど、日本とは異なるITの仕組みを紹介しています。
はじめに
2026年9月に中国・ハルビンを旅行した際、地図アプリについても日本とは違う事情を感じました。
Google Mapsだけでは十分に情報を得られず、現地の地図サービスである「高徳地図（Amap）」を利用する場面がありました。
この違いを調べていくと、単に利用できるアプリが違うだけではなく、地図サービスが扱う座標系そのものが異なるという技術的な背景が見えてきます。
今回は旅行中の体験を入口に、中国の地図サービスで使われる座標系と、システム開発で気をつけたいポイントについて整理してみます。
中国では仕組みが頻繁に変わります。あくまで2026年9月時点の情報として参考程度にお楽しみいただければ幸いです。
あくまで私一人の感想です。条件によっては通用しないこともありますので、ご注意ください。
対象者
- 中国旅行で地図アプリの違いを感じた人
- Google MapsやAmapなどの地図APIを利用するエンジニア
- GPS座標を扱うWebアプリ・モバイルアプリを開発している人
- 座標系やGISについて基本的な知識を整理したい人
結論
中国の地図サービスを利用する際には、地図上の位置を表す緯度・経度が、すべて同じ基準であるとは限らないことを理解しておく必要があります。
代表的な座標系として、次の3つがあります。
- WGS-84：GPS/GNSS測位で一般的に使われる座標系
- GCJ-02：中国の地図サービスで広く使われる座標系
- BD-09：百度地図（Baidu Maps）で利用される座標系
これらは単に数値の表現形式が違うわけではありません。
同じ場所を表していても、座標系が異なると緯度・経度の値が変わります。そのため、座標系を意識せずに異なる地図サービスや位置情報を組み合わせると、地図上の位置が大きくずれる可能性があります。
旅行中に感じた地図サービスの違い
中国ではGoogle Mapsだけでは十分に情報を得られない場面がありました。
そこで現地の地図サービスである高徳地図（Amap）を利用しました。
高徳地図は、中国国内の地図情報やナビゲーションに対応したサービスです。
旅行者にとっては現地の地図サービスを使うこと自体が重要ですが、エンジニアとして気になったのは、その地図上に表示される位置情報が何を基準にしているのかという点です。
例えば、GPSで取得した現在地を地図上に表示する場合、GPSから取得した緯度・経度をそのまま地図APIに渡せばよいとは限りません。
これは中国の地図サービスを利用するときに特に注意したいポイントです。
中国の地図で使われる3つの座標系
まず、代表的な座標系を整理します。
| 座標系 | 概要 | 主な用途 |
|---|---|---|
| WGS-84 | 世界的に利用される測地基準系 | GPS/GNSS測位、一般的な位置情報 |
| GCJ-02 | 中国国内の地図サービスで広く利用される座標系 | 高徳地図、Tencent Mapsなど |
| BD-09 | GCJ-02をベースに百度が独自に変換した座標系 | 百度地図 |
厳密にはWGS-84は測地基準系、GCJ-02やBD-09は中国の地図サービスにおける座標系・変換方式という違いがあります。
ここでは実装上の理解を優先し、まとめて「座標系」と呼びます。
WGS-84
WGS-84は、GPS/GNSS測位などで一般的に利用される世界的な測地基準系です。
スマートフォンなどで取得する位置情報も、一般的にはWGS-84系の座標を想定することが多いです。
ただし、実際にアプリやSDKから取得する座標は、OSや位置情報サービス、利用するSDKによって変換されている場合もあります。
そのため、位置情報を取得しただけで「必ずWGS-84」と判断するのではなく、APIの仕様を確認する必要があります。
GCJ-02
GCJ-02は、中国国内の地図サービスで広く利用されている座標系です。
高徳地図の公式FAQでも、同サービスの地図プラットフォームがGCJ-02を採用していることが説明されています。
https://lbs.amap.com/faq/advisory/others/39838
WGS-84の座標をGCJ-02の地図上にそのまま表示すると、位置がずれることがあります。
このずれは、単純に「すべての地点を同じ方向へ100m移動する」といったものではありません。
BD-09
BD-09は、百度地図で利用される座標系です。
百度の公式ドキュメントでは、WGS-84、GCJ-02、BD-09の関係が説明されています。
https://lbs.baidu.com/docs/jsapi?title=jspopularGL%2Fguide%2Fcoorinfo
概念的には次のような関係になります。
WGS-84
│
│ 中国の地図向け座標変換
▼
GCJ-02
│
│ 百度独自の座標変換
▼
BD-09
このため、Amap用の座標をそのまま百度地図に渡すことも、逆に百度地図の座標をAmapに渡すことも、適切とは限りません。
なぜ地図上の位置がずれるのか
ここが今回の技術的なポイントです。
WGS-84とGCJ-02の間には、座標変換による位置の差があります。
中国国内では、WGS-84の位置をGCJ-02の地図に直接表示すると、数十〜数百メートル程度ずれるケースがあります。
この位置ずれは、地図データそのものが間違っているというより、異なる座標系の数値を、そのまま同じものとして扱ってしまうことによって発生します。
例えば、次のような状況です。
- GPSから取得した現在地をGCJ-02の地図に直接表示する
- WGS-84で保存された店舗情報をGCJ-02の地図上に描画する
- GCJ-02の座標をBD-09の地図APIに渡す
いずれも、座標系が一致していなければ位置ずれの原因になります。
なお、位置ずれの大きさは地域や地点によって異なります。固定のオフセット値を加減算するだけでは、正しく変換できません。
座標変換は単純な足し引きではない
座標変換という言葉から、次のような処理をイメージするかもしれません。
変換後の緯度 = 元の緯度 + 0.001
変換後の経度 = 元の経度 + 0.001
しかし、GCJ-02への変換は、このような単純な固定値の加算ではありません。
変換量は地点に応じて変化するため、位置に依存した非線形な変換として扱う必要があります。
この性質から、いくつかの実装上の問題が発生します。
1. 変換を二重に適用してはいけない
例えば、すでにGCJ-02に変換された座標を、もう一度WGS-84からGCJ-02への変換処理に通してしまうと、意図しない位置ずれが発生します。
APIの入力値がどの座標系なのかを把握し、必要な変換だけを行うことが重要です。
2. 逆変換は単純に元の値へ戻せるとは限らない
WGS-84からGCJ-02への変換と、GCJ-02からWGS-84への変換は、同じ処理を逆向きに実行すればよいわけではありません。
GCJ-02からWGS-84への逆変換は、一般に近似的な方法で実装されます。
そのため、変換後の座標が元の座標と完全に一致するとは限りません。
また、地図サービスの公式APIが提供している変換方向にも注意が必要です。必要な方向の変換がAPIで提供されているかを確認し、提供されていない場合は独自実装を安易に採用しない方がよいでしょう。
3. 座標変換APIを利用する
高徳地図は、座標変換用のWeb APIを提供しています。
https://developer.amap.com/api/webservice/guide/api/convert
このAPIでは、GPS座標や百度座標などを指定し、高徳地図で利用する座標へ変換できます。
APIのパラメータには、元の座標系を指定するcoordsysがあります。
また、座標の指定順序は**経度・緯度（longitude, latitude）**です。
この点も、地図APIを利用する際に注意したいところです。
緯度・経度の順序にも注意する
座標系の違いとは別に、緯度と経度の指定順序も混乱しやすいポイントです。
例えば、次の2つの表現があります。
緯度, 経度
latitude, longitude
経度, 緯度
longitude, latitude
地図APIやデータ形式によって、どちらを採用しているかが異なります。
例えばGeoJSONでは、座標を経度・緯度の順序で表します。
{
"type": "Point",
"coordinates": [139.6917, 35.6895]
}
これは東京付近の位置を表す例です。
一方で、位置情報を扱うライブラリや関数によっては、緯度・経度の順序で引数を受け取ることもあります。
そのため、次のような問題が発生しがちです。
- APIの仕様では経度・緯度なのに、緯度・経度で渡してしまう
- DBに保存する順序とAPIに渡す順序が異なる
- 配列の順序がコード上で分かりにくい
- 座標変換処理の入力と出力で順序を取り違える
特に座標を単なる2つの数値として扱っている場合、コンパイル時に間違いを検出できないことがあります。
可能であれば、座標を単なる数値配列ではなく、意味が分かる型やオブジェクトとして扱うことも検討したいです。
地図APIを使うシステム設計で考えたいこと
ここまでの内容を踏まえると、地図APIを利用するシステムでは、座標を単なる緯度・経度のペアとして扱うのは危険です。
少なくとも、次の情報を意識して管理したいところです。
- 緯度
- 経度
- 座標系
- 座標の取得元
- 必要に応じて変換履歴
例えば、内部データとして次のような形式を考えられます。
{
"latitude": 35.6895,
"longitude": 139.6917,
"coordinateSystem": "WGS84",
"source": "gps"
}
もちろん、これはあくまで概念的な例です。
実際のシステムでは、利用する地域、地図サービス、データの取得元、適用される法令やサービス規約などを踏まえて、適切な座標系を決める必要があります。
座標系を明示的に管理する
例えば、次のような設計を考えます。
位置情報の取得
│
▼
座標系を確認
│
▼
必要な変換を実施
│
▼
地図APIへ渡す
ここで重要なのは、座標変換を地図APIの呼び出し部分に集約することです。
各画面や各機能で個別に変換処理を実装すると、変換漏れや二重変換が発生しやすくなります。
座標変換を共通の責務として管理することで、利用する地図サービスを変更した場合にも、影響範囲を限定しやすくなります。
距離計算や近傍検索にも影響する
座標系の違いは、地図上の表示だけでなく、距離計算や近傍検索にも影響します。
例えば、店舗検索システムで「現在地から500m以内の店舗」を検索する場合を考えます。
検索対象の店舗座標と、ユーザーの現在地が異なる座標系で保存されていると、距離計算の結果が正しくなくなる可能性があります。
また、緯度・経度は角度であり、単純に緯度や経度の差をメートルとして扱うこともできません。
距離計算には、対象地域や精度要件に応じて、測地線距離の計算や適切な投影座標系を利用する必要があります。
近傍検索をDBで実施する場合も、座標系が統一されているか、利用する空間関数の前提が満たされているかを確認したいところです。
地図APIを利用するときのチェックリスト
実際に地図APIを利用する場合、次の点を確認しておくと安心です。
- 利用する地図サービスの座標系を確認したか
- GPSやOSの位置情報APIが返す座標系を確認したか
- APIに渡す座標の順序（緯度・経度 / 経度・緯度）を確認したか
- 座標変換が必要な箇所を明確にしたか
- 変換済みの座標を二重変換していないか
- DBに保存する座標系を明示しているか
- 距離計算や近傍検索で座標系が統一されているか
- 地図サービスの公式APIや利用規約に沿って変換しているか
まとめ
中国旅行をきっかけに地図サービスについて調べてみると、普段何気なく使っている地図アプリにも、座標系という技術的な前提があることが分かりました。
特に中国では、WGS-84、GCJ-02、BD-09という複数の座標系が使われているため、異なるサービスを組み合わせる際には注意が必要です。
今回の話は中国特有の事情ではありますが、根本的には外部サービスが扱うデータの前提を理解し、自分のシステムで明示的に管理することが重要という、一般的なシステム設計の話でもあります。
地図APIに限らず、外部サービスとの連携では、データの形式だけでなく、そのデータがどのような基準や意味を持っているのかを確認することが大切だと感じました。
参考資料
- 高徳地図：座標系に関するFAQ
- 高徳地図：座標変換API
- 百度地図：座標系について
- GeoJSON：座標系・地理座標に関する解説
- Developing the Chinese Academic Map Publishing Platform（MDPI）
この記事で、中国旅行を通じて感じたインターネットやITサービスの違いを紹介するシリーズは一区切りです。
旅行中のちょっとした違和感をきっかけに調べてみると、普段の開発でも意識したい技術的なポイントがいくつも見つかりました。
こうした経験を、今後の開発にも活かしていきたいと思います。
中国旅行で見えてきたITの違いシリーズ
2026年9月の中国・ハルビン旅行をきっかけに、現地のインターネットやITサービスについて、技術者目線で整理した全5回のシリーズです。