はじめに
ダッシュボードを作った。
毎日見てもらうために、メールやSlackで日次配信もするようにした。
...だけど、誰も見てくれていない。
バラバラだったデータをまとめて、せっかくダッシュボードで見やすくしたのに。
この数ヶ月はなんだったんだ。
似たような経験をした人は、意外と多いのではないでしょうか。
もちろん、ダッシュボードに意味がないわけではありません。複雑なデータをまとめあげ、可視化し、今何が起きているのかを把握できる状態にすることには大きな価値があります。
ただ、ダッシュボードにも限界があります。
それは、基本的には「見る」ためのものだということです。
ダッシュボードが見られなくなる理由
ダッシュボードは、異変に気づくためには有効です。
たとえば、次のような変化はダッシュボードで把握できます。
- 売上が下がっている
- 在庫が足りない
- 広告効率が悪化している
ダッシュボードがあれば、このような異変に気づくことはできます。
しかし、問題はその先です。
異変に気づいたあと、実際のアクションはたいてい別の場所で行われます。
- 担当者にSlackで連絡する
- Salesforceを開いて商談を確認する
- Teamsで会議を設定する
つまり、ダッシュボードは「状況を確認する場所」にはなりますが、「業務を進める場所」にはなっていません。
見るだけで終わるものは、日々の業務に組み込まれない。
日々の業務に組み込まれないものは、だんだんと見られなくなる。
オントロジーとは何か
そこで重要になるのが、Palantirの文脈で語られる「オントロジー（Ontology）」という概念です。
Palantir（パランティア）は、企業や行政機関向けに、バラバラに存在するデータを統合し、意思決定や業務アクションにつなげるためのソフトウェアを提供している米国企業です。近年は、生成AIを実際の業務に組み込むための基盤を提供する企業としても注目されています。
ここでいうオントロジーとは、単にデータをきれいに整理するための仕組みではありません。
現実の業務で使われている「顧客」「商談」「製品」といった言葉や、それらの関係性を、デジタル上でも扱える形にしたものです。
もう少し具体的に言うと、会社の中で日々使われている「顧客」「商談」「製品」といった概念を、データ上のオブジェクトとして定義し、それぞれの関係性やルール、操作できるアクションまで含めて整理したものがオントロジーです。
詳しく見ていきましょう。
デジタル世界と現実世界の間にあるズレ
まず前提として、現実世界とデジタル世界の間には大きなズレがあります。
現実世界では、私たちは「顧客」「商談」「製品」といった単位で物事を認識しています。
一方で、デジタル世界、特にデータベースの世界では、情報はテーブル単位で管理されています。
たとえば「製品」という概念ひとつを取っても、DB上では
-
productsテーブル -
product_categoriesテーブル -
product_imagesテーブル -
pricesテーブル -
ordersテーブル -
inventoryテーブル
などに分かれていることが多いです。
エンジニアであれば、それらを結合して「製品」という情報を再構成できるかもしれません。
しかし、業務担当者が普段考えている「製品」は、テーブルの集合ではありません。
商品名、カテゴリ、画像、価格、担当部署、販売チャネルなどがまとまったモノとして認識しています。
つまり、業務で考える単位とDBが保持する単位のズレが、データ活用を難しくしています。
オントロジーは、業務の単位でデータを再構成する
オントロジーは、このズレを埋めてくれます。
テーブル構造をそのまま人間に見せるのではなく、現実の業務で認識されている単位に合わせてデータを再構成します。
たとえば、「製品」というオブジェクトを定義し、その中に商品名、画像、カテゴリ、価格、在庫、関連する注文などを紐づけます。
そうすることで、業務担当者はDBのテーブル構造を知らなくても、「製品」という普段使っている概念を通じて、データを理解し、必要に応じて更新できるようになります。
なお、ここまで「テーブルを結合してオブジェクトを作る」と書いてきましたが、実際のデータソースは同じデータベースの中のテーブルだけとは限りません。
たとえば「顧客」というオブジェクトひとつを取っても、
- 基幹システムの顧客マスタ
- Salesforceの商談データ
- サポートツールの問い合わせ履歴
のように、別々のシステムにまたがった情報から組み上がることがあります。
こうした複数のシステムをまたいで一つのオブジェクトを組み上げることの方が、オントロジーの本質に近いと言えます。（同じDBの中のテーブルを結合するだけなら、エンジニアがJOINすれば済む話。）
オブジェクトは、関係性でつながっている
ここまでは、バラバラのデータを「製品」「顧客」といった業務上の単位にまとめる話をしてきました。
ただ、現実の業務概念は、それぞれが単体で存在しているわけではありません。
「製品」には「担当部署」があり、「注文」がひもづいています。
「顧客」には「商談」があり、その商談には「担当者」がいます。
私たちは普段、こうしたものごとの関係性も含めて業務を理解しています。
オントロジーでは、この関係性も表現します。
オブジェクトを単独で定義するだけでなく、オブジェクト同士をリンクでつなぐのです。
たとえば、顧客オブジェクトと商談オブジェクトをリンクでつなぎ、商談と担当者をつなぎ、製品と注文をつなぐ。
こうして、現実の業務にある「このデータとあのデータは、こういう関係でつながっている」という構造が、そのままデータ側に表現されます。
そして、このオブジェクト同士がリンクでつながっているという性質が、次に説明するように、大きな効果を生みます。
一つの変更が、つながった先まで波及する
オントロジーの強さが分かりやすく出るのは、たとえば「担当者の引き継ぎ」のような場面です。
営業担当者が異動・退職して、ある顧客の担当が別の人に変わったとします。
「担当者を変える」と言うと一見シンプルですが、実際にやることを並べてみると、変更が必要な箇所は驚くほど多くなります。
- Salesforce上の、進行中の商談のアサイン
- 顧客への定期レポートの送付元・送付先
- Slackの通知やメンションの向き先
- 問い合わせ窓口やメール転送の設定
- 契約書・発注書に記載された担当者名
- ダッシュボードの「担当者別」の集計や、目標・クォータの割り当て
しかも厄介なのは、これらがバラバラのシステムに散らばっていることです。
そして多くの場合、引き継ぎ直後の慌ただしい時期に、口頭やメモを頼りに一つずつ手で直していきます。
その結果どうなるか。
ほぼ確実に、どこか漏れます。
顧客が、もういない担当者にメールを送り続ける。
定期レポートが、前任者宛に届き続ける。
重要な通知が、誰にも気づかれないまま流れていく。
これは担当者個人の注意不足というより、構造の問題です。
「この担当者が、どの顧客・どの商談・どのレポートにつながっているのか」という関係性が、どこにも一元的に持たれていない。関係性は、前任者の頭の中にしかないからです。
オントロジーがあると、この構造が変わります。
担当者、顧客、商談、契約、レポート設定、通知設定が、それぞれオブジェクトとして定義され、リンクでつながっています。
ポイントは、「この担当者が、どの顧客・どの商談・どの契約・どのレポートにひもづいているのか」という関係性が、人の頭の中ではなく、データ側に明示的に持たれていることです。
この状態であれば、引き継ぎのときにやることは一つです。
担当者の割り当てを変える。それだけで、つながっている先まで変更が波及します。
- 商談のアサインが切り替わる
- 定期レポートの送付元・送付先が更新される
- 通知のメンション先が変わる
- ダッシュボードの担当者別の集計も、自動的に正しくなる
担当者は、どのシステムのどの画面を直せばいいかを、いちいち覚えておく必要はありません。
「担当者を変える」という業務上の操作をするだけで、関係する箇所が漏れなく更新されます。
ここで効いているのは、オントロジーがオブジェクトをリンクでつないでいるという性質です。
バラバラだったデータが、業務上意味のある関係性でつながっている。だからこそ、一つの変更が、つながった先まで漏れることなく波及していきます。
オントロジーは会社全体の共通言語になる
もうひとつ重要なのは、オントロジーが会社全体の共通言語になるという点です。
会社の中では、同じ言葉が部署ごとに違う意味で使われることがあります。
たとえば、「売上」という言葉ひとつを取っても、部署によって定義が違います。
営業は「受注金額」を売上と呼び、経理は「会計上認識された金額」を売上と呼び、マーケティングは「キャンペーン経由で発生した購入金額」を売上と呼ぶことがあります。
この状態のまま会議をすると、「今月の売上はいくらか」という単純な問いに対して、部署ごとに違う数字が出てきます。
このとき問題なのは、どの数字が正しいかではありません。
多くの場合、「どの定義の売上を見ているのか」が揃っていないことが問題なのです。
曖昧な言葉を、業務で使える定義に分解する
オントロジーを構築すると、この曖昧さを整理できます。
「売上」という曖昧な言葉をそのまま扱うのではなく、たとえば以下のように分けて定義します。
・営業売上 = 受注金額
・注文売上 = 注文確定金額
・会計売上 = 会計基準に従って認識された金額
・広告帰属売上 = 特定キャンペーンに紐づく購入金額
これによって、全員が同じ定義で同じ対象を見ながら議論できるようになります。
部署ごとに使うアプリは異なっていても構いません。営業には商談管理、マーケティングには施策分析、経理には請求・売上認識のアプリが必要です。
重要なのは、それぞれのアプリが、裏側では同じ顧客、同じ製品、同じ商談、同じ契約、同じ売上定義につながっていることです。
つまりオントロジーは、単なるデータ統合でも、単なる可視化ツールでもありません。
現実世界の業務をデジタル上で扱える粒度に変換し、共通の意味を与え、その上で業務アクションを実行できるようにする仕組みなのです。
AI時代のオントロジー
オントロジーの先にある、学習する業務基盤
ここまでが、Palantirの文脈で語られるオントロジーの強さだと私は理解しています。
ただ、この記事で考えたいのは、単に「オントロジーすごい」「Palantirすごい」という話ではありません。
むしろ考えたいのは、その考え方をAI時代の業務改善にどう接続できるのか、ということです。
オントロジーによって、会社の中の顧客、商談、製品、売上、施策が、業務上意味のある単位で整理されます。
これはAIにとっても重要です。
なぜなら、AIが業務に対して意味のある示唆を出すためには、単に大量のテーブルにアクセスできるだけでは足りないからです。
- 「何が何を意味しているのか」
- 「どのデータがどの業務概念に対応しているのか」
- 「どの対象に対して、どのアクションが実行できるのか」
こうした業務上の文脈が整理されていることで、AIは初めて、単なる数値の要約を超えて、業務改善につながる仮説を出しやすくなります。
AIは単なるダッシュボードの上では弱い
AIは、単なるダッシュボードの上では大したことができません。
もちろん、数値の増減を要約したり、異常値を検知したりすることはできます。
しかし、それだけではまだ弱いです。
本当に価値が出るのは、AIが業務上意味のあるオブジェクトを理解し、それらの関係性からパターンを見つけ、具体的な業務改善の示唆を出せるようになったときです。
たとえば、営業活動のデータがオントロジー上で整理されているとしましょう。
顧客、業界、初回商談、提案書、提案内容、価格説明、フォローアップ、担当者、受注、失注理由などが、それぞれ意味のあるオブジェクトとして定義されています。
その状態でAIが分析すれば、次のような示唆が出せるかもしれません。
- 「初回商談から7日以内に、顧客の既存業務フローを図解した提案書を送った案件は、受注率が平均より23％高い」
- 「一方で、価格説明を2回目の商談前に行った案件は、失注率が高い」
- 「特定業界では、導入効果をROIで説明するより、現場工数削減で説明した方が成約しやすい」
こういう示唆は、単なる売上ダッシュボードからは出てきにくいです。
売上が上がった・下がった、商談数が増えた・減った、という結果を見るだけではなく、その裏側にある行動や文脈まで見にいく必要があるからです。
誰が、どの顧客に、どのタイミングで、どんな提案をして、その結果どうなったのか。
こうした情報が業務上意味のある形で整理されているからこそ、AIはパターンを見つけられます。
AIの示唆を鵜呑みにしない
同時にここで重要なのは、AIの示唆をそのまま正解として扱わないことです。
AIは "相関" を見つけるのは得意です。
しかし、それが "因果" なのかどうかまでは簡単には判断できません。
「初回商談から7日以内に提案書を送った案件の受注率が高い」としても、本当に提案書のスピードが原因なのかは分かりません。
もしかすると、そもそも温度感の高い顧客ほど早く提案書を求めていただけかもしれない。
あるいは、優秀な営業担当者がたまたまそういう行動を取っていただけかもしれない。
あるいは、特定の業界や商材に限って有効なパターンかもしれない。
だからこそ、AIの示唆には人間が入る必要があるのです。
AIの示唆を、組織の形式知として育てる
ここから先が、AI時代のオントロジー活用として面白いところだと考えています。
AIが見つけたパターンに対して、現場担当者や管理者が判断する。
「⭕️これは確からしい」
「❌これは偶然っぽい」
「❌これは誤解を生みそうだから却下」
このように、AIが出した示唆を人間がレビューし、使えるものと使えないものに分けていく仕組みが必要になります。
管理者がApprove/Rejectする形でも良いですし、現場担当者のGood/Badのようなフィードバックでも良いと思います。
重要なのは、AIの示唆を一度きりの自動生成コメントで終わらせないことです。
Goodが多い示唆は、他のチームや類似ケースでも参照される。
Badが多い示唆は、表示頻度を下げる。
現場で補足されたコメントは、次の分析や提案に活かされる。
こうした循環が回ると、AIの示唆は単なるレポートではなく、組織の中で検証された知見に近づいていきます。
つまり、AIが仮説を見つけ、人間が業務文脈で判断し、使える知見だけが残っていく。
このプロセスによって、現場の暗黙知が少しずつ形式知化されていきます。
ダッシュボードの先にあるもの
ここまで来ると、データ活用は「分析」で終わらなくなります。
AIが業務データから仮説を見つける。
↓
人間がその仮説を検証する。
↓
有効なものは業務ルールや推奨アクションとして残る。
↓
微妙なものは表示を下げる。
こうした循環ができると、データ活用は単なる可視化ではなく、業務を学習させていく仕組みに近づいていきます。
ダッシュボードは、今何が起きているのかを見るためのものです。
一方で、AIとオントロジーを組み合わせた業務基盤は、「何が起きているのか」だけでなく、「次に何を試すべきか」「その判断は本当に有効だったのか」まで扱える可能性があります。
まとめ：ダッシュボードの先にある、学習する業務基盤
ダッシュボードは、データを見えるようにするための強力な手段です。
ただし、見えるだけでは業務は変わりません。
本当に重要なのは、データを業務の言葉で理解し、そのまま判断やアクションにつなげられることです。
オントロジーは、そのための土台になります。
そしてAIを組み合わせることで、業務データから仮説を見つけ、人間が検証し、有効な知見を組織に蓄積していく循環を作ることができます。
ダッシュボードの次に必要なのは、単にデータを見る仕組みではなく、業務そのものを少しずつ賢くしていく仕組みなのだと思います。
最後に
この記事で書いたような「データを見える化して終わりにしない」仕組みづくりは、まだ多くの会社で試行錯誤の途中にあります。
Sapeetでも、データやAIを使って、プロダクトや業務をより良くしていくための仕組みづくりに取り組んでいます。
ただダッシュボードを作るのではなく、データをどう業務に組み込み、どうアクションにつなげ、どう継続的に改善していくか。
こうしたテーマに向き合いながら、プロダクト開発や業務改善を進めています。
まだ正解が固まっている領域ではありません。だからこそ、自分たちで仮説を立て、試し、改善しながら、より良い仕組みを作っていける余地があります。
こうしたテーマに興味がある方は、ぜひ一緒に働きませんか？