本シリーズの第1部では、自動車業界のデータインフラがインテリジェンスインフラを凌駕してしまった理由について解説し、そのギャップを埋めるためのSonatusのフレームワーク「Agentic Loop」（検知 → 収集 → 推論 → 実行 → 学習）を紹介しました。第2部では、各段階が実際にどのような役割を果たすのか、またなぜその順序が個々の段階と同様に重要なのかについて、具体的に解説していきます。
DETECT
検出はループの起点であり、その質によって下流のすべての処理の質が決まります。検出が不十分だと、システムにノイズが溢れかえってしまいます。一方、適切に行われれば、それは精密なフィルターとして機能し、重要な信号を浮き彫りにしつつ、重要でない信号は無視します。
自動車システムにおける従来の検出手法は、閾値の超過、故障コードのトリガー、合否の二値判定といったルールに基づく傾向があります。これらのルールは、既知の故障モードに基づいて、ある時点においてエンジニアによって策定されたものです。それらは、定義上、事後的なものであり、問題が発生するより広範なシステムの文脈から切り離された状態で、すでに確認されている問題を検出するように調整されています。
エージェント型アーキテクチャにおける検知は、これとは異なります。このアーキテクチャでは、確率的かつ文脈に応じて動作し、複数の車両ドメインにわたるパターンを同時に活用します。つまり、パワートレインや熱管理、車両ネットワークといった各領域を個別に扱うのではなく、それらの交差する部分に着目するのです。特定の走行シナリオにおいて、特定のネットワークトラフィックパターンと一致する熱事象は、その熱事象が単独で発生した場合とは異なるシグナルとなります。 文脈によって意味は変わり、適切なタイミングで正しいシグナルを抽出するためには、検知システムが文脈を認識できる必要があります。
重要な点は、検出が継続的に行われるということです。つまり、テスト日の終わりにバッチ処理として行われるのではなく、車両のインテリジェンス・インフラストラクチャに組み込まれたリアルタイムのレイヤーとして機能するのです。これこそが、このループを単なる分析的なものではなく、能動的なものとしているのです。
COLLECT
調査する価値のあるものが検出されると、収集段階において、どのデータを収集するか、そして同様に重要なこととして、どのデータを収集しないかが決定されます。
ここでの変化は、常時ロギングから、イベントをトリガーとした的を絞ったデータ収集への移行です。常時ロギングでは膨大な量のデータが生成されますが、その大部分は決して分析されることはありません。携帯電話ネットワークを介して送信するコストも、保存するコストも、データを処理するコストもかかります。さらに重要なのは、大量のログには通常、実用的なアクションにつなげるために必要な文脈が欠けているという点です。データ収集のきっかけとなった要因が分からなければ、生のテレメトリデータを解釈することは困難です。
イベント駆動型の収集では、この関係が逆転します。検出レイヤーが調査に値するシグナルを特定すると、収集ステージはターゲットを絞ったキャプチャを構成します。つまり、適切なチャネル、適切な時間ウィンドウ、適切なクロスドメインのコンテキストを、対象となるイベントの周囲で正確にキャプチャするのです。エンジニアは、ギガバイト単位の連続したログではなく、そのイベントが発生した状況に関する詳細な注釈が付けられた、重要なデータのみを受け取ることになります。
これにより、再実行が不要になります。以前は失われていたコンテキスト――つまり、誰かがロガーを設定する前にウィンドウが閉じてしまった状況――が、システムがすでにそれを監視していたため、初回で捕捉されるのです。プロトタイプを再度実行する必要はありません。エンジニアたちは必要な情報をすでに得ているのです。
理由
推論は、インテリジェンス・アーキテクチャとデータ・アーキテクチャを最も明確に区別する段階である。この段階で、ループは「何が起きたか」から「なぜ起きたか」へと移行する。
車両システムは極めて複雑であるため、手作業による根本原因の分析はますます困難になっています。パワートレイン、熱管理、ADAS、車両ネットワークといった領域間の相互作用により、単一のデータストリームだけでは明確に把握できない故障モードが生じます。経験豊富なエンジニアであっても、CANログ、イーサネットキャプチャ、センサーデータ、システムイベントトレースにわたる信号の相関関係を分析し、根本原因に関する仮説を立てるのに数日かかることもあります。 そして、その専門知識は容易に引き継ぐことができません。それは個々のエンジニアに宿るものであり、長年の診断業務を通じて蓄積されたものであり、その人材が転職などを検討した瞬間に、人材流出のリスクとなるのです。
エージェント型アーキテクチャにおける推論段階では、まさにこのような多源・多分野にまたがるデータに対して、AI を活用した分析を行います。これはエンジニアの判断に取って代わるものではなく、データから仮説に至るまでの時間を短縮するものです。エンジニアが確認、検証、そして対応できるよう構造化された形で、裏付けとなる証拠とともに根本原因の候補を提示します。エンジニアは引き続きプロセスに関与し続けますが、そのプロセスは単に高速化され、個人が手作業で処理できる範囲をはるかに超える複雑さに対応できるようになります。
このことには、業界が過小評価しがちな「知識の保存」という側面もあります。診断の専門知識が推論層に組み込まれる――つまり、熟練エンジニアが蓄積してきたパターン認識が、彼らの頭の中だけに留まるのではなくシステムに組み込まれる――ことで、それは永続的な組織資産となります。それは消滅することなく、蓄積されていくのです。
ACT
「行動段階」こそが、このループを単なる分析的なものに留まらず、真に能動的なものにする要素である。これがなければ、「能動的ループ」は洗練された報告システムに過ぎない。これがあることで、知能という結果が生まれるのである。
対応の範囲は意図的に広く設定されています。一方の極端な例としては、検証エンジニアがすでに使用しているツールを介して、裏付けとなる証拠と根本原因の候補を伴った構造化された調査結果を提示することが挙げられます。もう一方の極端な例としては、特定の車両グループに対してOTAによる設定更新をトリガーしたり、特定のディーラー店舗にある車両に対してサービス推奨事項を通知したりすることが挙げられます。 これら両極端の間には、推論の信頼度、決定の重要度、およびOEMの組織方針に合わせて調整された、さまざまな自動および半自動の対応が存在します。
アクション層は、このループが最も顕著なビジネス価値を生み出す場でもあります。以前は、対応するために数日間の手作業による分析や定例会議が必要だった分析結果が、数時間で明らかになり、広まっていくようになります。以前は保証請求の急増をきっかけとして初めて実施されていた車両品質への介入も、顧客からの最初の苦情が届く前に実施できるようになります。
学ぶ
「学習段階」こそが、エージェントループを、これまで車両の知能化に適用されてきた他のあらゆるアプローチと一線を画すものであり、かつ、すべての段階の中で戦略的に最も重要な段階である。
このループの各段階は、それ単体でも価値があります。しかし、学習段階がなければ、ループは静的なものになってしまいます。つまり、1,000サイクル目における検知、収集、推論の質は、1サイクル目と何ら変わりません。学習段階は、文字通りの意味でループを完結させます。つまり、結果が検知モデルや推論知識ベースにフィードバックされ、何が確認されたか、何が誤りだったか、そしてどのような新しいパターンが現れたかに基づいて、それらが更新されるのです。
つまり、このシステムは時間の経過とともに明らかに向上していくということです。それは、わずかな改善が積み重なるような漸進的な向上ではなく、複利的な向上です。なぜなら、各サイクルがシステムの蓄積された知性に加わり、それによってその後のすべてのサイクルの質が向上するからです。これがOEM戦略にとってなぜ重要なのかについては、後ほど改めて触れます。なぜなら、これがこのアーキテクチャがもたらす最も重要な意味だと私たちは考えているからです。
なぜ「オペレーティングシステム」が適切な比喩なのか
オペレーティングシステムの比喩については、正確に定義しておきましょう。なぜなら、正しく根拠付けられていないと、単なるポジショニングのための言葉に聞こえてしまう恐れがあるからです。
オペレーティングシステムは、アプリケーションの機能そのものを実行するものではありません。アプリケーションが本来の目的である機能に集中できるように、基盤となるリソース（演算能力、メモリ、I/O）を管理します。また、多種多様な処理が効率的に実行できる、安定した共有プラットフォームを提供します。
「エージェントループ」は、車両のインテリジェンスにおいても同様の役割を果たします。これは、車両データに内在する複雑さ（検知、収集、推論、実行、学習）を管理することで、その上に構築を行うチームが、エンジニアリング上の意思決定、製品品質の向上、顧客へのサービス提供といった本来の業務に集中できるようにします。エージェントループは、これらの機能を置き換えるものではありません。むしろ、エージェントループを活用することで、各機能が、それなしの場合よりもはるかに高いスピードと品質で運用されるための環境を整えるのです。
また、オペレーティングシステムと同様に、その上で動作する機能が多ければ多いほど、その価値は高まります。検証、品質、サービスにまたがる共有されたインテリジェンス基盤は、各部門が孤立して同じ機能を展開する場合よりも価値が高いのです。なぜなら、検証段階で学習されたパターンが現場での検出に役立ち、現場で確認された故障モードが検証のベースラインにフィードバックされるからです。このループは、単一の機能内だけで循環するのではなく、機能同士を結びつける役割を果たしています。
「ループ」の実践：SOP前とSOP後
このループのアーキテクチャは、車両のライフサイクルを通じて変化することはありません。変化するのは、データソースと、ループの最終段階で行われる処理の内容です。
SOP前の検証段階では、このループは、構造化および非構造化のテストシナリオを実行する試作車両に対して動作します。 検出機能は、試走中にリアルタイムで異常を特定します。ターゲットを絞ったデータ収集により、車両がthe garage に戻り、ウィンドウが閉じる前に、その場ですぐに関連するコンテキストを捕捉します。推論機能は、検証チームに対してその日中に、場合によってはそれよりも早く、根本原因の候補を提示します。対応策としては、テストプロトコルの即時調整や、担当のエンジニアリングチームへの設計上の指摘などが挙げられます。学習機能は、次のテストサイクルに向けて検出モデルと推論モデルを更新するため、システムは以降のテストにおいて、何を注視すべきかをすでに把握した状態で臨むことができます。
SOP終了後、現場では、同様のループが量産車両のフリート全体で大規模に実行されます。検出プロセスにより、地域、走行サイクル、ソフトウェアバージョン、または環境条件ごとに集積する故障モードなど、新たに現れつつあるパターンが特定されます。対象を絞ったデータ収集により、その現象が発生している車両から得られた正確かつ再現性のある証拠を用いて、その兆候が裏付けられます。推論プロセスを通じて、フリートレベルで根本原因が診断されます。 具体的な対応策としては、特定のソフトウェア構成に対するOTAアップデート、顧客に不具合が顕在化する前の予防的なサービスキャンペーン、あるいは部品サプライヤーへの品質アラートの発出などが挙げられます。学習プロセスでは、新たな故障モードを検出のベースラインに組み込むため、次のプラットフォームにはその知見が最初から組み込まれた状態で開発が開始されます。
検証用車両と量産車群の間でアーキテクチャの構造が変わることはなく、変わるのはデータソースと最終的な処理のみです。しかし、この一貫性は単なる設計上の細部に留まりません。この一貫性こそが、この種のシステムが稼働期間が長くなるほど価値を高める理由であり、OEM各社が現在この問題についてどのように考えるべきかという点において、最も重要な論拠となっているのです。
