システムズエンジニアリングの最前線で、AIは何を変え始めているのか

はじめに

第1回では、フロンティアAIが、単体の業務やシステムを支援する存在にとどまらず、複数のシステムの接続、依存関係、意味構造を読み解く存在になりつつあることを見ました。AIがシステム間の関係を読み取り、判断や実行に関与し始めると、製造業における競争力の論点は、AIをどこに導入するかだけでは整理しきれなくなります。

第2回では、この論点を、製造業の開発フェーズに着目して考えます。航空宇宙や自動車をはじめとする複雑な製品開発では、システムズエンジニアリング、MBSE、Vモデル、要求定義、検証・妥当性確認といった考え方が使われてきました。これらは、複雑な製品やシステムを、構想、設計、実装、検証、運用まで一貫して成立させるための基盤です。

その最前線では、AIをどのように取り入れるかが新しい論点として広がっています。AIを便利な支援ツールとして使うだけでなく、要求、設計、検証、運用、更新の流れの中で、どのように位置付けるかが問われ始めています。第2回では、システムズエンジニアリングの最前線から、AIが何を変え始めているのかを整理します。

システムズエンジニアリングの最前線で起きていること

製造業では、航空宇宙や自動車などの領域で、MBSE、Vモデル、要求定義、検証・妥当性確認といった考え方が使われてきました。これらは、複雑な製品やシステムを、構想から設計、実装、検証、運用まで一貫して成立させるためのシステムズエンジニアリングの考え方に支えられています。

中でも航空宇宙は、高い信頼性と安全性が求められる複雑なシステムを扱う領域として、システムズエンジニアリングを深く実務に組み込んできた分野の一つとして捉えることができます。航空機や宇宙機器では、多数のサブシステム、部品、ソフトウェア、運用条件、認証要件が複雑に関係します。そのため、個別の設計だけでなく、要求、機能、構成、検証、運用をライフサイクル全体で整合させる見方が重要になってきました。

そのシステムズエンジニアリングの最前線でも、AIを開発ライフサイクルにどのように組み込むかが、重要な論点になりつつあります。いわゆるAI4SE（AI for Systems Engineering）、すなわちシステムズエンジニアリングのためのAIと、SE4AI（Systems Engineering for AI）、AIのためのシステムズエンジニアリングという議論です。AIを便利な支援ツールとして使うだけでなく、要求、設計、検証、運用、改訂の流れの中で、どのように位置付けるかが問われ始めています 。

従来のシステムズエンジニアリングでは、システムの構成、要求、機能、検証、運用を体系的に扱ってきました。Vモデルは、その代表的な枠組みの一つです。左側で要求、構想、設計を段階的に具体化し、右側で実装、統合、検証を進めることで、システム全体の整合性を確認していきます。この考え方は、AIが組み込まれる時代においても、開発と検証の基盤であり続けます。

AIやデジタルエンジニアリングが入ることで重要になるのは、Vモデルを捨てることではなく、大きなVモデルの中で、小さな単位の仮説検証を繰り返すことです。Vモデルの左側では、過去の設計知識、要求、制約条件、標準、故障モード、運用シナリオを参照し、設計の選択肢や影響範囲を早期に検討する。右側では、デジタル上での検証を活用し、品質上の懸念や設計上の不整合を前倒しで低減する――こうしたフロントローディングが、後段の物理検証に持ち込むリスクを減らしていきます。

ただし、航空機のように高い信頼性と厳しい認証が求められる領域では、最終的な安全確認や認証に向けた物理検証が、コンポーネントレベルから製品統合レベルまで残ります。デジタルエンジニアリングやデジタルツインは、物理検証を不要にするものではなく、物理検証に入る前に不確実性や不整合を減らすための基盤として捉えることが重要です。

一方で、そこにAIが入ることで、ナレッジ参照、判断材料の作成、検証支援、承認、停止、再評価の境界が見えにくくなります。AIが示したものは、設計案なのか、検証結果なのか、判断材料なのか、承認に使える証拠なのか。この切り分けが曖昧になると、誰が判断し、誰が承認し、どこまで責任を持つのかも曖昧になります。

さらに、AIを含むシステムの開発と運用は、一つの企業に閉じにくくなっています。学習データ、モデル、API、クラウド、運用ルール、監督責任が、サプライヤー、AIベンダー、クラウド事業者、運用者、利用者、規制当局にまたがります。人間による監視や承認も、形式として組み込まれていることと、実際に必要な場面で介入できる設計になっていることの間に、ずれが生じやすくなっています。

このような環境では、「何を作るか」という構成の記述だけでも、「どのように検証し、運用するか」という運用の記述だけでも、AIが関与する判断の流れを十分に捉えきれないことがあります。そこで重要になるのが、「誰が、どの条件で、何を判断し、どこで承認し、どこで止め、誰が責任を負い、いつ更新・再評価するのか」という、判断と責任を扱う視点です。

複数の見方でシステムを捉えるという考え方

複雑なシステムを扱うとき、一つの図や一つのモデルだけで全体を捉えることは難しくなります。たとえば、一つの円すいを考えてみます。上から投影すれば円に見えます。真横から投影すれば三角形に見えます。どちらも同じ対象を見ていますが、見る角度が変わることで、得られる像はまったく異なります。複数の角度から眺めて初めて、それが立体的な円すいであることが分かります。

システムの記述も、これに近い考え方で捉えることができます。構造として見れば、部品やサブシステムの組み合わせとして見えます。機能として見れば、入力、処理、出力の流れとして見えます。安全の観点から見れば、危険源、故障、冗長性、停止条件が見えやすくなります。運用の観点から見れば、利用者、保守、環境条件、変更対応が見えてきます。どれか一つの見方が正しく、他が誤っているということではありません。それぞれが、同じシステムの異なる一面を表しています。

システムズエンジニアリングでは、こうした複数の視点をどのように組み合わせ、モデルとして記述するかが重視されてきました。近年では、MBSEの広がりもあり、システムをどの視点から記述し、どの関心に対してモデルを用いるのかを、より明示的に設計するようになっています。つまり、モデルそのものだけでなく、どの角度からモデルを見るのか、どの関心に対して何を表現するのかが、開発や検証の前提になります。

AIが関与するシステムでは、ここに新しい見方が加わります。AIは、フィジカル空間で起きている事象をセンサー、画像、ログなどを通じて読み取り、デジタル空間にある文書、設計情報、業務ルールと結び付けます。そして、LLMやVLMのようなニューラルネットワークによる推論を経て、提案や判断材料として人間やシステムに返します 。

このとき、AIは単なる処理機能にとどまりません。フィジカル空間、デジタル空間、人間の判断をつなぎ、現場で起きていることを別の文脈で読み直す役割を担います。例えば、設備ログを品質の兆候として見るのか、安全の問題として見るのか、保全の優先度として見るのかによって、必要な判断は変わります。同じ情報でも、どの判断に接続するかによって意味が変わるのです。

このAIを経由した見方をどのように取り入れるかが、これからの重要な論点です。AIが何を見て、何を意味として抽出し、どの判断に影響し、どこで人間が承認し、どこで停止し、どの結果を改善へ戻すのか。従来の構成、機能、安全、セキュリティ、運用、変更管理という見方に、判断、権限、責任、承認、停止、更新、再評価という見方が重なります。

この見方で捉えると、判断や責任は、どれか一つの部品や一つのソフトウェア機能の中に閉じていないことが分かります。AIモデル、制御システム、クラウド、運用ルール、人間の承認、サプライヤー、規制対応など、複数の成果物や組織をまたいで現れます。従って、判断と責任の問題は、個別要素の設計だけでなく、要素間の接続や層間の整合性として捉え直すことが重要になります。