Palantir Foundry、VS Code ワークスペースを開発環境として案内

Palantir Foundry のドキュメントで、VS Code ワークスペースの概要が案内されています。Foundry 上の Code ワークスペースを使い、Python transforms、OSDK React アプリケーション、Compute modules などを VS Code の操作感で開発するための環境です。

要点

• VS Code ワークスペースは、Palantir infrastructure 上にデプロイされる VS Code ベースの開発環境として説明されています。
• Python transforms、OSDK React アプリケーション、Compute modules、Python libraries などの開発ワークフローを対象にしています。
• Palantir extension for Visual Studio Code が Python 環境の自動設定や Foundry リソースとの連携を担います。
• Code Repositories はプルリクエストレビューやリポジトリ管理を含むコード管理向け IDE、VS Code ワークスペースは編集体験と Foundry 統合を重視する環境として位置づけられています。
• 既存または新規の対応リポジトリから VS Code を開け、既定エディタとして設定できるとされています。

今回の公式ドキュメントで語られていること

今回の VS Code ワークスペース文書は、Foundry の開発者体験をどの環境へ寄せるかを示すページです。公式ページでは、VS Code ワークスペースは Microsoft の VS Code IDE の操作感を Palantir platform に持ち込み、Code ワークスペースを使って本番向けコードを書くための統合開発環境として説明されています。対象は Python transforms だけではありません。OSDK React アプリケーション、Compute modules、Python libraries など、Foundry 内でコードを書く複数のワークフローにまたがっています。自動的な環境設定と Foundry リソースとの連携を備える点が、単なるローカルエディタ利用との違いです。

Python transforms の文脈では、Palantir extension for Visual Studio Code が起動時に Python 環境を設定し、Foundry での変換開発に必要な作業を支援するとされています。データ変換を日常的に書くチームにとっては、エディタが変わるだけではなく、依存関係、事前確認、デバッグ、ビルド、ターミナル操作をどこで行うかが変わります。これまで Code Repositories 上の操作や社内手順を前提にしていた場合、VS Code ワークスペースで同じレビュー、テスト、実行確認、権限管理ができるかを確認する必要があります。

ドキュメントは、Code Repositories と VS Code の役割も分けています。Code Repositories は、編集、バージョン管理、変更管理、継続的インテグレーションを含む Palantir-built IDE として、プルリクエストレビューやリポジトリ管理に向く環境です。一方、VS Code ワークスペースは、Foundry platform からアクセスできる VS Code 環境であり、Palantir extension によって Foundry リソースと統合されます。つまり、既存の Code Repositories を完全に否定する内容ではなく、コード編集と統合開発の中心を VS Code 側へ広げる案内として読むのが適切です。

使い始める導線も実務上のポイントです。既存または新規の対応リポジトリを VS Code で開けること、Code Repositories の画面から Open in VS Code を選べること、新規リポジトリ作成時に VS Code を選ぶとワークスペースに入れることが説明されています。また、対応リポジトリ種別では VS Code を既定のコードエディタに設定でき、種類によっては設定に関係なく VS Code で開くものもあります。これは、開発チームの標準エディタ、オンボーディング資料、レビュー手順に影響する変更です。

このページで注意したいのは、VS Code ワークスペースが Palantir のインフラ上で動く環境である点です。ローカルの VS Code 拡張機能と、Foundry プラットフォームから使う VS Code ワークスペースは別の選択肢として説明されています。ローカル環境での拡張機能利用、Foundry 上のワークスペース、Code Repositories のどれを標準にするかは、ネットワーク、認証、データアクセス、開発者端末の制約によって変わります。特にデータ変換やアプリケーションコードが本番データや Ontology に近い場合、便利な編集体験だけでなく、どの環境にどの権限を持たせるかを合わせて決める必要があります。

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

Foundry 上で Python transforms、OSDK React アプリケーション、Compute modules、Python libraries を開発しているチームに関係します。開発基盤を管理する管理者、社内の Foundry 開発標準を決めるチーム、Code Repositories から VS Code ワークスペースへの移行を検討するチームは確認しておきたい内容です。

実務で確認したいポイント

まず、どのリポジトリ種別が VS Code ワークスペースの対応対象なのかを確認する必要があります。Python transforms は対象でも、すべての既存リポジトリやワークフローが同じように移れるとは限りません。次に、プルリクエストレビュー、CI、権限、シークレットの扱い、データセット事前確認、ターミナル実行、デバッグの手順を、Code Repositories と VS Code ワークスペースのどちらで行うかを整理する必要があります。

社内標準にする場合は、既定エディタ設定だけでなく、例外運用も決めておきたいです。ローカルの VS Code 拡張機能を使う人、Foundry 上のワークスペースを使う人、Code Repositories を使い続ける人が混在すると、トラブルシュートやレビュー時の前提がずれます。管理者は、利用可能な組織、Code ワークスペースのコンピュート使用量、アクセス制御、監査ログを合わせて確認するとよさそうです。

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

VS Code ワークスペースの案内は、Foundry の開発体験を一般的な VS Code の操作感へ近づける動きとして読めます。ただし、データ基盤の開発ではエディタの使いやすさだけで判断できません。Python transforms やアプリケーションコードがデータ、ontology、権限、CI に接続されるため、導入するチームは開発者体験とガバナンスの両方を確認しながら標準化する必要があります。