Palantir 2026年5月5日のリリースノート解説: Global Branching GA 予定

Palantir は 2026年5月5日、Global Branching が 2026年5月18日の週から全 users / all enrollments で generally available になる予定だと発表しました。Foundry 上の複数 application にまたがる変更を branch で作り、end-to-end に test し、Main へ merge するための基盤です。

要点

• Global Branching は 2026年5月18日の週から GA 予定
• transforms、TypeScript v1 functions repositories、Pipeline Builder、Ontology、Workshop、AIP Logic、Object Views が対象
• branch 上で resources を変更し、Main の更新取り込み、conflict 解決、approval、merge を扱える
• merge permission と branch lifecycle の security model が更新される
• Restricted Views と Automate は beta として branching support が始まる

今回のリリースノートで語られていること

Global Branching は、Foundry を大規模な業務開発基盤として使う組織にとって重要な変更です。従来のようにアプリや pipeline ごとに個別に変更を管理するのではなく、Ontology、Workshop、AIP Logic、Pipeline Builder などをまたいだ変更を一つの branch 上で扱い、本番に影響を与えずに開発・検証・merge できる方向へ進みます。業務アプリ、データ変換、AI Logic が密につながる環境では、変更の一部だけを安全に試せても、全体の整合性を確認できなければ本番リスクは残ります。Global Branching はその問題に対する Palantir 側の答えです。

発表では、branch and modify resources、remove resources、Main からの更新取り込みと conflict 解決、protected resources、approval policies、branched resources の trace、checks clear 後の merge などが示されています。これはソフトウェア開発の Git workflow に近い考え方を、Foundry の ontology / workflow / application resources へ広げるものです。ただし、通常の code repository と違い、対象は業務データや権限、AI Logic、アプリ UI を含みます。そのため、誰が branch を作れるか、誰が review するか、どの checks が merge 前に必要かを、アプリ所有者と platform 管理者が明確にする必要があります。

security model と branch lifecycle の変更も見逃せません。merge は専用 branch role ではなく、proposal を view できる user が approvals と checks を満たした後に実行できる形へ変わります。一方で branch owner は Do not merge setting で merge を止められます。inactive branches では ontology resources が de-index され、data は eventually deleted される一方、logic は保持されると説明されています。開発の自由度が上がる分、branch の棚卸し、archive / restore、approval policy の設計が運用上の焦点になります。

対象になりそうなチーム

• Foundry 上で Ontology、Workshop、AIP Logic、Pipeline Builder を運用する platform team
• 本番業務アプリの変更管理と approval を担う product owner
• Foundry resources の development / test / production workflow を整備する governance team

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

Global Branching を使う前に、対象 application ごとの support 範囲、approval policy、branch owner、merge 権限、inactive branch の扱いを確認します。既存の本番変更手順が branch / proposal / checks / merge に置き換わる部分と、従来の change management が残る部分を分けておくと混乱を避けやすくなります。

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

Global Branching GA は、Foundry を業務アプリ開発基盤として本格運用するための変更管理機能です。便利な開発機能というより、複数アプリにまたがる変更を安全に本番へ送るための governance layer として見るべきです。