目次を表示する

オントロジー入門 2026 ─ 哲学・Palantir・GraphRAG までの全体像

実践 ─ オントロジー設計 8 アンチパターン + ツール選定 + 最初の30日

第9章: 実践 ─ オントロジー設計 8 アンチパターン + ツール選定 + 最初の30日

8アンチパターンと30日プラン

第3部までで「何を知るべきか」は揃った。本章では「いつ・何を・どう手を動かすか」を実践として整理する。3部構成：

  1. Palantir 公式の 8 アンチパターン（症状 → 根本原因 → 脱出法）
  2. ツール選定軸（Property Graph / Triplestore / Semantic Layer / GraphRAG OSS）
  3. 最初の30日プラン

Part 1: 8 アンチパターン

Palantir 公式ドキュメント “Ontology design: Best practices and anti-patterns” は、オントロジー設計でほぼ唯一体系化された 8つのアンチパターンを提供する。Palantir 専用のように見えるが、Property Graph / Triplestore / 自社実装すべてに当てはまる普遍的な失敗パターンだ。

mindmap
  root((8<br/>アンチパターン))
    Object Type 設計
      1 System Silos
      2 Kitchen Sink
      3 God Object
      4 Vague Naming
    Link Type 設計
      5 Time Machine
    Action Type 設計
      6 Action Sprawl
      7 Golden Hammer
    ガバナンス
      8 Permission Conflation

順に見ていく。

#1 System Silos ─ ソースシステムを Object Type にしてしまう

症状：SAP_Customer、Salesforce_Customer、DWH_Customer が別々の Object Type として存在する。BI レポートで「真の顧客数」が出せない。

根本原因：データ統合のコストを払わず、ソースシステムの構造をそのまま Ontology に持ち込んだ。

脱出法：

  • 統一の Customer Object Type を作る
  • Pipeline Builder（または ETL ツール）で複数 dataset を寄せて backing する
  • Customer のプロパティに source_system: SAP | Salesforce | DWH を持たせて出自を保持
# ❌ Anti-pattern
ObjectTypes:
  - SAP_Customer:
      backingDataset: ds_sap_raw
  - Salesforce_Customer:
      backingDataset: ds_salesforce_raw
  - DWH_Customer:
      backingDataset: ds_dwh

# ✅ Correct
ObjectTypes:
  - Customer:
      backingDataset: ds_customer_unified
      properties:
        - source_system: enum [SAP, Salesforce, DWH]
        - external_ids: list<{system, id}>

#2 Kitchen Sink ─ 技術的詳細をそのまま Object Type に

症状：Customer Object Type に _etl_run_id、_pipeline_version、_last_modified_by_dbt のような ETL メタデータが混在。BI ユーザーが本質的な属性を見つけられない。

根本原因：「Intentional curation」（意図的な整理）の不足。pipeline のメタとビジネスデータを分けていない。

脱出法：

  • ETL メタデータは backing dataset に留める
  • Object Type にはビジネス的に意味のあるプロパティだけ
  • 監査が必要なら audit というネスト構造で隔離

#3 God Object ─ 1つに何でも詰める

症状：Activity という Object Type に「商談」「サポート問い合わせ」「請求」「メール送信」が全部入っている。属性が100個以上あり、半数の行で半数の列が NULL。

根本原因：「概念的に少し似ている」だけで1つにしてしまう。One entity per type（1 Object Type = 1 概念）の原則違反。

脱出法：

  • 別概念は別 Object Type に分ける
  • 共通特性は Interface（ポリモーフィズム）で抽出
  • “Activity” を Deal / SupportTicket / Invoice / Email に分割
graph TB
    God[ ❌ Activity<br/>商談・サポート・請求・メール]
    Good[✅ 分割]
    Good --> D[Deal]
    Good --> S[SupportTicket]
    Good --> I[Invoice]
    Good --> E[Email]
    Good --> IF[Interface: HasCustomer<br/>共通の Link を抽出]
    style God fill:#1a2030,stroke:#ff4d6d
    style Good fill:#1a2030,stroke:#00d9c0

#4 Vague Naming ─ 抽象的すぎる名前

症状：Item、Entity、Record、Data のような抽象 Object Type が乱立。何を指すか文脈がないと分からない。

根本原因：命名の段階で具体性を捨てた。「Sales Order Line Item」のように具体的に名付けない。

脱出法：

  • 業務語彙を使う：SalesOrder / PurchaseOrder / LineItem
  • ドメイン専門家のレビューを通す
  • 命名規則を最初に決め、CI でチェック

#5 Time Machine ─ 履歴を「同じレコードの過去」で表現

症状：Customer.address が時間とともに変わるのに、レコードを上書きしている。「3か月前の住所」がもう取れない。

根本原因：履歴を別エンティティとしてモデル化していない。OLTP 的発想を Ontology に持ち込んだ。

脱出法：

  • 履歴が必要なら別エンティティに：CustomerAddress Object Type を作る
  • CustomerAddress は valid_from / valid_until を持つ
  • Customer から CustomerAddress への Link Type で時系列接続
graph LR
    C[Customer] -->|hasAddress| A1[CustomerAddress<br/>valid: 2024-01 〜 2025-06]
    C -->|hasAddress| A2[CustomerAddress<br/>valid: 2025-06 〜 現在]
    style C fill:#1a2030,stroke:#4cc9f0
    style A1 fill:#1a2030,stroke:#b794f4
    style A2 fill:#1a2030,stroke:#b794f4

第8章で見た Zep / Graphiti の「事実の有効期間」も、まさにこの考え方の現出。

#6 Action Sprawl ─ Action が増えすぎる

症状：updateCustomerName、updateCustomerEmail、updateCustomerPhone、updateCustomerAddress … と単一プロパティ更新の Action が10個以上ある。BI 画面が選択肢で埋まる。

根本原因：「業務プロセスに沿った束ねた Action」ではなく、「DB UPDATE 文と1対1」の Action を作っている。

脱出法：

  • 業務プロセスに沿って Action を束ねる：updateCustomerProfile（複数フィールドを一括更新）
  • 単一フィールドの軽微な編集は Object Explorer の inline edit に任せる

#7 Golden Hammer ─ すべてを Action で解決

症状：バッチ ETL も、定時通知も、cron-like なジョブも、すべて Action として実装されている。Action が数百個ある。

根本原因：用途を分けていない。Action は「人間が実行する変更」のためのもの。

脱出法：第5章で扱った棲み分け：

用途適切なツール
バッチ変換Pipeline Builder（pipelines）
人間の入力Action Type
イベント駆動Automation

「Golden Hammer」（金槌しか持たないと、すべてが釘に見える）への警告。

#8 Permission Conflation ─ Ontology 権限とデータ権限の混同

症状：「ユーザー A は Action X を編集できるが、その Object の backing dataset を読めない」状態を考慮していない。あるいは逆に、データを読める全員が Action 定義を編集できてしまう。

根本原因：Ontology resource permission と Data permission を同じレイヤで扱った。

脱出法：

  • Palantir の場合、明示的に分離されている：
    • Ontology Editor / Owner：Object Type / Action Type の定義を編集
    • Data Permission：backing dataset の読み取り
graph TB
    User[ユーザー]
    User --> OP[Ontology Permission<br/>定義の編集]
    User --> DP[Data Permission<br/>データ読み取り]
    OP --> O[Object Type 定義]
    DP --> D[(Backing Dataset)]
    style OP fill:#1a2030,stroke:#b794f4
    style DP fill:#1a2030,stroke:#4cc9f0

アンチパターンまとめ表

#アンチパターン症状根本原因脱出法
1System SilosSAP_X / Salesforce_X が並立統合コストを避けたPipeline で寄せて統一 Object Type
2Kitchen SinkETL メタが Object に混入意図的整理の不足ビジネス属性のみ、ETL メタは dataset に
3God ObjectActivity に何でも詰める1 type per concept 違反分割 + Interface で共通化
4Vague NamingItem / Record / Data具体性の欠如業務語彙、命名規則
5Time Machine履歴を上書き履歴を別エンティティ化していない履歴は別 Object Type + valid_from/until
6Action Sprawl単一プロパティ更新 Action 多数DB UPDATE 1対1業務プロセスで束ねる
7Golden Hammer何でも Action用途分け不足バッチ=pipeline / 人=Action / イベント=Automation
8Permission Conflation定義権限とデータ権限の混同レイヤ分離不足Ontology Permission と Data Permission を分離

これらは Palantir 限定ではなく、Neo4j / Stardog / 自社 KG 実装でも同じ罠が待っている。抽象化すれば普遍。

Part 2: ツール選定軸

第3章 / 第7章 / 第8章で個別に見たツール群を、選定の物差しとして再整理する。

4 つのカテゴリ

graph TB
    Tools[ツール選定]
    Tools --> PG[Property Graph 系]
    Tools --> RDF[RDF / Triplestore 系]
    Tools --> SL[Semantic Layer 系]
    Tools --> GR[GraphRAG OSS 系]
    PG --> PG1[Neo4j / Memgraph / TigerGraph / Neptune / FalkorDB]
    RDF --> RDF1[Stardog / GraphDB / AllegroGraph / Jena]
    SL --> SL1[Cube / dbt SL / Looker / Unity Catalog / AtScale]
    GR --> GR1[Microsoft GraphRAG / LightRAG / HippoRAG / Neo4j LLM Builder]
    style PG fill:#1a2030,stroke:#4cc9f0
    style RDF fill:#1a2030,stroke:#ff4d6d
    style SL fill:#1a2030,stroke:#b794f4
    style GR fill:#1a2030,stroke:#00d9c0

選定フローチャート

flowchart TB
    Start[要件] --> Q1{何を主目的とするか?}
    Q1 -- 業務オペレーション + Action --> Palantir[Palantir Foundry]
    Q1 -- BI メトリクス揃え --> SL[dbt SL / Cube / Unity Catalog]
    Q1 -- 知識検索 / RAG --> Q2{多ホップ・推論が必要?}
    Q1 -- アプリ統合グラフ --> PG[Neo4j / Memgraph]
    Q2 -- Yes --> Q3{規制ドメイン（医療/金融）?}
    Q2 -- No --> VR[ベクトル RAG で十分]
    Q3 -- Yes --> RDF[Stardog / GraphDB]
    Q3 -- No --> Q4{コスト制約は?}
    Q4 -- 厳しい --> Lazy[LazyGraphRAG + Property Graph]
    Q4 -- 緩い --> GR[Microsoft GraphRAG / Neo4j + LLM Builder]

選定軸の表

軸質問選択肢
規模数千万エンティティ超?超 → Neptune/TigerGraph、未満 → Neo4j/Memgraph
クエリ複雑度多ホップ・推論が要る?要 → RDF + OWL（Stardog/AllegroGraph）
推論必要性SHACL/OWL 推論が必須?Yes → Triplestore
LLM 統合度MCP / Agent との接続必要?要 → MCP first-class（Memgraph、Cube）
コストLazyGraphRAG コスト障壁解消後OSS GraphRAG が現実解
オープン標準ベンダーロックイン回避?OSI 準拠製品 / Open Catalog (Iceberg)
Action / 業務動詞も必要?Palantir Foundry

主要ツールの代表的な「向き不向き」

ツール向く場面向かない場面
Palantir Foundryエンタープライズ業務オペレーション軽量 SaaS / 個人開発
Stardog + Voicebox規制ドメイン、推論重視アプリ統合中心
Neo4j + LLM KG Builderアプリ + GraphRAG重い OWL 推論
Memgraph + MCPリアルタイム + LLM Agent大規模ストレージ
dbt Semantic Layerdbt 中心の BI 基盤業務 Action
Cube.dev多 BI / Embedded analytics推論ベース KG
Microsoft GraphRAG OSS研究 / PoCコスト制約あり Production
LazyGraphRAGコスト制約あり Production即実装したい初期 PoC

Part 3: 最初の30日プラン

オントロジーの世界に最初の30日で入り込むロードマップ。

gantt
    title オントロジー学習ロードマップ（30日）
    dateFormat  YYYY-MM-DD
    section Week 1
    3文脈の整理 (本書 第1章)        :a1, 2026-05-04, 2d
    Gruber と Open World (第2章)    :a2, after a1, 2d
    SemWeb スタック (第3章)         :a3, after a2, 3d
    section Week 2
    Palantir Ontology を読む (第4章) :b1, 2026-05-11, 2d
    Semantic/Kinetic/Dynamic (第5章) :b2, after b1, 2d
    一般 Semantic Layer (第6章)     :b3, after b2, 3d
    section Week 3
    Microsoft GraphRAG OSS を動かす :c1, 2026-05-18, 3d
    LazyGraphRAG を試す             :c2, after c1, 2d
    Neo4j or Memgraph Sandbox       :c3, after c2, 2d
    section Week 4
    PoC: 自社の小領域を KG 化       :d1, 2026-05-25, 4d
    8 アンチパターンで設計レビュー :d2, after d1, 2d
    ツール選定の決定 / 経営報告    :d3, after d2, 1d

Week 1: 概念の地図を作る

第1〜3章を読みながら、自分の言葉で要約する。Closed World vs Open World を実例（自社のRDB と知識グラフ）で対比できれば成功。

Week 2: 現代基盤を理解する

  • Palantir Foundry のドキュメントを読む（無料アカウントは作れないので公開ドキュメントで）
  • dbt Semantic Layer のチュートリアルを試す（自分の Snowflake / BigQuery と接続）
  • Cube.dev のクイックスタート

Week 3: GraphRAG を手で動かす

  • Microsoft GraphRAG OSS を試す 
    pip install graphrag
graphrag init --root ./my-project
# 小さな text コーパスでインデキシング
graphrag index --root ./my-project
graphrag query --root ./my-project --method global "全体のテーマは?"
  • LazyGraphRAG で同じデータを試してコスト・品質を比較
  • Neo4j Sandbox（無料）で Cypher を学ぶ
  • Neo4j LLM Knowledge Graph Builder で非構造化テキスト → KG 抽出

Week 4: 自社 PoC を立ち上げる

「自社の小領域」を1つ選んで、KG 化を試す：

PoC 例目的ツール
社内 Wiki の RAG 改善単純な検索 → 多ホップ可能化LightRAG / Microsoft GraphRAG
サポート FAQ の関係性可視化関連質問の探索Neo4j + Bloom
営業データの統一 Customerサイロ解消dbt model + 統一 view
ドキュメント横断検索RAGCortex Search / Bedrock GraphRAG

設計を 8 アンチパターンでレビューする。最低限「System Silos / God Object / Vague Naming / Permission Conflation」の4つだけは確認。

30日後のゴール

  • オントロジーの3文脈を自分の言葉で人に説明できる
  • Closed World vs Open World の違いを実例で言える
  • Palantir の Object/Link/Action/Function を Ontology 設計の語彙として使える
  • Semantic / Kinetic / Dynamic の3層を自社システムに当てはめて議論できる
  • Microsoft GraphRAG（または LazyGraphRAG）を自分のデータで動かした
  • 8 アンチパターンを「症状 → 根本原因 → 脱出法」で即答できる
  • 自社の小領域 PoC を 1つ動かした

キャッチアップ・継続学習リソース

公式

コミュニティ・ブログ

  • Sean Falconer：Semantic Web の現状を継続的に書く
  • Atlan / DataHub blogs：Semantic Layer / Ontology のエンタープライズ視点
  • phData / SELECT.dev：実装視点
  • arxiv.org：GraphRAG / KG 関連の最新研究

国内

  • 富士通 GENIAC / Knowledge Graph Extended RAG の発表
  • NEC AI 関連プレスリリース
  • NTT データ DATA INSIGHT

年次イベント

  • Knowledge Graph Conference（KGC、毎年）
  • Snowflake Summit（毎年6月、Cortex 関連）
  • ESWC（European Semantic Web Conference）
  • Palantir AIPCon

本章の要点

#要点
1Palantir 公式の 8 アンチパターン（System Silos / Kitchen Sink / God Object / Vague Naming / Time Machine / Action Sprawl / Golden Hammer / Permission Conflation）は普遍的
2アンチパターンは 症状 → 根本原因 → 脱出法 の3段で揃う
3ツール選定の4カテゴリ：Property Graph / RDF Triplestore / Semantic Layer / GraphRAG OSS
4選定軸：規模 / クエリ複雑度 / 推論必要性 / LLM 統合度 / コスト / オープン標準 / Action
530日プラン：Week1 概念整理 → Week2 現代基盤 → Week3 GraphRAG 実装 → Week4 自社 PoC
6LazyGraphRAG（コスト1000分の1）の登場で「軽量ベクトル → 必要部分だけ KG 化」が現実解
730日後のゴール：3文脈・Open World・3層モデル・GraphRAG・8 アンチパターン・PoC

効いている根本原理

本章は4原理を実装に降ろした章だった：

  • 原理1（共通言語）：System Silos / Vague Naming への対策
  • 原理2（Semantic vs Kinetic）：Action Sprawl / Golden Hammer
  • 原理3（構造 → 推論）：Time Machine（履歴を別エンティティに）
  • 原理4（LLM 橋渡し）：GraphRAG / LazyGraphRAG / MCP の選定

次の最終章で、4原理を全章にわたって回収する。