はじめに
GT7（グランツーリスモ7）の走行データは、UDP通信を介して 1秒間に60回（60Hz） という高頻度で出力されます。
しかし、5分間の走行で約18,000行に達するこのデータをそのまま眺めても、改善点を見出すことは困難です。
- グラフを見ても「どこをどう直すべきか」直感的に分からない
- 数万行に及ぶ数値データは、人間にとっても、LLMにとっても扱いが難しい
本記事では、この課題を 「数値 → 意味抽出 → 言語化」 という設計パターンで解決し、走行データを “プロの助言”として出力するAIコーチを構築した手法を解説します。
この記事でわかること
- LLMが苦手な「高頻度・大量の数値データ」を扱うための設計パターン
- 時系列データをドメイン知識に基づいて「文脈（コンテキスト）」に変換する方法
- AWS Bedrock（Claude） × Python × Streamlit による実装構成
- 趣味のプロジェクトを「技能伝承」や「DX」に応用する視点
なぜLLMにテレメトリをそのまま渡してはいけないのか？
1. 技術的制約（トークンとコスト）
18,000行のCSVをそのままプロンプトに流し込めば、一瞬でコンテキストウィンドウを圧迫し、実行コストも跳ね上がります。
2. 本質的な「意味」の欠如
LLMにとって、単なる数値の羅列は「背景のない数字」に過ぎません。
「時速150kmから120kmに落ちた」という事実（Fact）は分かっても、それが「コーナー進入でのブレーキの引きずりすぎ（Meaning）」であると判断するには、ドメイン知識を介した解釈が必要だからです。
全体アーキテクチャ
- データ取得（Ingestion）: Pythonを用いてGT7からUDPパケットを受信・蓄積（※）
- 特徴量抽出（Feature Engineering：ドメイン知識を数値化する工程）: Pandasで統計量や独自指標を算出
- 推論（Reasoning / LLM）: AWS Bedrock（Claude 4.6 Sonnet）に要約データを渡し、アドバイスを生成
- 可視化・UI（Presentation）: Streamlitで可視化とチャットフィードバックを表示
※ 補足：本実装では、UDP通信で受け取ったバイナリをPythonのstructモジュールでパースし、Pandas DataFrame化しています。
図：GT7テレメトリを「意味」に変換し、LLMに入力するまでの処理パイプライン
コアアイデア：ドメイン知識による「意味への変換」
LLMに渡すのは「データ」ではなく「意味」です。
この変換処理こそが、本システムの価値の中核となります。
ここで、エンジニア（またはドライバー）としての知見をコードに落とし込みます。
※ 本記事では、時系列データそのものではなく「要約統計量」をLLMに入力しています。
実装例：Pythonによる特徴量抽出
単純な平均値ではなく、 「ドライビングの質」 が出る指標を定義するのがコツです。
import pandas as pd
class TelemetryAnalyzer:
@staticmethod
def compute_summary(df):
# 1. まず、辞書を作る前に必要な変数を計算しておく
# 0より大きい値（有効なタイム）の中から最小値を見つける
valid_best_laps = df[df["best_lap_ms"] > 0]["best_lap_ms"]
best_lap_ms = valid_best_laps.min() if not valid_best_laps.empty else 0
best_lap_sec = round(best_lap_ms / 1000, 3) if best_lap_ms > 0 else None
# 2. 計算した結果を辞書にまとめて返す
return {
"best_lap_sec": best_lap_sec,
"speed_max_kmh": round(df["speed_kmh"].max(), 1),
# 【ドメイン知識1】アクセル全開率
"throttle_full_pct": round((df["throttle_pct"] >= 80).mean() * 100, 1),
# 【ドメイン知識2】ブレーキの引きずり率
"braking_ratio_pct": round((df["brake_pct"] > 0).mean() * 100, 1),
# ギア使用分布
"gear_usage": df[df["speed_kmh"] > 10]["gear"].value_counts(normalize=True).to_dict()
}
AWS Bedrock (Claude) を採用した理由
今回の構成では、AWS Bedrock経由で Claude 4.6 Sonnet を使用しています。
- 高い推論能力: 少ない統計データから「荷重移動の乱れ」や「ライン取りのミス」を推論する能力が非常に高い
- セキュアな環境: DX推進のプロトタイプとして考える際、データのプライバシーが保護されたマネージド環境（AWS）であることは重要
- 高速なレスポンス: 走行直後にフィードバックを得るための低レイテンシ
プロンプト設計：AIに「役割」を与える
def build_system_prompt():
return """
あなたは世界最高峰のレーシングコーチです。
提供される統計データに基づき、プロの視点でアドバイスしてください。
【分析指針】
- throttle_full_pctが低い → コーナー立ち上がりでパワーをかけきれていない。
- braking_ratio_pctが高い → ブレーキをダラダラと残しすぎ。
- これらを組み合わせて、荷重移動や走行ラインの課題を「推論」してください。
必ず具体的な改善アクションを3つ提示してください。
"""
AIコーチのアドバイス
構築したパイプラインを通じて出力された、実際のアドバイス画面がこちらです。スロットル全開率やブレーキの踏み込み率といった統計データから、ラップタイム更新のための「伸びしろ」が言語化されています。
図：AIのアドバイス（全体）
図：AIのアドバイス（拡大）
数値ベースの統計量から、ドライビング操作へと解釈が変換されている点に注目してください。これは「数値 → 意味 → 行動」という変換が成立していることを示しています。
ビジネス・DXへの応用
この「高頻度時系列データ → 特徴量抽出 → LLMによる言語化」のパターンは、レースゲーム以外にも応用可能な有効な設計パターンです。
- スマートファクトリー: 設備の振動データから「ベアリングの摩耗」という“意味”を抽出し、保全担当者に「あと3日で交換してください」と言語化して伝える
- 技能伝承: 熟練工の動作データをセンサーで取得。新人に対し「今の腰の入れ方は角度が浅い」と、熟練者の感覚をAIで再現する
- 物流・安全運転: ドライバーの挙動データから「急ブレーキが多い」だけでなく、「疲労による認知の遅れ」の兆候を言語化して警告する
まとめ
本プロジェクトで示したのは、「LLMにデータを読ませるのではなく、意味を読ませる」という設計思想です。
数万行に及ぶログデータを、そのまま扱うのではなく、ドメイン知識を介して「意味ある情報」に変換することで、LLMは初めて価値ある推論を行えるようになります。
このアプローチは、レースデータに限らず、あらゆる高頻度データを扱うシステムに応用可能です。
AIを単なるツールとして使うのではなく、意思決定を支えるパートナーへと引き上げる――
そのための実践的な一例として、本記事が参考になれば幸いです。
次のステップ
本記事では「統計量ベースの要約」によるAIコーチングを実現しましたが、今後はさらに以下の方向へ発展させていきたいと考えています。
-
セクター別デルタ解析の導入
速いラップとの比較から「どの区間で、どれだけ遅れているのか」を分解し、
コーナー単位での具体的な改善ポイントを提示 -
時系列パターンの活用
スロットル・ブレーキ・速度の「波形そのもの」を特徴量として扱い、
「操作の滑らかさ」や「荷重移動の質」を評価 -
リアルタイムコーチングへの拡張
走行中または直後にフィードバックを生成し、
“振り返り”から“その場での改善”へと進化
単なる分析ツールではなく、
「ドライバーの意思決定に介入できるAIコーチ」 を目指して、継続的に検証を進めていきます。
本記事のような、データ分析やAIを活用した試行錯誤について、noteでも継続的に発信しています。
試してみたことや気づいた点も含めてまとめているので、興味のある方はぜひご覧ください。
https://note.com/toolstudio22