オントロジーは「先に決める」か「データから起こす」か
オントロジーで AI に業務知識を渡す — AWS の OSS「Context Ontology Accelerator」を試してみた が話題になっています。オントロジーをテーブルや文書から起こして提案を人が確認して使うという話です。
現場では部署ごとに「売上」の意味が違いエージェントが誤った数字をすぐ拡散します。原因の一つはオントロジーの作り方の違いです。実務の答えはコアを人が設計し周辺は AI に起案させることです。
同じ「オントロジー」でも作り方は大きく二つあります。
一つはデータが来る前に実体と関係の型を決めておくやり方です。この記事では明示型（事前定義）と呼びます。
もう一つはすでにあるスキーマや文書から意味の構造を起こすやり方です。この記事では推論型と呼びます。
オントロジーを自動で作成するというのは推論型を指すことが多いです。
実務では二つを混ぜることも多いです。ポイントは正しさを誰が設計するかです。
なぜ今、作り方で分けるのか
AI エージェントを業務で使うためにはモデルの性能より渡すコンテキストを調整する方が効果的な場面が増えています。Text-to-SQL でも実企業のスキーマでは「言葉と列をどう結びつけるか」で問題が起こりやすいです。「売上」の意味が部署で違う。外部キーがカタログに無い。テーブルと文書をまたがないと答えられない。プロンプトを工夫するだけではこういう類の問題は解決できません。
指標の定義が曖昧なままエージェントを本番で利用すると誤った数字がすぐ拡散します。PoC では見えなかった語彙のズレが本番で大きな問題になります。
セマンティックレイヤー・オントロジー・ナレッジグラフなど呼び名は製品ごとに違います。やろうとしていることはかなり近く業務の意味をシステムが使える形で持つことです。製品名で並べると話が散るのでこの記事では作り方で分類します。
明示型（事前定義）— 先に型を決める
顧客・注文・チケット・製品といった実体と関係をデータより先に決めます。業界標準のオントロジーを土台にする場合もあれば自社の用語を一から決める場合もあります。あとから取り込むデータは先に決めた型に合わせて取り込みます。
関係も型として先に決めます。問い合わせのたびに「たぶんこう繋がる」と推測させる代わりに辿り方を最初から決めておきます。用語のブレを抑えやすく監査のときもどの型に従ったかを追いやすくなります。型がぶれなければエージェントの答えも安定しやすいです。
ドメインが大きいと設計に時間がかかります。スキーマや業務が変わったあとの更新も重いです。型を決められる人が足りないと前に進みません。
白紙から型を組む場合もあれば最初から業務領域の型が入っている場合もあります。顧客・製品・開発向けに型を先に持っている製品もありその差は Palantir Foundry OntologyとDevRevの思想と実装の違い に書いています。
明示型では正しさの設計者は人です。データを取り込む前に必ず型を定義します。
推論型（データから起こす）— ソースから案を起こす
テーブル・カタログ・文書などすでにあるものを入力にしてクラスや関係の案を作ります。スキーマからの生成・文書からの概念抽出・既存オントロジーとの対応づけ（グラウンディング）などが含まれます。
既存のテーブルや文書から骨格を早く作れます。現場の名前や言い回しも拾いやすいです。最初の整備コストは下がりやすいです。
ただソースに書いていない業務定義までは正確に取れません。関係の抜けや盛りすぎた一般化も混ざります。提案をそのまま本番に使うとエージェントが辿る意味が信用できなくなります。テーブルの分け方・命名の癖・コメントの有無・部署ごとの別名がそのまま「意味」になりやすいからです。
冒頭の記事で扱っている Context Ontology Accelerator は推論型の一例です。埋め込みで既存概念と突き合わせる方法や論文 RIGOR に沿った反復生成など生成のやり方はいくつかあります。
入力の違い
スキーマ／カタログから起こす
テーブル・列・参照関係からクラスやプロパティを作ります。物理スキーマに近い形が意味の骨格になりやすいです。カタログに外部キーが無くても列名から参照を推定して提案することがあります。
文書から起こす
用語集・返品ポリシー・運用手順などから概念や関係を作ります。テーブルだけでは持っていない業務ルールがここに入ることがあります。
文書から型を作ることと検索用に文書をグラフ化する GraphRAG は似て見えます。どちらも根拠は文書側にありますが目的は違います。文書から型を作るのは意味を業務資産として持つことです。GraphRAG は検索を良くすることです。詳しくは RAG を超える知識統合 や GraphRAGの限界とLightRAGの登場 に書いています。
ここできついのは グラフを作る段階で誤りが混ざること です。
典型的な流れは次のとおりです。
- 文書をチャンクに分ける
- チャンクごとに LLM がエンティティや関係を抜き出す
- それをグラフに載せる
ここで起きる問題です。
- チャンクで文脈が切れると関係の一方しか見えない・定義が別チャンクにある
- 抽出時に文書に無い関係を足したり別物を同一視したりするハルシネーションが混ざる
- 一度グラフに入ると「構造がある＝正しい」に見え以降の検索や回答がその誤りを再利用する
ベクトル RAG の幻覚が主に回答時なのに対しこちらは索引の時点で誤りがエージェントにとっての正解として扱われます。
だから文書から起こす推論型では根拠が文書にあっても安心できません。どの文に紐づくか・抽出結果を人が見るか・コアの型に合わせて落とすかが必要です。スキーマから起こす場合もソースの癖は残りますが文書＋チャンク＋LLM 抽出はその混入が特に起きやすいです。
同じ仕組みでスキーマ由来と文書由来の両方を扱うこともあります。その場合でも正しさの起点は人が先に決めた型よりソースから出た提案に寄ります。
推論型では正しさの初稿はデータとモデル側にあります。人が直すまでは仮置きです。
ハイブリッド：起案は推論、確定は人
よくある流れは次のようになります。
- スキーマや文書からオントロジーを提案する
- 人がレビューし必要なら直して承認する
- 機械でも品質チェックをかける
- 承認されたものだけをエージェントに渡す
Accelerator はこの流れの具体例です。提案（proposal）は人が承認するまで本番に使いません。チェックは推論器による論理の整合だけでなく構造メトリクスや設計アンチパターンの検出も含む三層です。承認後のオントロジーをエージェントから使う方法もあります。
オントロジーを作る速さは推論型側です。正しさの最終判断は人になります。レビュー担当がいなければ提案がそのまま本番に利用されます。ハイブリッドで大事なのは承認の手前で止められることです。
レビューでは次の3点を見ると良いです。
- クラス名は業務の言葉かテーブル名の直訳か
- 関係は外部キー由来か業務上のつながりか
- 「売上」など解釈が割れる語に人の定義があるか
冒頭の記事でも定義済み指標に一致したときと一致しなかったときで金額が分かれる例が出ています。
ハイブリッドでは正しさの最終判断は人です。起案の速さは推論型側です。
コアは設計し、周辺は AI で足す
人手だけで全部書くのも AI に全部任せるのも現実的ではありません。分けるのが現実的です。
初期にズレると困るコアは人が設計します。あとから足す項目は AI に案を出させ人は例外だけ見ます。正しさを誰が設計するかをコアと周辺で変えます。
コアとして人が設計した方が良いのは以下のようなものです。
- 顧客・契約・製品・案件など横断して辿る実体（自社で同じ役割のもの）
- 部署で揉めやすい指標の定義
- 権限の前提になる関係（誰が何に紐づくか）
あとから AI に案を出させてよいものです。
- テーブル追加に伴う属性の提案
- 用語集やポリシー文書からの補足概念
- コアへの対応づけ案・別名・説明文の下書き
コアが先にあると AI の提案もレビューしやすくなります。何への追加かが分かるからです。設計の手間はコアに使います。スキーマ変更への追従は AI に任せます。
DevRev では顧客・製品・開発まわりの実体と関係が製品側に最初から入っています。この記事で言うコアに相当するものを導入前から型として持っている形です。外のシステムから来るデータはその型に合わせて取り込み同期します。型の中身の比較は先の Palantir 比較記事に書いています。
エージェントの記憶としての設計は ナレッジグラフをエージェントの「記憶」にする設計 にまとめています。
実務でどう選ぶか
| 状況 | 選び方 |
|---|---|
| ドメインが複雑で用語やルールを厳密に揃えたい | コアは明示型。周辺はハイブリッドでレビュー |
| スキーマがよく変わる。まず早く見たい | 推論型で起こし最低限の人レビュー。コアだけ先に決めると後が楽 |
| レビューできる人がいる | ハイブリッド（起案は推論、確定は人） |
| テーブルが少なく語彙も素直 | 本格オントロジーは不要なことも多い |
| エージェントが本番で型を辿る | コアを固定し取り込みはマッピングと同期で合わせる |
確認しておきたいのは解釈が割れる指標に公式定義があるか。提案を承認する担当は誰かです。
実務ではコアを誰が設計するかを先に決め残りは AI 起案と人の例外レビューに回します。
Context Ontology Accelerator の使いどころ
ここからは Context Ontology Accelerator を試す人向けです。設計論だけ読む場合は前節までで十分です。
Context Ontology Accelerator は AWS 上に立てる OSS です。公式の説明でも AI がオントロジー作成を加速し人がレビューする前提になっています（ドキュメント）。Scan でソースをつなぎます。Model で提案を承認します。Serve では定義済みメトリクス・構造化クエリ・文書からの回答を使い分けます。結果をエージェントに渡します。
例えば次のようなときに使います。
- AWS 上に Glue や JDBC のスキーマがあり Text-to-SQL やエージェントで「言葉と列」が本番で崩れている
- テーブルの状態とポリシー文書の両方を見ないと答えられない問いがある
- 承認済みの意味だけを MCP などでエージェントに渡したい
- OWL や SHACL・標準オントロジーへの突き合わせを自分のアカウントで一周試したい
前節までの分け方をそのまま当てはめます。コアは人が決めます。提案は周辺のドラフトとしてレビューします。指標の定義やエージェント接続は承認後の資産ができてからにします。
Neptune や OpenSearch Serverless などを含む構成なので常時課金に見合わない小さな検証では試したら環境を落とす前提の方が安全です（公式の Getting Started でもコスト注意があります）。Accelerator は人の設計を加速するドラフト作成用として使うと良いです。起こすこと自体が目的になると推論型の弱点がそのまま残ります。
まとめ
- 明示型では正しさを人が先に設計します。推論型ではソースから案を起こします
- ハイブリッドでは起案は推論、確定は人です。承認の手前で止められることが重要です
- 初期にズレると困るコアは人が設計し周辺は AI に起案させて人が例外を見ます
- 文書から起こす推論型や GraphRAG では構築時の幻覚が索引に混入します。運用打撃が大きいです
- Accelerator はコアを人が決め周辺の下書きに AI を使う前提でドラフト作成に向きます
関連する実装の差や記憶の設計は次に書いています。
参考・出典
- オントロジーで AI に業務知識を渡す — AWS の OSS「Context Ontology Accelerator」を試してみた（AWS Japan 有志）
- Context Ontology Accelerator（GitHub）
- Context Ontology Accelerator ドキュメント
- RIGOR: Retrieval-Augmented Generation of Ontologies from Relational Databases
- Palantir Foundry OntologyとDevRevの思想と実装の違い
- ナレッジグラフをエージェントの「記憶」にする設計
- RAG を超える知識統合
- GraphRAGの限界とLightRAGの登場
- LLM 依存度を下げる業務 AI アーキテクチャ設計
更新履歴
- 2026-08-03: 初版公開
フィードバック受け付け
本記事は AI を活用して執筆しています。内容に誤りや追加情報があれば Zenn のコメントよりお知らせください。
Discussion