オントロジーとは？RAG・AIエージェントの精度を高める業務知識の定義を徹底解説

---

はじめに

社内文書を検索して回答するAIの仕組み（RAG）を作ったものの、「現場の言葉で質問すると答えられない」「複数の文書にまたがる質問になると急に精度が落ちる」と感じたことはないでしょうか。原因の多くは、AIが文書の「意味のつながり」を持っていないことにあります。文章を断片として検索するだけでは、「この製品の図面はどれか」「この顧客の注文はどの担当者が対応したか」のような、業務では当たり前の関係をたどれません。

この課題に対する答えのひとつが、本記事のテーマであるオントロジーです。オントロジーとは、業務に登場する概念（顧客・注文・製品など）と、概念どうしの関係（顧客は注文を出す、など）を、AIが扱える形で定義したものです。Microsoftの研究では、オントロジーで検索を裏付けたRAGは、正確な事実の再現率が55%、回答の正しさが40%向上したと報告されています（詳細は本文で解説します）。

本記事では、オントロジーの定義とよく混同される用語との違いから、小さく始める作り方、RAG・AIエージェントへの活かし方までを、公開論文と一次情報に基づいて解説します。

目次

1. オントロジーとは：基礎知識
2. オントロジーの作り方：小さく始める実装ステップ
3. 応用・発展：LLMによる構築支援とAIエージェントへの展開
4. まとめと結論

1. オントロジーとは：基礎知識

1-1. 業務の概念と関係を定義したもの

オントロジーとは、対象とする世界（ここでは業務）に何が存在し、それらがどう関係しているかを、機械が扱える形で明示的に定義したものです。情報科学の分野では1990年代から知識表現の研究で使われてきた用語で、「概念化の明示的な仕様（an explicit specification of a conceptualization）」と定義されています（Gruber, 1993）。

定義だけでは分かりにくいので、製造業の受注業務を例にします。この業務には「顧客」「注文」「製品」「図面」といった概念が登場します。そして概念の間には関係があります。

• 顧客は注文を発注する
• 注文は製品を含む
• 製品は図面を参照する

この「概念の一覧」と「関係の一覧」を書き出して定義したものがオントロジーです。ポイントは、オントロジーはデータそのものではなく、データの意味を定めるルール（定義）だということです。個々の顧客名や注文番号はデータであり、「顧客は注文を発注する」はそのデータをどう解釈するかの定義にあたります。

1-2. スキーマ・ナレッジグラフ・RAGとの違い

オントロジーは、データベースのスキーマやナレッジグラフとよく混同されます。違いを表で整理します。

用語	何を扱うか	目的
オントロジー	概念と関係の「定義」	業務の意味を人間とAIの共通ルールにする
データベーススキーマ	テーブルとカラムの「構造」	システムがデータを正しく格納・処理する
ナレッジグラフ	定義に従って実データを結んだ「グラフ」	関係をたどった検索・推論を可能にする
RAG	文書を検索して回答する「仕組み」	AIの回答を社内文書などの根拠に基づかせる

補足: RAG（Retrieval-Augmented Generation：検索拡張生成）は、質問に関連する文書を検索し、その内容を根拠としてLLM（大規模言語モデル）に回答させる仕組みです。オントロジーはRAGと対立する技術ではなく、RAGの検索を賢くするために組み合わせて使います。

スキーマとの違いが特に重要です。スキーマは「t_order テーブルに cust_cd カラムがある」のようにシステム都合の構造を定めます。一方オントロジーは「顧客が注文を発注する」のように現場の人間が使う言葉と関係で意味を定めます。同じデータでも、スキーマだけではAIは cust_cd が「得意先」とも「クライアント」とも呼ばれる同じ概念だと分かりません。この対応付けを担うのがオントロジーです。

ナレッジグラフとの役割分担はこうです。オントロジーが「顧客は注文を発注する」と定義し、ナレッジグラフはその定義に従って「A社 → 発注する → 注文#1234」のように実データを結びます。オントロジーなしでもナレッジグラフは作れますが、定義がないと関係の名前や粒度がばらつき、たどれないグラフになりやすいため、両者はセットで扱われます。

1-3. 従来のRAGの弱点と、オントロジーが精度を高める理由

従来のRAGは、文書をチャンク（数百文字程度の断片）に分割し、質問と意味の近いチャンクをベクトル検索で拾って回答します。この方式には構造的な弱点が3つあります。

1. 表記ゆれ・同義語に弱い：「得意先」で書かれた文書は、「クライアント」での質問と意味がずれ、検索から漏れることがあります。
2. 文書をまたぐ関係をたどれない：「製品Xの図面を作った担当者は誰か」のように、複数の文書に分かれた事実をつなぐ質問に答えられません。チャンクは互いの関係を知らないためです。
3. 全体を横断する質問に答えられない：「この1年の障害報告に共通する原因は何か」のような、データセット全体を見渡す質問は、そもそも「検索して読む」方式では扱えません。

オントロジーは、この3つにそれぞれ効きます。別名の定義が表記ゆれを吸収し、関係の定義が文書をまたぐ事実をつなぎ、概念単位の集約が全体横断の要約を可能にします。この効果は、Microsoftの研究でも数値で確かめられています。研究は2つあり、答えたい質問の種類によってアプローチが分かれます。

ひとつ目は、質問のたびに読む範囲を絞り込む方法です（OG-RAG、Microsoft、2024年）。オントロジーに沿って文書を意味のまとまりごとに整理しておき、質問が来たら、関係するまとまりだけをAIに渡します。無関係な文書を最初から外せるため、「製品Xの図面を作った担当者は誰か」のような、特定の事実を問う質問で精度が上がります。4種類のLLMでの評価で、正確な事実の再現率が55%向上、回答の正しさが40%改善、事実に基づく推論の精度が27%向上したと報告されています。

ふたつ目は、あらかじめ要約を作っておく方法です（GraphRAG、Microsoft Research、2024年）。LLMに文書からエンティティ（実体）と関係を抜き出させてナレッジグラフを作り、関係の深いまとまりごとに要約を用意しておきます。この下準備があると、「この1年の障害報告に共通する原因は何か」のように、文書を1つずつ読んでいては答えられない質問にも対応できます。100万トークン規模のデータセットで、従来型RAGでは扱えなかったこうした質問に対し、回答の包括性と多様性の両面で上回ったと報告されています。

つまりRAGの精度がそれ以上伸びなくなったとき、チャンクの切り方や検索モデルの調整だけでなく、データの意味構造そのものを整えるやり方が、研究で裏付けられたもうひとつの選択肢になります。高精度なRAGをDifyで構築する手法についてはこちらもご参考ください。

2. オントロジーの作り方：小さく始める実装ステップ

オントロジーと聞くと、全社のデータを網羅する大規模な整備を想像しがちですが、最初からそれを目指す必要はありません。ここでは対象業務1つ・概念5〜10個の最小構成で作り始める手順を解説します。

2-1. 業務の名詞と関係を洗い出す

最初の材料は、すでに社内にあります。業務マニュアル、帳票、基幹システムのマスタ、用語集です。そこから次の3つを書き出します。

1. 概念（名詞）：業務に登場する「もの・こと」。例：顧客、注文、製品、図面、担当者
2. 別名（表記ゆれ）：同じ概念を指す別の呼び方。例：顧客＝得意先＝クライアント。同じものを指す別表記を1つにまとめる作業は「名寄せ」と呼ばれます
3. 関係：「主語 — 関係 — 目的語」の形で書ける事実の型。例：顧客 — 発注する — 注文

この段階の成果物はExcelや表で十分です。重要なのは、現場の人が実際に使っている言葉を採用することです。システムのカラム名ではなく現場の言葉で定義するからこそ、現場の言葉で質問できるAIになります。

なお、洗い出しの対象になる図面・帳票類がそもそもAIで扱える形になっていない場合は、先にデータの構造化が必要です。図面や帳票をAIが使える形に変える手法についてはこちらもご参考ください。

2-2. 定義ファイルに落とす

洗い出した内容を、機械が読める定義ファイルにします。学術分野にはOWL（Web Ontology Language：オントロジーを厳密に記述するための国際標準）もありますが、社内利用の最小構成なら、まずはYAML（字下げで階層を表す、読み書きしやすい記述形式）で十分です。

# オントロジー定義の最小例（受注業務）
concepts:                            # 業務に登場する概念の一覧
  - name: 顧客                       # 概念の正式名称
    aliases: [得意先, クライアント]   # 同じ概念を指す別表記（名寄せに使う）
  - name: 注文                       # 2つ目以降の概念も同じ構造で並べる
    aliases: [受注, オーダー]         # 別表記は現場で使われているものをすべて登録する
  - name: 製品                       # 概念は最初は5〜10個で始める
    aliases: [品番, アイテム]         # 別表記が無い場合は空リストでよい
relations:                           # 概念どうしの関係の一覧
  - subject: 顧客                    # 関係の主語にあたる概念
    predicate: 発注する              # 関係の名前（現場の言葉で付ける）
    object: 注文                     # 関係の目的語にあたる概念
  - subject: 注文                    # 「注文は製品を含む」という関係
    predicate: 含む                  # 関係の名前は動詞形に統一すると読みやすい
    object: 製品                     # 同じ概念が複数の関係に登場してよい

この定義ファイルが、そのままチームの共通言語になります。「関係の名前は動詞形に統一する」「別名は現場ヒアリングで追加する」のような運用ルールをファイル冒頭のコメントに書いておくと、属人化を防げます。

2-3. データベースに格納する最小スキーマ

定義ができたら、実データと結びつけて格納します。以下は、PostgreSQLとpgvector（ベクトル検索用の拡張機能）を有効化した環境を前提にした、最小のテーブル構成例です。実際の導入では、扱うデータ量や既存システムに合わせて調整してください。

-- オントロジーとRAGを接続する最小テーブル構成の例
CREATE EXTENSION IF NOT EXISTS vector;         -- pgvector拡張を有効化する

CREATE TABLE entities (                        -- 概念の実体（エンティティ）を格納する
  id   SERIAL PRIMARY KEY,                     -- エンティティの識別子
  type TEXT NOT NULL,                          -- 概念の種類（顧客・注文・製品など）
  name TEXT NOT NULL                           -- 正式名称（例:「A社」）
);

CREATE TABLE aliases (                         -- 別表記を正式名称に対応付ける（名寄せ用）
  entity_id INTEGER REFERENCES entities(id),   -- 対応するエンティティ
  alias     TEXT NOT NULL                      -- 別表記（例:「エー社」「A商事」）
);

CREATE TABLE relations (                       -- エンティティどうしの関係を格納する
  subject_id INTEGER REFERENCES entities(id),  -- 主語のエンティティ
  predicate  TEXT NOT NULL,                    -- 関係の名前（例:「発注する」）
  object_id  INTEGER REFERENCES entities(id)   -- 目的語のエンティティ
);

CREATE TABLE chunks (                          -- RAG用の文書チャンクを格納する
  id        SERIAL PRIMARY KEY,                -- チャンクの識別子
  content   TEXT NOT NULL,                     -- チャンクの本文
  embedding VECTOR(1536)                       -- 次元数は使用する埋め込みモデルに合わせる
);

CREATE TABLE evidence_links (                  -- エンティティとチャンクの対応付け
  entity_id INTEGER REFERENCES entities(id),   -- チャンク内で言及されているエンティティ
  chunk_id  INTEGER REFERENCES chunks(id)      -- 言及元のチャンク
);

テーブルができたら、2-2で定義した概念と関係に従って実データを入れます。「A社」を顧客として登録し、別表記を結びつけ、注文との関係をつなぐまでが次の例です。

-- 定義に従って実データを登録する例（idは自動で採番される）
INSERT INTO entities (type, name) VALUES
  ('顧客', 'A社'),                             -- 「顧客」の実体としてA社を登録（id=1になる）
  ('注文', '注文#1234');                       -- 「注文」の実体を登録（id=2になる）

INSERT INTO aliases (entity_id, alias) VALUES
  (1, 'エー社'),                               -- A社の別表記。現場で使われる呼び方を登録する
  (1, 'A商事');                                -- 別表記は必要なだけ追加できる

INSERT INTO relations (subject_id, predicate, object_id) VALUES
  (1, '発注する', 2);                          -- 「A社 → 発注する → 注文#1234」の関係を登録

ここまで入れておくと、「エー社の注文は？」と質問されても、aliases から正式名称のA社を特定し、relations をたどって注文#1234に到達できます。定義（2-2）と実データ（ここ）が対応した状態が、オントロジーを業務データに適用した姿です。

構成のポイントは2つあります。ひとつは、aliases テーブルを最初から用意することです。表記ゆれの吸収はオントロジーの効果が最も分かりやすく出る部分で、後付けにすると名寄せのやり直しが発生します。もうひとつは evidence_links です。エンティティとチャンクを対応付けておくことで、このエンティティに関する文書だけに検索を絞れます。あわせて、回答の根拠になった文書も提示できます。

2-4. RAGと組み合わせる

格納したオントロジーをRAGの検索フローに組み込みます。設計の基本形は次の流れです。

1. エンティティ解決：質問文に含まれる語を aliases で正式名称に変換する（「得意先Aの受注」→ エンティティ「A社」「注文」）
2. 関係の展開：relations をたどり、質問に関連するエンティティを広げる（「A社」→ 発注する → A社の注文群）
3. 検索範囲の絞り込み：evidence_links で、関連エンティティに紐づくチャンクに検索対象を絞る
4. 回答生成：絞り込んだチャンクをコンテキスト（LLMに渡す参考情報）としてLLMに渡し、回答を生成する

従来RAGとの違いは、ベクトル検索の前段に意味の処理（1〜3）が入ることです。検索対象が文書全体ではなく、質問と関係があると定義上いえる範囲に絞られるため、無関係なチャンクの混入が減ります。OG-RAGが示した精度向上は、この「検索対象を概念的に裏付ける」効果によるものです。

LLMに渡すコンテキストをどう設計するかは、オントロジーの有無にかかわらずRAGの品質を左右します。コンテキストエンジニアリングの実践についてはこちらもご参考ください。

3. 応用・発展：LLMによる構築支援とAIエージェントへの展開

3-1. オントロジー構築はLLMに手伝わせる

ここまで読んで、「定義の洗い出しを人手でやるのは大変そうだ」と感じた方も多いはずです。実際、オントロジー整備の負担は長年この分野の課題でした。しかし状況は変わりつつあります。ナレッジグラフ構築には、オントロジー設計、知識抽出（文書からの取り出し）、知識融合（重複や表記ゆれの統合）の3工程があります。2025年のサーベイ論文（ある分野の研究を広く調査して動向を整理した論文）では、このいずれもがルールベースの手法からLLMを使う生成的な手法へ移行していると整理されています。

同サーベイは、構築のアプローチを2つに分類しています。

アプローチ	特徴	向いている場面
スキーマあり（schema-based）	事前に設計した定義に従って抽出する。構造・一貫性を重視	定義が固まっている基幹業務
スキーマなし（schema-free）	LLMに構造ごと発見させる。柔軟性・網羅性を重視	定義がまだ無い領域の探索

実務では、この2つを段階として使う方法が現実的です。まずスキーマなしでLLMに業務文書から概念と関係の草案を作らせ、人間がレビューして正式な定義に整え、以降はスキーマありで抽出を回します。草案づくりをAIに任せ、確定を人間が担うように分担すると、ゼロから人手で定義するより着手の負担を大きく下げられます。

3-2. AIエージェントの世界モデルとしてのオントロジー

オントロジーの用途はRAGの精度向上にとどまりません。もうひとつの重要な文脈が、AIエージェント（自律的にツールを操作してタスクを進めるAI）です。

エージェントに業務を任せるには、業務に何が存在し、どの操作が許されるかをエージェント自身が参照できる必要があります。オントロジーは、ここで3つの役割を果たします。ひとつは、業務にどんな概念が存在するかをエージェントに示す世界モデル（エージェントが前提とする業務の全体像）としての役割です。次に、どの概念にどの操作をしてよいかという行動範囲と権限を定める役割があります。そしてもうひとつが、人間とAIが同じ言葉で業務を扱うための共通言語としての役割です。

具体例で考えます。「注文をキャンセルして」と指示されたエージェントは、オントロジーがあれば「注文」が何を指すか、キャンセルによって「製品」「請求」との関係がどう変わるか、そして自分にその操作権限があるかを、定義に基づいて判断できます。定義がなければ、エージェントは文書の記述から都度推測することになり、挙動が安定しません。エージェントの活用が広がるほど、オントロジーは、精度向上の手段にとどまらず、安全に任せるための前提に近づいていきます。

3-3. 導入時の注意点

効果とあわせて、制約も押さえておきます。

1. 適用領域を選ぶ：OG-RAGの論文自体が、効果を発揮するのは事実に基づく推論が中心で、業務のルールや手順が定義できる領域だと明記しています。定義が困難な非定型業務にまで最初から広げないことが重要です。
2. 維持の仕組みを決めてから始める：業務が変われば概念も関係も変わります。定義ファイルのオーナー（更新責任者）と見直しのタイミングを決めずに作ると、実態とずれた定義が残り続けます。
3. 名寄せは継続的な運用になる：別名は導入後も現場から見つかり続けます。「気づいた人が aliases に追加を依頼する」のような軽い運用ルートを用意しておくと、定義が現場の言葉に追随できます。

4. まとめと結論

本記事の要点をまとめます。

• オントロジーとは、業務の概念と関係を機械が扱える形で定義したものです。データそのものではなく、データの意味を定めるルールにあたります。
• 従来RAGの弱点（表記ゆれ・関係をたどれない・全体横断の質問）に構造から効きます。 Microsoftの研究では、オントロジーで検索を裏付けることで事実の再現率が55%向上・回答の正しさが40%改善し、ナレッジグラフを使う手法では全体を横断する質問にも答えられるようになったと報告されています。
• 最小構成は「概念5〜10個＋別名＋関係」から始められます。 YAMLの定義ファイルと、実体・別表記・関係・文書・対応付けの5つのテーブルで、既存のRAGに意味の前処理を追加できます。
• 構築はLLMに草案を作らせ、人間が確定する分担が現実的です。 さらにAIエージェント時代には、オントロジーは業務の全体像・してよい操作の範囲・人間とAIの共通言語という3つの役割も担います。

参照情報の時点: 本記事で引用した論文・記事は2026年7月13日時点で参照した内容に基づきます。研究動向は更新されるため、最新の情報は記事末尾の参考文献をご確認ください。

最後に

私たちは、単にシステムを組むだけの開発会社ではありません。低コストで高品質なAIツールの構築から、ROI（投資対効果）を最大化する導入ロードマップの策定、社内スタッフが自らAIを運用・改善できる体制の構築まで、AI導入の成功に必要なすべてを最初から最後まで丸ごと支援いたします。

実は、ご相談いただく方のほとんどが「何が分からないかも分からない」という状態からのスタートです。構想段階でも、ただのアイデアベースでも構いません。
まずは、あなたのお困りごとをそのまま聞かせていただけませんか？貴社のビジネスを加速させるパートナーとして伴走いたします。

参考文献

1. Kartik Sharma, Peeyush Kumar, Yunqing Li（Microsoft）「OG-RAG: Ontology-Grounded Retrieval-Augmented Generation For Large Language Models」（2026年7月13日参照）
2. Darren Edge ほか（Microsoft Research）「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」（2026年7月13日参照）
3. Haonan Bian「LLM-empowered Knowledge Graph Construction: A Survey」（2026年7月13日参照）
4. Thomas R. Gruber「A Translation Approach to Portable Ontology Specifications」（2026年7月13日参照）
5. 山口夏生・Komlock lab（Zenn）「オントロジーとは何か」（2026年7月13日参照）