初めに
ここ 1〜2 年で、LLM を使ったオントロジー構築の論文と OSS が一気に増えました。
NeOn-GPT、Ontogenia、OntoChat、OntoGPT (SPIRES)、AutoSchemaKG、OntoKG、Wikontic、OntoLearner など、名前を挙げるだけでもきりがありません。
ただ、これらを「論文別」「ツール別」に眺めても、自分のプロジェクトでどこから手を付ければよいのか分かりにくいです。
そこで今回は、オントロジー構築の手法を次の 3 レイヤに分解したうえで、業界のベストプラクティスから見て効く順に並べ直してみます。
レイヤ1: 設計 — 何を作るかを決める
レイヤ2: 抽出 — 中身をどう埋めるか
レイヤ3: 品質保証 — 壊れていないことをどう保証するか
対象読者は、実際に業務データでオントロジー / ナレッジグラフを構築したい技術者です。
結論
先に結論を書きます。効く順はだいたい次です。
まず効く:
1. 能力質問（CQ）駆動の要件定義 [設計]
2. 既存オントロジーの再利用 [設計]
3. スキーマ制約付き抽出 [抽出]
4. 形式検証 + 自動修復ループ [品質保証]
その後に効く:
5. 多段パイプライン分解 [抽出]
6. マルチエージェント審議 / アンサンブル [品質保証]
条件付きで効く:
7. クラスタリング駆動のスキーマ帰納 [抽出]
最後に検討:
8. エンドツーエンドの単発プロンプト [抽出]
そして持論を先に書いておきます。
オントロジー構築の本質は「抽出」ではなく「合意」です。
LLM が得意なのは抽出のほうで、合意は人間側の作業です。ここを逆にすると、誰も同意していないクラス階層が大量に出てきて、結局あとで捨てることになります。
1. 能力質問（CQ）駆動の要件定義 ★最優先
概要
能力質問（Competency Question, CQ）とは「このオントロジーはどんな質問に答えられるべきか」を自然言語で書いたものです。Grüninger と Fox が 1995 年に提唱した、オントロジー工学では最も古典的な考え方です。
METHONTOLOGY → NeOn → LOT（Linked Open Terms）という方法論の系譜があり、LOT は要件仕様・実装・公開・保守という 4 フェーズで構成されます。
LLM 時代の実装としては次があります。
Ontogenia : メタ認知プロンプトで自己反省・構造修正、
オントロジー設計パターン（ODP）を組み込む
CQbyCQ : CQ とユーザーストーリーを直接 OWL スキーマに変換
OntoChat : 対話で「ユーザーストーリー作成 → CQ 抽出 →
CQ のフィルタ/クラスタリング → 言語化によるテスト」
RevOnt : 逆方向。既存のナレッジグラフから CQ を復元する
商用でも、metaphacts の metis は LOT 方法論に沿って CQ 作成・再利用・エンコード・評価を支援する構成になっています。
良い点・弱い点
良い点:
- スコープが先に閉じるので、無限に広がらない
- CQ がそのまま受け入れテストになる
- 非エンジニアと会話できる唯一の成果物
弱い点:
- CQ を集めるのに人手と時間がかかる
- ドメイン専門家は LLM への指示が上手くない、
という研究報告もある（仲介役が必要）
私の見解
ここを飛ばして良かったプロジェクトを見たことがありません。CQ が 20 個も書けないなら、そもそもオントロジーを作る段階ではないと思います。
2. 既存オントロジーの再利用
概要
ゼロから作らず、Schema.org、FOAF、SKOS、あるいはドメイン標準（医療なら SNOMED CT、製造なら ISO 系）を土台にする方法です。
2026 年の Extended NeOn-GPT は、この「再利用ステップ」を LLM パイプラインに明示的に組み込んだ点が新しいところです。構成は 2 つで、
(i) 多段プロンプトによる草稿生成
要件仕様 → 能力質問 → 概念化 → 形式モデリング
→ インスタンス投入 → ドキュメント化
(ii) 自動検証と修復
外部ツール呼び出しの編成 + LLM による修正提案
論文では Wine / ケモインフォマティクス / 環境微生物学 / 下水道網の 4 ドメインで、GPT-4o と Mistral・Llama-4・DeepSeek を比較評価しています。
良い点・弱い点
良い点:
- 語彙の相互運用性がタダで手に入る
- LLM のモデリング判断のブレが小さくなる
弱い点:
- 既存語彙の探索・マッピング自体がコスト
- 業務固有の概念は結局自分で定義することになる
私の見解
再利用は「全部乗せ」にしないのがコツです。上位語彙は借りて、中位から下は自分で定義する。ここを欲張ると、使わないクラスだらけの重いスキーマになります。
3. スキーマ制約付き抽出（Constraint-guided Extraction）
概要
先にスキーマ（型・関係の制約）を決めておき、LLM の抽出をその枠内に強制する方式です。今いちばん結果が出ている抽出手法だと思います。
代表例を 3 つ挙げます。
OntoKG（2026年4月、ProRata.ai）は、すべてのプロパティを intrinsic（検索用のノード属性、例: 生年月日） か relational（辿れるグラフのエッジ、例: 雇用主） に分類してルーティングします。2026年1月の Wikidata ダンプ（約1億件）に適用し、ルールベースのクリーニングで 3460万件のコア集合を抽出、各プロパティを 8 カテゴリ・94 モジュール（intrinsic 56 / relational 38）に割り当てています。カテゴリ被覆率 93.3%、モジュール割当率 98.0%、最終的に 3400万ノード・6120万エッジ・38 関係タイプの property graph を出力しています。
Wikontic（2025年12月）は、修飾子付きの候補トリプルを抽出したうえで Wikidata ベースの型・関係制約を強制し、エンティティを正規化して重複を減らします。MuSiQue では生成トリプルの 96% に正解エンティティが含まれ、MINE-1 では 86% で情報保持の SOTA を達成しています。
OntoGPT の SPIRES は、既存オントロジーの識別子に接地させた再帰的ゼロショットプロンプトで、生物医学ドメインのスキーマベース抽出を行います。
良い点・弱い点
良い点:
- 出力が最初から機械可読・検証可能
- エンティティ正規化を同時にやれば重複が激減する
- 下流（検索・推論）の実装が一気に楽になる
弱い点:
- スキーマを先に決められないと使えない（→ 手法1・2 が前提）
- スキーマ外の新概念を取りこぼす
私の見解
intrinsic / relational の切り分けは、地味ですが実務でいちばん効く考え方です。NL2SQL でいう「フィルタ条件になる列」と「JOIN 経路になる列」の区別と同じで、ここを設計時に決めておくと、後段のクエリ生成が驚くほど安定します。
4. 形式検証 + 自動修復ループ
概要
生成したトリプルを SHACL / OWL で検証し、違反したら LLM に直させる、いわゆる 生成 → 検証 → 修正のループです。
ここで技術者が押さえるべきなのは、SHACL と OWL は目的が逆だという点です。
OWL : 開放世界仮説（OWA）。データは不完全という前提で「推論」する
SHACL: 閉世界仮説（CWA）。データは完全という前提で「制約違反を検出」する
つまり「Aさんの部署が書かれていない」を、OWL は「まだ分かっていないだけ」と扱い、SHACL は「必須項目が欠けている」と扱います。この違いを理解せずに両方かけると、検証結果が意味不明になります。
実装例としては、arXiv:2604.20795（2026年4月、Partenit.io）が、エンティティ認識 → 関係抽出 → 正規化 → トリプル生成 → SHACL/OWL 検証 → 継続更新というパイプラインを提示しています。
良い点・弱い点
良い点:
- 「動くが間違っている」出力を機械的に落とせる
- CI に組み込める（回帰検知ができる）
弱い点:
- shape の定義自体が設計作業
- 検証で落ちた分をどう救うかの運用設計が必要
私の見解
上記の論文はプレプリントで、定量評価はハノイの塔ベンチマークと定性ケース 1 件です。アーキテクチャの考え方は参考になりますが、「産業レベルで実証済み」と読むのは行き過ぎだと思います。手法として堅いのは、あくまで SHACL/OWL という W3C 標準のほうです。
5. 多段パイプライン分解
概要
1 回のプロンプトで全部やらせず、タスクを分割してつなぐ方式です。ISWC 2025 で開催された LLMs4OL 2025 チャレンジ（主催: TIB）のタスク構成が、そのまま実用的な分解の型になっています。
Task A: Text2Onto 生テキストから用語と型を抽出
Task B: Term Typing 用語の上位型を判定
Task C: Taxonomy Discovery 型どうしの階層関係を発見
Task D: Non-Taxonomic Relation 分類階層以外の意味関係を抽出
チャレンジの結論として、商用 LLM + ドメイン調整済み埋め込み + ファインチューニングを組み合わせたハイブリッド構成が総合で最も強く、生物医学・技術系データセットではドメイン特化モデルが有効だったと報告されています。プロンプト設計・RAG・アンサンブル学習の重要性も挙げられています。
良い点・弱い点
良い点:
- 段階ごとに評価・差し替えができる
- 失敗箇所が特定できる
弱い点:
- LLM 呼び出しコストが段数分増える
- 段間のエラーが累積する
私の見解
同チャレンジの重要な指摘は「LLM は汎化は強いが、**関係の意味（relational semantics）**をつかむには追加の構造化学習・特化ファインチューニング・外部知識検索が必要かもしれない」という点です。つまり Task D が一番難しい。手法 3 の制約付き抽出が効くのも、まさにここです。
6. マルチエージェント審議 / アンサンブル
概要
複数の LLM に同じタスクをやらせ、相互レビューや多数決で最終出力を決める方式です。
LLMs4OL 2025 の DREAM-LLMs は、1 つの LLM が他 3 つの予測と根拠をレビューして最終判断を出す「審議ステップ」を導入しています。CQ 生成側でも CQGen-MAS（AAMAS 2026）のようなマルチエージェント系が出ています。
良い点・弱い点
良い点:
- 単一モデルのブレを平準化できる
- 根拠のレビューが監査ログとして残る
弱い点:
- コストが単純に N 倍
- 全員が同じ間違いをすると効かない
私の見解
効果は確かにありますが、費用対効果は手法 4 の形式検証に負けます。 SHACL は決定的で安価で、何度動かしても同じ答えを返します。まず検証、余裕があれば審議、の順番でよいと思います。
7. クラスタリング駆動のスキーマ帰納（schema-free）
概要
スキーマを事前に決めず、データ側からボトムアップで型を発見する方式です。Bian のサーベイ（arXiv:2510.20345）では、スキーマベース（構造・正規化・一貫性を重視）と対比される schema-free（柔軟性・適応性・オープンな発見を重視） のパラダイムとして整理されています。
LKD-KGC : 文書要約から抽出したエンティティ型をクラスタリングし、
オープンドメインのスキーマを高速に帰納
AutoSchemaKG : Web スケールのコーパスから動的スキーマ帰納で
自律的にナレッジグラフを構築
良い点・弱い点
良い点:
- 未知ドメインの探索、初期調査が速い
- 人間が思いつかない型が出てくることがある
弱い点:
- 型が実行のたびに揺れる（再現性が低い）
- 業務用語との対応付けが結局あとから必要
- 差分更新・バージョン管理が難しい
私の見解
「始める」には良いが「運用する」には弱い、というのが率直な印象です。探索フェーズで型の候補を出させ、確定したら手法 1〜3 の枠に落とす、という使い方が現実的です。いきなりこれを本番に置くと、半年後にスキーマが誰にも説明できなくなります。
8. エンドツーエンドの単発プロンプト（最後に検討）
概要
「このドキュメントから OWL オントロジーを作って」と 1 回投げる方式です。
研究上の評価は一貫しています。GPT-4 クラスの出力品質は初級のモデラー相当には届くが、NeOn-GPT の Wine オントロジー評価では、もっともらしい構造は作れても論理的一貫性と推論で苦戦し、人間による反復的な修正が必要だったと報告されています。
良い点・弱い点
良い点:
- とにかく速い、デモに向く
- 議論のたたき台としては十分使える
弱い点:
- 論理的一貫性が保証されない
- 再現性がない（毎回違うものが出る）
- そのまま本番に載せられない
私の見解
捨てる前提の草稿を出す道具と割り切るなら有用です。問題は、これがそれっぽく見えてしまうことで、レビューなしに承認されるとプロジェクトが最初から傾きます。
評価をどうするか
手法を選ぶ以上、比較する物差しも必要です。
| ベンチマーク | 測るもの |
|---|---|
| LLMs4OL (ISWC) | 用語抽出・型付け・階層発見・非分類関係抽出 |
| Text2KGBench | オントロジー駆動の KG 生成 |
| Bench4KE | 能力質問（CQ）の自動生成品質 |
| OntoURL | 記号的オントロジーの理解・推論・学習 |
実装ライブラリとしては、モジュール構成のオントロジー学習ライブラリ OntoLearner も出てきています。自前でパイプラインを組む前に一度見ておく価値はあります。
まとめ
| 順位 | 手法 | レイヤ | 一言 |
|---|---|---|---|
| 1 | CQ 駆動の要件定義 | 設計 | 飛ばしてはいけない |
| 2 | 既存オントロジー再利用 | 設計 | 上位は借り、下位は自作 |
| 3 | スキーマ制約付き抽出 | 抽出 | 今いちばん結果が出る |
| 4 | 形式検証 + 自動修復 | 品質保証 | 安価・決定的・CI 化できる |
| 5 | 多段パイプライン分解 | 抽出 | 関係抽出が最難関 |
| 6 | マルチエージェント審議 | 品質保証 | 効くがコスト N 倍 |
| 7 | クラスタリング駆動 | 抽出 | 探索向き、運用は弱い |
| 8 | 単発プロンプト | 抽出 | 捨てる前提の草稿 |
最初の一歩としては、この構成をおすすめします。
CQ を 20 個書く
+ 上位語彙だけ既存オントロジーから借りる
+ intrinsic / relational を分けたスキーマを定義する
+ SHACL で検証して CI に載せる
+ 足りない型が見えてきたらクラスタリングで探索する
なお、格納先については、Oracle Database 26ai 以降のようにベクトル検索とプロパティグラフ（SQL/PGQ）を 1 つのエンジンで扱えるデータベースを使うと、「関係ストア + ベクトル検索 + グラフ探索」を別々のミドルウェアに分けずに済みます。運用するコンポーネントが減るのは、この領域ではかなり効きます。
オントロジー構築の本質は、LLM に賢く抽出させることではありません。
関係者が同意できる語彙を決め、それが壊れていないことを機械的に検証し続けることです。