Palantir Foundry、開発ライフサイクルのレガシーフェーズを整理

Palantir Foundry の開発ライフサイクル文書では、Foundry プラットフォームの機能が実験段階、ベータ、一般提供、レガシー、サンセット、廃止予定、廃止済みといった段階で説明されています。Python transforms の Code Repositories 編集がレガシーフェーズへ移る案内と合わせて、このライフサイクル定義は Foundry の機能移行を読むための前提になります。

要点

• レガシーは「継続利用できる本番機能だが、積極的な新規開発はない」段階として説明されています。
• レガシーフェーズの機能は、広く導入済みで継続利用でき、一般提供と同様にサポート対象とされています。
• Sunset は将来の非推奨化が予定されるものの、まだ正確な日付がない段階です。
• 廃止予定は、退役日と移行経路が伝えられる段階です。
• Deprecated は、機能や関連 API が利用できず、サポートも終了した状態です。

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

このドキュメントは、Foundry の個別機能がどの成熟度やサポート状態にあるかを読み違えないための基準を示しています。冒頭では、Palantir が顧客の実課題に合わせて本番品質のソフトウェアを継続的に進化させる一方で、機能ごとに開発段階、利用可能性、サポート、公開ドキュメントの状態が異なると説明されています。表では、実験段階、ベータ、一般提供、レガシー、サンセット、廃止予定、廃止済みが並び、開発が続いているか、広く利用できるか、サポートされるか、公開ドキュメントがあるかが整理されています。

レガシーフェーズの定義は、今回特に重要です。公式ページでは、レガシーは機能やプロダクトの作業が完了し、追加の機能開発が見込まれない段階として説明されています。とはいえ、これはすぐ使えなくなるという意味ではありません。レガシーアプリケーションは Palantir の顧客基盤に広くインストールされ、継続的な本番利用に使え、一般提供と同じくサポート対象とされています。新規顧客には opt-in basis で提供されることが多く、積極的な新規開発は止まっていても、フィードバックは新しいアプリケーションやツールへの作業に役立つため歓迎される、と説明されています。

この違いは、Python transforms の Code Repositories 編集がレガシーフェーズに移る案内を読むときに効きます。レガシーと聞くと、すぐに廃止や移行期限を想像しがちですが、Palantir の定義では「新規機能開発の中心ではないが、広く利用され、継続利用とサポートはある」状態です。したがって、既存の Code Repositories 手順を使うチームは、ただちに停止するものとして慌てるのではなく、VS Code ワークスペースへの移行優先度、利用できない enrollment の例外、レビューや CI の手順を計画的に整理する必要があります。

サンセット、廃止予定、廃止済みの違いも実務上の読みどころです。サンセットは将来の廃止予定があるものの、正確な日付はまだ確認されていない段階です。廃止予定では、退役予定日や移行手順が伝えられ、Palantir は管理者への通知や Upgrade Assistant などを使って移行期限を示すと説明しています。廃止済みになると、機能や関連 API は利用できず、サポートも終了し、公開ドキュメントも削除される状態です。この段階差を理解していないと、レガシーを廃止予定と誤解したり、サンセットを単なる注意喚起として軽く見たりするリスクがあります。

また、一般提供についても注意があります。一般提供機能は通常、デフォルトで有効化され、プラットフォームの中核になります。ただし、enrollment によってはインフラ依存や契約条件により、すべての一般提供機能が有効とは限りません。新機能が一般提供と発表されても、特定の Foundry enrollment で利用できるまで1週間以上の遅れがある場合があるとも説明されています。つまり、ライフサイクル表は「使えるはず」という期待だけでなく、自社環境で実際に利用できるかを確認するためのものです。

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

Foundry を管理するプラットフォーム管理者、Python transforms や Code Repositories を使う開発チーム、AIP や Workshop などの機能導入計画を管理するチームに関係します。機能が一般提供、レガシー、サンセット、廃止予定のどこにあるかを、社内手順、移行計画、サポート問い合わせ、利用者への案内に反映する必要があります。

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

まず、自社で使っている Foundry 機能のライフサイクル状態を棚卸しする必要があります。レガシーは今すぐ利用停止ではありませんが、新規開発の中心ではないため、代替機能や推奨環境があるなら移行計画を持つべきです。サンセットや廃止予定が付いた機能は、移行期限、代替ツール、影響するワークフロー、API 利用箇所を確認する必要があります。

次に、一般提供と書かれている機能でも、自社 enrollment で実際に有効かを確認する必要があります。インフラ構成、契約条件、managed SaaS か self-hosted かによって利用可否が変わる場合があります。管理者は、公式ドキュメント、Announcements、Upgrade Assistant、管理者通知を合わせて見て、利用者に誤解のない形で案内することが重要です。

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

Palantir の開発ライフサイクル文書は、機能の成熟度やサポート状態を正しく読むための基準です。特にレガシーフェーズは、廃止ではなく「継続利用とサポートはあるが、新規機能開発の中心ではない」状態として理解する必要があります。Foundry を長期運用するチームは、この定義を移行計画、社内標準、リスク説明に組み込むことで、個別アナウンスを過剰にも過小にも解釈せずに済みます。