前回のおさらい
前回は、オントロジーとは「業務の概念と関係を機械が誤解しないよう整理した設計図」であり、2000年代の「セマンティックウェブ」時代には専門家が手作業で厳密に作る重い仕組みだった、という話をしました。
今回は本題、なぜこの古びた概念が2026年の今また注目されているのかを掘り下げます。
LLMは「賢い」けど「あなたの会社を知らない」
ChatGPTやClaudeのようなLLMは、Web上の膨大な知識を学習していて、一般的な質問には驚くほど的確に答えてくれます。
でも、こんな場面を想像してください。
「うちの会社では『案件』と『商談』は別の意味で使ってて、『代理店経由の注文』と『直接注文』では承認フローが違うんだけど……」
これ、LLMは知りません。当然です、学習データに載っていないからです。
さらに厄介なのは、AIエージェントが自律的に判断・実行するようになったことです。チャットで答えるだけなら間違いに人間が気づけますが、エージェントが勝手に「案件」と「商談」を混同したまま処理を進めてしまうと、業務が静かに壊れていきます。
つまり課題はこうです。
LLMの知能は十分。でも「その会社固有の意味」を知らないから、業務では信頼できない。
ベクトル検索（RAG）だけでは足りなかった
「じゃあ社内文書を読ませればいいのでは？」と、多くの企業がRAG（Retrieval-Augmented Generation）に取り組みました。文書をベクトル化して、質問に近い内容を検索して回答に使う仕組みです。
これはこれで有効なのですが、弱点もあります。
- 「Aの取引先で、Bという条件を満たすものを全部教えて」のような関係をたどる質問が苦手
- 似た言葉の文書を拾ってくるだけで、概念同士の正確な関係までは理解できない
- 複数の情報源をまたいだ多段階の推論が難しい
ここで「じゃあ、業務の概念と関係を、機械が正確に扱える形で先に定義しておこう」という発想が戻ってきました。これが今のオントロジー再評価の正体です。
昔との決定的な違い
同じ「オントロジー」という言葉でも、今の使われ方は当時とかなり違います。
| 観点 | セマンティックウェブ時代 | LLM/AIエージェント時代 |
|---|---|---|
| 目的 | Web全体での知識共有 | 自社業務でAIに誤解させないこと |
| 作り方 | 専門家が手作業で厳密に定義 | LLMが素案を自動生成→人が調整 |
| 厳密さ | 論理的矛盾ゼロを目指す | 「使えれば十分」なライトウェイト運用も可 |
| ゴール | 機械が意味を理解して連携する | AIエージェントが業務判断を間違えない |
| 例えるなら | 分厚い法律の条文集 | 新人に配る「うちの会社の用語集」 |
つまり今のオントロジーは、厳密な学術体系というより、「AIエージェント用の新人研修資料」に近いイメージです。完璧である必要はなく、「案件と商談を混同しない」レベルの実用性があれば十分、というスタンスに変わってきています。
業界の動きも後押ししている
実際、大手プラットフォーマーも同じ方向に動いています。
- Snowflakeは業務指標やエンティティの関係を定義する「Semantic Views」
- Databricksは指標の定義と集計軸を分離する「Metric Views」
- Microsoftは業務エンティティと関係を定義する「Fabric IQ」の「Ontology」
呼び方は「セマンティックレイヤー」だったり「オントロジー」だったりバラバラですが、狙いは共通していて、AIに渡す前に業務の意味をきちんと整理しておくという点です。
そしてこの効果は数字にも表れていて、意味の層がきちんと整備された範囲の質問については、正答率がほぼ100%に達したという計測結果も報告されています。クエリの生成が決定的（毎回同じ手順で処理される）になるため、LLMが微妙に間違った答えを作りにくくなる、という理屈です。
次回予告
背景と理屈はわかった。では、実際の現場ではどう始めればいいのか。次回は、いきなり全社展開せずに成功させるための、現実的な進め方を紹介します。
→ 第3回「実務では何をすればいいのか」へ続く