保証・コネクテッド・サプライヤー品質をつなぐ、ナレッジグラフという発想
本稿は、エンタープライズAIの「意味の層」シリーズの第2部です。第1部では、確率論的なAIを決定論的な業務知識（オントロジー／ナレッジグラフ）で支える、という考え方を扱いました（第1部はこちら）。第2部では、それが最も効く領域のひとつ——自動車を、具体的に見ていきます。
自動車のデータは、「つながっていない」
自動車のデータは、一か所にありません。販売は DMS（販売店管理）に、設計・部品構成は PLM に、保証は保証システムに、走行データはテレマティクスに、品質クレームはまた別のデータベースに——というように、目的別のシステムに分かれて存在します。
それぞれのシステムは、単体では優秀です。問題は、それらを横断して一つの問いに答えようとした瞬間に現れます。同じ「車両」「部品」「クレーム」という言葉が、システムごとに別のIDで、別の粒度で記録されている。人が手作業でつなぐには、膨大な照合が必要になります。
検索拡張生成（RAG）も、ここでは万能ではありません。多くのRAGはベクトル類似度で「似た文書」を引くため、文章の検索には強い。しかし「点と点を、関係をたどってつなぐ」問いには弱い、という指摘があります（第1部で触れたGraphRAGの動機です）。
自動車ドメインの中核エンティティと関係
自動車のデータには、業務を問わず繰り返し現れる中核エンティティがあります。顧客・車両・販売店・保証・部品・サプライヤー・クレームです。これらの関係は、本来とても明快です。
- 顧客は車両を所有する
- 販売店は車両を販売する
- 車両は保証を保有し、保証はクレームを対象とする
- 車両は部品から構成され、部品はサプライヤーから供給される
- クレームは、問題のあった部品を参照する
この関係を、VIN（車台番号）を軸に、意味の層（オントロジー）として一度定義してしまえば、どのシステムから来たデータも、同じ意味の上に乗ります。「車両」が、すべての文脈で同じ車両を指す——その共通の土台ができます。
なお、これらのエンティティは、構造化データだけから生まれるわけではありません。保証やクレームの多くは、VIN・部品番号・日付といった構造化メタデータと、不具合の状況を綴った自由記述（非構造化テキスト）の両方を持ちます。さらに整備マニュアルや作業記録、テレマティクスのログも、非構造化の入力ストリームです。意味の層は、その両方を同じ実体に結びつけます。Engineering.IAが構造化フィルタとセマンティック検索を組み合わせているのは、まさにこのためです——型でしぼり込み、文章の意味で探す。構造化と非構造化を、一つの問いの中で扱えるようにしています。
横断クエリ ― 「点と点をつなぐ」問いに答える
意味の層があると、これまで「数週間の集計作業」だった問いが、一回のクエリになります。たとえば、品質部門のこんな問いです。
どのサプライヤー起因の部品不具合が、どの地域のハイブリッド車で、保証コストを最も押し上げているか?
これは、単一の表を引く問いではありません。サプライヤー → 部品 → 車両（ハイブリッド）→ 地域 → 保証クレーム → コストという、複数のエンティティを順にたどる「マルチホップ」の探索です。
ベクトル検索だけでは、この連鎖を再現しにくい。一方、ナレッジグラフの上では、定義されたエッジ（関係）を順にたどるだけで答えにたどり着きます。AIエージェントは、自然言語の問いをこのグラフ探索に「翻訳」し、根拠（どのクレーム・どの部品・どのサプライヤーか）付きで返します。
コネクテッドカー ― 走行シグナルを同じグラフに載せる
ここにテレマティクスのシグナル（DTC＝故障コードやセンサーデータ）を、同じグラフに接続すると、できることがさらに広がります。
走行中に現れた異常の兆候を、車両 → 部品 → サプライヤー → 製造ロットという関係でたどれば、予兆検知や、リコール範囲の精密な特定につながります。「どのサプライヤーの、どのロットの部品を積んだ車両（VIN）が対象か」を、関係をたどって絞り込めるからです。範囲が広すぎても狭すぎても問題になるリコールにおいて、この精度は実利に直結します。
実装の現実 ― VINの名寄せから始まる
率直に言えば、自動車のナレッジグラフは、いきなり全社規模で作るものではありません。出発点は、ほぼ常にVINを軸にした名寄せ（エンティティ解決）です。同じ車両・同じ部品が、システムごとに違う表記・違うIDで記録されている——その表記揺れ・重複・欠損を、どう一つの実体に束ねるか。ここがデータ品質の勝負どころです。
そして、すべてを一度にモデル化しようとしないこと。一つの保証・品質ユースケースに範囲を絞り、そこで効く最小限のエンティティと関係だけを定義してPoCを回す。第1部で述べた「この問いに、毎回・正確に・根拠付きで答えられなければ困るか?」という見極めを、ここでも使います。
実例 ― Engineering.IA
ある大手商用車メーカーのエンジニアは、長年にわたり蓄積された数十万件の技術クレームを抱えていました。しかし、その知識の活用は、Excelのフィルタリングと担当者の記憶に頼っていました。
Cubastionが構築した Engineering.IA は、この大規模なクレームデータを、構造化フィルタリング（決定論的）とセマンティック検索（確率論的）を組み合わせたハイブリッドRAGで、会話的に検索・分析できる知識基盤に変えました。回答には必ず出典（クレームID）が付き、根拠まで遡れます。派手な機能ではありません。けれど、エンジニアが迷わず使い始められたのは、「意味」と「出典」が整っていたからです。
これは、本シリーズの主張の縮図です。性能の高いモデルを足したのではなく、データに意味と追跡可能性を与えた。それが、現場で使われ続けるAIと、使われないAIを分けました。
まとめ ― 結べているか、が差になる
自動車のエンタープライズAIで差がつくのは、おそらくモデルの新しさではありません。顧客・車両・部品・サプライヤー・クレームという中核エンティティの「意味」を、どれだけ結べているかです。
意味が結ばれていれば、横断的な問いに、根拠付きで、毎回同じ品質で答えられます。結ばれていなければ、どれほど高性能なモデルも、分断されたデータの前で立ち止まります。
Cubastionは、自動車業界向けのエンタープライズAI・DXを、横浜拠点の日本語対応チームで支援しています。「自社のどのデータを、VINを軸にどうつなぐと効くのか」を整理したい方は、AI・生成AIサービスもあわせてご覧ください。
あわせて、構造化データと非構造化データを「どう結ぶか」を技術的に掘り下げた併走記事もご覧ください：非構造化データを、構造化データとどう結ぶか
本稿は全3部の第2部（自動車ドメイン）です。第3部では、金融分野（不正検知・AML）での具体像を扱います。