確率論的なAIと、決定論的な業務知識をつなぐ「意味の層」
生成AIの精度は、ここ数年で大きく向上しました。それでも、社内で実際に使おうとすると、ある壁に突き当たることがあります。「デモでは賢いのに、本番では信用しきれない」という壁です。
この壁の正体は、多くの場合、モデルの性能ではありません。統計的な「正しさ」と、業務が求める「毎回同じであること」は、別の指標だという点にあります。一度うまく答えられたかどうかと、同じ問いに、いつでも、根拠付きで、同じ答えを返せるかどうか。後者を業務は要求します。そして後者を支えるのは、AIの性能ではなく、AIの「下」に何を置くかです。
本稿は、その「下に置くもの」——確率論的なAIを支える、決定論的な意味の層について扱います。対象は、エンタープライズでのAI活用を検討する技術・DX・情報システムの担当者の方です。
LLMが「理解」しているもの、していないもの
大規模言語モデル（LLM）は、膨大なテキストから、語と語が「一緒に出てくる」関係——統計的な共起——を学習します。たとえば「Toyota」「Corolla」「保証」「販売店」といった語が近くに現れやすいことを、モデルはよく知っています。
しかし、モデルは次のような関係そのものを、内在的に持っているわけではありません。
- Corolla IS_A 車両（車種は車両の一種である）
- 車両 HAS 保証（車両は保証を持つ）
- 保証クレーム REFERENCES VIN（クレームは車台番号を参照する）
モデルが学習しているのは「パターン」であって、「業務上の確定した意味」ではありません。だからこそ、文脈次第で表現が揺れ、ときに事実と異なる出力（ハルシネーション）も生じます。賢さの問題ではなく、構造の問題です。
オントロジーとは何か ― 用語集との違い
ここで、混同されがちな4つを区別しておきます。
- 用語集・タクソノミー: 語を分類し、階層に並べたもの。「車両 ＞ 乗用車 ＞ ハイブリッド車」のような親子関係を扱います。
- オントロジー: それに加えて、関係・制約・ルールを形式的に定義したもの。「保証は必ず1台の車両に紐づく」「クレームは保証を参照する」といった制約まで含みます。
- ナレッジグラフ: オントロジーという「型（スキーマ）」に、実際のデータ（実体）を接続したもの。
- 言い換えると、オントロジーが「意味の定義」、ナレッジグラフが「定義に沿ってつながった実体」です。
この層があると、すべてのシステムが同じ意味を参照できます。どのシステムにとっても「保証クレーム」が同じものを指す——その共通の土台が、組織のなかにできます。
確率論的推論と、決定論的知識 ― 対立ではなく、層
| 観点 | 生成AI（確率論的） | オントロジー／グラフ（決定論的） |
|---|---|---|
| 性質 | パターンを学習 | 意味を明示的に定義 |
| 強み | 柔軟な言語・推論 | 一貫性・traceability |
| 弱み | 出力のばらつき | 構築・維持にコスト |
| 説明可能性 | 限定的 | 定義に遡って追跡可能 |
| 役割 | 推論する | 根拠を与える |
この2つは、しばしば対比されます。けれど、競合するものではありません。むしろ、互いの弱みを補い合う関係にあります。
LLMは、柔軟な言語理解と推論に強い。一方で、出力にはばらつきが残ります。オントロジー／グラフは、一貫性と追跡可能性（traceability）に強い。一方で、構築と維持にはコストがかかります。強みと弱みが、ちょうど裏返しになっているのです。
ここで誇張は避けます。オントロジーを置けば、誤りがゼロになるわけではありません。定義の誤りや、実体データの欠損があれば、当然そこに引きずられます。それでも、「語の意味が曖昧なまま推論する」という一群の誤りは、構造的に減らせます。重要なのは「どちらを選ぶか」ではなく、「どう重ねるか」です。
意味を「操作可能」にする ― 自然言語から、正確なクエリへ
決定論的な意味の層があると、曖昧な自然言語の問いを、正確なクエリに「翻訳」できます。たとえば、次のような問いを考えます。
北海道で2024年以降に販売されたハイブリッド車の、未処理の保証クレームを見せてほしい。
意味の層がなければ、AIは「ハイブリッド」「北海道」「保証」「未処理」といった語を、テキストだけから推測しなければなりません。意味の層があれば、この問いは既知の概念に対応づけられ、次のように分解されます。
VehicleType = Hybrid DealerRegion = 北海道 SaleDate > 2024 ClaimStatus = Open
近年、この発想を検索・推論に組み込む手法も登場しています。検索拡張生成（RAG）の多くは、ベクトル類似度で関連文書を引きます。これは強力ですが、エンティティ間の関係をたどる必要がある問い——「点と点をつなぐ」問いには弱いという指摘があります。これを補うのが、ナレッジグラフを用いた GraphRAG（Microsoft Research, 2024）です。
ただし、注意点があります。LLMがテキストから自動抽出したグラフと、人手で統制された企業オントロジーは、別物です。前者は手軽ですが、後者のほうが、定義の正しさと監査可能性の点で信頼の度合いが高い。両者は地続きの「スペクトラム」であり、求める信頼性に応じて、どこまで統制するかを選ぶことになります。
構造化と非構造化 ― 二つの入力ストリーム
企業のデータは、二つの形で並行して存在します。一つは構造化データ——基幹システムやデータベースに整然と並ぶ、行と列の記録（取引、マスタ、システムログ）。もう一つは非構造化データ——文書、メール、技術マニュアル、問い合わせ履歴、自由記述の項目、各種ログやシグナルです。
従来、この二つは別々に扱われてきました。構造化データはSQLで問い合わせ、非構造化データは全文検索やRAGで扱う、という具合です。けれど、現場の問いは、しばしば両方にまたがります。
意味の層は、この二つを一つに束ねる場所でもあります。構造化データはそのまま実体として接続でき、非構造化データからは、エンティティと関係を抽出してグラフに取り込めます（前述のGraphRAGは、まさにテキストからグラフを起こす手法です）。どちらの経路を通っても、同じ「車両」「顧客」「クレーム」という既知の概念に解決される——そこに、構造化と非構造化を横断して問える土台が生まれます。
アーキテクチャとして見る
これらを1枚にまとめると、本稿冒頭の図（図解1）になります。データソース（ERP・CRM・DMSなど）の上に、オントロジー＋ナレッジグラフという決定論的な層を置き、その上でLLM・AIエージェントが推論する。出力は、説明可能で、監査可能で、一貫した意思決定になります。
データ → オントロジー → ナレッジグラフ → AI
この順序が、要点です。「データ → LLM」ではなく、間に「意味」を挟む。Cubastionの実装でも、Microsoft Azureを基盤に、構造化フィルタ（決定論的）とセマンティック検索（確率論的）を組み合わせるハイブリッド構成を採っています。
どこで効くのか（概観）
意味の層が効くのは、概念が多数のシステムに分散し、関係をたどる必要がある領域です。
- 自動車: 顧客・車両・販売店・保証・部品・サプライヤー・クレームが、いくつものシステムに分かれて存在します。統一した意味の層があれば、「どのサプライヤー起因の不具合が、どの地域のハイブリッド車で保証コストを押し上げているか」といった横断的な問いに答えられます。
- 金融（BFSI）: 口座・カード・取引・加盟店・国の関係をたどる、不正検知やAML（マネーロンダリング対策）。
- 製造: 部品・工程・不具合の関係をたどる、品質分析と根本原因の特定。
それぞれの具体像は、本シリーズの第2部（自動車）・第3部（金融）で扱います。
実装の現実 ― オントロジーは「作って終わり」ではない
正直に書きます。オントロジーの構築・維持には、相応の労力がかかります。概念の洗い出し、部門間での定義の合意、変化に合わせた更新——これらは技術というより、合意形成とガバナンスの仕事です。
そして、すべての用途に必要なわけではありません。
- 向いている: ドメインが複雑で、同じ概念が多数のシステムに分散し、誤りのコストが高い領域（保証・不正・コンプライアンス・安全）。監査可能性が要件になる場合。
- 過剰なこともある: 単発・小規模で、データが単純で、多少の誤りが許容できる用途。素のRAGやLLMで「十分」なら、そこに意味の層を敷く必要はありません。
見極めの問いは、シンプルです。「この問いに、毎回・正確に・根拠付きで答えられなければ困るか?」 答えがイエスなら、意味の層への投資が効いてきます。ノーなら、まずは軽い構成から始めればよいのです。
まとめ ― 「意味」を定義できた企業が先行する
生成AIの性能は、これからも上がり続けます。しかし、性能が上がるほど、「その出力を業務で信頼できるか」という問いは、かえって重くなります。
次のエンタープライズAIの競争を分けるのは、おそらく最大のモデルを持つ企業ではありません。自社の業務の「意味」を、最も明確に定義できた企業です。オントロジーが意味を与え、AIが推論を担う。両者が重なったとき、データは、決定論的で・説明可能で・信頼できる知性に変わります。
Cubastionは、構造化データフィルタリングとセマンティック検索を組み合わせたGenAI知識基盤 Engineering.IA を、自動車分野の大規模クレームデータで実装しています。「自社のどのデータに、意味の層を敷くと効くのか」を整理したい方は、AI・生成AIサービスのページもあわせてご覧ください。
あわせて、構造化データと非構造化データを「どう結ぶか」を技術的に掘り下げた併走記事もご覧ください：非構造化データを、構造化データとどう結ぶか
本稿は全3部の第1部（概念とアーキテクチャ）です。第2部では自動車、第3部では金融分野での具体像を扱います。