「全社で数字の定義を揃えたい」という相談を受けると、提案として出てくる選択肢がばらつきます。データカタログを入れましょう、セマンティックレイヤーを整備しましょう、オントロジーを作りましょう。どれも間違いではないものの、解く課題が違うため、症状に合っていなければ動かないまま終わります。
3つの役割の違いを、実際に困っている場面から逆算して整理します。
役割の違いを1枚で
| データカタログ | セマンティックレイヤー | オントロジー | |
|---|---|---|---|
| 主な目的 | どこに何があるかを探せるようにする | 指標の定義を1か所に揃える | 業務の対象と操作を定義する |
| 扱う対象 | テーブル、カラム、所有者、来歴 | 指標、ディメンション、集計ロジック | オブジェクト、リンク、アクション |
| 読み書き | 読み取り（メタデータ） | 読み取り | 読み取りと書き戻し |
| 主な利用者 | データ担当者、分析者 | 分析者、BI利用者 | 業務担当者 |
| 解く症状 | 欲しいデータが見つからない | ツールごとに数字が違う | 判断したあとの実行が手作業 |
分かれ目は最下段です。困っているのが「探せない」ならカタログ、「数字が合わない」ならセマンティックレイヤー、「気づいた後の作業が重い」ならオントロジー型の設計になります。
症状から選ぶ
欲しいデータがどこにあるか分からない
担当者に聞かないとテーブルの意味が分からない、似た名前のテーブルが並んでいて選べない。この状態ならカタログが効きます。ただしカタログは、入力と更新が回らないと半年で使われなくなります。導入より運用設計のほうが重い施策です。
会議で数字が食い違う
営業が出した売上とBIの売上が合わない、部署ごとに「解約」の数え方が違う。この場合はセマンティックレイヤーで定義を1か所に集約します。ここで大事なのは、ツールを入れる前に、どの定義を正とするかを決める権限を誰が持つかを決めておくことです。
気づいた後の作業が手作業のまま
ダッシュボードで異常を見つけたあと、別のシステムを開いて確認し、担当者に依頼を出し、実施記録を手で入れている。ここが重いなら、業務の対象と操作を定義する設計が効きます。Palantirのアクション型は、オブジェクトやプロパティ、リンクへの変更を一度の操作として定義し、変更は書き戻し用データセットに取り込まれます（Action types / Overview）。
3つは排他ではない
順番として現実的なのは、定義を揃える取り組みを先に済ませることです。用語と指標の定義が固まっていないまま業務操作を定義しても、どの定義に対して操作しているのかが曖昧になります。
| 段階 | やること | 完了の目安 |
|---|---|---|
| 1 | よく使う指標の定義を書き出し、正とする定義を決める | 会議で数字の食い違いが起きない |
| 2 | 主要なテーブルに意味と所有者を付ける | 担当者に聞かずにデータへ辿り着ける |
| 3 | 対象業務を1つ選び、その業務の対象と操作を定義する | 判断から実行までが1画面で完結する |
段階1と2を飛ばして3から入ると、作った仕組みが特定の部署でしか使えないものになりがちです。定義が揃っていない状態で操作だけを作ると、その部署の解釈に合わせた画面ができあがり、他部署に展開する段階で作り直しになります。
逆に、段階1と2で止まってしまう企業も多くあります。定義とカタログが整った時点で「データ整備は終わった」と見なされ、現場の作業は手作業のまま残ります。整備そのものは成果ではなく、判断と実行が変わって初めて投資が回収されます。段階3に進む条件を、着手時に決めておいてください。
段階1を実際にやってみる：指標3つの定義を確定する
抽象的な手順だと動けないので、記入例まで置きます。使うのは1枚の表だけです。
| 指標 | 正とする定義 | 対象外にするもの | 決めた人 | 確定日 |
|---|---|---|---|---|
| 月次売上 | 検収が完了した月に計上。税抜 | 受注済みで未検収のもの、社内取引 | 経営企画部長 | 2026-09-05 |
| 解約率 | 当月末の契約社数 ÷ 前月末の契約社数 で算出した減少分 | 無料期間中の離脱、契約の一時停止 | カスタマーサクセス責任者 | 2026-09-05 |
| 商談化率 | 初回商談を実施した件数 ÷ 有効リード数 | 名刺交換のみ、既存顧客からの問い合わせ | 営業本部長 | 2026-09-12 |
この表で重要なのは4列目です。定義を書くこと自体は難しくありません。もめるのは「誰の定義を正とするか」で、決め役が空欄のままだと、半年後に同じ議論が再燃します。
会議での切り出し方も決めておくと進みます。「この指標の定義、いま部署ごとに違っていると思います。今日はどれが正しいかではなく、誰が決めるかだけ決めさせてください」と最初に言うと、定義論争に入らずに進行できます。
3指標が固まったら、BI・スプレッドシート・基幹の帳票のうち、少なくとも2か所で同じ数字が出ることを確認します。ここまでが段階1の完了条件です。
よくある失敗
| 失敗 | 何が起きるか | 避け方 |
|---|---|---|
| ツール選定から入る | 要件が固まらないまま比較表だけが増える | 直近の困りごと5つを先に書き出す |
| 全指標を一度に定義しようとする | 合意形成が終わらず、着手前に熱が冷める | 3指標に絞る |
| 決め役を決めない | 定義が何度も蒸し返される | 指標ごとに1人を決めて表に書く |
| カタログを入れて終わりにする | 入力が更新されず半年で使われなくなる | 更新の担当と頻度を導入前に決める |
| 分析者だけで進める | 現場が使わず、判断が変わらない | 対象業務の担当者を最初から入れる |
4つ目は特に多く見られます。カタログは導入より運用のほうが重い施策で、更新が止まった時点で価値がなくなります。誰が、どの頻度で、何をきっかけに更新するかを、導入を決める前に書いておいてください。
よくある質問（FAQ）
Q. セマンティックレイヤーがあれば、オントロジーは不要ですか。
分析までが目的なら不要です。判断のあとの実行まで含めたいときに、扱う範囲が変わります。Palantir公式の定義でも、アクション型は変更操作を定義するもので、読み取り側の仕組みとは対象が異なります。
Q. どれから着手すべきか、社内で意見が割れています。
直近3か月で実際に起きた困りごとを5つ書き出し、上の表の「解く症状」に当てはめてください。分布が偏った先が、いま着手すべき対象です。ツールの比較から入ると結論が出ません。
Q. 小さく始める方法はありますか。
あります。指標を3つに絞って定義を確定し、その3つだけをどのツールから見ても同じ数字になる状態にします。これだけでも会議の進み方は変わります。範囲を広げるのはその後で構いません。
Q. 定義を決める権限を、誰に持たせるべきですか。
その指標を使って意思決定する人に持たせるのが原則です。売上の定義なら経営企画、解約率ならカスタマーサクセスというように、数字で判断を下す立場の人が決めます。データチームが決めると、現場が納得しないまま運用が始まり、別の集計が裏で作られます。
Q. 定義を変更したくなったときは、どうしますか。
変更そのものより、いつから変わったかを残すことが重要です。定義を書いた表に変更日と変更理由の行を足し、過去の数字を遡って作り直すかどうかを明示してください。ここを決めずに変えると、前年比が意味を持たなくなります。
出典
- Palantir 公式ドキュメント「Ontology — Core concepts」（2026-08-21 参照）
- Palantir 公式ドキュメント「Action types — Overview」（2026-08-21 参照）
本記事の定義部分は上記一次情報にもとづきます。判断や見解の部分は当社によるものです。
どれが自社の症状に合うかは、実際の困りごとを並べてみると短時間で決まります。困りごとの棚卸しから、初回相談（30分・無料）で整理できます。