本レッスンのゴール:
「オントロジーとは何か？」「なぜDB設計やER図だけでは不十分で、オントロジーが必要なのか？」「業務導入・ナレッジグラフ構築はどう進めるのか？」の本質を掴みます。
1. オントロジーとは？（なぜビジネスで注目されるのか）
オントロジー（Ontology）とは、元々は哲学用語で「存在論」を意味しますが、情報科学・ITにおいては「ある特定ドメインにおける概念（モノや事象）の定義と、それらの関係性・ルールをコンピュータが処理できる形式で明示化したもの」を指します。
RDB（データベース設計）とオントロジーの決定的な違い
| 比較軸 |
リレーショナルDB (ERモデル) |
オントロジー (セマンティックモデル) |
| 主な目的 |
特定アプリのトランザクション処理・整合性保持 |
組織横断の意味的統合・知識の再利用・論理推論 |
| スキーマの柔軟性 |
テーブル構造に縛られる（変更コスト大） |
グラフ構造（ノード・エッジ追加が極めて容易） |
| 仮説の前提 |
閉世界仮説 (CWA): DBにない＝存在しない |
開世界仮説 (OWA): 未知の情報が存在することを前提 |
| 推論能力 |
SQL等で明示的に結合した条件のみ取得 |
ルール・関係性から「明示されていない知識」を推論導出 |
2. ナレッジグラフとLLM/RAGへの業務適用パターン
生成AI（LLM）の発展に伴い、オントロジーは「ハルシネーションの抑制」「正確なエンタープライズ検索」「複雑なリレーション探索」の中核基盤となっています。
主要な業務ユースケース:
- GraphRAG / KG-RAG: 文書を単にチャンク分割してベクトル検索するだけでなく、エンティティ間の関係（「部門Aが契約したベンダーBのシステムC」）をグラフとして探索し、LLMに高精度なコンテキストを与える。
- サイロ化データの意味的統合: 営業（Salesforce）、ERP（SAP）、顧客マスタ等で異なる名称・スキーマで管理されている「顧客」「契約」の概念をオントロジーで統一マッピング。
- 意味的推論 (Reasoning): 「親会社がコンプライアンス違反リスクあり ＝ 子会社・関連取引先も影響対象」のようなビジネスロジックを自動判定。
3. オントロジー構築の5ステップ（ベストプラクティス）
- コンピテンシー・クエスチョン（CQ）の策定: 「このオントロジーはどんな業務上の問いに答えられなければならないか？」を自然言語で5〜10個定義する（最重要）。
- 概念・語彙の抽出（Taxonomy設計）: 対象ドメインのコアエンティティ（クラス）と階層関係（is-a）を整理。
- 関係性（Properties）の設計: エンティティ間の結合（hasPart, manages, contractedWith 等）と属性（Data Property）を定義。
- 制約・オントロジー言語（OWL/SHACL）での実装: ProtégéやPythonライブラリを用いてOWL/RDFファイル形式に落とし込む。
- 実データとのマッピング・検証: 既存RDB/CSVからインスタンス（ABox）を生成し、CQに回答できるかSPARQL/グラフ探索で検証。
4. 理解度チェック（Practice Quiz）
問: 従来のRDB設計と比較した際の、オントロジー（ナレッジグラフ）の最大の特徴・強みとして最も適切なものはどれでしょうか？
次のステップ & 一次情報
まずは詳細な用語集と標準仕様をまとめた リファレンスドキュメント をご確認ください。
推奨一次情報: Ontology Development 101 (Stanford University) / W3C RDF 1.1 Primer