エージェント型AIが単なる支援ツールを超え、ワークフロー内で実行を担う局面が増えるなか、信頼性の確保が大きな課題になっている。複数ドメインを横断して推論し、エンジニアリングツールを呼び出しながら反復作業を進めるこうしたシステムは、厳格な安全性や性能、検証要件を満たす環境で動かなければならないからだ。MathWorks Korea専務のキム・ヨンウ氏は、こうした課題への対応策として「System-First Engineering」の重要性を指摘する。

AIが計画、実行、反復を主導する場合、個々の結果は妥当に見えても、システム全体では意図しない挙動を招くことがある。構成要素同士の相互作用が、新たなエラー要因になり得るためだ。

ソフトウェア定義製品でこうしたリスクが高まる背景には、AIの自律性そのものではなく、システムレベルの振る舞いを実行可能な形で表現できないエンジニアリングワークフローがある。現在、車両リコールでは5件に1件以上がソフトウェア関連の修正につながっており、同様の統合不具合は他のソフトウェア定義システムでも起きている。単体テストを通過したタイミング変更でも、元の挙動に依存する大きな制御ループに組み込めば問題化するケースがある。

こうした不具合が起きるのは、開発が進む過程でシステムレベルの挙動が一貫して評価されないためだ。そこで重要になるのが、開発初期からシステムレベルの動作を基準に据えるSystem-First Engineeringである。これはモデルベース設計によって実装される考え方だ。

前提条件に依存した受け渡しではなく、実行可能なシステムモデルを共通資産として使うことで、エンジニアとエージェント型AIの双方が参照できるシステムレベルの基準を整えられる。こうしたモデルは、機械、電気、ソフトウェアの各領域をまたぐ共通の動作基準として機能し、AIを抽象的な要件ではなく、検証済みのエンジニアリングワークフローに基づいて動かせるようにする。開発がチームや機能をまたいで広がっても、同じ挙動を一貫して解釈できるようになる。

System-First Engineeringは、エージェント型AIを構造化された環境の中で機能させ、意図しないリスクを抑える枠組みでもある。先進的なチームは、ハードウェアがそろう前の段階からシステムを仮想化し、自動化ワークフローを通じてシステムモデルを継続的に評価している。主な手段はCI/CDパイプラインと閉ループシミュレーションだ。

エージェント型AIは、モデル、テスト、検証活動を調整し、必要に応じて直接実行することで開発ワークフローを加速する。モデルベース設計で自動化できる工程を呼び出し、各段階の実行方法を定義した事前定義のプロセスモデルに沿って処理を進める形だ。

この環境では、エージェント主導の変更は後工程の統合不具合として表面化する前に、システム挙動の基準に照らして早い段階で評価される。エンジニアはエージェント型のプロセスと結果を監視し、最終的なV&V（Verification and Validation）の承認責任を担う。AIによる実行を個別成果物ベースではなく、システムレベルの根拠に基づいて統制できるようになる。

エージェント型AIへの信頼の土台になるのは再現性だ。そして再現性を支えるのが、追跡性と安全性レビューに必要な監査可能な証跡を一貫して残せる決定論的検証である。

System-First Engineeringを導入するチームは、解釈のぶれを招きやすい文書ではなく、システムアーキテクチャや設計からコード生成、テストまでを結ぶ実行可能な仕様を使う。これにより、エージェントが加えたすべての変更を同じシステム動作基準で評価できる。

ソフトウェアは日次で反復開発できる一方、ハードウェアには数週間から数カ月かかる。こうした状況で検証をハードウェアに依存させるのは現実的ではない。そこでチームは、構築済みのシステムモデルをシミュレーションで継続的に実行し、高コストなハードウェア試験への依存を減らす。ソフトウェア、アーキテクチャ、制御ロジックに加えられたあらゆる変更は、システム全体を表すモデル上で決定論的に検証される。

その結果、タイミング目標の未達や過剰なメモリ使用といったシステムレベルの不具合を、ハードウェア段階に入る前に捉えられる。再現可能な検証根拠があることで、作業が複雑化してもチームはエージェント型AIによる変更をレビューし、認証しやすくなる。

次に問われるのは、信頼を確立した上でエージェント型AIをその環境内でどう動かすかだ。エージェント型AIはエンジニアリングワークフローの中で、システムモデル、コンポーネントモデル、テストケース、シナリオ変形といった成果物を扱う。これらの多くは生成AIで作成できる。

もっとも、エージェント型AIの本質的な役割は成果物を作ることだけではない。変更が検証されるワークフローの中で、それらの成果物を扱う点にある。例えば、エージェントがタイミングパラメータを変更し、その変更自体はテストを通過しても、元の速度に合わせて信号を受け取るよう調整されていた下位コントローラが信号を誤って解釈する可能性がある。

こうした失敗を防ぐには、エージェント型AIを生成と実行を切り分けたワークフローの中で動かす必要がある。エージェント型AIは、シミュレーション、コード生成、解析、テストを含む既存のモデルベース設計ワークフローの自動化をさらに一段進める存在といえる。

これらのワークフローは、Simulink Agentic Toolkitのようなツールで実装できる。何が実行可能で、何が検証可能かを定義するのはSystem-First Engineeringの役割であり、自動化ステップをいつ、どのように適用するかを決めるのがエージェント型AIの役割だ。

System-First Engineeringを適用し、エージェント型AIをエンジニアリングワークフローに組み込むプロセスは段階的に進む。一般にエンジニアは、まず1つの機能と1つのチームから始め、自動化したシミュレーションとテストのワークフローでシステムモデルを検証した上で、隣接チームへと広げていく。

エージェント型AIは変更を生成・評価し、検証プロセスは次の段階に進む前に、その変更が適切にテストされたかを確認する。多くのチームは、全チームに同じCI/CDパイプラインと検証ガードレールを提供する共通の開始環境を整備する。特定のグループだけがモデルを運用し、CIや分野横断活用が進まない断片的な導入を避けるためだ。

この共通環境によって、エージェント型AIは孤立した形で導入されるのではなく、一貫したシステムレベルの文脈の中で稼働できる。結果として、ワークフローを分断せずに安定的な拡張が可能になり、AI主導の実行に対する信頼構築の基盤も整う。

ソフトウェア定義製品の開発は、チームが単一ドメインだけをシステムとみなし、エンジニアリング全体を見渡せなくなったときに破綻しやすい。エージェント型AIへの信頼も同じ条件で崩れる。

堅牢な製品づくりには、従来から妥協のない原則が求められてきた。今後はその原則をエージェント型AIにも同じように適用しなければならない。

実行可能なモデルでなければ、それは単なる意見にとどまる。コードは個々のコンポーネントの動作を定義できるが、実行可能なシステムモデルは、システムレベルで各コンポーネントがどう相互作用するかを示す共通基準を提供する。

変更がシステム全体モデルでの検証を通過しない限り、その変更は適用すべきではない。ローカルテストを通過した変更でも、システムの別の部分で回帰を引き起こす可能性があるためだ。

また、実運用条件を反映したシミュレーションで動作が検証されていなければ、それも推測の域を出ない。潜在的な故障モードは、ハードウェア試験や現場運用の段階になって初めて見つかることがあり、その時点での手戻りは大きなコストを伴う。

要件がモデル、テスト、データと結び付いていなければ、システム実装との整合性は崩れる。どのモデルやテストが各要件を検証しているのか追跡しにくくなり、実装された動作が当初の意図から外れる恐れがある。

エージェント主導の変更が、実行可能なモデル、決定論的な解析、人によるレビューで検証できないのであれば、その変更は受け入れるべきではない。そうした検証がなければ、レビューや承認の過程で何が、なぜ変わったのか、その変更がシステムレベルの要件を満たしているのかを説明できない。

最終的に、エンジニアはエージェント主導の変更に対する統制を維持し、システムレベルの根拠に基づいて結果をレビューし、承認する責任を負う。問題が起きた場合も、ほかのエンジニアリング課題と同様に、モデルとテストで追跡し、診断し、修正した上で次の段階へ進むことになる。

適切なツール、プロセス、実務を備えてシステムを設計するチームは、システムレベルの確信を失うことなくエージェント型AIを導入し、信頼できるソフトウェア定義製品を提供できる。一方で、それらを欠くチームは、統合、認証、あるいはリコールの段階で、エージェント型の動作が持つ限界に直面する可能性がある。