はじめに
RTCM（Radio Technical Commission for Maritime Services）形式のデータ解析は、GNSS技術者にとって長年の壁でした。
特に GLONASS 系 SSR（State Space Representation）は仕様が複雑で、bit単位の誤りが1つでもあれば結果が崩壊します。
はじめに
私もこの壁に直面し、GPTを使って自動化を試みましたが――最初は Heuristic エラー（推測処理）に悩まされ、正確なパースに到達できませんでした。
「もう無理かもしれない」と思った矢先、GPTから提案されたのが サンドボックス実行環境 でした。
※参考資料
①MADOCA 仕様書
https://ssl.tksc.jaxa.jp/madoca/public/doc/Interface_Specification_B_ja.pdf
②MADOCA LIB 説明
https://github.com/QZSS-Strategy-Office/madocalib/blob/main/MADOCALIB_manual_ver005.pdf
③RTKLIBソース
RTCM３のビット配置などはソースを参考にGPTがテンプレートを作成した。テンプレートはcommon (GPS,GALILEO,BEIDOU) Glonassの2個
RTCM-SSR_template_csv.v20251011.master_common
RTCM-SSR_template_csv.v20251011.master_glonass
common
MT１０５７・１０５８ MT１２４０・１２４１ MT１２５８・１２５９
Glonass
MT１０６３・１０６４
サンドボックスとは
サンドボックスは、コードを安全・再現可能に実行するための隔離環境です。GPTが自身でデバッグしてバグを解析できるGPT内環境です。
時間やメモリを自動制御し、失敗しても他の処理に影響を与えません。
GNSSやRTCMのように「bit単位の構造を厳密に扱う」処理において、サンドボックスは次のような強みを持ちます。
-
🔒 安全性：未知のバイナリでも安全に試せる
-
🔁 再現性：毎回同じ条件で実行・検証できる
-
🚦 制御性：タイムアウトやメモリ制限を自動適用
-
🧩 デバッグ性：途中出力・ログをその場で確認可能
これが「厳密さを求めるGNSS解析」と相性抜群でした。
1か月間の停滞と突破
当初、GLONASS SSR（RTCM MT1063/1064）のパースは、
テンプレCSVの構造を守っても符号やスケールが一致せず、1か月以上進みませんでした。
GPTに何度も相談しましたが、ヒューリスティック（推測）に頼る生成では正しい結果が出ません。
私は 「STRICT／fail-closed」 モードを要求し、GPTはそれに応えて サンドボックス実行で厳密検証する方式 を提案してくれました。
その瞬間から状況が変わりました。
-
CRC・IOD・符号・LSB すべて自動検証
-
失敗時は即停止し、ログとともに再現可能
-
正常ケースは CSV 出力＋統計＋スループット付き
結果、GLONASS SSRのパースが完全に成功。
「できないと思っていたもの」が、一夜にして再現性ある仕組みとして動き出しました。
実際の成果
出力された CSV の一部を示します。
衛星R05の軌道・時計補正が、MT1063と1064のペアで整合。
手動検証しても LSB, 符号, IOD がすべて一致し、RTCM標準（10403.3 Annex N/O）通りの結果になりました。
なぜサンドボックスが効いたのか
RTCM解析では「ヒューリスティック（推測）」を排除しなければ正答にたどり着けません。
サンドボックスでは実行環境が完全固定され、
“仮説で走らない”＝“検証しか通らない” 状態を作り出せます。
これは、開発者が失敗を恐れず試行錯誤できる「信頼できる試験場」そのものでした。
今後の展開
今回の成功で、SSRパースの他の系統（GPS 1057/1058、Galileo 1240/1241、BeiDou 1258/1259）にも同じアプローチを適用可能になりました。
次の目標は、SSR補正をエフェメリスに統合し、SP3生成まで自動化することです。
まとめ
GLONASS SSRパースを断念しかけた私を救ったのは、「AIの助言」ではなく「検証の仕組み」でした。
サンドボックスという仕組みが、GPTとの協働を安全で正確なものに変えたのです。
今後もこの環境を軸に、GNSS解析の壁を一つずつ越えていきます。
