Research Notes vol.1 — Geminiを自動運転コントローラとして評価する第一回トライアル(途中経過)

弊社では、実証研究プロジェクト 「autodrive」 の研究過程を継続的に共有するため、本記事より Lifegence Research Notes を順次公開してまいります。第一回となる本稿では、Google Gemini 2.5 Flash / Pro を自動運転コントローラとして据えた場合の挙動を、東京都内住宅地で収録した実走行データに対して評価した第一回トライアルの途中経過を報告します。

要旨 — 今回確認できた3つのこと

Gemini 2.5 Pro は実走行シーンの状況認識に十分な解像度を持つ:住宅地で発進準備中の自転車利用者を「ただ駐輪されている自転車」と区別し、リスクとして適切に言及できた。
数値センサ入力は意味付けなしに渡すと容易に誤動作する:スマートフォンIMUの生値(重力含み)を投入したところ、Proが「1G緊急ブレーキ相当」と解釈してフルブレーキ＋ハザード点灯にパニック化した。
プロンプト設計とサンプリングレートが結果を支配する:同一セッション・同一モデルでも、プロンプト世代を変えるだけで行動分布が大きく変わり、0.2 Hzサンプリングでは数秒スケールのイベントを取りこぼす。

本稿は 途中経過 であり、最終的な評価結論ではありません。サンプル数も限定的(N=68〜600)です。それでも、走行可能なエンドツーエンドの評価パイプラインが立ち上がり、設計上の落とし穴を実走行データで確認できた段階として、現時点の知見を共有する意義があると判断しました。

検証の概要

対象セッション:東京都内住宅地、晴天、約10分(Pixel 6 を FRONT 端末として車載)
評価対象モデル:gemini-2.5-flash / gemini-2.5-pro
評価モード:Shadow Mode(録画 → 走行後にオフラインでGemini推論 → 評価指標出力)。実車制御には一切接続していません。
設計世代:プロンプトおよび出力スキーマを5世代(v1〜v5)で比較

5世代のプロンプト・スキーマ設計

世代	設計の主旨	結果
v1	「慎重なドライバー」視点、離散action enum (continue/slow/stop/turn_*)	proが画像を「運転環境外」として28件超リジェクト
v2	「住宅地の狭路も運転環境扱い」「止まれは徐行通過 → slow」をプロンプトに追記	リジェクト消失。一方で過剰停止 → 過剰徐行に振れすぎ
v3	スキーマを連続値(throttle / brake / steering_deg / turn_signal)に全面改修	proが停車場面でbrake=0.70、非停車場面で0.29と明確に区別。妥当な数値出力域に到達
v4	IMUの前後加速度・横加速度・ヨーレートを画像と一緒に投入	proが完全パニック化(throttle>0が1/68、brake mean 0.94、ハザード点灯率53%)
v5	IMUの重力ベースラインを引き、「スマホ民生センサ・参考値」と明記	パニック消失。v3同等まで回復。ただしbrake識別力は減衰

ハイライト1:v4でProが「センサ異常」とpanicした件

「IMUデータも併せて渡せば判断精度が上がる」という前提で投入したところ、gemini-2.5-pro の挙動が一変しました。

指標	pro v3 (画像のみ)	pro v4 (IMU込み)
throttle > 0 frames	21/68	1/68
brake mean	0.44	0.94
brake識別力 (Δbrake stop vs non-stop)	+0.41	+0.02
turn_signal hazard	20/68	36/68 (53%)

ほぼ全フレームでフルブレーキ＋ハザードランプ点灯。Proの応答理由欄には「車両状態の矛盾(急減速と低速)」「加速度センサーの異常値の可能性」「システム異常の可能性」といった記述が並びました。

原因はシンプルで、Pixel 6 は端末座標系でIMUを出力するため、ax の中央値が-9.45 m/s² ≈ 重力1G。これを生のままプロンプトに「前後加速度 X m/s²」として渡していたため、Proは「-9.45 m/s²の急減速 = 1G緊急ブレーキ → 緊急事態」と妥当に解釈していたわけです。

v5で重力ベースラインを補正し「参考値」として明示したところ、パニック挙動は完全に消失しました。LLMに意味付けされていない数値を渡すと、もっともらしい解釈を自分で作って誤動作する — Agentic Company OSの設計においても、外部信号の意味論的ラッピングが品質を支配することを示唆する一例です。

ハイライト2:「自転車を準備している女性」の検出

走行記憶では「セッション開始から1分半頃に自転車で前を横切る女性」のシーンがあったはずでしたが、0.2 Hzサンプリング(5秒間隔、68 frames)のGemini出力には該当する記述が見当たりませんでした。

「Geminiが見落としたのか、サンプリング間隔の隙間に落ちたのか」を切り分けるため、80〜100sの窓を 1 Hz × pro v5 で再評価したところ、t=97s で次のような出力を得ました:

「狭い住宅街の道路で、右側に自転車の準備をしている女性がいるため、安全確認のため停止して様子を見ています。」

expected_changes: 「右側の女性が自転車で発進する可能性があるため、その動向を注視し、安全な間隔を保つ必要があります。」

risks: 「右側自転車の急な発進やふらつき」「対向車の出現」「左側の植え込みからの飛び出し」

該当フレームには確かに、自転車のハンドルに手をかけて発進準備中の女性が映っていました。Gemini Pro は「自転車に乗ろうとしている人」と「ただ駐輪されている自転車」を区別 し、対向車・植え込みからの飛び出しまで含めたリスクシナリオを併記できていました。

一方、0.2 Hzの隣接サンプル(t=95, 100)には女性が映っておらず、5秒間隔では検出不能なシーンであったことも確認できました。サンプリングレートが状況認識能力を物理的に制約する という、当然ではあるが実走行データで定量化できた事実です。

数字で振り返り

項目	値
対象セッション	10分(東京都内住宅地、晴天、Pixel 6 / Android 16)
プロンプト・スキーマ世代数	5(v1〜v5)
累計Gemini呼び出し回数	565件
累計コスト(API利用料)	約730円
累計実所要時間(並列実行)	約2時間
schema_error_rate(v3以降)	0%
pro v5のpredicted_path単調性	98%

なお、走行中の端末側リアルタイムオーバーレイは初回トライアルで全178件失敗しましたが、原因は AndroidManifest.xml に android.permission.INTERNET の宣言が欠落していた基本的なミスでした。エラーログを保全していたことで切り分けが容易になった反面、車載アプリ側の事前検証フローを改善する必要を認識しました。

既知事実の組み合わせとしての価値

技術的観点から誠実に申し上げると、本トライアルで個別に観測された事象は、いずれも先行事例で示唆されている範囲にあります:

VLMが画像を解釈して構造化出力できること
スマホIMUが端末座標系で重力を含む値を返すこと
プロンプト一行でLLM出力分布が変わること
0.2 Hzでは数秒のイベントを取りこぼすこと
Gemini ProがFlashより保守的に振る舞う傾向があること

今回の価値は「新発見」ではなく、これらの既知事実を組み合わせた際に、実走行データで具体的にどう壊れ・どう動くかを定量化したこと にあります。Shadow Modeでの段階的検証だからこそ、実車制御に接続する前に、設計上のフラジリティを安全な形で発見できました。

次のステップ

優先度	内容
1	1 Hz × 601 frames で v5 を本実行(相関の N を 10 倍に)
2	turn_signal の enum を `["off","left","right"]` に絞ってハザード誤用を機械的に防止
3	評価器(`evaluator.py`)を連続値メトリクス対応に書き換え
4	BLE同期した2台同時セッション解析(Phase C)
5	別シナリオ(夜間、雨天、高速、郊外)でのデータ収集

Agentic Company OSへの還元

本研究で得られた知見 — 構造化出力スキーマの収束過程、外部数値信号の意味論的ラッピングの重要性、サンプリングレートとイベント検出の関係 — は、弊社が開発する Lifegence Company OS におけるエージェント設計にも直接還元可能です。マルチモーダル基盤モデルが認識・判断・行動を統合的に扱う領域では、同じ設計パターンが横断的に有効であることを、本トライアルでも改めて確認できました。

次回 Research Notes では、1 Hz本実行および評価器更新後の結果を公開予定です。

autodriveプロジェクトのすべての検証は、Shadow Mode(実車制御に接続せず録画・オフライン解析のみ)の範囲で実施しています。実車の運転判断や制御にLLMの出力を直接使用することはありません。

BASE LAYER

PRIVATE

OSS (MIT)