適用対象:✅Power BI サービス
適切に準備されたセマンティック モデルにより、CopilotPower BIでビジネスの質問に正確に答える基盤が強化されます。 ユーザーに Copilot を導入する前に、モデルを評価し、回答の品質に影響する可能性がある問題に対処します。 まずは、レポートですでに使用されている指標、リレーションシップ、およびビジネス定義から始めましょう。 追加の手順では不正確なリレーションシップや不適切な集計を修正できないため、セマンティック モデルのモデリングの問題を解決します。 次に、 Copilot のモデルを最適化し、一貫したレビュー プロセスを確立します。
この記事は、セマンティック モデルの作成者、レポート所有者、およびユーザーに Copilot を導入するチームを対象としています。 これは、ユーザーが質問して結果を確認する方法を説明するCopilotを補完するものです。 この記事では、セマンティック モデルを準備し、生成 Copilot 回答を評価する方法について説明します。
注
次の要件に留意してください。
- 管理者が、Copilot in Microsoft Fabric を有効にする必要があります。
- Fabric の容量は、この記事に記載されているいずれかのリージョン ( Fabric リージョンの可用性) にある必要があります。 そうしないと、Copilot を使用できません。
- Copilot の使用を開始するには、事前に管理者によってテナント スイッチが有効にされている必要があります。 詳細については、「Copilot のテナント設定」の記事を参照してください。
- テナントまたはキャパシティが米国またはEUデータ境界の外にある場合、Copilot は既定で無効になります。 1 つの例外は、Fabric テナント管理者が 、Azure OpenAI に送信されたデータをテナントの地理的リージョン、コンプライアンス境界、または国内クラウド インスタンス テナント設定の外部で処理できる 場合です。 この設定は、Fabric 管理ポータルで確認できます。
- Copilot in Microsoft Fabric は、試用版 SKU ではサポートされていません。 有料 SKU のみがサポートされています。
- Power BI のスタンドアロン Copilot エクスペリエンスを確認するには、テナント管理者がテナント切り替えを有効にする必要があります。
注
Power BI サービス Web モデリング エクスペリエンスでは、Copilotはモデルを評価する以上のことを行うことができます。 テーブルと列の名前変更、リレーションシップの作成、DAX メジャーの生成など、変更を直接提案して適用することもできます。 この記事の最適化ガイダンスでは、その分析から得られるより優れた結果を直接サポートしています。明確に構造化された名前の付いたモデルは、より正確で有用な提案 Copilot 生成するのに役立ちます。
ビジネスに重点を置いた質問から始める
重点を置いたビジネス シナリオを選択し、ユーザーがよく寄せられる質問を特定します。 質問ごとに、予想されるメジャー、グループ化、日付ベース、フィルター、検証された結果を定義します。
あいまいさを明らかにする質問を含めます。 たとえば、 売上のパフォーマンスは 、収益、注文量、増加、または利益を指す場合があります。 既定の解釈を定義するか、説明を求める Copilot を指示します。
セマンティック モデルがサポートする合計、比較、ランキング、傾向に関する質問から始めます。 Copilot が最初の一連の質問に一貫して回答できるようになったら、さらに複雑な質問を追加します。
セマンティック モデルを確認して改善する
次の表の推奨事項を使用して、セマンティック モデル Copilot 解釈し、回答の品質を向上させることができます。
モデル構造
| 要素 | 考慮事項 | 説明 | 適用する場所 | 例 |
|---|---|---|---|---|
| テーブルリンク操作 | 明確なリレーションシップを定義する | テーブル間のすべてのリレーションシップを明確に定義し、それらが論理的であることを確認します。 どのリレーションシップが一対多、多対一、または多対多であるかを示してください。 | モデル ビューで、[リレーションシップの管理] を選択します。 |
Date[DateID]からSales[DateID]への一対多リレーションシップを作成し、リレーションシップがアクティブであることを確認します。 |
| ファクト テーブル | 明確な目的と詳細レベル | ファクト テーブルを明確に識別し、各行が表す内容を定義します。 計算で、その詳細レベルに適した集計が使用されていることを確認します。 | テーブルのプロパティとモデル構造 | ファクト テーブルに FactSalesなど明確に名前を付け、注文明細行ごとに 1 行など、その詳細レベルを記述します。 |
| 次元テーブル | 支援的な説明データ | ファクト テーブル内の定量的メジャーに関連する記述属性を含むディメンション テーブルを作成します。 | テーブルのプロパティとデータ モデルの構造 | 属性 (DimProduct、ProductName、Category) を持つBrandや、属性 (DimCustomer、CustomerName、City) を持つSegmentなどのディメンション テーブルを作成します。 |
| Hierarchies (階層) | 論理グループ化 | 特にレポートのドリルダウンをサポートするディメンション テーブルの場合は、データ内に明確な階層を確立します。 | テーブルのコンテキスト メニューで、[新しい階層] を選択します。 |
Dateテーブルで、階層 (Year>Quarter>Month>Day) を作成します。
Geographyテーブル: Country/Region>State>City。 |
| 関係タイプ | 明確に指定 | 正確なレポートが確実に生成されるように、リレーションシップの性質 (アクティブまたは非アクティブ) とそのカーディナリティを明確に指定します。 | [リレーションシップのプロパティ] ダイアログ |
Dateを多対一 (アクティブ) としてSalesに設定し、Productを多対一 (アクティブ) としてSalesし、必要に応じてロールプレイングリレーションシップを非アクティブとしてマークします。 |
指標とKPI
Copilot はアドホック計算を作成できますが、頻繁に使用される計算またはビジネス クリティカルな計算を、レビューされたメジャーとしてセマンティック モデルに追加します。 このアプローチでは、レポート作成者と Copilot 一貫したビジネス定義を使用できます。
| 要素 | 考慮事項 | 説明 | 適用する場所 | 例 |
|---|---|---|---|---|
| 対策 | 標準化された計算ロジック | 説明と理解が容易な標準化された明確な計算ロジックをメジャーに提供します。 | 測定定義と説明プロパティ | DAX の測定: Total Sales = SUM(Sales[SaleAmount]) し、「すべての売上金額の合計」という説明を追加します。 |
| 対策 | 名前付け規則 | 計算方法と目的を明確に表す指標名を付けてください。 | メジャーを作成するときのメジャー名フィールド |
Average Customer Ratingという省略形ではなく、わかりやすい名前のAvgRatingを使用します。 |
| 対策 | 事前定義済みでレビュー済みの指標 | 一般的な要求とビジネス クリティカルな計算のための再利用可能なメジャーを作成します。 レポート作成者と Copilot が一貫したビジネス定義を使用するように、そのロジックを確認します。 | メジャー定義と説明プロパティ | 返品、割引、および取り消された注文の承認済み処理を使用して [Net Sales] を定義します。 年初来売上や前月比成長など、一般的によく求められる指標を含めます。 |
| 対策 | 比率 | 適切な分子、分母、集計の動作を使用して比率を定義します。 | メジャー定義内 |
[Gross Margin %]を定義するために、承認された粗利メジャーを、平均行レベルのパーセンテージではなく、承認済みの純売上メジャーで割ります。 |
| 対策 | カウント | 行数とビジネスイベント数が別の結果を示す場合は、別々のメジャーを作成してください。 | メジャー定義内 |
[Order Line Count]とは別に[Order Count]を定義します。 |
| 対策 | ポイントインタイム バランス | 製品、拠点、日付にまたがってスナップショットを適切に集計できるメジャーを使用します。 | メジャー定義内で | 日付をまたいで毎日のインベントリ スナップショットを合計するのではなく、終了在庫メジャーを定義します。 |
| 対策 | 表示形式 | 各指標の単位とスケールが明確になる書式を適用します。 | メジャーの Format プロパティ内で | 金額は通貨、比率はパーセント、件数は整数として書式設定します。 |
| 主要業績評価指標 (KPI) | 定義済みで関連性の高い | ビジネス コンテキストに関連し、レポートに頻繁に表示される KPI のセットを確立します。 | 一般的に監視される KPI の対策を作成する |
ROI = DIVIDE([Profit], [Investment])、CAC = DIVIDE([Marketing Spend], [New Customers])、LTV = [Avg Order Value] * [Purchase Frequency] * [Customer Lifespan]などのメジャーを定義します。 |
列とデータの品質
| 要素 | 考慮事項 | 説明 | 適用する場所 | 例 |
|---|---|---|---|---|
| 列名 | 明確なラベル | 列名を明確にし、わかりやすいものにします。 便利なビジネス識別子を保持しますが、コンテキストなしでさらに参照する必要がある ID やコードは避けてください。 | Power Query エディターまたはモデル ビューで列の名前を変更する | 列の名前を ProdID から Product ID または Product Nameに変更し、 CustNo から Customer Numberに変更します。 |
| 列のデータ型 | 正しく一貫性のあるもの | すべてのテーブルの列に正しく一貫性のあるデータ型を適用して、メジャーが正しく計算されるようにし、適切な並べ替えとフィルター処理を可能にします。 | 列のプロパティで、 データ型を設定する |
Sales[SaleAmount]が 10 進数 (テキストではなく)、Date[Date]が日付 (テキストではない)、Product[ProductID]が整数であることを確認します。 |
| データの一貫性 | 標準化された値 | フィルターおよびレポートでの一貫性を確保するために、列内では標準化した値を維持します。 | 検索と置換、または Power Query 変換を使用する。 |
Status列では、すべての値で一貫した大文字と小文字の区別が使用されていることを確認します(Open、Closed、Pending (open、CLOSEDなど、大文字と小文字が混在しません)。 |
| 日付列 | 明確なビジネスの意味 | ビジネス上の意味が異なる日付を区別します。 会計年度がいつ開始されるかを含め、期間で会計年度または暦年を使用するかどうかを文書化します。 テキスト ラベルのみに依存するのではなく、日付列とリレーションシップを使用します。 | 日付テーブル、リレーションシップ、および説明プロパティ内 | 個別の Order Date 列と Shipment Date 列を使用します。
Q1などのラベルのみに依存するのではなく、会計期間の列を定義します。 |
| キー列 | 欠損のない一意の値 | リレーションシップと計算によって正確な結果が生成されるように、キーの欠落または重複に対処します。 | Power Query の変換とソース データにおける | 顧客ディメンションの各行に一意の非空白の顧客キーがあることを確認します。 |
更新、セキュリティ、およびメタデータ
| 要素 | 考慮事項 | 説明 | 適用する場所 | 例 |
|---|---|---|---|---|
| スケジュールを更新する | 透過的でスケジュールされた | データの更新スケジュールを明確に伝えて、分析しているデータのタイムラインをユーザーが確実に理解できるようにします。 | データセットの設定とドキュメント | "データは毎日午前 6 時 (UTC) に更新されます"、または "15 分間の増分更新によるリアルタイム データ" というテキスト ボックスまたは説明を追加します。 |
| セキュリティ | ロール レベルの定義 | 一部のユーザーにしか表示すべきでない機密性の高い要素がある場合は、さまざまなレベルのデータ アクセス用にセキュリティ ロールを定義します。 | モデル ビューで、[ロールの管理] を選択します | ロール "営業チーム" をフィルター Sales[Region] = USERNAME() で作成し、ロール "HR" は従業員データテーブル用のフィルターを使用して作成します。 |
| メタデータ | 構造のドキュメント | 参考までに、テーブル、列、リレーションシップ、メジャーなど、データ モデルの構造を文書化します。 | 説明プロパティと外部ドキュメントを使用する | テーブルと列に説明を追加します。 モデル ダイアグラム、データ ディクショナリ、メジャー カタログを使用して別のドキュメントを作成します。 |
DAX クエリに関する考慮事項
次の表に、Copilotを使用して正確なデータ分析式 (DAX) クエリを作成するのに役立つその他の条件を示します。 これらの推奨事項は、正確な DAX クエリを生成するのに役立ちます。
| 要素 | 考慮事項 | 説明 | 適用する場所 | 例 |
|---|---|---|---|---|
| メジャー、テーブル、列 | 説明 | description プロパティで、各要素とその使用方法を定義します。 ビジネス上の意味、単位、および重要な除外から始めます。 Copilot は最初の 200 文字のみを使用します。 | [プロパティ] ウィンドウのメジャー、テーブル、列の [説明] フィールド | メジャー [YOY Sales]の場合は、「受注の前年比 (YOY) の差」という説明を追加します。 'Date'[Year] 列と共に使用して、最新の年以外の年別に表示します。 一部の年は、前年の同じ期間と比較されます。 |
| 計算グループ | 説明 | モデルメタデータには計算項目は含まれません。 計算グループ列の説明を使用して、計算項目の一覧と使用方法を説明します。 Copilot は最初の 200 文字のみを使用します。 | 計算グループ列の [プロパティ] ウィンドウ |
タイム インテリジェンス サンプル計算グループ列の場合は、「現在: 現在の値、MTD: 月次累計、QTD: 四半期累計、YTD: 年初来、PY: 前年、PY MTD、PY QTD、YOY: 前年比、YOY%: YOY を %として使用する」という説明を追加します。メジャー テーブルの場合は、「メジャーはデータを集計するために使用されます。」を追加します。 これらの指標は、CALCULATE([Measure Name], Time intelligence[Time calculation] = YOY) という構文を使用して、年次比較として表示できます。 |
テスト結果のトラブルシューティング
AI 命令を更新する前に、生成されたクエリと結果を確認して問題の原因を特定します。
| Issue | 確認すべきこと |
|---|---|
| 不適切なビジネス メトリック | メジャー名、説明、AI データ スキーマの選択、既定のメトリックを定義する手順を確認します。 |
| 予期しない合計または期間 | フィルター コンテキストと日付ベースと予想される結果を比較します。 次に、リレーションシップの動作と集計ロジックを確認します。 |
| カテゴリが見つからないか、結果がない | ソース データ、更新状態、カテゴリ値、要求された期間、コンシューマーのアクセス許可を確認します。 結果を 0 として解釈しないでください。 |
| 誤解を招くプレゼンテーションでデータを修正する | 単位、書式、並べ替え、および説明がデータの裏付けを超えた内容になっていないかを確認します。 |
| 応答が遅い、または失敗した | 生成されたクエリとセマンティック モデルのパフォーマンスを調べます。 ビジネス ガイダンスを変更する前に、クエリを検証済みの参照クエリと比較します。 |
| AI 変更の準備データ が反映されない | 正しいセマンティック モデルを変更したことを確認し、変更を有効にする時間を許可します。 Copilot ペインを閉じて再度開き、デプロイと更新の要件を確認します。 |
テスト、デプロイ、更新の要件については、「Copilot ツールの変更と考慮事項と制限事項をテストする」を参照してください。