Salesforce Unlocked Packages: モジュール型開発とデプロイへのモダンアプローチ

執筆者：Salesforce アーキテクト

背景と応用シナリオ

Salesforceプラットフォームにおけるアプリケーションライフサイクル管理 (Application Lifecycle Management, ALM) は、長年にわたり進化を続けてきました。かつては変更セット (Change Sets) や Ant Migration Tool を用いた、いわゆる「組織駆動型 (Org-driven)」の開発が主流でした。しかし、このアプローチは、大規模なチームや複雑なプロジェクトにおいては、メタデータの依存関係の管理、バージョン管理の困難さ、デプロイの信頼性の低さといった課題を抱えていました。

こうした課題を解決するために登場したのが、Salesforce DX (Developer Experience) の中核をなすUnlocked Packages (アンロックドパッケージ) です。Unlocked Packagesは、ソースコード駆動型 (Source-driven) の開発モデルを前提とした、より近代的で柔軟なパッケージングおよびデプロイの仕組みです。Salesforceアーキテクトの視点から見ると、これは単なるデプロイツール以上の意味を持ちます。それは、アプリケーションアーキテクチャをモジュール化し、責務を分離し、スケーラブルで保守性の高いシステムを構築するための戦略的基盤となるのです。

応用シナリオは多岐にわたります。

大規模エンタープライズアプリケーションの分割：モノリシック（一枚岩）な組織のメタデータを、機能ドメインごと（例：販売、サービス、マーケティング）に独立したパッケージに分割する。これにより、各チームは他のチームへの影響を最小限に抑えながら、自律的に開発とリリースを進めることが可能になります。
共通コンポーネントの再利用：複数のビジネスユニットやプロジェクトで共通して利用されるコンポーネント（Lightning Web Components、Apexユーティリティクラス、カスタムオブジェクトなど）をベースとなるパッケージとして切り出し、共有ライブラリのように利用する。
ISV (独立系ソフトウェアベンダー) アプリケーションの拡張：AppExchangeで提供される管理パッケージ (Managed Package) の機能を補完または拡張するアドオン機能を、Unlocked Packagesとして開発・配布する。
段階的なリファクタリング：既存の巨大なコードベースを一度に刷新するのではなく、特定の機能から順にUnlocked Packagesに切り出し、段階的にモダンなアーキテクチャへと移行する。

Unlocked Packagesを導入することは、技術的な変更だけでなく、開発文化そのものを変革するきっかけとなります。アーキテクトとして、この強力なツールを理解し、プロジェクトの特性に合わせて最適なパッケージ分割戦略を設計することが、成功への鍵となります。

原理説明

Unlocked Packagesの仕組みを理解するためには、いくつかの重要な概念を把握する必要があります。これらはすべてSalesforce DXのフレームワーク上で機能します。

Dev Hub とスクラッチ組織

Dev Hub (開発ハブ) は、Unlocked Packagesのライフサイクル全体を管理する特別なSalesforce組織です。通常、本番組織または特別なDeveloper Edition組織をDev Hubとして有効化します。Dev Hubは、作成したパッケージやそのバージョン情報を一元的に追跡・管理する「信頼できる唯一の情報源 (Single Source of Truth)」となります。また、スクラッチ組織 (Scratch Orgs) という、一時的で設定可能な使い捨てのSalesforce組織を作成する機能も提供します。開発者はこのスクラッチ組織上でパッケージのコンポーネントを開発し、テストを行います。

パッケージとパッケージバージョン

パッケージ (Package) は、sfdx-project.jsonファイルで定義されるメタデータコンポーネントの集合体です。どのメタデータをどのパッケージに含めるかは、このファイル内のディレクトリパスによって指定されます。アーキテクチャ設計の観点からは、このファイルがアプリケーション全体の構成図となります。

パッケージバージョン (Package Version) は、ある時点でのパッケージのメタデータの不変なスナップショットです。一度作成されたパッケージバージョンの内容は変更できません。バージョン番号（例：1.2.0.3）が付与され、このバージョンを特定の組織（サンドボックス、本番）にインストールすることになります。この不変性により、どの組織に何がデプロイされているかが明確になり、リリースの再現性と信頼性が劇的に向上します。

依存関係 (Dependencies)

Unlocked Packagesの最も強力な機能の一つが、パッケージ間の依存関係 (Dependencies) を明示的に定義できることです。例えば、「共有コンポーネントパッケージ」に依存する「販売管理パッケージ」を作成できます。この場合、「販売管理パッケージ」をインストールする組織には、事前に指定されたバージョンの「共有コンポーネントパッケージ」がインストールされている必要があります。SFDX CLIがこの依存関係を解決し、インストールを制御してくれます。アーキテクトは、この機能を利用して、クリーンで階層的なアプリケーションアーキテクチャを構築できます。

ソース駆動型開発モデル

Unlocked Packagesは、バージョン管理システム（Gitなど）を信頼できる情報源とするソース駆動型開発を前提としています。開発者はローカル環境でコードを書き、変更をGitにコミットします。CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインがその変更を検知し、自動的にパッケージバージョンを作成し、テストを実行し、検証済みバージョンを次の環境にデプロイします。組織内のメタデータではなく、リポジトリ内のソースコードが「正」となるのです。

サンプルコード

ここでは、Salesforce DX CLI を使用して Unlocked Package を作成し、バージョンを上げ、組織にインストールするまでの基本的な流れを、公式ドキュメントに基づいたコマンドで示します。これらのコマンドはプロジェクトのルートディレクトリで実行することを想定しています。

1. パッケージを作成する

まず、sfdx-project.json ファイル内でパッケージを定義した後、Dev Hub組織にそのパッケージの存在を登録します。force-app ディレクトリ内のメタデータを `my-app-package` という名前のパッケージとして定義する例です。

# my-app-package という名前の Unlocked Package を作成します。
# --name: パッケージの名前 (英数字とアンダースコアのみ)
# --description: パッケージの説明
# --type: パッケージの種別。Unlocked を指定します。
# --path: パッケージに含めるメタデータが格納されているディレクトリ
# --target-dev-hub: パッケージ情報を登録する Dev Hub 組織のエイリアス
sf package create --name "my-app-package" --description "My application package" --type Unlocked --path "force-app" --target-dev-hub MyDevHub

成功すると、sfdx-project.json ファイルにパッケージID（0Ho...）が追記されます。

2. パッケージバージョンを作成する

次に、現在のソースコードのスナップショットとして、不変のパッケージバージョンを作成します。このプロセス中に、Salesforceはバックグラウンドでビルド組織を立ち上げ、メタデータのコンパイルやApexテストの実行を行います。

# my-app-package の新しいバージョンを作成します。
# --package: バージョンを作成するパッケージの名前またはID
# --installation-key: インストール時に要求するパスワード (オプション)
# --wait: コマンドが完了するまで待機する時間（分）
# --code-coverage: Apexコードカバレッジの計算を強制します。本番インストールには75%以上が必要です。
# --target-dev-hub: パッケージバージョンを作成・管理する Dev Hub 組織のエイリアス
sf package version create --package "my-app-package" --installation-key "MyTestKey123" --wait 20 --code-coverage --target-dev-hub MyDevHub

このコマンドは完了までに時間がかかることがあります。成功すると、パッケージバージョンID（04t...）が返されます。これが、特定の組織にインストールするためのIDとなります。

3. パッケージバージョンをインストールする

最後に、作成したパッケージバージョンをターゲットとなる組織（スクラッチ組織、サンドボックス、本番）にインストールします。

# 指定したパッケージバージョンをターゲット組織にインストールします。
# --package: インストールするパッケージバージョンID (04t...)
# --installation-key: バージョン作成時に設定したパスワード
# --target-org: インストール先の組織のエイリアス
# --wait: インストールが完了するまで待機する時間（分）
sf package install --package "my-app-package@1.0.0-1" --installation-key "MyTestKey123" --target-org MyTestSandbox --wait 10

my-app-package@1.0.0-1 の部分は、バージョン作成時に返されたパッケージバージョンID (`04t...`) やエイリアスに置き換えることができます。

注意事項

Unlocked Packagesをアーキテクチャの柱として採用する際には、いくつかの重要な点に注意を払う必要があります。

依存関係の管理

循環依存 (Circular Dependency) は絶対に避けなければなりません。これは、パッケージAがパッケージBに依存し、同時にパッケージBがパッケージAに依存する状態です。このような構造はパッケージバージョンを作成できなくなり、開発プロセス全体を停止させる可能性があります。アーキテクチャ設計の初期段階で、パッケージ間の依存関係を一方向の有向非巡回グラフ (DAG) として明確に定義することが極めて重要です。

パッケージの粒度

「一つのパッケージにどれだけのメタデータを含めるべきか」は、常に議論の的となります。

ファイングレイン（細かい粒度）：多くの小さなパッケージを作成するアプローチ。再利用性が高く、独立したデプロイが可能ですが、パッケージ間の依存関係が複雑化し、管理オーバーヘッドが増大する可能性があります。
コースグレイン（粗い粒度）：少数の大きなパッケージを作成するアプローチ。管理は容易ですが、モノリシックな構造に逆戻りし、チーム間の結合度が高まり、デプロイのリードタイムが長くなるリスクがあります。

アーキテクトは、組織の構造、チームのスキルセット、アプリケーションのドメイン境界を考慮し、最適なバランスを見つける必要があります。

破壊的変更 (Destructive Changes)

パッケージからコンポーネント（Apexクラス、オブジェクト項目など）を削除することは、単純な「ソースコードからファイルを削除する」操作では完了しません。コンポーネントを削除した新しいバージョンをアップグレードインストールしても、古いバージョンのコンポーネントは組織に残り続けます。コンポーネントを組織から物理的に削除するには、アンインストールするか、別途メタデータAPIによる削除デプロイを実行する必要があります。この挙動を理解し、コンポーネントの廃止プロセスを計画に含めることが重要です。

権限とDev Hubの設定

Dev Hub組織と、それを利用するユーザーには適切な権限が必要です。ユーザーには「Salesforce DX」権限セットを割り当てる必要があります。また、Dev Hub組織自体でパッケージ作成機能を有効化しておく必要があります。

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

Unlocked Packagesは、Salesforce開発を現代的なDevOpsプラクティスへと導くための強力なパラダイムシフトです。アーキテクトとしてこの技術を最大限に活用するためには、以下のベストプラクティスを推奨します。

設計第一のアプローチ：コードを書き始める前に、アプリケーション全体のアーキテクチャを設計し、パッケージの境界と依存関係を明確に定義します。ドメイン駆動設計 (Domain-Driven Design) の概念を取り入れ、ビジネスの境界と一致するパッケージを作成することが理想的です。
依存関係の可視化：パッケージ依存関係グラフを図として文書化し、チーム全体で共有します。これにより、開発者は自身の変更がシステム全体に与える影響を理解しやすくなります。
厳格なバージョン管理：セマンティックバージョニング (例: `MAJOR.MINOR.PATCH`) などの一貫したバージョン管理戦略を採用し、どのバージョンがどの環境にデプロイされているかを常に追跡します。
CI/CDの完全自動化：パッケージバージョンの作成、テスト、およびデプロイのプロセスをCI/CDパイプラインに組み込み、完全に自動化します。これにより、手作業によるミスを排除し、リリースサイクルを高速化できます。
ベースパッケージの活用：組織全体で共有されるユーティリティクラス、基本となるLightningコンポーネント、カスタムメタデータ型などを「ベースパッケージ」または「コアパッケージ」として切り出し、他のすべてのパッケージがそれに依存する階層構造を構築します。

結論として、Unlocked Packagesは単なるツールセットではなく、スケーラブルで保守性の高いSalesforceアプリケーションを構築するための設計思想そのものです。アーキテクトの役割は、この思想を深く理解し、組織の目標達成のために最適な形で実装戦略を策定・推進することにあります。

にゃんこのSalesforce日記

このブログを検索