audit-tenant-settings

テナント設定の監査

監査済みのベースラインに照らして Fabric／Power BI のテナント設定を監査し、差分を明らかにし、容量／ドメイン／ワークスペースのスコープにおける委任されたオーバーライドを列挙し、それらの設定が参照する Entra セキュリティグループを調査して、調査結果に基づいた次の対応についての話し合いにつなげます。必ずこのスキルと併せて fabric-cli スキルを呼び出してください。このスキルが依存する fab CLI のガイダンスと管理 API のリファレンスを提供します。

前提条件

このプラグインは fabric-cli プラグインのアドオンです。次が必要です。

• fabric-cli プラグインがインストールされ、有効になっていること。fab CLI のガイダンスと管理 API のリファレンスドキュメントを提供します。
• Fabric／Power BI の管理者アカウントで認証された fab CLI（ms-fabric-cli）。
• セキュリティグループの調査時は、Graph の権限（Group.Read.All、User.Read.All、Directory.Read.All、RoleManagement.Read.Directory）で認証された az CLI。

設定

.claude/fabric-admin.local.md によるプロジェクトごとの設定：

---
enabled: true
tenant_label: "Contoso"
snapshot_path: "~/.cache/fabric-admin-audit/last-snapshot.json"
drift_threshold_high: 5
drift_threshold_medium: 15
notification_level: "info"
schedule: "weekly"
---

# Fabric Admin Configuration

Additional context or tenant-specific notes.

フィールド	型	デフォルト	用途
enabled	bool	true	プラグインの有効／無効を切り替えます
tenant_label	string	なし	PDF のマストヘッドと監査レポートに表示するラベル
snapshot_path	string	~/.cache/fabric-admin-audit/last-snapshot.json	前回実行時のスナップショット JSON の保存先／読み込み元
drift_threshold_high	int	5	高リスクの差分数がこの値を超えたときに警告します
drift_threshold_medium	int	15	差分の合計数がこの値を超えたときに警告します
notification_level	string	info	詳細度：quiet、info、verbose
schedule	string	weekly	希望する監査頻度：daily、weekly、monthly、ad-hoc

このスキルを使う場面

生の API 呼び出しではなく、解釈を踏まえた回答が必要な、テナント、委任、または SG のスコープに関するガバナンス上の質問に対して呼び出します。よくある依頼：

• 「テナントのガバナンス監査を実行してください」
• 「先月から何か変化しましたか？」
• 「PublishToWeb は何をするもので、有効にすべきですか？」
• 「PowerBI_ServicePrincipals グループにスコープが設定されている設定はどれですか？また、メンバーは誰ですか？」
• 「容量／ドメイン／ワークスペースのすべてのオーバーライドを表示してください」
• 「この設定は、自分のシナリオで有効にしても安全ですか？」

重要なルール

• 決して推測しないでください。 テナント設定の動作、SG のメンバーシップ、オーバーライドの影響は、厳選されたメタデータ、ライブ API、または Microsoft Learn に基づいて判断してください。情報源に記載がない場合や、情報源同士が矛盾する場合は、そのことを明確に伝えてください。
• 要件を確認してください。 AskUserQuestion スキルを使って、テナント、ユーザーの行動、導入状況について定期的にユーザーに質問してください。fabric-cli スキルと fab を使って、テナント内の項目やその構成を把握し、アクティビティログやイベントからユーザーの導入状況やアクティビティを確認してください。重要な傾向、異常、高リスクの操作やシナリオ（Web への公開、エクスポート、外部ユーザー、組織全体、または C レベル従業員との共有など）を指摘してください。
• ポータルのタイトル、説明、推奨事項、リスクレベル、SG メンバーシップ、ACL の形式を捏造しないでください。 メタデータや API に情報がない場合は、取得してください。
• 絶対的なコンプライアンス適合の主張（HIPAA、SOC 2、GDPR など）はしないでください。 結論は、厳選されたベースラインとの観測された乖離、および API から得た生データに限定してください。
• 推奨事項は一般的なものであり、処方的でも普遍的でもありません。 厳選された recommended フィールドは、主観的なコミュニティの既定値を反映しており、ユーザーのシナリオに合わせたものではありません。常にそのニュアンスを説明し、判断はユーザーに委ねてください。
• 現実的かつ批判的に考え、危機をあおる表現は避けてください。 ユーザーのシナリオが実現可能かを検討し、意思決定や計画にユーザーが参加できるようにして、現在のテナント設定構成がもたらす実際の影響を理解できるようにしてください。
  • ガバナンスにはどのような影響がありますか。ユーザーは何を実行、アクセス、作成できますか。
  • 作成、共有、配布などの主要なプロセスにどのような影響がありますか。
  • Fabric の容量使用量やリソースの制約にどのような影響がありますか。
  • 効果的な分析を妨げるような摩擦が生じますか。
  • 有効化または無効化によって、ユーザーが操作できなくなったり、新たな依存関係が生じたりしますか。

信頼できる情報源（優先順位順）

1. 厳選されたメタデータ：references/tenant-settings-metadata.yaml。既知の設定ごとに human_name、description、preview、source_url、recommended、risk、recommendation_nuance が含まれています。テナント設定に関する質問には、まずこれを確認してください。
2. ライブ API（fab api と az を使用）：
   • テナント全体の状態：fab api "admin/tenantsettings"
   • 委任されたオーバーライド：fab api "admin/capacities/delegatedTenantSettingOverrides"、admin/domains/...、admin/workspaces/...
   • Entra グループとロールの割り当て：az ad group、az rest --method get --uri https://graph.microsoft.com/v1.0/...
3. https://learn.microsoft.com/en-us/fabric/admin/tenant-settings-index の Microsoft Learn、または pbi-search CLI。メタデータが古い場合、設定が新しい場合、またはユーザーがベースラインでは回答できない機能について質問した場合に使用してください。

ワークフロー

以下の手順を順番に実行してください。明確な理由がある場合に限り手順を省略できます。黙って省略してはいけません。

1. 前提条件を確認する

• fab --version が最新であることを確認してください。古い場合は uv tool upgrade ms-fabric-cli を実行してください。
• fab auth status で有効なセッションを確認してください。有効でない場合は、ユーザーに fab auth login の実行を依頼してください。
• 管理者アクセスを確認してください：fab api "admin/capacities" 2>&1 | head -5。401 または 403 が返された場合、そのアカウントは Fabric / Power BI 管理者ではありません。処理を中断し、ユーザーに今後の進め方（管理者に実行を依頼する、または管理者権限不要のスクリプトに切り替える）を確認してください。
• SG の調査が必要な場合は、az account show で、少なくとも Group.Read.All、User.Read.All、Directory.Read.All、RoleManagement.Read.Directory を持つセッションが解決されることを確認してください。自動で認証せず、az login を実行するよう依頼してください。

2. 監査スクリプトを実行する

uv run ${CLAUDE_PLUGIN_ROOT}/skills/audit-tenant-settings/scripts/audit-tenant-settings.py -o /tmp/tenant-audit.md

よく使われるオプション：

• --drift-only を指定すると、レポートは非準拠の設定のみになります。
• --snapshot /path/to/snap.json を指定すると、複数のテナントを監査する場合にテナントごとの分離が維持されます。
• --no-snapshot を指定すると、変更検出をスキップします（初回実行時や、状態をリセットしたい場合）。

スクリプトは、ライブ状態とキュレーション済みメタデータを統合し、ドリフト、プレビュー機能、SG のスコープ、前回のスナップショット以降の変更を一度に計算します。管理者向けの書き込みエンドポイントには、1 分あたり 25 件のレート制限があります。429 が返された場合は Retry-After に従ってください。

共有しやすい 1～2 ページの概要資料を作成するには、同じスナップショットを使って PDF ジェネレーターを実行します。

uv run ${CLAUDE_PLUGIN_ROOT}/skills/audit-tenant-settings/scripts/generate_audit_pdf.py -o /tmp/tenant-audit.pdf

PDF では、主要な件数、前回のスナップショット以降の変更、ドリフトテーブル、委任されたオーバーライドの概要に焦点を当てます。Markdown スクリプトと同じ監査ロジックをインポートして再利用し、同じスナップショットパスを読み取るため、変更検出の内容は一致します。管理者として実行しない場合は --no-overrides を指定してオーバーライドの列挙をスキップするか、--tenant-label "Contoso" を指定してヘッダーにテナント名を追加します。PDF は関係者向け、Markdown の監査結果は作業時の確認用です。両方を併用してください。

3. スクリプトの出力を確認する

生成された Markdown を最初から最後まで一度読み、次の順序で所見を提示します。

1. Summary セクションの主要な件数（合計、準拠、ドリフト、プレビュー、SG スコープ）。
2. 前回の監査以降の変更（追加、削除、切り替え、sg_changed、property_changed）。スナップショットがなければ「初回実行」と伝えます。
3. リスクの高いドリフト：ドリフトテーブルで risk: high とタグ付けされた設定。
4. SG スコープに関する懸念：ベースラインがスコープ設定（on:sg / off:sg）を推奨しているにもかかわらず、現在は組織全体に適用されている設定、およびヒューリスティックによってフラグが付けられた個別の UPN。
5. 現在有効なプレビュー機能（管理者は、自分が同意したことに気づいていない場合がよくあります）。

要約は簡潔に（400 語未満）まとめます。ユーザー向けの文章では API 名ではなくポータルのタイトルを使い、正確さが重要な場合に限り (settingName) を補足します。

4. 委任されたオーバーライドを列挙する

テナント全体の状態は全体像の半分にすぎません。親の delegateToCapacity / delegateToDomain / delegateToWorkspace が true に設定されている設定は、そのスコープでローカルオーバーライドに置き換えられる可能性があります。この手順を省略することは、ガバナンスレポートで問題が起きる最も一般的な原因です。

3 つのスコープすべてから取得し、各オーバーライドに drift-vs-tenant、drift-vs-recommended、high-risk（親に risk: high がある場合）、または orphan（親が委任していないため、オーバーライドが残存している場合）のタグを付けます。準拠している場合も含め、オーバーライドを暗黙のうちに省略してはいけません。特定のワークスペース、キャパシティ、またはドメインについてユーザーから質問された場合は、テナントのデフォルトより先にオーバーライドを表示し、実効状態がわかるようにします。

すべてを列挙する方法、フィルタリング、変更の仕組みについては、references/delegated-overrides.md を参照してください。

5. セキュリティグループの設定と戦略を調査する

セキュリティグループに適用される設定の強度は、そのグループのメンバー構成、所有者、ガバナンスに左右されます。空、または長期間更新されていない SG を指定するスコープ設定は、実質的にスコープが設定されていないのと同じです。逆に、範囲が広くメンバーが動的に追加される SG に制限した設定は、RLS が適切に設定されたテナントで組織全体に適用するよりも制限が緩くなる場合があります。

稼働中のテナント設定で参照されているすべての graphId を列挙し、それぞれを az ad group で解決します。メンバーを @odata.type で分類し、Fabric／Power BI／グローバル管理者のロール割り当てと照合して、調査結果を対応するテナント設定の行に反映します。確認が必要なカテゴリ（空のグループ、ゲストメンバー、古い所有者、動的メンバーシップ、ネストされた SP）と正確な Graph クエリは、references/security-groups.md を参照してください。

SG 戦略自体に問題があるように見える場合（たとえば、無関係なセキュリティ体制に同じ SG を使い回している、ロール用のグループに個々のユーザーを直接追加している、退職した従業員が所有者になっているなど）は、過度に危機感をあおることなく、率直に指摘します。目的はユーザーを怖がらせることではなく、モデルを見直す手助けをすることです。

6. 設定の乖離を詳しく調べる

乖離が重要な設定について意見を述べる前に、信頼できる情報源に基づいて説明します。

1. キーワードで厳選されたメタデータを検索します。

   grep -i -A6 '<keyword>' ${CLAUDE_PLUGIN_ROOT}/skills/audit-tenant-settings/references/tenant-settings-metadata.yaml
   

2. 実際の状態を確認します。

   fab api "admin/tenantsettings" -q "text.tenantSettings[?settingName=='<API name>']"
   

3. メタデータが古い場合や、シナリオに必要な詳細が不足している場合は、正規のドキュメントを取得します。メタデータの source_url、またはポータルのタイトルや API 名を指定した pbi-search の検索結果を使用します。
4. 次の形式で回答します。ポータルのタイトルと API 名、1 文での説明、プレビューの状態、現在の状態、推奨される設定、リスクレベル、推奨に関する補足、ドキュメントへのリンク。

メタデータとドキュメントの内容が一致しない場合は、ドキュメントを優先し、ベースラインを更新できるよう、食い違いをユーザーに伝えます。

7. 調査結果を示し、根拠に基づいた議論を始める

結果は客観的に提示します。過度に危機感をあおる表現は避けます。ベースラインから乖離している設定が、必ずしも誤りとは限りません。ベースラインは一般的な基準であり、ユーザーのシナリオには合わない場合があります。同様に、ベースラインに合致している設定でも、ユーザーの組織にとっては不適切な場合があります。

乖離がある領域については、それぞれ次の 2 つの観点から話し合います。

• 推奨設定との乖離：厳選されたベースラインに準拠していない現在の設定です。変更によって何が変わるのか、どの機能が使えなくなるのか、何が可能になるのかを説明します。
• 推奨設定だがユーザーには不適切：ベースラインに合致していても、ユーザーのシナリオに応じて変更が必要になる場合がある設定です（たとえば、選択的に PublishToWeb を有効にする必要があるセルフサービス型の組織や、一般的な推奨よりも ServicePrincipalsUseReadAdminAPIs を厳しくする必要がある規制対象のテナントなど）。

推奨に影響する場合は、ユーザーのシナリオについて、要点を絞った短い質問をします。たとえば、ライセンスモデル（Pro、PPU、Premium、Fabric）、コンテンツのライフサイクル（セルフサービス型かエンタープライズ型か）、規制への対応状況、既存の SG 戦略、進行中の導入目標などです。推奨に影響しないことはユーザーに尋ねません。

8. ユーザーと次のステップを策定する

一方的に計画を提示するのではなく、ユーザーと共同で策定します。候補は次のとおりです。

• ドキュメント：何かを変更する前に、現状、SG メンバーシップ、オーバーライドの一覧をランブックに記録します。
• セキュリティグループの修正：SG を作成または統合し、ユーザー／SP を割り当て、空または古くなったグループを廃止し、退職した従業員から所有権を移します。
• テナント設定の制御された変更：まず SG スコープを使って一部のユーザーで試験運用し、その後対象を広げます。必ずポータルまたは明示的な fab api -X post コマンドを使用します。このスキルから自動適用することはありません。
• 容量／ドメイン／ワークスペースのオーバーライド監査：ユーザーとオーバーライドの一覧を確認し、意図したものと削除すべきものを判断します。
• Power BI 実装計画シリーズの導入計画、実装計画、セキュリティおよびコンプライアンス計画に関する確認事項。内容を再掲せず、該当する記事を案内します。
• 定期スナップショットとアラート：その場限りのレビューではなく継続的な監視を希望するユーザーには、監査スクリプトを定期的に実行する設定（たとえば cron、スケジュール設定した GitHub Action、スケジュール実行する Fabric ノートブック、Azure DevOps パイプラインなど）を提案します。これによりスナップショットを更新し、差分を見やすい場所へ送信します。その後、変更検出の出力をアラート通知先に連携できます。Fabric Activator も選択肢の一つですが、Power Automate 経由の Teams またはメール、webhook 経由のページャー、シンプルな受信トレイルールなども利用できます。これを使えば、監査を手動で再実行しなくても、Microsoft による新しい設定の追加、設定状況の変化、SG メンバーシップの変更を検出できます。範囲と連携方法はユーザーが決定します。このスキルはフローの設計を支援できますが、明示的な承認なしに何かを構築してはなりません。

すべての計画の最後に、免責事項を記載してください。"These recommendations are based on the curated baseline and the live API state at the time of this audit. The agent may not present fully accurate or scenario-appropriate information; the user is responsible for due diligence, piloting changes, and confirming with their own security, compliance, and Fabric administration teams before applying anything in production."

出力基準

• ユーザー向けテキストでは、ポータルのタイトル（メタデータの human_name）を使用します。精度が重要な場合や API 名の方が認識されやすい場合に限り、(settingName) を付記します。
• 件数を含む要約は、ASCII テーブルまたは整列した箇条書きで示します。絵文字や装飾的な書式は使用しません。
• メタデータやドキュメントの説明と推奨事項は、意味を変えるような言い換えをせず、原文どおり引用します。
• 監査の全体要約は 400 語未満、単一設定に関する質問への回答は 200 語未満にします。recommended フィールドが review の設定について、ユーザーから「設定すべきか」という二択の質問があった場合は、ベースラインとして明確な推奨がないことを明示し、考慮すべき点を示します。
• ユーザーから明示的に求められない限り、SG メンバーの完全な一覧やワークスペースユーザーの完全な一覧を開示しません。件数、ロール別内訳、注意すべき名前付きの項目で要約します。

例外ケース

• ライブ API に未知の設定がある場合：Microsoft が前回のメタデータ更新後に追加した設定です。背景情報を得るため Learn の該当項目を取得し、tenant-settings-metadata.yaml の拡張を提案します。
• メタデータにある設定がライブ API に存在しない場合：設定名が変更されたか、廃止されています。推奨事項を示してはなりません。
• 設定の表現が曖昧な場合：クエリに一致する設定が複数ある場合は候補を列挙し、どれを指しているかユーザーに確認します。
• fab auth セッションがない場合：先に fab auth login を実行するようユーザーに依頼します。自動認証してはなりません。
• SG に関する質問が出た際に az login していない場合：az login を実行するようユーザーに依頼します。初回のスモークテストには、スクリプトのヒューリスティック UPN フラグを代替として使えることを案内します。
• レート制限（429）：Retry-After に従って待機します。再開時は最初からやり直さず、失敗した設定から再開します。
• 非常に大きなテナントの場合：管理者向けワークスペース API とアイテム API はページングされます。continuationUri／continuationToken を使用してストリーム処理し、すべてを単一の応答に読み込もうとしてはなりません。

リソース

同梱ファイル

• references/tenant-settings-metadata.yaml ; 既知の Fabric / Power BI テナント設定すべての精選されたベースライン（ポータルのタイトル、説明、プレビュー、推奨事項、リスク、補足情報、ドキュメントへのリンク）。
• references/delegated-overrides.md ; 委任されたオーバーライドを列挙、分類し、（容量についてのみ）変更します。
• references/security-groups.md ; graphIds を解決し、メンバーを分類し、危険な兆候を検出して、管理者ロールの割り当てと照合します。
• scripts/audit-tenant-settings.py ; 監査と変更検出のスクリプトです。メタデータ YAML は、同階層の references/ パスから読み込みます。
• scripts/generate_audit_pdf.py ; 同じ監査の概要を、読みやすい 1～2 ページの PDF として生成します。同階層のスクリプトをインポートして監査ロジックを再利用し、必要に応じて委任されたオーバーライドを列挙して、主要な件数、前回の監査以降の変更、差分テーブル、委任されたオーバーライドのセクションを含む、簡潔で編集記事風の概要を生成します。Markdown 形式の監査の後（または代わり）に uv run scripts/generate_audit_pdf.py -o /tmp/tenant-audit.pdf を実行します。PDF は関係者と共有し、Markdown は作業時の確認用に保管してください。

メインの fabric-cli スキルの関連資料

• plugins/fabric-cli/skills/fabric-cli/references/admin.md ; 設定の更新、ページング、アクティビティイベントに関する管理 API の基本的な仕組みです。
• plugins/fabric-cli/skills/fabric-cli/references/permissions.md ; ガバナンス監査のドメイン横断部分におけるワークスペースとアイテムの ACL ワークフローです。
• plugins/fabric-cli/skills/fabric-cli/SKILL.md ; fab CLI のエントリーポイントとコマンドリファレンスです。

外部資料

• Microsoft Learn のテナント設定インデックス ; スクリプトが取得できるすべての設定の権威ある最新情報です。
• Power BI の導入計画：セキュリティとコンプライアンスの計画 ; ステップ 8 で検出事項と併せて参照してください。