生成AIが文章を作るだけなら、企業は便利な道具を一つ増やせば済みます。けれどもAIが在庫を振り替え、保守作業を起票し、取引先への発注まで進めるとなれば、話は急に重くなります。AIは何を知ってよいのか。どの操作まで許されるのか。間違えたとき、誰が止められるのか。この境界を曖昧にしたままでは、賢いモデルほど怖い存在になりかねません。
そこで注目したいのが、Palantir Technologies（以下、パランティア）の「Ontology」です。これは難しそうな名前ですが、ひと言で表すなら、会社にあるデータを「設備」「注文」「担当者」といった仕事上の意味で結び、さらに「停止する」「承認する」「発注する」という操作まで載せる業務地図です。パランティアのAI全体像を扱った記事から一歩進めると、同社の本当の勝負どころは、最も賢い基盤モデルを自前で持つことよりも、AIを現実の仕事へ安全につなぐ層にあるように見えてきます。
もちろん、Ontologyを導入すれば会社が自動で動き出すわけではありません。現在すでに提供されている機能と、まだベータ段階の機能、そして5年後・10年後の予測を分けながら、パランティアの現在地と将来性を見ていきましょう。
パランティアの現在地はモデル企業より運用基盤に近い
パランティアをOpenAIやAnthropicと同じ「AIモデルの会社」として見ると、強みをつかみにくくなります。同社は複数のモデルを企業データや現場の手順へ結び、意思決定から実行までを管理する基盤を提供しています。生成AI競争の主役がモデルの知能だけで決まらなくなったとき、企業側の文脈と権限を握る位置には大きな価値が生まれます。
売上と顧客数は実験企業の段階を超えた
パランティアの2026年第1四半期のForm 10-Qによれば、四半期売上高は約16億3,300万ドルで、前年同期比85％増でした。顧客数は1,007社となり、前年同期の769社から増えています。売上の内訳は政府部門が53％、商業部門が47％で、政府向けだけに依存する会社という昔の見方も、実態を十分に表さなくなりました。
これは、AIを試して終わるのではなく、組織の運用へ組み込む需要が強いことを示す数字です。機密性の高い政府業務と、速度を求める民間業務の両方で成長している点は、権限管理と実行を含む同社の設計が市場に受け入れられている有力な材料でしょう。
高成長だけでOntologyの勝利とは言い切れない
ただし、好調な業績をそのままOntology単体の優位性とみなすのは早計です。契約にはFoundry、Gotham、AIPなど複数製品が含まれ、個別機能の売上は切り分けられていません。同社自身も、顧客候補へ提供する試験導入やブートキャンプが契約に結び付く保証はないと開示しています。成長は確かな現在地ですが、導入の速さや継続率、競合製品への乗り換えにくさまで含めて見なければ、将来の支配力は判断できません。
Ontologyは会社の名詞と動詞を同じ地図へ置く
企業のデータは、販売、在庫、保守、人事など別々のシステムに散らばっています。データベース上の列名を読めるだけでは、「この部品が遅れると、どの製品と顧客に影響するか」までは分かりません。Ontologyは、そのばらばらな記録へ業務上の意味を与え、AIと人が同じ対象を指して話せる状態を作ります。
ObjectsとRelationsが業務の意味を作る
パランティアの公式説明では、Objectsは顧客、設備、注文、拠点など現実の対象を表し、Relationsはそれらの関係を表します。たとえば「設備Aが製品Bを作り、製品Bが注文Cに割り当てられている」と結べれば、設備の故障を単独のアラートではなく、納期と売上に波及する出来事として扱えます。
この意味付けは地味ですが、AIにとっては重要です。言語モデルがもっともらしい文章を返すだけでなく、企業内で「どのAの、どのBなのか」を間違えずにたどる足場になるからです。
Actionsが分析を現実の変更へ変える
Objectsが会社の「名詞」なら、Actionsは「動詞」です。公式文書にあるOntology Actionsは、オブジェクトの変更や業務処理を、定められた手続きとして実行します。在庫の割り当て、作業指示の作成、担当者の変更などを、分析画面から実際の運用へつなげられるわけです。
ここが一般的な社内検索との大きな違いです。「部品が足りません」と答えるだけのAIと、「代替在庫の候補を示し、権限を確認し、承認後に振り替える」AIでは、仕事への影響がまるで違います。後者には、正解を当てる能力だけでなく、正しい手順で動く能力が必要です。
Securityが誰に何を許すかを決める
Ontologyの設計文書は、意思決定モデルをData、Logic、Action、Securityの組み合わせとして説明しています。AIが見られる情報、呼び出せる道具、保持できる記憶、実行できる操作を細かく制御し、記録を残す考え方です。AIに万能の社内アカウントを渡すのではなく、人や役割に応じて狭い通行証を持たせる設計に近いでしょう。
| 構成要素 | 担う役割 | 弱いと起きること |
|---|---|---|
| Data | 現場の事実を取り込む | 古い情報で判断する |
| Logic | 計算や業務ルールを適用する | 判断基準が部署ごとにずれる |
| Action | 承認された変更を実行する | 提案だけで仕事が止まる |
| Security | 閲覧・操作・記録の境界を定める | 越権や情報漏えいにつながる |
四つは足し算ではなく掛け算です。どれか一つがゼロに近ければ、AIは企業の中で安心して働けません。Ontologyの価値は、データ整理の見栄えよりも、この四つを同じ業務モデルに載せるところにあります。
AIエージェントはどこまで仕事を動かせるのか
現在のパランティア製品には、会話から情報を探すだけでなく、Ontologyの操作を呼び出す仕組みがあります。ただし、すべてが完成された自律運用ではありません。製品ごとの成熟度と、人の承認が残る範囲を見分ける必要があります。
会話型AIは確認付きでActionを実行できる
AIP Chatbot Studioは、言語モデルをOntologyや文書、各種ツールへ接続する機能です。公式文書では、会話中にOntology Actionを使い、設定に応じて自動実行するか、利用者へ確認を求めてから実行できると説明されています。たとえば保守記録を調べ、交換対象を特定し、担当者の承認後に作業チケットを作る流れが一つにつながります。
一方、開発支援を行うAI FDEでは、変更を別のブランチに作り、利用者の確認を経て反映する設計が基本です。セキュリティとガバナンスの説明によれば、AI FDEは利用者本人の権限で動き、Ontology Actionの実行には毎回承認が必要で、操作は監査記録に残ります。「自律化」と「無許可」を同じ意味にしない姿勢が見えます。
pro-code Agentsは複数の開発基盤を受け入れる
さらにパランティアは、開発者が独自の処理を組めるAgents機能をベータとして公開しています。OpenAI Agents SDK、Claude Agent SDK、Google ADK向けのひな型があり、エージェントは限定された権限でOntologyやPalantirの機能へ接続できます。
この点は将来性を考えるうえで面白いところです。どの基盤モデルが首位になっても、そのモデルを企業の業務地図へ差し込めるなら、パランティアはモデル競争の外側で価値を保てます。ただしAgentsはまだベータです。大規模な本番運用でどれほど安定し、開発コストを下げられるかは、今後の実績で確かめるべき領域です。
社内から企業間へ進むには別の標準が要る
Ontologyは一つの企業や組織の中で共通の意味を作ることに強みがあります。しかし、買い手の「注文」と売り手の「受注」が同じ定義とは限りません。AIが企業をまたいで交渉や発注を進めるには、本人性、委任された権限、契約条件、取り消し方法を相互に確認する標準が必要です。この先にある課題は、AIエージェント同士の企業間取引を扱った記事で詳しく掘り下げています。
つまり、パランティアだけで企業間市場が完成するわけではありません。社内の意味と操作を整えるOntologyに、社外で通用する認証や取引規約が重なって初めて、エージェントは会社の境界を越えられます。
強みと同じ場所に導入の重さもある
企業の仕事を深く理解する基盤は、スイッチ一つでは作れません。設備名や商品コードをそろえるだけでなく、誰が例外を承認し、どの条件なら処理を止めるのかまで決める必要があります。Ontologyが深く入るほど価値は増えますが、導入の重さも同じ場所から生まれます。
Ontologyづくりはデータ整備で終わらない
現場には、正式な手順書に書かれていない例外が山ほどあります。納期が迫った注文を誰が優先するのか、故障の兆候がどこまで進めばラインを止めるのか。こうした暗黙の判断を、Objects、Relations、Actionsへ落とし込むには、現場担当者と技術者が一緒に設計しなければなりません。
これはパランティアにとって参入障壁である一方、顧客にとっては時間と費用の負担です。短期間で成果が出る業務から始め、後から対象を広げられるかどうかが、普及の速度を左右します。
権限が間違えばAIは整然と越権する
権限管理があるだけで安全とは限りません。もとの設定が広すぎれば、AIは許された範囲で堂々と不適切な操作を進めてしまいます。怖いのは暴走するロボットというより、間違った社内規程に忠実な優等生かもしれません。
- 重要なActionには、人の承認と金額・回数の上限を置く
- 誰が、どの情報を根拠に、何を実行したかを追跡できるようにする
- 本番とは別の環境で失敗例を繰り返し評価する
- 異常時に人が即座に停止し、処理を戻せる手順を用意する
パランティアは監査や権限の仕組みを提供しますが、何を許すかを決める責任まで引き受けてくれるわけではありません。技術的な統制と、経営上の責任分担をセットで設計する必要があります。
深い統合は乗り換えにくさを生む
業務の意味、操作、権限を一つの基盤へ積み上げるほど、別の製品へ移る作業は難しくなります。これは継続収益を得たいパランティアには強みですが、顧客には囲い込みのリスクです。データを取り出せるだけでなく、業務モデルと操作定義をどこまで再利用できるかが重要になります。
工場や物流では、ソフトウェアの操作が機械の動きへ届きます。パランティアをフィジカルAIの現場OSとして考えた記事で見たように、現実世界へ近づくほど停止判断と責任の設計は重くなります。便利さだけでなく、撤退経路まで設計できる企業が、長く使いこなせるでしょう。
5年後と10年後、Ontologyは企業のAI憲法になれるか
ここからは予測です。現在確認できる製品機能と業績を土台にしていますが、将来を保証するものではありません。焦点は、AIの知能がどこまで伸びるかよりも、企業がどこまで権限を渡せるかにあります。
2031年は権限付きエージェントが定型業務を動かす
5年後には、Ontology上で定義された狭い業務を、複数のエージェントが分担する企業が増えると予測します。需要予測の変化を見つけるエージェント、代替案を計算するエージェント、承認条件を確認するエージェントが連携し、人は高額な変更や例外だけを判断する形です。
実現を後押しするのは、モデル性能の向上、操作履歴の評価、役割ごとの細かな権限設定です。逆に、業務データが古いまま、例外処理が整理されず、責任者が決まらなければ普及は止まります。パランティアが優位に立つには、強力な機能よりも「小さく安全に任せ、失敗から修正できる」導入方法を標準化できるかが鍵になります。
2036年は企業をまたぐ業務地図が試される
10年後には、一社の中だけでなく、供給網や公共インフラをまたぐ限定的な業務地図が生まれる可能性があります。部品不足、輸送遅延、電力制約を関係企業が必要な範囲だけ共有し、各社のエージェントが代替計画を調整する世界です。すべてのデータを一か所へ集めるのではなく、意味と権限を保ったまま必要な情報だけを交換する方向が現実的でしょう。
もしこの層で広く使われる標準を押さえられれば、Ontologyは単なるデータ製品ではなく、企業活動の「AI憲法」に近づきます。誰が何を知り、どの条件で行動できるかを定めるからです。ただし、社会インフラに近づくほど、一社の独自仕様だけでは受け入れられません。相互運用性、第三者監査、各国の規制への対応が不可欠です。
予測が外れる四つの条件
パランティアの将来が明るいと決めつけることもできません。少なくとも、次の条件が重なると優位性は薄れます。
- クラウド各社の業務モデルと権限管理が十分に成熟し、より安く導入できる
- 企業が深い統合より、交換しやすい小型ツールを選ぶ
- ベータ機能が本番規模で安定せず、運用負担が下がらない
- 権限事故や説明責任への不安から、自律実行の範囲が広がらない
それでも、企業AIの価値が「よい回答」から「安全な実行」へ移る流れは強まっています。パランティアを見るとき、モデルの賢さだけを比べるのは少しもったいありません。Ontologyが会社の名詞と動詞をどこまで正確につなぎ、人が安心して権限を渡せる場所を作れるのか。そこに、同社の次の10年を測る物差しがあります。
