Salesforce アンロックパッケージ: モダンなアプリケーション開発への詳細ガイド

背景と適用シナリオ

従来の Salesforce 開発では、変更セット (Change Sets) や Ant 移行ツール (Ant Migration Tool) を利用したメタデータの本番組織へのデプロイが一般的でした。しかし、これらの方法は手動作業が多く、バージョン管理が煩雑で、大規模な開発や複数のチームが関わるプロジェクトでは多くの課題を抱えていました。特に、モノリシック（一枚岩）な構成の組織では、特定の機能改修が他の機能に予期せぬ影響を与える「デグレード」のリスクが常に存在していました。

こうした課題を解決するために、Salesforce は Salesforce DX (Salesforce Developer Experience) という、モダンな開発手法を提唱しました。その中核をなす技術の一つが、今回解説する Unlocked Packages（アンロックパッケージ）です。

Unlocked Packages は、アプリケーションやメタデータをモジュール化し、独立してバージョン管理・デプロイできる強力な仕組みです。これにより、開発チームは自身が担当する機能ドメインに集中でき、より迅速かつ安全にアプリケーションをリリースすることが可能になります。具体的な適用シナリオは以下の通りです。

モノリシック組織のモジュール化: 巨大化した本番組織のメタデータを、機能単位（例：営業支援、顧客サポート、マーケティング）でパッケージに分割し、依存関係を整理する。
社内共通コンポーネントの配布: 複数の部署や関連会社の Salesforce 組織で利用される共通のコンポーネント（Apex トリガーフレームワーク、共通 Lightning Web Components など）をパッケージ化し、一元的に管理・配布する。
CI/CD パイプラインの統合: パッケージのバージョン作成、テスト、プロモーション、デプロイといった一連のプロセスを自動化し、DevOps を実現する。
ISV パートナーのアプリケーション開発: AppExchange で配布する Managed Packages ほど厳格な IP 保護は不要だが、複数の顧客に同じアプリケーションを配布・アップグレードしたい場合に最適です。

原理説明

Unlocked Packages は、Second-Generation Managed Packaging (2GP) の一種であり、ソースコード駆動開発を前提として設計されています。従来のパッケージ（1GP）とは異なり、パッケージの「源」は特定のパッケージング組織ではなく、Git などのバージョン管理システム (Version Control System) にあるソースコードです。

開発の基本的なフローは以下のようになります。

Dev Hub の有効化: 開発のハブとなる本番組織またはトライアル組織で Dev Hub（開発ハブ）機能を有効にします。Dev Hub は、開発用の使い捨て環境である Scratch Orgs（スクラッチ組織）の作成や、パッケージのバージョン管理を行います。
ソースコードの開発: 開発者は、ローカル環境で Salesforce CLI (SFDX) を使用して Scratch Org を作成し、VS Code などのエディタでソースコード（Apex クラス、LWC、オブジェクト定義など）を開発します。
バージョン管理システムへのプッシュ: 開発が完了したソースコードは、Git などのバージョン管理システムにプッシュされます。これが信頼できる唯一のソース (Single Source of Truth) となります。
パッケージバージョンの作成: SFDX CLI を通じて Dev Hub にコマンドを送信し、バージョン管理システム上のソースコードから新しいパッケージバージョンを作成します。このプロセスは非同期で実行されます。
パッケージバージョンのテストとプロモーション: 作成されたパッケージバージョンをサンドボックスなどのテスト環境にインストールして検証します。品質が担保されたバージョンは「プロモート（昇格）」することで、本番組織へのインストールが可能な状態になります。
ターゲット組織へのインストール: プロモートされたパッケージバージョンを、任意のサンドボックスや本番組織にインストールします。既存のバージョンがインストールされている場合は、アップグレードとして扱われます。

この一連のプロセスを支える重要な設定ファイルが sfdx-project.json です。このファイル内で、プロジェクトのディレクトリ構造、どのディレクトリがどのパッケージに属するのか、そしてパッケージ間の依存関係などを定義します。

Unlocked Packages は Managed Packages とは異なり、コンポーネントのソースコードはインストール先の組織で参照・変更が可能です（アンロックされている所以です）。しかし、Unmanaged Packages とは違い、バージョン管理が可能でアップグレードもできるため、アプリケーションのライフサイクル管理に非常に適しています。

サンプルコード

ここでは、SFDX CLI を使用して Unlocked Package を作成し、バージョン管理する一連のコマンドと設定ファイルの例を Salesforce 公式ドキュメントに基づいて紹介します。

1. sfdx-project.json の設定

まず、プロジェクトのルートディレクトリにある sfdx-project.json ファイルで、パッケージの定義を行います。ここでは `my-app` というパッケージを定義しています。

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "my-app",
      "versionName": "ver 0.1",
      "versionNumber": "0.1.0.NEXT"
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "58.0",
  "packageAliases": {
    "my-app": "0HoXXXXXXXXXXXXXXX"
  }
}

【解説】

path: パッケージに含めるメタデータが格納されているディレクトリを指定します。
package: このディレクトリが属するパッケージの名前を定義します。
versionName / versionNumber: パッケージバージョンのエイリアスとバージョン番号のテンプレートです。`NEXT` はバージョン作成時に自動的にインクリメントされるキーワードです。
packageAliases: パッケージ作成後に割り当てられるパッケージ ID (0Ho...) を、人間が分かりやすいエイリアス (`my-app`) にマッピングします。

2. パッケージの作成

Dev Hub 組織にログインした状態で、SFDX CLI を使ってパッケージを作成します。このコマンドは `sfdx-project.json` ファイルを読み取り、Dev Hub 組織にパッケージを登録します。

# Dev Hub組織のエイリアスを my-dev-hub と仮定
# パッケージ名は sfdx-project.json で定義した 'my-app'
# パッケージタイプとして Unlocked を指定

sfdx force:package:create --name "my-app" --description "My Unlocked Package" --packagetype Unlocked --path "force-app" --targetdevhubhub "my-dev-hub"

【解説】

--name: パッケージ名を指定します。`sfdx-project.json` の `package` 属性と一致させます。
--packagetype: `Unlocked` を指定します。
--path: パッケージ化するソースコードのパスを指定します。
--targetdevhubhub: この操作を実行する Dev Hub 組織のエイリアスを指定します。

成功すると、`sfdx-project.json` の `packageAliases` に新しいパッケージ ID (0Ho...) が自動的に追記されます。

3. パッケージバージョンの作成

次に、現在のソースコードのスナップショットとして、新しいパッケージバージョンを作成します。

# -p: パッケージのエイリアスを指定
# -d: バージョン作成の基になるソースディレクトリを指定
# -k: インストールキー（パスワード）を設定
# --wait: コマンドが完了するまで待機する時間（分）
# --json: 結果をJSON形式で出力

sfdx force:package:version:create -p "my-app" -d "force-app" -k "YOUR_INSTALL_KEY" --wait 10 --json

【解説】
このコマンドは非同期で実行され、完了までに数分から数十分かかることがあります。--wait オプションで完了を待つか、後でステータスを確認することができます。成功すると、バージョン ID (04t...) が生成されます。この ID は、特定のバージョンを一意に識別するために使用されます。

4. パッケージバージョンのプロモート

テストが完了したバージョンを、本番環境にインストールできるようプロモート（昇格）します。

# -p: プロモートするパッケージバージョンのID (04t...) を指定
# -n: Dev Hub組織のエイリアスを指定

sfdx force:package:version:promote -p "04tXXXXXXXXXXXXXXX" -n "my-dev-hub"

【解説】
一度プロモートされたバージョンは、削除したり変更したりすることはできません。プロモートは、そのバージョンがリリース可能であることを示す重要なステップです。

5. パッケージのインストール

最後に、プロモートされたパッケージをターゲットの組織（サンドボックスや本番）にインストールします。

# -p: インストールするパッケージバージョンのID (04t...) を指定
# -u: インストール先の組織のエイリアスを指定
# -k: バージョン作成時に設定したインストールキー
# --wait: インストールが完了するまで待機する時間

sfdx force:package:install --package "04tXXXXXXXXXXXXXXX" --targetusername "my-sandbox" --installationkey "YOUR_INSTALL_KEY" --wait 10

注意事項

Unlocked Packages を活用する上で、以下の点に注意が必要です。

権限: 上記の CLI コマンドを実行するユーザーには、Dev Hub 組織に対する適切な権限（「第二世代パッケージの作成と更新」など）が必要です。また、Dev Hub 機能を有効化できるのは Enterprise Edition 以上の組織です。
API 制限: パッケージバージョンの作成はリソースを消費する操作であり、24時間あたりの作成数には上限があります。CI/CD で頻繁にバージョンを作成する場合は、この制限に注意してください。
依存関係の管理: パッケージは他のパッケージに依存できます。例えば、共通オブジェクトを定義した `base-schema` パッケージを、ビジネスロジックを含む `business-logic` パッケージが参照する、といった構成です。この依存関係は sfdx-project.json で明示的に定義する必要があり、依存先のパッケージを先にインストールしないと、依存元のパッケージはインストールできません。
破壊的な変更: 一度パッケージに追加したコンポーネント（カスタム項目、カスタムオブジェクト、Apex クラスなど）を後のバージョンで削除（破壊的変更）することは、原則としてできません。コンポーネントを削除したい場合は、手動でインストール先の組織から削除する必要があります。これは、インストール先の組織でそのコンポーネントが利用されている可能性があるため、パッケージのアップグレードで勝手に削除されないようにするための安全措置です。
メタデータのサポート範囲: すべてのメタデータタイプがパッケージ化に対応しているわけではありません。対応状況は Salesforce の公式ドキュメント「Metadata Coverage Report」で確認してください。未対応のメタデータは、パッケージとは別の方法（従来のメタデータ API など）でデプロイする必要があります。

まとめとベストプラクティス

Unlocked Packages は、Salesforce アプリケーションのライフサイクル管理を劇的に改善する強力なツールです。ソースコード駆動の開発、モジュール化、そして自動化を推進することで、開発チームはより高品質なアプリケーションを迅速に提供できるようになります。

最後に、Unlocked Packages を最大限に活用するためのベストプラクティスをいくつか紹介します。

パッケージを小さく、焦点を絞る: 1つのパッケージには、関連性の高い機能（高凝集）だけを含め、他の機能への依存は最小限（疎結合）に保ちます。これにより、パッケージの再利用性が高まり、メンテナンスも容易になります。
バージョン管理システムを信頼できる唯一のソースとする: すべての変更はバージョン管理システムを通じて行い、組織のメタデータを直接変更する「Source of Truth」の原則を徹底します。
CI/CD パイプラインを構築する: パッケージバージョンの作成、単体テストの実行、サンドボックスへの自動インストール、結合テスト、プロモーション、本番へのデプロイといった一連のプロセスを自動化します。
依存関係を明確に定義する: パッケージ間の依存関係を可視化し、適切に管理します。循環参照（パッケージ A が B に依存し、B が A に依存する）は避けるべきです。
セマンティックバージョニングを採用する: `MAJOR.MINOR.PATCH`（例：2.1.3）のようなバージョニングルールを導入し、変更の性質（破壊的変更、機能追加、バグ修正）がバージョン番号から分かるようにします。

Unlocked Packages への移行は、単なるツールの導入ではなく、開発文化そのものの変革を伴います。しかし、その先には、より堅牢で、スケーラブルで、アジャイルな Salesforce 開発の世界が待っています。

にゃんこのSalesforce日記

このブログを検索