platform-manifest-generate

platform-manifest-generate

ローカルソース、組織、または明示的に指定したコンポーネントリストから、Salesforce メタデータマニフェスト（package.xml またはいずれかの破壊的変更用バリアント）を生成します。このスキルの対象は、マニフェストファイルの作成のみです。ファイルができたら、platform-metadata-deploy または platform-destructive-deploy に引き継ぎます。

---

ツールの制限

sf project generate manifest の実行には Bash ツールのみ を使用し、手作業で作成する代替手順には Write ツールを使用してください。MCP ツールは使用しないでください。

---

このスキルが担当するタスク

次のいずれかに該当する場合は、platform-manifest-generate を使用してください。

• ソースディレクトリ（例：force-app/main/default/classes/）から package.xml を作成する
• 明示的に指定したコンポーネントのリスト（例：AccountService、ContactSelector、Account）からマニフェストを作成する
• --from-org を使って組織を調査し、マニフェストを作成する
• 削除用の destructiveChanges.xml、destructiveChangesPre.xml、または destructiveChangesPost.xml を作成する
• package.xml と破壊的変更用マニフェストを一度の操作で両方作成する

次の場合は、別のスキルに委任してください。

• デプロイを実行する → platform-metadata-deploy
• 本番リリース前に検証する → platform-deploy-validate
• 破壊的変更をデプロイする → platform-destructive-deploy（このスキルが生成するマニフェストを 使用 します）
• メタデータをローカルに取得する → platform-metadata-retrieve

---

2 つの生成方法

方法 A — CLI による生成（推奨）

sf project generate manifest を実行します。常にこの方法を優先してください。すべてのメタデータ型に対応し、標準的な XML を生成します。また、* を出力しないため、ワイルドカードによる危険を完全に回避できます。

CLI には 3 つの入力モードがあり、同時には使用できません。

入力	フラグ	使用する状況
ソースディレクトリ	--source-dir (-p)	ユーザーが、メタデータがすでにローカルに存在するフォルダーを指定する場合
コンポーネントリスト	--metadata (-m)	ユーザーが、ApexClass:AccountService CustomObject:Account のように特定のコンポーネントを指定する場合
組織の調査	--from-org	ユーザーが、組織内の現在の全コンポーネント（または絞り込んだサブセット）を指定する場合

--source-dir と --metadata は、どちらか一方のみ指定できます。--from-org は、--metadata（対象に含める型を絞り込む）または --excluded-metadata（対象から除外する型を指定する）と組み合わせられます。

確認済みフラグ（フラグを推測で追加しないでください。不明な場合は sf project generate manifest --help で確認してください）。

フラグ	用途
--source-dir, -p	スキャンするローカルソースのパス
--metadata, -m	含めるコンポーネント名（例：ApexClass:AccountService）
--from-org	調査する組織のユーザー名またはエイリアス
--name, -n	出力ファイル名を指定する（--type とは同時に指定できません）
--type, -t	定義済みのマニフェスト種別：package | pre | post | destroy
--output-dir, -d	マニフェストの出力先ディレクトリ
--api-version	リクエストに使用する API バージョンを指定する
--include-packages, -c	--from-org の使用時に managed および／または unlocked パッケージのメタデータを含める
--excluded-metadata	--from-org の使用時に除外する型
--json	機械可読形式の出力

--type によるマニフェストのファイル名：

--type	出力ファイル
package（デフォルト）	package.xml
pre	destructiveChangesPre.xml
post	destructiveChangesPost.xml
destroy	destructiveChanges.xml

--type と --name は、どちらか一方のみ指定できます。

CLI の標準的な例

# Build package.xml from a source dir
sf project generate manifest \
  --source-dir force-app/main/default \
  --name package.xml \
  --output-dir manifest \
  --json

# Build package.xml from an explicit component list
sf project generate manifest \
  --metadata ApexClass:AccountService \
  --metadata ApexClass:ContactSelector \
  --metadata CustomObject:Account \
  --name package.xml \
  --output-dir manifest \
  --json

# Build destructiveChanges.xml from a component list
sf project generate manifest \
  --metadata CustomField:Account.OldField__c \
  --metadata CustomField:Account.OldStatus__c \
  --type destroy \
  --output-dir manifest \
  --json

# Build a manifest by introspecting an org (filtered)
sf project generate manifest \
  --from-org <alias> \
  --metadata ApexClass,CustomObject,CustomLabels \
  --output-dir manifest \
  --json

package.xml と破壊的変更用マニフェストの両方が必要な場合は、CLI を 2 回実行します。1 回目は --type package（またはデフォルト）、2 回目は --type destroy／pre／post を指定します。

パス B — 手動作成の代替手段

CLI ではユーザーの意図を表現できない場合に限り使用します。たとえば、「今日変更した Apex クラスだけ」が必要で、その変更セットがクリーンなディレクトリやコンポーネントのリストではなく、git diff から導出される場合です。その場合は次の手順に従います。

1. コンポーネントを自分で特定します（例：git diff --name-only を解析し、パスをメタデータタイプに対応付けます）。
2. メタデータタイプごとにグループ化します。
3. 以下のスキーマを使って XML をインラインで出力します。
4. 必ず sf project deploy start --manifest <file> --dry-run を実行してクロスチェックします（platform-metadata-deploy に引き継ぎます）。

Manifest XML schema

ルート要素はメタデータ名前空間の <Package> です。各メタデータタイプには、コンポーネントごとに 1 つの <members> と、単一の <name> を含む <types> ブロックを 1 つずつ配置します。末尾の <version> で、マニフェストの API バージョンを宣言します。

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>AccountService</members>
        <members>ContactSelector</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>Account</members>
        <name>CustomObject</name>
    </types>
    <types>
        <members>Account.Status__c</members>
        <name>CustomField</name>
    </types>
    <version>62.0</version>
</Package>

注意：

• CustomField、BusinessProcess、RecordType、Layout、ListView、ValidationRule、WebLink などのコンポーネントに紐づくタイプでは、メンバーに Object.Name 形式を使用します。
• destructiveChanges.xml、destructiveChangesPre.xml、destructiveChangesPost.xml では、同じ XML 構造を使用します。異なるのはファイル名と目的だけです。
• 空のマニフェスト（<types> ブロックがないもの）は有効であり、破壊的変更用マニフェストと併用されることもあります。

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>62.0</version>
</Package>

---

API バージョンの処理

すべてのマニフェストの末尾にある <version> 要素には、プロジェクトの API バージョンを設定する必要があります。

解決順序：

1. プロジェクトルートの sfdx-project.json から sourceApiVersion を読み取ります。
2. ユーザーが --api-version を指定した場合は、代わりにその値を使用します。
3. どちらも利用できない場合は、sf --version が報告する値（CLI にバンドルされている API バージョン）を使用します。ただし、ユーザーに警告し、再現性を確保するために sfdx-project.json で sourceApiVersion を設定するよう推奨します。
4. 出所を明示せずに、値（例：62.0）を出力に暗黙的にハードコードしてはいけません。

# Quick read of sourceApiVersion
jq -r '.sourceApiVersion' sfdx-project.json

CLI パスを使用する場合、ユーザーが明示的に上書きしない限り --api-version は省略します。CLI はすでに sourceApiVersion を読み取ります。

---

ワイルドカードメンバー（<members>*</members>）

ワイルドカードメンバーは、そのメタデータタイプのすべてのコンポーネントに一致します。すべてのタイプで使用できるわけではありません。 使用が許可されていないタイプに * を使用すると、Wildcards are not supported for this metadata type のようなデプロイ／取得エラーが発生します。

ワイルドカードの使用不可（列挙が必要）

これらのタイプでは、メンバー名を明示的に指定する必要があります。一般的な例：Profile、PermissionSet、PermissionSetGroup、CustomLabels、CustomObjectTranslation、Layout、Workflow（一部のパッケージ構成の場合）、SharingRules、StandardValueSet、ManagedTopics、および内容がオブジェクトに紐づくほとんどの「コンテナー」タイプ（CustomField、RecordType、BusinessProcess、ListView、ValidationRule、WebLink、CompactLayout）。

これらのタイプでは、明示的に列挙します。

<types>
    <members>Admin</members>
    <members>Standard User</members>
    <name>Profile</name>
</types>

ワイルドカードを通常使用できるタイプ

ほとんどの「自己完結型」コンポーネントタイプでは、* を使用できます。例：ApexClass、ApexTrigger、ApexComponent、ApexPage、AuraDefinitionBundle、LightningComponentBundle、CustomApplication、CustomTab、StaticResource、EmailTemplate、Report、Dashboard、Flow、FlexiPage、CustomMetadata。全タイプと例外については、references/wildcard-allowlist.md を参照してください。

目安：確信が持てない場合は、コンポーネントを明示的に列挙してください。CLI パス（--source-dir／--metadata）では * が出力されないため、この問題を回避できます。

---

例

例 1 — ディレクトリから package.xml を作成する

「force-app/main/default/classes/ から package.xml を生成して」

sf project generate manifest \
  --source-dir force-app/main/default/classes \
  --name package.xml \
  --output-dir manifest \
  --json

結果：そのフォルダー内のすべての Apex クラスを列挙した manifest/package.xml。

例 2 — 特定のコンポーネントを含むマニフェストを作成する

「AccountService、ContactSelector、および Account カスタムオブジェクトを含むマニフェストを作成して」

sf project generate manifest \
  --metadata ApexClass:AccountService \
  --metadata ApexClass:ContactSelector \
  --metadata CustomObject:Account \
  --name package.xml \
  --output-dir manifest \
  --json

結果：指定された 3 つのコンポーネントだけを含む manifest/package.xml。

例 3 — 削除用の package.xml と destructiveChanges.xml の両方を生成する

「次の削除対象について、package.xml と destructiveChanges.xml の両方を作成してください：Account.OldField__c、Account.OldStatus__c」

# Empty/minimal package.xml (deletion-only deploy still needs a package descriptor)
sf project generate manifest \
  --metadata CustomLabels \
  --name package.xml \
  --output-dir manifest \
  --json

# destructiveChanges.xml
sf project generate manifest \
  --metadata CustomField:Account.OldField__c \
  --metadata CustomField:Account.OldStatus__c \
  --type destroy \
  --output-dir manifest \
  --json

生成後、削除の検証と実行のために platform-destructive-deploy に引き継ぎます。

---

失敗モード

症状	考えられる原因	対処方法
Path does not exist: <dir>	--source-dir が存在しないフォルダーを指している	パスを確認します。ls で検証し、ユーザーの指定が曖昧な場合は force-app/main/default をデフォルトとして使用します
生成されたマニフェストが空	ソースディレクトリに認識可能なメタデータが含まれていない、またはすべてのファイルが無視された	.forceignore を確認します。パスにメタデータファイル（*.cls、*-meta.xml など）が実際に含まれていることを確認します
デプロイ時に Wildcards are not supported for this metadata type が発生する	手動作成したマニフェストで、ワイルドカードが許可されていないタイプに * を使用した	上記のワイルドカード許可リストを参照し、コンポーネントを明示的に列挙します
<version> がない、または一致しない	sfdx-project.json に sourceApiVersion がない	sfdx-project.json に sourceApiVersion を追加するか、CLI に --api-version を渡します
You can specify either --type or --name, but not both	CLI の呼び出しで両方のフラグを渡した	どちらか一方を削除します。定義済みの名前には --type、カスタム名には --name を使用します
You can specify either --source-dir or --metadata, but not both	CLI の呼び出しで両方を渡した	入力モードをどちらか一方にします
--from-org の出力にコンポーネントがない	組織のイントロスペクションで一括処理を行いすぎた、またはそのタイプが管理パッケージに含まれている	SF_LIST_METADATA_BATCH_SIZE の値を下げます。意図した場合は --include-packages managed を追加します

---

スキル間の連携

必要な作業	委任先	理由
生成したマニフェストでデプロイを実行する	platform-metadata-deploy	このスキルはファイル生成までを行います
本番リリース前に検証する	platform-deploy-validate	本番環境に対する事前テストを行います
破壊的変更マニフェストに記載されたコンポーネントを実際に削除する	platform-destructive-deploy	このスキルが破壊的デプロイを検証して実行します
マニフェストに記載されたメタデータを取得する	platform-metadata-retrieve	組織のメタデータをローカルに取得します
マニフェストに記載するメタデータを作成する	その他の platform-* 生成スキル（例：platform-custom-object-generate）	マニフェストは、ディスク上にすでに存在するものを列挙するだけです

---

完了形式

Manifest goal: <package | pre | post | destroy>
Input mode: <source-dir | metadata list | from-org | hand-built>
Output: <path/to/manifest.xml>
API version: <value> (source: sfdx-project.json | --api-version | CLI default)
Component count: <N> across <M> metadata types
Next step: <platform-metadata-deploy | platform-deploy-validate | platform-destructive-deploy>