みちびき（準天頂衛星システム）の災害・危機管理通報サービス＋UNO Q

2024年12月に下記の制作記事を掲載し、災害・危機管理通報サービスの情報の受信を継続していたが、最近、テスト配信された情報の内容が変わったように感じたので調査してみた。また、台風の位置などが緯度・経度でしか表示されず、その位置を把握しずらいという問題点があったので、その問題点を解決できるシステムを検討した。

システムの概要、サービスで配信されている情報の内容については、下記公式サイト、または、下記記事を参照してください。

公式サイト：みちびき（準天頂衛星システム：QZSS）

（注）本記事の内容は正確性を保証するものではない。

（2026年2月6日 追記）YouTube動画を追加しました。　https://youtu.be/C-uNQ4S1AAE

---

システムの配信情報の現状

最近受信した情報は下図の通りで、DCレポートとして、現時点で実際に発生している台風の情報などが配信され、DCXメッセージでは、テスト情報として台風の情報（2月3日配信情報）などが配信されている（テストではない本番の情報も配信されている）。
DCXメッセージには、「避難行動」、「楕円情報」、「追加対象地域」という項目が含まれているが、これらの項目は以前には無かったように思った。正しくは、項目はあったのかもしれないが、その内容に初めて気が付いたということかもしれない。今回は、その項目について調べてみた。また、現状の通報情報の有用性、システムの現状・予定などもあらためて調べてみた。

PCのブラウザに表示した受信情報画面

DCXメッセージの例

緯度・経度と対象地域と追加対象地域とは何か、その関係は？

ChatGPT 5.2 Thinkingの回答

添付PDFに出てくる「台風情報」の中で、

• 緯度・経度（北緯○度○分、東経○度○分…）
• 対象地域（自治体名）
• 追加対象地域（別の範囲）

が同時に見えているのは、実は “同じ台風情報でも、系統が違う情報” が混在しているためです。
PDF内には少なくとも次の2種類の「台風」が載っています。

（追記）２種類の台風とは、DCレポートに記載された台風（実際に発生している台風２号）と、
DCXレポート（テスト）に記載された台風（テストデータ）のこと。

1) 災危通報(台風)の「緯度・経度」は何の位置か

PDFの「災危通報(台風)(発表)」は、台風2号について

• 発表時刻
• 基点時刻（予報）と「12時間後/24時間後/45時間後」
• 緯度・経度
• 中心気圧、最大風速…

という形で複数行が並んでいます。

この 緯度・経度は“その時刻（○時間後）における台風の中心位置（予報点）” を表します。
たとえば「24時間後」の予報点として緯度・経度が出ている、という読み方になります。

重要：この形式（災危通報(台風)）自体には、あなたが言う「対象地域／追加対象地域」は出ていません。ここでの緯度・経度は“台風そのものの位置”です。

2) 自治体送信情報(テスト)（DCX）の「対象地域／追加対象地域」は何か

PDFには別枠として「DCXメッセージ（最新10件）」があり、その中に

• 災害カテゴリ種別：気象 – 熱帯低気圧（台風）
• 避難行動（例：留まれ…）
• 楕円情報（中心緯度・中心経度・長軸半径・短軸半径・方位角）
• 対象地域：自治体名
• 追加対象地域（もう一つの楕円情報つき）

という形式のメッセージがあります。

ここでのポイントは：

• 楕円情報（中心緯度・中心経度…）＝“警戒・行動を促す地理的な範囲（ジオフェンス）”
• 対象地域（自治体名）＝その範囲に対応づけられた行政区域の説明（人間向けのラベル）
• 追加対象地域＝追加で指定される別の範囲（多くは避難先/退避先など、行動文とセットで扱う）

です。

実際、PDFには「避難行動：追加対象地域に向かってください。」のように、追加対象地域が“行動の行き先”として書かれている例があります。

※台風以外（洪水）でも同じ構造（楕円＋対象地域＋追加対象地域）が出ています。

3) これらの情報の「関係」

まとめると、関係はこうです。

A. 「災危通報(台風)」の緯度・経度（DCレポートに記載された台風の情報）

• 台風の中心位置（予報点）を表す
• 時刻（○時間後）ごとに複数出ることがある

B. 「自治体送信情報（台風カテゴリ）」の中心緯度・中心経度（楕円）
　　（DCXメッセージに記載された台風の情報）

• “危険が及ぶ／行動を促す対象エリア”の中心
• 台風の中心位置そのものとは限らない（自治体が定義する警戒・避難エリア）

C. 対象地域と追加対象地域

• 対象地域：主に「今いる人が該当する（警戒・避難が必要な）エリア」
• 追加対象地域：主に「向かう先」「退避すべき先（または退避すべき元）」など、行動文とセットの“追加エリア”
  • 例：追加対象地域へ向かう
  • 例：追加対象地域から退避（別メッセージ例）

実務的にどう扱うのが良いか

• 台風の進路表示・接近判定をしたい → 「災危通報(台風)」の緯度・経度（予報点）を使う
• 自宅が警戒対象に入るか（ジオフェンス通知）をしたい → DCX側の「楕円情報＋対象地域／追加対象地域」を使う

みちびきの災害・危機管理有報サービスの活用要領・有用性

2024年12月からこのサービスの受信を継続してきたが、長雨情報など、正常に配信される場合もあったが、自宅で感じた地震情報など、配信されない場合もあった。情報配信の速報性は期待できないことは分かっていたが、どのような基準で情報が配信されるかも理解できていない状況では、本当に役に立つシステムなのかと考えてしまう。
また、海上の強風情報など、その情報が必要なユーザーがかなり限定されているので、現在でも、これらの情報は有用なのかをあらためて確認してみた。

ChatGPT 5.2 Thinkingの回答

添付のPDFを見る限り、これは準天頂衛星「みちびき」経由で配信される災害・危機管理通報（DCレポート）や、より詳細な自治体送信情報（DCXメッセージ）を受信して一覧表示したログですね。
結論から言うと、条件が合えばかなり有用です。ただし「いつでも誰にでも万能」ではなく、得意な場面がはっきりしているタイプの情報です。

どんな情報が入っていて、どう活用できるか

1) 通信障害時の“最後の受け皿”として

この種の衛星配信は、携帯基地局やインターネットが不安定なときでも届く可能性があるのが強みです。
災害時に「回線が混んで情報が取れない」状況の補助情報として価値があります。

2) 海上・沿岸の安全管理（特に相性が良い）

PDFには海上濃霧・強風/暴風・着氷などの海上警報がまとまって出ています。
船舶・釣行・沿岸作業・港湾関係だと、行動判断に直結します（出港可否、帰港判断、装備強化など）。

3) 台風の予報ポイントを“機械が扱える形”で受け取れる

「台風○号、基点時刻○時間後、緯度経度、中心気圧、風速」みたいに構造化されています。
これは人が読むだけでなく、たとえば：

• 予報位置が一定距離内に入ったら通知
• 風速や気圧が閾値を超えたら備えのチェックリストを自動表示
• ログ化して「過去の台風接近時に何日前から何が出たか」を分析

といった“自動化”に向きます。

4) 自治体発の「対象地域＋避難行動」が出せる（DCX）

DCXの例では、対象地域（例：与那国町、堺市、八王子市など）と、重大度、継続時間、そして「避難行動」文言、さらに楕円（中心緯度経度＋半径など）で範囲が付いています。
これが本番運用で届く環境なら、

• 自宅座標が範囲内 → スマホ/ブザー/家の表示器で即通知
• 範囲外 → 通知抑制（不要な警報疲れを防ぐ）
• 家族の居場所（学校/職場）別に通知ルールを分ける

みたいな実装ができます。

「有用か？」への答え（メリット・注意点）

有用な理由

• 回線混雑や障害に強い可能性
• 情報が比較的構造化されていて自動処理しやすい
• 海上警報や台風など、行動に直結するカテゴリがある

注意点（ここを押さえると“使える情報”になる）

• テスト配信が混ざる：PDFにも「自治体送信情報(テスト)」が複数あります。
  → 実運用では「テスト/訓練/本番」を判定して通知の出し分けが必須。
• 公式発表の一次情報（気象庁や自治体の発表）と照合する運用が安全
  → 衛星側の表示は“速報・補助”と考え、最終判断は一次情報で。
• 受信環境に依存：屋内・アンテナ条件・受信機/デコーダ実装で取りこぼしが出ます
  → 重要用途なら「受信できている監視（死活監視）」もセットが安心。

いちばん現実的なおすすめ活用（家庭/個人）

PDFのようなログを活かすなら、次が効果が出やすいです。

1. “回線が落ちた時のバックアップ通知”（停電・荒天時用）
2. 海上警報/台風だけを抽出して通知（ノイズを減らす）
3. 対象地域（楕円）×自宅座標でフィルタ（本当に関係ある時だけ鳴らす）
4. 発表時刻と内容を保存して振り返り（備えの改善に使える）

---

ChatGPT 5.2 Thinkingの回答

できます。簡単なプログラムで判定可能です。ポイントは、DCXメッセージに書かれている「対象地域」の形が何かで、判定方法が変わります。

1) いちばん簡単：円（中心＋半径）なら一発

対象地域が「中心緯度・経度」と「半径（km）」で表されているなら、

• 自宅座標（lat, lon）
• 円の中心（clat, clon）
• 2点間距離 d（km）

を計算して、d ≤ 半径なら「含まれる」です。

Python例（ハバーサイン）

import math

def haversine_km(lat1, lon1, lat2, lon2):
    R = 6371.0
    phi1, phi2 = map(math.radians, (lat1, 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

def inside_circle(home_lat, home_lon, center_lat, center_lon, radius_km):
    return haversine_km(home_lat, home_lon, center_lat, center_lon) <= radius_km

# 例
print(inside_circle(34.23, 135.17, 34.20, 135.20, 10.0))  # True/False

2) よくある：楕円（中心＋長短半径＋回転）でも“割と簡単”

DCXの対象範囲が「楕円（中心、長半径a、短半径b、回転角θ）」で来る場合もあります。
この場合は、まず自宅を中心から見た相対座標 (x, y)（km）に変換し、回転を戻してから

なら「含まれる」です。

ざっくり判定（地球を局所平面近似）

対象範囲が数十km〜100km程度なら、下の近似で十分役に立ちます（※超広域や高精度が必要なら後述）。

import math

def inside_ellipse(home_lat, home_lon, center_lat, center_lon,
                   a_km, b_km, theta_deg):
    # 局所平面近似：緯度経度差→km（中心緯度で補正）
    lat0 = math.radians(center_lat)
    km_per_deg_lat = 111.32
    km_per_deg_lon = 111.32 * math.cos(lat0)

    dx = (home_lon - center_lon) * km_per_deg_lon  # 東が+
    dy = (home_lat - center_lat) * km_per_deg_lat  # 北が+

    # 楕円の回転（thetaは「北から時計回り」を想定）
    th = math.radians(theta_deg)
    # 回転を戻す（-theta）
    x =  dx * math.cos(th) + dy * math.sin(th)
    y = -dx * math.sin(th) + dy * math.cos(th)

    v = (x/a_km)**2 + (y/b_km)**2
    return v <= 1.0

# 例
print(inside_ellipse(34.23, 135.17, 34.20, 135.20, 15.0, 8.0, 30.0))

3) もっと正確にやりたい場合（おすすめ）

「対象地域」が多角形だったり、楕円でも大きく広域だったり、厳密な測地線距離で判定したいなら、ライブラリを使うのが安全です。

• 多角形：shapely（点がポリゴンに含まれるか）
• 測地線：geographiclib や pyproj.Geod（距離・方位を正確に）

ただし、円 or 楕円（中心・半径類が揃っている）なら、上の短いコードで実用レベルにできます。

実装のコツ

• DCXに「テスト/訓練」が混ざることがあるので、判定前に種別でフィルタすると通知がうるさくなりません。
• 半径の単位（m/km）と、回転角の定義（北基準で時計回り等）だけは、メッセージ仕様に合わせてください
  （ここがズレると当たり外れします）。

---

ChatGPT 5.2 Thinkingの回答

できます。実現方法は大きく 2系統（既製アプリで即実用 / 自作で優先度まで厳密に制御） に分けて考えるのが現実的です。
ご要望の「津波＞洪水＞地震＞台風（※この優先度順）」でスマホ表示を統制したいなら、自作（小さなサーバ＋Push通知）がいちばん確実です。

方式A：既製アプリで“すぐ”運用（最短）

何ができる

• 地域を設定して、地震・津波・豪雨などの通知を受ける（現在地連動も可）
  例：Yahoo!防災速報は通知対象地域の設定や現在地連動が可能 (Yahoo! JAPAN)

できない／難しい

• 「津波→洪水→地震→台風」の優先順位で通知表示を制御（アプリ側の仕様次第で固定になりがち）
• 通知の統合（複数アプリの通知を1本化）や、同一事象の重複排除（地震速報＋自治体避難など）

➡️ まず試すには最適。ただし「優先度制御」を本気でやるなら方式Bへ。

方式B：優先度どおりに“自分で”制御（おすすめ）

「みちびき（QZSS）のDCX/DCレポート」＋「気象庁の防災情報XML」などを取り込んで、自宅が対象地域に入ったときだけ、優先度順にスマホへPush通知します。

全体構成（シンプル版）

1. 受信
   • (B1) みちびき：DCレポート / DCXを受信してデータ化
     • DCXの仕様書改版のお知らせ等が公開されています (みちびき（準天頂衛星システム）)
     • 受信の具体例（L1S受信設定など）の解説もあります (スイッチサイエンス)
   • (B2) 公式網：気象庁 防災情報XML（津波・地震・台風・洪水関連）を取得
     • 気象庁のXML仕様ページは継続更新されています (xml.kishou.go.jp)
2. 判定
   • メッセージ種別を「津波・洪水・地震・台風」に正規化
   • 対象範囲（円/楕円/多角形など）に 自宅座標が入るかを判定
   • 事象IDや発表時刻で重複をまとめる
3. 優先度ルールでキュー制御
   • 優先度：津波(最上位) ＞ 洪水 ＞ 地震 ＞ 台風
   • 例えば「同時に複数が来たら高優先だけ通知」「低優先はサイレントで履歴だけ」など
4. スマホへ通知
   • iOS/Android：Push通知（Firebase/APNs）
   • もっと簡単に：自分用のLINE通知（Messaging API）やPushover等でも可

優先度制御の“具体ルール”例

通知レベル（表示の強さ）も決めると実運用で迷いません。

• 津波：常に即時通知（音＋最前面）／繰り返し（更新が来たら上書き）
• 洪水：自宅が浸水想定エリアに入る or 警戒レベル高いとき即時
• 地震：緊急地震速報は即時、震度情報は履歴中心
• 台風：接近（距離/予報円/暴風域）で段階通知（例：48h/24h/12h）

※「みちびき側の通報区分（最優先/優先など）」も存在しますが (みちびき（準天頂衛星システム）)、今回はユーザー指定の優先度で上書きする設計が分かりやすいです。

実装の最小構成（費用と手間が少ない）

1) 自宅に常時動く小型機（Raspberry Pi等）＋通知

• Piが受信・判定して、スマホへPush/LINE通知
• メリット：家の“防災ハブ”として安定、停電対策もしやすい（UPS等）

2) 受信はクラウド／判定だけローカル

• 気象庁XML等はクラウド取得でOK
• みちびきDCX/DCレポートは 受信機が必要（L1S受信）。
  受信機→スマホ直は難しいので、受信機→自宅ハブ→通知が現実的。

重要な注意点（運用でハマりやすい）

• テスト配信が混ざる：DCXには試験データ配信ページもあります (みちびき（準天頂衛星システム）)
  → 本番通知から除外する条件が必須
• 「洪水」の定義を揃える：洪水（河川）・浸水害（内水）・大雨特別警報など、カテゴリ整理が必要
• iPhoneで“勝手に最前面表示”は制限が多い：通知の種類（緊急速報/通常Push）で挙動が変わるため、現実的には「音・バナー・繰り返し・重要通知」設定で運用

次に、あなた向けに設計を確定するための“最低限”の前提

確認なしでも案は出せますが、精度が跳ねます。以下のどれに近いですか？

• (1) 既製アプリでできる範囲でOK（優先度は妥協）
• (2) 自作したい（受信機あり/これから）
• (3) みちびきは補助で、主に気象庁XML＋自治体情報でやりたい

もし「自作したい（2）」なら、次の返信で

• 居住市町村（例：○○市）
• 使うスマホ（iPhone/Android）
• 家に常時動かせる機器（NAS / Raspberry Pi / PC など）
  だけ教えてください。そこから実装パターン（最小構成）＋通知ルール表＋データ取り込み先の具体案まで落として提案します。

---

通知システム検討

以前の記事で制作した受信機器では、警報の対象位置が緯度・経度で表現されており、その対象位置の地名などは表示されていなかった。また、楕円情報などで表示される、警報の対象地域に自宅が含まれるかが分かりにくいという問題点があったので、それらの問題を解決するために、Arduino UNO Qを追加した構成（通知システム）を検討する。

ChatGPT 5.2 Thinkingの回答

Arduino UNO Q（Linux側）に

• 対象地域（楕円など）に自宅が入るかの判定
• 緯度・経度 → 地域名称（市町村名など）への変換（逆ジオコーディング）

をやらせることは現実的です。
ただし、実装のコツは「UNO Qに渡すデータの形」と「地域名変換をオフラインでやるか／オンラインを許すか」です。

1) 全体アーキテクチャ（パターン2を維持して拡張）

現状

• 受信ボード：DCX/DC Reportを受信・デコードし、Web表示
• UNO Q：表示器・ブザー（重要イベントだけ受けて警報）

（補足）表示器は、UNO Qに実装されているLEDマトリックス、ブザーはGPIO経由で増設

拡張後（おすすめ）

• 受信ボード → UNO Q：「重要イベントだけ」ではなく、“判定に必要な最小フィールド”も送る
• UNO Q（Linux/Python側）：
  1. イベント正規化（津波/洪水/地震/台風など）
  2. 自宅が対象範囲に入るか判定（楕円/円/ポリゴン）
  3. 必要なら緯度・経度→地域名変換
  4. ブザー/OLED/Web画面（UNO Q側ダッシュボード）へ出力

重要：受信ボードの「解釈結果」をUNO Qへ投げるより、受信ボード→UNO Qへ“生のパラメータ”を渡し、判定はUNO Qで統一すると後々ラクです。

2) 受信ボード → UNO Q に送るべき最小データ

A. DCX（対象範囲が楕円で来るタイプ）

UNO Q側で「自宅が範囲内か」を判定するには、最低これが要ります。

• event_type（例：rain/flood/typhoon/evac…）
• issued_at（発表時刻）
• severity（重大度/レベルがあれば）
• area_shape（楕円なら）
  • center_lat, center_lon
  • major_km, minor_km
  • angle_deg（方位角）
• area_text（対象地域の文字列があるならそのまま）
• extra_area_shape（追加対象地域があるなら同様に）

受信ボード側で“楕円情報”を既に表示できているなら、それをそのままUNO Qへ渡せます。

B. DC Report（台風の予報点が緯度・経度で来るタイプ）

• typhoon_id
• forecast_points[]（時刻/緯度/経度/気圧/風など）
• 可能なら radius（強風域/暴風域が取れるなら）
  ※無い場合は「距離閾値」で段階判定します。

3) UNO Qで「自宅が対象地域に入るか」判定は可能か？

可能です。計算は軽く、UNO Q（Linux側）なら余裕があります。

判定方法（代表）

• 円（中心＋半径）：2点間距離 ≤ 半径
• 楕円（中心＋長短半径＋角度）：ローカル平面に落として楕円不等式で判定
• ポリゴン：点が多角形の内側か（レイキャスティング）

あなたのPDFに出ていた「楕円情報」前提なら、楕円判定が最短・安定です。
（中心からの相対座標を回転して (x/a)^2+(y/b)^2<=1）

実務のコツ

• 自宅座標（那覇市の自宅位置）をUNO Qに固定値として設定（config.jsonなど）
• 受信ごとに「対象地域」「追加対象地域」それぞれを判定
  • 例：「対象地域＝警戒区域」「追加対象地域＝避難先」など、表示/警報の意味を分けられる

4) UNO Qで「緯度・経度 → 地域名称」変換は可能か？

可能です。ただし選択肢が2つあります。

方式1：オフライン（ネット不要、強い）

UNO Q内に 行政区域境界データ（市町村ポリゴン）を持たせて、

• 入力：緯度・経度
• 出力：那覇市／沖縄県…のような地域名

を自前で求めます。

メリット

• ネット不要（災害時に強い）
• “どの範囲に入ったか”の判定と整合する

デメリット

• 境界データ（GeoJSON等）がやや重い
  → 対策：沖縄県だけに絞る／メッシュで索引を作る／簡略化データを使う

現実的な最小

• 「沖縄県内の市町村」だけをUNO Qに入れる
• まずは 那覇市かどうかだけ判定できれば目的達成（全部の市町村名は後回しでもOK）

方式2：オンライン逆ジオコーディング（実装が楽）

UNO Qから外部APIへ問い合わせて住所/市町村名を返してもらう方式です。

メリット

• 実装が最短、データ管理不要
  デメリット
• ネットが無いと動かない
• API制限・利用規約・レート制限がある

あなたの「ローカル完結寄り」という方針なら、方式1（オフライン）を基本にして、平常時だけ方式2を補助として使うのが一番事故りにくいです。

5) 「重要イベントだけ送る」思想を保ったまま、判定をUNO Qに寄せるには？

おすすめは、受信ボード側はこう割り切ることです。

受信ボード（送る側）

• 「重要イベントかどうか」を粗く判定（津波/避難/洪水警戒など）
• そのイベントについて、UNO Qが判定できるだけの 範囲パラメータと座標を送る
  （つまり“重要だけ送る”は維持しつつ、内容は薄くしない）

UNO Q（判定する側）

• 自宅含有判定（対象地域・追加対象地域）
• 表示文生成（例：「自宅が対象地域内」「避難先候補：追加対象地域」）
• ブザー/OLED/Web表示の最終決定（優先度・抑制もここ）

6) 具体的な最小構成案（追加機器なし）

通信方式（おすすめ順）

1. UDP（LAN内）：軽い・速い・実装簡単
2. UART：最も確実（ネット不要）が配線必要
3. MQTT：拡張性は最高だがブローカが要る（UNO Qがブローカでも可）

データ形式

• JSON 1行（1イベント＝1行）にすると扱いやすいです
  • 受信ボード：イベント発生時に送信
  • UNO Q：受信して即判定、ログ保存

7) ここまでを那覇市運用に落とした「UNO Q側ルール」例

• 津波：自宅が対象地域内 → 即ブザー（強）＋OLED最優先表示
• 洪水/大雨：自宅が対象地域内 → ブザー（中）
• 地震：沖縄で一定震度以上 → ブザー（中）
• 台風：予報点が那覇から距離◯km以内 → 段階表示（ブザーは抑制）

次にやると一気に形になること（おすすめ）

あなたの受信ボードのWeb表示が既にあるので、まずは

1. 受信ボード側に「UNO Qへイベントを送る」処理を追加（UDPでOK）
2. UNO Q側に「受信→楕円判定→表示/ブザー」常駐スクリプト追加
3. 余裕が出たら「オフライン市町村境界データ」で地域名変換を追加

この順が最短です。

もし、受信ボード側からUNO Qへ送れる情報が「楕円パラメータまで出せる」のか、「対象地域文字列しか出せない」のかで設計が変わります。
受信ボードがUNO Qへ送れる項目（いま取れているフィールド）を、箇条書きでそのまま貼ってください。
貼ってもらった内容だけで、UNO Q側の判定ロジックとデータ形式（JSON例）を決め打ちで作ります。

---

ChatGPT 5.2 Thinkingの回答

だいたい分かります。まず「どのデータ源・形式か」で桁が変わりますが、“市町村ポリゴン（行政区域）”として現実的に使われる代表例だと、次のサイズ感です。

国土交通省 国土数値情報「行政区域データ（N03）」のファイル容量（公式に明記あり）

これは「都道府県／市区町村の境界ポリゴン」を含む代表的なオープンデータで、全国・地方別のZIP容量がページに明記されています。

• 全国（令和5年）：427MB（GML.zip） (国土数値情報)
• 地方ブロック（令和5年）（例）
  • 北海道：41.5MB (国土数値情報)
  • 東北：75.0MB (国土数値情報)
  • 関東：39.6MB (国土数値情報)
  • 甲信越・北陸：39.6MB (国土数値情報)
  • 東海：40.6MB (国土数値情報)
  • 近畿：30.3MB (国土数値情報)
  • 中国：33.7MB (国土数値情報)
  • 四国：34.2MB (国土数値情報)
  • 九州：82.3MB (国土数値情報)
  • 沖縄：15.3MB (国土数値情報)

重要な注意（サイズの見え方）
上の数値は「圧縮ZIP（GML）」の容量です。実運用では、

• 解凍後（GML）
• GeoJSONへ変換
• さらにポリゴンの簡略化（simplify）や、必要な地域だけ抽出
  …でサイズが大きく変わります（一般に、GeoJSONはテキストなので大きくなりがち）。

あなたの用途（那覇市周辺の逆ジオコーディング/所属判定）なら、沖縄県だけ（15.3MB）を素材にして、UNO Qへ載せる前に「那覇市＋周辺市町村だけ抽出」「簡略化」すれば、かなり軽くできます。 (国土数値情報)

Geofabrik / OpenStreetMap のサイズ感（参考）

OSMは行政界“だけ”ではなく道路やPOIなど全部入りなので、同列比較はできませんが、規模感の参考になります。

• 日本のOSM抽出（PBF）：2.2GB (Geofabrik Download Server)
• 地方別のPBFも数百MB規模（例：関東 434MB、近畿 322MB など） (Geofabrik Download Server)

行政界だけを取り出して使うこともできますが、UNO Qで「市町村所属判定」をしたいだけなら、OSMより 国土数値情報N03（目的に直球）の方が作業量が少ないことが多いです。

e-Stat（政府統計の総合窓口） の境界データ（補足）

e-Stat側も境界データ（Shape/KML/GML）を提供していますが、少なくとも今回参照したヘルプページではファイル容量の一覧が前面には出ていません（選択する地域・レイヤで大きく変わります）。提供形式の説明はあります。 (e-Stat)
サイズを“確定値”で言うなら、上のN03のように「一覧で容量が明記されている」データが確実です。

まとめ：ざっくりの目安（UNO Qで扱う前提）

• 全国の市町村ポリゴンを丸ごと：最低でも 数百MB（圧縮）、加工後はさらに増える可能性
• 都道府県単位：多くは 数MB〜数十MB（圧縮）（沖縄は 15.3MB） (国土数値情報)
• UNO Qでの現実解：
  1. 沖縄県だけ取得 → 2) 那覇市周辺だけ抽出 → 3) ポリゴン簡略化 → 4) “点がどの市町村に入るか”をローカル判定
     が一番軽くて堅いです。

必要なら、次は「UNO Qに載せる用」に、

• N03（沖縄県）から 那覇市＋周辺だけを抜いて軽量化する手順（PCで前処理）
• UNO Q側での 点-in-ポリゴン判定の高速化（簡易インデックス：BBox→候補絞り込み）
  を、最小構成で提案します。

制作済みの受信機器にUNO Qを付加して通知システムを構築する方法の概略を検討することができた。
UNO Qを使えば、記憶容量にも余裕があり、プログラムもLinux環境を利用でき、GPIOでのブザーなどの拡張性があり、Raspberry Piよりも省電力そうなので、災害時のポータブル電源での運用に適していると思われる。

災害時、避難場所などに設置される専用装置もあり、災害・危機管理通報サービスは専用装置での活用を前提にしたものだが、設置場所・設置数が限定されるので、今回の通知システムが自宅での情報収集に役立つかどうかを検証していきたい。

災危通報のシステムの現状・今後の予定

最後に、災害・危機管理通報サービスの現状と、現時点での予定を調査したので紹介する。

ChatGPT 5.2 Thinkingの回答

以下は、準天頂衛星「みちびき」の災害・危機管理通報（災危通報）まわりについて、2026年2月5日（JST）時点で確認できる「現状」と「今後」を、一次情報中心に整理したものです。

1) 現状：いま何が運用されているか

DC Report（基本の災危通報）

• 気象庁の防災気象情報に基づく災害情報を、衛星信号（L1S）で配信するサービスとして位置づけられています。
  (みちびき（準天頂衛星システム）)
• 想定利用先として、屋外サイネージ・街灯・車載機（カーナビ等）など“受信して表示する端末”が挙げられています。
  (みちびき（準天頂衛星システム）)

DCX（災危通報の拡張）

• DCXは、基本（DC Report）に加えて JアラートとLアラート（避難情報）、さらにアジア太平洋向け災害情報を追加で配信する枠組みです。(みちびき（準天頂衛星システム）)
• このうち Jアラート／Lアラート配信は 2024年4月1日にサービス開始しています。(みちびき（準天頂衛星システム）)
• DCXは L1S信号を使い、メッセージタイプ44、フォーマットは共通EWSメッセージフォーマットを採用、とされています。(みちびき（準天頂衛星システム）)

「緊急情報を優先配信」する機能が“本運用”に

• DCXで、緊急性の高い情報を優先配信する仕組みが 2025年7月1日から本運用開始と告知されています。
  (みちびき（準天頂衛星システム）)
  • これ、まさに「津波・洪水・地震・台風などを優先度つけてスマホに出したい」ニーズと相性が良い考え方です
    （ただし、端末側の実装で“どう扱うか”は別問題）。

2) 最新の仕様・開発者向け情報（何を見れば追えるか）

仕様書更新（DCR / DCX）

• DC Report（DCR）のユーザインタフェース仕様（IS-QZSS-DCR）は 2025年9月25日に第15版が告知されています。
  (みちびき（準天頂衛星システム）)
• DCXの仕様書は IS-QZSS-DCX-003に改版（2025年4月1日告知）。(みちびき（準天頂衛星システム）)
• さらに英語の仕様一覧ページ側で、2025年11月13日に「図表等が判読しづらい」ため改訂があった旨が明記されています。(みちびき（準天頂衛星システム）)
• 免責（重要）：サービスは無償公開だが保証はなく、生命・財産に関わる用途は冗長化等が必須、などの注意が明確に書かれています。(みちびき（準天頂衛星システム）)

試験用データ配信（受信機/アプリ開発の検証に使える）

• 災危通報の試験用データを月2回定期配信している公式ページがあり、直近では 2026年2月10日/2月26日の予定が示されています。(みちびき（準天頂衛星システム）)
  • 受信・デコード・表示までの一連の動作確認に使えるので、「まず簡単に作ってみたい」段階ではかなり有用です。

3) 今後の予定：海外向け（アジア太平洋）や拡張の方向性

海外（アジア太平洋）向け災害情報配信

• DCXのうち、アジア太平洋向け災害情報配信は“2025年度に開始予定”と、公式が明記しています。
  (みちびき（準天頂衛星システム）)
• 2025年の内閣府資料でも、アジア大洋州でのユーザ獲得に向けて 海外向けEWSS（災危通報）整備を進める文脈が確認できます。(内閣府ホームページ)
• 実証面では、フィジー等でDCXを含む受信システムを構築して受信確認した事例が掲載されています
  （海外展開の実務が動いていることが分かる材料）。(みちびき（準天頂衛星システム）)

※「2025年度開始予定」が“実際に開始したかどうか”は、上記ソースだけでは断定できません
（開始告知が別ページにある可能性があります）。

4) 衛星打上げ計画の最新動向（サービス継続性に影響）

災危通報そのものは、衛星コンステレーション全体の運用状況の影響を受けます。

• 2025年12月：H3ロケット8号機の打上げ失敗により「みちびき5号機」は喪失したと考えられる、とJAXAからの報告を受けた旨が、内閣府サイトに掲載されています。(みちびき（準天頂衛星システム）)
• 同談話内で、「7号機を可能な限り早期に打上げ」「7機体制の早期実現」「11機体制も視野」といった方針も述べられています。(みちびき（準天頂衛星システム）)
• しかし 2026年2月5日：7号機は“2026年3月31日までの打上げは実施しない”、新予定日は決まり次第告知とされています。(みちびき（準天頂衛星システム）)

→ つまり、拡張や体制強化は進めたいが、ロケット側の事情もあってスケジュールは流動的、というのが“いまの最新像”です。

5) あなたの用途（優先度つきでスマホ表示）に効いてくる“最新トピック”

今回あなたが狙っている「津波・洪水・地震・台風を優先度順にスマホへ」という要件に直結しやすいのは次の2つです。

1. DCXの“緊急情報の優先配信”が本運用開始（2025/7/1）(みちびき（準天頂衛星システム）)
2. 試験データの定期配信（受信～判定～通知の実装テストに使える）(みちびき（準天頂衛星システム）)

必要なら、次のステップとして

• あなたの添付PDFに出てくる「優先度」「対象地域」「イベント種別」などの項目を、“スマホ通知ロジック（フィルタ・優先度・抑制・重複排除）”に落とした設計案
• 仕様書（IS-QZSS-DCR / IS-QZSS-DCX-003）のどこを読めば「地域判定」や「優先度判定」に必要なフィールドが取れるか

…まで、具体化して提案できます。

現時点では、拡張や体制強化についての目新しい情報はなく、しばらくは7機体制構築の進捗次第という状況のようだが、配信される情報のフォーマットなどに関する、小さな改善のテストは静かに行われそうだ。