15年前の走行データがAIで蘇る？【検証編：iPodデータの「誤差」を科学し、Pythonで自動解析する】

アプリの「公式記録」と「生データ」の埋まらない溝

iPodで記録した966個のランニングデータ。その中からサンプルを1つ取り出し、Geminiに1kmごとの平均ペースを算出してもらいました。しかし、その結果を当時のNikeランニングアプリの出力と比較したところ、数秒程度のズレが生じることが分かりました。

システム管理者として、なぜこの差異が生まれるのかを分析した結果、以下の3つの要因が浮かび上がりました。

1. サンプリング間隔と「補間計算」の問題 2009年当時のデータは10秒刻みで記録されています（例：08:47:30, 08:47:40...）[cite: 69]。ちょうど1km（1000m）に到達した瞬間が、必ずしもこの記録タイミングと重なるとは限りません。 アプリ側はセンサーの生データを用いてミリ秒単位で「1km到達」を特定している可能性がありますが、ログデータから後計算する場合、10秒間の「点と点」の間をどう埋めるかという補間計算で、どうしても誤差が生じてしまいます[cite: 69, 70]。

2. 計算アルゴリズム（スムージング）の差 GPSや加速度センサーの誤差を補正するため、アプリ側では独自の「スムージング」処理が行われています[cite: 73]。画像に表示されるスプリットタイム（1km地点 6'44''など）はこの補正後の数値です。一方で、テキストデータの各ポイントに含まれるペース値は「その瞬間の生データ」であり、区間全体を平均化する際のロジックがアプリと異なれば、結果も変わってしまうのです[cite: 73]。

3. 「有効な走行時間」の定義の違い データの冒頭（動き出しの20秒間など）は、移動距離が極端に短く記録されています。アプリによってはこの静止に近い状態を「走行時間」から除外することがありますが、ログデータから一律に計算すると、この数秒の解釈が1kmあたりのペースに反映されてしまいます[cite: 66]。

結論：過去のデータは「最善の近似値」として扱う

検討の結果、アプリの数値は「リアルタイムの公式記録」、テキストファイルは「後出しの汎用ログ」であり、数秒のズレは仕様上避けられないものと判断しました。完璧な一致は求めず、当時の走りを振り返るための「最善の近似値」として、分析を進めることにしました。

960回分のログをPythonで一括解析する

いよいよ、960回分のTCXファイルを自動解析するプログラムの作成に入ります。Geminiをプログラミングの家庭教師にして、以下のロジックを実装しました。

• 入力： 960個のTCX形式データ [cite: 204]

• 出力： 年月日時間（JST変換）、距離（km）、走行時間（時分秒）、平均ペース、消費カロリー、および全区間の1kmラップを含むExcelファイル [cite: 63, 205, 206]

• 計算ロジック：

  • 世界標準時（UTC）から日本時間（JST）へ9時間を加算して変換 [cite: 2, 63]

  • 1kmスプリットは、1000mを超えた直後の記録をラップタイムとして採用

  • 平均ペースは、Nike独自の MeanPace タグのデータを利用 [cite: 66, 80]

  • データが存在しない項目は空欄として処理

使用する技術スタック：

• xml.etree.ElementTree：TCX（XML）ファイルの高度なパース [cite: 61]

• datetime：タイムゾーンの正確な変換 [cite: 63]

• pandas：データの構造化とExcel/CSVへの一括書き出し [cite: 58]

AIとの対話を重ね、ついに15年前の「カオスなデータ」を現代の「整った資産」へと変換する準備が整いました。