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

公式なLLMへのアクセスを持つ企業が40%にとどまる一方で、90%以上の従業員がすでにAIを利用している場合、問題はもはや導入ではありません。それは、AIがガバナンスされた製品の現実の中で機能しているかどうかです。

多くの企業はいまだに、無許可のAI利用をポリシーの問題として扱っています。しかし、それでは本質的なシグナルを見逃していると思います。

従業員が公式ツールを回避する場合、それは組織が聞きたくないことを示していることが多いのです。つまり、需要はすでに存在しており、承認された体験がそれに応えていないということです。

この点は、この文章のきっかけとなったハーバード・ビジネス・レビューの記事、The Hidden Demand for AI Inside Your Companyから得た最も鋭い示唆でした。数字は無視できません。公式なLLMサブスクリプションを購入している企業はわずか40%ですが、それらの企業の90%以上の従業員が業務で個人用AIツールを使用していると報告しています。これは一部の行動ではありません。潜在的な需要が表面化しているのです。

多くの企業機能にとって、これはガバナンス上の課題を生みます。しかし製品組織にとっては、それ以上の意味を持ちます。

なぜなら企業内では、人々は単にメールを整えたり一般的な文書を要約したりしているわけではないからです。要件、BOM、設計変更、サプライヤーデータ、品質イベント、製造計画、サービス履歴、そして製品を定義する複雑な関係性の網の中で作業しています。ここから議論は一気に深刻になります。

問題はAIの利用ではありません。製品の真実を伴わないAIの利用です。

これは多くの企業がまだ過小評価している部分だと思います。

汎用的なAIツールは印象的であっても、エンジニアリングにおいて重要な点では誤っている可能性があります。どのリビジョンが最新かを知らないかもしれません。有効性（エフェクティビティ）を理解していないかもしれません。要件がすでに置き換えられているか、品質問題がまだ未解決か、あるいはユーザーがそのデータにアクセスすべきかどうかさえ認識できない場合があります。また、リリース状態、トレーサビリティ、構成ロジック、変更の影響といった概念も自然には理解しません。

そしてPLM中心の環境では、これらは例外ではなく業務そのものです。

本当のリスクは、従業員がAIを使っていることではありません。エンジニアリングの意思決定を信頼できるものにするガバナンスされたコンテキストの外でAIを使っていることです。

ここに本質的なギャップがあります。モデルの品質ではなく、コンテキストの品質です。

シャドーAIは違反ではなくシグナルである理由

HBRの記事はここで重要な指摘をしています。企業はシャドーAIに対して制限や監視で対応しがちですが、この行動自体が満たされていないニーズの証拠です。従業員はスピード、統合、パターン認識、そして摩擦の軽減を求めています。つまり、仕事を進めようとしているのです。

この教訓はデジタルエンジニアリングではさらに重要になります。

エンジニア、品質チーム、生産計画担当者、プログラムリーダーが日常業務でコンシューマー向けAIを使用しているなら、それは組織の摩擦を可視化しています。検索の遅さ、知識再利用の弱さ、システムの断片化、サイロ化されたコンテキスト、過剰な引き継ぎ、そして意思決定の瞬間に十分なトレーサビリティがないことです。

この問題がデジタルスレッド戦略と直結する理由はここにあります。デジタルスレッドは単に現代的に聞こえるから価値があるのではありません。コンテキストに構造を与えるからです。要件をシステムモデルに、部品をBOMに、変更を品質記録に、サプライヤーをコンプライアンス影響に、サービス問題を設計に結びつけます。この接続されたコンテキストがなければ、AIは文章を生成するだけです。しかしそれがあれば、エンジニアリング業務を支援できます。

この違いは大きいものです。

次のエンタープライズAIはコンテキストアーキテクチャで決まる

エンタープライズAIの勝者は、最も多くのパイロットを実施する企業ではありません。パイロットはすでに十分にあります。足りないのは運用レベルのコンテキストです。

先行する企業は、AIをガバナンスされた製品データ、ライフサイクルロジック、アクセス制御と結びつけます。つまりAIを独立したアシスタントではなく、運用モデルの一部として扱います。

これはスタック全体に影響します。

PLMリーダーにとっては、製品データの連続性がバックオフィスの課題ではなくAI準備の課題になります。デジタルエンジニアリングチームにとっては、ライフサイクルトレーサビリティとドメイン横断の連携の重要性が高まります。MBSEやMBEの取り組みにとっては、機械が扱える構造化されたモデルと接続された表現の重要性が強まります。エンタープライズアーキテクトにとっては、分断されたシステムの上にAIを置けばその分断がそのまま引き継がれるため、相互運用性への圧力が高まります。

不十分な入力は、不十分な出力を生みます。ただしより速く。

ガバナンスは依然重要だが進化が必要

HBRの記事で評価した点の一つは、人間の責任を強調していることです。BBVAのモデルでは、AIは自律的な主体として扱われず、人間が責任を持ち、コアシステムへの直接的な変更は制限されています。この原則はエンジニアリングではさらに重要です。

エンジニアリング組織が遅くあるべきだからではありません。そうではなく、統制された加速が必要だからです。

つまり、AIには制限されたアクセスが必要であり、機密性の高い製品IPへの無制限アクセスではいけません。最新かつ権限のあるデータを使用し、古いエクスポートに依存してはいけません。可視化されたワークフローと明確な責任が必要です。そして意思決定が追跡、検証、監査できるシステム内で動作する必要があります。

これはデモ向けのAIよりも地味に聞こえるかもしれませんが、それでよいのです。信頼できるエンタープライズAIは派手さよりもアーキテクチャに依存します。

今、何を意味するのか

実務的な問いは、もはやAIがエンジニアリングに必要かどうかではありません。この議論は終わっています。

本当の問いは、エンジニアリング環境がAIに必要なコンテキストを提供できる状態にあるかどうかです。無謀にならずに有用であるために。

これはより難しい問いです。なぜなら表層の下を見なければならないからです。データ品質、権限管理、プロセス成熟度、デジタルスレッドの完全性、そしてPLMが本当にガバナンスされた製品の真実のシステムとして機能しているのか、それとも単なる別のリポジトリに過ぎないのかという点です。

ここで市場は静かに変化しています。エンジニアリングにおけるAI導入は、接続されたライフサイクル基盤を持つ組織と、断片化されたツールを積み重ねてきた組織の違いを明らかにします。前者はAIを実際のワークフローに組み込むことができ、後者は印象的なデモと慎重なコンプライアンス対応を繰り返すことになります。

結び

したがって、シャドーAIを主なリスクと捉えるべきではありません。

より大きなリスクは、製品コンテキスト、ライフサイクル規律、そしてエンジニアリングに必要なガバナンスなしにAIを運用することです。

これが現在の実験の波の下にある戦略的課題です。そしてデジタルスレッド、PLM、MBSE、MBE、そしてエンジニアリングデータ戦略が、1年前よりもさらに重要になっている理由です。背景ではなく、基盤として。

未来は製品システムの隣にあるAIではありません。

製品システムの中にあるAIです。

そしてそれを最初に実現した組織は、リスクを減らすだけでなく、より良い意思決定をより速く行い、より高いトレーサビリティと少ないノイズを実現するでしょう。

Category:
Artificial Intelligence Digital Engineering Digital Thread