コネクテッドシステムからインテリジェントエンジニアリングへ

このページの内容は、サードパーティサービスによって自動翻訳されています。

AIエージェントがデータへのアクセスだけでは不十分な理由

長年にわたり、エンジニアリングにおけるデジタルトランスフォーメーションは、システム統合を中心に進められてきました。

私たちは、CADとPLM、PLMとERP、そしてエンジニアリングと製造、品質、サプライヤー、サービスをつないできました。

こうした取り組みは今なお重要です。しかし、システムを接続すること自体は、もはや最も難しい課題ではありません。

本当に難しいのは、情報がシステム間を移動する中で、エンジニアリングコンテキストを維持することです。

要求事項は単なるテキストではありません。設計は単なる形状データではありません。変更は単なる改訂済みオブジェクトではありません。それぞれには、製品構成、リビジョン、依存関係、責任者、承認履歴、そしてそれまでに行われた意思決定などのコンテキストが含まれています。

そのコンテキストが失われると、システム同士は接続されたままでも、エンジニアリングの知識はつながりを失ってしまいます。

従来のシステム統合は、システム間で情報を移動させることを目的としていました。しかし、データを移動させるだけでは、そのデータの意味を受け取る側のシステムやチームが理解できるとは限りません。

要求事項は、それが影響を及ぼす設計、試験、リスク、認証エビデンスと結び付いたままでしょうか。

設計変更は、ソフトウェア、ハードウェア、製造、品質、サービスにまたがって正しく理解されるでしょうか。

チームは、その情報がどの製品、どの顧客構成、どのリビジョンに適用されるものかを判断できるでしょうか。

どの情報が信頼できる正本で、どれが単なるコピーなのかを見分けられるでしょうか。

もはや本当の課題は、情報を移動させることではありません。その情報を価値あるものにしている関係性を維持することです。

システム統合よりもエンジニアリングコンテキストが重要な理由

デジタルスレッドは、製品ライフサイクル全体のシステムを結び付けるものとして説明されることがよくあります。しかし、その説明だけでは十分ではありません。

真に価値あるデジタルスレッドとは、人とシステムが「何が変更されたのか」「なぜ変更されたのか」「何に影響するのか」「どの構成に適用されるのか」「誰が承認したのか」「どのようなエビデンスがその判断を裏付けているのか」を理解できる仕組みでなければなりません。

そのためには、永続的な識別子、トレーサビリティを備えた関係性、構成情報、所有者情報、来歴、そして情報の正当性を維持する仕組みが必要です。

目標は、すべてのエンジニアリング分野を一つのシステムへ集約することではありません。現代のエンジニアリング環境は、今後も分散したままでしょう。機械設計、エレクトロニクス、ソフトウェア、システムズエンジニアリング、シミュレーション、製造、品質、サプライヤー、サービスは、それぞれ異なるツールを使い続けます。

重要なのは、情報を分散したまま維持しながら、それらを結び付けるコンテキストを失わないことです。

AIの普及により、この重要性はさらに高まっています。

第一世代のエンジニアリングAIは、主にコパイロットとして機能してきました。コパイロットは、情報の検索、要約、コンテンツの生成、情報の比較、次のアクションの提案などを支援します。しかし、結果を解釈し、最終的な判断を下すのは人間です。

次の段階は、AIエージェントへの移行です。

エージェントは質問に答えるだけではありません。実際のワークフローに参加します。

エンジニアリングエージェントは、変更作業の準備、影響を受ける項目の特定、情報の更新、関連するエビデンスの収集、承認プロセスへの回付などを行うことができます。

そのためには、基盤となるデータ環境に、これまで以上に高いレベルが求められます。

コパイロットであれば、不完全なコンテキストでも役立つ場合があります。しかし、エージェントは、自分がどの製品、どのバリアント、どのリビジョンを扱っているのか、どの情報が正本なのか、変更対象にどのような依存関係があるのか、どのルールを適用すべきか、どの段階で人による承認が必要なのかを理解していなければ、安全に行動することはできません。

複数のシステムにエージェントを接続しただけでは、それらのシステム内にある情報同士の関係性まで理解できるわけではありません。

エージェントは、局所的には正しい変更を行っても、別の場所で問題を引き起こす可能性があります。要求事項の変更は、ソフトウェア、ハードウェア、試験、製造指示書、サプライヤー、認証エビデンスにまで影響する場合があります。また、ある製品構成では正しい変更でも、別の構成では誤りになることもあります。

だからこそ、データへのアクセスだけでは十分ではありません。AIには製品コンテキストが必要です。

目指すべきものは、制限のない自律性ではありません。適切に管理された権限委譲です。

AIは、作業案の作成、依存関係の特定、影響評価、裏付けとなるエビデンスの作成、適切なレビュアーへの回付を支援できます。一方で、判断、承認、そして最終的な責任は人が担い続けます。

このモデルを機能させるには、製品環境の中で、エージェントがアクセスできる情報、変更できる内容、評価すべき依存関係、従うべきルール、そして結果を承認する担当者を明確に定義する必要があります。

この基盤がなければ、エンジニアリングエージェントは限定的でリスクの低い作業しか担えません。この基盤があれば、より実践的で価値の高いエンジニアリングワークフローを支援できるようになります。

AIエージェントのためのPLM基盤を構築する

PLMはこれまで、製品構成、リビジョン、ドキュメント、プロセスを管理するシステムとしての役割を担ってきました。その役割は今後も重要ですが、それだけでは十分ではありません。

これからのPLMには、分散したエンジニアリング環境全体で製品コンテキストを維持する役割が求められます。その価値は、より多くの情報を保存することではなく、製品を理解し、変更を評価し、適切な意思決定を支えるために必要な関係性を維持することにあります。

AIがこうした意思決定やワークフローに関与するようになるほど、その重要性はさらに高まります。

エンジニアリングおよびPLMのリーダーが今問うべきことは、システム同士が接続されているかどうかではありません。

本当に重要なのは、システムをまたいでもエンジニアリングコンテキストが維持されているかどうかです。

変更を実施する前に依存関係を把握できるでしょうか。正しい製品構成を確実に特定できるでしょうか。AIは、信頼できる正本と、単に利用可能な情報とを区別できるでしょうか。提案されたすべてのアクションを、その根拠となるエビデンスや承認までさかのぼって追跡できるでしょうか。

こうした課題を解決できる企業は、製品の複雑さをより適切に管理し、AIを責任ある形で組織全体へ拡張していくための優位性を得ることができます。

システム統合は今後も不可欠です。しかし、統合そのものが最終目的ではありません。

目指すべきものは、人が信頼でき、AIエージェントがその上で判断し行動できる、一貫性があり、管理され、実用的な製品理解を実現することです。

このテーマについてさらに詳しく知りたい方は、ブログ「Building the Foundation for AI in Product Development」をご覧ください。