review-report

Power BI レポートのレビュー

開発者やコンサルタントに実行可能なフィードバックを提供するため、Power BI レポートを体系的に評価します。レポートレビューでは、レポートが効果的で、適切に構築され、実際に利用されているかを評価します。成果物は、具体的な推奨事項を添えた、優先順位付きの指摘事項一覧です。

このスキルは、次の3つのシナリオのいずれかで機能します。

1. 開発中のレポート：このシナリオでは、正確に収集された要件に基づき、レポートのコンテンツ、構成、整理、パフォーマンスを重視します。
2. テスト中のレポート：このシナリオでは、ユーザーからのフィードバックを取り入れたり、Power BI／Fabric でデプロイされたレポートの基本情報を確認したりします。
3. 利用中のレポート：これが理想的なシナリオで、利用状況を重視します。最終的な成功の判断基準は、レポートが利用されているかどうかです。レポートへのアクセス権を持つ人のうち、過去28日間にアクセスした人の割合と、その利用頻度を確認します。質の低いレポートは利用されないか、利用が減少します。

シナリオ2〜3でも、レポートのコンテンツや構成に関するフィードバックを提供できますが、ほかの項目を優先してください。

使用するタイミング

レポートのレビュー、監査、またはヘルスチェックを実施する際に有効にします。よくあるきっかけは次のとおりです。

• リリースや引き継ぎの前にレポートの品質をレビューする
• 既存のレポートを維持する価値があるか評価する
• ワークスペース全体で最適化の機会を特定する
• レポートの設計やデータ表示の有効性を評価する
• レポートのパフォーマンス問題を調査する

レビューの観点

包括的なレポートレビューでは、6つの観点を評価します。すべてのレビューで6つすべてが必要なわけではありません。ユーザーのニーズに合わせて範囲を設定してください。

1. 利用状況と導入状況

レポートの価値を示す、最も客観的な指標です。 どれだけ優れた設計でも、誰にも閲覧されないレポートはメンテナンスの負担になります。

script/ 内のスクリプトを使って利用状況データを取得します。

# Workspace overview (views, rank, page views, load times)
python3 scripts/get_report_usage.py -w <workspace-id>

# Add Tier 3 cross-workspace last-visited timestamps via the undocumented DataHub V2 API
# Useful for the "is this report being used at all" question without tenant admin role
python3 scripts/get_report_usage.py -w <workspace-id> --include-datahub

# Single report deep-dive (daily views, per-viewer breakdown, page views by day)
python3 scripts/get_report_detail.py -w <workspace-id> -r <report-id>

# Distribution audit (who has access, through what channels)
python3 scripts/get_report_distribution.py -w <workspace-id> -r <report-id>

閲覧者のフィルタリング： 導入状況の指標から、レポートの利用者ではないユーザーを除外します。サービスプリンシパル（種類が App）、レポート開発者、IT／サポート担当者が含まれると、閲覧者数が水増しされ、リーチが実態と異なるものになります。識別のヒューリスティックについては references/usage-metrics.md を、Microsoft Graph API を使ったセキュリティグループと配布リストの解決については references/distribution.md を参照してください。

利用状況の指標を評価します：

• オーディエンスへのリーチは最も重要な指標です。アクセス権を持つユーザーのうち、過去 7 日、28 日、60 日間に実際にレポートを閲覧したユーザーの割合はどれくらいでしょうか。リーチの計算方法と数値の意味については references/distribution.md を参照してください
• 閲覧傾向： 閲覧状況は安定していますか、増加していますか、それとも減少していますか。7 日間のローリング平均を使います（references/usage-metrics.md を参照）
• ページ閲覧の分布： 閲覧が 1 ページに集中していますか、それともレポート全体に分散していますか。ページが未使用だと判断する前に、ツールヒントまたはドリルスルーの対象ページ（直接閲覧は想定されません）ではないか確認し、pbir pages list で到達可能かどうかを確かめてください
• 最終アクセス日時： レポートが最後に誰かにアクセスされたのはいつですか。Tier 1（Admin Activity Events、30 日間のローリング期間、管理者ロールが必要）が公式な方法です。Tier 3 DataHub V2 の lastVisitedTimeUTC フィールド（--include-datahub）は、管理者権限なしでワークスペースを横断できる代替手段です。文書化されておらず、動作しなくなる可能性があることをユーザーに伝えてください
• 読み込み時間： P50 および P90 の読み込み時間は、対象オーディエンスにとって許容範囲内ですか。解釈については references/performance.md を参照してください

「健全」または「懸念あり」とみなす基準に、根拠のないしきい値を使わないでください。基準はレポートのオーディエンス、目的、ライフサイクルの段階によって異なります。アナリスト 3 人向けのレポートと、経営幹部 300 人向けのレポートでは、期待値が異なります。結論を出す前に、レビュー期間をレポートの更新頻度に合わせてください。最新の Usage Metrics レポートでよくある誤解と、廃止／維持／再設計を判断するためのフレームワークについては references/usage-interpretation.md を参照してください。

サブスクリプションは閲覧ではありません。 メールサブスクリプションはレポートのスナップショットを配信しますが、閲覧イベントは生成しません。有効な購読者は admin/reports/{id}/subscriptions（Fabric Admin が必要）で確認してください。閲覧数が 0 でも有効なサブスクリプションがあるレポートは、受動的に利用されています。

閲覧傾向には7 日間のローリング平均を使います。日ごとの生の件数はばらつきが大きいためです。現在の 7 日間平均を直前の 7 日間と比較し、傾向を把握してください。方法については references/usage-metrics.md を参照してください。

重要なポイント： 閲覧数が 0 のレポートが、必ずしも問題のあるレポートとは限りません。新しいレポート、季節的に利用されるレポート、サブスクリプション経由で利用されるレポート、またはテレメトリで捕捉されない埋め込みシナリオで使われるレポートの可能性があります。最終アクセス日時と照合してください。管理者アクセスが可能な場合は Tier 1 の管理者 Activity Events フィードを優先してください。利用できない場合は Tier 3 の DataHub V2 を代替手段として使い、文書化されていないことをユーザーに伝えてください。

権限： Tier 1（WABI）には、いずれかのワークスペースロールが必要です。Tier 2（モデル）には、ワークスペースの Contributor 以上が必要です。配布とサブスクリプションの確認には Fabric Admin（テナントレベル）が必要です。必要な権限の全一覧については references/usage-metrics.md を参照してください。

利用状況メトリックのデータセットスキーマと利用可能なテーブルについて、詳しくは usage-metrics-dataset/ を参照してください。

2. デザインとレイアウト

ビジュアルデザインと情報アーキテクチャを評価します。詳しいガイドラインは、pbi-report-design スキルを参照してください。参考：Data Goblins Report Checklist。

チェックリスト：

• ページタイトルがあり、内容を適切に表しています
• ビジュアル間と余白の間隔が一貫しています（ビジュアル間とページ余白が均等です）
• 詳細度のグラデーションに従っています（KPIは左上、詳細は右下）
• 色を意図的かつアクセシブルに使用しています（むやみに色を使わず、色覚多様性のあるユーザー向けに赤と緑を使い分けていません）
• フォントファミリー、サイズ、書式が全体を通して一貫しています
• ビジュアルの数が妥当です（目安として1ページあたり最大12～15個。複雑さに応じて異なります）
• 空のビジュアルがありません（すべてのビジュアルにフィールドがバインドされています）
• テーマが適用されています（Power BI の既定のテーマではありません）
• グラフの軸はゼロから始まっています（意図的な場合を除きます）
• すべてのビジュアルで既定の並べ替えが設定されています
• 選択ペイン内のビジュアルオブジェクトに、わかりやすいラベルが付いています（説明的な名前でグループ化されています）
• 対象ユーザーに必要な場合、モバイルレイアウトが用意されています
• ビジュアルヘッダーが設定されています（ドリルダウンやドリルスルーが不要な場合は無効にします）
• インタラクションが設定されています（クロスフィルタリングや強調表示を意図的に設定し、既定のままにしていません）
• パフォーマンスに配慮が必要なページでは、スライサーの「適用」ボタンを検討しています
• 必要に応じて、ページ間でスライサーが同期されています

3. データモデルのバインド

レポートと、その基盤となるセマンティックモデルとの接続を評価します。

チェックリスト：

• レポートは独自のモデルを埋め込むのではなく、公開済みのセマンティックモデルに接続しています（「薄いレポート」）
• すべてのフィールドバインドが、既存のモデル列またはメジャーを参照しています
• 拡張メジャー（薄いレポートのメジャー）は、レポート固有のロジックに限り、必要最小限に使用しています
• 壊れたフィールド参照や孤立したフィールド参照がありません
• ビジュアルでメジャーと列を適切に使い分けています（集計コンテキスト）
• ビジュアルレベルで個別のフィルターが有効になっていません

4. パフォーマンス

レポートの読み込み時間とビジュアルの複雑さを評価します。パフォーマンス監査スクリプトを実行してください。

python3 scripts/performance_audit.py -w <workspace-id> -r <report-id>

パーセンタイルの解釈、ビジュアルのフィールドバインドからの DAX クエリの推定、よくあるアンチパターンについては、references/performance.md を参照してください。

主な指標： P50 と P90 の読み込み時間、ページあたりのビジュアル数、拡張メジャーの数です。ビジュアル数は目安にすぎず、実際に負荷を左右するのはビジュアルごとのクエリコストです。コストモデルの全容、Performance Analyzer のエクスポートの解釈方法、DirectQuery レポートレイヤーのチューニング手段、インタラクションとナビゲーションの監査については、references/performance-audit.md を参照してください。まずコストモデルを確認せずに、ビジュアル数の固定的なしきい値を適用しないでください。

5. レポートのメタデータとガバナンス

レポートのガバナンス状況を評価します。references/report-metadata.md を参照してください。

チェックリスト：

• 薄いレポートです（公開済みのモデルに接続しており、埋め込み型の厚いモデルではありません）
• 対象ユーザーに適した推奨ステータスです（本番環境では「認定済み」、チームでの使用では「昇格済み」）
• テナントポリシーで求められる場合、秘密度ラベルが適用されています
• 本番ワークスペースにある場合、デプロイパイプラインに含まれています
• ワークスペースアプリまたは組織アプリで配布しています（直接リンクや Web への公開ではありません）
• 個々のユーザーではなく、セキュリティグループ経由でアクセス権を付与しています
• 利用者には閲覧のみのアクセス権（閲覧者ロール）を付与し、編集アクセス権は開発者に限っています
• データガバナンス上のリスクについて、Excel へのエクスポートの利用パターンを確認しています（references/export-to-excel.md を参照）

6. アクセシビリティ、標準、ドキュメント

レポートがアクセシビリティ、組織の標準、ドキュメントの要件を満たしているか評価します。

アクセシビリティ：

ほとんどのアクセシビリティチェックは PBIR ファイルに対して静的に実行できます。フォーカスの移動とスクリーンリーダーによる読み上げの確認のみ、公開中のレポートが必要です。手順の全容については、references/accessibility-audit.md を参照してください。ジオメトリ／配置の監査、タブ順序の照合、静的チェック（代替テキスト、装飾項目、色のみを使った表現）、SVG メジャーの確認、スクリプトの視覚的な確認、モバイル対応が含まれます。

チェックリストの概要：

• すべてのデータビジュアルに代替テキストがある（SVG メジャーのホストやスクリプトビジュアルも含む）
• 装飾項目がタブ順序から除外されている（tabOrder = -1）
• タブ順序が幾何学的な読み取り順（上から下、左から右）に一致している
• 色のみを使った表現がない（形状、グリフ、またはテキストと組み合わせている）
• 色のコントラストが WCAG 2.1 AA を満たしている（テキストは 4.5:1、UI 要素は 3:1）
• フォントサイズが読みやすい（データは最小 9pt、ラベルは 12pt）
• 利用者向けのページにモバイルレイアウトがある
• キーボードの Tab キーによる移動を実際に確認している（ファイルからは確認できません）

標準：

• ガバナンスポリシーで必要とされている場合、機密ラベルが適用されている
• 命名規則に従っている（レポート名、ページ名、ビジュアルのタイトル）
• 問題の報告やフィードバックの送信先リンクが用意されている
• フィルターの組み合わせが十分にテストされている

ドキュメント（引き継ぎ／本番運用向け）：

• 目的の説明：レポートが回答するビジネス上の問い
• 想定する対象者とユーザー層が特定されている
• 一般的でない機能が文書化されている（ビジュアルレベルのフィルター、非表示のスライサー、ブックマーク、カスタムビジュアル）
• サポート担当者と手順が明確になっている
• ビジネスユーザー向けのトレーニング／定着化資料が用意されている

レビューワークフロー

ステップ 1：範囲

ユーザーが何をレビューしてほしいのかを明確にします。以下を確認します。

• 単一のレポートですか、それともワークスペース全体の監査ですか？
• 特に重視する観点はどれですか？（利用状況、デザイン、パフォーマンス、すべてですか？）
• レビューのきっかけとなった具体的な懸念はありますか？
• 結果はどこに記録すればよいですか？（スクラッチパッド、エージェント用ドキュメント、Obsidian のノート、Wiki など）

ステップ 1a：範囲とアクセス権の確認

ユーザーに次の点を尋ねます。

• 基盤となるセマンティックモデルにアクセスできますか？
• レポートとモデルの両方の開発者ですか、それともどちらか一方のみですか？

セマンティックモデルが対象範囲に含まれる場合は、semantic-model スキルも並行して使用します。レポートの問題（ビジュアルの表示が遅い、（空白）値、フィールドの欠落など）の多くはモデルに起因します。レポートに現れるモデル関連の症状については、references/best-practices.md を参照してください。

ステップ 1b：レポートのライフサイクル段階を確認

レポートがローカルのみで、まだ公開されていない場合は、ユーザーに次のように尋ねます。

「このレポートは、まだ利用者がいない開発中のものですか、一部のユーザーを対象にテスト中のものですか、それともすでに配布され、活発に利用されて価値を生み出しているはずのものですか？」

これにより、どの観点が該当するかを判断できます。

段階	利用状況データ？	レビュー内容
開発	いいえ	デザイン、データモデルとのバインド、パフォーマンス、アクセシビリティ、構成
テスト	一部	上記すべてに加え、テスターが実際にテストしているか確認（テスト対象者からのビュー）
本番	はい	利用状況、配布、エクスポート分析を含むすべての観点

レポートの成否は、利用されているか、ビジネス価値を提供しているかにかかっていることをユーザーに伝えます。デザイン、パフォーマンス、構成は事前にレビューできますが、レポートが役立っているかどうかを測る客観的な指標は利用状況データだけです。適切な要件収集は定着化に役立ちますが、定着化を保証することはできません。

レポートがローカルのみの場合は、公開版がどこにあるか（または今後どこに公開されるか）を尋ねます。利用状況の指標を得るには、Power BI サービスにレポートが公開されている必要があります。

ステップ 2：データの収集

利用状況スクリプトを実行して定量データを取得します。レポート定義をエクスポートするか調査して、定性的な評価を行います。

Step 3: 評価

上記のチェックリストを使い、関連する各観点を確認します。見つかった項目は、重大度に応じて評価してください。

• Critical：機能の破損、セキュリティリスク、または容量を消費している完全に未使用のレポート
• High：ユーザーに影響するパフォーマンスの問題、重大な設計違反、データバインディングの欠落
• Medium：設計の不整合、中程度のパフォーマンス上の懸念、アクセシビリティの部分的な不足
• Low：軽微な仕上げ項目、スタイルの好み、最適化の機会

Step 4: 検出事項の報告

検出事項を構造化された要約として提示します。影響が最も大きい項目から記載してください。

形式：

REPORT REVIEW: <Report Name>
===============================

USAGE SIGNAL
  Views (30d): 47  |  Viewers: 8  |  Rank: #3/22
  Top pages: Overview (60%), Detail (30%), Trends (10%)
  Load time P50: 3.2s  |  P90: 7.1s

CRITICAL
  - [Performance] P90 load time exceeds 7s due to 14 visuals on Overview page

HIGH
  - [Design] No page titles on 2 of 3 pages
  - [Binding] 3 visuals have broken field references

MEDIUM
  - [Design] Inconsistent margins (24px left, 32px right)
  - [Accessibility] Missing alt text on 5 data visuals

LOW
  - [Design] Default theme applied; consider custom theme
  - [Standards] Report name uses spaces instead of hyphens

前提条件

使用状況スクリプトを実行する前に、次の点を確認してください。

• Azure CLI で認証済みであること：必要に応じて az login を実行します
• fab CLI で認証済みであること：必要に応じて fab auth login を実行します（配布スクリプト用）
• Python の requests パッケージ：uv pip install requests

参考資料

• references/usage-metrics.md -- 使用状況データ API（公式および非公開）の完全なドキュメント
• references/usage-interpretation.md -- 最新の Usage Metrics の正しい読み方、廃止・維持・再設計の判断フレームワーク
• references/distribution.md -- すべてのレポートへのアクセス経路と監査方法
• scripts/get_report_usage.py -- ワークスペースレベルの使用状況の概要
• scripts/get_report_detail.py -- 単一レポートの詳細分析（日別、閲覧者別、ページ別）
• scripts/get_report_distribution.py -- 配布の監査（ACL、アプリ、Web への公開）
• scripts/performance_audit.py -- 読み込み時間と視覚的な複雑さの分析
• references/performance.md -- パーセンタイルの解釈、ビジュアルメタデータからの DAX クエリ推定
• references/performance-audit.md -- クエリコストモデル、Performance Analyzer のエクスポート、DirectQuery のチューニング、操作／ナビゲーションの監査
• references/accessibility-audit.md -- 配置／タブ順序の監査、静的なアクセシビリティ検査、SVG／スクリプト／モバイルの確認
• references/report-metadata.md -- シック／シン、認定、機密性、パイプライン、モデルのプロパティ
• references/export-to-excel.md -- エクスポート操作の分析、データガバナンスへの影響
• references/best-practices.md -- データ可視化の原則、グラフの選択、色、インタラクション設計
• usage-metrics-dataset/ -- エクスポートされた Usage Metrics データセット（TMDL スキーマとレポート定義）

関連スキル

• semantic-model -- セマンティックモデルの設計とレビューを補完するスキル（モデルが対象範囲に含まれる場合は並行して実行します）
• pbi-report-design -- 詳細なレポート設計ガイドラインとレイアウトルール
• modifying-theme-json -- テーマの作成、準拠状況の監査、書式設定の昇格
• deneb-visuals、python-visuals、r-visuals、svg-visuals -- ビジュアル固有のレビュー基準（現在は custom-visuals プラグインに含まれています。claude plugin install custom-visuals@power-bi-agentic-development で追加します）