目次を表示する

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

Palantir Foundry の Ontology ─ digital twin としての設計

第4章: Palantir Foundry の Ontology ─ digital twin としての設計

Palantir Foundry の Ontology 4要素と業界事例

第1部で「オントロジーとは何か」を抽象的に見た。第2部の最初の章として、**「2026年エンタープライズで実際に最も大規模に動いているオントロジー実装」**である Palantir Foundry の Ontology を見ていく。

なぜ Palantir なのか

「オントロジー」と聞いてエンタープライズ界隈で最も思い浮かぶのが Palantir Foundry / AIP。理由は3つある：

  1. 規模：U.S. Army TITAN（$178.4M、2025-03 最初の2機納入）、Airbus Skywise、SOMPO Holdings（国内 8,000+ 従業員が日常利用）など社会インフラ級の事例
  2. 語彙：「Ontology は組織の digital twin」「Semantic / Kinetic / Dynamic Layer」というフレーミングが業界の語彙を変えた
  3. OWL/RDF を使わない：第3章で見たセマンティックWebスタックを採用せず、独自のグラフ + アクションモデルで実装している ─ これが「OWL/RDF を使わないとオントロジーではない」という誤解を打破する好例

第3章で扱った RDF/OWL がアカデミック・W3C 系統だとすれば、Palantir Ontology はプロダクション・エンタープライズ系統の代表。両者は対立するのではなく、異なる文化圏の異なる実装として併存している。

Palantir 公式の位置付け ─ “digital twin of an organization”

Palantir 公式は Ontology を「組織の operational layer」と位置づけ、以下のように説明する：

The Ontology is the digital twin of your enterprise. It connects datasets, models, and real-world things.

データセット・モデル・現実世界のオブジェクト（plant、equipment、order、patient、aircraft 等）を結ぶ層であり、**「サイロ化したデータと意思決定の分断」**を解消することを目的とする。

graph TB
    subgraph Real World
        RW1[Aircraft]
        RW2[Maintenance Crew]
        RW3[Spare Parts]
        RW4[Maintenance Schedule]
    end
    subgraph Foundry Ontology
        OT1[Object Type: Aircraft]
        OT2[Object Type: Crew]
        OT3[Object Type: Part]
        AT1[Action Type: Schedule Maintenance]
    end
    subgraph Backing Data
        DS1[(Dataset: SAP)]
        DS2[(Dataset: ERP)]
        DS3[(Dataset: Sensor logs)]
    end
    DS1 --> OT1
    DS2 --> OT2
    DS3 --> OT3
    OT1 -.-> RW1
    OT2 -.-> RW2
    OT3 -.-> RW3
    AT1 --> RW4
    style OT1 fill:#1a2030,stroke:#b794f4
    style OT2 fill:#1a2030,stroke:#b794f4
    style OT3 fill:#1a2030,stroke:#b794f4
    style AT1 fill:#1a2030,stroke:#ff4d6d

「Ontology は thin な semantic layer ではない」と Palantir 公式が強調する点が重要。第6章で見る一般 Semantic Layer 製品（Cube / dbt SL 等）と決定的に違うのは、Action / Function / Security も同じ層に同居していることだ。

4 要素 ─ Palantir Ontology の構成ブロック

Palantir Foundry の Ontology は、以下の4つで成り立つ。

graph TB
    O((Foundry Ontology))
    O --> OT[Object Type<br/>名詞]
    O --> LT[Link Type<br/>関係]
    O --> AT[Action Type<br/>動詞]
    O --> F[Function<br/>ビジネスロジック]
    OT --> OTE[例: Aircraft, Customer, Order]
    LT --> LTE[例: Aircraft assigned to Crew]
    AT --> ATE[例: Schedule Maintenance]
    F --> FE[例: TypeScript / Python]
    style OT fill:#1a2030,stroke:#4cc9f0
    style LT fill:#1a2030,stroke:#b794f4
    style AT fill:#1a2030,stroke:#ff4d6d
    style F fill:#1a2030,stroke:#00d9c0

Object Type（名詞）

現実世界のエンティティ・イベントのスキーマ定義。クラスに相当。

// 概念的なイメージ
{
  name: "Aircraft",
  properties: {
    tailNumber: "string",
    model: "string",
    flightHours: "integer",
    lastMaintenanceAt: "timestamp"
  },
  // backing dataset との結合
  backingDataset: "ds_fleet_master"
}

ER 図のテーブルに似ているが、Foundry の Object Type は backing dataset と疎結合で、複数 dataset から1つの Object Type を構成できる（SAP の Customer + Salesforce の Customer + 自社 DWH の Customer を統一 Customer に寄せる）。

2つの Object Type 間の関係性スキーマ。RDB の JOIN に相当するが、型として一級市民である点が違う。

graph LR
    A[Object Type:<br/>Aircraft] -->|Link Type:<br/>maintained by| C[Object Type:<br/>Maintenance Crew]
    A -->|Link Type:<br/>contains| P[Object Type:<br/>Part]
    style A fill:#1a2030,stroke:#4cc9f0
    style C fill:#1a2030,stroke:#4cc9f0
    style P fill:#1a2030,stroke:#4cc9f0

Link は単なる FK ではなく、Property Graph のエッジに似た一級概念。1対1 / 1対多 / 多対多のカーディナリティと、Link 自体への属性も持てる。

Action Type（動詞）

★ Palantir Ontology の最も特徴的な要素。Object / Property / Link への変更操作スキーマで、副作用（外部システム書き戻し、通知、webhook）も束ねる。

# 概念的なイメージ
ActionType:
  name: "Schedule Maintenance"
  parameters:
    - aircraft: ObjectType<Aircraft>
    - scheduledAt: timestamp
    - crew: ObjectType<MaintenanceCrew>
  effects:
    # Foundry 内のオントロジー更新
    - update Aircraft.lastScheduledMaintenanceAt
    - create MaintenanceSchedule (Object)
    - link Aircraft -> MaintenanceSchedule
    # 外部システム書き戻し
    - SAP: create work order via API
    - Slack: notify maintenance team
    - mobile: push notification to assigned crew

これが**「Kinetic Layer」**の核心 ─ 第5章でこのテーマだけに章を割く。

Function（ビジネスロジック）

TypeScript / Python で書く任意のロジック。Object を入力に取り、Action から呼ばれる。LLM Tool としても使えるのが2024-2026 で重要になった機能。

// 概念的なイメージ
@OntologyFunction()
function calculateMaintenancePriority(
  aircraft: Aircraft
): "high" | "medium" | "low" {
  const hoursSince = aircraft.flightHours - aircraft.lastMaintenanceAt;
  if (hoursSince > 1000) return "high";
  if (hoursSince > 500) return "medium";
  return "low";
}

この Function が AIP の Logic ブロックや Agent Studio のツールとして呼び出される。

Datasets と Ontology の関係

Foundry の中で Datasets と Ontology は別の層にあり、責務が違う。

graph TB
    subgraph Pipeline 層
        Raw[Raw Datasets<br/>S3 / RDB / SAP / Salesforce 等]
        PB[Pipeline Builder<br/>ETL]
        Clean[Clean Datasets]
        Raw --> PB
        PB --> Clean
    end
    subgraph Ontology 層
        OT[Object Types]
        LT[Link Types]
        AT[Action Types]
        F[Functions]
    end
    subgraph アプリ層
        WS[Workshop アプリ]
        AIP[AIP Agent / Logic]
        OE[Object Explorer]
    end
    Clean --> OT
    OT --> LT
    OT --> AT
    OT --> F
    OT --> WS
    AT --> WS
    F --> AIP
    OT --> OE
    style OT fill:#1a2030,stroke:#4cc9f0
    style AT fill:#1a2030,stroke:#ff4d6d
  • Datasets：原材料（SAP、ERP、ログ、CSV、…）。Pipeline Builder で整形
  • Ontology：意味づけ層（Object Type に backing する）
  • アプリ：Object と Action を消費する UI（Workshop、Object Explorer、AIP Agent）

「Ontology は dataset の上のセマンティックレイヤだが、Action と Function を含む点で thin ではない」 ─ これが Palantir の主張。

周辺アプリ ─ Ontology を消費する UI

Ontology Manager

Object / Link / Action Type を編集する管理 UI。Ontology Owner / Editor の権限ロールで管理。データガバナンスと密接に連携。

Object Explorer

end user 向けの検索・可視化アプリ。「Aircraft N12345 の状態を見せて」のような自然なクエリで Object を引いて、関連 Link を辿れる。

Workshop

ノーコードのアプリ構築ツール。Action Type を Submit ボタンに、Object を表・詳細パネルに割り当てて社内アプリを作る。「Ontology + Workshop」で end-user-facing なオペレーションアプリが2-3週間で立ち上がるのが、Palantir の典型的な売り。

Slate / Pipeline Builder（補助）

  • Slate：旧型の HTML/JS 風カスタムアプリ（Workshop 推奨に後退）
  • Pipeline Builder：ETL 側（Kinetic ではない、batch transformation）

AIP（Artificial Intelligence Platform）との連携

2024-2026 の Palantir 戦略で、Ontology は **「LLM の世界モデル + ツールカタログ」**として再定義された。

AIP の主要コンポーネント

コンポーネント役割
AIP Logicノーコードで LLM-powered Function を作る環境。“Use LLM” block + Tool（Query objects / Apply actions / Call function）を組み合わせ
AIP Agent StudioOntology / 文書 / Tool を装備したチャットエージェント。Workshop に widget として埋め込める
AIP Threadsアドホックな文書質問用
AIP Assistプラットフォーム内ヘルプ AI

LLM × Ontology 統合の核心

graph TB
    User[ユーザー: 自然言語の質問]
    User --> AIP[AIP Logic / Agent Studio]
    AIP --> LLM[LLM]
    LLM -.tool call.-> AIP
    AIP --> Tools[3 種類の Tool]
    Tools --> T1[data tool<br/>Query objects]
    Tools --> T2[logic tool<br/>Call function]
    Tools --> T3[action tool<br/>Apply actions]
    T1 --> O[(Ontology)]
    T2 --> O
    T3 --> O
    O --> Result[結果 + 副作用]
    Result --> User
    style LLM fill:#1a2030,stroke:#b794f4
    style O fill:#1a2030,stroke:#4cc9f0
    style T3 fill:#1a2030,stroke:#ff4d6d

重要な設計：LLM 自身は tool を直接呼ばない。AIP Logic がユーザの権限内で実行する。これが Confused Deputy 系の権限濫用を構造的に防ぐ（AIセキュリティ編 第7章を参照）。

Model Context Protocol (MCP / OMCP)

2025-07 ロールアウトされた Palantir MCP（OMCP）は、Object Type / Action Type / Query Function を MCP tool として外部公開できる仕組み。

これにより：

  • AI IDE（Cursor、Claude Code 等）から Foundry オントロジーを安全に読み書き
  • 外部の AI Agent が Foundry の Object に対してアクション

ができるようになった。「Ontology は MCP の最良のスキーマ供給源」という位置づけ。

業界事例

Palantir 公式 case study で確認できる実例を、ユースケースごとに整理する。

防衛・政府

事例内容
U.S. Army TITAN2024年 prime award $178.4M、10 prototype。2025-03 最初の2機を納入。Anduril、L3Harris、Northrop と連携
NHS England + Palantir FDP7年£330M、医療データ統合プラットフォーム。2025-10 時点で 215 施設中 72 トラスト未満 adopt（採用率 1/3 未満）、BMA は 2025-06 に反対決議。現実は順風満帆ではないことも記録すべき
Golden Dome（米ミサイル防衛）2026-03 Reuters 報道、フェーズ1 で $185B 規模

製造

事例内容
Airbus Skywise2017年〜、A350 製造でサプライヤ含む不均質データを統合、A350 納入を 33% 増
BPパイプライン保全〜CO2 排出〜再エネ ROI
Tyson FoodsSCM / 物流

製薬

事例内容
SanofiPalantir パートナー、データ統合プラットフォームとして
MerckFoundry DevTools を OSS 公開（顧客発の最初の OSS ライブラリ）

金融

事例内容
Morgan StanleySingle Client View（数百万口座）
Credit Suisse2016年〜、コンプライアンス / Single View

国内

★ SOMPO Holdings（最も成熟した国内事例）

項目内容
パートナーシップ2019年 Palantir Japan を共同設立
プラットフォームReal Data Platform 構築
用途介護施設管理、損害保険 underwriting、支払最適化、不正検知
利用規模国内 8,000+ 従業員が日常業務で利用
保険代理店1万人超が動的料金 / リスク評価 AI モデルを使用
投資2023年 $50M 拡張、2025-08 マルチイヤー契約延長

「国内事例で digital twin が実際に動いている規模」として、SOMPO は他社が参照する基準点になっている。

何を解いているか ─ 改めて整理

mindmap
  root((Palantir<br/>Ontology))
    解く問題
      サイロ化
      意思決定の分断
      手作業のオペレーション
      外部システム連携の複雑さ
    提供価値
      共通の意味モデル
      実行可能なアクション
      ガバナンスと権限
      LLM の世界モデル化
    特徴
      OWL/RDF 不使用
      Object/Link/Action/Function
      digital twin
      Workshop で UI 即生成

第3章で見た RDF/OWL はアカデミック寄りで「世界の構造を厳密に記述する」のが主目的。Palantir Ontology は実務寄りで「世界の構造を記述しながら、それを動かす」のが主目的。目的が違うから実装も違う。

本章の要点

#要点
1Palantir 公式は Ontology を「digital twin of your enterprise」と位置づけ
24 要素：Object Type / Link Type / Action Type / Function ─ 名詞・関係・動詞・ロジック
3OWL/RDF を使わない独自実装。「OWL/RDF でないとオントロジーではない」という誤解を打破
4Datasets ≠ Ontology。Pipeline Builder で dataset を整形 → Ontology が意味づけ → Workshop / AIP がアプリ層で消費
5AIP は Ontology を「LLM の世界モデル + ツールカタログ」として活用。data tool / logic tool / action tool の3種
6**MCP（OMCP、2025-07）**で外部 AI Agent からも Foundry オントロジーへ安全アクセス可能に
7事例：TITAN（$178.4M、2025-03 納入）/ Airbus Skywise（A350 納入 +33%）/ SOMPO（国内 8,000+ 従業員利用）
8NHS FDP のように採用が順調でない事例も含めて知っておく

効いている根本原理

本章は 原理1（共通言語） と 原理4（LLM 時代の橋渡し） が中心だった。Palantir Ontology は組織の意味を共通化し、その上に LLM を乗せる構造。次章では、ここで触れた Action Type をさらに深掘りし、Palantir 公式の整理である Semantic / Kinetic / Dynamic 3層モデルを、本シリーズの中核図解章として展開する。