旅行計画アプリ「たびくる」に、旅行中の移動を軌跡として残す機能を追加している。位置情報は扱いを誤ると、記録の消失だけでなく、意図しない共有にもつながる。そこで、端末への記録とCloudKitへの公開を別の操作にし、公開する前に記録を停止して確認する流れにした。以下は2026年9月29日までの開発記録であり、機能全体の実機受入完了を示すものではない。

位置記録を先に端末へ保存する

Map画面の「軌跡」パネルから記録を明示的に開始・停止する。Core Locationの「使用中のみ」の許可とバックグラウンド位置情報を使い、ロック中も端末に保存する実装を追加した。旅行期間外、精度不足、重複、時刻の逆転、不自然な急変を除外し、5分を超える欠測では線を分ける。地図には表示点数を最大5,000点に抑えた点線を描き、端末内の原本とは分けて扱う。同じ旅行で記録を再開すると、新しい区間を同じ軌跡に追加する。

初期実装では、保存ファイル名にセッションのUUIDが展開されず、複数旅行の軌跡が同じJSONファイルを上書きし得た。ファイル名をセッションUUIDごとに直し、残っている旧形式のファイルは読み取れた場合に新形式へ保存してから退避するようにした。既に上書きされた過去の軌跡はアプリ内から復元できない。

起動時の復元中に新しい記録を始めると、後から完了した復元が新しい状態を置き換える可能性も見つかった。復元が終わるまで記録開始を無効にし、保存処理を単一のワーカーへ集約した。連続する更新は最新の状態を後続の保存へ回し、バックグラウンド移行時には保留中の保存完了を待つようにした。

停止した軌跡だけをCloudKitへ公開する

公開は停止済みの記録を選び、確認した後に実行する。旅行本体のデータは変更せず、既存の旅行レコードの子としてTripTraceSessionとTripTraceChunkを保存する。位置の点列は500点単位のCKAssetに分け、全チャンクがそろうまで公開済みの軌跡として扱わない。

実機では公開操作後に「別の端末で旅行プランが更新されました」と表示された。調査で、旅行本体を再保存する経路と、軌跡レコードの再保存時に最新のchange tagを使わない経路が見つかった。公開時は旅行レコードの存在を確認するだけにし、既存の軌跡レコードは取得して更新する。初回保存後の状態更新にも、保存結果に含まれる最新のchange tagを使うよう修正した。公開・再公開・取消の実機再受入は残っている。

共有先では、同じ旅行のCloudKit Zoneから公開済みの軌跡を取得し、Mapへ読み取り専用の線として重ねる処理を追加した。取得に使うのはZoneの変更履歴で、軌跡の検索用インデックスには依存しない。公開途中、チャンク不足、取消済みの記録は表示対象から外す。こちらも2端末間での表示は未確認である。

公開取消で子レコードを残さないために

9月29日の静的監査では、旅行を削除しても公開済みの軌跡レコードが残り得ることと、CloudKitの部分的な削除失敗を成功として扱い得ることが分かった。SessionとChunkへ親の削除に連動する参照を追加し、既存レコードも対象にできるよう、公開取消と旅行削除では子レコードを明示的に取得・削除する。個々の削除結果を確認できた場合だけ端末側を「未公開」に戻し、失敗した場合は「取消待ち」を維持するようにした。

軌跡レコード型はCloudKit Productionへ反映済みとの報告がある。一方、今回追加した削除連動用フィールドのDevelopment環境での生成、Productionへの反映、実際のCloudKitでの取消・旅行削除は未実施である。

確認できた範囲

軌跡の表示と共有取得処理を追加した後、XcodeのDebugビルドは成功した。iPhone SimulatorではMapと軌跡パネルの表示を確認したが、iCloudにサインインしていないため共有取得は試せていない。9月29日の保存順序と削除処理の修正後もDebugビルドは成功した。共有同期のシェル回帰は同日に修正・実行して成功したが、Core Locationや実CloudKitの検証ではない。

残る確認は、複数旅行の記録を再起動後も個別に読めるか、位置許可とロック中の保存、長時間記録の電池消費、2端末間の公開・再公開・表示・取消、通信断や旅行削除時の結果である。これらの実機受入を終えるまで、旅行軌跡機能を完成扱いにはしない。