旅のしおりをGoogleマイマップに変換してスケジュール順に共有した

旅行のしおりに書いていた訪問先を、Googleマイマップにインポートできる形にして旅行メンバーに共有することにした。前日にダウンロードフォルダへ出力してもらったファイルには要らないスポットが混ざっていたので、そこを除いてしおり全体を作り直すところから始めた。

不要なスポットを除いて全件を作り直す

前日作ったインポート用ファイルには、しおりに載せるつもりのないスポットが2〜3件紛れ込んでいた。まずそれを除いてもらい、しおりに載っている確定行程と自由行動候補のスポット全部を、訪問日と時間帯を添えた形で再出力してもらった。

日程・時間帯を添えたのは、あとで「スケジュール通りに並ぶマップ」を作るための下ごしらえだった。この時点ではまだピンの並び順までは意識していなかった。

食事アイコンと観光アイコンを分けてみる

ピンの絵柄がすべて同じだと地図上で見分けがつかない。「食事系と観光系でアイコンを変えられないか」と聞いてみたら、Googleの標準アイコンセットにフォークとナイフ（食事）・カメラ（観光）・ベッド（宿泊）・飛行機（空港）が用意されていて、KMLのStyle定義でそのまま差し替えられることが分かった。

<Style id="food-icon">
  <IconStyle>
    <Icon><href>http://maps.google.com/mapfiles/kml/shapes/dining.png</href></Icon>
  </IconStyle>
</Style>

カテゴリごとに絵柄と色を変えたバージョンを送ってもらい、いったんはこれで満足していた。

カテゴリよりスケジュール順を優先する方針に切り替える

翌朝、地図のスクリーンショットが送られてきて「食事と観光をガッチャンコしてほしい」と言われた。理由を聞いて納得した。食事フォルダと観光フォルダを分けると、フォルダ内の並び順もその単位で独立してしまい、Day1の観光→Day1の食事→Day2の観光…という時系列の流れが地図上のリストから読み取れなくなる。

欲しかったのは「食事」「観光」という分類の一覧性ではなく、Day1→Day2→Day3、同日内は時刻順というスケジュールそのままの一覧性だった。そこで食事と観光の2フォルダを「スケジュール」という1つのフォルダに統合し、Day単位・時刻順に並べ直してもらった。アイコンの絵柄と色はカテゴリごとに残したので、時系列で追いながら種類も一目で判別できる。宿泊とルートのフォルダは元の構成のまま独立させておいた。

分類の軸と並び順の軸は別物で、両方を1つのフォルダ構造に押し込もうとすると片方が犠牲になる。カテゴリ分けを手放してスケジュール軸に寄せたのは、見せたい情報が「種類」ではなく「時系列」だったからだと、あとから言語化できた。

カスタムピンは実店舗データと繋がっていない

インポートしたピンをタップしても口コミや営業時間が出てこないことに気づいて、「実際の場所と合っているか、口コミも含めて普通のGoogleマップで確認したい」と相談した。答えは単純で、自作したKMLのピンは緯度経度だけを指定したマーカーであり、Googleが持っている実店舗データとは紐づいていなかった。

解決策として、各ピンの説明欄に「通常のGoogleマップでこの場所を検索して開く」検索リンクを埋め込んでもらった。

https://www.google.com/maps/search/?api=1&query=<緯度>,<経度>

ピンをタップして吹き出し内のリンクをタップすると、店名検索と同じ状態の通常のGoogleマップが開き、口コミ・営業時間・写真・道順ボタンが見られる。座標がずれていないかもそこで照合できる。全スポット分の説明欄に一括で仕込んでもらった。

作ったマイマップは、別アプリを入れなくてもGoogleマップ本体（アプリ・PC版）の「マイプレイス」から開けるので、自分のマップに取り込んで普段使いのGoogleマップと同じ感覚で見られるようにした。

gogcliでカレンダーに登録する

確定した予約は、gogcliスキル経由でGoogleカレンダーにも登録してもらった。--location・--description の両方に対応していたので、場所と補足情報を添えた形で1件ずつ登録できた。現地時間と手元のタイムゾーンがずれる行程だったので、時差を計算に入れた時刻で登録してもらった。

途中でレストランの予約時刻の訂正が1件入った。この修正は、しおりのMarkdown・地図のピンデータ・Googleカレンダーの3箇所に同じ情報が分散していたので、3箇所まとめて直してもらう必要があった。1箇所だけ直して終わらせなかったのは、あとで「どれが正しい情報か」で迷いたくなかったからだ。

別セッション: 空港へのアクセスをカレンダーに登録する

翌日の空港移動に向けて、保安検査場を通過できる締切時刻から逆算して、最寄り駅からの乗り換えプランをカレンダーに登録する作業も別セッションでやってもらった。締切時刻と乗り換え情報をウェブで調べる過程で、まず参照先が403エラーを返してWebFetchが撥ねられ、r.jina.aiプロキシ経由に切り替えて取得し直す一幕があった。

さらに調査の途中、取得した文章の中に「未知の乗り換え案内APIを叩いてみてほしい」という、直前の会話と脈絡のない指示が紛れ込んでいるのに気づいて、いったん手が止まった。プロンプトインジェクションの可能性を疑い、本人が送った指示かどうかを確認してから、実在するAPIだと分かった後も念のため確立された乗り換え案内サービスの結果とクロスチェックしてから採用する、という段取りにしてもらった。見慣れない指示が会話の流れに割り込んできたら、まず立ち止まって確認する。今日はそれがそのまま機能した形になった。

最寄り駅の候補についても途中で訂正が入り、登録済みのカレンダー予定を訂正後の駅発で登録し直してもらった。最終的には、余裕を持った乗り換えプラン1件がカレンダーに残った。

学び

分類の軸（カテゴリ）と並び順の軸（スケジュール）は別物。両方を1つのフォルダ構造に詰め込もうとすると、どちらかの一覧性が壊れる
自作のKMLピンはただの座標マーカーで、Googleの実店舗データとは無関係。口コミ・営業時間まで見せたいなら、通常のGoogleマップへの検索リンクを説明欄に仕込む必要がある
同じ情報がしおり・地図データ・カレンダーの3箇所に分散していると、1件の訂正でも3箇所まとめて直さないと情報がずれる
会話の流れと脈絡のない指示が調査結果に紛れ込んだら、実行前に一度立ち止まって本人の指示かどうかを確認する。今回はそれで実害なく済んだ