本ブログでは、AIベースの自律システムの近未来について、以下を取り上げます。
- AIベース自律システムのトレンド（例：「エンドツーエンド」への移行）
- 自律システムにおけるV&Vの役割拡大 ― AIベースシステムの「実装」と「V&V」の双方に共通して使えるツールの必要性
- AIがV&Vをどう支援するか ― センサーシミュレーション、行動モデル、テキスト→シナリオ生成、AIアシスタント等
- V&Vにおける抽象化が常に必要な理由 ― それをどう表現すべきか
その前に、「近未来」「AIベース自律」「抽象化」「V&V」の意味を明確にしておきます。これは学術論文ではなくブログです。多少のくだけた表現はご容赦ください。
定義
「近未来」：最近は未来の到来が非常に速く、タイムラインの確実性は低いですが、ここでは今後5年程度（ただし多くは今後2年で起こると想定）を指します。
「AIベース自律システム」：ここでの「自律システム」は、安全クリティカルで具現化（物理実体）を持つ自律を指します。自動（半自動）車両、ロボット、船舶、ドローン等。例としてはADS（自動運転システム）、特にAV（自動運転車）を用いますが、議論は上記すべてに当てはまります。安全クリティカルな非具現化の自律システムにも当てはまる点はありますが、ここでは扱いません。
「AIベース自律システム」は、機械学習の比重が高まる自律システム全般を指し、完全エンドツーエンドのシステムも、複合AI（Compound AI Systems）のようにMLが主要役割を担うアーキテクチャも含みます。
「抽象化（アブストラクション）」：ここでは形式的抽象化を意味します。数学・物理・交通ルール等の人間の知識を明示かつ正確に定義／符号化したものです。たとえば「衝突までの時間（TTC）」や「四方向一時停止（four-way stop）」は形式的抽象化です。
一方で非形式的抽象化も存在し、これは後で別途扱います。
「V&V」（Verification & Validation）：システムの安全性・品質に対する信頼を獲得し、バグを発見・修正する反復プロセスです。以下で述べるデータ自動化機能を用います。
「データ自動化」：V&Vで用いる “仕組み（装置・手法・コンテンツ）” を指します。カバレッジ空間・KPI・チェックの定義、シナリオ生成／マッチング、メトリクス評価、要求管理、トリアージ、バグ修正などを含みます。
「V&Vのための機能」に留まらず、実装（例：ML学習の指針）にも極めて有用であるため、ここではデータ自動化機能と呼びます。
予想されるトレンド
今後数年で、次のような傾向が見られると考えます（詳細は後述）：
- 自律はますますAIベースになる
- 完全エンドツーエンドか、よりML比重が高まるのかは不明確
- 自律の市場は急速に拡大
- 汎用・マルチタスクのFMベースのロボティクス基盤に取り組む動きは既にある
- デプロイの努力はデータ自動化中心へ
- AIはデータ自動化そのものにもますます寄与
- ただし、データ自動化には透明性と抽象化が不可欠
いずれの時点でも、開発者は目標安全度を最も効率よく達成する手段を選びます。そのため、実装におけるAI、データ自動化におけるAI、非AI要素の「その時点に最適な組み合わせ」が用いられます。
AIベース自律システムにおけるデータ自動化の役割拡大
古くから「開発とはV&Vである。空っぽのシステムから始め、V&Vが“何も動かない”バグを見つける」と冗談があるほど、V&Vは中心的です。
安全クリティカルなAIベース自律システムでは、データ自動化の重要性がさらに高まります。AIは複雑なシステムを作りやすくしますが、不具合が入りやすく（LLMのハルシネーションなど）、かつブラックボックスのため検証が困難です。結果として求められるV&V比率（実装に対するV&Vの比重）は増加します。
さらに、実装プロセス自体もデータ自動化機能を必要とします。AIベース自律システムの設計の多くはML学習であり、対象となる「空間」全体を探索して、良い／悪い挙動を明確に規定しなければなりません。これはカバレッジとチェックに非常に近い概念です。
バグ修正や機能追加は、主に学習データへの（是正・否定的）事例追加で行われ、探索・バグ事例発見にはV&Vとほぼ同じデータ自動化機能が要ります（AI訓練の世界ではデータ・フライホイールと呼ばれる部分）。
端的に言えば、こうしたシステムの構築・展開の大半はデータ自動化に関わると言っても過言ではありません。
Data-Automation for AI-Centric AVs
実装プロセスでのデータ自動化の使い方
エンドツーエンドAVを例にします。機能させ、十分に安全にするための多くはML学習であり、データ自動化は二つの側面で関わります：
- 「領域」を列挙し、その事例で学習
- 現行システムのバグを発見し、追加学習で修正
まず2)（実務では後段になることも）から：
- 現行の学習済みシステムを用意
- 高品質なV&Vを実施
- ODDに適合した**詳細なVPlan（検証計画）**を使用
- 実走ログ評価＋合成テスト生成でカバレッジを充足
- チェック、失敗トリアージ等を実施
- バグを見つけたら
- 問題領域へ一般化
- 十分な事例を収集／生成
- 是正・否定例として学習データに反映
- 安全・合法性・快適性等の目標に達するまで反復
同時に1)も必要です。2)だけでは非効率だからです：
- 思いつく限りの「領域」（難所を含む）を列挙
- 例：「他アクターの違法行為を扱う」
- それに応じたVPlanを作成
- 実走ログ評価＋合成生成で「十分な」事例を作成
- 学習に用いる
実際には両手法を反復的に用い、必要とするデータ自動化機能はほぼ同じです。
V&Vと実装に共通のデータ自動化機能
両者に必要な共通機能の例：
- 実走行ログからの事例探索（シナリオマッチング）
- 実走行ログの拡張（スマートリプレイ＋バリエーション）
- 完全シンセティックシナリオ生成（抽象シナリオに基づく制約付きランダム）
- 形式的抽象言語でシナリオ定義・カバレッジ目標・KPIを表現
- 標準DSL（例：OpenSCENARIO DSL）による抽象定義・評価・生成
- トリアージとデバッグ
データ自動化におけるAIの役割拡大
AIベース自律システムはデータ自動化の巧拙に依存しますが、幸いAIはデータ自動化そのものにも大いに役立ちます：
- AIベースの高度なセンサーシミュレーション（ニューラルリコン等）
- AIベースの行動モデル（より自然な挙動）
- テキスト→シナリオ／テキスト→マッチング事例（しばしば視覚言語FMに基づく）
- AIベースのV&Vアシスタント
特に、マルチモーダルFMベースのV&Vアシスタントには大きな期待があります。完全ではなくとも、例えば8割超で正答できるタスク集合に対しては非常に有用になります。
例：トリアージ＆分析アシスタントが夜間の大規模テスト実行と並走し、異常ランを停止・是正、トリアージを自動実施。誤りうるため、以下が重要：
- 何をなぜ行ったかの詳細で構造化されたログを残す
- ログの任意の詳細について対話できる
- その「決定」（失敗クラスタリング・分類等）が取り消し可能（例：Gitで管理しリバート可）
時間と共に、アシスタントはテスト自動生成等も行えるようになります。
V&VはAIだけで完結するか？ ― 答えはNo。
「AIがOKと言ったからOK」では人々は納得しません。規制当局や健全な常識は、人間が定めたルール（シナリオ、カバレッジ定義、チェック等）に基づく検証を要求します。ここで抽象化が本質になります。
アセッサ（評価者）が必要とするもの
AIベース自律もAIアシストV&Vも段階的に進化します。どの段階でも、人が「正しく行われたか」を確認する必要があります。
ここでは広義のアセッサ（評価者）を想定します：
- 規制当局
- AV事故訴訟の陪審
- フリート事業者（AVベンダー選定前）
- OEM（外部AVスタック採用前）
- AV企業の経営陣（デプロイ判断前）
- AV企業のV&Vチーム（変更受け入れ前） など
アセスの要諦：
- 必要な状況を十分に**テスト（カバレッジ）**したか
- 状況に応じた**適切な基準（チェック）**を適用したか
- 結果が目標安全度を満たすほど十分か
良い出発点は安全ケースであり、そこには対象状況（カバレッジ）、行ったチェック、結果が示されます。
情報（安全ケース、VPlan／カバレッジ結果、KPI／チェック、トリアージ結果等）を任意の深さまで掘り下げ、信頼性を確認できる必要があります。AIアシスタントによるディベート（賛否両論）支援も有用でしょう。
最終的には、透明性、人間の用語、明確な抽象化が不可欠です。
抽象化（アブストラクション）の役割
アセスには抽象化が必要です。状況・チェック・結果を直感的だが形式的に定義された用語で表す必要があります（例：TTC、無保護右左折、ローリングストップ、左側通行国、最小リスク操作）。
実装がこれらの抽象に限定される必要はありません（曖昧なケースも扱えるため望ましい）。ただし挙動の評価や、学習への影響には抽象化が必要です。
非形式的抽象化（例：テキスト→シナリオ）も有用ですが、精密ではないため、形式的抽象化の代替にはなりません。
カバレッジ抽象化
ODDのカバレッジマップを定義するには、操舵・天候・故障など多くを考慮します。
例えば操舵空間をシナリオ（無保護右左折、四方向停止等）に分割し、さらにケース（カバレッジビン）に細分化します（例：左／右の無保護右左折、黄信号から進入までの時間レンジ、交差時の最接近車両速度レンジ、PET＜N秒のニアミス等）。
これらの用語（無保護左折、PET等）は全て厳密定義が必要です。さらに、他の抽象（「パンク」「センサー無効」「緊急車両進入」等）と合成する場合もあります。
したがって、どのシナリオが起きたかの評価、どのビンに分類するか、PET等の測定を行う形式言語が必要で、解釈の齟齬がない透明性が求められます。
チェックとKPIの抽象化
チェックはさらに複雑で、より多くの抽象化を必要とします：
- 各種KPIの計算（PET、TTC等）
- ルール／慣行の遵守（例：ローリングストップ禁止）
- 文脈依存のチェック（例：実行必須の場合を除き実線越え禁止） → 文脈シナリオの定義が必要
- 国・ODD依存（例：四方向停止がない国、雨非対応時の最小リスク操作の確認）
**未知の危険（SOTIF）**発見も抽象化が不要に見えるかもしれませんが、実際には：
- 既知の抽象次元を賢く混合しつつ、パラメータをランダム化した新データ生成が有効
- ランダム化しても妥当性を保つには抽象化が必要（例：PET＜3秒の無保護左折）
- 悪化兆候（低TTC等）を抽象的に指標化 → データ駆動探索で問題に迫る → 未知を既知化
非形式的抽象化の役割
非形式的（マルチモーダルFMベース等）抽象化は極めて有用です。重要なのは使い所と形式的抽象化との組み合わせとなります。
- テキスト→生成シナリオ：厳密な制御は難しくても、迅速で直観的な誘導に有用。形式的抽象化で結果を評価できることが前提
- テキスト→マッチング事例：やや曖昧な概念（「譲るべき」「歩行者に配慮」等）が必要な場合に有効
多くの状況で、「正しさ」は非形式的抽象化に部分的に依存します。しばしば、抽象には明確な形式的サブセットがあり（単純なルールで判定）、その周囲に曖昧な領域が存在します（違反しても警告に留める等）。
まとめ ― 4つの要点
- AIベース自律は急速に前進している
- その結果、V&Vの相対的重要性が上昇している
- 実装とV&Vの双方でデータ自動化の重要性が高まっている
