資料を足してもAIが賢くならない理由：オントロジーという考え方【2026年版】
この記事の概要
資料を足したのに、AIの答えの質が上がらない。
同じ質問をしたのに、先週と今週で違う答えが返ってくる。
この2つは、モデルの気分の問題ではありません。
渡している資料が、対象どうしの関係を書いていないことから来ています。
本記事は全4回シリーズの第1回として、その関係を明示する道具であるオントロジーを扱います。
シリーズを通した用語はこの回で固定します。
なお本記事のうち、一次資料で確認できた記述には脚注で出典を付けました。
出典のない整理は、かなうテック（屋号：Kanau Tech™）が実務で使っている見方であり、公式に定義された方法論ではありません。
Part 1. 資料を足しても答えが安定しないとき、何が起きているか
AIに社内の知識を渡す方法は、いくつかあります。
会話の中でファイルを直接指定する。
プロジェクトの指示書に追記する。
参照用のディレクトリを整える。
どれも効果があります。
ただし共通の限界があります。
これらはすべて、対象を置く、名前を付ける、分類する、という操作です。
対象と対象の関係を書き足す操作ではありません。
具体的に考えます。
注文を扱う仕組みの仕様書と、決済を扱う仕組みの仕様書が、それぞれ丁寧に書かれているとします。
それでも「注文の仕組みが決済の仕組みを呼び出している」という一文は、どちらにも書かれていないことがあります。
人間どうしなら、その場にいる誰かが知っているので問題になりません。
書く必要がないほど当たり前だからです。
しかしAIは、書かれていない部分をその場で推測して埋めます。
推測はだいたい当たります。
ただし、毎回まったく同じにはなりません。
同じ質問への答えが日によって変わる現象は、ここから来ています。
星が並んでいても、星と星を結ぶ線が引かれていなければ、どの星座なのかは読む人が毎回決め直すことになります。
線にあたるものが、これから扱うオントロジーです。
Part 2. オントロジーの5つの構成要素
オントロジー（ontology）はもともと哲学の用語で、存在論と訳されます。
情報科学では、Tom Gruber による定義が広く使われています。
その定義によれば、オントロジーとは、ある知識領域をモデル化するための表現の基本要素を定めたものです1。
基本要素は通常、クラス、属性、関係の3つになります。
そして基本要素の定義には、それぞれの意味と、論理的に矛盾なく使うための制約が含まれます1。
この最後の制約という部分は、後で効いてきます。
実務で使う形に開くと、部品は5つになります。
- クラス：概念の型。「サービス」という種類そのもの
- 個体：クラスの具体例。注文サービス、決済サービス
- プロパティ：要素が持つ属性。決済サービスは外部の決済事業者に依存する
- 関係：要素どうしのつながり。注文サービスは決済サービスを呼び出す
- 制約：成り立つ条件。サービスどうしがデータベースを直接共有しない
クラス、個体、プロパティという語の並びは、オントロジーを厳密に記述するための言語であるOWL 2でも同じ形で使われています2。
この5つのうち、他の整理手法に欠けているのは関係だけです。
クラスやプロパティは、データベースの設計書にも普通のドキュメントにも書いてあります。
フォルダ分けやタグ付けでも、ある程度は表現できます。
しかし関係は、たいていどこにも書かれていません。
書かれていないから読む側が毎回推測し、そのぶれが答えのぶれになります。
Part 3. 関係に型を付ける
オントロジーの関係は、ただ線を引くのではなく、線に名前が付きます。
実務でよく使う型は、次のようなものです。
- is-a：〜の一種である（普通預金 is-a 預金口座）
- part-of：〜の一部である（エンジン part-of 自動車）
- calls：〜を呼び出す（注文サービス calls 決済サービス）
- depends-on：〜に依存する（決済サービス depends-on 外部決済事業者）
- derived-from：〜から導かれる（課税所得 derived-from 所得金額）
型が付くと、関係をたどれるようになります。
「注文サービスが呼び出すものは何か」という問いに、推測なしで答えが出ます。
さらに「注文サービスが最終的に依存している外部の相手は何か」という2段階の問いにも、線を2本たどるだけで答えが出ます。
この2段階目に注目してください。
「注文サービスは決済サービスを呼ぶ」と「決済サービスは外部決済事業者に依存する」の2本があれば、「注文サービスは外部決済事業者に依存する」が導けます。
この結論は、どの資料にも書かれていません。
線を2本たどった結果としてだけ存在します。
これを多段推論（マルチホップ推論）と呼びます。
文書をどれだけ丁寧に書いても、自動では出てこない種類の答えです。
この節の型の一覧と分類は、かなうテックが実務で使っている整理であり、公式に決められた語彙ではありません。
どの型を使うかは、扱う業務によって決め直すことになります。
Part 4. タグでもタクソノミーでもない
関係を持てるかどうかで、整理手法は3つに分かれます。
| 整理方法 | 構造 | 関係の表現 | AIから見たときの扱い |
|---|---|---|---|
| タグ、フォルダ | ラベルと一軸の階層 | 持たない | 関係はモデルが推測するしかない |
| タクソノミー | 親子の階層 | 上位と下位のみ | 縦はたどれるが横の関係は推測 |
| オントロジー | 多軸のネットワーク | is-a、calls、depends-on などを型で明示 | 書かれた関係を推測せずたどれる |
フォルダには構造上の弱点があります。
1つのファイルは1つの場所にしか置けません。
決済サービスの仕様書を決済フォルダに置くか外部連携フォルダに置くかで、どちらかを諦めることになります。
タグは複数貼れます。
しかし「受注」と「決済」の2つを並べても、その2つがどういう関係なのかは表現できません。
タクソノミーは生物分類のような親子の階層です。
縦方向はたどれますが、「注文サービスは決済サービスを呼ぶ」という横の関係を持てません。
オントロジーとその他の手法を分ける点は1つです。
関係をモデルに推測させるか、あらかじめ確定させておくか。
Part 5. 関係を明示すると何が変わるか
ここから先は、かなうテックが実務で使っている見方であり、公式の仕様ではありません。
理由は4つに整理できます。
推測の余地が減る
資料に書かれていない部分は、必ず推測で埋められます。
関係を明示すると、その部分の推測が消えます。
消えた分だけ、答えが安定します。
選べる関係が有限になる
関係を「あらかじめ決めた型から選ぶ」形にすると、モデルが取れる選択肢が有限になります。
自由記述であれば、もっともらしい誤りはいくらでも作れます。
型が5つに決まっていれば、作れる誤りはその範囲に限られます。
もっともらしい誤りは、自由度の高いところで起きます。
型を決める作業は、自由度を構造的に下げる作業です。
探索の回数が減る
グラフがなければ、AIは関係しそうなファイルを片端から開いて読み、関係ないと分かって次を開きます。
グラフがあれば、この探索の一部が「該当する対象とその隣を取る」操作に置き換わります。
ここで注意が要ります。
探索が減ることと、費用や時間が減ることは、同じではありません。
この差については第3回で、実際に測った数字とともに扱います。
渡す情報の密度が上がる
大量の情報を渡すほど答えがよくなるわけではありません。
関係のない情報が混ざるほど、判断はぶれます。
グラフは、関連する対象だけを選んで渡すことを可能にします。
10ファイルをまるごと渡す代わりに、5つの対象と8本の関係だけを渡す形です。
Part 6. RAGとどう使い分けるか
RAG（Retrieval-Augmented Generation）は、質問文と意味の近い文書をベクトル検索で探してモデルに渡す仕組みです。
オントロジーとは、引いてくる原理が違います。
| 問いのタイプ | RAG（ベクトル検索） | オントロジー（グラフ） |
|---|---|---|
| 単一の事実を引く | 得意 | ほどほど |
| 複数文書をまたぐ集約 | 苦手 | 得意 |
| 対象どうしの比較 | ほどほど | 得意 |
| 関係をたどる多段推論 | 苦手 | 得意 |
「就業規則の有給休暇は何日か」はRAGの独壇場です。
該当する条文を引けば終わります。
「このサービスが止まったとき、影響はどこまで及ぶか」は、RAGが最も苦手な形です。
答えが1か所に書かれておらず、散らばった依存関係を漏れなく拾う必要があります。
ベクトル検索は近い文書を上位数件返す仕組みなので、漏れがないことを保証できません。
両者は競合しません。
組み合わせる手法はGraphRAGと呼ばれ、Microsoftの研究チームが論文として公開しています3。
この論文は、コーパス全体に向けられた問い（たとえば「このデータセットの主要なテーマは何か」）に対して、従来のRAGが失敗することを出発点にしています3。
手法は2段階のインデックス構築から成ります。
まず文書からエンティティの知識グラフを導き、次に関連の強いエンティティ群ごとに要約をあらかじめ生成しておく形です3。
問いが来たら、各要約から部分的な回答を作り、それらをまとめて最終的な回答にします3。
100万トークン規模のデータセットを対象に、従来のベクトル検索型RAGと比べて、回答の包括性と多様性の両方で改善したと報告されています3。
ここは範囲を正確に読む必要があります。
改善が報告されているのは、コーパス全体を見渡す特定の種類の問いについてであり、しかも比較相手は従来型のRAGです。
「RAGより優れている」という一般化はできません。
実務での使い分けを一行で言えば、探すのはRAG、たどるのはオントロジーになります。
この言い切りは、かなうテックの整理です。
Part 7. 参考情報としてのオントロジーと、実行基盤としてのオントロジー
同じ言葉が、目的の異なる2つの文脈で使われています。
この区別が、本シリーズで最も重要な部分です。
1つは、AIに渡す参考情報としてのオントロジーです。
AIが読みに行く地図であり、強制力はありません。
期待できるのは、答えの安定と、渡す情報の絞り込みです。
もう1つは、業務システムの実行基盤としてのオントロジーです。
こちらは実行時に違反を弾きます。
企業向けのデータ基盤では、この形が製品の中核に据えられている例があります。
ベンダーの公式ドキュメントによれば、そこでのオントロジーは組織のデジタルツインとして働き、意味的な要素（オブジェクト、プロパティ、リンク）と、動的な要素（アクション、ファンクション、動的なセキュリティ）の両方を含むものだと説明されています4。
データの書き換えは、定義済みのアクションを通ります4。
「担当者が空欄なのに状態が対応中」のような中途半端な状態は、そもそも作れません。
貼り紙で土足禁止と書くのが参考情報で、靴だと開かない自動ドアが実行基盤です。
なお直前の引用元はベンダーの製品ドキュメントであり、中立の技術標準ではありません。
この区別を踏まえると、次のことが言えます。
AIの記憶にオントロジーを入れても、業務ルールの強制力は生まれません。
「オントロジーを入れればAIが業務ルールを守る」と期待すると、外れます。
強制力が要る箇所は、グラフの外側にある処理の流れで担保することになります。
区別が曖昧なまま導入すると、効果の測り方を間違えます。
なお、グラフをどこに置き、誰が運用し、どの順序で導入するかという保存と運用の設計は、別の記事で扱っています。
本シリーズは、その入れ物に入れる概念モデルをどう決めるかを扱います。
保存と運用の側はナレッジグラフをいつ持ち込むかをご覧ください。
Part 8. 中小企業の現場で言うと何にあたるか
ここまではソフトウェアの例で説明してきました。
同じ構造は、AIを使わない場面にもあります。
暗黙知が外に出る。
「この書類はいつも山田さんが先に見る」という手順が、担当者の頭の中にしかない状態は珍しくありません。
関係として書き出せば、担当者が変わっても手順が残ります。
用語のずれが見える。
営業が言う「案件」と、経理が言う「案件」が別のものを指している状況は、書き出して初めて分かります。
同じ言葉に2つの定義が付いていることが、関係を明示する作業の中で表面化します。
変更の影響範囲が見える。
「この規程を変えたら、どの手順書とどの様式に波及するか」は、関係をたどる問いです。
Part 6で見たとおり、答えが1か所にないため、文書を検索する方法では漏れが出ます。
一度作れば何度も使える。
関係の記述は、質問のたびに作り直すものではありません。
これらはAIの導入とは独立に成立する効果です。
AIに渡すかどうかを決める前でも、関係を書き出す作業自体に意味があります。
業務ドメインでの具体的な組み立て方は、本シリーズの第4回で扱います。
Part 9. このシリーズの読み方
全4回の構成です。
| 回 | 扱うもの |
|---|---|
| 第1回（本記事） | 概念。5つの構成要素、関係の型、RAGとの使い分け、参考情報と実行基盤の区別 |
| 第2回 | 学術的な基礎。RDFのトリプル、OWL、推論、書かれていないことの扱い、厳密さをどこで止めるか |
| 第3回 | Claude Codeへの実装と、自分で測った結果。効いた問いと効かなかった問い |
| 第4回 | 業務ドメインへの適用。関係の型の語彙をどう決めるか |
第3回では、実際にナレッジグラフを渡して測った数字を出します。
先に書いておくと、測った条件では総コストが下がりませんでした。
その内訳と、効いた問いと効かなかった問いの切り分けを、生の数字とともに扱います。
自社の業務のどこに用語のずれがあるか、どの規程がどこに波及するかの切り分けは、無料相談でも承っています。
関連記事
参考文献
すべての出典は2026年8月2日時点のものです。
- Tom Gruber「Ontology」Encyclopedia of Database Systems（Springer, 2009）掲載項目 — https://tomgruber.org/writing/definition-of-ontology
- W3C「OWL 2 Web Ontology Language Primer (Second Edition)」W3C勧告、2012年12月11日 — https://www.w3.org/TR/owl2-primer/
- 「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」arXiv:2404.16130 — https://arxiv.org/abs/2404.16130
- Palantir 公式ドキュメント「Ontology building」（ベンダーの製品資料） — https://www.palantir.com/docs/foundry/ontology/overview
注記：本記事のうち、一次資料に基づく記述は Part 2 のオントロジーの定義と構成要素、Part 6 の GraphRAG に関する記述、Part 7 の実行基盤の説明のみです。Part 1、Part 3、Part 4、Part 5、Part 8 は、いずれもかなうテック（屋号：Kanau Tech™）が実務で用いている整理と判断であり、公式に定義された方法論ではありません。Part 7 で引用したデジタルツインの説明は特定ベンダーの製品ドキュメントであり、中立の技術標準ではありません。本記事は特定の製品やサービスの採用を推奨するものではなく、自社の業務に合うかどうかは個別にご判断ください。