Posted on Oct 28, 2025 in blog
前回( 個別受注のPLM(その2) )まで、個別受注企業で重要な目的別BOMの1つとしてP-BOMについて触れました。個別受注企業では、その他のBOMとして、出荷BOM、サービスBOM、メンテナンスBOMなども欠かせません。ちなみに、前々回( 個別受注のPLM(その1) )で目的別の種類についても触れています。目的別BOMの深堀りは別途展開したいと思います。今回から数回にかけて「PLMとAI」について触れたいと思います。近年どこもかしこも 『 AI 』 です。無論、このPLM界隈においても、AI の話題になります。ただ、CHATGPTなど生成AIが話題になっているため、多くの人が「 AI = 生成AI 」という思考で、議論の範囲が少し狭いように思えます。なので、数回にわけて、PLMにおけるAIの検討視点など全体像的な部分に始まり、最終的にはPLM領域ならではの部分( BOMの親子関係であるPSデータや、ドキュメント間のリレーションデータなど) を使ったAIはどのようになっていくべきかについて触れたいです。
上記の画像が、AI を検討するにあたっての主要な論点( PLMならではのPSやリレーションなどを考慮した部分は入っていない) です。全体的な話は次に展開するとして、まずは最近よく聞かれる内容にざっくり答えていきたいです。私は、設計標準化・設計ナレッジの見える化・自動設計などの改革も推進しています。その際に、「最近AIがでてきて、自動設計などもAIでできるのでしょうか?」とよく聞かれます。言葉が少ないと語弊が生まれますが、あえてシンプルに答えると、「 現時点では、AIでの自動設計は無理 」というのが私のスタンスです。自動設計はどこの部分か?AIで無理といっても0-100ではないよね?とか厳密に答えるならいろいろ言えるのですが、ざっくり答えると「無理」と思っています。設計の本質は「設計諸元」を決める行為であると思っています。材質・板厚・長さなどなど、適切な諸元値を選べるかが重要な要素です( ※以前のブログで少し触れてます ) 。 この設計諸元を選ぶのは、設計のメカニズムや根拠に基づいてロジカルに選んでいます。ロジカルに根拠を持って選ばないと性能保証・安全保障ができないからです。そう考えると、適切な諸元を選ぶという行為は、ルールベースで構造的に演繹的な視点で整理をし選ぶことが避けられないと思っています(上記図の左下)。ルールベースなので、諸元値の選び方を関数化するということです。( 関数で表現が面倒とか、それをどうやって管理メンテするのか?など運用問題は一旦おいておいて) 論理的には頭の中を関数で表現することは可能です。逆に関数で表現できないということは論理的な仕事をしていないということになります。0-100ではないため、頭の中を100%関数化する必要はありません。30%40%でも関数化できればそれが自動化にも繋げられます。40%できれば徐々に60%70%と上がっていきます。それでも無理な部分は残るとは思いますが。設計諸元を選ぶのは現時点ではルールベースが最適解だと思っています( 5年後10年後のAIはまた別だと思いますが) 。
では、設計諸元を決める領域でAIが全く使えないのかというとそうではないです。検図や図面チェックの領域では AI は有効だと思います(上記図でいう右下5,6部分)。 要はいまで言う、ベテランが図面を見て、「危ないところが”光って見える”」。この部分は AI に変わることができると思います。ベテランの危ないところが光って見えるは、ロジカル・構造的に・ルールベースで危ないところを検知しているわけではないです。より多くの図面を目にし、経験を積むことで、感覚的に「危ないところが光って見える」という現象が起きています。経験を積み上げる(=帰納的)は、統計やAI の得意とする領域です。危ない所や、間違えやすい部分、リスクのありそうな部分、トラブルになりやすい部分など、リスク部分を抽出しているだけで、実際にその状態がNGである確証がない場合もあります。危険そうだから再度チェックして。あの案件と比較して。あの時の担当者と会話して・・・など、再確認を促すことになります。
「 設計で諸元値を決めるのはルールベース、検図やチェックは AI ベース 」
というのが、現時点での切り分けだけだと思っています。繰り返しですが、AIの進化も日進月歩です。5年後には諸元値を確定する部分の多くはAIでできる世界は来るのだと思いますが、あくまでも現時点での使い分けとして考えてください。
次回は、上記図で示しているPLM領域におけるAIの検討視点について触れたいと思います。
2025年10月28日 プリベクト 北山一真
Blog-List