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


Arasでグローバルアライアンスを統括する立場として、私は多くの時間をパートナーやお客様との対話に費やしています。そして今、皆が同じ問いに向き合っています。誰もが印象的なAIのデモを目にしています。しかし、そのデモから6か月後、パイロットプロジェクトを数千人のユーザー、長年にわたって蓄積されたエンジニアリングデータ、そして現実の予算のもとで稼働する仕組みへと移行しなければならなくなったとき、何が起こるのかを説明できる人はそれほど多くありません。

AIがデモで見せられることと、実際に運用するために必要なこと。このギャップこそが、エンタープライズAI評価の次の段階を左右することになるでしょう。そして、このギャップはArasにおける私たち自身の考え方にも大きな影響を与えてきました。Aras InnovatorEdgeにおけるAIへのアプローチもその一つです。これについては、この記事の後半で改めて触れます。

ここ数年、業界での議論は主に機能面に集中してきました。情報を見つける、文書を要約する、次のステップを提案する、コンテンツを作成する、日常的な作業を代行するといったアシスタント機能です。こうしたデモが実際に印象的であることは間違いありませんし、生産性向上の可能性も現実のものです。しかし、機能そのものが最も難しい部分だったわけではありません。その機能を企業全体で確実、安全、かつ経済的に運用することこそが難しいのです。そして、それは15分間のデモでは決して見えてこない部分です。

デモで見えるのは玄関先であって、基礎ではない

私は最近、このことを新築住宅が並ぶ一角を見学することにたとえて考えるようになりました。道路から見れば、10軒の家はほとんど同じように見えるかもしれません。広さも、仕上げも、外観の印象も似ています。しかし、道路からは基礎の品質も、壁の内側がどうなっているかも、電気工事が規定どおりに行われているかも分かりません。そんな状態で家を買う人はいないでしょう。そして最近、お客様からも、AIをそのような方法で購入したくはないという声を聞くことが増えています。

洗練された対話型インターフェースを見ただけでは、その下にあるシステムが、エンジニアリングデータの中で要件と設計、設計と変更、変更とサプライヤー、そしてサービス履歴がどのようにつながっているかを本当に理解しているかどうかは分かりません。ユーザー権限がそのまま引き継がれるのか、回答を元の情報まで追跡できるのか、デモでは完璧に機能した体験が、現実の複雑さを伴う本番環境の負荷にも耐えられるのかも分かりません。エンタープライズAIにおいて長期的に最も重要になるアーキテクチャ、データ基盤、ガバナンス、経済性といった要素は、ベンダーが最初に強調する部分ではないことがほとんどです。

AIが実際にどこで動いているのかを確認する

購入を検討する側ができる最も有効な質問の一つは、一見すると非常に単純です。これは実際にどこで動いているのか?

AI機能の中には、プラットフォーム内にネイティブに組み込まれているものもあります。一方で、外部モデル、クラウドサービス、ベクトルデータベース、あるいはバックエンドで接続されたパートナー技術に依存しているものもあります。どちらのアプローチも、それ自体が間違っているわけではありません。分散型アーキテクチャによって、組織は用途ごとに最適なモデルを選択できる場合があります。しかし、どの部分がどちらに該当するのかについて、お客様には明確な説明を受ける権利があります。なぜなら、そのアーキテクチャ上の判断が、セキュリティリスク、知的財産の保護、パフォーマンス、サポート責任、そして最終的にはコストにまで影響するからです。

アシスタントがPLM環境にネイティブに組み込まれているように見えても、実際には複数の外部サービスを経由している場合があります。そして、それぞれに独自のライセンス、従量課金、セキュリティ要件が存在するかもしれません。最初からそれを理解したうえで採用するのであれば、合理的な設計です。しかし、契約更新時になって初めて分かるのであれば、話は違います。ベンダーには明確に答えてもらいましょう。何がコアプラットフォーム内に残り、何が外部に出るのか。モデルは実際にどこで実行されるのか。どのデータがセキュリティ境界を越えるのか。そして、それぞれの部分のサポート責任は誰が負うのか。これらは単なる技術的な補足事項ではありません。投資の実際のリスクとコスト構造を決める要素です。

時間の節約とコストの削減は同じではない

私が目にするAIのビジネスケースのほとんどは、時間短縮の話から始まります。エンジニアが何時間もかかっていた情報を数分で見つけられる。品質担当者がすべてのファイルを一つずつ開かなくても、より多くの記録を確認できる。サービス技術者が電話を始める前に製品履歴の要約を確認できる。これらは実際のメリットです。しかし、それだけでは計算の半分にすぎません。

本当の経済的価値を判断するには、その生産性を実現するために必要なコストを差し引いて考える必要があります。新たな利用権、クラウド利用料、モデル利用料、ストレージ、統合作業、データ準備、監視、セキュリティ、さらに導入に必要なプロフェッショナルサービスやトレーニングなどです。ある作業が30%速くなったからといって、ビジネス上のメリットも30%増えるわけではありません。短縮された時間の一部は、AIが生成した内容の確認に使われます。パイロット段階では低コストに見えたものでも、企業規模で稼働し、利用量が増えれば、まったく違うコスト構造になる可能性があります。

これはまさに、CFOが議論の場に持ち込み始めている問いです。このAIは本当に業務コストを下げているのか。それとも、ソフトウェア、インフラ、統合、ガバナンスといった項目にコストが目立たない形で分散される、新たな運用レイヤーを追加しているだけなのか。

自社データに対する隠れたコストに注意する

エンタープライズAIは企業データの上に成り立っています。エンジニアリングや製造業では、そのデータは何十年にもわたる投資の成果です。製品構成、要件、コンフィギュレーション、図面、シミュレーション結果、サプライヤー記録、品質上の指摘事項、コンプライアンスの証拠、サービス履歴などが含まれます。その情報がベンダーのアプリケーションやクラウド内に保存されていたとしても、情報そのものはお客様のものです。

AIがエンタープライズソフトウェアにより深く組み込まれるにつれて、お客様が率直な質問をするのは当然です。AIレイヤーを通じて自社の情報にアクセスするだけで料金を支払うことになっていないか? データを安全に公開し、権限を維持し、サービスをオーケストレーションし、トレーサビリティを維持することには明確な価値があり、その作業に対してベンダーが対価を得るのは当然です。しかし、商用モデルでは、付加価値のあるAI機能と、お客様がすでに所有し、管理のために費用を支払ってきたデータへの基本的なアクセスを明確に区別する必要があります。新たな料金が、ガバナンスされたAPI、モデル利用、インフラ、事前構築済みエージェント、オーケストレーション、データ変換、実装のどれに対するものなのかを具体的に確認してください。単に曖昧な「AI」という項目でまとめられていないかを見る必要があります。

私が話をする多くの経営層は、以前にも同じようなパターンを経験しています。当初は包括的だったプラットフォームの約束が、徐々に追加モジュール、コネクタ、料金階層、各種手数料へと細分化されていくパターンです。AIの価格設定についても、今から同じレベルの精査を求めるのは当然でしょう。

1社のAIベンダーだけではAI戦略にはならない

一つのモデルが企業内のすべてのユースケースに最適である可能性は低いでしょう。文書要約に最適化されたモデルは、技術分析には適さないかもしれません。公開モデルでは、規制対象のプログラムや防衛関連プログラムの要件を満たせない可能性があります。高度に特化したモデルは優れた結果を出せても、日常的な作業には過剰で、コストも高すぎるかもしれません。

組織は今後も、業務の性質に応じてAIサービスを選択していくでしょう。データの機密性、必要な精度、導入環境、レイテンシ、説明可能性、コストなどが判断材料になります。つまり、AI戦略を一つのベンダーや一つのモデルに依存させるべきではありません。モデルは急速に進化し続け、価格も変化し、今日の差別化要因はいずれ一般化していきます。長期的に価値を持つ投資は、特定のモデルではありません。その周囲にある基盤、つまりガバナンスされたデータ、権限、ビジネスルール、API、トレーサビリティ、オーケストレーションです。モデルを入れ替えるたびに、そのモデルにコンテキストを提供するデジタル環境を再構築しなければならないのであれば、ベンダーロックインを解消したことにはなりません。単にその場所を移しただけです。

AI機能からAI運用モデルへ

優れたデモは、そのAI機能が技術的に実現可能であることを証明します。しかし、その機能を実際の企業全体で安全に運用できることまでは証明しません。

AIを運用可能なものにするには、より難しい問いに答える必要があります。推奨内容が間違っていた場合、誰が責任を負うのか。エージェントが自律的に実行できるアクションと、人による承認が必要なアクションをどう分けるのか。プロンプトやモデルをどのように更新し、その変更を本番業務に適用する前にどうテストするのか。特にエンジニアリング環境では、これらは抽象的なガバナンスの問題ではありません。AIによって行われた、あるいはAIの影響を受けた製品上の判断は、品質、安全性、コンプライアンス、コスト、長期的なサービス責任に影響を及ぼす可能性があります。したがって、AIはもっともらしい回答を生成するだけでは不十分です。既存の業務を管理しているのと同じ統制の中で機能し、権限、コンフィギュレーションのコンテキスト、ライフサイクルの状態、そして結果の根拠となった情報の明確な記録を維持しなければなりません。

私がお客様に勧めるAI品質の評価方法

まず、データ基盤から始めます。AIは、ガバナンスされ、つながった企業情報を対象に機能しているでしょうか。それとも、互いに切り離された文書から似た表現を検索しているだけでしょうか。レコード同士がどのように関連しているかを理解しているのか、それとも単に一致する情報を取得しているだけなのかを確認してください。

次にアーキテクチャを見ます。ベンダーは、データがどこへ送られ、どのように処理され、どのモデルが関与しているのか、さらに外部サービスの一つが変更されたり停止したりした場合に何が起こるのかを明確に説明できるべきです。

ガバナンスも同じくらい重要です。AIは既存の権限を継承し、追跡可能な結果を生成し、重要な判断について人が確認、承認、修正、あるいは取り消しを行えるようにする必要があります。すでに信頼している統制を迂回するシャドープロセスを生み出すべきではありません。

最後に、自信ではなく証拠を求めてください。その機能は、精度、ハルシネーション、レイテンシ、セキュリティ、スケーラビリティについて実際にどのようなテストを受けているでしょうか。現在、実際の本番シナリオで稼働しているでしょうか。そして、サイクルタイムの短縮、品質の向上、リスクの低減を測定可能な形で実現しているでしょうか。優れたAIソリューションは、プレゼンテーションの見栄えではなく、アーキテクチャ、ガバナンス、再現可能な成果によってその価値を証明します。

この議論におけるArasの位置づけ

Arasでは、効果的なエンジニアリングAIは、PLMの上にチャットボットを後付けするのではなく、信頼できる製品コンテキストから始める必要があると考えています。製品情報の価値は、個々のレコードだけにあるわけではありません。要件、構成、コンフィギュレーション、設計、変更、サプライヤー、品質イベント、製造上の判断、コンプライアンス上の義務、サービス履歴の間に存在する関係性にこそ価値があります。このつながったコンテキストがデジタルスレッドです。私たちの目標は、エンジニアリング組織が依存している権限、ライフサイクル管理、トレーサビリティを損なうことなく、AIがそのデジタルスレッドの中で機能できるようにすることです。

この考え方がAras InnovatorEdgeの基盤になっています。Edge APIは、パートナーやお客様がデジタルスレッドの情報やアクションを制御された方法で公開できるようにします。Edge Builderは、特定の役割やタスクに合わせたアプリケーションの構築を支援します。Edge AIは、Aras Innovator®と直接連携するAIエージェントを構築、オーケストレーション、ガバナンスするための基盤となることを目的としています。すべてのAI機能をコアプラットフォーム内に置く必要はありません。組織は、自社の技術要件、セキュリティ要件、経済的要件に応じて、異なるモデルやサービスを自由に取り入れられるべきです。一方で、変わってはならないのが、その下にあるガバナンスされた基盤です。信頼できる一つの製品記録、一貫した権限体系、追跡可能な履歴を維持し、切り離されたAI実験の寄せ集めにしないことが重要です。

もう一つ率直に言えば、ベンダーであれお客様であれ、AIがどこで最大の価値を生み出すのか、あるいは導入が最終的にどのような形になるべきなのかを、まだ誰も完全には把握できていません。だからこそArasは、パートナーやお客様と緊密に連携しながら、AIがどこで現実的かつ具体的な価値を生み出すのか、責任ある形で導入・ガバナンスするには何が必要なのか、そして現在進行しているエンジニアリング業務にどのように組み込むべきなのかを見極めています。

AIのデモはこれからもますます印象的になっていくでしょう。しかし、AIで成果を上げる組織は、その下にある基盤も同時に強化した組織です。そして契約した後ではなく、契約する前に難しい問いを投げかけた組織です。

エンジニアリング組織向けのエンタープライズAIを現在評価していて、何に注目すべきかについて意見を交わしたい方は、ぜひお話しできればと思います。それこそが、私と私のチームが担っている重要な役割の一つです。LinkedInでつながるか、下のコメント欄からぜひご連絡ください。