「オントロジー」という言葉を、最近 BI や DWH のベンダーからも聞くようになりました。dbt Semantic Layer、Cube、Databricks Unity Catalog、これらが「意味レイヤー」を提供する、と説明されるようになっています。DX 推進担当のあなたは、「Palantir と何が違うのか」の見極めに困っていないでしょうか。
違いは、「動詞」を持つか、持たないかです。既存の BI/DWH 系オントロジーは「名詞だけ」の読み取り専用で、Palantir の Operational Ontology は「名詞 + 動詞」で書き戻しまで扱える。この記事では、その質的な差と、Operational Ontology を実現する設計思想を整理します。
セマンティックとキネティックの構造
| 要素 | 役割 | 業務例 |
|---|---|---|
| セマンティック（意味・名詞） | オブジェクトとリンク：業務の登場人物と関係 | 「注文」「顧客」「在庫」、注文と顧客の関連 |
| キネティック（動き・動詞） | アクションとファンクション：業務の操作と業務ルール | 「注文をキャンセルする」「在庫を引き当てる」（ルール込み） |
Palantir 自身の公式ドキュメントでも、この 2 要素で説明されています。オブジェクトを「名詞」、アクションを「動詞」に見立て、両者が揃うことで「操作できるオントロジー（Operational Ontology）」が成立する、という整理です。
読み取り専用オントロジーの限界
BI 系のセマンティックレイヤー（dbt Semantic Layer、Cube 等）は、名詞だけの世界です。指標定義や項目名を全社で揃え、「売上」の定義を統一する。これは重要ですが、Read Only の範囲です。
| 観点 | セマンティックレイヤー | Operational Ontology |
|---|---|---|
| 扱う要素 | オブジェクト + リンク（名詞） | オブジェクト + リンク + アクション + ファンクション |
| データフロー | 一方通行（分析先へ） | 双方向（分析先 ↔ 業務システム） |
| 業務ルール | 持たない | アクションに組み込む |
| 代表製品 | dbt Semantic Layer、Cube、Looker LookML | Palantir Foundry |
| 向く用途 | 分析・レポート | 分析 + 業務操作 |
読むだけで足りるならセマンティックレイヤーで十分。「気づいて、次の一手を打つ」まで一気通貫で欲しいなら、Operational Ontology の設計が要ります。
Read/Write の閉ループの実装
Operational Ontology を Foundry で実現する場合、書き込み経路は次のように設計されます。
| 経路 | 内容 | 設計思想 |
|---|---|---|
| 読む方向 | 業務システム → データパイプライン → オントロジー → アプリ | 既存の DWH + BI と同じ流れ |
| 書く方向 | アプリ → アクション → オントロジー → 業務システム（Write-back） | アクション経由でしか書き込めない、直接書き換え不可 |
| 業務ルール | アクションの中に埋め込まれ、実行前にチェック | 「出荷済み注文はキャンセル不可」等をコードで表現 |
| System of Record | 業務システム側に残す | オントロジーは中間層、真実の所在は基幹システム |
アクション経由の書き込み強制は、モデルの整合性を保つ設計です。Excel のコピーが増殖して「どれが正しい数字か分からない」の対極にあります。
Operational Ontology の実装例
Foundry の Workshop で「Assign Order」というアクションを定義する場合、次のようなコードイメージになります。
担当者が入力できるのはリスト内の従業員のみ、実行時にステータスが自動で「assigned」に切り替わる、実行者と時刻がログに残る、業務システムへの Write-back API が呼ばれる。この 4 つがアクションの中に組み込まれます。担当者が空欄のまま「対応中」といった中途半端な状態は、そもそも作れません。
エンジニア向けの TypeScript ファンクションで、より複雑なルール（複数オブジェクトへの一括更新、条件付きロジック、外部 API 連携）も定義できます。
なぜ Palantir はここまで作り込んだのか
Operational Ontology は、単なる技術ではなくビジネス戦略でもあります。
| 観点 | Palantir 側の意図 |
|---|---|
| 差別化 | 他社の BI/DWH と質的に違う位置を確保 |
| 居座り構造 | 業務ルールがオントロジーに載ると、離脱コストが劇的に上がる |
| 拡大導線 | 1 部門で書き込みが動けば、他部門にも横展開の説得力が出る |
| 学習ループ | 業務ルールを FDE が現場で学び、製品側にフィードバック |
「操作できるオントロジー」は、顧客価値と Palantir の商業戦略の両方を満たす設計です。この構造を理解した上で、代替設計の可能性を検討します。
オープンスタックでの再現可能性
Operational Ontology は、技術的にはオープンスタックで再現可能です。次の組み合わせが標準的な構成になります。
| 層 | オープンスタック製品 | 担う要素 |
|---|---|---|
| セマンティック | dbt Semantic Layer + Cube | オブジェクト、リンク |
| キネティック | Temporal + Custom API | アクション、ファンクション |
| アプリケーション | Retool + Streamlit + カスタム React | 画面と業務フロー |
| Write-back | API層でシステム連携 | 業務システムへの書き戻し |
Foundry の一体化された連続性は失われますが、単一ベンダー依存を避けられます。中堅企業では、この代替構成の方が経済的に噛み合うケースが多くなります。
まとめ
Operational Ontology は、セマンティック（名詞）とキネティック（動詞）を組み合わせて Read/Write の閉ループを生む設計です。読み取り専用のセマンティックレイヤーとは質的に違い、業務システムへの書き戻しまで扱えます。Palantir Foundry の中核価値ですが、オープンスタックでも再現可能で、選択は統合価値と居座り構造のトレードオフになります。
オープンスタックでの Operational Ontology 構築、既存 DWH/BI からの Read/Write 統合への移行、あるいは Palantir 導入後の維持不能問題への対処など、貴社の現状を踏まえた設計は、Empower STKの初回相談でご案内できます。
あわせて読みたい
- Palantir Foundry の実体：オントロジーとリバースドメインモデリング、日本企業のDX文脈で読み解く
- Palantir Foundry を機能分解する：Data Pipeline / Ontology / Application の3階層
- DWH/BI からオントロジーへ：Read Only の限界と、書き戻し（Write-back）の設計
- Palantir 代替のオープンスタック構成：dbt + セマンティックレイヤー + アプリ層で作る Operational Ontology
- セマンティックレイヤーとメトリクス管理：dbt Semantic Layer・Cube・Lightdash の違い
よくある質問
Q. dbt Semantic Layer だけで Operational Ontology は組めますか？
A. 組めません。dbt Semantic Layer はセマンティック（名詞）だけを提供します。アクション（動詞）を追加するには、別途 API 層とアプリ層の設計が必要です。
Q. Databricks Unity Catalog は Operational Ontology ですか？
A. 現時点では違います。Unity Catalog はデータガバナンスと Read 系のメタデータ管理が中心で、業務ルール込みのアクション定義は含みません。Databricks Apps との組み合わせで近づく可能性はありますが、Foundry の Operational Ontology とは設計思想が異なります。
Q. Operational Ontology を組む前に、まず整えるべきものは？
A. データパイプライン層と、その上のセマンティックレイヤー（読み取り専用）を先に組みます。書き戻したい業務が明確になってから、キネティック層を追加する順序が現実的です。いきなり Operational を目指すと、業務ルールの整理が追いつかず失敗します。