「商談」と「案件」は同じものか、別物か。「顧客」には休眠した相手も含むのか。日々の業務で当たり前に使う言葉も、いざ機械で扱おうとすると定義が曖昧で、システムごとに食い違っていることが少なくありません。この言葉と概念の意味をきちんと定義し、機械が解釈できる形にするのがオントロジー（Ontology）です。ナレッジグラフ入門の続編として、その中身を掘り下げます。
オントロジーとは
オントロジーとは、ある領域（ドメイン）に存在する概念（クラス）と、その関係、満たすべき制約を明示的に定義した「共有された語彙の設計図」です。もとは哲学の「存在論」に由来しますが、情報技術の世界では「対象世界をどんな概念でモデル化するか」を取り決める実務的な枠組みを指します。
たとえば営業ドメインなら、「顧客」「商談」「製品」をクラスとして定義し、「顧客は商談を持つ」「商談は製品を含む」といった関係を定め、「商談には必ず一人の担当者がいる」といった制約を加えます。これにより、人によって解釈が揺れていた業務知識が、機械にも人にも同じ意味で通じる共通言語になります。
オントロジーとナレッジグラフの関係
両者はよく混同されますが、役割は明確に違います。
- オントロジー＝スキーマ（型・ルール）：どんな概念と関係が存在しうるかの定義。いわば設計図。
- ナレッジグラフ＝インスタンス（実データ）：その設計図に従って積み上げた具体的な事実。
「人は組織に所属する」と定めるのがオントロジー、「田中はA社に所属する」という事実がナレッジグラフ、という関係です。良いオントロジーがあるほど、ナレッジグラフは一貫性を保ち、矛盾や重複を防ぎながら拡張できます。逆に設計図なしに事実を積み上げると、すぐに「意味の通らないグラフ」になってしまいます。
標準技術：RDF・RDFS・OWL
オントロジーやナレッジグラフを記述するために、W3Cが定めた標準技術群があります。
- RDF：事実を「主語 — 述語 — 目的語」のトリプルで表す基本データモデル。
- RDFS：クラスや継承（「課長は社員の一種」）など、基本的な語彙の枠組みを定義する。
- OWL：より厳密な制約や論理を表現できる言語。「同一とみなす」「両立しない」といったルールや、機械による推論を可能にする。
- SPARQL：RDFデータに対する問い合わせ言語。SQLのグラフ版にあたる。
これらを使うと、明示的に書いていない事実を推論で導けるのが大きな利点です。たとえば「東京は日本の一部」「渋谷は東京の一部」と定義しておけば、「渋谷は日本の一部」と機械が自動で結論づけられます。一方で、すべてをOWLで厳密に作り込む必要はなく、目的に応じて軽量なRDFS止まりにする判断も実務では重要です。
オントロジー設計の進め方
設計は次のような流れで進めます。
- 1. 範囲と目的を決める：何のためのオントロジーか。問いに答えられる範囲に絞る。
- 2. 重要な概念を洗い出す：業務で頻出する名詞（顧客・契約・製品…）を列挙する。
- 3. クラス階層を整理する：概念の上下関係（一般⇄具体）を決める。
- 4. 関係とプロパティを定義する：概念同士をどうつなぐか、どんな属性を持つかを定める。
- 5. 制約とルールを加える：必須項目や数の制限、両立しない関係などを明示する。
- 6. 既存の標準語彙を再利用する：schema.orgなど公開オントロジーを流用し、車輪の再発明を避ける。
業務での活用例
オントロジーは地味に見えて、効果は広範囲に及びます。
- データ統合の共通語：部門ごとに異なる用語を一つの意味体系に束ね、名寄せやマスタ統合を支える。
- 高度な検索・質問応答：概念の関係をたどり、単純なキーワード一致を超えた答えを返す。
- 規制・コンプライアンス：ルールを明示的に定義し、違反の自動チェックに使う。
- 生成AIの土台：LLMの回答を、定義済みの概念と事実に紐づけて検証可能にする。
つまずきやすいポイント
よくある失敗は最初から完璧を目指しすぎることです。あらゆる例外を網羅しようとすると、誰も保守できない巨大な定義になって破綻します。実務では「小さく作り、使いながら洗練する」のが鉄則です。また、オントロジーは一度作れば不変ではなく、業務の変化に合わせて更新し続ける必要があります。設計と運用をセットで考えることが欠かせません。
まとめ
オントロジーは、曖昧な業務知識に明確な意味を与え、機械が一貫して扱えるようにする「概念の設計図」です。ナレッジグラフの品質を支える土台であり、生成AIの信頼性を高める鍵でもあります。次は、これらをLLMと組み合わせる実践としてGraphRAGを見ていきましょう。