はじめに
最近、データエンジニアリング界隈で「オントロジー」という言葉を見かける機会が増えてきました。X のポストやブログ記事でも、コンテキストエンジニアリングや AI エージェントの文脈で「オントロジー」が取り上げられることが増えています。
X投稿:
記事:
自分自身がオントロジーが何かを調べようとしたとき、文脈によって微妙に違う使われ方をしていたり、説明が抽象的だったり文章が長かったりと、なかなかピンと来る説明が見つけられませんでした。
そこで、この記事では主にデータエンジニア向けの説明として、まずオントロジーとは何か、どのように LLM のコンテキストとなりうるのかをざっくり押さえたうえで、データ基盤での Semantic Layer との役割分担について考えてみたいと思います。
オントロジーとは
オントロジーは特定のドメインの知識を概念や関係、属性として表現したものです。たとえば、「注文は顧客に紐づく」「顧客はメールアドレスを持つ」「注文は支払済、発送済みのステータスがある」のようなドメイン知識を、機械可読なかたちで記述する枠組みがオントロジーです。
オントロジー自体は新しい考え方ではなく、医療ドメインの SNOMED CT（疾患・症状・検査・治療などの関係を整理した医療オントロジー）や、企業内の組織・プロセス・KPI を整理する Enterprise Ontology など、複雑なドメイン知識を構造化する用途で以前から使われてきました。
オントロジーの歴史
オントロジーは LLM で新しく出てきた概念ではなく、もともと「存在するとは何か」を探究する哲学の一分野として発展してきました。その後、1970年代以降の AI や Computer Science, Information Systems の分野で「機械が理解できる知識表現」という意味で「オントロジー」という言葉が使われるようになりました。オントロジーができると、その上で推論エンジンといわれるルールベースのソフトウェアを実行して、たとえば医療オントロジーからは「与えられた症状からなんの病気の可能性があるか列挙する」、サプライチェーンのオントロジーからは「この部品の製造が遅延すると、どの製品の出荷が遅れるかを洗い出す」というような決定的な推論をさせることができます。
LLM 文脈では、「オントロジーを構築する」とは、社内全体や特定の事業・部署に閉じたドメイン知識を、機械可読に構造化することを指すことが多いです。これまでは、社内に散在する知識を一箇所に集め、それを構造化し、さらに日々のアップデートに追従させることのハードルの高さから、医療や金融など、一部のドメインを中心にオントロジーが構築されてきました。
それが、LLM の登場によってオントロジーのメンテナンスコストを下げやすくなり、かつオントロジーを使うインセンティブが高まったため、オントロジー構築にあらためて注目が集まっている...というのが最近の流れだと感じています。
ちなみに、オントロジー関連で名前をよく見る Palantir という会社は、自社データや業務プロセスをモデリングする Foundry というプラットフォームを提供するベンダーです。2010年代から金融犯罪の検知やサプライチェーン管理などの分野で Foundry を提供していて、昨今の「自社データに紐づいた AI エージェント文脈」と相まって、あらためて注目を集めています。
データモデルとの違い
オントロジーはドメイン知識を概念どうしの関係で表すと書きましたが、データモデルや ER図でも同様に概念どうしの関係を has-one / has-many / belongs-to のように表現できます。データモデルがオントロジーと異なる点は、あくまでテーブルをどう設計したかという実装レイヤーの話です。
オントロジーはより人間のメンタルモデルに近いレイヤーで、知識そのものをモデリングすることを目指します。データモデルはメンタルモデルを特定のシステムに落とし込んだ実装の1つに過ぎないため、設計の議論が必要ですし、「イマイチなデータモデル」が存在しえます。
知識の表現とは
オントロジーは、「どんな概念や関係・属性があるか」という観点でドメイン知識をモデリングしますが、人間や機械がオントロジーを扱うためには何かしらのかたちで表現する必要があります。
RDF (Resource Description Framework) はもともと Web 上のリソースとそれらの関係をグラフとして表現するための W3C 標準仕様ですが、オントロジーで定義した概念・関係を記述する代表的な手段として広く利用されています。
RDF では、 主語・述語・目的語の3つで構成される「triple」 によって概念どうしの関係を表します。たとえば、「注文」「顧客」「商品」といったドメイン知識を triple で表すと、次のように書くことができます。
:order_1 :hasCustomer :customer_1 .:customer_1 :hasEmail "user@example.com" .
1つ目の例では、主語が :order_1 で、 :customer_1 という目的語に対して :hasCustomer という述語/関係で結びついています。 Triple は主語と目的語をノード、述語をエッジとしたグラフで表すことができるので、こうした triple を積み重ねることでドメイン知識を機械可読な知識グラフとして構築できます。
Semantic layer の課題
データ基盤でビジネスロジックを反映するレイヤーとしては、すでに semantic layer が広く利用されています。実際、最近のデータ基盤 x LLM の動きを見ると、text-to-SQL や分析エージェントの多くはsemantic layer と LLM を組み合わせる構成になっています。
テーブルやカラムの description、ビジネス指標の定義 (e.g. 売上 = amount の sum) 、LookML/dbt モデルといったコンテキストを渡すことで、LLM に「どのテーブルを使えばいいか」「テーブルどうしをどう結合するか」「どのカラムを集計すればいいか」を伝えられます。
一方で、 semantic layer だけを使った場合、「今月の売上の前月比を教えて」といったシンプルなクエリは生成できるものの、前月比で15%下がっていた場合、その要因が季節要因なのか、組織再編のせいなのか、あるいはそもそも異常値なのか、といった深堀りはしにくいです。
より自律的な分析エージェントをつくるには、社内にどんなエンティティがあり、それらがどのような関係やルールで動いているかというより広いドメイン知識が必要になります。
しかし、「四半期末は大口契約が集中する」「カテゴリーAは冬に需要が高まる」といった知識は、典型的な semantic layer の範囲には収まりません。こうしたドメイン知識を LLM に渡せるコンテキストとして落とし込むために、昔からある知識を機械可読な形式で記述するオントロジーの技術が改めて注目されている、というのが近年の流れだと感じています。
オントロジーと semantic layer の違い
改めてオントロジーの話に戻ると、英語圏の投稿では「Ontology vs Semantic Layer」、つまり「オントロジーがあれば Semantic Layer は不要なのか」という対比をよく見かけます。私自身は「オントロジーと Semantic Layer は補完関係」という (割と多数派の) 意見です。
私見として、オントロジーと Semantic Layer はそれぞれ以下のような役割があると思っています。
- オントロジー: 人間のメンタルモデルを AI に伝える
- Semantic Layer: クエリの選択肢を限定する
Semantic layer の課題は前述の通りですが、一方で、オントロジーだけあれば良い、つまり「ドメイン知識があれば正しいクエリが書ける」という主張についても自分は懐疑的です。
ドメイン知識のある人間でも「売上」の定義がチームごとにブレたり、JOIN や WHERE句を間違えたりすることはわかっていて、semantic layer はこの問題を解決するために登場しました。そのため、オントロジーでドメイン知識を LLM に伝えられても、クエリを正しく書くためのガイド/ガードレールとしての semantic layer は別途必要だと考えています。
実際に semantic layer の効果として、たとえばこちらの記事では semantic layer を与えると、エージェントの失敗する回数を減らすことができたとあります。
出典: https://juhache.substack.com/p/semantic-layer-map-for-chat-bi-agents
まとめると、ドメイン知識を伝えるためのオントロジー、クエリの書き方を伝える semantic layer として両側面からのコンテキストを与えると、より効果的なAIエージェントが組めるはずです。
実際にオントロジーを扱う方法
ここまでで、オントロジーと semantic layer の役割や違いを見てきましたが、実際にどうやって社内のドメイン知識をオントロジーとして管理すべきかという点については、まだ業界全体で定番のやり方があるとは言いづらい状況です。
以下では、自分が調べた範囲で見つけたオントロジー管理の手段をかんたんに紹介します。
Microsoft Fabric のオントロジー機能
Microsoft Fabric では、まだプレビュー段階ではあるものの、機能としてオントロジーが提供されていて、「エンティティ」「リレーション」「プロパティ」といった情報を入力したり可視化するインターフェースがあります。
オントロジーは Fabric の分析エージェント機能の「データエージェント」と連携することで、ビジネス用語を使った分析が可能になります。
こちらの画像はどちらも以下の記事より引用させていただきました。Microsoft Fabric におけるオントロジーがスクショ付きでわかりやすく解説されていました。
Neo4j LLM Knowledge Graph Builder
上の知識表現の箇所で少し触れましたが、オントロジーはグラフ構造として表現できます。そのためオントロジーはグラフデータベースと相性が良く、Neo4j からは Knowledge Graph Builder というツールが提供されています。
Knowledge Graph Builder は名前の通り知識グラフを構築するためのアプリケーションで、PDF や動画、Web ページといった非構造化データから LLM・LangChain を使って知識グラフを自動生成できます。
出典: https://www.youtube.com/watch?v=LlNy5VmV290
概念どうしの関係を表したグラフ・ドキュメントのチャンクどうしの関係を表したグラフの両方が Neo4j データベースに格納されるため、このツールで生成したデータを土台に Graph RAG などの手法が適用できます。
(参考: https://neo4j.com/labs/genai-ecosystem/llm-graph-builder/)
Palantir のオントロジー設計ベストプラクティス
以下のリンクは、記事の冒頭で触れた Palantir のフォーラムに掲載された公式ベストプラクティスです。
想定読者としては Foundry など Palantir のプロダクトを使っているユーザーですが、「ビジネス上の意思決定に必要な情報から概念・関係を抽出する」「概念ごとに担当者をアサインする」「ビジネスユーザーの言葉を使って命名する」といった、オントロジー設計全般に転用できる tips もあります。
まとめ
本記事では、コンテキストエンジニアリングやデータ基盤の文脈でオントロジーが何か、 semantic layer との対比を見てきました。
ポイントをまとめると以下の通りです。
- オントロジーは知識を構造化するための枠組み
- Semantic layer では表現できるドメイン知識に限界がある
- ドメイン知識を LLM のコンテキストに入れるアプローチとしてオントロジーが再注目されている
- 分析エージェントにおいては、オントロジーと semantic layer は補完関係
オントロジーや知識グラフについてもう少し深堀りをしたい場合、以下のレポートがコンパクトにまとまっていておすすめです。
LLM のコンテキストにオントロジーを組み込む手段は、まだ LLM 文脈でもデータエンジニアリング文脈でも業界全体として模索しているフェーズだと思います。「うちのチームではこうしている」「ここがうまくいかなかった」などの知見があればぜひコメントや X で教えてください！
「AI時代だからこそ、 Data Engineering の基礎を固めていきたい」という思いで発足したデータエンジニア2名によるグループです。発信を通して私たちも学んでいきたいと考えているので、フィードバックや感想などいただけるととても嬉しいです！
Discussion