背景・目的
生成AI（LLM）を業務で使うと、すぐに「それっぽいが根拠のない答え」にぶつかります。モデルは学習時点の知識しか持たず、社内のデータや最新の事実を知りません。ここを埋める技術として、メタデータ・オントロジー・ナレッジグラフ・コンテキスト（コンテキストエンジニアリング）といった言葉をよく見かけるようになりました。これらは大きく2種類に分かれます。データに意味と根拠を与える技術（メタデータ・オントロジー・ナレッジグラフ）と、用意した知識を限られた入力にうまく渡す技術（コンテキストエンジニアリング）です。
ただ、これらは層が違う話を一緒くたに語られがちで、関係が分かりにくいのが実情です。メタデータとオントロジーはどう違うのか、ナレッジグラフとRAGはどこでつながるのか、コンテキストエンジニアリングは何を指すのか。本記事ではそれぞれの正体と役割を区別し、全体のイメージをもつことを目的にします。
個別の深掘り（オントロジー／ナレッジグラフ、コンテキストエンジニアリング）は別記事に分けます。
この記事は筆者が手を動かした検証レポートではなく、公式仕様・一次情報をもとにした概念整理です。掲載するコード例は公式ドキュメントに基づくものであり、筆者環境での実行結果ではありません。
まとめ
| 項目 | 内容 |
|---|---|
| これは何 | AIに「意味」と「根拠」を与えるデータ側の技術（メタデータ → タクソノミー → オントロジー → ナレッジグラフ）と、それをLLMにつなぐ仕組み（ベクトル検索・RAG・GraphRAG・コンテキストエンジニアリング・MCP）の全体地図 |
| 何ができる | ①各概念の違いを区別できる ②なぜLLMにこれらが不可欠かを説明できる ③支える標準技術（RDF/OWL/SPARQL・埋め込み・RAG・MCP）の役割が分かる |
| 全体の構図 | 「データに意味を持たせる層」と「意味を持ったデータをLLMに渡す層」の2段で捉えると整理しやすい |
| 押さえどころ | LLMは確率で言葉を続ける仕組みで、外から意味と根拠を与えないと事実性が担保されない。メタデータ系技術はその根拠を構造として用意する |
| 注意 | 「コンテキスト」「ベクトル」「グラフ」は分野ごとに別の意味で使われる語。本文で都度区別する |
概要
全体像（2層の地図）
この記事で扱う技術は、大きく2つの層に分かれます。データに意味と根拠を持たせる「データ側」と、それをLLMに渡す「つなぐ側」です。まずこの地図を押さえると、各技術がどこに位置し、どうつながるかが一目で分かります。
各技術を同じ軸（層・役割・他との違い）で並べると、違いがはっきりします。
| 層 | 技術 | 役割 | 具体例 | 他との最大の違い |
|---|---|---|---|---|
| データ側 | メタデータ | データに説明を付ける | 列「cst_cd」＝顧客コード | 関係は持たず説明を足すだけ |
| データ側 | タクソノミー | is-a階層で分類する | 犬 is-a 哺乳類 | 上下関係だけ。横の関係を持てない |
| データ側 | オントロジー | 型・ルール（スキーマ）を定義 | 著者は書籍を執筆する | 任意の関係を定義。実データは持たない |
| データ側 | ナレッジグラフ | 型に沿った実データを結ぶ | 著者A→執筆した→書籍1 | オントロジーの実データ版（中身を持つ） |
| つなぐ側 | 埋め込み／ベクトル検索 | 意味の近い文書を探す | 問いに近い文書を取得 | 意味の近さで引く。関係はたどれない |
| つなぐ側 | RAG | 検索結果を入力に添えて答えさせる | 検索＋生成 | 外部知識を都度与える枠組み |
| つなぐ側 | GraphRAG | グラフの関係をたどって検索・要約 | 横断的な要約 | ベクトルでなく関係をたどる |
| つなぐ側 | コンテキストエンジニアリング | 入力に何を入れ何を捨てるか設計 | 履歴の圧縮・取捨 | 「渡し方」の設計。データ自体は作らない |
| つなぐ側 | MCP | 外部データ・ツールへの標準接続 | ツール連携仕様 | 接続の標準化。意味付けはしない |
オントロジーとナレッジグラフは同じ「データ側」でも、前者が型の定義、後者がその型で結んだ実データという違いがあります。コンテキストエンジニアリングは「データ側」ではなく「つなぐ側」に位置し、意味を作るのではなく渡し方を設計する点で、他と軸が異なります。
用語の整理
本文で繰り返し出る語を先に整理します。
- メタデータ: データについてのデータ。ファイル名・作成日・列の意味・タグなど、本体データを説明する情報
- タクソノミー: 用語を「上位・下位」の親子関係（is-a）だけで整理した分類体系。たとえば「犬 は 哺乳類 の一種」のように、1本の木（分類ツリー）で表せる範囲を扱う
- オントロジー: 概念どうしの関係を機械可読な形で形式的に定義した「型・ルール（スキーマ）」。上下関係（is-a）に加えて「執筆する」「所属する」など任意の関係も扱える。is-aだけを扱うタクソノミーを特別な場合として含み、それを関係の面で広げたものと言える
- ナレッジグラフ: オントロジーで定義した型に沿って、実世界の「もの（エンティティ）」とその関係をノードとエッジで結んだ実データ。オントロジーが「型・ルールの定義」なのに対し、こちらはその定義で結んだ実データにあたる（データベースのスキーマ定義と行データ、プログラミングのクラス定義とインスタンスの関係に近い）
- 埋め込み（embedding）: テキストなどを意味の近さが距離に表れる数値ベクトルに変換したもの
- RAG: 検索で外部知識を引いてきて、その結果をLLMの入力に添えて回答させる手法
- コンテキスト: ここではLLMが1回の推論で受け取る入力全体（コンテキストウィンドウの中身）を指す。日常語の「文脈」や、オントロジーの文脈（context）とは別の意味で使う
補足として、同じ名前で別物を指す語に注意します。「ベクトル」は後述の埋め込み（意味の数値表現）を指し、データベースの実行最適化で言う「ベクトル化（列をまとめて処理する手法）」とは無関係です。「グラフ」はここでは知識を表すナレッジグラフのことで、計算資源のGPUやグラフ理論一般とは別の文脈です。
なぜLLMに意味と根拠が要るのか
LLMは、与えられた文脈に続く言葉を確率的に選ぶ仕組みです。学習した範囲の外や、曖昧な問いに対しては、もっともらしい誤り（ハルシネーション）を出します。これを抑えるには、モデルの外から「正しい事実」と「その出どころ」を与える必要があります。RAGはこの考え方を最初に体系化した研究のひとつで、学習済みモデル（パラメトリックな記憶）と外部の検索インデックス（非パラメトリックな記憶）を組み合わせる方式として提案されました。
We explore a general-purpose fine-tuning recipe for retrieval-augmented generation (RAG) — models which combine pre-trained parametric and non-parametric memory for language generation.
（訳）検索拡張生成（RAG）の汎用的なファインチューニング手法を探究する。これは、学習済みのパラメトリックな記憶と非パラメトリックな記憶を組み合わせて言語生成を行うモデルである。
メタデータ・オントロジー・ナレッジグラフは、この「外から与える事実」を、検索しやすく・意味がつながった形で用意するための技術と位置づけられます。
概念の階層（メタデータからナレッジグラフまで）
4つの概念は、単純なものから意味の濃いものへと積み上がる関係にあります。
| 概念 | 何を足すか | 例 |
|---|---|---|
| メタデータ | データに説明を付ける | 列「cst_cd」に「顧客コード」という説明を付ける |
| タクソノミー | 用語を階層で分類する | 「犬 is-a 哺乳類」のような上下関係 |
| オントロジー | 階層以外の関係も形式的に定義する | 「著者 は 書籍 を 執筆する」「書籍 は シリーズ に 属する」 |
| ナレッジグラフ | 定義に沿って実データを関係で結ぶ | 「著者A → 執筆した → 書籍1 → 属する → シリーズS」 |
タクソノミーが「分類ツリー」なのに対し、オントロジーは「執筆する」「所属する」など任意の関係を扱える点が違います。ナレッジグラフは、そのオントロジーをスキーマ（型の定義）として使い、実世界のエンティティどうしを結んだ実データにあたります。Googleが2012年に検索へ導入した Knowledge Graph は、この考え方を一般に広めた代表例です。
we’ve been working on an intelligent model—in geek-speak, a “graph”—that understands real-world entities and their relationships to one another: things, not strings.
（訳）私たちは、実世界のエンティティとそれらの相互関係を理解する知的なモデル、専門用語で言う「グラフ」に取り組んできた。文字列ではなく、ものを扱うという発想である。
https://blog.google/products/search/introducing-knowledge-graph-things-not
支える標準技術（RDF・OWL・SPARQL）
ナレッジグラフやオントロジーを機械可読にするための代表的な標準が、W3CのSemantic Web系仕様です。とくに形式的なオントロジー記述はW3CのOWLが中心になります（グラフの持ち方にはRDF系のほかにプロパティグラフ系もあり、そちらはCypherやGQL〈2024年のISO標準〉を使います。詳細は次記事で扱います）。次の3つで役割が分かれています。
- RDF: 情報を「主語 - 述語 - 目的語」の3つ組（トリプル）で表すデータモデル。関係に名前の付いたグラフになる
- OWL: RDFの上で、クラス・プロパティ・個体などを形式的な意味付きで定義するオントロジー記述言語
- SPARQL: RDFグラフに対する問い合わせ言語。関係をたどる検索を書ける
RDFはWebのリンク構造を拡張し、関係そのものに名前（URI）を与えてデータを共有できるようにします。
RDF extends the linking structure of the Web to use URIs to name the relationship between things as well as the two ends of the link (this is usually referred to as a "triple").
（訳）RDFはWebのリンク構造を拡張し、リンクの両端だけでなく、もの同士の関係にもURIで名前を付ける（これは通常「トリプル」と呼ばれる）。
OWLは、Semantic Web向けに形式的な意味を持つオントロジー言語として定義されています。
OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents.
（訳）OWL 2のオントロジーはクラス・プロパティ・個体・データ値を提供し、Semantic Webの文書として保存される。
SPARQLはRDFに対する問い合わせ言語で、異なるデータソースをまたいだ検索を表現できます。
SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware.
（訳）SPARQLは、データがRDFとしてそのまま保存されていても、ミドルウェア経由でRDFとして見えていても、多様なデータソースをまたぐ問い合わせを表現できる。
これら3つの関係は「RDF＝データの形」「OWL＝意味の定義」「SPARQL＝問い合わせ方法」と対応づけると整理できます。
意味を持ったデータをLLMにつなぐ（RAG・GraphRAG・コンテキストエンジニアリング・MCP）
データ側に意味と根拠を用意できても、それをLLMに届けなければ答えは変わりません。つなぐ側の技術が次の層です。
- 埋め込み＋ベクトル検索: 問いと文書を数値ベクトルにして、意味が近い文書を探す。RAGの標準的な検索手段
- RAG: ベクトル検索などで引いた文書をLLMの入力に添えて答えさせる。多くのLLMツールの基盤
- GraphRAG: ベクトル類似だけでなく、ナレッジグラフの関係をたどって検索・要約する拡張。分散した情報を横断する問いに強い
- コンテキストエンジニアリング: 限られたコンテキストウィンドウに、何を・どの形で入れるかを設計する考え方
- MCP: LLMアプリと外部のデータ・ツールを標準化された方法でつなぐオープン仕様
GraphRAGは、通常のRAGがベクトル類似に頼るのに対し、グラフとLLMを組み合わせる点を特徴とします。
GraphRAG (Graphs + Retrieval Augmented Generation) is a technique for richly understanding text datasets by combining text extraction, network analysis, and LLM prompting and summarization into a single end-to-end system.
（訳）GraphRAG（グラフ＋検索拡張生成）は、テキスト抽出・ネットワーク分析・LLMへのプロンプトと要約を1つのエンドツーエンドのシステムに統合して、テキストデータ集合を豊かに理解する手法である。
MCPは、データソースとAIツールの間に安全な双方向接続を作るためのオープン標準として導入されました。
The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.
（訳）Model Context Protocolは、データソースとAI搭載ツールの間に、安全で双方向の接続を構築できるオープン標準である。
コンテキストエンジニアリングは、プロンプトエンジニアリングの自然な発展と位置づけられています。詳細は別記事で扱います。
At Anthropic, we view context engineering as the natural progression of prompt engineering.
（訳）Anthropicでは、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展と捉えている。
https://www.anthropic.com/research/effective-context-engineering-for-ai-agents
実例（公式ドキュメントに基づく例）
ここで示すコードは、各仕様が定める記法（構文）に沿って筆者が作成した説明用の例で、筆者環境での実行結果でも、仕様書に載っている例でもありません。概念の形を具体的に掴むための最小例です。各項に、準拠した記法の定義元を示します。
- RDFのトリプル（主語 - 述語 - 目的語）を1行で書くと、関係に名前が付いたグラフの最小単位になります。下記はTurtle記法で書いた例です（構文の定義元: W3C RDF 1.1 Turtle。この例自体は仕様書中の例ではなく、筆者が作成したものです）。
:著者A :執筆した :書籍1 .
:書籍1 :属する :シリーズS .
- 上のグラフに対し、SPARQLで「書籍1を執筆した著者」を問い合わせる形は次のようになります（関係をたどる検索を書ける点がSQLとの違いです）。構文の定義元は W3C SPARQL 1.1 Query で、この例は筆者が作成したものです。
SELECT ?author
WHERE { ?author :執筆した :書籍1 . }
- RAGの流れは、おおまかに「問い → 検索 → 文脈として添付 → 生成」の順です。擬似的に書くと下記のようになります（RAGの考え方の出典: RAG論文 Lewis et al., 2020。下記は流れを示す擬似コードで、論文中のコードではありません）。
query = "書籍1の著者は？"
docs = vector_search(query) # 意味が近い文書を検索
prompt = docs + query # 検索結果を入力に添える
answer = llm(prompt) # 根拠付きで生成
実運用では、2と3のどちらで引くか（グラフをたどるか、ベクトルで引くか）が設計上の分かれ目になります。関係を横断する問いはグラフ側、文章の意味的な近さで足りる問いはベクトル側が向きます。
考察
- メタデータ系技術は「データに意味を持たせる層」、RAG/MCP系は「意味を持ったデータをLLMに渡す層」と2段で捉えると、各技術の居場所が整理できます
- オントロジー／ナレッジグラフは根拠の構造化に強く、RAG/コンテキストエンジニアリングは渡し方の設計に効きます。どちらか一方ではなく、両輪で噛み合わせる対象です
- ベクトル検索は手軽で広く使われますが、分散した事実を横断する問いには弱く、そこをGraphRAGが補う構図になっています
- 「コンテキスト」「ベクトル」「グラフ」は分野で意味が異なる語なので、チーム内の会話では毎回どの意味かを揃えておくと誤解を防げます
- 次のステップとして、オントロジー／ナレッジグラフの深掘り（RDF/OWL/SPARQLの具体）と、コンテキストエンジニアリングの深掘り（コンテキストウィンドウの設計）を別記事で扱います
参考
https://arxiv.org/abs/2005.11401
https://www.w3.org/RDF/
https://www.w3.org/TR/turtle/
https://www.w3.org/TR/owl2-overview/
https://www.w3.org/TR/sparql11-query/
https://blog.google/products/search/introducing-knowledge-graph-things-not
https://microsoft.com/en-us/research/project/graphrag
https://arxiv.org/abs/2404.16130
https://www.anthropic.com/research/model-context-protocol
https://modelcontextprotocol.io/
https://www.anthropic.com/research/effective-context-engineering-for-ai-agents