オントロジーとはなにか：PalantirがSOMPOで$60M改善した"データ地図"入門

2026/05/31

こんにちは。仕様書を書かないPM、カイです。

「オントロジーとは何か？」を、PMの実務目線でガッツリ整理します。哲学用語の解説ではなく、「BIダッシュボードで止まっている」「AIを入れたのに社内データと噛み合わない」と感じているPM/PdM、事業企画、スタートアップの経営層に向けて書いてます。

きっかけは、Zennで見つけた1本の記事でした。

なぜ今「オントロジー」なのか？PalantirとLLMが変えるデータ活用の常識

zenn.dev

channnnsmさんのこの記事を読んで、正直ハッとしたんですよ。

私はPMとして、ロードマップを描いたりPRDを書いたりするときに「データはあるのに、意思決定に繋がらない」というモヤモヤをずっと抱えてました。BIダッシュボードを眺めて「で、ここからどうする？」となるあの感覚です。

その違和感の正体が「オントロジーがないから」だと、この記事で言語化されたんですね。

本記事では、元記事のエッセンスをリスペクトしつつ、PMの実務にどう落とすかという視点で再解釈します。PalantirがSOMPOで2025年8月時点の直近3年で$60M（約90億円）の利益改善を実現した事例も交えながら、明日から使える5原則まで一気に解説します。

結論を先に言うと、こうです。

「BIダッシュボードは"読むだけの地図"。オントロジーは"仕事ができる地図"だ」

これがこの記事の通底メッセージです。それでは行きましょう。

1. なぜ今「オントロジー」なのか——2026年のデータ活用の転換点

BI・ダッシュボードで「止まっている」企業の共通課題

PMやってると、よくこんな場面に遭遇しませんか。

経営会議で立派なダッシュボードが映し出される。MAUのトレンド、CVRのファネル、ARPUの推移。数字は綺麗に並んでる。でも会議の最後、誰かが必ず言うんですよ。

「で、結局どうする？」

ここで沈黙が流れる。データはあるのに、次のアクションが出ない。これ、自分は何度も経験してます。

毎週火曜の週次レビューで、前週の数字を30分かけて読み解いて、「じゃあ施策どうする？」ってなった瞬間に「それ、Salesforceで確認してから決めましょう」「CSに聞かないと」「一旦スプレッドシートにまとめます」って話になって、意思決定は翌週に持ち越し——こういうループ、身に覚えありませんか。

このモヤモヤの正体を整理するとこうです。

ダッシュボードは「過去の結果」しか見せてくれない
「数字が動いた原因」を聞こうとすると、別のツール（Salesforce、Slack、社内DB）に飛ばないといけない
意思決定して「アクションを実行」するには、また別のツール（基幹システム）を開く必要がある

つまり、「見る」と「考える」と「動く」が完全に分断されてるんですね。BIはあくまで「見る」専用ツール。だから、ダッシュボードを眺めた後の「で、どうする？」で詰まる。

ここを埋める概念が、オントロジーなんですよ。

AIエージェント普及がオントロジーを必須にした理由

もう1つの転換点が、AIエージェントの普及です。

2025年以降、ChatGPTやClaudeにToolを持たせて社内システムを操作させる、いわゆる「AIエージェント」を本気で実装し始めた企業が一気に増えました。自分の周りのPMも、半数くらいは「社内AIエージェントPoC」みたいなプロジェクトに巻き込まれてます。

ただ、ここで大量に発生してるのが「AIが社内データの意味を理解できない問題」なんですね。

具体例で言うと、こんな感じです。

「先月の解約率を教えて」とAIに聞く
AIは社内DBにクエリを投げる
でも「解約」の定義が3つある（自動更新OFF / 退会申請 / 期限切れ）
AIはどれを返せばいいか分からず、適当に1つ選ぶ
PMが「あれ、数字違くない？」となる

これ、RAGを入れただけでは解決しないんですよ。データに「ビジネス上の意味」が紐づいてないから、AIがハルシネーションを起こす。

つまり、AIに会社のデータを正しく使わせるためには、その前に「データの意味を定義した地図」が必要になる。それがオントロジーです。

ここから本題に入ります。オントロジーという概念、実は「知ってると知らないとでPMのアウトプットが変わる」レベルの話なんですよ。

2. オントロジーとは何か——PMが理解すべき本質的な定義

オントロジーの定義：哲学用語から「ビジネスの地図」へ30秒で理解する

「オントロジーって、なんか哲学っぽくて難しそう」——そう感じてる人、多いと思います。

オントロジー（Ontology）はもともと哲学の用語で、「存在論」と訳されます。「世の中に何が存在し、それらはどう関係しているか」を扱う学問領域ですね。

PMがこの語源を覚える必要はありません。重要なのは、ビジネス文脈での意味です。

PMにとってのオントロジーを30秒で定義すると、こうです。

オントロジー＝会社にとっての「顧客」「契約」「案件」が何を意味するかを定義し、それらの関係性とアクションをひとつの地図にまとめたもの。

たとえば「顧客」という言葉。営業は「商談中のリード」を顧客と呼ぶし、CSは「契約済みアカウント」を顧客と呼ぶし、経理は「請求先」を顧客と呼ぶ。同じ言葉なのに、部署ごとに指してるモノが違うんですよ。

これ、エンジニアとの仕様詰めでも毎回発生しませんか。「ユーザーっていうのは、ここでは誰のことですか？」「ログインしてる人ですか、会員登録した人ですか？」——PMが「え、そういう話だったっけ」ってなるアレです。

オントロジーは、この「会社の中で言葉と実体の対応を1枚の地図にする」作業のことです。

Palantirの公式ドキュメントでは、オントロジーは組織のオペレーション層であり、多くの場面において組織のデジタルツインとして機能する、と表現されています。

@Palantir Foundryのオントロジー解説を読むと、データセットやモデルといった「デジタル資産」を、現実世界の「モノ」（工場、機器、顧客注文、金融取引）と接続する層だと書いてあります。

Palantir

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。 Palantir オントロジー...

www.palantir.com

データベースのテーブル定義ではなく、「会社という組織がデジタル空間にもう一度立ち上がっている状態」を作るための地図、ということですね。

DBスキーマ・ナレッジグラフとオントロジーの違い（PM向け対比）

「それってDBスキーマと何が違うの？」と思ったPMの方、鋭いです。自分も最初そう思いました。

PMが押さえるべき違いを、ざっくり対比すると以下です。

概念

主な目的

誰が読む？

アクションを持つ？

DBスキーマ

データを正しく保存する

エンジニア

持たない

ナレッジグラフ

データ間の関係を可視化する

データサイエンティスト

持たない

オントロジー

ビジネスを動かすための地図

PM・現場・AI

持つ（書き込み可能）

ここがミソなんですが、オントロジーの最大の特徴は「アクションを持つ」ことなんですよ。

DBスキーマは「テーブル定義書」、ナレッジグラフは「関係性の図」。どちらも見るための情報設計です。でもオントロジーは違って、「このオブジェクトには、こういう動詞（アクション）を実行できる」が組み込まれてる。

たとえば「顧客」オブジェクトに対して、「契約を更新する」「請求を保留する」「担当営業を変更する」といったアクションが、地図そのものに紐づいてるイメージです。

「見る」だけじゃなく「動かす」設計になってる。これがオントロジーの本質です。これがどう実務を変えるか、次のセクションで具体的に見ていきましょう。

3. BIダッシュボードとオントロジーの決定的な違い

BIダッシュボードは「Read Only」、オントロジーは「Read/Write」

ここからが、PMにとっていちばん大事なパートです。

BIダッシュボードとオントロジーの違いを、エンジニアっぽく言うと「Read Only」と「Read/Write」の違いなんですよ。

BIダッシュボード

オントロジー

データ操作

Read Only（見るだけ）

Read/Write（見て、書き戻せる）

ユーザー行動

「数字を見て会議する」

「数字を見て、その場で決定し、システムに反映する」

業務との関係

業務の外側で動く（分析ツール）

業務の中で動く（運用層）

AIとの相性

データを見せるだけ

AIにアクションを実行させられる

元ネタのZenn記事で、channnnsmさんがめちゃくちゃ秀逸な対比を示していました。

BIツール: 売上が落ちている事実を確認して終わる。アクションは別システムへ移動する必要がある
オントロジー: 売上低下に気づいたその画面で、発注などのアクションまで完結する

これですよ、これ。

PMの感覚で言うと、ダッシュボードは「報告書」で、オントロジーは「ハンドル」みたいなものです。報告書を見ても車は動かないけど、ハンドルを握れば動かせる。

「見るだけ」から「動ける」データ基盤へ

もう少し具体的にPMの実務に引きつけてみます。

たとえば、サブスクサービスのChurn（解約）対策を考えるシーンを想像してください。

BIの世界（よくあるPMの月曜朝）:

ダッシュボードでChurn率を見る → 「先月3.2%、悪化してる」
別タブでSalesforceを開いて、解約理由の自由記述を読む → 「価格面が多そう」
SlackでCSチームに「重点フォロー対象のリストください」と依頼 → 翌日返信
その後、自分でスプレッドシートに整理 → PRDを書く → エンジニアに相談 → リリースまで2週間

ここまでの工程、PMの体感として「3日くらい潰れる」感じです。自分も身に覚えがあります。

オントロジーの世界:

オントロジーで「解約リスクが高い顧客一覧」を開く → AIが既に予測スコア付き
「高リスク顧客」オブジェクトに対して「フォロー施策を実行する」アクションをクリック
CSへのアサイン、メール配信、Slack通知が一気に走る
結果は同じ画面でリアルタイムに反映

「データを見る場所」と「仕事をする場所」が統合されてるんですよ。

これがオントロジーが「仕事ができる地図」と呼ばれる理由です。BIが地図帳なら、オントロジーはGoogleマップで「ルート案内→ナビ開始」までやってくれる、と言うとイメージしやすいかもしれません。

このBefore/Afterの違いが「概念の話」ではなく「実際の現場で起きている」と証明したのが、次のSOMPO事例です。

4. Palantir Foundryが証明したビジネスオントロジーの実力

Palantir×SOMPOのオントロジーで3年$60M改善した仕組み

「で、それって本当に効果あるの？」というPMの方、ここが楽しいパートです。

代表事例が、PalantirとSOMPOホールディングスのパートナーシップです。

Palantirの公式SOMPO事例ページや複数の報道によると、SOMPOは2025年8月時点の直近3年間で約$60M（約90億円）の利益改善を実現しました。さらに今後3年で追加$100M（約150億円）の改善が見込まれてます。

Sompo | Palantir

PalantirはSOMPO社と共同でPalantir Foundryを基盤にリアルデータプラットフォーム (RDP) を構築しました。

www.palantir.com

$60M、約90億円です。中堅スタートアップなら年商が丸ごと改善したレベルの数字ですよ。これが「概念実証」ではなく「3年間の本番運用」から生まれてる。

具体的に何をやったかというと、保険金請求プロセスを「エンドツーエンドで再設計」したんですね。

不正検知（Fraud Detection）
請求の優先度付け（Triage）
継続モニタリング
アンダーライティング（引受判断）の自動化

これら全部をPalantir Foundry上で支えて、保険金請求プロセス全体を「ひとつの仕事ができる地図」として再構築したわけです。

特に注目すべきは、日本のSOMPOで8,000人以上の社員がこのプラットフォームを日常業務で使ってることなんですよ。

8,000人ですよ。PoCで終わってる事例じゃなくて、本番運用で組織全体が動いてる。

PMの目線で見ると、これは「機能のリリース」ではなく「業務OSの入れ替え」レベルの話です。元ネタ記事で言われていた「『現場の手作業』が『オントロジー上のアクション』に置き換わった」という表現が、まさにこの実態を捉えてます。

提供：Palantir Technologies

富士通×Palantirが示す日本市場の本格展開フェーズ

もう1つ、私が注目している動きがあります。

Palantirとの戦略的なグローバルパートナーシップを強化し、企業における生成AIの業務実装と業務変革支援を加速

当社は、Palantir Technologies Japan株式会社と、生成AIを容易に業務に組み込むためのプラットフォーム「Palantir AIP」（Artificial Intelligence Platform、以下、Palantir AIP）に関するライセンス契約を2025年8月5日に締結しました。本契約により、当社は「Palantir AIP」を国内外のお客さまに提供できるようになるとともに、「Fujitsu Uvance」のオファリングへ組み込み提供することが可能となります。これにより、当社は、お客さまの業務における生成AIの実装や経営の意思決定の高度化を支援し、業務変革に貢献します。

global.fujitsu

Palantirとの戦略的なグローバルパートナーシップを強化し、企業における生成AIの業務実装と業務変革支援を加速

このパートナーシップで富士通は、2029年度末までに約$100M（約150億円）の売上を目標として掲げています。

私がこの発表で注目したのは、数字の大きさだけじゃないんですよ。

日本のSIerの巨頭がPalantir Foundryを取り込んで、自社の業務SI領域にビジネスオントロジーの実装を持ち込もうとしている。これはオントロジーが「理屈の話」から「日本企業の現場ツール」に降りてきたサインだと読んでいます。

PRDでベンダー選定や全社データ基盤の議論をするとき、これまで「オントロジー基盤を入れる」という選択肢は、外資系大企業か先進的なスタートアップの話でした。でも今は、富士通経由でそれが日本の中堅・大企業の実装オプションになろうとしている。

自分の周りのPMでも「次のデータ基盤どうする」という議論が増えてますが、その文脈にオントロジーという観点を入れておくのは、2026年以降のPMとして素直にアリだと思ってます。

では、実際にPMがどう動けばいいか。ここからが実践編です。

5. オントロジーとAIの関係——ハルシネーションを減らし実務に使う仕組み

AIが社内データの「文脈」を誤解する理由

AI活用に取り組んでるPMなら、一度はこの壁にぶつかってると思います。

「ChatGPTは超賢いのに、社内データを渡した瞬間にハルシネーションが激増する」

原因はLLM側にあるんじゃなくて、社内データに「意味」が紐づいてないからなんですよ。

たとえば、こんなテーブルがあるとします。

customers
- id: 12345
- name: "株式会社A"
- status: "C"
- updated_at: "2026-05-30"

AIにこのテーブルを渡して「アクティブな顧客を教えて」と聞いても、status: "C"が何を意味するか分からない。Cは「Cancel（解約）」かもしれないし、「Contract（契約中）」かもしれない。

人間のベテラン社員は、Cを見た瞬間に「あ、これは契約中だな」と分かる。でもAIには分からない。なぜなら、社内で共有されてる「Cは契約中を意味する」という暗黙知が、データに書かれてないからです。

これがハルシネーションの正体です。LLMが嘘をついてるんじゃなくて、「文脈が書かれてないから推測するしかない」状態なんですね。

「それ、AIに壁打ちした？」って聞く前に、そもそもAIに渡す「地図」が整ってるかどうか——これを先に確認するのが、AI時代のPMの仕事だと思ってます。

オントロジーはAIへの「業務マニュアル」である

ここでオントロジーが効いてきます。

オントロジーは、データ自体に「ビジネス上の意味」を埋め込む設計です。先ほどの例で言うと、こんな感じになります。

顧客（Customer）オブジェクト
- ID: 12345
- 名称: 株式会社A
- ステータス: 契約中（"C"="Contract"）
- 補足: ステータスは "C"=契約中, "X"=解約, "P"=保留 を意味する
- 関連アクション: 契約更新, 請求保留, 担当変更
- 注意: 売上集計時は税抜き、返品分は除外する

これをAIが読むと、status: "C"を「契約中の顧客」と正しく理解できるし、「契約更新」というアクションを実行できる、と認識します。

channnnsmさんの記事で印象的だったのが、この一節でした。

「新入社員に教えるように、AIにも説明を書く」

これ、めちゃくちゃ的を射てるんですよ。

新人がジョインしたとき、PMは何をやるか。データの読み方、用語の定義、暗黙のルール、関連部署の連絡先を「業務マニュアル」として渡しますよね。オントロジーは、まさにAI向けの業務マニュアルです。

一般的な役割の違いとして言えば、RAGが「社内ドキュメントをAIに渡す」仕組みなら、オントロジーは「社内データに業務文脈を埋め込む」仕組みです。前者は知識検索、後者は実行基盤。役割が違うんですよ。

ハルシネーション対策でRAGを入れてるPMの方、それだけでは限界があります。データに意味を埋め込む設計がないと、AIは結局推測で答えるしかない。ここがオントロジーが必要な理由です。

理解が深まったところで、実際にPMが明日から使える原則に落としていきましょう。

6. PMが明日から実践できる「オントロジー思考」5原則

ここからは、Palantir Foundryのような本格的なオントロジー基盤がなくても、PMが明日から思考のフレームワークとして使える5原則を紹介します。

元ネタのchannnnsmさんの5原則をベースに、PM実務の言葉で再解釈してます。

原則1：オントロジー的対象化——テーブルではなく「モノ」で考える

失敗あるある: PRD書くとき、つい「usersテーブルにlast_loginカラムを追加する」みたいなDBスキーマ起点で書いてしまう。エンジニアと話すと「それuserじゃなくてsessionの話じゃない？」と齟齬る。

原則: データを「テーブル」ではなく「ビジネス上のモノ」として捉える。usersではなく「顧客」、ordersではなく「注文」「契約」「請求」と分けて考える。

PM実務での使い方: PRDの冒頭に「登場する主要オブジェクト」セクションを設けて、ビジネス用語で書き出す。

登場オブジェクト
- 顧客: ログイン可能な利用者（法人/個人を含む）
- 契約: 顧客と弊社の間の月額利用合意
- 請求: 契約に基づき毎月発生する支払い義務

これ、エンジニアとの会話が劇的にスムーズになります。私は今、PRDテンプレに「登場オブジェクト」セクションを必ず入れてます。

「前から欲しいと思ってたやつだ」ってエンジニアに言ってもらえると、ちょっと嬉しいんですよ。

原則2：アクション設計——データに「動詞」を紐づける

失敗あるある: 機能仕様を書くとき、画面とデータ構造ばかり考えて「ユーザーが結局何のアクションを取りたいのか」が曖昧になる。

原則: オブジェクトに対して「実行可能な動詞」を必ずセットで設計する。「顧客」だけじゃなく「顧客に対して何ができるか」までを地図に書く。

PM実務での使い方: オブジェクトごとに「許可アクション一覧」を作る。Marty Caganさんが言う「Outcome指向のプロダクト設計」を実装する具体策として、これが効きます。

顧客に対する許可アクション
- プラン変更（誰が？: CS or 本人）
- 契約一時停止（誰が？: CSのみ、要承認）
- 支払い方法更新（誰が？: 本人のみ）

これを書いておくと、後で「この機能、誰が使えるんだっけ？」という議論が一発で終わります。

原則3：メタデータ充実——AIが読める「文脈」を書く

失敗あるある: ダッシュボードの売上数字を見て「あれ、これって税込？税抜？返品分は引いてある？」とSlackで聞きまくる。毎月。

原則: データに「定義」「除外条件」「集計ルール」をメタデータとして書く。人間にもAIにも読める形式で。

PM実務での使い方: 各KPIの横に「定義書」を必ず添える。本当に1行でいいから書く。

MAU（月間アクティブユーザー）
- 定義: 当月に1回以上ログインしたユーザー
- 除外: 社内テストアカウント、退会者
- 注意: タイムゾーンはUTC+9で集計

これがないと、AIに「先月のMAUを教えて」と聞いた瞬間にズレた数字が返ってくるんですよ。AI時代のPMにとって、メタデータの整備は「コードを書かないコーディング」だと思ってます。

原則4：データ名寄せ——複数システムの「同一存在」を統一する

失敗あるある: Salesforceの「Account ID」、基幹システムの「顧客コード」、決済システムの「Customer ID」が別々。同じ会社なのに、システムごとにIDが違って集計できない。

原則: 別システムにある「同じ実体」を1つに統合する。単純な文字列一致ではなく、ビジネスロジックで判定する。

PM実務での使い方: 主要オブジェクト（顧客、契約、商品）について「マスターIDは何か」を定義する。「Single Source of Truth」をどこに置くか、PMが決め切る。

「うちはSalesforceを顧客マスターにする。他システムは全部そこに紐づける」みたいな判断ですね。技術判断に見えて、これは完全にPM/事業の意思決定です。

ここを曖昧にしたまま走り出すと、後で必ず数字が合わなくなって地獄を見ます。自分も過去にやらかしてます。

原則5：オントロジーの段階的実装——1つのドメインから始める

失敗あるある: 「全社データを統合する大プロジェクト」を立ち上げて、半年経っても何も動かない。気がつくと予算だけ消えてる。

原則: 全社統合から始めない。「1つのユースケース」「1つのドメイン」から始めて、価値を出してから広げる。

PM実務での使い方: 最初のオントロジー対象を1つに絞る。「カスタマーサポートの問い合わせ対応」とか「営業の商談管理」とか、明確に範囲を切る。

channnnsmさんの言葉を借りると、こうです。

「全社のデータを統合した完璧なオントロジーを作ろうとすると100%失敗する」

PMの感覚で言うと、これはOpportunity Solution Tree（OST）の考え方そのものなんですよ。

Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes

Opportunity solution trees help product teams chart the best path to their desired outcome. They keep the team aligned as they manage the messy cycles of continuous discovery. In this article, we’ll cover what an opportunity solution tree is, the benefits of using one, how to create one, and

www.producttalk.org