Palantirが2025年2〜3月にとんでもなく高騰しました。しかし、なぜこんなに人気が出たのでしょうか？
あまり知られていないSWを作る会社なのに、何がそんなに効果的なのでしょうか？
この会社が作った製品の利用料金はいくらなのでしょう？この企業についてよく知らないのが現状です。
もしPalantirが目指す方向ですべての産業をデジタルトランスフォーメーションしたらどうなるでしょうか？
そうなれば、すべてを仮想（シミュレーション）で回してみることができるので、仮想地球も作れて、すべてを管理下に置けるようになると思います。
PalantirであれSnowflakeであれ、彼らが作ろうとしている製品はビッグデータ基盤の意思決定ツールと見ることができます。
しかし、この意思決定自体も自動化したいという考えも浮かびます。毎日社員の業務をリアルタイムに反映できるように、社員に業務状況のリクエストを自動で送り、どれくらいの内容で何をどのようにしたかの中間報告を受けるのです。すべてがGitコミットのように残るなら、単に仕事のための仕事として文字数稼ぎなのかどうかを把握できるでしょう。
Palantirの競合：Snowflake、Databricks、C3.AI（それぞれ専門分野が異なります）
海外ではSnowflakeの方が評価されているようです。
以下の内容はPalantirの学習講座を見ながらまとめたものです。記事の一番下にリンクがあるので、必要であれば直接訪問してより良い内容を確認してください！
Foundry#
Foundryはソフトウェアの名称：オペレーショナル意思決定プラットフォーム
さまざまな産業の開発者ではないすべての職種がデータとモデルを通じてインパクトを創出できるよう支援するツールです。
国家的危機状況のような緊急な要件に対応できるよう設計されています。
財務データ、個人識別情報、健康情報、未分類情報、機密政府データなどセキュリティに敏感な顧客も使用できるように作られています。HIPAA、GDPR、ITARを含む全般的な規制要件を満たしています。
デジタルトランスフォーメーションが必要な産業が優先されているようで、Palantirの製品がより必要とされています。このような産業が人類にとってIT企業よりもさらに重要だと以前Peter Thielが述べたことがあり、関連があると思います。
PalantirのSWはユーザーが見られるよう柔軟に表現される必要があり、時間とともに変化する条件に適応しなければ組織が使えません。データ専門家だけが使える環境であってはならず、真のデジタルトランスフォーメーションはすべてのチームとユーザーを一つにまとめてこそ可能だとされています。ビッグデータ活用のために企業はデータパイプラインの構築とデータによる分析に苦労しています。
通常、分析はダッシュボードを提供することで役割を果たします。そしてさらに大きな問題は、このような投資によるコストが実質的な変化をどれだけもたらすのか明確でないことです。
データを集めて構築し分析して意思決定をすれば終わりではなく、また別の問題につながります。すべてがつながっていないため、結果とフィードバックが再びデータに反映されません。そのため企業がビッグデータを構築しても改善されない確率が高いのです。だからFoundryは持続可能な方法で提供しています。組織全体を接続してデジタルトランスフォーメーションを可能にします。
Palantirが言うデジタルトランスフォーメーションは、社員の行動や事務業務も含まれているようです。
Ontology#
OntologyとOntologyを支援するアプリケーション
OntologyはFoundryの核心で、複数のレイヤーで構成されています。
第1レイヤーはセマンティックレイヤー：組織内のすべてのタイプのデータソースを共有されたデジタル表現に接続します。組織を構成するさまざまな名詞の集合体です。製造業や小売業であれば、店舗の位置、顧客、取引、物流センターなどさまざまな資産や企業、イベントが業務環境として構成されています。
このような物体とイベントの間には関連性があり、相互作用する方式もあります。セマンティックレイヤーモデルによって動作する動的属性もあります。セマンティックレイヤーは生きている表現であり模型です。
第2レイヤーはキネティックレイヤー：動く組織。組織のすべての行動、機能およびプロセス、動詞。Ontologyを実際にアクティベートします。
顧客が取引を完了 -> 製品が物流センターに到着 -> 店舗に配送されるといった作業を実行します。
すべての物体、イベント、作業が共有される方式でモデリングされます。組織の共通言語に基づいた発展的な意思決定、コラボレーション、アプリケーション構築の礎となります。
第3レイヤーはダイナミックレイヤー：シミュレーション、最適化、プロセス自動化。一つの組織をプログラミングコードと同様のアプローチで扱います。さまざまなシナリオの探索、分岐後のシナリオがダウンストリームのオペレーションに与える影響などを確認できます。意思決定を行う時点でこれらのシナリオを更新し、戦略とオペレーション間のスムーズな接続性を強化できます。
使い方は一つのワークフローから始めてOntologyを拡張します。Ontologyはデータ統合から始まります。Foundryのさまざまなパイプラインアプリケーションを使えば、テーブル形式のデータ（DB）、センサーデータ、トランザクションデータ、地理空間ソース、サードパーティデータなど（Tableauのようなもの）さまざまなデータソースをOntologyと統合できます。
これらのデータソースがOntologyに到達すると、顧客、製品、価格、倉庫など実際の概念に関連する直感的な概念に変換されます。
Ontologyを構成するには、構造化・非構造化データについて考える必要があります。組織基準で構成された抽象的な世界（Palantir Foundryで統合された世界）にこれらのデータを接続する方法も検討しなければなりません。
データを入れるだけで終わるのではなく、特定のデータで動作するモデルに基づいて運用されています。モデルを構築するにはモデルビルディングツール、ストアドプロシージャ、サードパーティツール、オープンソースなどを活用すればよいです。データサイエンティストが主に詳しいです。
これらのモデルは過去の小さな断片を基に構築されています。組織に完全に統合されるようにモデルが作られていません。モデルを作ったとしても、モデルからインパクトを創出するのはさらに難しいことです。そして部門はサイロ化されているためモデルをうまく活用できていません。
人がモデルをうまく活用できないため、これらのモデルをOntologyのような共有システムに統合してこそ、ようやく価値ある活用ができます。
Foundryはオペレーショナル意思決定プラットフォームであるため、多くのタイプの分析能力を強化するには各データの詳細な表現が必要です。データアナリストが価格変動（例えば）が実際にどのような影響を与えたかを予測と比較して分析する必要があります。これをFoundryではオブジェクトの動的属性を活用すればよいです。属性はモデルと提供されたデータに基づいています。
このような分析でアプリ開発者は意思決定者に注意が必要な異常値を知らせるオペレーショナルアプリを構築します（内部でのみ使用されるアプリのようです）。例として自動価格変動が発生し、製品の需要が大きく抑制される可能性があります。このような場合、モデルが認識した内容では説明が難しいケースも発生し得るとのことです。その場合はそのテーマの専門家が意思決定者となり、状況を評価する必要があります。この評価後、アプリから再びOntologyに流れる必要があります。これをwrite backと呼びます。そうすることでシステムが段階的にインテリジェント化し、エンドユーザーから予測の更新、アクション、戦略の更新など多くの情報を得ることができます。
Ontologyを使用すれば、安定的で制御された方式で運用する基本システム全体ですべての作業を実行できます。精緻な意思決定を下すことができ、意思決定者にさまざまな「仮定」シナリオを実行できる機能を提供します。分析とオペレーショナル意思決定を連携し、すべての意思決定が最大限情報に基づいた決定となるよう保証します。
Ontologyは企業全体で使っていたツール構築フレームワーク、開発チーム、組織外部のパートナーにもアクセスが可能です。
OPI(=API)を通じて提供しています。そのためFoundryのフロントエンド以外にもサードパーティアプリでも使用可能です。
Ontologyは組織のすべての参加者のための共通語彙を生成することで、異なるデータソース、モデル、システムを統合し、コラボレーションと依存ワークフローを可能にします。
ビッグデータで業務遂行方式まで変えてコラボレーションまで可能にするのではないでしょうか？データの生成とデータ品質を見れば、誰がうまくやっていて誰がそうでないかも確認できそうです。
自分たちの仕事の義務が付与されれば、企業の全体目標にどうつながるか、目標のためのものであることを認識させることができると思います。
例）給食のおばさんの心構え
A: 社員にランチを提供する。
B: 肉料理を提供したら企業の売上が上がった。
このうちBのようにある意味を知ると、意思決定に臨む姿勢が変わるでしょう。
ある企業がある問題を解決しようとする時、その解決過程で業務、方式、管理、運営などさまざまなポイントでも問題が発生します。結局それを適切に解決できず見当違いの解決をしたり、解決せずに進んでも、解決しようとした問題に到達できずに崩壊するのではないでしょうか。もちろん売上と利益の方が重要な場合もあります。
問題を解決するための意思決定に必要なすべての情報を提供されているか？
— Ted Mabrey
意思決定の改善は標準化された作業のおかげではなく、自分の決定から生まれるリアルタイムデータが我々の作業方式を変化させることにあります。
ある問題が発生するとその問題の根本原因を見つけなければなりませんが、この過程は容易ではありません。しかしFoundryを導入していれば関連関係があるため比較的容易でしょう。そしてOntologyで問題を解決しやすい可能性があります。このような改善を通じてより良い意思決定が可能になります。
Ontologyの可視化#
Ontologyシステムの第一のバケットはデータ。
Foundryにはデータの接続、変換、統合、管理ができるよう設計されたアプリがあります。
構造化、非構造化、テーブル、IoT、地理、商用データソース（SAP、Salesforce、Oracleなど）をFoundryに接続できます。
こうする理由は、ビッグデータを構築するということは第一に各種データを一箇所に集める必要があるからです。次に接続して変換して統合して意思決定を行わなければなりません。この過程は企業ごとに異なり、また何が正しいのか分からない人にとっては難解です。活用方法もないのにとりあえずビッグデータを構築しようというのは、「うちも飲み会をしなきゃ」と言って飲み会の前に何を食べるか決めずに決定するようなもの。明確な目標の中での優先順位が必要です。
モデルとは#
モデルは料理のレシピのようなものです。
モデルはデータを通じて学習した一種のレシピ、データを理解する特別な関数です。
例）スパムメールフィルターモデル
- データ（材料）：大量のスパムメールと正常メールの内容、件名、送信者情報など
- モデル（レシピ）：スパムメールと正常メールを区別するルールとパターン（例：特定の単語が多く含まれるとスパム、特定のキーワードが件名にないと正常など）
- 結果（料理）：新しいメールがスパムか正常メールかの分類
例）株価予測モデル
- データ（材料）：過去の株価データ、金利、経済指標、ニュース記事など
- モデル（レシピ）：株価変動に影響を与える要因とパターン（例：金利が上がると株価が下落する可能性が高いなど）
- 結果（料理）：明日の特定企業の株価予測
モデルなしでデータをそのまま使うと、あまりに複雑で膨大なためミスが起こり得ます。毎回このようにするのは非効率的で、モデルがあれば自動的に結果を予測・分類してくれます。微妙なパターンのように人が見逃しがちな重要な情報を持つ隠れたパターンを見つけることができません。
モデル学習を行ってこそモデルを作ることができます。
- 学習データセット：例）料理の材料、完成した料理の写真 / スパムメールの例、正常メールの例
- 検証データセット：中間チェック用の試験問題のようなもの。検証データセットで予測し結果を正解と比較して少しずつ修正・改善する
- テストデータセット：モデル学習が終わった後の最終実力評価のための本番試験問題のようなもの。テストデータで最終予測を行い結果を実際の正解と比較してモデルの性能を最終的に評価する
最初は予測できませんが、検証データセットで間違いノートを作り、再び学習データセットで復習すると、徐々により正確な予測ができるようになります。この過程を最適化と呼びます。最適化の目標はできるだけ正確に予測できるようレシピを調整することです。
= もしかしたらこの過程を学生に適用すれば試験でうまくいくのではないでしょうか？
良い先生（データ）、良い教材（データセット）、地道な努力（最適化）、優秀なモデル（名門大生 能力のある学生）
このような学習過程を実行するには場所が必要です。
-
データセット接続：散在するデータを一箇所に集めること。複数のデータソースを一つに統合。データを準備する過程
例）冷蔵庫、棚、市場など複数の場所にある料理の材料をキッチンに持ってきて整理すること。 -
AWS SageMakerやGCP Vertex AI：クラウドベースのAIモデル開発専用キッチン。強力なAIモデルを簡単に作れる
例）料理道具フルセット：さまざまなツール、アルゴリズムの提供、自動化 -
モデルはデータを通じて学習した「レシピ」であり、データを効率的に活用するために必要です。
-
モデル学習はモデルにデータを「食べさせながら」レシピを「教える」過程です。
-
データセット接続はモデル学習のために複数のデータを「キッチン」に持ってきて「材料」を準備する過程です。
-
GCP Vertex AI、AWS SageMakerはモデル開発のための「最先端クラウドキッチン」です。
FoundryとOntologyの分析機能
データ分析を支援するアプリは、すべてのタイプのユーザーが組織のデジタルツインを調査・探索できる共通ワークベンチとなれるよう設計されています。
AWSのアプリのようにPalantirも内部にさまざまなツールがあります。どう使ってどう接続するかはユーザー次第です。
分析にはQuiver（クイバー）を使います。データサイエンティストが開発したモデルを使って現在の分析と比較できます。強力な統合データおよびモデル基盤を備えることが非常に重要です。
ユーザーがモデルの予測と異なる結論に達した可能性があり、ユーザーは最新の分析結果をより正確に反映するようモデルを更新する同僚（例：データサイエンティスト）にフィードバックを提供できます。分析ワークフローはさまざまなレベルの技術的複雑さで発生し得ます。深い専門知識や長期間の調査が必要など、オペレーショナルワークフローのための総合的な意思決定サポートの役割も果たします。
オペレーションユーザーは正しい判断を下すために準備された分析と対話し、一部のパラメータを変更して結果を評価できる必要があります。
多数の分析機能を活性化するには、効果的なデータの民主化が可能でなければなりません。適切なレベルの技術的複雑さを備えたさまざまな分析ツールが必要です。Foundryが提供しています。
重要な注意事項として、Ontologyへのアクセスを民主化する過程で最も重要なのは、セキュリティと権限が中央制御されているかどうか、そして誤ったデータを分析したり誤ったモデルを使用してバイパスできないケースです。
Ontologyは権限およびアクセス制御、アクセスタイプの定義、状態などを含め中央的に構成・管理されます。Ontologyを使用するユーザーは毎回探索のために重要な境界を設定・リセットする代わりに、分析およびオペレーショナル意思決定に集中できます。
いずれにしても、こうしたデータが有機的につながっていてフィードバックも即座に反映できる環境が構築されているため、内部/外部で使用するために作られたアプリを通じてユーザー（=実務者）が値をCUDすれば即座に反映されます。そのようなカスタムアプリを作れるよう提供しています。
Foundryは、Ontologyのオブジェクトと要素を表示・分析するだけでなく、アプリ開発者がオペレーション担当ユーザーの日常業務で使用できるカスタムアプリを構築できるよう支援します。
技術
マニュアルおよびサポート関連リソース
ケーススタディ
- 国際商業銀行のデジタル化プロセス
- PG&E + Palantir
- Airbusの社員エンパワーメント
- 英国NHSとFoundry
- 研究とFoundry
- より多くの情報はPalantirのインパクトスタディホームページで見つけられます
Never mistake motion for action.
— Ernest Hemingway
