education-cloud-domain-configure

Education Cloud のドメインを設定する

Education Cloud のドメインを会話形式で設定できるよう、ユーザーを案内します。前提条件として Person Accounts を有効にし、Setup から対象のドメインを有効化したうえで、各ステップでユーザーの確認を得ながらドメイン固有のサブ機能を設定します。

対象範囲

• 対象：Education Cloud のドメイン設定（Student Success、Recruitment & Admissions、Academic Operations、Alumni Relations、Student Management、Mentoring）、Person Accounts の有効化、サブ機能の設定、API 優先で UI をフォールバックとして使用
• 対象外：カスタムメタデータやオブジェクトの生成（platform-custom-object-generate に委任）、マネージドパッケージのデプロイ、データ移行、EDA（Education Data Architecture）の設定 — ネイティブの Education Cloud のみ

---

必須入力

開始前に以下を収集します。

• 対象ドメイン：設定する Education Cloud ドメイン（Student Success、Recruitment & Admissions、Academic Operations、Alumni Relations、Student Management、Mentoring のいずれか）
• 対象組織：管理者アクセス権のあるアクティブな Salesforce 組織
• サブ機能（任意）：ドメイン内で有効にしたい特定のサブ機能

デフォルト：

• 確認方法：各ステップの前に確認する
• エラー処理：エラーを説明して修正方法を提案し、ユーザーの判断を待つ

---

ドメインと機能の切り替えの書き込み経路（正式）

すべてのドメイン／サブ機能の切り替えは IndustriesSettings 設定ファイルにあります（Core の ORG_PREFERENCES 許可リストではありません）。また、元に戻せません（false → true のみ — 切り替え前に警告し、元に戻せると決して約束しないでください）。書き込み手順は常に READ（DurableId による tooling GET）→ WRITE（書き込み可能な dispatch ツール経由で PUT /services/data/v68.0/headless/metadata）→ 冷間検証（GET を再実行 — success:true だけでは証明になりません） です。書き込みを行う前に references/toggle-write-path.md を読み、エンドポイント一覧、正確な xmlRep の形式、DurableId 定数、確認済みの失敗クラス（サイレントな no-op、冷間検証時の 500 エラー、ライセンスによる制限）を確認してください。

---

作成時の規約

1. 機能を先に説明します。 機能名と、その機能が顧客に何をもたらすかを平易な言葉で説明します（例：「時間の競合を防止 — 学習者がスケジュールの重複するコース提供に登録するのを防ぎます」）。切り替えの API 要素名（enableCosConflicts）から説明を始めてはいけません。要素名は技術／API 呼び出しのサブセクションにのみ記載します。
2. 切り替え前に説明します。 すべての機能とサブ機能について、有効にする内容を顧客が確認前に理解できるよう、「機能の説明」を一行で記載します。
3. サブ機能を列挙して確認します。 ドメインにサブ機能がある場合は、すべて列挙し、続行する前に顧客に有効化する機能と除外する機能を確認します。
4. すべての C/U/D を事前に通知します。 作成、更新、削除を行う前に操作内容を伝え、承認／拒否／変更のいずれかを選べるようにします。
5. 手動の手順を明示します。 API では実行できない手順がある場合は手動作業として記載し、ドメイン設定の最後に提示します。
6. 必ず冷間検証を行います。 書き込み時の success:true は証明になりません。状態（レコードまたは設定オブジェクトの GET）を再読み込みし、意図したフィールド／要素の値を確認します。

---

実行時のトランスポート

最初の呼び出しの前に、headless-360 の dispatch 経由で GET /services/data/vXX.X/limits を実行し、トランスポートの健全性を確認します。2xx の場合は、すべての呼び出しをこれ経由で行います。利用できない場合、または 4xx／5xx の場合は、利用可能な他のトランスポート（別の Salesforce MCP、認証済みの sf CLI、カスタム MCP）でも同じ読み取りを試し、最初に正常応答したものを使用して、その旨を通知します。どれも正常でない場合は処理を停止し、ユーザーに接続を依頼します。決して捏造してはいけません。

headless-360 経由で SOQL を実行する場合は、クエリを url 内の ?q= にインラインで指定せず、queryParams を通じて渡してください（インライン指定では ROUTE_NOT_FOUND により 404 になります）。呼び出し形式の詳細：references/gotchas-extended.md（「Transport call shapes」）。

セットアップウィジェット

5 つの HXL ウィジェット（display_widget：Intent、Review、Plan、Apply、Verify）でワークフローを可視化します。各チェックポイントで自動的にレンダリングし、表示するかどうかを尋ねないでください。これらは視覚的な補助であり、ゲートではありません。ホストや組織で描画できない場合は、テキストで続行してください。すべてのプロパティは、実際の読み取り結果から計算します。行のアクションボタン（たとえば Enable）をクリックすることは、その項目に対するユーザーの承認です。別途確認を求めるやり取りは不要です。チェックポイント、プロパティのコントラクト、レンダリング呼び出し、フォールバックについては、references/setup-widgets.md を参照してください。

---

ワークフロー

フェーズ 0 — 基盤の前提条件（組織レベル）

すべての Education Cloud ドメインで、これらの基盤設定が必要です。ドメイン設定に進む前に確認してください。

視覚的なレビュー。 フェーズ 0、1、1.5 の読み取り後、HxlSetupReview を使って 8 つの前提条件を一度レンダリングします（「セットアップウィジェット」を参照）。その後、保留中の項目を会話形式で確認します。有効化するたびに再レンダリングしてください。

1. 組織のエディションを確認する — queryParams: {"q": "SELECT OrganizationType FROM Organization"} を指定して GET /services/data/v68.0/query をクエリします（単一レコードのため、Id は不要です）。次に、そのレコードを scripts/check_org_edition.py --allowed "Enterprise Edition,Performance Edition,Unlimited Edition,Developer Edition" に渡します（標準入力：{"records": [...]}）。eligible: false の場合は、Education Cloud の利用には Enterprise 以上のエディションが必要であることをユーザーに警告します。

2. Lightning Experience を確認する — Lightning Experience が有効になっていることを確認します。有効でない場合は、Setup → User Interface → Enable Lightning Experience に移動するようユーザーに案内します。

3. Education Cloud ライセンスを確認する — 権限セット名は組織やリリースによって異なります（確認済みの 2 つの組織では、どちらも EducationCloudUser は提供されていませんでした。代わりに %EducationCloud% に一致するものを探してください）。queryParams: {"q": "SELECT Id, Name FROM PermissionSet WHERE Name LIKE '%EducationCloud%'"} を指定して GET /services/data/v68.0/query をクエリし、さらに GET /services/data/v68.0/sobjects/BusinessProfile/describe を実行します（createable を取得します。404 の場合は null）。その後、両方を scripts/check_license_provisioned.py に渡します（標準入力：{"permissionSets": [...], "businessProfileDescribe": {...}}）。provisioned: false の場合はプロビジョニングされていないため、ユーザーに伝えて停止します。provisioned: true で matchingPermissionSets が空の場合は、プロビジョニング済みとして扱いますが、不一致についても伝えます。

4. Education Cloud Full Access を割り当てる — 実行中のユーザーの Id を特定します（不明な場合はユーザー名を尋ねます）。queryParams: {"q": "SELECT Id, PermissionSet.Name FROM PermissionSetAssignment WHERE AssigneeId='<running user Id>' AND PermissionSet.Name LIKE '%EducationCloud%'"} を指定して GET /services/data/v68.0/query をクエリし、結果を scripts/check_permission_assigned.py に渡します（標準入力：{"records": [...]}）。assigned: false の場合は、Setup → Permission Sets → Manage Assignments から、組織で実際に使用されている権限セット（ステップ 3 の matchingPermissionSets）を割り当てるようユーザーに案内します。

   この環境で Bash ツールを利用できない場合は？ これらのスクリプトはローカルのデータ変換のみを行い、組織への呼び出しも認証情報も必要ありません。確認を省略せず、同等の比較をインラインで実行してください。

5. Education Cloud Foundation を有効にする — 元に戻せません。有効化する前にユーザーに警告し、元に戻せるとは約束しないでください。 これはメタデータ PUT の経路では実行されません（enableEducationCloud では何も変更されないことを確認済みです）。専用の呼び出しエンドポイントが必要です。references/toggle-write-path.md の「Enabling the foundation」を読み、READ → WRITE → cold-VERIFY の順序と UI のフォールバックを確認してください。cold-verify で true と確認できたら、ステップ 6 に進みます。

フェーズ 1 — 個人アカウントを有効にする

6. ドメインの選択を確認する — まだ指定されていない場合は、設定するドメインをユーザーに尋ねます。次の一覧を提示します。

   • 学生の成功支援
   • 採用・入学
   • 教務運営
   • 卒業生関係
   • 学生管理
   • メンタリング

   これら6つのドメインとそのステータスを含む HxlSetupIntent を表示します。

7. 個人アカウントについて説明する — 次のように説明します。「Education Cloud には個人アカウントが必要です。個人アカウントを使用すると、個人（学生、出願者、卒業生）を、統合されたレコード内で取引先と取引先責任者の両方として追跡できます。」

   WARNING：個人アカウントは有効化すると無効にできません。続行する前に、この変更を元に戻せないことをユーザーが理解しているか確認してください。

8. 個人アカウントを有効にする（UI） — 個人アカウントには、サポート対象の組織設定書き込み API がありません（setup/org/preferences/{name} エンドポイントは 404 を返します）。Setup → Quick Find → 「Account Settings」→ Select Account Settings → 「Enable Person Accounts」をオン → Save をクリックするよう、ユーザーに指示します。トグルがオンになり、保存されたことをユーザーが確認するまで待ってから、フェーズ 1.5 に進みます。

   確認方法：GET /services/data/v68.0/sobjects/Account/describe を実行し、IsPersonAccount／Person* フィールドが存在することを確認します。この describe 呼び出しが唯一有効な確認方法です。IsPersonAccount または個人アカウントのフィールドに対して SOQL を実行してはいけません（references/gotchas-extended.md の「Person Accounts verification」を参照）。

フェーズ 1.5 — 基本設定：依存機能とデータスペースのマッピング

これは、ドメインごとのセクションの前にある Setup 独自の「Setup Basics」グループ（Person Accounts、Dependent Features、Data Space Mapping）に対応します。複数のドメインのサブ機能から参照される依存機能がいくつかあるため、ここで設定しておくと、ドメインの設定中に再確認する手間を省けます。

9. 依存機能を提示する — references/dependent-features.md を読み、カテゴリ（API トグル確認済み／手動 UI のみ／未テスト）ごとに分類した全リストをユーザーに提示します。API 要素名ではなく、機能名と「何をする機能か」の一行説明を先頭に記載します。ユーザーがすべての機能を有効にしない場合でも、必ずこのリストを提示し、今すぐ有効にする機能を尋ねてください。その選択を明示的に記録してから、ステップを省略せずフェーズ 2 に進みます。選択されなかった機能は後で再検討できます。

10. 選択した各依存機能を設定する — references/dependent-features.md（「Configuration shapes」）では、各機能を4つの設定形式（IndustriesSettings トグル、組織設定トグル、ドメインのサブ機能との重複、手動 UI のみ）に分類しています。選択した機能を参照し、正確な要素名、DurableIds、注意事項を確認します。参照資料に別途記載がない限り、トグルは元に戻せません。警告したうえで、READ → WRITE → cold-VERIFY の順に実行します。

11. OmniStudio を有効にする — OmniStudio は Education Cloud ライセンスに含まれています。API 呼び出しを試みるか、Setup → OmniStudio Settings → Enable へ移動するようユーザーに指示します。

12. Business Rules Engine を有効にする — Business Rules Engine は Education Cloud ライセンスに含まれています。Setup → Business Rules Engine → Enable へ移動するようユーザーに指示します。

13. データスペースのマッピング — DataSpaceFeatureMappings Setup Operation Recipe（/headless/invoke/platform/data-space-feature-mappings）を使用します。このスキルのほとんどのトグルとは異なり、これは元に戻せます（削除がサポートされています）。完全な事前確認／READ／WRITE／cold-VERIFY／取り消しの手順、有効な機能値、ステータスコードの処理については、references/dependent-features.md の「Data Space Mapping」セクションを参照してください。事前確認に失敗した場合、または invoke 呼び出しでエラーが発生した場合は、手動 UI（Setup → 「Set Up Education Cloud」→ Data Space Mapping）に切り替えてください。

フェーズ 2 — 対象ドメインを有効化する

14. ドメインの目的を説明する — references/domain-features.md のインデックスで選択されたドメインを確認し、リンク先のドメイン別ファイル（例：references/domain-features/student-success.md）を開いて、前提条件を含め、ドメインが提供する機能をユーザーに説明します。

15. ドメイン固有の前提条件を確認する — フェーズ 0 の OmniStudio／Business Rules Engine に加えて、ほとんどのドメインでは追加のライセンスまたは先行するドメインが必要です。ドメイン別の一覧は references/domain-features.md（「Domain prerequisites」）にあります。前提条件が満たされていない場合はユーザーに警告し、利用可能な機能で続行するか、先に前提条件を整えるかを尋ねます。これらのドメイン前提条件を含めて HxlSetupReview を表示します。

16. ドメインの有効化を確認する — 取り消し不可 — 設計上、一方向のみです（false → true のみ）。 ユーザーに明確に警告し、元に戻せる、またはロールバックできると約束してはいけません。次のように尋ねます：「[Domain Name] を有効にする準備はできていますか？ これにより、ドメイン固有のオブジェクト、項目、設定機能が有効になり、その後は無効にできません。」

17. ドメインのトグルを有効にする — 各ドメインは IndustriesSettings の enableXXX フィールドです。Domain & Feature Toggle Write Path に従います：READ（DurableId を使用して Tooling API の GET）→ WRITE（dispatch 書き込みツールを介し、xmlRep に単一の <enableXXX>true</enableXXX> 要素を含めて PUT /services/data/v68.0/headless/metadata）→ VERIFY（Tooling API の GET で true が表示される）。

    ドメインごとのトグルフィールド：references/domain-features.md（「Domain toggle fields」）。Recruitment & Admissions にはマスタートグルがありません。この手順を省略し、references/domain-features/recruitment-admissions.md の「Enablement & Toggles」に進みます。

    成功時（200 { success: true }、同期処理、ポーリング不要）は手順 18 に進みます。失敗時は、Setup → 「Set Up Education Cloud」→ ドメインのセクション（例：「Set Up the Student Success App」）に移動してドメインのトグルをオンにし、Save をクリックして確認を待つようユーザーに案内します。

18. ドメインが有効であることを確認する — 手順 17 のコールド検証（Is<Domain>Enabled = true）で、トグルが有効であることはすでに確認済みです。オブジェクトのプロビジョニングを確認するには、GET /services/data/v68.0/sobjects/CaseTeamTemplate/describe を実行します。200 はオブジェクトが存在すること（ドメインが有効であること）を示します。404／NOT_FOUND の場合は、非同期プロビジョニングのために 1～2 分待ってから再試行します。queryParams を使用した SOQL の SELECT count() FROM <Object> も利用できます。

フェーズ 3 — サブ機能を設定する

19. サブ機能のリファレンスを読む — 選択したドメインの references/domain-features/ 内にあるファイルを読み込み、利用可能なサブ機能と詳細な設定手順を確認します。

20. サブ機能の選択肢を提示する — ドメインで利用可能なサブ機能（ドメインの references/domain-features/ ファイルに記載）を一覧表示し、設定するものをユーザーに確認します。Student Success には必須の実行順序（Support Process → Case Record Types → Success Teams → Care Plans → Support Programs → Salesforce Scheduler → コンソール／ポータル）があります。それ以外のドメインでは、各サブ機能は互いに独立しています。選択が決まったら HxlSetupPlan を表示します。

21. 選択した各サブ機能を設定する — 機能の内容を説明し、元に戻せない場合は警告してから、ユーザーに確認します（行のウィジェットボタンをクリックした場合は確認済みとみなします）。その後、ドメインの references/domain-features/ ファイルに記載された正確な設定手順に従います（5 種類すべてに対応：Data／Tooling API によるレコード作成、Toggle Write Path による IndustriesSettings の切り替え、アプリ／コンソールの設定、Experience Cloud ポータルの設定、OmniStudio の有効化。各サブ機能についてエンドポイント、リクエストボディの形式、注意事項、検証方法を記載）。切り替えには、ドメインの切り替えと同じ IRREVERSIBLE + READ→WRITE→cold-VERIFY ルールを適用します。Phase 1.5 ですでに設定されている場合は、最初に cold-read を行います。API が失敗した場合は、リファレンスに記載された Setup UI の手順に切り替えます。HxlSetupApply を表示し、各項目の cold-verify の後に再表示します。

22. 概要 — すべてのサブ機能の設定後、どの方法（API、UI、OmniStudio）で何を有効にしたかを一覧表示します。失敗や必要な手動作業があれば報告します。次のステップを提案する場合は、このセッションで実際に確認された阻害要因や依存関係（例：まだ無効になっている前提条件、ユーザーが質問したが後回しにしたサブ機能）に限定します。関連するすべての機能やドメインを網羅した一般的な一覧にはしません。cold-verify 済みの書き込みごとに 1 行を設けた HxlSetupVerify を表示します。

---

ルール／制約

制約	理由
ドメインを有効にする前に、Foundation、Person Accounts、OmniStudio、Business Rules Engine を有効にする必要があります	ドメインはこれらの基盤オブジェクト／設定、およびポータルコンポーネントやポリシールール用の OmniStudio／BRE に依存します
各手順の前に必ずユーザーに確認し、まず機能の内容を説明します	会話型ワークフローのパターンです。ユーザーの明示的な承認や理解なしにコマンドを実行しません
UI へのフォールバック手順後はユーザーの確認を待ち、有効化のたびに cold-verify を行います	成功したと決めつけず、状態を再読み込みします（tooling GET、describe、record GET、または queryParams 経由の SELECT ...）
ドメインを有効にする前に、ドメイン固有の前提条件を確認します	追加ライセンスや、事前に設定済みである必要があるドメインを求めるものがあります
Phase 0 のチェックには、インラインの説明ロジックではなく scripts/ ヘルパーを使用します	決定論的で高速であり、組織への呼び出しや認証情報が不要です。Bash ツールが利用できない場合に限り、同等の比較をインラインで実行します

---

注意事項

問題	解決方法
Education Cloud ライセンスがプロビジョニングされていない	先にライセンスをプロビジョニングするよう、Salesforce のアカウントチームに連絡してください
Person Accounts、Education Cloud Foundation、およびドメインの切り替えは、一度 ON にすると無効にできません	有効化を試みる前に、これは元に戻せない操作であることをユーザーに警告してください
setup/org/preferences/{name} が EDU の切り替えに対して 404 を返す	ORG_PREFERENCES の許可リストに含まれていません。代わりに PUT /services/data/v68.0/headless/metadata で書き込んでください
Tooling sObject の PATCH で IndustriesSettings を更新すると 400 JSON_PARSER_ERROR が返る	complexvalue フィールドでは PATCH が拒否されます。headless metadata の PUT パスを使用してください。tooling GET は読み取りと検証専用です
Tooling GET では 000000000000000AAA ではなく、実際の DurableId が必要	まず SELECT Id,DurableId FROM IndustriesSettings をクエリしてください
ドメイン／サブ機能の有効化が反映されるまで、1～2 分かかる場合があります	API 呼び出しの直後に検証で何も返されない場合は、2～3 分待ってから再試行してください

AURA-IS-CANONICAL のサイレントな no-op、cold-verify の 500、およびライセンス制限による失敗の種類については references/toggle-write-path.md を、発生頻度の低い注意事項については references/gotchas-extended.md を参照してください。

---

最終確認チェックリスト（取り消せない書き込み）

以下の各項目を完了として報告する前に、その書き込みについて両方のチェックが済んでいることを確認してください。

• Education Cloud Foundation — 無効にできないことをユーザーに警告し、有効化後に cold-verify（新たに読み取った educationCloudEnabled: true）に合格している。
• Person Accounts — 有効化後は無効にできないことをユーザーに警告し、Account の describe で IsPersonAccount／Person* フィールドが存在することを確認している。
• 今回のセッションで有効化した各ドメインの切り替え — 書き込み前にユーザーが「有効化後は無効にできない」ことを確認し、tooling GET の cold-verify で Is<Domain>Enabled: true が表示されている。（ステップ 18 のオブジェクト describe で確認できるのはオブジェクトのプロビジョニングのみです。cold-verify の代わりにはなりません。）
• 今回のセッションで有効化した、取り消せない各サブ機能／依存機能の切り替え — 書き込み前にユーザーが確認し、cold-verify でフィールドが true と表示されている。

承認と cold-verify の両方のチェックが済んでいない機能を、最終サマリーで「有効」として記載しないでください。

---

出力に関する想定

このスキルはファイルを生成しません。設定は Setup のナビゲーション、CLI コマンド、または API 呼び出しで行われます。想定される出力は、各ステップ後の会話形式での確認、ホストと組織が対応している場合にライブ状態を反映する HXL Setup ウィジェット（display_widget による Intent、Review、Plan、Apply、Verify）、設定が有効であることを示す検証結果、失敗時の修正方法を提示するエラーメッセージ、および設定したすべての機能を列挙する最終サマリーです。

---

スキル間の連携

必要な作業	委任先
Education Cloud 用のカスタムオブジェクトの作成	platform-custom-object-generate
Education Cloud オブジェクト上のカスタムフィールドの作成	platform-custom-field-generate
入力規則の生成	platform-validation-rule-generate
権限セットの設定	platform-permission-set-generate
メタデータパッケージのデプロイ	platform-metadata-deploy

---

リファレンスファイル一覧

ファイル	参照するタイミング
references/domain-features.md	ドメインごとのリファレンスファイルの一覧です。選択したドメインに適したファイルを見つけるには、ここから始めてください
references/domain-features/<domain>.md	フェーズ 2 のステップ 14（ドメインの目的を説明）、フェーズ 3 のステップ 19（サブ機能を特定）、フェーズ 3 のステップ 21（サブ機能の設定手順と API 設定の優先項目名）
references/dependent-features.md	フェーズ 1.5 のステップ 11～12（セットアップの基本 — いずれかのドメインを扱う前に、依存機能を提示して設定する）、また、特定のドメインだけに属さない複数製品にまたがる機能についてユーザーから質問された場合は、常に参照してください。その場合は「依存機能のセットアップ」として提示し、関連する場合はドメイン間の重複にも触れてください
references/setup-widgets.md	ステップ 6、15、20、21、22、およびフェーズ 0 のレビュー（5 つの HXL セットアップウィジェットのプロパティ契約と Education Cloud のマッピング）
references/gotchas-extended.md	エラーが上記の「よくある問題」表にある 10 項目のいずれにも当てはまらない場合
scripts/check_org_edition.py	フェーズ 0 のステップ 1（組織エディションの確認）
scripts/check_license_provisioned.py	フェーズ 0 のステップ 3（Education Cloud ライセンスの確認）
scripts/check_permission_assigned.py	フェーズ 0 のステップ 4（Education Cloud のフルアクセス割り当ての確認）