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

Semantic / Kinetic / Dynamic ─ 名詞・動詞・規則の3層モデル

2026/05/04

第5章: Semantic / Kinetic / Dynamic ─ 名詞・動詞・規則の3層モデル

Semantic / Kinetic / Dynamic 3層モデル

第4章で Palantir Foundry の Ontology を概観した。本章は本シリーズの中核図解章として、Palantir 公式の整理である Semantic / Kinetic / Dynamic 3層モデルを深掘りする。特に「Kinetic Layer」── オントロジーが動詞として動くという発想は、伝統的な OWL/RDF の世界には存在しなかった新しい考え方だ。

3層モデルの全体像

Palantir 公式の Architecture Center は、Ontology を以下の3層で整理する。

graph TB
    subgraph Ontology
        S[Semantic Layer<br/>名詞]
        K[Kinetic Layer<br/>動詞]
        D[Dynamic Layer<br/>規則]
    end
    S --> SE[Object Type<br/>Link Type<br/>Property]
    K --> KE[Action Type<br/>Function<br/>Automation]
    D --> DE[権限<br/>ライフサイクル<br/>ガバナンス]
    style S fill:#1a2030,stroke:#4cc9f0
    style K fill:#1a2030,stroke:#ff4d6d
    style D fill:#1a2030,stroke:#b794f4

層	役割	言語的たとえ	構成要素
Semantic（意味）	「何が存在するか」	名詞	Object / Link / Property
Kinetic（動き）	「何ができるか」	動詞	Action / Function / Automation
Dynamic（規則）	「いつ・誰が・どう動くか」	副詞・規則	権限 / ライフサイクル / ガバナンス

**「名詞だけでなく、動詞も、副詞も、すべてオントロジーに含める」**というのが Palantir の発明。これは伝統的な OWL/RDF（名詞中心）と決定的に違う。

1. Semantic Layer ─ 名詞の世界

第3章・第4章で見た領域。Object Type、Link Type、Property を定義する。

Object Type が答える問い

「この組織は何を扱っているか？」

例（航空会社の場合）：

Aircraft（航空機）
Flight（フライト便）
Passenger（乗客）
Crew（乗務員）
Maintenance Schedule（整備計画）
Spare Part（補充部品）
Airport（空港）

これらをすべて Object Type として定義する。複数のソースシステム（SAP、ERP、運航管理システム、整備記録）から来るデータを、1つの統一 Object Type に寄せるのが Semantic Layer の仕事。

Link Type が答える問い

「それらはどう繋がっているか？」

graph LR
    F[Flight] -->|operated by| C[Crew]
    F -->|departs from| AP[Airport]
    F -->|arrives at| AP
    F -->|uses| AC[Aircraft]
    AC -->|requires| MS[Maintenance Schedule]
    AC -->|contains| SP[Spare Part]
    style F fill:#1a2030,stroke:#4cc9f0
    style C fill:#1a2030,stroke:#4cc9f0
    style AP fill:#1a2030,stroke:#4cc9f0
    style AC fill:#1a2030,stroke:#4cc9f0
    style MS fill:#1a2030,stroke:#4cc9f0
    style SP fill:#1a2030,stroke:#4cc9f0

これが Semantic Layer の中核 ─ 「組織を1枚のグラフとして書く」。第3章で見たセマンティックWebの RDF triple が「データのレベルで世界をグラフにする」のに対し、Palantir Semantic Layer は「ビジネスの意味のレベルで世界をグラフにする」。

一般 Semantic Layer 製品との違い（軸の違い）

第6章で詳しく扱うが、一般 BI 系の Semantic Layer（Cube / dbt SL / Looker / Unity Catalog Metric Views）は「メトリクス（Revenue, ARR）」を一元定義することが目的。

Palantir Semantic Layer は「エンティティ（Aircraft, Customer）」を一元定義することが目的。

graph LR
    Q[Semantic Layer の主役は?]
    Q --> M[メトリクス中心<br/>Revenue / ARR / DAU]
    Q --> E[エンティティ中心<br/>Customer / Aircraft / Order]
    M --> M1[Looker LookML]
    M --> M2[dbt Semantic Layer]
    M --> M3[Cube.dev]
    M --> M4[Unity Catalog Metric Views]
    E --> E1[Palantir Foundry Ontology]
    E --> E2[Stardog]
    E --> E3[Neo4j + RDF]
    style M fill:#1a2030,stroke:#4cc9f0
    style E fill:#1a2030,stroke:#ff4d6d

「どちらが正解」ではなく「目的と読者が違う」。BI ユーザー向けはメトリクス中心、業務オペレーション向けはエンティティ中心。

2. Kinetic Layer ─ 動詞の世界（本章の主役）

★ ここが本シリーズで最も新しい概念。「オントロジーが動く」という発想だ。

Palantir 公式の定義

“to model actual decisions, the system must include verbs—executable actions” （実際の意思決定をモデル化するには、システムは「動詞」── 実行可能なアクション ── を含む必要がある）

伝統的なオントロジー（OWL/RDF）は 名詞だけ だった。「Aircraft とは何か」「Aircraft と Flight の関係は」を書くだけで、「Aircraft をどう操作するか」は別のレイヤだった。これが分離されていることが、エンタープライズ実装で問題だった。

Action Type が束ねる3つの責任

graph TB
    AT[Action Type:<br/>Schedule Maintenance]
    AT --> R1[Foundry 内部の更新]
    AT --> R2[外部システム書き戻し]
    AT --> R3[Workflow オーケストレーション]
    R1 --> R1E[Aircraft.lastMaintenance 更新<br/>MaintenanceSchedule Object 作成<br/>Aircraft - Schedule の Link 作成]
    R2 --> R2E[SAP に Work Order 発行<br/>Slack 通知<br/>Mobile プッシュ通知]
    R3 --> R3E[承認フロー起動<br/>条件付き Action 連鎖<br/>失敗時のロールバック]
    style AT fill:#1a2030,stroke:#ff4d6d

伝統的には「DBの UPDATE」「外部APIの呼び出し」「ワークフロー」は別々のシステムだった。Action Type はこの3つを1つのスキーマで束ねる。

具体例：Schedule Maintenance Action

# Action Type 定義の概念モデル
ActionType: Schedule Maintenance
  parameters:
    aircraft: Aircraft
    scheduledAt: timestamp
    crew: MaintenanceCrew
    parts: List<Part>

  validation:
    - aircraft.status != "in flight"
    - crew.availability includes scheduledAt
    - crew.certifications include aircraft.model

  effects:
    # Foundry 内部
    - create MaintenanceSchedule (linked to aircraft, crew)
    - update aircraft.nextMaintenanceAt = scheduledAt
    - update crew.assignedSchedules += new schedule

    # 外部システム
    - SAP.createWorkOrder(aircraft, scheduledAt, parts)
    - Slack.notify(channel: crew.team, message: "...")
    - mobile.push(user: crew.lead, message: "...")

  permissions:
    - role: "MaintenancePlanner" can execute
    - role: "Auditor" can view

  audit:
    - log to AuditTrail Object
    - retain for 7 years (regulatory)

これだけのことが、1つの Action Type 定義で完結する。フィールド技師が iPad で Aircraft Object を開き、“Schedule Maintenance” Action を実行 → SAP に WO 発行 + Slack 通知 + Workshop ダッシュボードに反映、までが一気通貫で動く。

Function ─ Action のロジック層

Action は副作用を束ねるが、ロジック自体は Function（TypeScript / Python）として書く。

// 概念的なイメージ
@OntologyFunction()
function calculateOptimalMaintenanceWindow(
  aircraft: Aircraft,
  crews: List<MaintenanceCrew>,
  parts: List<Part>
): { scheduledAt: Date; selectedCrew: MaintenanceCrew } {
  // ビジネスロジック
  // - 部品在庫の確認
  // - クルーの稼働状況
  // - フライトスケジュールとの衝突回避
  // を計算して最適時刻と担当を返す
  return { scheduledAt, selectedCrew };
}

Function は LLM Tool としても使えるため、AIP Agent が「最適な整備時刻を考えて」と言われたときに、この Function を呼んで答える。

Automation ─ イベント駆動の Action

「Aircraft の flightHours が 1000 を超えたら、自動的に Schedule Maintenance Action を発火する」というイベント駆動の仕組み。手動 Action と違って人間が介在しない。

graph LR
    E[Event:<br/>aircraft.flightHours > 1000] --> A[Automation]
    A --> AT[Action Type:<br/>Schedule Maintenance]
    AT --> S[副作用一式]
    style E fill:#1a2030,stroke:#ff4d6d
    style A fill:#1a2030,stroke:#b794f4
    style AT fill:#1a2030,stroke:#ff4d6d

「バッチ処理は Pipeline、人間入力は Action、イベントは Automation」と棲み分ける ─ これが Palantir 公式の Anti-Pattern「Golden Hammer」（全部 Action にする）への対策（第9章で扱う）。

3. Dynamic Layer ─ 規則の世界

3層モデルの3つ目。「いつ・誰が・どう動くか」を制御する。

主な構成要素

要素	内容
Permission	Object Type / Action Type の RBAC（Functional Role + Access Role）
Lifecycle	Object のステータス遷移、Action の有効期間
Governance	Ontology Owner / Editor の権限分離、変更承認フロー
Audit	全 Action 実行の監査ログ（規制対応）

Permission の階層

Palantir では Ontology Resource Permission（Editor 等）と Data Permission（dataset の読み取り）が分離している。

graph TB
    User[ユーザー] --> FR[Functional Role:<br/>Maintenance Planner]
    FR --> AR1[Ontology Permission:<br/>Schedule Maintenance Action 実行]
    FR --> AR2[Data Permission:<br/>Aircraft Object 読み取り]
    AR1 --> O[Action Type]
    AR2 --> D[(Backing Dataset)]
    style FR fill:#1a2030,stroke:#b794f4
    style AR1 fill:#1a2030,stroke:#ff4d6d
    style AR2 fill:#1a2030,stroke:#4cc9f0

「Action 実行権限を持っているが、backing dataset の読み取り権限がない」という状況も成立する。これは Confused Deputy 攻撃（AIセキュリティ編第7章で扱った概念）に対する構造的防御になっている。

3層モデルが解いている問題

なぜ Palantir はこの3層整理にこだわるのか。理由は3つある：

(1) 「動詞を一級市民にすると、現実の業務がモデル化できる**」

伝統的な ER 図や OWL は名詞中心。動詞は別途「ストアドプロシージャ」「業務アプリケーション」「ワークフローエンジン」に分散していた。Action Type として一級市民にすると、業務プロセスがオントロジーの一部になる。

(2) 「LLM が世界を理解しやすくなる」

LLM Agent が Foundry を使うとき、「データを取る」だけでなく「アクションを起こす」ところまで一貫したスキーマで記述されているのが大きい。AIP Agent はこの Kinetic Layer を Tool として直接呼べる。

(3) 「ガバナンスを意味モデルに統合できる」

Dynamic Layer により「Action 実行権限」「変更承認フロー」がオントロジーの一部になる。ガバナンスが後付けではなく、最初から組み込まれる。

LLM 時代との接続

graph TB
    LLM[LLM Agent]
    LLM --> Q1[Query Object<br/>'今飛んでいる Aircraft は?']
    LLM --> Q2[Call Function<br/>'最適な整備時刻を計算']
    LLM --> Q3[Apply Action<br/>'Schedule Maintenance を実行']
    Q1 --> S[Semantic Layer]
    Q2 --> K[Kinetic Layer / Function]
    Q3 --> K
    Q3 --> D[Dynamic Layer<br/>権限チェック]
    style LLM fill:#1a2030,stroke:#b794f4
    style S fill:#1a2030,stroke:#4cc9f0
    style K fill:#1a2030,stroke:#ff4d6d
    style D fill:#1a2030,stroke:#7c8db5

3層モデルはLLM Agent との接続点が3つある：

Semantic Layer：Agent がデータを問い合わせる先
Kinetic Layer：Agent が呼び出すツール（Function / Action）
Dynamic Layer：Agent の実行権限を制御する境界

「Ontology は LLM の世界モデル」というフレーズは、この3つすべてを含んでいる。第8章で詳しく扱う。

一般化：3層モデルは Palantir 専用ではない

「Semantic / Kinetic / Dynamic」というネーミングは Palantir 公式だが、この発想は他のシステムでも応用できる。

Palantir 概念	一般化	他システムでの相当物
Semantic Layer	データの意味づけ	dbt model、GraphQL Schema、ER 図
Kinetic Layer	実行可能なアクション	API Gateway、Workflow Engine、Stored Procedure
Dynamic Layer	権限・ガバナンス	RBAC、Policy as Code、Audit Log

つまり「3層に分けて考える」ことは、Palantir を使っていなくてもシステム設計の考え方として有用だ。

8つのアンチパターンへの予告

第9章で扱う Palantir 公式の 8 アンチパターンのうち、Kinetic Layer 関連が3つある（Action Sprawl、Golden Hammer、Permission Conflation）。Action の設計は、Object Type の設計と同等以上に難しいことが分かる。

本章の要点

#	要点
1	Palantir 公式の 3層モデル：Semantic（名詞）/ Kinetic（動詞）/ Dynamic（規則）
2	Semantic Layer は Object Type / Link Type / Property。「組織を1枚のグラフとして書く」
3	一般 Semantic Layer 製品はメトリクス中心、Palantir Semantic Layer はエンティティ中心 ─ 軸が違う
4	Kinetic Layer = 動詞。Action Type は ① Foundry 内部更新 ② 外部システム書き戻し ③ Workflow オーケストレーションの3つを束ねる
5	Function は Action のロジック層。LLM Tool としても使えるのが2024-2026 の重要な進化
6	Automation はイベント駆動の Action。「バッチは Pipeline、人間入力は Action、イベントは Automation」と棲み分け
7	Dynamic Layer は権限・ライフサイクル・ガバナンス・監査。Confused Deputy 攻撃に構造的に強い設計
8	LLM Agent は3層すべてに接続：Semantic に問い合わせ、Kinetic を呼び、Dynamic で制御される
9	3層モデルは Palantir 専用ではない。一般化してシステム設計の考え方として有用

効いている根本原理

本章は 原理2（Semantic と Kinetic は分離可能だが連動する） が真ん中に立った章だった。原理1（共通言語） はSemantic、原理4（LLM 時代の橋渡し） はAgent接続点で、すべてが3層モデルに収斂する。次章では、Palantir Semantic Layer と対をなす 一般 Semantic Layer 製品（Cube / dbt SL / Looker / Unity Catalog Metric Views / OSI）を整理する。