PlannerForge、LLMエージェントで自動運転テスト工程を統合

導入

自動運転システムを検証するには、単に珍しい交通場面を作ればよいわけではない。自然言語で書かれた要求を実行可能なシナリオへ変換し、適切な場面を選び、必要なら変更を加え、運動プランナーを動かしたうえで、結果が本当に意味のある失敗を示しているか判断する必要がある。しかし従来のシナリオベーステストでは、これらの工程が複数のツールに分散し、相互の連携が限られていた。EMNLP 2026採択論文のPlannerForgeは、この分断をLLMエージェントで埋めようとする。

主なポイント

• テスト工程を横断。 シナリオ生成、選択、変更、モジュールルーティング、プランナーのテスト、ADS評価を一つの流れにまとめる。LLMを単なるシナリオ作成器ではなく、工程を調整する層として利用する設計だ。
• 二つの追加ステージ。 従来の生成から評価までの流れに加え、ADS EnhancementとADS Benchmarkingを導入する。前者はシステム改善、後者は複数のシステムや設定の比較を支援する位置付けである。
• 複数モデルで比較。 10種類の既存LLMを5つのプロンプト条件で評価し、タスク別の最高スコアは0.88〜1.00だった。20B〜35B規模のオープンモデルは多くのタスクで商用APIに匹敵し、Qwen3.6:35Bは報告された5タスクのうち3タスクで商用モデルと同等水準に達した。
• 連結時の性能も測定。 モジュールを順番につないだ場合、種となるクエリの保持率は商用モデルで83%、オープンモデルで78%だった。個別タスクの高い精度だけでは、完全なテストパイプラインの品質を保証できないことが分かる。
• 自然言語要求を実行可能場面へ。 Scenario Factory 2.0との比較では、200件の要求から193件の実行可能シナリオを作成し、ベースラインの144件を上回った。都市、道路、車両に関する指定属性の実現率は92〜96%だった。

意義と課題

PlannerForgeの意義は、シナリオ生成、シミュレーション実行、結果分析を独立したユーティリティとして扱わず、LLMエージェントが連携させる構成を示した点にある。複雑なテスト条件を自然言語で記述しながら、実行可能な検証へ落とし込める可能性がある。

ただし、これらはフレームワークとタスクの性能を示す結果であり、自動運転の安全性が証明されたことを意味しない。最終的な有効性は、シミュレーターの信頼性、シナリオの現実性、評価基準の十分性、そしてエージェントが自分の誤りを検出できるかに左右される。エンドツーエンド保持率も、ルーティングや形式変換が依然として重要なボトルネックであることを示す。今後は、複雑な交通参加者間の相互作用、実データ、独立した安全監査の下でも同じ安定性を保てるかが問われる。

出典：Hugging Face Daily Papers