アジリティを解き放つ：Salesforce開発者のためのアンロックドパッケージ詳細解説

概要とビジネスシーン

unlocked packages（アンロックドパッケージ）は、Salesforce開発におけるソース駆動開発と継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインを劇的に加速させるための強力なツールです。これにより、組織内のメタデータをモジュール化し、バージョン管理を容易にし、デプロイの信頼性を向上させることができます。

実際のビジネスシーン

シーンA - 製造業：ある製造業企業では、複数の事業部門が同じSalesforce組織を利用しており、共通の顧客管理コンポーネントやプロセス自動化フローが異なるプロジェクトで何度も開発され、コードの重複とデプロイの競合が頻繁に発生していました。

ビジネス課題：開発効率の低下、リリース時の衝突、共通コンポーネントの品質維持の難しさ。
ソリューション：unlocked packagesを導入し、共通の顧客管理コンポーネント、カスタムオブジェクト、Apexライブラリを独立したパッケージとしてモジュール化。各事業部門のプロジェクトはこれらのパッケージを依存関係としてインストール。
定量的効果：共通コンポーネントの開発・保守期間を20%短縮。デプロイ時の競合エラーが70%削減され、リリースの安定性が大幅に向上。

シーンB - 金融サービス：金融サービス企業は、規制変更や市場のニーズに迅速に対応するため、頻繁にSalesforceの機能を更新する必要があります。従来の変更セットやAnt Migration Toolでは、大規模なデプロイが複雑で、テストと承認に時間がかかっていました。

ビジネス課題：リリースの遅延、デプロイの複雑性、本番環境へのリスク。
ソリューション：各機能領域（例：ローン申請プロセス、コンプライアンスレポート）をunlocked packagesとして定義し、専用のCI/CDパイプラインを構築。Gitをソースコード管理のハブとし、変更は自動的にパッケージバージョンとして作成され、サンドボックスにデプロイ・テストされます。
定量的効果：リリースサイクルを30%高速化。デプロイの自動化により手作業によるエラーがほぼゼロになり、リリース時のダウンタイムリスクを最小化。

シーンC - SaaS企業：Salesforceをベースに独自のSaaSアプリケーションを構築している企業は、コア機能の継続的な改善と、顧客固有のカスタマイズのバランスに苦慮していました。コア機能のアップデートが顧客固有のカスタマイズに影響を与えることが課題でした。

ビジネス課題：コア機能のアップデートと顧客固有カスタマイズの分離、メンテナンスコストの増大。
ソリューション：アプリケーションの共通基盤となるコア機能を複数のunlocked packagesとして構築。顧客固有のカスタマイズは、各顧客のSandboxで直接開発するか、または別のunlocked packagesとして管理し、コアパッケージに依存させます。
定量的効果：コア機能のメンテナンスコストを15%削減。顧客固有カスタマイズへの影響を最小限に抑えつつ、コア機能の迅速なデリバリーを実現。

技術原理とアーキテクチャ

unlocked packagesは、Salesforce DX（Developer Experience）の核となる機能の一つであり、ソース駆動開発（Source-Driven Development）モデルに基づいています。これは、メタデータの単一の真実の源（Single Source of Truth）をバージョン管理システム（例: Git）に置き、そこからパッケージを構築するアプローチです。

基礎的な動作メカニズム

unlocked packagesは、特定のディレクトリに定義されたメタデータ群をパッケージ化します。このパッケージはバージョン管理され、Salesforce組織にインストール可能な単一のエンティティとして扱われます。これにより、開発者はモジュール単位で機能を作成、テスト、デプロイでき、組織全体のメタデータへの影響を局所化できます。

主要コンポーネントと依存関係

Salesforce DX CLI：パッケージの作成、バージョンの生成、インストールといったすべての操作の中心となるコマンドラインインターフェースです。
sfdx-project.json：Salesforce DXプロジェクトのルートにある設定ファイルで、パッケージの名前、タイプ（unlocked）、バージョン定義、パッケージディレクトリのパスなどを定義します。
パッケージディレクトリ：sfdx-project.jsonで指定された、パッケージに含めるメタデータが格納されているローカルファイルシステムのディレクトリです（通常はforce-appまたはカスタム名）。
パッケージレジストリ：Salesforceが提供する、作成されたすべてのパッケージバージョンが登録・管理される場所です。
バージョン管理システム（VCS）：GitなどのVCSにメタデータソースを格納し、チームでの共同開発や変更履歴の追跡を行います。

データフロー

unlocked packagesのデータフローは、主に以下のステップで進行します。

ステップ	説明	関連するSalesforce DX CLIコマンド
1. 開発	開発者はスクラッチ組織またはサンドボックスで、Gitリポジトリにプルされたメタデータソースに基づいてコードやメタデータを開発します。	`sf project generate`, `sf project deploy start`, `sf project retrieve start`
2. パッケージ定義	`sfdx-project.json`ファイルでパッケージを定義し、パッケージに含めるメタデータを含むディレクトリを指定します。	`sfdx-project.json` の手動編集
3. パッケージ作成	初回のみ、パッケージエイリアスとパッケージIDを関連付けるためにパッケージを作成します。	`sf package create`
4. パッケージバージョン作成	指定されたパッケージディレクトリのメタデータから新しいパッケージバージョンを生成し、レジストリに登録します。	`sf package version create`
5. インストール	作成されたパッケージバージョンをスクラッチ組織、サンドボックス、または本番組織にインストールします。	`sf package install`
6. アップグレード	既存のパッケージをより新しいバージョンにアップグレードします。これにより、インストール済みのコンポーネントが更新されます。	`sf package install --upgrade-type`

ソリューション比較と選定

unlocked packagesは、Salesforceのメタデータ管理における現代的なアプローチを提供しますが、他のソリューションとの違いを理解することが重要です。

ソリューション	適用シーン	デプロイパフォーマンス	Governor Limits	複雑度
unlocked packages	組織内のモジュール化された機能デプロイ CI/CDパイプラインとの統合複数チームでの共同開発共有可能なライブラリやフレームワーク	中〜高（パッケージのインストールは高速だが、バージョン作成には時間がかかる場合がある）	インストール自体は限定的。インストール後のコード実行は対象組織の制限に従う。	中（DX CLI、`sfdx-project.json`、バージョン管理の知識が必要）
アンマネージドパッケージ	小規模なコンポーネントの共有学習や簡単な機能配布オープンソースプロジェクト（知財保護なし）	低（手動でのパッケージ作成、インストール、変更管理が煩雑）	インストール後のコード実行は対象組織の制限に従う。	低（シンプルなインターフェースで作成可能）
変更セット (Change Sets)	同一組織内のサンドボックスから本番へのデプロイ小〜中規模な変更のデプロイ CI/CDが導入されていない環境	低（手動でのコンポーネント選択、デプロイが時間と手間を要する）	デプロイ中にApexテストが実行される際のCPU時間などの制限。	低（GUIベースで直感的）

unlocked packages を使用すべき場合：

✅ 組織内で再利用可能なコンポーネントをモジュール化し、デプロイプロセスを標準化したい場合。
✅ 継続的インテグレーション/デリバリー（CI/CD）パイプラインにSalesforceデプロイを統合し、自動化された開発フローを構築したい場合。
✅ 複数の開発チームが同じSalesforce組織で作業しており、メタデータの競合を最小限に抑えたい場合。
✅ パッケージバージョンを厳密に管理し、特定の機能セットを任意のSalesforce組織にロールアウト、またはロールバックできる柔軟性を求められる場合。
❌ ISV（独立系ソフトウェアベンダー）としてアプリケーションを販売し、知的財産を保護したり、ライセンス管理を行ったりする必要がある場合は、第二世代マネージドパッケージ（2GP）の検討が必要です。unlocked packagesは通常、組織内でのデプロイやパートナーによるカスタマイズのベースラインとして利用されます。

実装例

ここでは、Salesforce DX CLI を使用して簡単なカスタムオブジェクトを unlocked package として作成・インストールする手順を示します。

前提条件：Salesforce DX CLIのインストール、Salesforce Dev Hubの有効化、デフォルトのDev Hub組織エイリアスの設定。

ステップ1: Salesforce DXプロジェクトの作成

sf project generate -n MyUnlockedPackageProject -d MyUnlockedPackageProject --template standard

これにより、MyUnlockedPackageProject という名前の新しいプロジェクトディレクトリが作成されます。

ステップ2: カスタムオブジェクトの作成とメタデータのプル

スクラッチ組織を作成し、そこでカスタムオブジェクト（例: Product__c）を作成します。

sf org create scratch -d 7 -f config/project-scratch-def.json -a MyScratchOrg
sf project deploy start
// スクラッチ組織でProduct__cカスタムオブジェクトをUIから作成
sf project retrieve start -m CustomObject:Product__c

これにより、force-app/main/default/objects/Product__c にメタデータがプルされます。

ステップ3: `sfdx-project.json` の更新とパッケージの定義

sfdx-project.json ファイルを編集し、パッケージディレクトリとパッケージ定義を追加します。

{
  "packageDirectories": [
    {
      "path": "force-app", // パッケージに含めるメタデータがあるディレクトリ
      "default": true,
      "package": "MyProductPackage", // パッケージの名前
      "versionName": "ver 1.0",
      "versionNumber": "1.0.0.NEXT", // 次のバージョン番号
      "definitionFile": "config/project-scratch-def.json"
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "60.0", // 使用しているAPIバージョン
  "packageAliases": {
    "MyProductPackage": "0Ho..." // パッケージ作成後に自動で追加されるパッケージID
  }
}

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

MyProductPackage という名前で unlocked package を作成します。

sf package create -n "MyProductPackage" -t Unlocked -r "force-app"
// 成功すると、"MyProductPackage": "0Ho..." のようなエイリアスが sfdx-project.json に自動で追加されます。
// 0Ho から始まるIDはパッケージIDです。

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

パッケージディレクトリのメタデータからパッケージバージョンを作成します。

sf package version create -p "MyProductPackage" -d "force-app" -w 10
// -p: パッケージエイリアスまたはID
// -d: パッケージディレクトリのパス
// -w: 待機時間（秒）
// コマンド実行後、パッケージバージョンID (04t...) が出力されます。

ステップ6: パッケージのインストール

作成したパッケージバージョンを別のSalesforce組織（例: MySandboxAlias）にインストールします。

sf package install -p "MyProductPackage@1.0.0-1" -o MySandboxAlias -w 10
// -p: パッケージエイリアスとバージョン番号 (例: @1.0.0-1)
// -o: インストール先の組織エイリアス
// -w: 待機時間（秒）

これで、MySandboxAlias というSandbox組織に Product__c カスタムオブジェクトを含むパッケージがインストールされました。

注意事項とベストプラクティス

権限要件

Salesforce DX CLIの利用：Dev Hubが有効化された組織に接続できるSalesforceユーザーが必要です。通常は「システム管理者」プロファイルを持つユーザーを使用します。
パッケージ作成：パッケージを作成およびバージョンを作成するユーザーは、Dev Hub組織に対して「パッケージマネージャー」権限セットライセンスと関連する権限セットが割り当てられている必要があります。
CI/CDエージェント：自動化されたCI/CDパイプラインでパッケージ操作を行う場合、ヘッドレス認証（JWTベースの認証など）を使用し、最小限の権限を持つ専用のインテグレーションユーザーを設定することが推奨されます。

Governor Limits

unlocked packagesの操作自体が直接的にApex Governor Limitsに抵触することは稀ですが、以下の点に注意が必要です。

メタデータAPIの制限：パッケージバージョン作成時やインストール時には内部的にメタデータAPIが利用されます。Salesforce組織には、1日あたりに実行できるメタデータAPIの呼び出し回数に制限があります（例: 組織あたり最大 250,000 回の非同期呼び出し）。
- ⚠️ 公式ドキュメントの確認が必要: これらの具体的な数値はSalesforceの更新によって変更される可能性があるため、常に最新の公式ドキュメントを参照してください。
パッケージのテスト実行：パッケージがインストールされた後、そのパッケージに含まれるApexコードが実行される際には、インストール先の組織のGovernor Limitsが適用されます。

エラー処理

パッケージバージョン作成エラー：
- 原因：メタデータの破損、依存関係の欠如、APIバージョンの不一致、名前の重複など。
- 解決策：`sf package version create` コマンドの出力メッセージを詳細に確認します。`--validation-only` フラグを使用して、実際にパッケージを作成せずに検証のみを行うことができます。また、Gitで変更を管理し、競合を事前に解決することも重要です。
パッケージインストールエラー：
- 原因：インストール先の組織でのメタデータ競合、既存のコンポーネントとの名前重複、必要な権限の欠如。
- 解決策：エラーメッセージを注意深く読み、問題のコンポーネントを特定します。インストール先の組織のメタデータを確認し、競合を解決します。`sf package install --upgrade-type Delete` (推奨されない操作だが、既存コンポーネント削除で競合回避) などのオプションもありますが、慎重に使用する必要があります。

パフォーマンス最適化

パッケージの粒度：パッケージを小さく、特定の機能に焦点を当てて分割することで、パッケージバージョンの作成とインストールが高速化し、依存関係の管理が容易になります。
CI/CDパイプラインの最適化：パッケージバージョン作成、テスト実行、デプロイの各ステップを自動化し、並列処理を導入することで、全体的な開発サイクルを短縮します。
スクラッチ組織の活用：開発とテストにスクラッチ組織を積極的に利用することで、変更が既存の組織に与える影響を最小限に抑え、素早いイテレーションを可能にします。

よくある質問 FAQ

Q1：unlocked packagesとアンマネージドパッケージの主な違いは何ですか？

A1：unlocked packagesはSalesforce DXのソース駆動開発モデルに最適化されており、バージョン管理、依存関係の明示的な定義、CI/CDパイプラインとの統合が可能です。一方、アンマネージドパッケージはシンプルなコンポーネント共有を目的とし、バージョン管理やアップグレード機能は限定的です。

Q2：unlocked packagesのデバッグやトラブルシューティングはどのように行いますか？

A2：unlocked packagesに含まれるApexコードやVisualforceページなどは、インストール先のスクラッチ組織やサンドボックスで標準のデバッグツール（開発者コンソール、Debug Logs）を使用してデバッグできます。パッケージバージョン作成時のエラーについては、`sf package version create` コマンドの詳細な出力や、`sf package diagnose -p ` コマンドで問題を特定できます。

Q3：パッケージ間の依存関係はどのように管理すべきですか？

A3：sfdx-project.jsonファイル内で、各パッケージの定義に`dependencies`セクションを追加し、依存するパッケージのエイリアスとバージョン番号を指定することで、依存関係を明示的に管理します。Salesforce CLIは、パッケージのインストール時にこれらの依存関係を自動的に解決します。循環参照を避けるように設計することが重要です。

まとめと参考資料

unlocked packagesは、Salesforce開発をモジュール化し、CI/CDを推進するための不可欠なツールです。これらを活用することで、開発チームはより迅速かつ信頼性の高い方法で価値を提供し、Salesforce組織の健全性を維持できます。ソース駆動開発と組み合わせることで、Salesforceの開発プロセスに真のアジリティをもたらすことができるでしょう。

公式リソース

📖 公式ドキュメント：Introduction to Salesforce DX Unlocked Packages
📖 公式ドキュメント：Create and Install Unlocked Packages
🎓 Trailhead モジュール：Package Development Model
🔧 関連 GitHub サンプル：Dreamhouse LWC Sample with Unlocked Package

にゃんこのSalesforce日記

このブログを検索