AIエージェントはデモでは完璧に動きます。本番に出した瞬間に壊れる、という経験を持つエンジニアは多いはずです。その根本原因は「データの質が低い」ことではなく、「意思決定の構造がシステムに存在しない」ことにあります。

2026年1月、Palantirはこの問題への技術的な回答を「Agentic Runtime」ブログシリーズで公開しました。自社プラットフォームAIPでどうやってエージェントを本番展開まで持っていくか、セキュリティ設計の全体像が示されています。

この記事でわかること：

  • Palantir Ontologyがデータ・ロジック・アクションをどう一元化するか
  • 本番エージェントを守る5つのセキュリティ次元の内容
  • 製造業でのサプライチェーン危機対応の実例
  • Palantir AIPへのアクセス方法

https://blog.palantir.com/connecting-ai-to-decisions-with-the-palantir-ontology-c73f7b0a1a72

「データ管理」だけでは不十分な理由

従来のデータアーキテクチャは、レポーティングや分析のために最適化されています。しかし、リアルタイムの意思決定を支援するには「データを整理すること」だけでは足りません。

Palantirの主任アーキテクト、Akshay Krishnaswamy氏によると、すべての意思決定には3つの要素があります。使われる情報である「データ」、判断のプロセスである「ロジック」、そして決定の実行である「アクション」です（参考）。従来のシステムはデータの管理に特化しており、ロジックとアクションは別々のツールに分散していました。

この構造が、AIエージェントを本番に投入した際の失敗の温床になります。エージェントはデータにアクセスできても、どのロジックを使うべきか、何を実行してよいかのコンテキストを持てません。

3要素を統合するPalantir Ontology

Palantir Ontologyは、データ・ロジック・アクションを「決定中心のモデル」として一元化するアーキテクチャです。

データの側面では、ERPやIoT、非構造化リポジトリなど様々なソースを、企業の語彙に合ったセマンティックオブジェクトとして統合します。さらに「意思決定データ」、つまりいつ・誰が・どの選択肢を検討し・何を決定したかという文脈まで自動的に記録します。

ロジックの側面では、MLモデル・最適化アルゴリズム・ビジネスロジックを「AI対応ツール」として統一インターフェースで公開します。これにより、LLMがこれらのロジック資産を人間と同じ方法で活用できるようになります。

アクションの側面では、決定の実行をシナリオとして安全にステージングし、レビュー後にERPや製造システムなど企業の全基盤に書き戻す仕組みを持っています。人間とAIエージェントが同じアクションフレームワークを共有する設計です。

本番エージェントを守る5つのセキュリティ次元

https://blog.palantir.com/securing-agents-in-production-agentic-runtime-1-5191a0715240

2026年1月のブログ「Securing Agents in Production」では、本番展開に必要なセキュリティの全体像が詳しく解説されています。

まず「推論コアへの安全なアクセス」として、複数のLLMプロバイダーへの接続をプロジェクト単位・ユーザーグループ単位で制御します。プロンプトやレスポンスがサードパーティに保持されない設計で、トークン使用量もプロジェクト・ユーザーごとに追跡されます。

次に「エージェント実行基盤の隔離」として、Kubernetes基盤「Rubix」が各ワークロードを厳密に分離します。すべてのノードは48時間以上存在できない設計で、エフェメラルな環境がセキュリティの基礎になっています。

「メモリへのポリシー適用」では、ワーキングメモリ・エピソードメモリ・セマンティックメモリ・プロシージャルメモリの4種類すべてに、同一のセキュリティポリシーが適用されます。ベクター検索による過去の学習内容の読み込みも、同じ権限管理の下で動きます。

「マルチモーダルツールの管理」では、エージェントがERPや製造システムなどの外部ツールを呼び出す際、Ontologyで定義されたオブジェクトへのアクセス権が動的に評価されます。「プロビナンスベースセキュリティ」により、複数のツールが連鎖して呼ばれる場合でも、データのマーキングポリシーが全体を通じて守られます。

最後に「リアルタイム監視と事後監査」として、LLMの各呼び出し・ファンクション実行・ツール使用のトレースが記録されます。どのバージョンのデータを参照したか、どのロジックが使われたかまで追跡できる設計です。

実例：製造業のサプライチェーン危機

Palantirがブログで公開した事例を見ると、実際の価値が見えてきます。

医療機器メーカー「Titan Industries」（ブログ内の架空企業）では、主要サプライヤーが突然の供給停止に陥りました。Ontologyにはサプライヤー情報・倉庫在庫・製造スケジュール・出荷状況・顧客注文がリアルタイムで統合されています。

AIコパイロット「Disruption Bot」は、これらのデータと既存の最適化モデルを横断的に参照し、担当者がまだ検討していなかった代替素材の再配分プランを提案しました。プランはシナリオとしてステージングされ、人間のアナリストが最終承認してから実行に移ります。この「AIが提案し、人間が承認する」設計が、エンタープライズ環境での信頼性を担保しています。

導入と料金

Palantir AIPは企業向けプラットフォームのため、価格は公開されていません。評価はBootcampプログラムを通じた実際の業務での試用から始まり、数時間での成果を目標にした形式で進みます。開発者向けにはOntology SDK（OSDK）が提供されており、プロコード・ローコード双方での開発に対応しています。

Ontologyが従来のプラットフォームと異なる点

Palantir Ontologyが最も異なるのは、「データを整理する場所」ではなく「決定をモデル化する場所」という設計思想にあります。AIエージェントが本番で機能するには、何にアクセスできるか・何を実行してよいか・どんなロジックを使うかのコンテキストが必要です。Palantirはその文脈をOntologyとして企業全体で共有することで、エージェントが人間と同じ土台の上で動けるようにしています。