Salesforce Unlocked Package 徹底解説：開発者のためのモジュール型開発ガイド

執筆者：Salesforce 開発者

背景と適用シナリオ

Salesforceプラットフォームでの開発は、その歴史の中で大きく進化してきました。初期の頃は、変更セット (Change Sets) を使って Sandbox から本番環境へメタデータを移行するのが一般的でした。しかし、組織の規模が拡大し、開発チームが複数に分かれ、アプリケーションが複雑化するにつれて、変更セットの管理は困難を極めるようになりました。依存関係の追跡が難しく、バージョン管理も手動で行う必要があり、デプロイメントの失敗も頻繁に発生しました。

このような課題を解決するために登場したのが、Salesforce DX (Developer Experience) という新しい開発手法と、その中核をなす Unlocked Packages (アンロックドパッケージ) です。

Unlocked Packagesは、組織のメタデータをモジュール化し、独立して開発、バージョン管理、デプロイできる強力な仕組みです。これは、従来のモノリシック（一枚岩）な開発スタイルから、マイクロサービスに似た、より近代的でアジャイルな開発スタイルへの移行を可能にします。開発者として、Unlocked Packagesを理解し活用することは、開発の効率性、品質、そしてスケーラビリティを飛躍的に向上させるための鍵となります。

適用シナリオ

大規模アプリケーションのモジュール化: 複雑で巨大な組織のメタデータを、機能単位や共通ライブラリ単位でパッケージに分割し、依存関係を明確にしながら管理します。これにより、各チームは他のチームの影響を最小限に抑えながら、独立して開発とリリースを進めることができます。
社内共通コンポーネントの配布: 複数の部署やプロジェクトで共通して利用するApexクラス、Lightning Web Components、ユーティリティなどを一つのパッケージにまとめ、社内の各組織に簡単に配布・更新できます。
CI/CD パイプラインとの統合: パッケージのバージョン作成、テスト、プロモート、インストールといった一連のプロセスはすべてコマンドラインインターフェース (CLI) で実行できるため、Jenkins、GitHub Actions、CircleCIなどのCI/CDツールとの親和性が非常に高いです。これにより、開発から本番リリースまでのプロセスを完全に自動化できます。
AppExchange アプリの拡張機能開発: ISVが提供するManaged Packageの機能を拡張するようなアドオンを、Unlocked Packageとして開発・管理することができます。

原理の説明

Unlocked Packagesは、Second-Generation Managed Packaging (2GP) の一種です。しかし、AppExchangeで配布されるようなIP保護が目的のManaged Packageとは異なり、主に社内での開発や組織間のメタデータ配布を目的としています。その動作原理を理解するために、いくつかの重要な概念を見ていきましょう。

1. ソース駆動 (Source-Driven) 開発: Unlocked Packagesの最大の特徴は、信頼できる唯一の情報源 (Single Source of Truth) がSalesforce組織ではなく、バージョン管理システム（VCS、例：Git）にあることです。開発者はローカル環境でコードを書き、Gitで管理し、そのソースコードから直接パッケージバージョンを作成します。これにより、変更の追跡やコードレビューが容易になります。

2. Dev Hub とスクラッチ組織: 開発プロセス全体を管理する中心的な組織が Dev Hub (開発ハブ) です。Dev Hub組織でUnlocked Packagesの作成やバージョン管理を行います。実際の開発やテストは、Scratch Orgs (スクラッチ組織) と呼ばれる、使い捨てのSalesforce環境で行うのが一般的です。スクラッチ組織はDev Hubから簡単に作成・破棄でき、常にクリーンな環境でパッケージの動作確認ができます。

3. `sfdx-project.json` ファイル: プロジェクトのルートディレクトリにあるこのJSONファイルが、Salesforce DXプロジェクト全体の設定を定義します。特に、どのディレクトリがどのパッケージに属するのか、パッケージ間の依存関係は何か、といった情報を記述する、いわばプロジェクトの設計図です。

4. パッケージのライフサイクル: Unlocked Packageの開発は、以下のサイクルを繰り返します。

パッケージの作成 (`package create`): Dev Hub組織にパッケージを登録します。これはプロジェクトの初期に一度だけ行います。
パッケージバージョンの作成 (`package version create`): Gitの特定のコミット時点のソースコードを元に、不変のパッケージバージョンを作成します。このバージョンには `04t` から始まるIDが付与され、`1.0.0.1` のようなバージョン番号が付けられます。このプロセスでApexテストが実行され、コードカバレッジが検証されます。
バージョンのプロモート (`package version promote`): 作成したバージョンがベータ版からリリース版に昇格します。本番環境にインストールできるのは、プロモートされたリリース版のみです。
パッケージのインストール (`package install`): 特定のバージョンをスクラッチ組織、Sandbox、または本番環境にインストールします。アップグレードやアンインストールも可能です。

この仕組みにより、開発者は個々のメタデータではなく、「バージョン管理されたパッケージ」という単位でアプリケーションを管理できるようになります。これにより、デプロイメントの信頼性が格段に向上するのです。

サンプルコード

ここでは、Salesforce CLI を使用して Unlocked Package を作成し、バージョン管理する具体的な手順をコードと共に解説します。これらのコマンドは、Salesforce DX プロジェクトのルートディレクトリで実行することを前提としています。

ステップ1: `sfdx-project.json` の設定

まず、プロジェクトの構成ファイルである `sfdx-project.json` でパッケージを定義します。`force-app` ディレクトリを `my-awesome-app` という名前のパッケージとして定義する例です。

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

解説:
・`path`: パッケージに含めるメタデータのソースファイルが格納されているディレクトリを指定します。
・`package`: このパッケージディレクトリに付けるエイリアス（別名）です。
・`versionNumber`: `MAJOR.MINOR.PATCH.BUILD` 形式のバージョン番号です。`NEXT` は、バージョン作成時にCLIが自動的にビルド番号をインクリメントすることを示します。
・`packageAliases`: パッケージを作成すると、`0Ho` から始まるパッケージIDがここに自動的に設定されます。

ステップ2: パッケージの作成

次に、Dev Hub組織に対してパッケージを作成（登録）します。このコマンドはプロジェクトごとに一度だけ実行します。

# Dev Hub 組織にログインしていることを確認
# -v は Dev Hub のエイリアス
sf package create --name "My Awesome App" --description "Core functionality for my awesome application" --package-type Unlocked -v MyDevHub

解説:
・`--name`: パッケージの名前を指定します。
・`--package-type`: パッケージの種類を `Unlocked` に指定します。
・`-v MyDevHub`: このコマンドを実行する対象となるDev Hub組織のエイリアスを指定します。
このコマンドが成功すると、`sfdx-project.json` の `packageAliases` に、パッケージ名と `0Ho` から始まるIDのマッピングが追加されます。

ステップ3: パッケージバージョンの作成

ソースコードの準備ができたら、インストール可能なパッケージバージョンを作成します。このコマンドはDev Hub組織に対して実行され、バックグラウンドでApexテストの実行やメタデータの検証が行われます。

# -p は sfdx-project.json で定義したパッケージのエイリアス
# -d はパッケージ化するソースコードのディレクトリ
# --wait はコマンドが完了するまで待機する時間（分）
# --code-coverage はコードカバレッジの計算を強制する
sf package version create --package "my-awesome-app" --path force-app --installation-key-bypass --wait 10 --code-coverage

解説:
・`--package`: `sfdx-project.json` で定義したパッケージのエイリアスを指定します。
・`--installation-key-bypass`: インストールキーなしでインストールできるようにします。社内向けパッケージでは一般的に使用されます。
・`--wait 10`: バージョン作成プロセスが完了するまで最大10分間待機します。完了すると、`08c` から始まるパッケージバージョンIDが返されます。
・`--code-coverage`: このパッケージに含まれるApexコードのカバレッジを計算し、75%未満の場合はバージョン作成を失敗させます。品質を担保するために非常に重要なオプションです。

ステップ4: パッケージバージョンのインストール

作成したパッケージバージョンを、テスト用のスクラッチ組織やSandboxにインストールします。

# -o はインストール対象組織のエイリアス
# -p はインストールするパッケージバージョンのID (08c...) またはエイリアス
sf package install --package "my-awesome-app@0.1.0-1" -o MyScratchOrg --wait 10

解説:
・`--package`: `パッケージエイリアス@バージョン番号` の形式で指定します。`08c...` のIDを直接指定することも可能です。
・`-o MyScratchOrg`: インストール先の組織（スクラッチ組織やSandbox）のエイリアスを指定します。
・`--wait 10`: インストールが完了するまで最大10分間待機します。

以上の手順を CI/CD パイプラインに組み込むことで、Gitへのプッシュをトリガーに、パッケージのビルド、テスト、デプロイを自動化することができます。

注意事項

Unlocked Packagesを導入・運用する際には、いくつかの注意点があります。

権限: パッケージを作成・管理するには、Dev Hub組織で「第二世代パッケージの作成と更新」システム権限が必要です。また、パッケージをインストールする先の組織では「パッケージのダウンロード」権限を持つユーザである必要があります。
依存関係の管理: パッケージは他のパッケージに依存することができます。例えば、共通のユーティリティクラスを `common-lib` パッケージとして作成し、`feature-a` パッケージがそれに依存する、といった構成です。この依存関係は `sfdx-project.json` で明示的に定義する必要があります。循環依存（AがBに依存し、BがAに依存する）は許されないため、アーキテクチャ設計が非常に重要になります。
メタデータのサポート範囲: すべてのメタデータタイプがパッケージ化に対応しているわけではありません。対応状況は Salesforce が提供している Metadata Coverage Report で確認する必要があります。対応していないメタデータは、引き続き従来のデプロイ方法（Source Deployなど）を併用する必要があります。
破壊的変更 (Destructive Changes): パッケージの新しいバージョンでApexクラスや項目を削除する場合、注意が必要です。コンポーネントをパッケージから削除しても、インストール先の組織から自動的に削除されるわけではありません。削除するには、別途破壊的変更 (`destructiveChanges.xml`) を用いたデプロイが必要です。
Apexのテスト要件: 本番環境にインストールするパッケージバージョンは、パッケージ内のApexコードが75%以上のコードカバレッジを満たしている必要があります。これは、変更セットのデプロイ要件と同様ですが、パッケージ単位で厳密に適用されます。

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

Unlocked Packagesは、現代のSalesforce開発におけるデファクトスタンダードとなりつつある強力なツールです。ソース駆動開発を基本とし、メタデータをバージョン管理可能なモジュールとして扱うことで、開発チームの生産性とアプリケーションの品質を大幅に向上させることができます。

開発者としてUnlocked Packagesを最大限に活用するためのベストプラクティスを以下に示します。

小さく始める: 既存の巨大な組織を一度にすべてパッケージ化しようとしないでください。まずは独立した新しい機能や、共通のユーティリティなど、依存関係の少ない部分からパッケージ化を試みるのが成功への近道です。
明確なパッケージ戦略を立てる: アプリケーションをどのように分割するか、アーキテクチャの設計が最も重要です。機能単位（ドメイン駆動）、技術レイヤー単位（トリガーフレームワーク、UIコンポーネントなど）、あるいはその両方の組み合わせなど、プロジェクトに合った分割戦略をチームで議論し、決定してください。
依存関係は一方向に保つ: パッケージ間の依存関係は、できるだけシンプルで一方向になるように設計します。循環依存は絶対に避けなければなりません。共通基盤となるパッケージを明確に定義することが重要です。
CI/CDによる自動化を徹底する: パッケージバージョンの作成、テスト、プロモート、組織へのインストールといった一連の作業は、すべて自動化すべきです。手作業をなくすことで、ミスを減らし、迅速なリリースサイクルを実現します。
セマンティックバージョニングを採用する: `MAJOR.MINOR.PATCH` (例: `2.1.5`) のようなセマンティックバージョニングルールをチームで採用し、バージョンの変更が何を意味するのか（破壊的変更、機能追加、バグ修正）を明確にしましょう。

Unlocked Packagesへの移行は、単なるツールの変更ではなく、開発文化そのものの変革を伴います。しかし、この変革を受け入れ、正しく実践することで、あなたのチームとSalesforce組織は、より堅牢で、スケーラブルで、管理しやすい未来を手に入れることができるでしょう。

にゃんこのSalesforce日記

このブログを検索