著者： ダウウェイ・ビークルのCEO、ジョニー・リュー
公開日： 2026年7月9日
読了時間： 15分
カテゴリ： 電気自動車、AIエンジニアリング、モデルベース設計（MBD）
Table of Contents
チャットボットブームを超えて
自動車ソフトウェアエンジニアリングチームが次のようなフレームワークを検討する場合 エルメス代理店 または オープンクロー そして単に「より賢いチャットボット」と見なすだけでは、使い方が間違っています。特に「3電気」システム（バッテリー管理システム）における高信頼性自動車R&Dにおいては、[BMS]車両制御ユニット[VCU]、およびモーター制御ユニット[MCU])AIの真の価値は、エンジニアのために最終決定を下すことではない。
むしろ、その価値は、ファイルアクセス、ツール呼び出し、CLIコマンド実行、ブラウザサンドボックス、エンタープライズ知識検索を整理する能力にある。 監査可能で決定論的なエンジニアリングパイプライン。
この記事では、AIエージェントが安全性を損なうことなく、モデルベース設計（MBD）の断片化されたツール群をどのように橋渡しできるかを説明し、単純なツール呼び出しから完全なエンジニアリングのクローズドループに至るまでの明確な道筋を示します。
1. エンジニアリングにおける根本的な問題点：断片化されたファイル、サイロ化されたツール、そして途切れた証拠連鎖
経験豊富なパワートレインソフトウェアエンジニアなら誰でも、典型的な制御システムの不具合は、単一の孤立したファイルに起因することはほとんどないことを知っています。次の標準的なトラブルシューティングシナリオを考えてみましょう。
- 症状： 低温条件下では、バッテリー充電電力制限が予期せず低下します。これに伴い、トルク制限が断続的に発生し、診断トラブルコード（DTC）が実際のコントローラー出力とシステム仕様と不一致を示すことがあります。
この問題を診断するには、エンジニアは膨大で断片化されたデータセットを同時に開き、解析し、相互参照する必要がある。
[System Requirements] ── (DOORS / Word)
│
[Software Model] ── (MATLAB Simulink / Stateflow)
│
[Network Interfaces] ── (DBC / ARXML)
│
[Memory Mapping] ── (ASAP2 / A2L / Calibration Parameters)
│
[Real-world Behavior] ── (Vector CANoe Trace / CANape Logs / MDF4)
断片化の4つのレベル
このワークフローは、4つの異なる側面における深刻な断片化を浮き彫りにしています。
- ファイルレベルの断片化： 要件は Word または IBM DOORS に存在し、制御ロジックは MATLAB Simulink モデルに存在します (
.slx）およびステートフローチャート。バスインターフェースはで定義されています。.dbcまたは.arxml; メモリ アドレスは以下のように定義されます.a2l; テストスクリプトはCAPLまたはPythonで記述されています。テストログは.mdf、.dat、 または.csvファイル。 - ツールチェーンの分離： エンジニアは常に作業環境を切り替える必要がある。MATLAB/Simulink（モデル設計）からVector CANoe（バスシミュレーション）、Vector CANapeまたはTsMaster（キャリブレーション/測定）、Excel（データマッピング）、そして社内Webベースの課題追跡システム（Jira）へと、次々と作業環境を切り替えるのだ。
- 意味の不整合： まったく同じ物理変数（例えば、目標バッテリー充電電流）は、別の名前で呼ばれるかもしれない。
目標変更額機能要件仕様書において、bms_I_targetSimulink モデルワークスペースでは、BMS_ターゲット電流CAN DBC信号データベースにおいて、P_BMS_Chg_Curr_Limitキャリブレーション用のA2Lファイルには、サンプリングレート、スケーリング係数、単位、有効値範囲などが異なる場合が多い。 - 証拠連鎖の欠落： 生成型AIは仮説的な根本原因を容易に示唆できます。しかし、その示唆がログ内の特定のミリ秒、トレース内の特定の信号遷移、Simulinkモデル内の特定のパス、または特定のテストケースIDを指し示すことができない場合、 工学的結論として受け入れられない。
問題は、LLMがどれほど優れているかということではない。問題は次の点だ。 AIエージェントはMBDツールチェーンの中でどのような位置づけにあるのか、どのようにファイルにアクセスするのか、いつスクリプトを呼び出すことが許可されるのか、そしていつ停止して人間のエンジニアに制御を戻す必要があるのか？
2. 従来の自動化の限界とエージェントの境界
自動車業界のソフトウェア部門は、数十年にわたり自動化スクリプト（MATLAB API、Python DBCパーサー、CAPLテストスイート、CI/CD Jenkinsパイプライン、Excelマクロなど）を使用してきました。これらのツールは、高い決定性、再現性、そして完全な監査可能性を備えています。
しかし、これらの手法はコンテキスト切り替えコストが高いという欠点がある。PythonスクリプトはDBCを解析でき、MATLABスクリプトはモデルチェックを実行できるが、意味的なコンテキストを共有していない。
以下のマトリックスは、従来の自動化スクリプトが限界に達する箇所と、AIエージェントが介入すべき箇所を定義しています。
| エンジニアリングアーティファクト | 従来の自動化には限界がある | AIエージェントの境界 |
|---|---|---|
| Simulink / Stateflow | スクリプトは（Model Advisorのような）静的設計ルールチェックを実行し、XMLレポートを生成します。しかし、これらのレポートを解釈し、不具合をシステム要件に紐付けるには、依然として手作業が必要です。 | エージェントはモデルアドバイザーのレポートと元の仕様を読み込み、不具合をマッピングし、優先順位付けされたエンジニアリング問題リストを生成します。 一度もない モデルファイルを直接編集します。 |
| DBC / A2L / MDF | PythonやCANapeのスクリプトを使えば信号リストを抽出できるが、DBCとA2L間で変数をマッピングするには、エンジニアが手動で、しかも壊れやすいExcel変換テーブルを維持管理する必要がある。 | エージェントは、DBC、A2L、およびモデル全体にわたるスケーリング係数、データ型、物理単位、およびキャリブレーションパラメータのバージョンを分析することにより、意味マッピングの不一致を動的に解決します。 |
| カヌー / CAPL | 自動テストベンチはテストスクリプトを実行し、HTML形式のテストレポートを出力します。しかし、「失敗」判定の根本原因を特定するには、ログを手動で追跡する必要があります。 | エージェントはCANoeテストトレースとCAPLログファイルをスキャンし、正確な障害発生タイムスタンプを特定し、それを診断コードと関連付け、CAPLスクリプトの修正案を作成します。 |
| 要件仕様 | 標準スクリプトでは、要件文書にIDフィールドがあるかどうかを確認できますが、テキストの明瞭さを評価したり、テストカバレッジをマッピングしたりすることはできません。 | エージェントは、機能的な受け入れ基準を抽出し、実際のテストポイントと照合して、エンドツーエンドのトレーサビリティマトリックスのドラフトを生成します。 |
| 内部ウェブツール | エンジニアは、トレースログや診断エラーコードをJira、Confluence、または社内ナレッジベースに手動でコピー＆ペーストする必要があります。 | エージェントは検索および取得ツールを使用して内部データベースをスキャンし、過去の問題ログを相互参照し、参照元URLとともに参照情報を記録します。 |
3. リファレンスアーキテクチャ：オーケストレーション層におけるLLM
安全性が重要なシステム開発（ISO 26262 ASIL-D ソフトウェアパイプラインなど）で AI エージェントを安全に展開するには、LLM は厳密に オーケストレーションレイヤー完全に隔離された 安全実行ループ。
┌────────────────────────────────────────────────────────┐
│ HUMAN ENGINEER (Review) │
└───────────────────────────▲────────────────────────────┘
│
[State / Logs] │ [Approve / Correct]
│
┌───────────────────────────▼────────────────────────────┐
│ LLM ORCHESTRATION LAYER (Agent) │
│ - Plan Formulation - Context Assembly │
│ - Semantic Mapping - Reasoning & Tool-calling │
└───────────────────────────┬────────────────────────────┘
│
[Authorized Tool Calls] / [Structured Outputs]
│
┌───────────────────────────▼────────────────────────────┐
│ AUDITABLE EXECUTION LAYER │
│ ┌───────────────────────┐ ┌───────────────────────┐ │
│ │ Sandboxed Environment│ │ Whitelisted Tools │ │
│ │ - Read-Only Snapshots│ │ - MATLAB / CANoe APIs│ │
│ │ - Isolated Browsers │ │ - Python/CAPL Parsers│ │
│ └───────────────────────┘ └───────────────────────┘ │
└────────────────────────────────────────────────────────┘
フレームワークとしては オープンクロー ツールを、エージェントが呼び出すことができる構造化された関数（実行、Web 取得、ローカル検索、メッセージング）として定義します。同様に、 エルメス代理店 ローカルサンドボックスを使用して、システムユーティリティを安全に実行します。
自動車ソフトウェアに関しては、以下の5つの絶対的なセキュリティ対策を確立する必要があります。
- 読み取り専用ストレージのサンドボックス化： エージェントは、ワークスペースの読み取り専用スナップショットまたは専用のgitブランチ上で動作する必要があります（
./project_snapshot) 生産ブランチ、暗号鍵、または独自のベースラインリポジトリへの書き込みアクセス権を決して持たせてはならない。 - ホワイトリストに登録されたツール呼び出し: エージェントは生のシェルコマンドを実行することはできません。代わりに、事前に作成された決定論的なPythonまたはMATLABランナースクリプトのホワイトリストを呼び出すことで、エンジニアリングエコシステムと連携する必要があります。
- 実行制約ログ記録: すべてのスクリプト実行は厳密なディレクトリ内で実行され、実行タイムアウト制限が適用され、すべての
標準出力、stderr終了コード、および入力ファイルのハッシュ値。これらのログは、変更不可能な監査証跡として保存されます。 - 分離されたブラウザプロファイル: Webから情報を取得する場合（ASAM標準定義の検索や社内Jiraボードの確認など）、エージェントは、個人または企業のSSO認証情報から完全に隔離された専用のブラウザプロファイルを使用する必要があります。
- ナレッジベーステナントの分離： 独自のキャリブレーションガイドラインや過去のプロジェクトのデバッグデータを含む検索拡張生成（RAG）データベースに接続する場合、システムは顧客間のIP漏洩を防ぐために、厳格な役割ベースのアクセス制御（RBAC）を適用する必要があります。
4. ステップバイステップの統合：エージェントとMBDツールチェーンのマッピング
AIエージェントが完全な4ステップのMBDワークフローをどのように実行するのかを見ていきましょう。
Step 1: Parse Specs ──► Step 2: Scan Model ──► Step 3: Align Signals ──► Step 4: Parse Logs
(Requirements to (MATLAB Report (DBC to A2L (CANoe Trace
Test Matrix) Analyzer) Mapping) to Evidence)
ステップ4.1：テストマトリックス作成のための要件仕様書
エージェントは、要件ドキュメント（DOORSからエクスポートされたマークダウンファイルやJSONファイルなど）を取り込み、各機能句を分析して以下の情報を抽出します。
- 前提条件（例：
バッテリー温度 < -10°C） - アクティブ入力（例：
Charge_Plug_Detected == TRUE） - 期待されるシステム出力（例：
最大変化電流制限 == 15A） - 関連する診断上の疾患。
エージェントは最終的なコードを書こうとするのではなく、構造化された テストマトリックス案 JSON形式で、後続のMIL/SIL/HILテストのための明示的な検証ポイントを定義します。
ステップ4.2：モデル検証によるチェックリストの発行
エージェントは Simulink モデルの変更をブロックされています (.slx）または Stateflow チャートを直接実行するのではなく、コマンドライン インターフェイスを介してローカルの MATLAB スクリプトを呼び出します。このランナー スクリプトは次のとおりです。
- MATLABをヘッドレスセッションで起動します。
- カスタムの静的設計ルールチェッカーを実行します（命名規則のチェックや、リンクされていない信号ポートの検索など）。
- 構造化された診断レポートを出力します。
エージェントはこのレポートを読み、ソフトウェア設計ガイドラインと照合し、エラーを強調表示する構造化されたチェックリストを生成します（例：「ステートフローチャート」）。 チャージマネージャー デフォルトの遷移パスがありません。
ステップ4.3：DBC、A2L、およびキャリブレーションフィールドのセマンティックマッピング
このステップでは、物理的な通信信号をコントローラの内部メモリと照合します。エージェントは専用のPythonパーサーを呼び出し、CAN DBCファイルとコントローラA2Lファイルを読み取ります。
次に、統一された変数マッピングテーブルを作成し、重大な不一致がないかを確認します。
[Signal: BMS_Target_I] ── (DBC Unit: Ampere | Scale: 0.1 | Offset: 0)
VS
[Parameter: Target_I_Cal] ── (A2L Unit: Ampere | Scale: 0.01 | Offset: -40)
▲
[Agent Flags Mismatch]