オントロジー設計の実務 — LLM・RAGの精度を決める知識構造の作り方

「RAGを導入したが、期待した答えが返ってこない。」この相談を受けて原因を調べると、検索アルゴリズムやモデルの問題ではなく、検索対象となる知識そのものが構造化されていないことに行き着くケースが大半です。本稿では、その解決手段であるオントロジー設計を、実務で使える粒度で解説します。

1. オントロジーとは何か

オントロジーとは、対象領域に登場する概念と、概念間の関係・制約を明示的に定義した仕様のことです。もともとは哲学の用語ですが、情報科学では「知識の共有と再利用のための、概念化の明示的な仕様」として使われます。

抽象的に聞こえますが、中身は具体的です。たとえば製造業なら、次のような取り決めの集合がオントロジーです。

• 概念の定義: 「製品」「部品」「工程」「設備」「不具合」をそれぞれ何と定義するか
• 同義語の統制: 「品番」「型番」「部品番号」は同じものを指すのか、別物か
• 関係の定義: 製品は部品から「構成される」、工程は設備を「使用する」
• 制約の定義: 1つの不具合報告は必ず1つの工程に紐づく、など

ポイントは「暗黙の了解を明文化する」ことです。ベテランの頭の中では繋がっている知識を、機械が辿れる形に書き下ろします。

2. なぜ今、LLMの文脈でオントロジーなのか

RAG（検索拡張生成）は、質問に関連する文書を検索し、それを根拠にLLMが回答する仕組みです。この構成では、検索で正しい文書を取れなければ、その先の生成がどれだけ賢くても正しい答えは出ません。

そして検索を狂わせる主要因が、知識の非構造化です。当社がオントロジー構築支援で繰り返し目にする典型は次の3つです。

2.1 用語の不統一

同じ対象が「客先」「得意先」「取引先」と文書ごとに違う名前で書かれている。埋め込みベクトルは意味の近さをある程度は吸収しますが、社内固有の略語や型番の表記ゆれまでは吸収できません。質問者が「得意先」と聞き、文書が「客先」と書いていれば、検索スコアはそのぶん下がります。

2.2 概念間の関係が未定義

「この製品のこの不具合は、どの工程で発生したか」という質問に答えるには、製品→部品→工程→不具合という関係の連鎖を辿る必要があります。文書の中に関係が明示されていなければ、ベクトル検索は「近い文書」を返すだけで、関係を辿った回答はできません。

2.3 部門ごとのサイロで意味が分岐

営業の「納期」と製造の「納期」が別の日付を指している、といった意味の分岐は、部門をまたぐ質問で誤答の温床になります。どちらが悪いのではなく、定義が擦り合っていないことが問題です。

この3つはいずれも、検索アルゴリズムの改善では解決しません。知識の側を直す必要があり、その方法論がオントロジー設計です。

3. オントロジー設計の5ステップ

Step 1: スコープを1業務に絞る

最初の分岐点です。全社の用語辞書を最初から作ろうとするプロジェクトは、ほぼ確実に途中で止まります。まず「設備保全の問い合わせ対応」「契約書の条項検索」のように、質問と答えの形が想像できる1業務に絞ります。効果が確認できてから隣の業務に広げるほうが、結果的に速く進みます。

Step 2: 用語の棚卸しと統制

対象業務の文書（マニュアル・報告書・台帳）から名詞を洗い出し、同義語・略語・表記ゆれを正式名称に紐付けます。ここで作る同義語辞書は、オントロジーの中で最も費用対効果が高い成果物です。検索クエリの言い換え展開に使うだけでも、検索漏れが目に見えて減ります。

Step 3: 概念階層の定義

統制した用語を「AはBの一種である（is-a）」「AはBの一部である（part-of）」で整理します。「NC旋盤は工作機械の一種」「主軸はNC旋盤の一部」という階層があると、「工作機械の不具合事例」という質問でNC旋盤の事例も返せるようになります。

Step 4: 関係と制約の定義

階層以外の関係（工程は設備を使用する、不具合は工程で発生する）と、成り立つべき制約（不具合報告には発生工程が必須）を定義します。ここまで来ると、知識は「文書の集まり」から「辿れるネットワーク」に変わります。

Step 5: 検証と運用プロセスの設計

実際の質問集で検索精度を測り、漏れの原因（辞書の不足か、関係の欠落か、チャンク分割の問題か）を切り分けて改修します。あわせて、新しい用語・製品が生まれたときに誰がオントロジーを更新するかを決めます。更新プロセスのないオントロジーは、作った瞬間から陳腐化が始まります。

4. ナレッジグラフへの実装

設計したオントロジーは、Neo4jなどのグラフデータベースにナレッジグラフとして実装します。実務では、ベクトル検索とグラフ探索を組み合わせたハイブリッド構成が有効です。ベクトル検索で入口となる概念を見つけ、そこからグラフの関係を辿って関連知識を集め、LLMに渡す。この構成なら「関係を辿らないと答えられない質問」にも対応できます。

なお、検索対象の文書をどう分割するか（チャンキング）も検索精度の上限を決める要素です。分割戦略ごとの実測比較はテキストチャンキング技術の比較研究にまとめています。オントロジーが「言葉と関係」の問題を解き、チャンキングが「文書の切り方」の問題を解く、という分担です。

5. よくある失敗パターン

• 最初から全社を対象にする — 部門間の定義調整が終わらず、成果が出る前に力尽きます。1業務で効果を示してから広げます。
• IT部門だけで作る — 用語の意味を決められるのは業務の当事者だけです。現場へのヒアリングなしに作った辞書は、現場の言葉と一致しません。
• 更新プロセスを決めない — 新製品・新用語は次々に生まれます。更新の責任者と手順を決めていないオントロジーは、半年で実態と乖離します。
• ツール選定から入る — グラフDBやオントロジーエディタは手段です。先に「どの質問に答えられるようになりたいか」を決めないと、ツールだけが残ります。

6. まとめ

RAGの精度問題の多くは、モデルではなく知識の構造に原因があります。オントロジー設計は、①スコープを絞り、②用語を統制し、③階層と④関係・制約を定義し、⑤検証と更新プロセスを回す、という手順で進めます。最初の一歩は対象業務1つの用語棚卸しです。そこだけでも検索品質は変わります。