Palantir Foundry 2026年6月16日の更新: 分析、AIモデル、配布、自動化監視を強化

Palantir Foundry Announcements では 2026年6月16日、SQL Studio の一般提供、AIP での Grok Build 0.1 提供、Foundry DevOps の複数プロダクト同時パッケージ、Autopilot の Automation events タブが案内されました。開発、分析、AIモデル利用、リリース運用、監視にまたがる更新です。

要点

• SQL Studio が一般提供になり、表形式データと Ontology オブジェクト型を専用アプリから SQL で分析しやすくなりました
• Grok Build 0.1 は、xAI モデルファミリーが有効な対象環境で AIP から使えるコーディング向けモデルとして追加されました
• Foundry DevOps では、同じドラフトグループ内の複数プロダクトを依存関係順にまとめてパッケージできるようになりました
• Autopilot の Automation events タブは、従来の Object executions タブを置き換え、失敗調査や実行履歴を自動化処理単位で見やすくします

今回の更新で変わること

2026年6月16日の Foundry Announcements は、単一の大きな新機能というより、Foundry を日常的な開発・分析・運用基盤として使うチームに効く更新が同じ日に並んだものです。SQL Studio の一般提供は、Foundry 内で SQL を使う作業を、断片的なコンソール操作から専用アプリでの反復的な分析へ寄せる更新です。表形式データだけでなく Ontology のオブジェクト型も対象に入り、SQL ワークシートの保存、共有、バージョン復元、結果の表やチャート表示、AI支援によるクエリ作成まで含むため、分析者とデータ基盤担当の作業場所が近づきます。

Grok Build 0.1 の追加は、AIP のモデル選択肢を広げる更新です。原文では、xAI が有効な米国およびサポート対象リージョンの環境で利用でき、Web 開発やデバッグ、MCP 対応を含むコーディング作業向けモデルとして説明されています。ただし、利用できるかどうかは環境管理者による xAI モデルファミリーの有効化、リージョン、トークン費用、社内の外部モデル利用ルールに依存します。便利なモデル追加としてだけでなく、誰がコードやデータに触れるAIモデルを使えるのかを決める管理項目です。

Foundry DevOps の更新は、プロダクト配布の運用に関係します。これまではプロダクト間の依存関係を解決するため、チームが手作業でリリース順を調整する必要がありました。今回の更新では、同じドラフトグループ内で複数プロダクトを扱い、リンク済みプロダクトの依存関係をグラフで確認し、公開時には依存されるプロダクトから順にパッケージできると説明されています。複数の業務アプリ、Ontology、パイプライン、データ接続をひとまとまりで配布する組織では、リリース作業の抜け漏れを減らす意味があります。

Autopilot の Automation events タブは、自動化処理の実行を調査するための観測面を広げます。各イベントでは、自動化処理名、実行された効果、フォールバックアクション、イベント詳細、成功・失敗・フォールバック発動などの結果、トリガーになったオブジェクトを確認できます。実行は Automate の履歴表示とそろう形でバッチ単位にまとめられ、個々のオブジェクト実行に対するトレースログ、関連リソースへのリンク、エラーメッセージ、スタックトレース、処理時間も見られます。失敗イベントで絞り込み、同じ自動化処理の成功例と失敗例を比較できるため、監視というより、運用時の原因調査に近い更新です。

SQL Studio 一般提供で確認したいこと

SQL Studio は、Furnace と Ontology SQL を背景に、表形式データと Ontology オブジェクト型を SQL で扱う専用アプリとして一般提供になりました。Furnace は表形式データ向け、Ontology SQL はオブジェクト型や多対多リンク向けの SQL エンジンとして説明されています。利用チームは、どの分析を SQL Studio のワークシートとして保存・共有するのか、誰がプロジェクト内で共有できるのか、書き込み操作や Iceberg テーブル操作をどの権限で許すのかを確認したいところです。

また、AI支援パネルは現在のコードや参照スキーマを踏まえてクエリ作成、説明、デバッグを助けるとされています。便利な一方で、AIが提案した SQL をそのまま意思決定や本番処理に使うのではなく、指標定義、フィルタ条件、権限、対象データの意味を人が確認する運用が必要です。

Grok Build 0.1 を AIP で使うときの見方

Grok Build 0.1 は、コーディング作業やツール呼び出しを伴うAI利用を意識したモデルとして追加されています。Foundry 内で使えるモデルが増えることは、開発者にとって選択肢の拡大ですが、実務では「使える」ことと「使ってよい」ことを分けて判断する必要があります。

確認したいのは、対象環境で xAI モデルファミリーが有効か、どのリージョンで使えるか、トークン費用が既存モデルとどう違うか、コードや業務データを扱う際の社内ルールに合うかです。とくにコーディング向けモデルは、リポジトリ内容、設定ファイル、ログ、エラー文、内部API名などに触れやすいため、権限とレビュー手順を先に決めるのが安全です。

Foundry DevOps の複数プロダクト対応

Foundry DevOps の複数プロダクト同時パッケージは、単に操作をまとめる機能ではありません。複数のプロダクトが互いに依存している場合、どれを先に公開するかを間違えると、下流のアプリやワークフローが必要な入力を見つけられないことがあります。今回の更新では、ドラフト内のプロダクトと上流・下流の依存関係をグラフで見られ、壊れたリンク関係の警告も確認できるとされています。

運用チームは、関連プロダクトをまとめて公開できるようになるほど、ロールバック、承認、テスト、変更通知の単位も見直す必要があります。便利になった分、ひとつの公開操作が複数の業務資産へ波及するためです。

Autopilot の Automation events タブ

Automation events タブは、自動化処理がどのオブジェクトに対してどのように動いたかを追いやすくする更新です。失敗したイベントを絞り込み、該当イベントのトレースログとエラーメッセージを読み、影響を受けたオブジェクトの履歴へ移動し、成功例と失敗例を比較する流れが原文で示されています。

これは、自動化処理を本番業務に入れているチームにとって重要です。自動化は動いている間は便利ですが、失敗時には「どのロジックブロックで止まったのか」「どのオブジェクトが対象だったのか」「同じ自動化処理でも成功したケースと何が違ったのか」を説明できなければ、利用者からの問い合わせや業務影響に対応しにくくなります。

対象になりそうなユーザー・チーム

• Foundry 上で SQL 分析や Ontology オブジェクト型の探索を行う分析チーム
• AIP のモデル選定、利用権限、トークン費用を管理するAI基盤担当
• Foundry DevOps で複数プロダクトや業務アプリを配布するプラットフォーム運用担当
• Autopilot や Automate を本番業務に組み込んでいる業務アプリ担当

今すぐ対応が必要か

すでに SQL Studio、AIP、Foundry DevOps、Autopilot を使っているチームは、管理画面や利用条件を早めに確認する価値があります。特に Grok Build 0.1 は、対象リージョンと xAI モデルファミリーの有効化が前提になります。Foundry DevOps と Automation events は、既存のリリース手順や障害調査手順に組み込むかを確認するとよさそうです。

一方、これらの機能をまだ使っていない組織では、すぐに移行作業が必要というより、今後の標準運用候補として把握しておく更新です。SQL Studio の一般提供は、Foundry 内の分析作業を広げるきっかけになりやすいため、共有・権限・レビューの方針だけは先に決めておくと導入しやすくなります。

結局、この更新をどう見るべきか

今回の Palantir Foundry 更新は、AIモデル追加だけの記事ではありません。SQL 分析、コーディング向けモデル、複数プロダクトのリリース、自動化処理の監視を同じ日に進めており、Foundry を「作る」「配る」「動かす」「調べる」ための運用面を広げる内容です。本番基盤として使うチームほど、便利さよりも、権限、費用、依存関係、失敗時の調査手順をセットで確認するべき更新です。