consumer-goods-sync-management-configure

CG Cloud Mobile Sync をセットアップするには、Act 1（Setup Sync）、Act 2（Assign Users）、Act 3（Plan & Verify）の3つすべてを順番に実行する必要があります。同期の成果物をインストールするだけでは不十分です。 ベースラインのインストールは Act 1 の一工程です。それを終えてもセットアップは完了していません。

顧客の組織で Consumer Goods (CG) Cloud Mobile Sync をセットアップし、営業担当者が CG Cloud Mobile App をインストールして、その日の訪問予定をオフラインで確認できるよう、管理者または実装担当者をガイドします。関連する機能は、管理パッケージ Sync Management App（名前空間は実行時に解決されます。Session state の ns_prefix を参照してください）と CG Cloud のコア／Retail Execution設定にあります。

このスキルでは、実際のトランスポートで実行できる操作（Headless-360／汎用コア呼び出し（SOQL、sObject REST、Connect、Tooling）、sf のデプロイ、パッケージ内の global @RestResource /v1/* エンドポイント）を可能な限り自動化します。public なパッケージメソッドだけでは不十分です。管理パッケージでは public は名前空間内に限定され（サブスクライバー組織からはアクセスできません）、呼び出し可能なのは global／webservice／@RestResource メンバーのみです。汎用コア機能でも呼び出し可能なパッケージアクションでも工程を完了できない場合、このスキルは必要なものと、それを提供する担当者を報告し、その工程を中止します。機能を偽装することはありません。

対象範囲と完了の定義 — まずお読みください

範囲を限定する条件のない「CG Cloud mobile sync をセットアップする」「Retail Execution 用に sync をセットアップする」「Consumer Goods mobile sync を設定する」という依頼は、Act 1 → Act 2 → Act 3 の順に、3つの ACT をすべて実行することを意味します。「成果物をインストールするだけ」という意味ではありません。限定のない依頼に対してインストールだけを実行しようとしているなら、それを防ぐのがこのセクションの目的です。Act 1 のステップ 1（準備状況の確認）から始めてください。

成果物をインストールしただけでは完了ではありません。 Act 3 の終了時点（有効化された設定が一覧表示され、4つのオブジェクト全体で検証され、ベースラインファイルと照合済みの状態）に達して初めてセットアップが完了します。インストール後に終了した実行は部分的な実行です。その旨を明確に伝えてください。

Act 1 は「インストールだけ」ではありません。 インストール前に必須の準備確認ゲート（A1.1 の名前空間ゲートと A1.2 のRetail Execution の有効化）があり、インストール後にも確認（A1.4）が必要です。Retail Execution が有効でない組織にベースラインをインストールすると、同期できない設定が作成されます。そのため、まず準備状況を確認し、必須条件を満たさない場合は報告して中止し、回避策で処理することはありません。ベースラインのインストール自体が同期設定です（ルートの Sync_Config__c とその値はベースライン CSV から取得されます）。別途「設定を作成」する工程はありません。

スキルが完了できない工程は、その工程だけを中止する合図であり、実行全体を中止する合図ではありません。 該当する境界と、不足している要素を提供する担当者（CG Cloud プラットフォーム／Retail Execution、または組織管理者）を報告し、その後、妨げられていないすべての工程を続行してください。全工程を中止するのは、必須の準備条件を満たさない場合に限られます。同期メタデータが存在しない（パッケージがインストールされておらず、組織の名前空間も解決されない）、Retail Execution を有効化できず、かつすでに有効でもない、または Default_IOU の場合に対象ユーザーのデフォルトモビリティ IOU が不足している場合です。

正当に一部の工程だけを実行できるのは、管理者自身の依頼が限定的な場合のみです（例：「sync はすでにインストール済みなので、Chantelle を割り当てるだけ」「有効化済みの設定だけを確認する」）。ルーティング表を参照してください。依頼の範囲が限定されていない場合や、判断に迷う場合は、1 から 3 までのすべてを実行してください。

トランスポートの契約 — 自動化可能な各ステップは core または Sync Management App

これが誠実さの要です。ステップを実行する前に、そのトランスポートを把握してください。また、どのトランスポートでも完了できないステップについて、成功したように装うことは決してしないでください。

• core — Salesforce／Headless-360 の汎用機能：execute_api による直接の SOQL → GET /query?q=...；CG Cloud core の RetailExecutionSettings に対する取得→設定の組織設定トライアド；sObject REST の書き込み（POST /services/data/vXX.0/sobjects/<Entity>）；Schema／Tooling の describe 読み取り。
• Sync Management App — パッケージ内でトリガーされるアクション。実際のヘッドレスインターフェースは global @RestResource /v1/* エンドポイントで、主に次の 3 つの /v1/syncconfig/* ルートです：/install（GET で検出＋POST でインストール — A1.3）、/configs（GET でデプロイ済み設定＋戦略を取得 — A3.1 の一覧）、/assignment（GET／POST／DELETE でユーザー→設定の紐付け — A2.3）。public Apex メソッド（名前空間内限定）と Visualforce アクションは、Sync Management App ではありません。

どちらのトランスポートでもステップを完了できない場合は、不足しているものを報告し、それを提供する担当者を明示して、そのステップを中止してください。API 名を推測したり、回避策として書き込みを行ったりしてはいけません。実際に自動化できない箇所はわずかです。advanced-RE のパイロット版 GA ゲート（A1.2。プラットフォームの担当で、API なし）と、IOU メンバーシップの作成（A2.2。CG Cloud core／RE のタスクで、このスキルでは読み取りのみ）です。トランスポートの詳細なルールについては、references/transports-and-namespace.md を参照してください。

書き込み前に必須の計画 — 最初の書き込み前に提示すること

書き込みを 1 回でも実行する前に（RE の有効化、ベースラインのインストール、マッピング行の作成など）、対象範囲の判断を明示的かつレビュー可能な形で示す短い計画を提示してください。

1. 全体の流れは 3 つの幕で構成されます — Act 1（Sync のセットアップ）、Act 2（ユーザーの割り当て）、Act 3（計画と検証）。
2. 実行する幕／サブステップと、スキップする幕／サブステップ — スキップごとに、対象範囲を限定する管理者の依頼の正確な文言を引用してください（「依頼には『sync をセットアップして』と書かれていた」は、対象範囲を限定する条件ではありません）。完了できないステップがあれば、不足分を誰が提供するのかを明示してください。
3. 対象組織を明示的に確認してください（暗黙に引き継いではいけません）。また、パッケージオブジェクトに使用する解決済みの ns_prefix を指定してください。
4. 開始地点を明示してください。対象範囲が限定されていない依頼の場合は、Act 1 のステップ 1（準備状況：名前空間＋RE）から開始し、インストールから始めてはいけません。
5. この計画を作業ディレクトリの report.md に保存してください — そのファイルの書き込みが、組織への書き込みに先立つ最初のアクションです。各 Act の結果（実行したステップ、トランスポートタグ、読み戻し結果、ブロックされたステップ）を完了するたびに追記し、最後に最終判定を記載してください。このファイルが実行結果の成果物であり、チャットの記録ではありません。実行が早期に停止した場合でも、必ず存在していなければなりません。契約については、references/verify-and-smoke.md の「実行レポートをディスクに書き込む」を参照してください。

エントリーポイント — 管理者の実際の依頼に応じて進める

デフォルトのルール： 依頼で範囲が明示的に限定されていない限り、セットアップ全体として扱い、Act 1→2→3 を順番に実行します。 判断に迷った場合は、一連の手順全体を実行してください。

シグナル	開始箇所
「CG Cloud のモバイル同期をセットアップして」「Retail Execution の同期をセットアップして」／範囲を限定する条件がない／以前の状態が不明	一連の手順全体を実行します。組織を確認して名前空間を解決し、次に Act 1 のステップ 1（準備状況：名前空間＋RE）を実行してから、Act 1→2→3 を進めます。「インストールだけ」ではありません。Act 3 の終了状態に達するまで完了ではありません。
「同期はすでにインストール済みなので、ユーザーを割り当てるだけです」	範囲を限定 → Act 2。ユーザーを紐付ける前に、まずインストール済みの設定を読み戻し（Act 3 の一覧表示ステップ）、設定がデプロイ済みであることを確認します。
「Retail Execution のベースラインをインストールするだけでいいです」	範囲を限定 → Act 1 A1.3 のみ。ただし、A1.1/A1.2 の準備状況と、どのベースラインを使うかの明示的な確認が済んでから実行します。まず GET /v1/syncconfig/install で確認し、次に POST でインストールします。生の sObject 挿入で手動設定することは絶対に避けてください。スキップしたステップ（A1.4、Act 2〜3）は未完了として報告します。
「有効化されているものだけ確認／一覧表示して」	Act 3。読み取り専用で、書き込みはありません。
「Retail Execution を有効にして」	A1.2 のみ。CG Cloud のコア機能で、core への書き込みが成功することが必要です。プラットフォーム管理のパイロットゲートに該当するのは、advanced RE のみです（API なし）。

セッション状態（会話を通じて追跡）

• target_org_alias — 設定対象の組織。書き込みの前に明示的に確認します。
• ns_prefix — 名前空間プレフィックス（末尾に __ を含む）。A1.1 で実行時に検出します（ハードコードは厳禁）。一度解決したら、すべてのパッケージオブジェクトのパスで使用します。情報源は 2 つです。インストール済みの管理パッケージ（InstalledSubscriberPackage.NamespacePrefix）、または組織に登録された独自の名前空間（ソースをデプロイする DE／パッケージング組織の Organization.NamespacePrefix）。
• api_version — 生の HTTP URL に使用する Salesforce REST API バージョン。ハードコードは厳禁です。 GET /services/data で一度解決し、最も高い version を使用します。execute_api の呼び出しではバージョンを指定しません。
• org_ready — ブール値。A1.1 の名前空間ゲートと A1.2（RE が有効）の両方を通過すると true になります。いずれかで明確に失敗した場合は、実行を中止します。
• installed_config_id / installed_version — ベースラインのインストール（A1.3）から取得します。インストールされたもの自体が設定です。「設定作成済み」という別個のフラグはありません。
• act1_complete、act2_complete、act3_complete — Act ごとのブール値。必ず 1→2→3 の順に実行します。範囲が限定されていない依頼の場合、自動化できない手順について報告したものを除き、完了を報告する前に 3 つすべてが true でなければなりません。
• resolution_strategy — 設定ルートの Business_Area_Resolution_Strategy__c（Default_IOU または Custom_User_Field）。A2.3 が A2.2 を介した暗黙的な IOU 解決になるか、明示的なマッピング書き込みになるかを決定します。
• blocked_steps — スキルで完了できなかった手順の一覧。各手順について、境界と、不足している要素を提供する担当者を記録します。
• report_path — 実行のディスク上の成果物。作業ディレクトリに作成する report.md です。最初の組織への書き込みより前（事前書き込み計画の段階）に作成し、各 Act の区切りで追記します。これにより、途中で中断した場合でも、実行内容を正確に記録できます。チャットでの報告だけでは不十分です。記録はファイルとして存在する必要があります。

サブアクトごとのトランスポートマップ（概要）

各ステップで使用するトランスポートの信頼できる唯一の情報源です。詳細（API 名、フォールバック、担当者）については、references/transports-and-namespace.md、references/readiness-and-enablement.md、references/sync-management-app-install-backbone.md、references/verify-and-smoke.md を参照してください。

サブアクト	要件	トランスポート	注記
A1.1	同期メタデータが存在することを確認し、名前空間を解決する（必須の前提条件）	core	ここで唯一のハードストップとなるのは名前空間ゲートです（Tooling InstalledSubscriberPackage → それ以外の場合は Organization.NamespacePrefix）。ライセンスの読み取りは不要です（インストールにライセンスは不要）。また、権限セットの存在確認も不要です（権限セット名は変更または統合される可能性があります）。
A1.2	Retail Execution を有効にする	core	RetailExecutionSettings（ディスパッチャー、5 つの設定）または MDAPI Settings:RetailExecution（3 つのブール値）を介して読み取りと書き込みを行います。パイロット版 GA ゲートの対象となるのは advanced-RE のみです（API なし）。基本トグルには影響しません。
A1.3	確認を得て同期設定をインストールする（ベースラインのルートとサブ設定）	Sync Management App	SyncConfigInstallEndpoint /v1/syncconfig/install：GET discoverConfigs、POST installConfig。ベースラインは実行時に検出されます。ハードコードしないでください。インストールすること自体が設定です。 生の挿入による独自実装は行わないでください。
A1.4	追跡対象オブジェクトごとに、参照される項目セット定義が存在することを確認する	core（読み取り専用の describe）	名前は CSV によってインストールされます。定義（例：RetailMobilityRelevant）はパッケージではなく RE によってプロビジョニングされます。セットがない場合は報告して停止します。担当者は RE プロビジョニングです。
A2.1	対象ユーザーが存在することを確認する	core	execute_api を介した User SOQL。
A2.2	ユーザーが Mobility IOU に所属していることを確認する	core の読み取り専用前提条件（Default_IOU のみ）	InternalOrgUnitUser を読み取ります（IsDfltMobIntrOrgUnit = true）。IOU メンバーシップへの書き込みは行いません。Default_IOU に行がない場合は報告して停止します。Custom_User_Field の場合はスキップします。
A2.3	ユーザーをインストール済み設定に割り当てる	Sync Management App / IOU に暗黙的に依存 → A2.2	SyncConfigAssignmentEndpoint /v1/syncconfig/assignment（GET/POST/DELETE）。core は使用しません。直接書き込むと、オーバーロードされている Business_Area_Name__c が破損します。
A3.1	4 つのオブジェクトにわたって、有効化された設定を一覧表示し、検証する	Sync Management App（一覧表示）+ core（件数）	SyncConfigListEndpoint /v1/syncconfig/configs。4 つすべての COUNT() を1 回のバッチ化された匿名 Apex 呼び出しで実行します（オブジェクトごとに sf data query を繰り返すループは使用しません）。/v1/syncconfig/verify はありません。レコード件数が検証そのものです。
A3.2	ベースラインの静的リソースファイルと照合する	core	インストールされたオブジェクトごとの件数を、インストールされたベースラインが宣言する件数と照合します。件数は実行時に導出し、ハードコードしないでください。

Act 1 of 3 — 同期のセットアップ

インストール前に準備状況のゲートを確認し、インストール後に簡易的な反映確認を行います。オブジェクトごとの完全な検証は Act 3 で行うため、ここでは繰り返しません。ベースラインのインストールは中間ステップであり、アクト全体ではありません。

1. A1.1 — 同期メタデータの存在を確認し、名前空間を解決する。 core。同期オブジェクトが存在することを確認し、ns_prefix を解決します（Tooling の InstalledSubscriberPackage からパッケージを取得し、それ以外の場合は Organization.NamespacePrefix を使用）。どちらからも解決できない場合に限り、重大な不在として停止します。 パッケージのインストールにライセンス確認は不要なため、ここではライセンスを読み取りません。また、権限セットを名前で確認しないでください（権限セット名は変更または統合される場合があります）。Act 1 の実際の準備ゲートは、メタデータの存在確認（このステップ）と RE の再有効化（A1.2）の 2 つだけです。
2. A1.2 — Retail Execution を有効化する。 core の読み取りと core の書き込み。読み取りには RetailExecutionSettings（ディスパッチャー）または MDAPI Settings:RetailExecution を使用します。有効化にはディスパッチャーの PATCH セッター、または sf project deploy start --metadata "Settings:RetailExecution" を使用します（false→true に設定し、再読み込みして確認します）。RE の再有効化により、基本プロビジョニングも行われます。高度なパイロットの切り替え項目（orgHasAdvncdRetailExecutionPilot）には API がなく、高度な RE だけを制御します。
3. A1.3 — 同期設定を 4 つのオブジェクトにインストールする。 Sync Management App。discoverConfigs を GET します（実行時に検出するため、「Standard」という名前の設定はありません）。選択したベースラインと、そのマニフェストから算出したオブジェクトごとの件数を提示した後、管理者から明示的な OK を得た場合にのみ POST します。サブ設定は子ベースラインです。parentConfigId はマニフェストから取得し、親を先に処理する順序を保証します。生の sObject insert を使って手作業で構築しないでください。SUCCESS が返されたら、4 つすべての core COUNT() をまとめて実行する簡易的な集計チェックだけで、反映を確認します。つまり、1 回のバッチ化された anon-Apex 呼び出しを使い、合計が InstallResponse.recordsInserted と一致することを確認します（オブジェクトごとに sf data query をループしてはなりません。コールドスタートでタイムアウトするためです）。マニフェストの取得は不要です。これは Act 3 のオブジェクトごとの比較とは異なります。
4. A1.4 — 参照されているフィールドセット定義の存在を確認する。 core の読み取り専用 describe を使用します。デプロイはしません。 同期クエリのフィールドパスはセットが存在しない場合に例外を投げ（最初の同期で致命的なエラーになります）、同期対象のオブジェクトごとに確認する必要があります。不足があれば報告して停止します。担当者は RE プロビジョニングです。

Act 1 の終了状態： パッケージが存在する（ゲート通過）か、存在しないことを報告して実行を停止しており、RE が有効になっています。管理者の明示的な確認後、管理者が確認したベースラインが 4 つのオブジェクトにインストールされ（installed_config_id／installed_version を記録済み）、集計の COUNT()==recordsInserted チェックで反映が確認されており（ベースラインのオブジェクトごとの検証は Act 3 で実施）、参照されているフィールドセット定義の存在も確認済みです。詳細：references/act1-setup-sync.md。

3幕構成の第2幕 — ユーザーを同期設定に割り当てる

第1幕の後に実行します（第1幕でインストールした設定にユーザーをバインドします）。A2.3 のトランスポートを選ぶ前に、設定ルートの解決方式を特定します。

1. A2.1 — 対象ユーザーが存在することを確認します。 core。execute_api 経由で User を SOQL します。
2. A2.2 — ユーザーの Mobility IOU メンバーシップを確認します。 core の読み取り専用の前提条件で、Default_IOU の場合のみです。 デフォルトのモビリティ IOU（IsDfltMobIntrOrgUnit = true）を読み取り、iouId を A2.3 に引き継ぎます。該当する IOU がない場合は、報告して停止します（このスキルでは IOU メンバーシップを作成しません）。Custom_User_Field の場合は完全にスキップします — 「IOU がなければ停止」という一律のルールに一般化しないでください。
3. A2.3 — ユーザーを設定に割り当てます。 Sync Management App（マッピング行）／core（IOU による暗黙の割り当て）。割り当てでは、User（005）、Role（00E）、または Profile（00e）をバインドします。Role／Profile の行は、コホート全体をバインドします。GET /v1/syncconfig/configs で設定を選び、名前を Id に解決して、戦略に応じてスコープを指定します（Default_IOU → iouId、Custom_User_Field → businessArea ピックリスト）。/v1/syncconfig/assignment に POST してから GET で読み戻し、返された短い正規形の clientAppId を確認します。再割り当てはアップサートです。先に GET してください。重複する (configPath, businessArea, mappedRecordId) の組み合わせは拒否されます。バインドを移動する場合は、古い行を DELETE してから POST します。Sync_Client_App_Profile_Mapping__c に直接書き込まないでください — このエンドポイントでオーバーロードされた Business_Area_Name__c を導出する必要があります。

第2幕の完了状態： 対象ユーザーが確認済みで、Default_IOU の場合はデフォルトのモビリティ IOU も確認済み（または報告して停止済み）です。ユーザーはインストール済みの設定にバインドされ、読み戻しで検証されています。詳細：references/act2-assign-users.md。

3幕構成の第3幕 — 計画と検証

最終幕です — 正式な検証を行います（第1幕では簡易的な集計ランディングチェックのみ実施し、オブジェクトごとの比較はここで1回だけ行います）。条件なしのセットアップでは、この幕の完了状態に到達する必要があります。インストール後に停止しないでください。

1. A3.1 — 4つのオブジェクト全体で有効化された設定を一覧表示して検証します。 Sync Management App（一覧表示）＋ core（件数）。GET /v1/syncconfig/configs でデプロイ済みの設定と戦略を一覧表示します（代替手段として core の SOQL 一覧も使用できます）。4つの同期オブジェクトと Sync_Config_State__c（カスタム設定）の全件数は、1回のバッチ化した匿名 Apex COUNT() 呼び出しで取得します。オブジェクトごとの sf data query ループは使用しないでください（コールドスタートでタイムアウトします）。/v1/syncconfig/verify はありません — レコード件数が検証そのものです。
2. A3.2 — ベースラインの静的リソースファイルと照合して検証します。 core。インストール済みのオブジェクトごとの件数を、実行時に算出したインストール済みベースライン自身が宣言する件数と比較します（A1.3 で取得した有効化済み設定／バージョンからベースラインを特定します）。このオブジェクトごとの内訳の検証が A3.2 の役割です（合計件数のランディングチェックは第1幕で実施済みです）。これにより、合計は正しいものの内訳が異なるインストールを検出できます。件数をハードコードしないでください — ベースラインによって異なります。

第3幕の完了状態： 有効化された設定が /v1/syncconfig/configs で一覧表示され、core SOQL のレコード件数を通じて4つのオブジェクト（＋状態）全体で検証され、各件数がベースライン自身の宣言する件数と一致しています。詳細：references/act3-plan-verify.md。

スキル全体の完了条件

条件なしの CG Cloud モバイル同期セットアップが完了するのは、3つの幕すべてがそれぞれの完了状態に到達した場合のみです。スキルで完了できなかった手順がある場合は、その旨を明示して、必要な情報や作業を提供する担当者も記載してください。第1幕（組織の準備完了、管理者がベースラインのインストールを確認、フィールドセット定義の検証 — または不足しているセットを報告して停止）→ 第2幕（ユーザーの存在を確認、Default_IOU の場合はデフォルトのモビリティ IOU を確認 — または報告して停止、設定をバインド）→ 第3幕（有効化された設定を一覧表示し、core SOQL の件数を使ってベースラインファイルと照合・検証）。インストール（A1.3）だけで「完了」と報告するのは不備です。最後に、未完了の項目と、それぞれの不足部分を誰が提供するのかを明示的に列挙してください。

対象外／保留

期待値を設定するために記載しており、Act シーケンスを中止する理由ではありません。

• orgHasAdvncdRetailExecutionPilot の有効化トグルの削除／GA ゲート化 — CG Cloud コア（Retail Execution）。API はどこにもありません（A1.2）。
• 提供済みのものを超える新規／カスタムベースラインの作成（実行時に検出）— このスキルの対象外である、手動での ZIP（manifest + CSV）作成。
• Mobility IOU メンバーシップの作成（A2.2）— CG Cloud コア／RE のタスクです。このスキルでは読み取りのみを行います。

関連資料

• references/act1-setup-sync.md、references/act2-assign-users.md、references/act3-plan-verify.md — Act ごとに独立した詳細説明です。
• references/transports-and-namespace.md — トランスポートと名前空間のルール、および sf CLI の使い方です。
• references/readiness-and-enablement.md — 名前空間のゲートと RE の有効化の詳細です。
• references/sync-management-app-install-backbone.md — Sync Management App のインストール基盤です。
• references/verify-and-smoke.md — 検証とスモークテストのパターンです。
• examples/scenarios.md — 検証シナリオの実例（正しい実行とアンチパターンの実行）です。