platform-sharing-rules-generate

共有ルールジェネレーター

Salesforce の共有ルールメタデータを取得、作成、編集、削除し、組織のデフォルト設定を超えてレコードレベルのアクセスを制御します。条件ベースのルール、ロール／グループベースの所有者ルール、Experience Sites のゲストユーザールールに対応しています。

スコープ

• 対象範囲：sharingCriteriaRules、sharingOwnerRules、sharingGuestRules メタデータの作成、編集、削除、取得（get）；Metadata API Retrieve パターンを使用した組織からの既存共有ルールの取得；既存ファイルへの新しいルールの追加；ルール条件またはアクセスレベルの変更；メタデータファイルからのルールの削除；ゲストおよびポータルプロファイル向けルールの設定。
• 対象外：組織のデフォルト設定（OWD／共有モデル）の変更、Experience Sites の作成、権限セットまたはプロファイルの設定（platform-permission-set-generate を使用）、テリトリーベースの共有ルール。

---

確認事項

まだ明確でない場合は、作業を進める前にユーザーに確認してください。

取得操作の場合：

• どのオブジェクトの共有ルールを取得しますか？（標準またはカスタムオブジェクトの API 名、またはすべてのオブジェクト）
• どの対象組織からルールを取得しますか？（組織のエイリアスまたはデフォルト）

作成操作の場合：

• 共有ルールを適用するオブジェクトは何ですか？（標準またはカスタムオブジェクトの API 名）
• ルールの種類は何ですか？（条件ベース、ロール／グループベースの所有者ルール、またはゲストユーザールール）
• レコードを誰と共有しますか？（ロール名、グループ、ポータルロール、またはゲストユーザーのニックネーム）
• アクセスレベルは何ですか？（Read または Read/Write）
• 条件ベースのルールの場合：一致させるフィールド条件は何ですか？

編集操作の場合：

• どの既存ルールを変更しますか？（ルールの完全修飾名またはラベル）
• 何を変更しますか？（アクセスレベル、条件、ラベル — 注：sharedTo と sharedFrom はその場で編集できません）

削除操作の場合：

• どのルールを削除しますか？（ルールの完全修飾名またはラベル）
• ルールが属するオブジェクトを確認してください

---

必須入力

作業を進める前に、以下の情報を収集するか推測してください。

• オブジェクト API 名：ルールの対象となる sObject（例：Account、Property__c）
• ルールの種類：sharingCriteriaRules、sharingOwnerRules、sharingGuestRules のいずれか
• 共有先：ロール、グループ、ポータルロール、またはゲストユーザーのコミュニティニックネーム
• アクセスレベル：Read または Edit（読み取り専用または読み取り／書き込みに対応）
• 条件（条件ルール／ゲストルールの場合）：各フィルター項目のフィールド名、演算子、値

指定がない場合のデフォルト：

• アクセスレベル：Read
• includeRecordsOwnedByAll：条件ルールの場合は true
• includeHVUOwnedRecords：ゲストルールの場合は false
• アカウント共有ルールでは、すべてのサブアクセスレベルを None に設定した accountSettings を含めます

---

ワークフロー

各フェーズ内の手順は順番に実行します。フェーズ 3 は操作の種類によって分岐するため、該当する分岐のみを実行してください。フェーズ 4 は作成、編集、削除の場合にのみ適用されます（取得操作はフェーズ 3 で終了します）。

フェーズ 1 — 検出

1. SFDX プロジェクトのパスを解決する — プロジェクトの sfdx-project.json を見つけ、sharingRules/ のパッケージディレクトリを特定します。

2. Metadata API Retrieve パターンを使用して、必ず組織から最新の共有ルールを取得する：

   sf project retrieve start --metadata "SharingRules:<ObjectName>" --target-org <org>
   

   これにより、ローカルファイルに現在の組織の状態が反映されます。古くなっている可能性のあるローカルファイルを決して信用しないでください。古いファイルに対する編集や削除を行うと、組織ですでに削除されたルールが再作成されたり、他のユーザーが行った変更が上書きされたりする可能性があります。

3. 取得したファイルを読み込む — <packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml を解析して既存のルールを把握し、重複を避けます。

フェーズ 2 — 操作とルールタイプを特定する

4. 操作を特定する — ユーザーが共有ルールの取得、作成、編集、削除のどれを希望しているかを判断します。

5. ルールタイプを選択する — ユーザーの意図に基づいて選択します。各タイプの完全なスキーマと必須要素については、references/rule-types.md を参照してください。

6. Account 共有ルールの場合：accountSettings 要素は必須です。ユーザーが別途指定しない限り、サブアクセスレベルは None に設定します。

7. Guest ルールの場合：sharedTo では、サイトのゲストユーザーのコミュニティニックネームを持つ <guestUser> を使用する必要があります。Guest ルールでは、<role> や <group> は決して使用しないでください。

フェーズ 3 — 操作を実行する

取得の場合：

8a. フェーズ 1 ですでに取得したファイルを使用する — ステップ 2 の取得処理ですでに、組織から最新の <ObjectName>.sharingRules-meta.xml が取得されています。追加の取得は不要です。

8b. 取得したルールを読み取り、提示する — .sharingRules-meta.xml ファイルを解析し、次の内容を示してルールを読みやすい形式でユーザーに提示します。 - ルール名（fullName）とラベル - ルールタイプ（条件ベース、所有者ベース、または Guest） - アクセスレベル - 共有先 - 条件（該当する場合）

取得操作の場合は、フェーズ 4 をスキップします（書き込みは不要です）。取得処理により、メタデータファイルはローカルプロジェクトにすでに書き込まれています。

作成の場合：

8a. XML を構築する — references/rule-types.md のスキーマに従います。主要な構造は次のとおりです。 - オブジェクトごとに .sharingRules-meta.xml ファイルを 1 つ作成する - 同じオブジェクトのすべてのルールを同じファイルに記述する - 既存のファイルに追加する場合は、新しいルール要素を既存の <SharingRules> ルート要素の内側に追加する

8b. ルールに名前を付ける — 意図から <fullName> を導き出します（パスカルケース、スペースなし、説明的な名前）。スペースを含むタイトルケースの <label> を対応させて生成します。

編集の場合：

8a. 対象のルールを特定する — 既存の .sharingRules-meta.xml ファイルから、<fullName> または <label> でルールを検索します。

8b. サポートされていない編集を制限する — プラットフォームは <sharedTo> 要素や <sharedFrom> 要素のインプレース変更をサポートしていません。ユーザーが共有先または共有元の変更を要求した場合は、編集を拒否し、既存のルールを削除して、希望する対象で新しいルールを作成するよう指示します。これはルールタイプの変更にも使用されるのと同じパターンです（TC-16 を参照）。

8c. ルールタイプに基づいて変更内容を判断する： - 所有者ベースのルール（sharingOwnerRules）：編集できるのは <accessLevel> のみです。プラットフォームは、所有者ルールのその他の要素（sharedTo、sharedFrom、label）の変更をサポートしていません。アクセスレベル以外の変更をユーザーが要求した場合は、拒否して削除後に新規作成するよう指示します。 - 条件ベースのルール（sharingCriteriaRules）：編集がサポートされている要素は、<accessLevel>、<criteriaItems>、<label>、<booleanFilter> です。 - Guest ルール（sharingGuestRules）：編集がサポートされている要素は、<accessLevel>、<criteriaItems>、<label>、<includeHVUOwnedRecords> です。

削除の場合：

8a. 対象のルールを特定する — 既存の .sharingRules-meta.xml ファイルから、<fullName> または <label> でルールを検索します。

8b. 残りのルール数を数える — scripts/count-remaining-rules.sh <file> を実行して、ルールの合計数を取得します。数が 1（削除対象のルールのみ）の場合は、フェーズ 4 でファイル全体を削除する必要があります。

8c. 破壊的なデプロイを platform-destructive-deploy に委任する — 通常の sf project deploy start は追加のみを行い、組織からルールを削除することはありません。次のコンテキストを指定して、platform-destructive-deploy スキルに委任します。 - メタデータタイプ：SharingCriteriaRule、SharingOwnerRule、または SharingGuestRule（ルールタイプに応じて指定） - メンバー：<ObjectName>.<RuleFullName> - 対象組織：ユーザーが指定した組織

フェーズ 4 — 作成と検証

9. 変更を適用します：

   • 作成：ファイルを <packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml に書き込みます。
   • 編集：ステップ 8b で特定した要素のみを更新し、その他の要素はすべて元のまま保持します。
   • 削除（ルールが残る場合）：対象のルールを削除した更新済みファイルを書き込みます。
   • 削除（最後のルールの場合）：ファイル <packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml を完全に削除します。

10. 以下の検証チェックリストを実行し、出力を提示する前にシナリオごとの期待される動作を examples/create-cases.md、examples/edit-cases.md、examples/delete-cases.md で確認します。

---

検証チェックリスト

共通チェック

• ファイルに XML 宣言と <SharingRules xmlns="http://soap.sforce.com/2006/04/metadata"> ルート要素がありますか？
• オブジェクトごとにファイルが 1 つだけあり、すべてのルールがその中に含まれていますか？
• <fullName> はスペースのないパスカルケースになっていますか？
• <label> があり、人が読んでわかる内容になっていますか？
• <accessLevel> は Read または Edit ですか？

条件ルールのチェック

• <includeRecordsOwnedByAll> がありますか（必須のブール値）？
• 各 <criteriaItems> に <field>、<operation>、<value> がありますか？
• 選択リストの値は対象の組織で有効ですか？

ゲストルールのチェック 重大

• <sharedTo> は <guestUser> を使用していますか（<role> または <group> ではありませんか）？
• <includeHVUOwnedRecords> がありますか（必須のブール値）？
• <includeRecordsOwnedByAll> がありませんか（条件ルールにのみ必要で、ゲストルールには不要です）？

所有者ルールのチェック

• ルールに <sharedFrom> 要素と <sharedTo> 要素の両方がありますか？
• どちらも有効な <role>、<roleAndSubordinates>、または <group> の対象を使用していますか？

編集操作のチェック

• 最新の取得済みファイルを使って編集しましたか（古いローカルコピーではありませんか）？
• 編集はルールタイプでサポートされているフィールドに限定されていますか？
  • 所有者ルール：accessLevel のみ
  • 条件ルール：accessLevel、criteriaItems、label、booleanFilter
  • ゲストルール：accessLevel、criteriaItems、label、includeHVUOwnedRecords
• sharedTo／sharedFrom は変更せずに残しましたか？（ユーザーが変更を依頼した場合は拒否し、削除してから作成するよう案内してください）
• 意図した要素のみを変更しましたか？
• 編集後もすべての必須要素が含まれていますか？
• 変更したルールは、上記の共通チェックに引き続き合格していますか？

削除操作のチェック

• 正しいルールを削除しましたか（<fullName> で照合）？
• 残った XML は適切な <SharingRules> ルート要素を持ち、整形式ですか？
• ルールが残っていない場合、ファイルを完全に削除しましたか？
• 正しいメタデータタイプ（SharingCriteriaRule、SharingOwnerRule、または SharingGuestRule）を指定して、platform-destructive-deploy に委譲しましたか？

Account 固有のチェック 重大

• オブジェクトが Account の場合、3 つのサブ要素すべてを含む <accountSettings> がありますか？
• <caseAccessLevel>、<contactAccessLevel>、<opportunityAccessLevel> はすべて設定されていますか？

ルール／制約

制約	理由
オブジェクトごとに .sharingRules-meta.xml ファイルは1つのみ	プラットフォームの要件です。複数のファイルがあるとデプロイエラーが発生します
ゲストルールでは sharedTo に <guestUser> を使用する	<role> または <group> を使用すると、「ゲストユーザーのニックネームを guestUser フィールドに指定してください」というエラーが発生します
Account ルールには <accountSettings> が必要	指定しないと、「Account sharing rules には AccountSettings が必要です」というエラーが発生します
条件ルールでは includeRecordsOwnedByAll が必須	指定しないと、「必須フィールドがありません：sharingCriteriaRules」というエラーが発生します
ゲストルールでは includeHVUOwnedRecords が必須	指定しないとデプロイに失敗します
条件フィールドの値は、組織の選択リスト値として存在している必要がある	無効な値を指定すると、「選択リスト値が存在しません」というエラーが発生します
ファイルパスをハードコードせず、sfdx-project.json から解決する	顧客のプロジェクトでは、カスタムのパッケージディレクトリが使用されているためです
管理パッケージのカスタムオブジェクトには、名前空間プレフィックスを含む完全な API 名（例：ns__Object__c）を使用する	名前空間が付いたオブジェクトの共有ルールは、プレフィックス付きの名前で保存されます
sharedTo と sharedFrom はインプレースで編集できない	プラットフォームは共有対象の変更をサポートしていないため、デプロイに失敗します。代わりにルールを削除して、新しいルールを作成してください
所有者ベースのルールで編集できるのは accessLevel のみ	所有者ルールでは、その他のフィールド（label、sharedTo、sharedFrom）は変更できません。代わりに削除して再作成してください
編集または削除の前に、必ず組織から取得する	ローカルファイルが古い可能性があります。古いファイルを編集すると、削除済みのルールが再作成されたり、同時に行われた変更が上書きされたりするおそれがあります
ルールの削除には破壊的デプロイが必要	通常のデプロイは追加のみで、組織からルールを削除しません。platform-destructive-deploy に委任してください
編集時には変更しない要素を維持する	accessLevel のみを変更する場合、criteriaItems やその他のフィールドを変更してはいけません
削除時にはルールブロック全体を削除する	一部だけを削除すると無効な XML が残り、デプロイに失敗します
最後のルールを削除した場合は、ファイルも削除する	子要素のない空の <SharingRules> ルートは無効なメタデータです

---

注意事項

問題	解決方法
ゲストルールで <guestUser> の代わりに <role> を使用している	<guestUser>CommunityNickname</guestUser> に置き換えます
Account ルールに accountSettings がない	3つのアクセスレベルのサブ要素すべてを None に設定した <accountSettings> を追加します
条件ルールに includeRecordsOwnedByAll がない	<includeRecordsOwnedByAll>true</includeRecordsOwnedByAll> を追加します
選択リスト値が一致しない	条件を生成する前に、組織に問い合わせて有効な値を確認します
既存のルール名と重複するものを追加する	書き込む前に、既存の <fullName> の値を確認します
ゲストユーザーのニックネームが見つからない	次を問い合わせます：SELECT CommunityNickname FROM User WHERE UserType='Guest' AND IsActive=true
ユーザーが sharedTo または sharedFrom の編集を求めている	サポートされていません。編集を拒否し、ルールを削除して新しいルールを作成するよう案内します
ユーザーが accessLevel 以外の所有者ルールの編集を求めている	サポートされていません。所有者ルールで許可されているのは accessLevel の編集のみです。依頼を拒否し、削除して再作成するよう案内します
編集によってルールの種類が変わる（例：条件ルールから所有者ルールへ変更）	サポートされていません。代わりに古いルールを削除して、新しいルールを作成してください
ローカルファイルが古い（組織内でルールが削除または変更されている）	削除済みのルールが再作成されないよう、編集または削除の前に必ず組織から最新の情報を取得します
破壊的マニフェストを使用せず、通常のデプロイで削除した	ルールは組織に残ります。適切に削除するには、platform-destructive-deploy に委任してください
他の自動化から参照されているルールを削除する	下流への影響が生じる可能性についてユーザーに警告します
削除によって XML が不正な形式になった	削除後も XML の構造が正しく保たれていることを確認し、ファイルの整形式性を検証します

---

出力の期待事項

成果物：

• 取得操作の場合：<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml — 組織から取得した共有ルールファイルと、見つかったすべてのルールをまとめた整形済みサマリー
• 作成／編集／削除操作の場合：<packageDir>/sharingRules/<ObjectName>.sharingRules-meta.xml — 対象オブジェクトの完全な共有ルールファイル

---

スキル間の連携

必要な作業	委任先
権限セットの設定	platform-permission-set-generate スキル
カスタムオブジェクトの作成（対象オブジェクトが存在しない場合）	platform-custom-object-generate スキル
破壊的デプロイ（組織からのルール削除）	platform-destructive-deploy スキル

---

参照ファイル一覧

ファイル	読むタイミング
references/rule-types.md	フェーズ 2 — ルールを生成する前に、各ルールタイプの完全な XML スキーマを確認します
scripts/count-remaining-rules.sh	フェーズ 3、ステップ 8b（削除）— 共有ルール要素を数え、ファイルを削除すべきか判断します
examples/create-cases.md	フェーズ 4、ステップ 10 — 作成および追加のシナリオで想定される動作を確認します
examples/edit-cases.md	フェーズ 4、ステップ 10 — 編集のシナリオで想定される動作を確認します
examples/delete-cases.md	フェーズ 4、ステップ 10 — 削除のシナリオで想定される動作を確認します