Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

メタデータの分割

学習の目的

この単元を完了すると、次のことができるようになります。
  • 企業顧客がロック解除済みパッケージを使用する方法を説明する。
  • パッケージ開発と変更セット開発との違いを説明する。
  • パッケージを使用してメタデータをリリースする方法を説明する。

パッケージ開発が優れている理由

「パッケージ開発モデル」モジュールを修了した方は、モジュール形式のパッケージベース開発によって大きな変化がもたらされることをご存知でしょう。しかし、これらの原則をどうやって実践するか、疑問に思いませんか? このモジュール形式モデルはどのように役立つのでしょうか?

プラットフォームでの開発が初めての人にも、すでに慣れている人にも、パッケージ化は適しています。Salesforce を長期的に利用していれば、プラットフォームでカスタマイズや構築を重ねれば重ねるほど、組織の複雑さは高まります。1 つの Salesforce 組織は、管理およびやりとりの対象のメタデータすべての大きなコンテナとなっています。この打ち出の小槌を Salesforce では「スープ」と呼んでいます。

箱が、さまざまな関連メタデータを示す多様な形を含むスープで満たされています。次では、スープは、それぞれに特定の形を含む 3 個の箱です。これは、メタデータをパッケージに調整する仕組みを示しています。

Salesforce のカスタマイズを最近ロールアウトしている場合、変更セットまたは未管理パッケージを使用して、本番組織にメタデータをリリースしています。この従来の開発モデルは、変更セット開発と呼ばれています。開発は、主に Sandbox または本番組織の範囲で行われていました。

変更セット開発アプリケーションのライフサイクルでは、変更が本番組織にリリースされるまでは、開発とテスト環境間で組織変更を移動する必要がありました。最終的に、「信頼できる情報源」は本番組織になります。バージョン管理システムで外部的に変更を追跡していても、すべてが組織にあることは確実にわかっています。

ただし、これからは選択肢が増えます! パッケージ開発モデルでは、新しい改善された信頼できる情報源はバージョン管理システムです。Salesforce DX プロジェクトを使用して、ソースをパッケージディレクトリに整理できます。最終的な目標は、それらのディレクトリを使用して、バージョン管理が可能でメンテナンス、更新、インストール、アップグレードが容易なパッケージを作成することです。

とは言うものの、パッケージ開発への移行はゼロか十かという話ではありません。これから、どのように開始するのか見てみましょう。

パッケージとは

パッケージ化に詳しくないのであれば、パッケージを、メタデータで満たされたコンテナだと考えてください。機能を配布する単位を示します。

たとえば、従業員向けに経費を追跡するカスタムアプリケーションを構築したとします。カスタムオブジェクト、Apex クラス、Lightning コンポーネントなどを含めました。変更セット開発モデルでは、このカスタムアプリケーションに属するすべてのメタデータが Salesforce 組織に含まれています。ただし、これはアップグレードやメンテナンスが容易になるような方法で分離または整理されていません。パッケージ開発モデルでは、パッケージと呼ばれる適切に定義したコンテナに、そのメタデータを整理します。

パッケージを使用するべき最大の理由がメタデータ、つまりメタデータの整理であると聞いても、皆さんは驚かないでしょう。パッケージがなければ、Salesforce メタデータが扱いにくいものになり始める可能性があります。

ロック解除済みパッケージによる解決

Salesforce はさまざまなタイプのパッケージを提供しており、それぞれに独自の特徴があります。ここでは、特殊なパッケージ種別である、ロック解除済みパッケージを扱います。これは、特に社内用のビジネスアプリケーションに適しています。

ロック解除済みパッケージは、追跡可能な方法で、組織のメタデータの追加、編集、削除をサポートします。これにより、コンポーネントを再利用して、Salesforce アプリケーションを簡単かつすばやくアップグレードできます。これらは、実行する予定のすべてのメタデータの変更と更新をカプセル化します。

もちろん、アプリケーション、およびパッケージのコンテンツは時代によって変化します。変更を追跡するには、パッケージのバージョンを作成します。各バージョンは、パッケージのコンテンツのスナップショットであり、不変のアイテムです。

本番組織では、どのメタデータがどのパッケージバージョンから来たのか調査し、パッケージバージョンに関連するすべてのメタデータセットを確認できます。この調査プロセスは、AppExchange からインストールしたパッケージと同じです。

メタデータの変更を追跡するためのスプレッドシートはもう不要です。付箋も不要です!

ロック解除済みパッケージとは

ロック解除済みパッケージを使用すると、多くの柔軟性を得られます。ロック解除済みパッケージのメタデータは本番組織で変更できるため、システム管理者は、緊急の変更要求に対応して、本番環境で直接変更できます。

ロック解除済みパッケージにより、本番組織で直接変更する柔軟性が高まりますが、優れた機能には大きな責任が伴います。あなたのアンテナは反応していますか?

ロック解除済みパッケージは開発者制御型です。新しいパッケージバージョンのインストールは、本番組織で直接実施された変更を上書きします。システム管理者は、本番組織で実施したすべての変更に関して、パッケージが適切に更新されるように、開発チームと連絡を取り合うことが重要です。

ロック解除済みパッケージには、何を含められるのでしょうか? 朗報です! ほぼすべての種類の Salesforce メタデータおよびコンポーネントをロック解除済みパッケージに配置できます。

メタデータカバー率レポートは、複数のチャネルのメタデータカバー率の信頼できる情報源です。これらのチャネルには、メタデータ API、ソース追跡、ロック解除済みパッケージ、第二世代管理パッケージ、第一世代管理パッケージなどが含まれます。メタデータカバー率レポートにアクセスするには、https://developer.salesforce.com/docs/metadata-coverage に移動します。

使用の開始方法

その前に、重要で、繰り返し強調すべき点について話します。Salesforce DX ツールと開発の原則の採用は、ゼロか十かという話ではありません。少しずつ採用することも、思い切って採り入れることも可能です。Salesforce がそれを正しいかどうか判断することはありません。

では、拡張の準備ができている場合、どうやって開始するのでしょうか?

  • Salesforce に慣れていない、または新しいプロジェクトを開始する場合は、最初から、パッケージ開発モデルに従えます。
  • 分割されていない巨大なソースで作業開始する場合は、まずメタデータを切り分けて、ロジカルコンテナに整理しながら、段階的にパッケージ化を採用できます。

複数のアプリケーションで将来再利用できるコンポーネントとスキーマをパッケージ化して、小さく始められます。適宜、パッケージ間の連動関係を定義できます。自身で、進めるペースや許容する複雑さの度合いを決定できます。

この柔軟性がロック解除済みパッケージの威力です。

Salesforce DX を使用したパッケージ開発

パッケージ化のいくつかの基本概念を理解できたところで、パッケージ化ワークフローについて説明します。わかりやすくするために、あなたが単独の開発者兼リリースマネージャーであり、チームメイトが品質保証 (QA) に対応する場合を想定します。

まず、Salesforce DX プロジェクトのディレクトリに関連付けたパッケージの作成から開始します。開発者として、プロジェクトのメタデータを変更します。変更は蓄積します。スクラッチ組織を使用して、これらの変更の開発および単体テストを実施します (1)。

リリースマネージャーとして、QA と共有する準備が完了したら、パッケージバージョンを作成します。QA は、パッケージをインストールして、作業します。このパッケージを単体テストと CI にも使用します (2)。このプロセスの間に、バグの修正、新しい機能の追加、または既存の機能の変更を実施します。新しいパッケージバージョンを作成した後、もう一度単体テストプロセスを開始します (1)。

これが、パッケージ開発モデルの反復型の性質です。

正常なバージョンを得られるまで、このプロセスを QA と繰り返します。次に、ユーザー受け入れテスト (UAT) 用にこのバージョンを Sandbox にインストールして、最終的に本番環境にインストールします (3)。

パッケージのワークフローを左から右に示しています。コードは、開発およびテストにスクラッチ組織を使用します。継続的インテグレーションは、単体テストにスクラッチ組織を使用します。継続的配信は、構築と UAT に開発者 Sandbox と Partial Sandbox を使用します。リリースは、本番へのリリース前の最終テストに Full Sandbox を使用します。

パッケージバージョンのインストールは、メタデータのリリースと同様です。スクラッチ組織、Sandbox 組織、または本番組織、いずれの組織にもパッケージバージョンをインストールできます。つまり、メタデータのセットのリリースと同様です。

これで終了です。パッケージ開発モデルの基本的なアプリケーションライフサイクルについて学習しました。

初めてのパッケージリリース後

ハイテクとソフトウェア開発の世界では、満足して一息つく余裕はありません。多くの場合、次のリリースが待ち構えています。さあ、マントとスーツに身を包み、作業を再開して、新しい機能とカスタマイズを開発しましょう。登場するのは、新しいパッケージバージョンです。

パッケージメタデータを変更、追加、削除するときに合わせて、必要な新しいバージョンをすべて作成できます。各パッケージバージョンにはバージョン番号 (たとえば、1.3.0.2) があり、パッケージアップグレードを使用して、インストール済みパッケージバージョンにこれらの変更を適用します。

このプロセス (メタデータの変更 → パッケージバージョンの作成 → パッケージバージョンのテスト → 本番へのリリース) は、何度でも実行できます。

準備はできましたか? 初めてのロック解除済みパッケージを構築しましょう。

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む