Palantir オントロジー — データの上に「行動」を載せた運用層を公式文書で読む

「オントロジー」という語が指すもの

Palantir の文書でオントロジー（Ontology）は学術用語ではなく 製品の一つの層 だ。概要文書はこう定義する。

The Ontology is an operational layer for the organization. The Ontology sits on top of
the digital assets integrated into the Palantir platform (datasets and models) and
connects them to their real-world counterparts, ranging from physical assets like
plants, equipment, and products to concepts like customer orders or financial transactions.

データレイクにはテーブルがあり、モデルレジストリにはモデルがある。オントロジーはその二つの上に「工場」「注文」「取引」のような 現実の名前 を付け、その名前に対して何ができるかを定義する層だ。文書が明かす投資の目的は一文だ。"The goal of investing in the Ontology is to facilitate better decision-making in an organization at scale."

この記事はその層がどう構成されるかを、Palantir 公式文書（palantir.com/docs/foundry）の文だけでたどる。文書にないことは書いていない。

六つの部品 — 意味と運動

概要文書はオントロジーの構成要素を二つの群に分ける。組織の 意味（semantics） を定めるものと 運動（kinetics） を定めるものだ。

Defining the semantics of your organization happens by mapping existing datasources
into objects, properties, and links in the Ontology.

The kinetics of the organization—enabling change while complying with organizational
controls and governance—are defined in the Ontology using action types and functions.

コア概念文書の定義をそのまま写すと六つの部品になる。

部品	公式の定義
オブジェクトタイプ（object type）	"the schema definition of a real-world entity or event"
プロパティ（property）	"the schema definition of a characteristic of a real-world entity or event"
リンクタイプ（link type）	"the schema definition of a relationship between two object types"
アクションタイプ（action type）	"the schema definition of a set of changes or edits to objects, property values, and links that a user can take at once"
関数（function）	"a piece of code-based logic that takes in input parameters and returns an output"
インターフェース（interface）	"an Ontology type that describes the shape of an object type and its capabilities"

データベースに慣れた人のために文書は対応表も示す。データセットはオブジェクトタイプに、行はオブジェクトに、列はプロパティに、結合はリンクタイプに対応する。つまり前の三つ（オブジェクト・プロパティ・リンク）までは「よく整理されたスキーマ」だ。Palantir が他のデータプラットフォームと分かれるのは後の三つで、スキーマの上に 人ができる行動（アクション） と コードで書いた論理（関数） を同じ層に置く。

データセットがオブジェクトになる道

オブジェクトタイプはどこからデータを受け取るのか。オブジェクトタイプ概要文書は二つの経路を挙げる。

Objects are created and displayed in user applications by adding backing datasources
or configuring actions that create objects of an object type in Ontology Manager.

つまり (1) 既存のデータセットを backing datasource として付けるか、(2) データセットなしでアクションだけでオブジェクトを作るかだ。文書は従業員（Employee）オブジェクトタイプに社内ディレクトリのデータを付ける例を挙げ、逆に「すべてのオブジェクトをアクションで作るなら backing datasource なしでオブジェクトタイプを作れる」と書く。

データセットがオブジェクトに索引される過程は Object Storage v2 の Funnel が担う。

Funnel reads data from Foundry datasources (such as datasets, restricted views, and
streaming datasources) and user edits (from Actions) and indexes these data into
object databases. Funnel also ensures that indexed data is kept up-to-date as the
underlying datasources update.

重要な句は "user edits (from Actions)" がデータセットと 並んで 入力だということだ。原本のテーブルから来た値と、人が画面で直した値が同じ索引に入る。では衝突したらどちらが勝つのか。

編集が原本と衝突したときの規則

ここがオントロジーを「読み取り専用ビュー」と分ける核心で、文書は規則を明示する。

the final state of an object is always determined by the user edits applied to it,
regardless of any future datasource updates for edited properties in the same object.

既定の戦略では ユーザー編集が常に勝つ。 人が直したプロパティは、原本のデータセットが後で変わっても上書きされない。ただし直していないプロパティは原本の更新をそのまま受ける（"An unedited property receives data update from the input datasource, and it is applied to the object"）。

削除は編集ではない。"Deletions are not considered an edit. Once a deletion is applied, the object is no longer visible regardless of datasource state." そして同じキーでオブジェクトが再び作られても以前の編集は引き継がれない（"If the object is later recreated, it will not inherit the previous edits"）。

編集専用プロパティ（edit-only property）はさらに強い。代替戦略（「最新の値を適用」）を選んでも "user edits will always apply regardless of the timestamp on the input datasource" だ。

この規則がなぜあるのか。現場の担当者が「この設備は点検済み」と印を付けたのに、夜に原本システムから古い状態が再び降りてきて印が消えれば、オントロジーは誰も信じない画面になる。編集が勝つ規則はその信頼を守る装置だ。代わりに原本で本当に変わった値が無視されうるので、どのプロパティを編集可能にするかが設計の核心になる。

アクション — トランザクション、検証、副作用

アクションタイプ文書はアクションをこう捉える。

An Action in Foundry is a single transaction that changes the properties of one or
more objects, based on user-defined logic.

アクション一つはオブジェクト・プロパティ・リンクの変更の束で、パラメータで入力を標準化し、提出条件で権限を検査する。文書の例は「人事部門のような権限のある従業員だけがこのアクションを実行できるよう検証」し、提出時に「関連オブジェクト間のリンクを自動で作る規則」を含むものだ。副作用（side effect）には通知とウェブフックがあり、例は「旧マネージャと新マネージャに変更を知らせる通知」だ。

そしてこの文が、アクションがなぜオントロジーにあるのかを語る。

the same action logic and validations can be made available across all user-facing
applications, ensuring consistent edits.

画面ごとに別に書いた「保存ボタン」ではなく、オントロジーに一度定義したアクションをすべての画面が同じ検証で使う。規模の上限も文書にある。アクション一つが編集できるオブジェクトは既定で 10,000 個 で、より大きな値は申請で開かれる。

関数 — サーバーで動く論理

関数文書は言語を二つに固定する。"The languages supported by functions are TypeScript and Python." 関数はオントロジーを一級で扱う。

This includes support for reading the properties of various object types, traversing
links, and flexibly making Ontology edits.

用途として文書が挙げるのは四つだ。Workshop（Palantir のアプリビルダー）にオブジェクト集合や値を返す、「多くのオブジェクトを更新する複雑な編集を関数ベースのアクションとして表現する」、派生列に変換値を表示する、グラフ用に集計する。実行モデルは "executed on the server side in an isolated environment" で、言語モデルと組み合わせるときのために「結果を逐次ストリーミング」できる。

インターフェース — 多態性

インターフェースは複数のオブジェクトタイプに同じ形を共有させる。文書の例は Facility インターフェースに位置・名前などの共通プロパティを置き、Airport・Manufacturing Plant・Maintenance Hangar がそれを実装するものだ。すると "workflows can interact with Airport, Manufacturing Plant, and Maintenance Hangar object types, either in aggregate or independently" となり、新しいタイプがインターフェースを実装した瞬間に既存のワークフローに入ってくる。インターフェースのプロパティは "defined locally on the interface (recommended) or using shared properties" で定義し、一つのオブジェクトタイプが複数のインターフェースを実装できる。

規模とアーキテクチャ — 数字で

Object Storage v2 文書が明かす数値はこうだ。

項目	文書の数値
オブジェクトタイプ一つの索引スループット	"on the order of tens of billions of objects for a single object type"
オブジェクトタイプあたりのプロパティ上限	2,000
アクション一つの編集オブジェクト数（既定）	10,000
増分索引	すべてのオブジェクトタイプで既定で有効
OSv1（Phonograph）の廃止	2026 年 6 月 30 日

v2 の設計の要点は一文だ。"by separating the subsystems responsible for indexing and querying data, Object Storage v2 can scale horizontally more easily to meet future needs." 索引する側と問い合わせる側を切り離したということだ。

モデルと LLM はどこに付くのか

モデル文書はオントロジーの上でモデルを運用する順序を四つで書く。モデルを作り、直接デプロイ（direct model deployment）を構成し、「モデルを包む単純なラッパー関数を公開」してから、その関数を Workshop のようなユーザーアプリでリアルタイム推論に使う。モデルの結果は "real-world concepts (properties of an object type)" として定義される。予測値が別の技術的成果物ではなくオブジェクトのプロパティになるということだ。

LLM 側は AIP だ。AIP Logic 文書の定義は "a no-code development environment for building, testing, and releasing functions powered by LLMs" で、その関数は入力に "Ontology objects or text strings" を受け取り "return an output (objects and/or strings) or make edits to the Ontology" する。つまり LLM が作った論理も結局関数という同じ部品でオントロジーに入り、編集はアクションと同じ経路を通る。AIP 概要はこれらの道具が "production-ready AI-powered workflows, agents, and functions on top of the Ontology" を作ると書く。

開発者には SDK

Ontology SDK（OSDK）文書は対応経路をこう書く。"The OSDK supports npm for TypeScript, pip or Conda for Python, Maven for Java, and OpenAPI spec for any other language." オントロジーから関数と型を生成し、トークンは "scoped only to the ontological entities you want your application to access" だ。オブジェクトタイプがそのままコードの型になるので、オントロジーを直したら SDK を再生成するのが開発の流れの一部になる。

エンジニアの目で読み直す

Palantir オントロジーを一行で要約すれば 「スキーマ＋編集規則＋行動定義＋論理を一つの層に置いたもの」 だ。耳慣れないが、たいていの社内システムが散らばった形で持っているものだ。テーブルは倉庫に、保存ボタンの検証はアプリごとに、バッチ論理はスケジューラに、予測はノートブックにある。オントロジーはそれを一か所に集め、「誰がどのオブジェクトをどう変えられるか」をその場で定義する。

文書だけでは分からないことも書いておく。編集が勝つ規則が実運用でどんな衝突を生むか、2,000 プロパティや 10,000 編集の上限がどの業務で引っかかるか、Funnel の更新遅延がどれほどかは文書にない。この記事は公式文書が語る範囲で止まる。

出典

この記事の引用はすべて下記の Palantir 公式文書から取った（2026 年 9 月 11 日閲覧、応答 200 を確認）。

이 글의 인용은 전부 아래 팔란티어 공식 문서에서 가져왔다(2026년 9월 11일 열람, 응답 200 확인).