AI対応の出発点は、信頼できる製品データ

メーカー各社は、生産性と意思決定の向上を目指し、AI、デジタルスレッドの取り組み、自動化、全社的な近代化に多額の投資を行っています。議論の多くは、AIモデル、インフラ、システム統合に集中しています。しかし、こうした取り組みの根本的な前提条件である、業務上の意思決定を左右する基盤製品データやビジネスルールへの信頼を、多くの企業が見落としています。

課題は、単にシステムを接続することではありません。システム間でやり取りされる製品定義、構成ロジック、ビジネスルールの正確性を保つことが重要です。AI対応の出発点は、全社で扱う製品データへの信頼です。デジタルトランスフォーメーションとは、システムを接続するだけでなく、システム間を移動する情報の意味と正確性を維持することです。

企業が基幹システムを近代化し、製品ライフサイクル管理（PLM）、統合基幹業務システム（ERP）、構成・価格・見積もり（CPQ）、サービスの各プラットフォームを連携させるなかで、構成ロジックの不整合が、後続プロセスの正確性やAIを活用した推奨の有効性を、気付かれないまま損なうことがあります。信頼できる構成ロジックがなければ、AIは意思決定を改善するどころか、誤りを加速させます。

製品構成が見えない基盤となる理由

今日のメーカーは、PLM、ERP、CPQ、製造、サービスにまたがる相互接続されたエコシステムへの依存を強めています。製品構成は、エンジニアリング上の意図を、製造、販売、価格設定、サービスに必要な要件へと変換する結合組織の役割を果たします。

各システムが捉える製品像は異なります。PLMが必要とするのは技術情報と設計情報であり、製造部門が把握する必要があるのは何を製造できるか、CPQが必要とするのは販売ルールと市場ルールです。構成によって、こうした視点が結び付けられます。基盤となるロジックが変更されたり、不整合が生じたりすれば、システムがどれほど適切に連携されていても、デジタルスレッドは途切れます。

レガシールールが招く見えないリスク

製品構成モデルには、規制要件、製造上の制約、市場ごとの例外、価格設定ロジックなど、何十年にもわたって蓄積された知識が、時間をかけて組み込まれていることがよくあります。こうしたモデルを当初構築した人々はすでに退職している場合が多く、企業には、もはや誰も全容を把握していないルールが残されています。

SAP S/4HANAへの移行などの基幹システム近代化プロジェクトでは、通常、アプリケーション、インフラ、カスタムコードが重視され、構成ロジックは二次的なものとして扱われます。その結果、見過ごされがちなリスクが生じます。システムの移行自体は成功しても、従来のテストでは検出しにくい微妙な形で構成の動作が変わる可能性があるのです。

S/4HANAへの移行は、この問題をよく示しています。構文が同じでも、新しい構成エンジンが長年使われてきたルールを異なる方法で解釈することがあるためです。デフォルト値の適用方法、制約を評価する順序、ルール間の競合を解決する方法に違いがあると、ルール自体を一行も書き換えなくても、モデルが受け入れる組み合わせが変わる可能性があります。

これは単に混乱を招くだけではありません。不適切な構成ロジックは、ビジネス上の問題になります。失敗には二つのパターンがあり、どちらも大きなコストを伴います。

• 構成の誤りにより、実際には製造できない製品を企業が販売できることになり、手戻り、約束の不履行、顧客との関係悪化を招く。
• 構成の誤りにより、製造可能な製品を企業が販売できなくなり、売上を失い、競争優位性まで損なう可能性がある。

一つ目の失敗は、いずれ工場の現場で明らかになります。二つ目は表面化しません。構成ツールが許可しなかった販売は、受注記録に残らないからです。

検証が戦略的能力になりつつある

従来の移行検証は、手作業のテストや抜き取り確認に大きく依存していますが、膨大な数に上る製品の組み合わせを現実的に評価することはできません。構成検証では、データが問題なく移行されたかどうかではなく、ビジネス上の意図が維持されているかどうかに焦点を移します。

私は、移行したモデルが従来と同じ有効な構成を生成し、同じ無効な構成を引き続き拒否することを確認するためだけに、チームを配置しているメーカーを見てきました。それを確かめるほかに方法がないからです。これは細部にわたる高コストで時間のかかる作業ですが、それでも問題の一部を抜き出して確認するにすぎません。

対象となる規模を正確に捉えておくことが重要です。変数が30個あり、それぞれに5つの選択肢があるモデルでは、組み合わせはおよそ10²¹通りに上ります。これは地球上の砂粒の推定数をはるかに超える数であり、実際の産業用モデルはさらに大規模です。ユーザーインターフェースを人がどれだけ操作しても、この範囲を網羅することはできません。計算上、それは不可能です。

これが、形式手法が重要な理由です。組み合わせをサンプリングするのではなく、構成モデルを正準論理形式、すなわち、そのルールで許容されるすべての有効な組み合わせを簡潔に数学的に表現したものへと変換できます。この方法で変換した2つのモデルは、直接比較できます。両者がまったく同じ有効な製品の集合を表しているか、そうでなければ、どこで異なるのかが、片方では受け入れられ、もう片方では拒否される組み合わせの具体例とともに正確に示されます。同じ表現を使えば、実行時の動作を検索ではなく参照によって判定できるため、構成ツールは有効な選択肢だけを表示し、ユーザーが行き詰まることもありません。検証と実行時の正しさは、同じ能力を異なる方向から捉えたものだとわかります。

組織では、製品ルールにAIや自動化を導入する前に、このような形式的な比較を行う必要性が高まっています。目的は、移行リスクを減らすことだけではありません。エンジニアリング、製造、販売、サービスにわたる業務の継続性を保つとともに、構成モデルをリリース後ではなくリリース前にテスト、デバッグ、検証できるようにすることです。

AIは決定論的なエンジンの上に組み込むべきであり、エンジンに取って代わるものではない

構成エンジンをAIに置き換える必要はありません。むしろ、より持続性のある方法はその逆です。AIをユーザーと厳格な構成エンジンの間に置き、基盤となるルールは決定論的なまま保ちながら、より自然なガイド付き販売やレコメンデーションの体験を提供します。言語モデルが顧客の要望を解釈し、実際に製造可能かどうかはエンジンが判断します。こうした役割分担により、証明可能な正しさが求められるプロセスの部分を、設計上確率的なシステムに委ねずに済みます。

AIプログラムの成功を支えるのは信頼できるデータ

AIが推奨を生成する際の信頼性は、受け取る製品知識の信頼性を超えることはありません。検証されていない構成データを使うと、AIは企業全体の規模で誤りを拡散し、販売支援、製造上の判断、顧客への約束を損なうおそれがあります。

メーカーは、データの検証をAI導入の前提条件と捉えるべきです。これは、ソフトウェアテストがアプリケーション開発の前提条件となったのと同様です。デジタルトランスフォーメーションが進むにつれ、競争優位性の源泉は、誰よりも早くAIを導入することではなく、信頼できる製品インテリジェンスを基盤としてAIを導入することへと、ますます移っていくでしょう。