―――類似検索が切り拓くAI活用の第一歩

倉本：
弊社は2026年7月に開催された「ものづくりワールド」に出展しまして、Visual BOMの最新版（V6.2）の中のAI機能を紹介しました。
例えば、
・類似図面AI検索
・類似文章AI検索
といった機能です。過去に登録された情報から、AIが似たものを探してくれる仕組みですね。

北山：
その類似検索というのは全文検索とは違うのでしょうか？

倉本：
はい、完全一致検索ではありません。文章をベクトル化して類似度を計算するような仕組みです。キーワード一致だけでは拾えないものも対象にできます。

北山：
なるほど。そういう機能は非常に重要ですよね。どうしたって言葉は人によって揺らぎますから。マスタデータを類似検索できるのは理にかなっています。
今日はぜひ、その先についてもいろいろディスカッションさせていただきたくて。

倉本：
はい、ぜひお願いします。

―――要求仕様とBOMをつなぐAIの可能性

北山：
PLMにおけるAI活用で実現できたら本当に面白いと思っているのは、「要求仕様からBOMを自動生成できないか」というテーマです。
以前から書籍などにも書いていますが、設計というのはよく考えると、
・要求仕様が入力
・BOMが出力
なんですよね。だから私は、言語間の翻訳に近いんじゃないかと思っているんです。

倉本：
翻訳ですか？

北山：
例えば英語を入力すると日本語になって出てくる。これが翻訳ですよね。
同じように、
・顧客要求
・要求仕様書
を入力した結果、
・どんなユニットが必要か
・どんな部品が必要か
・どんな構成になるか
が出てくる。考え方としては近い気がするんです。

倉本：
なるほど。

北山：
GPTなどのLLMでも使われているトランスフォーマーモデルは、インプット言語の修飾・被修飾の関係、係り受けまで考慮したうえで、アウトプットを出力します。
同じように、どの要求仕様がどのユニットや部品にかかるかを考慮したうえで、構成を出力する、というような挙動が可能ではないかと考えています。ただ、そのためにどんなことをAIに学習させればいいのか、というのがまだ見つかっていないんです。私は技術屋さんではないので想像しているだけなんですけど。笑

倉本：
なるほど、おっしゃることは理解できました。

北山：
例えば個別受注の設備メーカーだと、
「処理能力をこれだけ上げたい」とか「この制御を追加したい」という要求が来ます。
すると設計者は経験を使って、
・このユニットが必要だ
・この配管が必要だ
・このセンサーが必要だ
という判断をします。でも、それって本質的には知識の集積ですよね。

倉本：
確かにそうですね。経験豊富な設計者は自然に判断します。

北山：
そうなんです。そして多くの場合、過去案件を参考にしています。「あの案件で似たことをやった」「この制御ならこのユニットだった」みたいな話ですね。
これまで私はそうした経験則を、
・150％BOM
・コンフィグレーションルール
・設計ナレッジ
といった形で整理してきました。つまり、人間がルールを定義するというアプローチです。しかしこれにも限界が見えてきました。

倉本：
ルール化コストも大きいですよね。

北山：
大きいです。しかも企業によって違う。企業毎ならまだしも、事業部、拠点、製品によっても違う。担当者によっても違う。
だから本当は、AIが自動的に特徴を学習してくれたらいいと思うんです。

―――設計者は本当に最適な選択ができているのか

倉本：
我々もAIの活用について考えてきていますが、やはり完全に自動生成させるのは現段階だと難しいと考えています。というのは、AIが嘘をついたり、間違えたりする可能性があるので、結局チェックに人の工数がかかったり、大きな手戻りが発生したりする可能性を排除できないからです。
ですので、現実的な第一歩としては、要求仕様に近い過去の案件を探して、そのBOMを提示するという形を模索しています。

北山：
まずはそこだと思います。
「この要求に近い案件は過去に5件あります。そのBOMはこれです」と出てくるだけでも違う。

倉本：
いわゆる「流用元の選定」ですね。

北山：
まさにそうです。実際には設計者って、会社の全案件を知っているわけではありません。
結局、自分が知っている案件から選ぶんです。だからこそ、自分の知らない候補を選択肢として出してくれるだけでもありがたい。ただ、そこにもう一つ視点を加えてみたいんです。

倉本：
ぜひ教えてください。

北山：
面白いことに、現場の皆さんのお話を聞いていると本当は80点の他人の設計より、70点の自分の設計を流用するケースってかなり多いんですよ。

倉本：
気持ちは分かります。自分の設計の方が意図を理解していますからね。よくわからない流用元を選んで失敗したくない、後から「なんでこれ選んだの？」という形で責任を取るのは嫌ですよね。

北山：
そうなんです。だから、本当に最適な流用元が選ばれているとは限らない。
そこでAIが、「本当はこっちの案件の方が近いですよ」と言ってくれたら大きな価値があります。

倉本：
そのとおりですね。我々は、たとえば、流用元を選ぶ根拠として過去の案件のQCDをAIでスコアリングして表示する、ということを考えています。
人の判断を置き換えるのではなく、人の判断を支援するAIを搭載していきたいという考えのもと、製品のエンハンスを進めています。

北山：
私の考えとも一致しています。設計というのは最終的に「意思決定」なんですよね。
たとえば、流用元を選ぶにあたって、
・コストを優先した
・納期を優先した
・品質を優先した
という判断があります。同じ要求でも選ぶ際の状況に応じて答えが変わりますよね。だから、本当に必要なのは「なぜその案を採用したか？」という判断の根拠です。

倉本：
当社もそこは重要視しています。なので、先ほど北山さんから「何をAIに学習させようか」というお話がありましたが、我々はその「判断の根拠」をこそ学習させるべきと考えています。
従来のPLMは、BOMや図面、ドキュメントなど製品情報の一元管理が中心でした。それによって判断、意思決定の高度化を支援してきたという自負があります。
今度はその次のステップ、高度化した判断の根拠を蓄積し、資産化していく。「判断の資産化」のステップととらえています。

北山：
とても腑に落ちました。判断の資産化、いいコンセプトですね。

倉本：
ありがとうございます。AIを活用するといっても、図面検索できます、文章検索できます、ではなくて、本当に欲しいのは判断を支援してくれるAIなんですよね。
最終的には、
・要求仕様
・BOM
・不具合情報
・設計履歴
こういったものを全部つなげて、人が判断するときに使える状態にする。そこにAIが乗る。そういう世界が来るのかなと思っています。

北山：
そうですね。そして将来的には、要求仕様を入力したら
「候補としてはこれが近い」「過去はこう判断していた」「この案は納期リスクがある」といった提案までしてくれる。そうなった時に初めて、PLMとAIが本当に結び付いたと言えるんじゃないかと思います。でもぜひ、モジュラーデザインやコンフィグレーションを支援したきた身として、個人的にはBOMの自動生成にもチャレンジしていただきたいです。笑