platform-dsar-policy-manage

platform-dsar-policy-manage: DsarPolicy のデータポータビリティ権、エンドツーエンド

DsarPolicy（データポータビリティ権（RTP）のエクスポートを制御するメタデータ）を、そのライフサイクル全体にわたって運用します。ツリーを設定し、エクスポートを実行し、実行を監査します。DsarPolicy は読み取り／エクスポートマップです。エクスポートで収集する対象者のレコードを指定します。データを削除することは決してありません。ここで重要なのは、XML の処理ではなく、判断です。

すべての応答の最初の行 — スキルについて説明しないでください。 最初に出力するトークンは、手順の実況ではなく、作業または回答にしてください。「これはカバレッジギャップ監査／ワークフロー D です……」「スキルのガイド／仕組みを読みます……」「ルール #1 に従って……」「SOR を見つけます……」などで始めないでください。 ワークフローの名前を挙げたり、これから読む参照ファイルを告げたり、実行前に手順を説明したりしないでください。まず作業（ツールの呼び出し）を始め、完了したら結果を提示してください。これは、ここで最初に明示しておく必要がある、根幹をなす呼び出し #8 です。最初のトークンに関わるためです。ユーザーのデータ／組織について平易な言葉で述べるのは問題ありませんが、スキル、ワークフロー、ルール、ツール、ファイルについて述べる文は避けてください。

根幹をなす呼び出し（正しく行わないとタスクは失敗します）

これらは、依頼文の冒頭にどんな表現があっても優先されます。毎回、最初に確認してください。呼び出し #1 は、ワークフローを選ぶ前、sf コマンドを実行する前に行う、すべてのタスクで文字どおり最初のアクションです。

1. 最初に必ず SOR ツールを経由してください — 例外なく、sf／エンドポイントを呼び出す前に実行します。 ここでのあらゆるタスク（「ポリシーが存在するか／ポリシーを一覧表示」といった簡単な読み取り専用の照会も含む）で、最初に行うことは、今回の実行で利用可能なツールから、discover / describe / dispatchの動詞を公開する機能ルーティングツールを探すことです（現時点では project-codey / Headless 360。mcp__<host>__discoverのような任意のホスト接頭辞も対象です。固定名ではなく動詞の形で判定してください）。該当するツールがあれば、それを最初に使います。DsarPolicyManager SOR（所有者は Privacy Center。isActiveが実行／編集／削除を制御します）に対してdiscover → describe → dispatchを行い、似ているだけのもの（データマスク、汎用的な同意、対象者の消去）は除外してください。「簡単な照会に見える」という理由で反射的にsfを最初に使うのは、繰り返し発生している最大の誤りであり、たとえそれで処理できたとしても正しくありません。sfを使うのは、ルーティングツールが利用できない場合に限るフォールバックです（どの組織でローカル認証済みかを確認するためにsf org listを実行するのは問題ありません。これはクライアント側の認証確認であり、SOR 呼び出しではありません）。以下のワークフローに記載されているすべてのsf／salesforce-api-contextコマンドは、ルーティングツールがない場合の記法です。ルーティングツールがある場合は、同等の操作をそちらからディスパッチしてください。詳細：references/headless-sor.md。
2. 消去ではなく、エクスポートしてください。 実行によって生成されるのはエクスポートファイルです。対象者のデータを消去／秘匿化／削除するわけではありません。依頼が削除（「取り除く」「消去する」「消し去る」）として表現されている場合は、まずその認識を正し、対象者のデータを消去したと報告してはいけません。消去は別の仕組みです。それが目的であれば、その旨を伝えて停止してください。認可が明確であれば、前提を正した後にエクスポートを実行してもかまいません。
3. 個人データを推測しないでください。 どのオブジェクト／関連に対象者のデータが含まれるかを分類するのは、管理者の判断事項です。依頼でその判断を委ねられている場合（「何が該当するか判断して」「全体を組み立てて」など）、推測したツリーを作成してはいけません。管理者が判断すべき事項（ルート、関連ごとの追跡／停止、項目）を列挙し、提案はすべて管理者の判断待ちとして示してください。範囲を広く推測すると、他の人のレコードまでエクスポートされます。
4. 上限は厳守してください — 上限を明示して停止し、グラフをたどらないでください。 ツリーの上限は、パスあたりの子 10 件、深さ 10、ノード 200 件です。上限のない依頼（「すべて」「グラフ全体」）は収まりません。「試しに」オブジェクトグラフを列挙してはいけません（終わりがなく、ターンを浪費します）。超過した具体的な上限を明示し、範囲を限定した代替案（ポリシーを分割する、ブランチを削減する）を提示してください。黙って途中で切り詰めてはいけません。
5. 数回ポーリングしたら確認してください — 終了まで待ち続けないでください。 実行ハンドルはステータスとファイルの両方を提供します。早すぎるgetfileはNOT_FOUND／"This file isn't ready yet"を返します。これは正常な動作であり、失敗ではありません。2～3 回ほどポーリングし、それでも終了状態にならなければ、ポーリングを続けるかユーザーに尋ねて停止してください。ループしてはいけません。後続の非同期処理によって、実行が終了状態にならないまま無期限に留まる場合があります。これはプラットフォーム／Tool Factory の領域であり、このスキルで診断したり介入したりするものではありません。ステータスをわかりやすく（実行中／完了／エラー）報告し、判断はユーザーに委ねてください。終了状態になる前にダウンロードしてはいけません。失敗した実行でも HTTP 201 が返ることがあります。HTTP コードではなく、本文の**エンベロープ／RequestStatusを確認してください。getfile のセグメントはdsarではなくdsr**です。
6. 履歴の確認は読み取り操作です。 実行履歴はDsarPolicyLogに対するSOQL クエリです。installListViewでも UI の一覧でもありません。実行は開始されません。
7. 自動で有効化したり、再公開したりしてはいけません。 有効化は、明示的な人間の確認を経て行う手順です。ACTIVE ポリシーを編集するには、まず無効化する必要があります — 無効化 → 編集 → 停止し、結果を報告してから、再有効化する明示的なユーザー確認を得てください。新しいポリシーは、ユーザーが有効化するまで INACTIVE のままです。自動で再公開すると、異議申し立てに必要な監査証跡の確認可能性が損なわれます。
8. 内部の処理について説明せずに作業してください（すべてのワークフローに適用されます。上部の説明を参照）。 ユーザーは業務上の質問をしています。その質問に答え、スキルがどう回答するかを説明してはいけません。ツールを実行して結果を提示し、途中経過を説明しないでください。次のような内容を途中で説明してはいけません。スキルのガイド、仕組み、参照ファイルをこれから読む／読んでいること（「スキルのガイドと仕組みを確認します」など）、どのワークフローに該当するか（「これはカバレッジギャップ監査／ワークフロー D です」「ワークフロー C の形式で確認します」など） — ユーザーはワークフローの文字で考えていないため、名前を出してはいけません。使用している SOR／ルーティングツール、または「スキーマを読み込み中／検出中／ディスパッチ中」であること。重要なルールの番号（「ルール #1 に従って」など）。似ているだけのものを除外する手順。操作の流れや GET と dispatch の使い分け（getAccessInfo、dispatch_readonlyなど）。これらは作業の進め方であり、進捗報告ではありません。（実行環境が通常のツール呼び出し行を表示するのは問題ありません。自分で逐一説明を加えないでください。）ユーザーに提示するのは最終回答と、呼び出しに必要な場合の平易な質問（AskUserQuestion）、またはユーザーの組織に関する短い範囲／同意の説明です（「ポリシーの一覧表示のみ行い、変更はしていません」「これはエクスポートであり、削除ではありません」など）。目安として、ユーザーのデータ／組織に関する文はユーザーに提示できますが、スキル、ワークフロー、手順、ツール、ルール、ファイルに関する文は内部にとどめてください。ワークフロー D の手法に関する前置きだけは、許可された「これからこう進めます」という説明です。それも、監査の進め方を平易に説明し（「ポリシーのオブジェクトから 1 階層外まで確認し、個人データが含まれる可能性のある項目を示します」など）、ワークフローの文字、ルール、ツール、ファイルは一切挙げてはいけません。この前置きは、「これはワークフロー D です」や「仕組みを確認します」と説明する許可ではありません。

DsarPolicy オブジェクトモデル

各エンティティには異なる方法でアクセスします。対象を推測することが、最も時間のかかる作業です。

エンティティ	内容	アクセス方法
DsarPolicy	ポリシーの基本情報とライフサイクル（ACTIVE/INACTIVE）	メタデータ API
DsarPolicyPath	ツリーノード。ルートオブジェクト、または親→関連の関係	メタデータ API（DsarPolicy の子）
DsarPolicyField	パスで収集されるフィールド	メタデータ API（パスの子）
DsarPolicyLog	実行ログ（実行ごとに 1 行）	標準 SOQL
エクスポートの実行	—	Connect DSR エンドポイント（POST）
ステータス／getfile	—	ハンドル上のConnect DSR エンドポイント。getfile のセグメントは dsr

connect の正確なルート／バージョンは、実行時に salesforce-api-context（または sf）を使って解決してください。sf sobject describe DsarPolicy* は実行しないでください。ツリーはメタデータであり、標準 SOQL で応答するのは DsarPolicyLog だけです。MCP サーフェスでは、各行が 1 つの DsarPolicyManager 操作に対応します。

動詞に応じてワークフローを選択する

実行したいこと	実行するもの	終了条件
ポリシーツリーを設定／編集する	A — 設定	有界なポリシーを INACTIVE で作成したとき。または、上限のないリクエストで上限を明示したとき／仕様が不十分なリクエストについて判断事項を列挙し、そこで停止したとき
対象者のエクスポートを実行する	B — エクスポート	対象者をルート Id に解決し、実行ステータス（実行中／完了／エラー）を読み取り、成功時にファイルを特定したとき。または、数回ポーリングしても実行中の場合、続行するかユーザーに確認したとき
過去の実行を確認する	C — 履歴	DsarPolicyLog から過去の実行を報告し、新たな実行を開始していないとき
未対応の PII を見つける	D — カバレッジギャップ	フィールドごとの理由を添えて候補を提示し、処置の判断は管理者に委ねたとき。読み取り専用

複数の依頼が混在する場合は、求められたことだけを実行してください。設定にエクスポートを追加したり、履歴の確認で実行を開始したりしないでください。

以下の各ワークフローは、呼び出し #1 がすでに完了していることを前提とします。discover／describe／dispatch SOR ツールを通じてルーティング済みか、利用可能なルーティング先がないことを確認済みである必要があります。各ワークフローにある sf／salesforce-api-context コマンドは、ルーティングツールがない場合の記述です。ルーティングツールがある場合は、それを通じて同等の操作をディスパッチしてください。

ワークフロー A — 設定

手順（メタデータの構造、関係／フィールドの解決、ライフサイクルの遷移）：references/configure.md。

1. 最初に分類する — describe を実行する前に条件に応じて終了します。 3 つのパターンがあり、そのうち 2 つは作成に進みません。
   • 上限なし（「すべて」「グラフ全体」）— 上限に収まりません。describe／ツリーの走査はしないでください。上限拒否レポート（呼び出し #3）を作成して終了します。
   • 仕様不十分 — 分類を委ねられており、ルート／フィールドが指定されていません。推測して作成しないでください。確認事項レポート（管理者の判断事項。複数のルートに対応し、提案は処置待ちとして記載）を作成して終了します。
   • 範囲が限定され、仕様が明確 — 指定されたルート／関係／フィールドが上限内に収まる場合は続行します。
2. 型を確認し、指定されたオブジェクトのみを describe する（名前を推測せず、指定された範囲を超えて展開しないでください）。

   sf org list metadata --metadata-type DsarPolicy --target-org <alias> --json
   sf sobject describe --sobject <NamedObject> --target-org <alias> --json
   

   DsarPolicy を一覧表示／describe できない場合は、その旨を報告して終了します（許容される終端結果です）。
3. ツリーを検証する（上限／名前を目視で判断しないでください）。

   python3 scripts/validate-policy-tree.py <tree.json>
   

   子の数 ≤10、深さ ≤10、ノード数 ≤200、および devname [a-zA-Z]+[a-zA-Z0-9_]* を確認します。
4. 承認された方針に忠実に、${outputDir} の下にメタデータを INACTIVE で作成します。承認されていないパスを追加せず、承認済みのパスを削除しないでください。

   ライフサイクルのゲート： 編集／削除は INACTIVE、実行は ACTIVE の状態で行います。ACTIVE のポリシーを変更する場合は、無効化 → 編集 → 停止の順に行ってください。再有効化の前に、ユーザーから明示的な確認を得てください（呼び出し #7）。

5. デプロイ（ベストエフォート）： sf project deploy start --source-dir <outputDir> --target-org <alias> --json。 型が完全に有効化されていない場合、デプロイが失敗することがあります。その場合は、未加工のエラーと前提条件を報告してください。成功したように装ってはいけません。デプロイの成否にかかわらず、分類作業は有効です。
6. 到達した結果を、references/report-format.md に従って報告します。結果は 上限拒否／確認事項／作成済み のいずれかです。切り詰めたツリーを「完全」として報告してはいけません。

ワークフロー B — エクスポートを実行する

エンドポイント、エンベロープのサンプル、ポーリング／ダウンロードの手順：references/export-and-history.md。

• B0. 対象者を特定します。 リクエストで受け取るのは dataSubjectId ではなく、メールアドレス／名前／ID です。 選択したポリシーのルートであるレコードの Id に解決します（Account／Contact／ Individual／Lead／User）。例：SOQL で Lead／Contact を Email により検索します。タイプがポリシーの ルートであることを確認します（実行対象は、対象者のタイプのルートサブツリーのみです。ルート以外の対象者を指定すると、何もエクスポートされません）。一致が0 件／複数件／ルート以外の場合は、停止して報告します。推測した Id で実行してはいけません。
• B1. 前提条件を確認します。 ポリシーは ACTIVE である必要があります（そうでない場合は A に進みます）。DSR のルートは salesforce-api-context で解決します。
  • ポリシーを慎重に選択します。 名前が指定されている場合はそれを使用します。指定がない場合は、コンテキスト内のポリシーを使用します。ポリシーが特定されていない場合、または該当する可能性のある ACTIVE ポリシーが複数ある場合は、確認を求めます（例：「<subject> に対して <policy> を実行します。よろしいですか？」）。黙って選択してはいけません。
  • アクセス： 401／403 の場合は、ガードを明示して停止します。ユーザー権限 Consent.CAN_EXECUTE_DSAR_POLICY、 組織機能 Consent.hasDsarPortability です。このエラー経路でも、ポーリングしてからダウンロードする順序を明示します（許容される終端結果です。やみくもに再試行してはいけません）。
• B2. 同意を確認し、削除について正しく説明します（呼び出し #2）。 削除として説明されている場合は、まず訂正します（消去ではなくエクスポートです）。承認が曖昧な場合は、AskUserQuestion で確認します。承認が明確な場合は続行します。
• B3. 実行 — HTTP コードではなくエンベロープを信頼します。 POST execute を実行し、実行ハンドルを取得します。 実行に失敗していても HTTP 201 が返る場合があります。エンベロープのステータスを確認し、失敗を示している場合は失敗として報告します。
• B4. 2～3 回ポーリングしてから確認を求めます。ダウンロードは終端状態になってからのみ行います（呼び出し #5）。 ハンドル（または DsarPolicyLog.RequestStatus）をポーリングします。初期段階の NOT_FOUND／「not ready」は想定内です。数回ポーリングしても終端状態にならない場合は、停止して、ポーリングを続けるか確認します。ループしてはいけません（非終端状態は後続の非同期処理を意味し、このスキルで診断する対象ではありません）。実行中／完了／エラーを報告します。
• B5. ダウンロード（終端成功の場合のみ）— セグメントは dsr。 dsar セグメントは 404 になります。エクスポート先を報告します。
• B6. references/report-format.md に従って報告します。解決した対象者（id + type）と選択したポリシー（曖昧な場合に確認したことも含む）、同意の確認、削除ではなくエクスポートであること、エンベロープ／実行ステータスに基づく結果を平易な言葉で示し、成功時はファイルの場所を伝えます。ポーリングの順序（数回ポーリングし、終端状態になってからのみファイルを取得し、まだ実行中なら確認したこと）を明示します。前提条件により実行できなかった場合も、順序を明示します。

ワークフロー C — 履歴（読み取り）

sf data query --target-org <alias> \
  --query "SELECT Id, DsarPolicyId, RequestStatus, CreatedDate FROM DsarPolicyLog WHERE DsarPolicyId = '<POLICY_ID>' ORDER BY CreatedDate DESC"

過去の実行（日時、ステータス）を報告します。「過去の実行なし」も有効な結果です。ログがない場合、または 401／403／404 の場合は、生のエラーと前提条件を提示します。ポリシーを実行してはいけません。installListView や UI リストは使用しないでください。

ワークフロー D — カバレッジギャップ分析（読み取り専用監査）

「まだ対象になっていない個人データはありますか？」 読み取り専用で決定論的に実行し、管理者向けに候補を提示します。分類や追加、有効化は行いません。スクリプトと評価基準は references/gap-analysis-guide.md、仕組みは references/gap-scan.md を参照してください。

1. 平易な方法の説明から始める（呼び出し #8） — ユーザーに合わせた言葉で、1文で説明します。ポリシーのオブジェクトから1階層だけ外側を確認し、PIIの可能性があるフィールドをそれぞれ理由とともに提示し、判断は管理者に委ねます。「ワークフロー D」「カバレッジギャップ監査」「仕組みを確認します」とは言わず、平易な言葉で手法を説明して、すぐに始めます。
2. 現在のカバレッジを確認する（読み取り専用） — ギャップは現在のカバレッジを基準にします。
3. 1ホップのみスキャンし、範囲を制限する — 各ルートと、プライバシー上もっとも関連性の高い1ホップのオブジェクトを最大約5個説明します。デフォルトは深度1で、再帰しません。生の --json による describe の内容を決してターンに読み込まないでください。全件の describe は約100KBあり、蓄積されたペイロードがイベントストリームの上限を超えて、レポートを書き込む前に実行が切り詰められます（ここで最も多い失敗です）。各 describe はまず {name,type,label} に絞り込んでください（references/gap-scan.md を参照）。ポリシー／タイプを読み取れない場合（機能が無効 — 対応している環境変数の経路）、ルートの describe を1件だけ絞り込んで取得し、そこで止めます。対象を広げないでください。ルートと1ホップの describe を2、3件使ってレポートを書き、スキップしたオブジェクトを明記して、深度ゲートを通じて確認できると案内します。成果物は作成したレポートです。すべてを集めてからではなく、早めに下書きを作成して書き込みます。
4. 候補にはフィールドごとに理由を付ける — コンプライアンスメタデータ > フィールドタイプ > 名前の意味、の順に優先します。「これはPIIです」と断定しないでください（呼び出し #3）。
5. 透明性をもって報告する — スキャンしたオブジェクト、各候補とその理由、カバー済みの項目と新たに見つかった項目、そして1階層という制限を明記します（候補がない場合も同様です）。
6. 深度を確認する — 明示的な確認があった場合のみ、さらに深く調べます（出力が大きく、コストがかかることを警告します）。
7. 判断を仰ぎ、変更はしない — 追加する項目を尋ねます。追加する場合はワークフロー A に引き継ぎます（INACTIVE の状態で、再有効化前に確認を求めます — 呼び出し #7）。

クイックルールと注意点

状況	対応
あらゆるタスクの開始時（単純な「一覧表示／ポリシーの有無の確認」という読み取りでも）	まず、今回の実行で利用できるツールから、discover／describe／dispatch のルーティングツールを探します（project-codey／Headless 360、または mcp__<host>__… という名前のもの — 動詞の形式で判別）。見つかった場合は、DsarPolicyManager SOR に対して discover／describe／dispatch を実行します。反射的に sf から始めないでください。ルーティングツールが利用できない場合に限り sf を使います（ローカル認証の sf org list は例外です）。
「すべて／グラフ全体を取得」	上限（10/10/200）を超えます — 上限を伝え、分割または絞り込みを提案します。グラフ全体をたどらないでください。
「不足しているPIIは何ですか？」	ワークフロー D — 読み取り専用、深度1。候補と理由を示し、判断は管理者に委ねます。追加も有効化もしません。
対象者がメールアドレス／名前で指定され、Id がない	先に解決します（B0）：ポリシーのルートエンティティをクエリし、ルートタイプを確認します。該当なし／複数／ルート以外の場合は停止します。
該当する可能性のある ACTIVE ポリシーが複数ある	実行前にどれを使うかユーザーに確認します。黙って選ばないでください。
数回ポーリングしても実行が In Progress のまま	下流の非同期処理（Tool Factory／プラットフォーム）に関するものであり、このスキルで診断する対象ではありません。実行中のままであると報告し、ポーリングを続けるか尋ねます。ループしないでください。
getfile が「未準備」／NOT_FOUND	終了前には想定される状態です。再度ポーリングしてください。失敗ではありません。
execute で HTTP 201 が返る	成功ではありません。エンベロープのステータスを確認してください。
getfile が 404	セグメントは dsar ではなく dsr である必要があります。
ACTIVE ポリシーを編集した直後	自動で再有効化しないでください。停止して状況を報告し、明示的な確認を得てください（呼び出し #6）。
sf sobject describe DsarPolicy の結果が空	ツリーは Metadata-API です。SOQL で取得できるのは DsarPolicyLog のみです。
DsarPolicy タイプが存在しない	そのことを伝えて停止します。捏造しないでください。
401／403／404 またはタイプが見つからない	前提条件を明示して停止します。やみくもに再試行しないでください。

出力（${outputDir}/report.md に書き込み）

実行したワークフローのみを報告します。各コマンドは1回だけ記載し、重要な結果は最初の画面内に示してください。 簡潔にしてください — 重要なポイント（ポーリング順序、削除ではなくエクスポート、1階層の上限）はそれぞれ1回だけ述べ、導入、補足、次の手順のリストで繰り返さないでください。約150行を大幅に下回る長さにし、オブジェクトごとの網羅的なダンプを貼り付けないでください。事前チェックでエラーとなる場合（機能／ポリシー／対象がない場合）は、阻害要因と前提条件を示し、順序を1回だけ述べて終了します。簡潔にしてください。ワークフローごとの契約（INACTIVE／再有効化確認のライフサイクルとポーリング順序を含む）：references/report-format.md。

リファレンス索引

ファイル	用途
references/headless-sor.md	MCP の操作面：SOR の検出→説明→ディスパッチ、類似対象の拒否、sf によるフォールバック
references/configure.md	メタデータの形式、ルート／リレーションシップの解決、<tree.json> 入力、ライフサイクル、複数ルート
references/export-and-history.md	DSR の実行／ステータス／ファイル取得ルート、エンベロープ、ポーリング順序、dsr セグメント、履歴クエリ
references/report-format.md	ワークフローごとのレポート契約
references/gap-analysis-guide.md	ワークフロー D：監査スクリプト、手順、候補フラグ付けの基準
references/gap-scan.md	ワークフロー D の仕組み：1ホップの列挙、差分、深度ゲート、レポート形式
scripts/validate-policy-tree.py	作成前の決定論的な上限および devname のチェック