AI時代の製造業を支えるPLMの条件とは？ アラスジャパン社長が説く、企業内に眠るデータを“AIの知見”に変える 「Adaptive PLM」の全貌

製造業のAI活用を阻むレガシーシステムのデータサイロ

　かつて経済産業省が警鐘を鳴らした「2025年の崖」。そのタイムリミットを過ぎた今日も、多くの製造業がレガシーシステムの呪縛に苦しんでいる。AIを活用して業務改革やモノづくり改革に挑もうにも、読み込ませるデータが依然としてレガシーシステムの中でサイロ化しているのだ。

　その最たる例が、設計や開発の現場に眠るエンジニアリングデータだ。製品開発の過程では、最適な解を導き出すために幾度となく試行錯誤が繰り返される。その過程で残される不採用の企画書や変更前の元データ、シミュレーションの経緯には、「なぜ設計変更が必要だったのか」「なぜその企画が不採用になったのか」「最適解を見つけるためにどのようなシミュレーションを行ったのか」など、最終的な結果（成功例）だけからでは見えないモノづくりのノウハウが詰まっている。しかし、現実にはこれらの貴重なデータの90％が、検討が終了した途端に不要なデータとして扱われ、活用されないまま眠っていると言われる。

　長年のノウハウが詰まったデータがあるのにもかかわらずAIの恩恵を得られない企業に対して、久次氏は次のように呼びかける。

　「モノづくりの中で蓄積してきた試行錯誤の履歴は、ノウハウの固まりであり、企業競争力の源泉です。それらのデータを活用できない状態のままでは、AIの力をモノづくりで存分に生かすことはできません。日本の製造業が海外に負けないスピードを維持するためには、まず社内に眠るデータをAIが使える状態に整えることから始めなければなりません」（久次氏）

プロセスこそ競争力の源泉
独自プロセスを生かせる情報基盤を

　AIの活用に向けてIT基盤の刷新を図る際、システムの標準機能に自社の業務フローを合わせることで、効率化を目指すアプローチも存在する。しかし、バックオフィス業務などとは異なり、製造業におけるモノづくりのプロセスは、競争優位の源泉そのものである。

　たとえ同じ機能を持つ製品を作る場合でも、企業によって設計思想や生産方式は全く異なる。それぞれが長年培い、改善を重ねてきた独自のプロセスこそが、市場における生存戦略なのだ。コスト要因や規模の要因など、多様な要素が絡み合って構築されたプロセスは、単なる業務フローを超えた価値を持つ。

　そのため、「他社の成功事例をそのまま当てはめたり、競争領域のプロセスを画一化したりしてしまえば、自分たちの強みを失うことになりかねません」と久次氏は警鐘を鳴らす。基幹系システムを導入する際、失敗を恐れて他社と同じものを入れようと考える企業は多いが、プロセスもデータも違う状態でうまくいくとは限らない。AI時代に真に求められているのは、システムに業務を合わせるのではなく、自社の強みであるプロセスを維持しながらデータを整理／統合できる情報基盤なのだ。

デジタルスレッド構築の要となる「ツール」と「プラットフォーム」

　AIの恩恵を最大限に享受するためには、エンジニアリングに関する情報を正しく整理し、製品の企画から設計、製造に至る各工程のデータを連携させ、ある変更が前後の工程にどう影響するかを追跡可能にする「デジタルスレッド」を構築することが不可欠だ。

　そのための第一歩となるのが、「ツール」と「プラットフォーム」の役割を明確に区別することである。PDM（Product Data Management）や3次元CADなどのツールは、個別に機能を提供し、個人の作業効率を飛躍的に向上させるものであり、デジタル空間上に現実の製品を再現するデジタルツインの構築を担う。これらは常に最新のテクノロジーへと入れ替えていくべき位置づけにある。

　それに対して、「PLMに代表されるプラットフォームは、情報を部門間で共有してプロセス全体の生産性を高めていく位置づけにあります」と久次氏は説明する。個別のツールで作られたデータを正規化し、企画や設計、製造など部門間で情報をシームレスに共有／連携させる基盤となる。長期間にわたってデータの変更履歴を維持管理し、製品開発にかかわる全ての業務をつなぐデジタルスレッドを管理することで、組織全体のモノづくりを効率化する役割を担う。

　個人の生産性を高めるためのツールを、組織全体の業務を効率化する目的で使おうとすれば、うまく機能しないのは当然である。だが、両者の違いを明確に理解していない組織が多く、役割を取り違えてシステムを導入してしまうケースが後を絶たないのが実情である。

「データ」と「プロセス」の分離が生む、変化に強いシステム

　プラットフォームを核にしてデジタルスレッドを構築する際、重要なポイントとなるのが「データ」と「プロセス」の分離である。

　品質管理の拠り所となるデータは、世代ごとに不変の記録としてしっかりと管理しなければならない。その一方で、業務フローそのものであるプロセスは、競争力を高めるために常に改善され、変化させていくべきものだ。これらがシステム内で密結合していると、プロセスを改善しようとしてもデータ構造の制約に引っ張られ、システムの改修が進まないという事態に陥ってしまう。

　これを避ける鍵は、システムの振る舞い（プロセス）を変更する方法にある。一般的な「カスタマイズ」のようにソースコードを直接書き換えるアプローチでは、プログラムが特定のデータ構造に強く依存してしまう。そのため、管理するデータ項目を一つ追加するだけでもデータベースやプログラムの修正が必要となり、迅速なプロセス変更が困難となる。

　それに対して、ローコードやノーコードを活用した「コンフィグレーション」であれば、画面上で設定を変更するだけでシステムの振る舞いを制御できるため、データ構造に影響を及ぼすことなくプロセスを疎結合のまま保ち、迅速に変更することが可能となる。

　なお、この密結合はシステムの更新（バージョンアップ）時にも大きな障壁となる。ソフトウェアは数年単位で大きく進化し、更新が必要となるが、データとプロセスが密結合したシステムでは、過去の設計データを新たな環境へそのまま移行することが困難となる。過去の知見を次の世代へ引き継げず、それが最新のテクノロジーを活用する際の足かせとなってしまうのだ。

　「モノづくりのライフサイクルは数十年に及びますが、プラットフォームとなるIT基盤は数年単位で更新します。その際に過去のデータをスムーズに引き継げなければ意味がありません。データとプロセスが疎結合であれば、長期間にわたってデータを維持管理し、蓄積し続けることができます。これが、AIの精度を高める大前提となるのです」と久次氏は説く。

企業固有のプロセスに柔軟に対応する「Aras Innovator」
業界標準テンプレートも提供

　これらの思想を体現しているのが、アラスのPLMプラットフォーム「Aras Innovator」だ。企画から要件定義、設計、製造、品質管理に至るまで、製品ライフサイクル全体をシームレスに統合管理する。

　同製品の最大の強みは、データとプロセスを疎結合に管理するオープンなアーキテクチャにある。システムに業務を合わせるのではなく、企業固有のプロセスにシステムを適合させる「Fit to Business」のアプローチを採用し、各社が持つ競争力の源泉を維持できるのだ。サブスクリプションモデルを採用しており、ユーザー独自のコンフィグレーションを維持したまま、追加のライセンス費用なしで最新機能へとアップデートできる点も大きな魅力である。

　しかし、Aras Innovatorはその自由度と機能の多彩さゆえに、初めて触れる企業に「自社の業務にどう適用すればよいかわからない」「一から設定を作り込まなければならないのか」と不安を感じさせる側面もある。これを解消すべく、Arasは現在、業界ごとの標準的なデータモデルや業務プロセスをあらかじめ設定したテンプレート「Industry Accelerator」の提供に力を入れている。

　「自動車や半導体、食品など、各業界のベストプラクティスを事前に適用して、お客様が普段使っている言葉や業務の文脈でシステムを直感的に理解し、スムーズに導入していただけるようにしています」と久次氏は話す。

　加えて、国内ではユーザー会「JAMP（Japan Aras Users' Meeting Platform）」が組織され、企業・業界の垣根を越えてシステム構築やパフォーマンス改善に関するノウハウが活発に共有されている。

AIとの融合でエンジニアの意思決定を支援する次世代基盤「Adaptive PLM」

　AI時代のPLMには、単に製品データやプロセスのノウハウを蓄積／管理するだけでなく、エンジニアの迅速かつ的確な意思決定を支援するために、AIと連携して高度な知見を引き出す役割も求められる。そのコンセプトとしてArasが提唱するのが「Adaptive PLM」だ。PLMとAIを融合させ、エンジニアの意思決定やWhat-If分析を直接的に支援するプラットフォームへと進化させる狙いがある。

　その中核を担うアーキテクチャが、「Aras InnovatorEdge（以下「Edge」）」と「Aras InnovatorEdge AI（以下「Edge AI」）」だ。エンジニアの意思決定には、PLM内の情報だけでなく、ERPシステムが持つコストやSCMシステムが持つ納期などのデータも必要となる。そこで、全てのデータを無理にPLMへ集約するのではなく、Edgeが既存のSoR（System of Record）システムから必要なデータを収集。Edge AIがそれらの情報を基に、ある設計変更がもたらす影響や納期遅延などのリスクを予測し、過去の事例に基づく回避策などをエンジニアに提示するのだ。自社の環境やポリシーに合わせてLLMを使い分けられる「BYOM（Bring Your Own Model）」の考え方を採用していることも特徴である。

　ただし、AI活用を広範な規模で進める場合、トークン消費量の増大が実運用で大きな課題となる。LLMに全てのデータの関連性を一から推論させた場合、膨大なトークンを消費してしまうからだ。「現在、AIを積極的に利用している企業に共通の悩みが、トークンのコストが極めて高くなってしまうことです」と久次氏は指摘する。

　この課題に対するArasの回答が、デジタルスレッドの活用である。

　「Aras Innovatorの中では、データAとデータBがどのような因果関係にあるのかがすでに証明されています。そのため、AIに一から推論させて関連するデータを探す必要はなく、デジタルスレッドをたどってデータを一気に取り出すだけでよいのです」（久次氏）

　Arasは、こうしたデータの取り出し方を「Thread RAG（スレッドラグ）」と呼んでいる。デジタルスレッドによりAIの推論を最小限に抑え、トークン消費量を抑えながら精度の高い回答を導き出す──コストと精度の両面で実用的なAI基盤を提供することこそ、Adaptive PLMの真価なのである。

データ間の依存関係を可視化する「Dependency Graph」で
AIが“隠れたコスト”を削減

　Edge AIが提供する具体的なエージェント機能の一つが「Dependency Graph」である。これはAIがシステム内のデータを解釈して広範な依存関係をマップとして可視化し、設計変更に伴う影響やリスクを予測して解決策まで提示する機能だ。

　具体的には、まず連携する外部システムからデータを取り込み、オントロジー解析によってデータ間のつながりを可視化する。例えば、製品の部品情報と過去のサービスログ（修理履歴）がどう結び付くのかといったことを可視化できる。そのうえで、「部品のトルク仕様を変更する」といった具体的な設計変更の要求を入力すると、AIがその変更が及ぼす影響範囲を即座に分析。変更によって生じるコストの増加やリードタイム長期化といった潜在的なリスクを瞬時に提示するのだ。

　それらのリスクを確認した担当者がチャットで軽減策を質問すると、AIは過去の試行履歴に基づいてトレードオフの条件や回避策を提案する。その内容に問題がなければ、関係するエンジニアを承認ワークフローへ自動的にアサインし、図面や材料の変更プロセスを実行するといった具合だ。

　これまで、エンジニアは設計変更の影響範囲を調べるために関連するさまざまなシステムや文書を確認し、対策のために会議を開いて議事録の作成に追われていた。過去の検討経緯がわからないことから同じ検証をやり直す“二度手間”も頻発していた。Dependency Graphの支援により、こうした非本質的な業務に費やされている“隠れたコスト”を大幅に削減できるのである。

　AIが過去の知見に基づいて賢明な判断や精度の高い予測を提供することで、エンジニアは本来の価値創出に専念できるようになる。ただし、これらの高度なAI活用は、単に最新のLLMを導入するだけで実現できるわけではない。AIの推論精度は、参照するデータの品質に完全に依存しているからだ。

　「現場に潜む隠れたコストを削減し、モノづくりの効率を飛躍的に高めるためには、参照するデータが正しく綺麗な状態にあることが不可欠です。AIの真価を最大限に引き出すためにも、まずは自社に眠るデータを整理し、情報の因果関係をデジタルスレッドでつなぐための基盤作りから始めていただきたいと思います」（久次氏）