標準地域メッシュコードのしくみ — 緯度経度から8桁を組み立てる

国勢調査の統計データ、ハザードマップの浸水想定、標高データ、そして座標変換のパラメータファイル。日本のさまざまなデータが 53394611 のような数字の並びで区切られています。これが標準地域メッシュコード（JIS X 0410）です。

一見すると意味不明な8桁ですが、中身は緯度経度そのものです。仕組みが分かればコードを見ただけで場所の見当がつくようになりますし、逆に緯度経度からコードを組み立てるのも電卓でできます。

座標変換の側から見ると、これは他人事ではありません。TKY2JGD.par のようなパラメータファイルの中身も、メッシュ単位で補正量を持っています。

3段階の入れ子構造

標準地域メッシュは、第1次から第3次までの入れ子で定義されています。

区分	桁数	緯度差	経度差	1辺の長さ（目安）
第1次メッシュ	4桁	40分	1度	約80km
第2次メッシュ	6桁	5分	7分30秒	約10km
第3次メッシュ	8桁	30秒	45秒	約1km

第1次メッシュは、20万分の1地勢図の1図葉にあたる区画です。これを緯線・経線方向に8等分したのが第2次メッシュ、さらに10等分したのが第3次メッシュ（いわゆる「1kmメッシュ」）になります。

緯度差と経度差の比が 40分 : 1度 = 2 : 3 になっている点がポイントです。日本の緯度帯では緯度1度あたりの距離のほうが経度1度あたりより長いので、この比にすることでおおむね正方形に近い区画になります。

第1次メッシュ（4桁）— 1.5倍がすべて

第1次メッシュコードの作り方は、拍子抜けするほど単純です。

上2桁 ＝緯度（度）× 1.5 の整数部
下2桁 ＝経度（度）の下2桁（つまり経度 − 100 の整数部）

緯度を1.5倍するのは、1区画が緯度40分＝2/3度だからです。緯度 ÷ (2/3) = 緯度 × 1.5 で「何区画目か」が出てきます。

経度側は1区画がちょうど1度なので、整数部をそのまま使えます。日本は東経100度台に収まるので、上の桁を落として2桁で足ります。

例：東京駅付近（北緯 35.6812 度／東経 139.7671 度）

緯度: 35.6812 × 1.5 = 53.5218  →  53
経度: 139.7671 の下2桁         →  39
第1次メッシュ = 5339

第2次メッシュ（6桁）— 8等分の余りを見る

第1次メッシュの南西端からの「はみ出し分」を、緯度は5分刻み、経度は7分30秒刻みで数えます。

緯度の余り: 35.6812 − 53 ÷ 1.5 (= 35.33333) = 0.34787 度 = 20.872 分
            20.872 ÷ 5 = 4.174  →  4

経度の余り: 139.7671 − 139 = 0.7671 度 = 46.026 分
            46.026 ÷ 7.5 = 6.137  →  6

第2次メッシュ = 5339-46 → 533946

5桁目が緯度方向、6桁目が経度方向のインデックス（0〜7）です。

第3次メッシュ（8桁）— さらに10等分

同じ要領で、緯度は30秒刻み、経度は45秒刻みで数えます。

緯度の余り: 20.872 − 4×5 = 0.872 分 = 52.3 秒
            52.3 ÷ 30 = 1.74  →  1

経度の余り: 46.026 − 6×7.5 = 1.026 分 = 61.6 秒
            61.6 ÷ 45 = 1.37  →  1

第3次メッシュ = 533946-11 → 53394611

7桁目が緯度方向、8桁目が経度方向のインデックス（0〜9）です。東京駅周辺の1kmメッシュは 53394611。統計データを扱ったことがあれば、見覚えのある番号だと思います。

座標変換の流れ

コードで書くとこうなる

def to_mesh_code(lat, lon):
    """十進度の緯度経度から第3次メッシュコード（8桁）を返す"""
    # 第1次
    p = int(lat * 1.5)                 # 緯度側 2桁
    u = int(lon) - 100                 # 経度側 2桁

    # 第2次（第1次の南西端からの余りを 8 等分）
    lat_rem = lat * 60 - p * 40        # 分
    lon_rem = (lon - 100 - u) * 60     # 分
    q = int(lat_rem / 5)
    v = int(lon_rem / 7.5)

    # 第3次（第2次の南西端からの余りを 10 等分）
    lat_rem2 = lat_rem - q * 5         # 分
    lon_rem2 = lon_rem - v * 7.5       # 分
    r = int(lat_rem2 * 60 / 30)
    w = int(lon_rem2 * 60 / 45)

    return f"{p:02d}{u:02d}{q}{v}{r}{w}"


def from_mesh_code(code):
    """第3次メッシュコードから南西端の緯度経度を返す"""
    p, u = int(code[0:2]), int(code[2:4])
    q, v = int(code[4]), int(code[5])
    r, w = int(code[6]), int(code[7])
    lat = p / 1.5 + q * 5 / 60 + r * 30 / 3600
    lon = 100 + u + v * 7.5 / 60 + w * 45 / 3600
    return lat, lon

逆算で返るのはメッシュの南西端の座標です。中心が欲しい場合は、第3次メッシュなら緯度に15秒、経度に22.5秒を足します。この「南西端が代表点」という約束は、グリッド補間の実装 — バイリニア内挿の中身で扱った格子の考え方と同じ発想です。

いちばん怖い落とし穴：メッシュは測地系に依存する

ここが実務で効いてくる話です。

メッシュコードは緯度経度から機械的に決まるので、どの測地系の緯度経度を入れたかでコードが変わりえます。旧日本測地系（Tokyo Datum）と世界測地系では、同じ場所の緯度経度が約400mずれます。第3次メッシュは1辺約1kmですから、境界付近では隣のメッシュに落ちます。

つまり、

同じ 53394611 でも、旧日本測地系基準のメッシュと世界測地系基準のメッシュは、地上では最大で半メッシュ近くずれた別の四角形を指している。

古い統計データや古いGISデータのメッシュを現在のデータと重ねるときは、どちらの測地系で切られたメッシュかを必ず確認してください。混ぜてしまうと、「隣の町の人口が乗っている」ような静かな事故になります。

測地系が明示されていないデータの見分け方は測地系が書いていない座標データの見分け方にまとめています。

CSVの入出力

もっと細かいメッシュ

第3次メッシュより細かい区画は、分割回数を桁で表します。

通称	桁数	1辺	作り方
2分の1地域メッシュ	9桁	約500m	第3次を2×2に分割（1〜4）
4分の1地域メッシュ	10桁	約250m	さらに2×2に分割
8分の1地域メッシュ	11桁	約125m	さらに2×2に分割

分割番号は南西=1、南東=2、北西=3、北東=4 の並びです。標高データやハザードデータでは、この500m・250mメッシュがよく使われます。

なお、Webの地図タイルで使われるXYZタイルは、Webメルカトル図法上の正方形をズームレベルで再帰分割したもので、地域メッシュとはまったく別系統です。混同しないよう、地理院タイルのしくみ（GeoPrism JP）と読み比べておくと整理しやすいと思います。

GeoConverterPro との関係

GeoConverterPro が内蔵する補正パラメータ（TKY2JGD／PatchJGD／セミダイナミック補正／POS2JGD）は、いずれもメッシュ単位で補正量を持つ格子データです。アプリはユーザーが入力した緯度経度からメッシュを特定し、周囲4点の補正量をバイリニア内挿して1点分の補正量を求めています。

「4隅がそろわない地点で結果が変わる」という話（CCQ＝座標変換クオリティー）も、この格子の構造から出てきています。メッシュの仕組みを知っておくと、変換結果の信頼度を自分で見積もれるようになります。

GeoConverterPro の画面