Palantir Foundry 2026年6月16日のリリースノート解説: SQL Studio 一般提供の確認点

Palantir Foundry Announcements では 2026年6月16日、SQL Studio が 6月15日の週から一般提供になったことが案内されました。Foundry 内で SQL を使う分析作業を、専用アプリ、AI支援、ワークシート共有、書き込み操作まで含めて扱う更新です。

要点

• SQL Studio は、Foundry 内で SQL を書き、実行し、結果を確認するための専用アプリとして一般提供になりました
• 表形式データと Ontology オブジェクト型を同じアプリから扱い、Furnace と Ontology SQL を用途に応じて使います
• AIP の会話型サイドパネルが、クエリ作成、説明、デバッグを支援します
• SQL ワークシートの保存、共有、履歴復元、複数タブ作業、表やチャートでの結果確認が説明されています
• 管理者は Control Panel の Application access ページから SQL Studio を無効化できます

今回の更新で変わること

今回の公式項目で重要なのは、SQL Studio が単なる新しい編集画面ではなく、Foundry 内の SQL 作業を一つの専用アプリへ集める位置づけで一般提供になった点です。これまでも Dataset Preview、Data Lineage、Ontology Manager などには文脈付きの SQL コンソールがありましたが、SQL Studio はその体験を独立した作業場所として拡張します。分析者は表形式データだけでなく、Ontology のオブジェクト型も SQL から扱えるため、テーブルの列を直接見る分析と、業務概念として整理されたオブジェクトをたどる分析を同じ入口で進めやすくなります。

技術面では、表形式データ向けの Furnace と、オブジェクト型や多対多リンクを扱う Ontology SQL が説明されています。どちらも共通の Spark SQL 方言を前提にしており、Furnace は処理内容に応じて Trino と Spark を使い分けます。Ontology SQL は、対応するクエリ形状ではインメモリの計算経路を使い、複雑な処理は Spark に回すとされています。つまり、利用者に見える価値は「SQL で書ける」だけではなく、用途に合わせた実行基盤が裏側で選ばれることにあります。

操作面では、ワークシートを個人用に保存したり、プロジェクト内で同僚と共有したり、保存ごとの版を確認して復元したりできます。結果は表として見るだけでなく、折れ線、棒、散布図、円、ヒストグラムなどのチャートでも確認できます。既定では 1,000行のプレビューが返り、適切な権限を持つ利用者は 1回の実行で最大 10,000行まで取得できると説明されています。また、複数の編集タブを開けるため、調査用の一時的な SQL と、共有するワークシートを分けて作業しやすくなります。

AI支援もこの更新の中心です。AIP の会話型サイドパネルは、現在の編集内容、参照しているデータセット、テーブル、オブジェクト型のスキーマを踏まえて、クエリ作成、説明、デバッグを助けます。これは SQL に詳しくない利用者の入口を広げる一方で、生成された SQL の意味、対象データ、フィルター条件、権限、結果の使い道を人が確認する必要があることも意味します。特に業務判断や本番処理につながる分析では、AI支援を「下書きの補助」として扱い、レビューと再現性を運用に組み込むことが重要です。

さらに、SELECT だけでなく、データセットへの CREATE TABLE、Iceberg テーブルへの CREATE、INSERT、UPDATE、DELETE、対応関数を確認する SHOW FUNCTIONS も挙げられています。書き込み操作まで扱えるため、SQL Studio を分析用の読み取り画面としてだけ見ると運用設計を見誤ります。誰に書き込み権限を与えるのか、どのワークシートを共有対象にするのか、変更結果をどうレビューするのかを合わせて確認したい更新です。

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

• Foundry 上で SQL 分析や探索的なデータ確認を行う分析チーム
• Ontology オブジェクト型を使って業務データを扱うアプリケーション担当
• SQL の書き込み操作、Iceberg テーブル、共有ワークシートの権限を管理するデータ基盤担当
• AIP によるクエリ作成支援を利用者に開放するか判断する管理者
• Foundry 内の分析作業を標準化したいプラットフォーム運用担当

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

まず確認したいのは、SQL Studio を誰に開放するかです。公式項目では、管理者が Control Panel の Application access ページから SQL Studio を無効化できることも明記されています。これは、一般提供だから全員にすぐ開けるべきという意味ではありません。表形式データ、Ontology オブジェクト型、Iceberg テーブル、SQL 関数を扱うため、利用者の役割に応じて読み取り、書き込み、共有の範囲を分ける設計が必要です。

次に、ワークシートの扱いです。個人の調査メモとして使うワークシートと、チームで再利用するワークシートでは、求められるレビュー水準が違います。意思決定やダッシュボードの根拠になる SQL は、誰が保存し、誰が復元でき、どの版が正とされるのかを決めておくと、後から結果の違いを説明しやすくなります。

AI支援をどう扱うべきか

SQL Studio の AIP サイドパネルは、利用者の現在の編集内容や参照スキーマを見ながら、クエリの作成、説明、デバッグを助けるとされています。これは便利ですが、生成された SQL が業務上正しいとは限りません。たとえば、期間条件、除外条件、オブジェクト型の意味、結合の前提がずれると、見た目には動く SQL でも判断材料としては危険になります。

導入時は、AI支援で作った SQL をそのまま共有ワークシートや本番処理へ進めるのではなく、レビュー対象として扱うのが現実的です。SQL の意味を説明できるか、想定する件数や結果と合っているか、不要なデータに触れていないか、権限上許される範囲に収まっているかを確認する手順を決めておきたいところです。

書き込み操作とベータ機能の注意点

今回の項目では、読み取りだけでなく書き込み操作も説明されています。データセット作成や Iceberg テーブルの更新ができる環境では、SQL Studio は分析画面であると同時に、データを変える入口にもなります。そのため、変更系の操作を許す利用者、検証用と本番用の分離、誤操作時の復旧方針を合わせて確認する必要があります。

また、Ontology SQL functions はベータとして説明され、すべての Foundry 環境で有効ではないとされています。Workshop、Actions、Automate、Ontology SDK などで再利用できる可能性がある一方、利用可否や有効化の条件は環境によって異なります。すぐに標準化する前に、対象環境で使えるか、どの処理形状が低遅延で動くか、誰が公開できるかを確認したい機能です。

今すぐ対応が必要か

すでに Foundry で SQL 分析を広く使っている組織では、早めに利用権限と共有方針を確認する価値があります。特に、AI支援、ワークシート共有、書き込み操作を同時に開放する場合は、便利さよりもレビューと権限設計が先です。

一方、まだ SQL Studio を本格利用していない組織では、すぐに移行するというより、代表的なデータセットや Ontology オブジェクト型で試し、既存の SQL コンソール作業や分析ノートをどこまで置き換えられるかを見る段階です。近い将来の予定として Global Branching、Marketplace パッケージ化、Git ベースの CI/CD 開発ワークフローとの連携、再利用可能な SQL ストアドプロシージャも挙げられているため、長期的には分析から本番化までの作業場所として広がる可能性があります。

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

SQL Studio の一般提供は、Foundry 内の SQL 体験を、補助的なコンソールから専用の分析アプリへ引き上げる更新です。表形式データ、Ontology オブジェクト型、AI支援、ワークシート共有、書き込み操作が一つに集まるため、利用者にとっては作業しやすくなります。そのぶん、管理者やデータ基盤担当にとっては、権限、レビュー、共有、変更管理を明確にする必要が高まる更新です。