aptpod Tech Blog

株式会社アプトポッドのテクノロジーブログです

AIエージェントが旅の軌跡まとめてくれるUX

計測データをもっと簡単に活用したいみなさん、

こんにちは、ソリューションアーキテクトの伊勢です。

収集された計測データを取得・加工してシステム連携するケースが増えてきました。

今回は自分で実装せず、AIエージェントにAPIの仕様を教えて実現してみます。

GeoJSONを生成し、地図サービスで可視化した結果をHTMLとして公開します。

はじめに

intdash API

以前ご紹介した intdash API は保存済みの計測データをREST APIで扱えます。

このAPI仕様をAIエージェントに理解してもらいます。

tech.aptpod.co.jp

やりたいこと

休みを取ってJR芸備線に乗ってきました。

JRで一番採算が取れない路線で廃線が議論されています。

tetsudokyogikai.net

GPS計測データ、駅情報、写真を地図上に重ねて、旅の流れを見えるようにします。

データフロー

複数の入力データを元に地図サービスで可視化します。

地図に載せたい情報は以下です。

  • intdashのGPS(GNSS)計測データ
    • タイムスタンプ
    • 緯度経度
    • 高度
    • 速度
  • 駅情報
    • 緯度経度
    • 駅名
  • 旅の写真
    • 撮影時刻
    • EXIFの緯度経度
    • サムネイル画像URL
    • 画像キャプション

手作業でやると、API仕様の確認、データ取得、バイナリデコード、S3公開、インタフェース向けの調整など、地味な作業がたくさんあります。

今回はこの一連の作業を Codex に依頼しました。

Codexとは

コードの読み書きやコマンド実行、ファイル生成、API調査などを行えるAIエージェントです。1

今回のポイントは、単にコードを書いてもらうだけではありません。

  • intdash API仕様を確認する
  • 実際にAPIへ接続してデータ構造を確認する
  • プロトコルのペイロード仕様を読んでバイナリをデコードする
  • 連携先で扱いやすいGeoJSONを検討する
  • 写真のEXIFを読み、サムネイルを作り、S3に公開する

AIエージェントはこういった「やりたいことは明確だけど、途中に細かい作業が多い」タスクを試行錯誤しつつ遂行してくれます。

kepler.glとは

位置情報データを地図上で可視化できるWebアプリケーションです。

GeoJSONやCSVなどをアップロードすると、点・線・ポリゴンなどの地理情報をレイヤーとして表示できます。

今回生成したGeoJSONをアップロードし、HTMLとしてエクスポートしました。2

kepler.gl

やってみた

緯度経度を可視化

今回の作業は、最初から細かい仕様をすべて決めていたわけではありません。

まずは、やりたいことをざっくり伝えました。

intdash計測データを元に kepler.glにアップロードするためのGeoJSONを生成してください。

入力データには intdash Motion v2 のGNSS計測データを取得します。 intdashのAPI仕様の認証、計測、計測データの取得方法を確認してください。

対象データはエッジ ise の日本時間2026/6/23に作成された複数の計測です。 一覧表示して確認させてください。

接続先サーバー環境情報はプロジェクトの

.env

に記載しています。

取得する計測データは以下のとおりです。

  • 緯度経度

取得するデータ名は推定して候補を提示してください。

2D Vectorペイロードフォーマットで格納されています。

緯度と経度に分けて出力してください。

計測データには1つずつ

  • タイムスタンプ

が付与されています。

GeoJSONに出力してください。

タイムスタンプはYYYY-MM-DD hh:mm:ss.SSS形式でラベル属性としても出力してください。

この時点で伝えていたのは、対象データ、API仕様、だいたいの出力イメージです。

初回レスポンス

生成されたGeoJSON

出力されたGeoJSONをkepler.glのデモ画面にアップロードすると、早速軌跡が表示されました。

初回アップロード

途中で調整も依頼しました。

kepler.glで可視化できました。

いくつか修正してください。

・可読性のため、geojsonをインデントフォーマットしてください。

・timestampは日本時間ということがわかるようにしてください。

・labelがtime属性と認識されていまっています。stringになるようにしてください。

高度・速度を追加

表示項目を追加してみました。3

以下の変更を加えてください。

・同計測から、高度・速度の計測データも取得して、項目として付与してください。

高度でグラデーション

速度でグラデーション

軌跡が北側に凸になっている箇所が高地で低速のようです。

表示レイヤー追加

intdash以外のデータも追加して表示します。

kepler.glにアップロードするGeoJSONを追加します。

インターネットからJR芸備線の駅の情報を取得してください

  • 緯度経度
  • 駅名

また、緯度経度のGeoJSONは線として出力するよう変更してください。

駅名レイヤー追加(下が北)

低速だった区間は備後落合駅の付近のようです。

写真サムネイルの追加

ローカルファイルからのGeoJSON生成も依頼しました。

プロジェクトの photo フォルダに旅の写真を置いてあります。
- QVGAサイズのサムネイルを作成
- EXIFから撮影時刻、緯度経度を抽出
- サムネイルをAWS S3にアップロード・公開URL取得
- サムネイルを画像認識してキャプションを生成
- 撮影時刻、緯度経度、キャプション、サムネイルURLからGeoJSONを作成

このように多岐にわたる作業を一手に依頼できるのも魅力です。

写真GeoJSONの生成

地図HTMLの公開

最後に地図の公開を依頼しました。

kepler.glからHTMLをダウンロードしてプロジェクトに置きました。
S3に配置して公開URLを取得してください。
また、プロジェクト内のフォルダを整理して古い不要ファイルは削除してください。

HTMLファイルの公開

今回できた地図HTMLをS3で公開しています。

公開HTML

3種類のデータを重ねたものです。 4

  • intdashの走行軌跡
  • 沿線の駅
  • 旅写真のサムネイルとキャプション

軌跡は速度で色分けしています。

「どんなところで何を見たのか」振り返れる旅の記録になりました。

感想

うまくいったところ

REST APIの理解、計測取得

CodexによるintdashのREST API仕様・アクセス方法を理解は滞りなく進みました。

プロジェクト/エッジ/計測を具体的なUUIDで指定しなかったので、

何らかの追加指示が必要になるかと思っていたのですが、

指示に該当する計測を自動で認識してくれました。

また、計測に含まれるデータIDを見て、緯度経度は gnss_coordinates と推定してくれました。

実際のデータを数件取得して、仕様通りのデコードができるか、値が妥当かを確認してくれました。

データIDの確認

gnss_coordinates は 2D Vector という2値形式で格納されています。

仕様では、X/YそれぞれがIEEE754 64bit浮動小数点数で、ビッグエンディアンです。

実際のAPIレスポンスでは、データ本体は以下のようにBase64文字列として返ってきます。

"data": {
  "d": "QEFVC8tEtA1AYJfd1+VRuw=="
}

「Base64をデコードしてください」と明示的に指示したわけではありませんが、CodexがAPIレスポンスの形と仕様を見て、data.d をBase64デコードし、16 bytesをビッグエンディアンの double として読む必要がある、と解釈してくれました。

"features": [
  {
    "type": "Feature",
    "geometry": {
      "type": "Point",
      "coordinates": [
        132.74583048619192,
        34.66442242483763
      ]
    },

なお、GeoJSONの座標は [longitude, latitude] の順なので、出力時には入れ替えてもくれました。このあたりは人間が手でやると間違えやすいところです。

軌跡GeoJSONを調整

最初はGNSSデータの緯度経度を点として出力しました。

駅位置の点とあわせて表示すると見づらいため、線として表示するよう変更したところ、色分けしやすいように平均高度・平均速度などを付与してくれました。

"properties": {
  "altitude_start": 198.84193365530137,
  "altitude_end": 196.83770584185308,
  "altitude_avg": 197.8398197485772,
  "speed_start": 0.9940862059593201,
  "speed_end": 0.5033005893230439,
  "speed_avg": 0.748693397641182
}
S3でファイル公開

サムネイルとkepler.glのHTMLをAWS S3に配置しました。

PCに導入済みのAWS CLIを使ってもらいましたが、アクセス情報はローカルのプロファルを使うよう指示しただけですんなり配置できました。

S3のサムネイルファイル

プロジェクト内を整理

生成物が増えてきたのでプロジェクト内を整理しました。

不要になった中間ファイルは削除しました。

リファクタリングも気軽に行えます。

試行錯誤したところ

写真データのサムネイル作成

HEICからサムネイルを作るところで少し詰まりました。

PCに入っていた ffmpeg で変換してもらいましたが、写真の一部だけが切り抜かれたようなサムネイルになりました。

最終的には macOSのQuickLookを使って、元写真全体からサムネイルを生成する方式に変更しました。

結果として、横写真は 320x240、縦写真は 180x240 のように、写真全体を保持したサムネイルになりました。

サムネイル生成修正

kepler.glでの画像表示

最初は画像URLが単なる文字列として表示されてしまいました。

そこで、kepler.glのTooltipで画像として扱えるように "<img>-tooltip" というプロパティ名に変更しました。

  "<img>-tooltip": "https://example.s3.ap-northeast-1.amazonaws.com/xxx.png"

サムネイル表示

おわりに

今回の実行結果をTech Blog記事を執筆します。

タイトルは

AIエージェントが旅の軌跡まとめてくれるUX

です。

過去の私の記事の章立てを参考にドラフトを作成してください。

https://tech.aptpod.co.jp/entry/2025/10/31/160000


今回は、Codexを使って思い出をまとめるユーザー体験の旅に出かけました。

やっていること自体は、APIからデータを取得して、GeoJSONにして、地図に載せるだけですが、実際には細かい判断がたくさんあります。

  • API仕様のどこを読めばよいか
  • どのデータ名が緯度経度なのか
  • バイナリペイロードをどうデコードするか
  • 連携サービスではどういうデータ形式が扱いやすいか
  • 写真サムネイルが正しく表示されているか
  • S3の公開設定が正しいか

これらをCodexと会話しながら進められるため、安心感が伴いました。

特に、一度表示してから方式修正を繰り返せたのが実用的でした。

AIエージェントは、最初から完璧な成果物を一発で出すというより、状況に合わせて柔軟に調整する随伴者でいてもらうのがよさそうです。5

心強いから、自然に一歩を踏み出せる。そんな景色が見えてきました。


  1. 今回はVS Codeの拡張機能実装を利用しています。
  2. 地図サービスのAPIによっては、データ連携もできます。
  3. GNSS内の項目は同じタイムスタンプが付与されているので一意に紐付けが可能です。
  4. ポイントにカーソルを当てても一度では写真が表示されないことがあるようです。
  5. 生成AIの回答や生成物には誤りが含まれる可能性があります。API仕様、データ件数、公開設定などは実際に確認しながら利用します。