⚑ アナーバー、 ミシガン、米国
車両のSDV化（Software‑Defined Vehicle; ソフトウェア定義車両）が進むにつれ、ソフトウェア単体ではなく、そのソフトウェアが「システム全体の中でどのように振る舞うか」を検証することが、ソフトウェア開発そのものと同じくらい重要になっています。特に車両の安全上重要なシステムにおいて、その傾向が顕著になります。
今回のインタビューでは、ウーブン・バイ・トヨタのシステムエンジニアとして活躍する アンドリュー が、トヨタのように大規模で多様な条件を抱いた環境下で課題に対応するため、どのようなシミュレーション／検証基盤が構築しているのかについて語ります。シミュレーション、ハードウェア、実車までテストを一貫して保つ方法、その継続が困難な理由、さらに実社会への導入に求められるスピードと信頼性を確保しながら、学習駆動型の複雑なシステムをテストするための要件について紹介します。
Q：まずは原点からお聞きします。システムエンジニアリングに惹かれたきっかけは？
かなり意図的なキャリアチェンジでした。私は今まで制御エンジニア、ソフトウェアエンジニア、インテグレーションエンジニア、キャリブレーション（基準合わせ）の業務にも携わりましたが、どのチームにも必ずシステム全体の方向性を示すシステムエンジニアやアーキテクトがいました。
システムエンジニアはすべてのコードを書くわけでも、ソフトウェアやハードウェアを設計するわけではありません。ですが、各要素がどのように相互作用するかを理解し、プロダクトとしての姿を形作ります。システム全体を俯瞰し、全体の挙動に責任を持つ。そのスタイルに強く惹かれました。
Q：システムエンジニアになるには特別なバックグラウンドが必要ですか？
まったくそんなことはありません。ソフトウェア、電気、機械、ロボティクスなどさまざまな分野出身のシステムエンジニアがいます。私たちが扱う多くのシステムはソフトウェアとハードウェアの組み合わせなので、どれか一つでも経験があれば、十分に強力な土台になります。
大切なのは、特定分野の専門知識よりも、境界を越えて考えられること、トレードオフを見極めること、そして実社会でシステムがどう動くかを常に意識できるかどうかです。
Q：Arene におけるシステムエンジニアリングの役割とは？
車のソフトウェア開発は、一般的に次の3つの環境を行き来します。
スピードとスケールに最適化された純粋なシミュレーション環境
一部の実機ハードウェアを使用したベンチ環境
すべてが揃う最終的な車両環境
Areneのシミュレーションと検証では、それぞれの段階で「システムがどのように振る舞うべきか」という明確かつ共通の期待値をチーム横断で定義し共有します。そして、その期待値がツールやインフラに一貫して反映されるように設計しています。システムエンジニアリングは、こうした取り組みを通じて、Areneの製品が開発のあらゆる段階でステークホルダーのニーズと整合した状態を維持できるように支えています。
開発の初期段階から実車まで、「一貫性が失われないように保証する」ということは車載ソフトウェアでは非常に難しい課題です。ただ、それに取り組んでいる点がウーブン・バイ・トヨタのエンジニアリングの特筆すべき理由の一つでもあります。
Q：最終的にどのような課題を解決しようとしているのでしょうか？
私たちの大きな目的は、複雑になり続ける車のソフトウェアを、スピードを落とさず、かつ自信を持って開発できるようにすることです。
現代の車両では、数多くのシステムが相互依存しており、それぞれが異なるチームによって開発され、それぞれ個別に更新されています。ただ、ある一箇所の変更が異なるところで思わぬ影響を与えてしまうことは珍しくありません。そのため、ある変更がシステム全体にどう波及するかを把握できる仕組みが必要になります。
同時に、異なる環境間でソフトウェアの振る舞いの一貫性を保つことで、テスト結果への信頼性が向上し、より速く、安全に、開発を進めることができます。トヨタのような規模では、この「スピードと信頼性」の両立こそが、安全を重視したSDVを実現する鍵になります。
「トヨタのような規模では、『スピードと信頼性』の両立こそが、安全中心のSDVを実現する鍵になります」
Q：純粋なシミュレーション環境、部分的なハードウェア環境、そして実際の車両環境のすべてにまたがって作業することは珍しいとおっしゃいましたが、それはなぜでしょうか？
珍しいのは、そうしたすべての環境において、同じ観点や条件でテストの意図を一貫して実施することです。
多くの企業では、開発のフェーズごとに異なるツールやベンダーを利用しているため、テスト結果を比較したり問題の再現をしたりするのが非常に困難です。実車で発生した問題をベンチ環境で再現するのは難しく、ソフトウェアを素早く修正できる原因まで突き止めるのはさらに困難になります。
ウーブン・バイ・トヨタでは、テストやシナリオ、インターフェース、さらにシステム自体をあらゆる環境で複製、再利用できるように設計をしています。そのため、実車で問題が起きた場合でも、ベンチ環境やシミュレーション環境で同様の状況を再現することができ、それによって、より容易で安全に問題の調査を行うことができます。原因を突き止めて修正した際には、ベンチ環境から実車環境まで同じテストを段階的に実施し、実際に問題が修正されたことが確認できます。
「ウーブン・バイ・トヨタでは、テストやシナリオ・インターフェース、さらにシステム自体をあらゆる環境で複製、再利用できるよう設計をしています」
Q：シミュレーションの話をもう少し掘り下げてお聞かせください。シミュレーション上のコンポーネントが実車と同等の挙動を示すかどうかは、何が決め手になるのでしょうか？
重要なのは大きく二つあります。プロトコルの忠実度と振る舞いの忠実度です。
プロトコルの忠実度とは、同じ言葉を話すことです。メッセージIDやデータ形式、タイミング、状態遷移が実車と同じであることを意味します。
振る舞いの忠実度とは、出力が車両のダイナミクス（挙動）や各種オペレーティングモードに対して、正しく反応していることを意味します。
どちらか一方でも欠けると、下流のECU (電子制御ユニット）は「不正確なデータ」を受け取り、一見すると正常に動いているようでも、実際には原因の特定が難しい形で問題が起きていることが多々あります。
だからこそ私たちは、実際のコンポーネントが持つインターフェースや前提条件を忠実に再現することに強くこだわっています。とくにシミュレーション結果が安全上きわめて重要な判断に使われる場面では、その重要性はさらに高まります。
Q：具体的な例を教えてください。
例えば、「急ブレーキ時のセンサー挙動」があります。急ブレーキにより車両の姿勢が変化すると、センサーが取得する情報も変化します。リアルなシミュレーションであれば、この変化が数値だけではなくタイミングも含めて正確に反映されなければいけません。
もし更新が遅れたり、現実と異なる動きをすれば、下流のシステムは一見正しく動いているようで、実際には微妙に誤った動作や判断をすることがあります。そういった問題は見つけにくく、誤って解釈されがちです。
Q：ウーブン・バイ・トヨタで仕事をする中で、難度が高く、面白かった技術を教えてください。
リアルタイム要件を満たしつつ、実車内でセンサーECUをシミュレートされたセンサーデータで動作させたことです。
物理センサーを切り離し、環境シミュレーターからのデータをセンサーECUに入力します。車から見れば、入力がシミュレーションであることは分かりません。下流システムは「本物のセンサー」同様正しいレート、フォーマット、振る舞いでデータが届くことを期待しています。シミュレートされたコンポーネントは、重要な点に関して、実機と同じように振る舞わなければいけません。
とくに難しかったのは、車両の動きとシミュレーションを同期し続けることです。純粋なソフトウェア環境では多少ズレが許容される場合でも、実車では許されません。シミュレーションデータが実車の動きと完全に同期していない場合、ごく小さなズレであっても、現実とは異なる判断が引き起こされる可能性があります。
そのレベルの忠実度を実現するのは非常に難しい挑戦でしたが、達成できたときの手応えは格別でした。実車を使いながらも、複雑で安全上重要な挙動を、制御された形でテストできるようになったからです。
Q：トヨタのような規模での開発では、テストカバレッジや自動化、フォールトトレランス（耐障害性）の考え方はどのように変わりますか？
ソフトウェアが多様な車種・地域・構成をまたいで動作するようになると、少数のテストや手動チェックのみに頼ることはできません。規模が大きいほど、カバレッジ、再現性、自動化を強く意識する必要があります。
同じ中核的な振る舞いを、さまざまなシナリオや構成で繰り返し検証し、ソフトウェアが進化し続ける中でも、それを継続的に行える仕組みが必要です。
また、失敗の捉え方そのものも変わります。この規模では単に「壊れる」ではなく、挙動のわずかな変化、タイミングのズレ、特定条件下のエッジケースなど、より繊細な問題が多くなります。そうした問題を早い段階で検出し、正しく理解し、何百万台もの車両に届く前に対処できるよう、より細かな仕組みを整える必要があります。
この規模で開発するということは、必然的に高い規律が求められるということでもあります。
Q：自動車業界の外から来たエンジニアが働いていて、驚く点などありますか？
多くの分野でも、実世界に影響を与える仕事はありますが、ここでは自分が作るものと実世界での成果が、より直接的につながっています。ドライバーや同乗者、あるいは歩行者など、実際の人の安全や体験に影響します。その責任の重さは、直接関わってみて初めて実感できました。
Q：現在開発されている技術で、今後に期待していることを教えてください。
学習ベースのシステムでは、従来の単純な合否テストは機能しません。単一の出力を見るのではなく、分布や傾向、トレードオフといった全体的な振る舞いを見る必要があります。今取り組んでいるのは、その振る舞いを意図的に調べるための仕組み作りです。たとえば、「少し条件を変えたときに判断はどれくらい変わるのか」「運用境界付近でどのように振る舞うのか」「モデルを作り直したら、その振る舞いはどう変わるのか」と言ったことを確かめる方法です。
これにより、開発と検証の間に、もっと強いフィードバックの循環が生まれます。問題が起きてから気づくのではなく、もっと早い段階で、より体系的にモデルの振る舞いを理解できるようになります。その結果、AIが判断や行動を担う機能を、より確信を持って進化させていけるようになります。なぜなら、「ちゃんと理解したうえで世に出す」ことができるようになるからです。
AIをブラックボックスとして扱うのではなく、問いかけ、理解し、信頼できるものとして向き合っていく。その転換こそが、この取り組みをもっと面白く、やりがいのあるものにしています。