onelake-catalog-govern-cli

テレメトリ — 必須です。 すべての api.fabric.microsoft.com 呼び出しには x-ms-fabric-skill: onelake-catalog-govern-cli を付ける必要があります（az rest の場合は --headers "x-ms-fabric-skill=onelake-catalog-govern-cli"）。 すべての LRO ポーリング、fabric_lro、再試行にも適用されます。スニペットには含まれていませんが、必ず追加してください。

重要な注意事項

1. ワークスペース名から ID を含むワークスペースの詳細を調べるには、すべてのワークスペースを一覧表示してから、JMESPath フィルタリングを使用してください。
2. ワークスペース ID、アイテムの種類、アイテム名から ID を含むアイテムの詳細を調べるには、そのワークスペース内の該当する種類のアイテムをすべて一覧表示してから、JMESPath フィルタリングを使用してください。

OneLake Catalog Govern — CLI（モードディスパッチャー）

OneLake Catalog の Govern ファミリー全体を対象とする 1 つのスキルです。ガバナンスに関するペルソナの詳細は、必要に応じて読み込まれる 4 つのモード別リファレンスに記載されています。このトップレベルのファイルの役割は、次の 3 つだけです。

1. モードを選択する（下の表を参照）。
2. 安全境界と、取り消し不能な書き込みに必要なゲートを明示することで、大きなリファレンス内に埋もれないようにします（取り消し不能な操作を参照）。
3. モード別リファレンスを 1 つだけ読み込み、その指示に従います。

必須／推奨／回避

必ず行うこと

• 修復を行う前に、呼び出し元の権限ティアに対応する監査セルから開始します。
• 破壊的、取り消し不能、または広範囲に及ぶ書き込みの前に、ステップ 2 の操作固有の確認ゲートを適用します。
• 選択した手順で文書化されている Fabric Admin、Core、Power BI、または Graph API のサーフェスを正確に使用します。401 または 403 を RBAC を回避する許可と見なしてはいけません。
• ガバナンス統計を提示する際は、対象範囲、除外項目、ページネーションの完全性、鮮度に関する注意事項を明示します。

推奨事項

• データ所有者の操作には、テナント管理者権限を要求する代わりに、権限が最小限の Core API または Power BI API を使用します。
• 検出事項は、インベントリのダンプを返すのではなく、根拠、影響、推奨アクション、優先度、作業量として報告します。
• 一括割り当てやラベル付けより先に、所有権とアクセス範囲の修正を行います。

回避すること

• 監査モードでテナントを変更してはいけません。
• エンドースメント、DLP ポリシー、管理者によるアイテム削除、サードパーティのアイテム ID 割り当てについて、書き込み API を捏造してはいけません。
• 非同期の 202 応答を、処理が正常に完了したものとして報告してはいけません。

ステップ 1 — モードを選択する

2 つの軸 → 2×2 のグリッド。 ティア（利用可能な API サーフェス）× アクション（監査または修復）。各セルは、Govern の 3 つの柱（健全性／保護／信頼）すべてを対象とします。

	監査（読み取り専用）	修復（書き込み）
Fabric Admin — /v1/admin/*、Fabric テナント管理者のみ	admin-audit	admin-remediate
データ所有者／運用管理者 — Core API ＋ ワークスペース／ドメイン／容量の管理者、テナント管理者ではない	dataowner-audit	dataowner-remediate

モード	読み込むリファレンス	ペルソナ／権限ティア	対象範囲	読み取り	書き込み
admin-audit	references/admin-audit.md	Fabric テナント管理者（/v1/admin/*）	テナント全体	✅	❌
admin-remediate	references/admin-remediate.md	Fabric テナント管理者のみ — すべての /v1/admin/* 書き込みには Fabric 管理者ロールが必要です。ドメイン管理者および容量管理者は対象外です	テナント全体	✅	✅
dataowner-audit	references/dataowner-audit.md	非管理者のワークスペースまたはドメイン所有者（Core API のみ）	呼び出し元が管理するワークスペース（要求に応じてアクセス可能な範囲に拡大）	✅	❌
dataowner-remediate	references/dataowner-remediate.md	ドメイン／ワークスペース／容量の管理者でもあるデータ所有者 — Core および Power BI API への書き込み、テナント管理者ではない	呼び出し元がロールを持つオブジェクト	✅	✅（セルフサービス）

ルーティングルール

• まず監査モードから開始します。 現状を確認する前に、修正を行ってはいけません。監査から修正に進む場合は、呼び出し元の権限が変わらない限り、同じティア内で行います。
• 役職名ではなく、呼び出し元がアクセスできる API サーフェスに基づいてティアを選びます。 /v1/admin/* を必要とする Fabric テナント管理者は admin-* セル、ワークスペース／ドメイン／容量ロールを通じて操作するデータ所有者は dataowner-* セルを使用します。
• **「修正／割り当て／適用／作成／削除」**は、修正モードのセルを使用します。テナント全体への書き込み（ドメインの作成／削除、一括ドメイン割り当て、ドメインロール、一括ラベル付け、認定）には admin-remediate を使用します。単一ワークスペースでの assignToDomain または assignToCapacity、タグの適用、説明の設定、更新、およびアイテムの ID には dataowner-remediate を使用します（これらに必要なのはオブジェクトスコープのロールであり、テナント管理者権限ではありません）。
• 読み取りと書き込みの分離は安全の境界です。プロンプトで要求されても、監査モードではテナントを変更してはいけません。監査モード中にユーザーから書き込みを求められた場合は、該当する修正モードに明示的に切り替えてください。独自の判断で書き込みを行ってはいけません。

ティアは役職名ではなく、API サーフェスで決まります。 admin-* モードは /v1/admin/* を呼び出し、Fabric テナント管理者ロール（Fabric 管理者／Power Platform 管理者／M365 グローバル管理者）が必要です。ドメイン、容量、ワークスペースの管理者は、たとえ自分のドメインを担当していても、該当しません。dataowner-* モードは、呼び出し元が特定のオブジェクトに対してすでに保有しているロールのスコープで、Core／Power BI API を使用します。Fabric テナント管理者ではないドメイン／WS／容量の管理者は、すべて dataowner-* セルを使用します。admin-* に移行できるのは、別途 Fabric テナント管理者ロールが付与された場合のみです。ロールはモード内のスコープ分岐です。別のモードを正当化するのは、異なる API サーフェスだけです。

⚠️ Fabric の既知の制約 — スコープを限定したガバナンスには、管理者以外が使える API がありません。 Fabric テナント管理者ではないドメイン管理者またはワークスペース管理者には、現在、自分のスコープにおけるガバナンス状況を確認する API パスがありません。/v1/admin/* は拒否され（Fabric テナント管理者ロールが必要です。Assign Domain Workspaces の権限に関する注記を参照してください）、Core API にはドメイン内のワークスペース一覧を取得したり、ドメインのガバナンス状態を返したりするエンドポイントがありません。dataowner-audit が報告できるのは、呼び出し元が直接アクセスできるワークスペースのみです。「自分のドメイン全体」ではありません。ドメイン／WS 管理者から自分のスコープ内のガバナンス詳細を求められた場合は、まずこの制約を伝え、401/403 になる admin-* モードに案内しないでください。

ステップ 2 — 取り消せない操作 — 必須ゲート（書き込み前にお読みください）

⚠️ これがモードのリファレンスだけでなく、ここにも記載されている理由。 これらは終端操作であり、元に戻すのが困難です。このような指示が大きなリファレンスファイル内の何十行もの中の1行として置かれていると、読まれても気づかないうちに無視されてしまいます。書き込み後ではなく、書き込み前にゲートが実行されるよう、自動読み込みされるディスパッチャー本文にもこの指示を繰り返し記載しています。完全な手順は remediate モードのリファレンス（admin-remediate.md、dataowner-remediate.md）に記載されています。これはチェックリストであり、代わりになるものではありません。

いずれかの remediate モードで以下の操作を実行する前に、ゲートを必ず通過してください。どのセルが操作を担当するかは、モード列に示されています。

取り消せない操作／終端操作	モード	最初に必ず実行するゲート
ドメインを削除する（DELETE /v1/admin/domains/{id}）	admin	サブドメイン（parentDomainId）およびドメインと各サブドメインに割り当てられているワークスペース数を確認します。孤立するワークスペースがある場合は、処理を停止し、影響を受けるドメイン／ワークスペースを明示してユーザーの明確な確認を得ます。REST API にはカスケード削除を阻止する機能がありません。確認は実行者の責任です。domain-crud.md § ドメインの削除を参照してください。
タグ定義を削除する	admin	先に、そのタグが付いているアイテムの数を報告します。削除すると、すべてのアイテムからタグが外れ、取り消せません。
ワークスペースをドメインに一括割り当てする	admin	各対象の現在の domainId を確認し、既存の割り当てが通知なく上書きされる前に警告します。先に対象リストをドライランします。
ドメインロールからプリンシパルを削除する	admin	ドメインの所有者がいなくならないことを確認し、削除するプリンシパルの名前を示します。
機密ラベルを一括変更する	admin	ドライランを行い、影響を受けるアイテムの正確なリストと変更前／変更後のラベルを示して、確認を得ます。サービスプリンシパル／マネージド ID は使用できません。呼び出しは失敗します。
テナント設定を書き込む（例：認定を有効にする）	admin	現在の値を読み取って表示した後、提案する値を示します。影響はテナント全体に及びます。
ワークスペースをドメインに割り当てる／割り当て解除する	dataowner	移動は再割り当てです。現在の domainId を確認し、移動元のドメイン名を示します。ドメイン共同作成者およびワークスペース管理者の権限が必要です。失敗した場合は、どちらの権限が不足しているか伝えます。
アイテムの所有権を再割り当てする（アイテム ID、プレビュー）	dataowner	呼び出し元にのみ割り当てられます。アイテムとその子アイテムに対する書き込み権限が必要です。意図した ID を確認します。
ワークスペースを容量に割り当てる	dataowner	ワークスペース管理者と容量共同作成者／管理者の権限が必要です。非同期の 202 が返されます。202 だけを根拠に成功を報告してはいけません。終端状態になるまでポーリングします。

書き込み API がない修復を約束しないでください。 推奨設定、DLP ポリシー、テナント管理者によるアイテムの削除には、書き込み用のエンドポイントがありません。その場合は、対応できる担当者の連絡先一覧を作成してください。references/admin-remediate/no-write-api-escalation.md § 問題を修正できる担当者に調査結果を回すを参照してください。

ステップ 3 — リファレンスを読み込み、作業を進める

ステップ 1 に一致するモードのリファレンスだけを読み込み、最初から最後までその指示に従ってください。共通の背景情報と各リーフ手順はここに索引化されており、どのファイルもこのディスパッチャーから1ホップで参照できます。リファレンスはリーフです。1つを読み込んだ後、別の手順が必要になった場合は、この索引に戻ってください。

ガバナンス共通リファレンス

• ガバナンスの柱 — 3つの柱、「良い」状態の定義、レポートの規約
• ガバナンスのデータソース — 検証済みの API フィールドの網羅状況、製品の死角、レポートの規約
• ガバナンスの役割 — 権限レベル、ドメイン／ワークスペースの役割、インサイトの更新遅延
• カタログの概念 — エンティティモデルと、API に裏付けられた用語および概念上の用語
• ../../common/COMMON-CORE.md — リポジトリレベルの Fabric REST パターン、認証、ページネーション
• ../../common/COMMON-CLI.md — リポジトリレベルの CLI 実装（az rest、ページネーション、認証レシピ）

モードディスパッチャー

• 管理者監査 — テナント全体を対象とする読み取り専用のガバナンス評価
• 管理者監査の対象範囲 — ガバナンス対象の母数、除外項目、既知の死角
• 管理者監査の評価 — エンドツーエンドの評価ワークフロー、優先順位付け、成果物の要件
• 管理者による修復 — Admin API を通じた、テナント全体を対象とするガード付き書き込み
• データ所有者監査 — Core API を通じた、呼び出し元のスコープ内での読み取り専用チェック
• データ所有者による修復 — Core API と Power BI API を通じた最小権限の書き込み

管理者監査の手順

• ドメインの健全性 — 割り当て、所有権、共同作業者の範囲、メタデータ
• ワークスペースの健全性 — 空または非アクティブなワークスペース、管理者の単一障害点
• 容量の健全性 — 容量の状態、所有権、ドメインとの整合性
• アイテムのインベントリ — Admin とスキャナーのインベントリ、およびフィールドの網羅状況
• アイテムの健全性 — 所有権、陳腐化、更新の状態
• 保護の適用状況 — 秘密度ラベルと DLP の可視性
• 信頼性を高めるキュレーション — 説明、推奨、タグの適用状況

管理者による修復の手順

• ドメインのライフサイクル — ドメインの作成、更新、安全な削除
• ワークスペースの割り当て — 一括割り当て方法の選択とドライラン
• ドメインのロール — 管理者と共同作業者の割り当て
• タグ — テナントのタグ定義の管理
• アイテムの秘密度ラベル — ガード付きの一括ラベル変更
• ドメインの既定ラベル — 新たな未ラベル項目の滞留を防止
• 信頼性の修復 — 認定の有効化と委任されたアクション
• 書き込み API がない場合のエスカレーション — 不足している API と、対応可能な担当者の特定

データ所有者の手順

• データ所有者によるワークスペースの健全性チェック — 呼び出し元のスコープ内における空または非アクティブなワークスペースのチェック

例

Audit our tenant's OneLake catalog governance posture and prioritize the findings.

Which workspaces I administer are not assigned to a domain?

Show a dry run for assigning these workspaces to the Finance domain, including current assignments.

Find unlabeled items tenant-wide and explain which remediations require a tenant admin versus a data owner.