顧客がアプリをつくる時代に、図面に残らない“なぜ”をAIへ──Thingsの「モノづくりの記憶」に着目したプロダクト戦略

アセットに乏しいスタートアップが新しい市場へ入るなら、導入が速く、成果がわかりやすく、同じ売り方を横展開できる領域を選ぶのが定石だ。

だが、Thingsが向き合うPLM市場は、その条件から遠い。モノづくりの根幹を扱うため、不具合が起きれば設計・生産・調達・品質保証へ影響が及ぶ。新しいシステムを入れるだけでも多くの関係者の合意が要る。長年使ってきた仕組みを置き換えるなら、なおさらだ。

PLMは、ERPのように「基幹システム」とも呼ばれるほど、影響範囲の大きな仕組みだ。入れ替えは一部門の判断では終わらない。顧客側の時計は、ゆっくりと進む。スタートアップには、その時間を待ち続ける難しさがある。

製造業の中枢に残されていたのは、需要のない空白ではない。買い手と売り手の時計が別々の速さで進むことで生まれた空白だった。

Thingsも当初は、『PRISM』という基幹システムを、従来のPLMより直感的に使えることを武器に導入してもらうつもりだった。だが、プロダクトが使いやすいことと、全社的な意思決定が動くことは、すぐにはつながらなかった。

取材内容等を基にFastGrowにて作成

言葉の整理をしておきたい

以降の議論は、企業システムを役割で三つに分ける見方を前提にしている。この三層は、以降のセクションでも同じ形で繰り返し出てくる。 ここで一度、何がどの層の話なのかを置いておきたい。

企業のシステムは、役割で三つに分けて考えられる。

現場の人とAIが実際に業務を進めるエンゲージメント層。図面を探す、FMEAをつくる、リスクを評価する——日々の操作が起きる場所である。

その下に、データへ意味と関係を与えるセマンティック層。どの文書がどの製品に属し、どの変更がどの判断から生まれたのかを定める。これまでは人が頭の中でつないでいた部分で、層として独立していなかった。ここが新たに生まれたとも言える。

いちばん下が、正本を保持するデータ層。何を「正しい記録」として扱うかが、ここで決まる。

取材内容等を基にFastGrowにて作成

〔注〕この「セマンティック層」の周りには、近い意味で使われる言葉がいくつかある。オントロジー、コンテキスト。どれも「データに意味を与える」ことを指しているが、書き手によって指す範囲が違う。ここで一度、区別しておきたい。セマンティックは、データに意味を与えること全般を指す、いちばん広い言葉である。オントロジーはその手段の一つで、ものごとの種類と、種類どうしの関係を、機械が扱える形で定義したものを指す。「これは部品である」「この部品はこの製品に属する」という取り決めそのものだ。コンテキストは、AIが答えを出すその場で参照する情報のまとまりで、多くは一度きりで消える。この記事が層の名前に「セマンティック」を採るのは、ここで問題にしているのが、手段（オントロジー）でも、一時的な参照（コンテキスト）でもなく、企業のシステムの中に層として残り続けるものだからである。

三層は互いを支え合う。データ層に正本があっても、意味づけがなければAIは根拠として使えない。現場が毎日使うエンゲージメント層がなければ、正本にデータは溜まらない。

PLMは、ERPやMESと並ぶ製造業の基幹システムである。そして『PRISM』は、この三層すべてをつくっている。すぐ使えるアプリケーションも提供し、その下の意味づけも、いちばん下の正本も自社で持つ。ただし重心は、下の二層にある。

なお、AIが人に代わって業務を進める部分は、SoA（System of Action、あるいはSystem of Agents）と呼ばれることがある。呼び方はまだ定まっていない。 この記事では、エンゲージメント層のうちAIが業務を動かす部分として扱う。

海外に目を向ければ、従業員情報というデータ層から始めて複数のプロダクトへ広げたRipplingのような型も、既存の記録システムへ接続して、その上でAIが顧客対応を進める層をつくるSierraのような型もある。だがThingsは、そのどちらとも違う。入口は上（エンゲージメント層）から、つくったのは下（正本とその意味づけ）から。両方を同時に進めている。

なお、この「下」にあたる部分をSoA等と対になるかたちでSoR（System of Record）と呼ぶこともあり、すべての判断のよりどころとなる正本データを司るものとして、強いプロダクトの条件としても語られる。Thingsはまさにこの立ち位置を狙い、緻密な開発を進めてきたのだ。

なぜ日本で、この二重の課題が起きているのか。前職で機械系エンジニアとして業務用パソコンの開発・量産立ち上げを担った瓜本氏は、現場の実感としてこう語る。

バーティカル領域のDXは、その業界の「現場」を捉えられる技術が現れたときに、大きく動く。鈴木氏は、製造業の技術転換をこう捉えている。

わかりやすい先行例が、建設・建築業界にある。この業界を動かした技術は、スマートフォンだった。

作業員がその場で図面を確認し、施工中の写真を撮り、日報を入力する。かつては紙や口頭で現場と事務所を往復していた情報が、日々の仕事の中でそのまま記録され、同じプロジェクトの関係者へ瞬時に共有されることで業務効率化が進んだ。スマートフォンが変えたのは、記録が生まれる場所だ。工事が行われる場所という建設業の「現場」を、その場でキャプチャできるデバイスが、業界の慣習を大きく変えた。紙と口頭で分かれていた記録どうしの関係性が、ここではじめて、正本として明確に保たれるようになった。

取材内容等を基にFastGrowにて作成

では、製造業の「現場」はどこにあるのか。

製造業の現場、というと工場を想像する人は多いかもしれない。しかし工場の自動化は、すでに一定実現されている。センサーやカメラの導入が進み、機械がいつ止まったのか、温度がどう変化したのか、不良品がいくつ生まれたのか。「何が起きたか」を捉えるIoT技術は浸透し、効率化も一定進んだ。

だが、それだけではわからないことがある。

なぜ、その部品を選んだのか。なぜ、その形状にしたのか。どの不具合を懸念し、どこまでのリスクを許容したのか。完成した図面はあくまでも成果物として、最終的な形状や仕様が記されている。しかし、そこへ至るまでの設計者の思考プロセスや、判断の根拠は図面だけでは読み解けない。設計者をはじめとするホワイトワーカーが担うこの思考工程こそが、工場の次の「現場」である。

では、その情報はどこにあるのか。担当者の頭の中にしかないものは、残念ながら復元できない。しかし図面の注記、要件書、過去に作成したエクセルのFMEA帳票、品質報告書、議事録、メールなどに断片的に残されている。その断片を寄せ集め、その意味合いや関係性を明確化（これをオントロジーと呼ぶことがある）して繋ぎ合わせることで、人やAIが活用できるデータとして資産化される。

従来のシステムが得意としてきたのは、あらかじめ項目や形式が決められた構造化データである。

LLMは、非構造化データを扱える。文章や画像の意味を捉え、異なる形式のファイルを地続きで扱うことができる。スマートフォンが建設現場で「起きたこと」をその場に残せるようにしたとすれば、LLMは製造業で、文書に埋もれていた「なぜそうしたのか」を、使える記録へ変える技術だ。製造業に残されていた新しい「現場」は、設計者が下した判断そのものであり、その痕跡が残された文書の山を、LLMがようやく読めるようにした。

設計開発DXの時代が、ここから始まる。

そして『PRISM』は、その情報をただ一つの箱へ集めるのではない。製品を構成する部品を軸に、図面、仕様、品質、設計変更、過去の不具合を結び付けている。それぞれの文書が、どの製品や部品に関係し、どの判断を経て現在の形になったのかをたどれる状態をつくる。

ただし、文書を読めるようになっただけで、異なる部門の情報が自動的につながるわけではない。断片を繋ぐには、何と何を「同じもの」として扱うのかを決めた骨格が要る。図面管理、品質管理、生産管理がそれぞれ別のデータ構造を持ったままなら、今度はAIが、どの部品についての情報なのかを判断できない。

その骨格を、製造業はすでに持っている。

ここで、架空の例を一つ置いてみる。実在の事故ではなく、製造業でよく起きる構図を単純化したものだ。

ある日、組立ラインの完成検査で、製品内部から微量の液漏れが見つかった。分解して調べると、原因はポンプユニットに使用されているシール部品の寸法不良だった。目の前の一台を修理するだけなら、部品を交換すればよい。しかし、現場と関係部門が判断しなければならないのは、その先である。

この部品は、他のどの機種に組み込まれているのか、仕掛品や在庫品だけでなく、すでに出荷した製品にも影響が及ぶのか。設計変更によって、途中から別の部品に切り替わっていないか。そして、生産を止めるべきか、継続してもよいのか。

オントロジーという言葉が広まるずっと前から、製造業が積み上げてきたものがある。BOMだ。この調査の速さを決めるのが、BOMである。

BOMはBill of Materialsの略で、日本では「部品表」と呼ばれる。一つの製品が、どのユニットと部品から、それぞれ何個ずつ構成されているかを表したものだ。完成品の下にユニットがあり、その下に部品が連なる。今回のシール部品であれば、ポンプユニットの下にぶら下がり、そのポンプユニットは複数の完成機種の下に置かれている。ただの一覧表に見えるが、ここに並んだ型番の一つひとつが、製造業のあらゆる情報を結び付ける鍵になる。

部品表を管理しない製造業は存在しない。多くの製造業が、部品構成の一覧として持っている。違いは、そこへ図面や品質、設計変更が意味を持ってひも付いているかどうかにある。従来からある、一覧としてのBOMは、どの部品が何個要るかを見やすくするに留まり、そこから先へスムーズにたどりやすいものではなかった。『PRISM』がBOMを中核に据えたのは、一覧としてではなく、情報どうしの関係を保つ骨格として使うためである。

冒頭の例に戻る。製造は組立手順書、設計は図面と設計変更票、調達は入荷ロット、品質保証は過去の不具合記録、生産管理は製造実績。同じ部品についての話が、部門ごとに別の資料へ散っている。ただし、資料そのものは、散らばったままでも大丈夫だ。

取材内容等を基にFastGrowにて作成

『PRISM』では、BOMを共通の鍵として、部品、製品、図面、設計変更、組立手順、過去の不具合といった情報がつながっている。ユーザーはAIアシスタントに、例えば次のように尋ねるだけでよい。

「不具合が見つかった部品番号P-1842の影響範囲を調べて。使用されている製品、対象となる図面と設計変更、過去の類似不具合、連絡すべき部門を整理して」

AIアシスタントは、その部品からBOMを上位へたどり、影響の及ぶ範囲を判断の根拠とともに返す。

これにより、現場は「影響範囲が分からないから止め続ける」のではなく、対象を限定したうえで、在庫の隔離、代替部品への切り替え、一部製品の生産再開、顧客への連絡といったアクションを早期に判断できる。従来は半日から数日を要していた初動調査を数分から数十分に短縮できれば、生産停止時間そのものを大幅に減らせる。

この経路は、調べるためだけのものではない。逆向きにも通る。

不具合の原因や対応結果が、部品や製品にひも付く新たな知見として残る。今回の経験が、次の設計審査やFMEA、類似製品の部品選定で使われる。

ただし、非常時にだけ開く経路では意味がない。日々の仕事で使われ続けていなければ、いざというときにも機能しない。製品情報の入力自体は、以前からそれなりに緻密に行われてきた。複数部門・複数企業で一つの製品をつくる以上、図面、部品、設計変更、品質情報を共有し更新する仕事は避けて通れない。壁になっていたのは、既存のPLMが現場の日常業務まで届き切らなかったことだ。高額な費用を投じても、入力負荷が高く、現場に定着しない。正しい記録を残すべき仕組みと、現場が実際に触れる場所が、分かれてしまっていた。

冒頭に述べたとおり、『PRISM』は使いやすさを追求すると同時に、複雑でとっつきにくかったPLMのユーザー側の接点を、普段から使えるアプリケーション＝エンゲージメント層へつくり替えてきた。記録の仕組みと現場のあいだに残った、この「ラストワンマイル」を越えるためである。探す・作業する・評価するという毎日の接点を押さえることで、業務の実行と記録の蓄積を同じ流れにする。

この層が導入の可否を左右することもある。ある装置メーカーは、他社のPLMの導入をいったん決定したものの、1年間経って定着しないと判断し、『PRISM』を選び直した。判断の理由は機能の多さではなく、設計者が毎日開き、使いこなせるかどうかだった。エンゲージメント層とは、この差が現れる場所である。

ある導入企業では、毎日数時間かけていた資料探しが、10分で済むようになった。他部署から届いていた「この図面の最新版はどこにあるのか」というメールでの問い合わせは、常に最新版がクラウドで共有されるようになり、問い合わせ自体がなくなった。規制対象になった部品の差し替えも、数百枚のエクセル部品表を開いて回る作業から、数クリックで終わる作業に変わった。

こうした日々の便利さが入力の負荷を上回るから、現場は使い続ける。使われるたびに、製品、設計、品質、失敗、判断の文脈が、BOMへひも付いた形で蓄積する。その循環があって初めて、鈴木氏の言う「モノづくりの記憶」が育つ。

なお、『PRISM』の導入は、既存の基幹システムを置き換えることを意味しない。新規導入・置き換え・共存のいずれの入り方もできるが、どの入り方でも、既存の基幹システムからマスターを奪う必要はない。モノの正本は既存側に置いたまま、判断の正本を新たにつくる。それが現実的な入り方だ。

アプリケーションを先に売り、その下でBOMをつくり込む。Thingsが選んだこの順番の意味が、いま変わり始めている。

生成AIの浸透により、業務アプリケーション単体の開発コストは大きく下がった。大企業から中小企業まで、特定業務にフォーカスした簡単なアプリケーションなら自社でつくれる。一方で、自社のAIエージェントを自律的に賢く育てる仕組みや、複数部門をまたいで使うためのアクセス権限、認証の仕組みなどのインフラの構築には専門知識が必要だ。

この領域は大企業にとっても自社開発の経験が浅く、そもそもメーカーとしてのコア業務ではない。だからこそ、高い信頼性が求められ、一朝一夕には真似できない部分に光が当たり始めている。

『PRISM』の使い方は、Thingsが提供するアプリケーションを使うところで止まらない。導入したあと、顧客自身がアプリケーションを開発して足していける。導入した時点が、拡張の出発点になる。

実際に、自社で見積作成のアプリケーションをつくった、とある公共施設メーカーがいる。『PRISM』のAPIを通じて最新の製造実績を読み込み、それをもとに見積を組み立てる仕組みだ。実績は日々更新されるため、見積の前提も自動的に最新へ入れ替わる。アプリケーションが増え、現場で使われるほど、活用できる情報が増えていく。

ClaudeをはじめとするAIエージェントは、いま急速に企業へ浸透し、従来ならSaaS事業者が提供していたようなアプリケーションを自社で内製する事例が日々生まれている。顧客内のアプリケーションの数が増えれば増えるほど、そこで生み出されるデータを循環させて別のアプリケーションで活用したいニーズが高まる。『PRISM』が持つ正本としてのデータと、意味付け・関連付けの仕組みがこの循環を支える。

逆に、その土台がないままアプリケーションだけが増えると、何が起きるのか。

アプリケーションが増えるほど、次のアプリケーションが参照できる記録は厚くなる。逆に振れる筋道もあった。共通の軸がないまま増やせば、増えた数だけつなぎ直す仕事が生まれる。どちらへ転ぶかは、下に何があるかで決まる。

アプリケーションが増えるほど負債になる、という筋道もありえた。業務ごとに別々のデータ構造でつくられていれば、増えた数だけつなぎ直す仕事が発生する。そうならないのは、意味と関係を決める層が、アプリケーションより先に存在しているからだ。生成AIでアプリケーションが誰にでもつくれるようになったことは、その層を持つ側と持たない側の差を、そのまま広げる方向に働く。

取材内容等を基にFastGrowにて作成

顧客が自分でアプリケーションを増やしていけるのは、増やしても突合表が生まれない土台があるからだ。つくる速さが上がるほど、この差は開く。

突合の作業が挟まれば、そこで誤りも生じる。AIは古い図面や別の部品の情報を、正しい前提として扱いかねない。Thingsが「正本（Single Source of Truth）」にこだわるのは、AIと人が同じ対象について矛盾のない判断をするためである。

アプリケーションそのものは、生成AIによって、これからさらに生み出しやすくなる。そのとき競争力を分けるのは、どの業務へ日常的に入り、どの記録を蓄積し、その記録を次のアプリケーションへどれだけ正確に渡せるかである。

なぜ鈴木氏は、この遠回りの道を選んだのか。原体験は、三菱商事時代にある。ドバイ向けの鉄道案件でPMを務め、複数国のメーカーとの折衝を最前線で担っていたときのことだ。

この視点は、事業の進め方にもそのまま表れている。

サプライチェーン全体で品質を作り込む仕組みは外部のベンダーとして要件を聞くだけでは理解できない。何度も現場に通い、担当者と会話を重ね、ビジョンに共感してもらい、一緒に作ることではじめて輪郭が見えてくる。だからThingsは、要求が厳しく、部門構成も入り組んだ大企業の現場を、あえて最初の相手に選ぶ。グローバル・ブレインをはじめとする株主が、出資にとどまらず大企業との協業の前線まで伴走しているのも、この方針に沿ったものだ。

さらに、その先に見据えているのは、Thingsという会社の成長だけではない。

では、誰とつくるのか

この顧客との向き合い方は、そのまま仕事の形になる。

顧客が抱える経営課題を理解し、現場の業務フローと技術的な制約を解きほぐし、『PRISM』でどこまで解決するのかを設計する。さらに、複雑な組織構造や意思決定の流れを捉え、関係者を巻き込みながら実現へ進めていく。経営、業務、組織、技術を横断して提案と判断を重ねるため、職種を問わず、常に新しいことを学び続けられる環境がある。

もう一つの魅力は、製造業の深い実務と、急速に進化するAIの最前線、その両方に立てることだ。顧客との対話から見つかった課題が、新たな機能やAIアプリケーションへ発展する可能性もある。

Thingsはまだ、製造業の標準を塗り替えた会社ではない。AIがエンジニアリングを自律的に進める未来も、部分的にしか実現していない。それでも、そこへ近づくための条件は一つずつそろってきた。図面や資料を探すために現場が毎日開く画面がある。製品と部品の関係を記録する仕組み（BOM）がある。その上でAIアプリケーションを動かせる構造もある。

記録が生まれる場所と、それが効く場所は違う。製造の現場で見つかった不具合が、部品を介して設計へ戻る。一つの業務で入力された事実が、別の業務の判断を変える。

人が替わっても、ノウハウが失われない。過去の失敗や設計意図をAIが読み、次の設計や品質改善へ返す。一つの現場で生まれた知見が、別の顧客や新しいアプリケーションへ広がっていく。

取材内容等を基にFastGrowにて作成

日本の品質は、これまで人に付いていた。それを仕組みへ移せば、担い手が替わっても、拠点が海外へ移っても、同じ設計と同じ品質を再現できる。日本の品質そのものを、輸出できる形にする。その共通基盤を、Thingsは下からつくっている。