前回のブログでは、Copilot for Power BI の基礎となる仕組みや活用に必要なスキルの種類、Copilot Tooling（AI 用にデータを準備）の一部（スキルまで）についてご紹介しました。今回は Copilot をより実務的かつ効果的に活用するための方法に踏み込んでいきます。具体的には、「AI 用にデータを準備する」ための Copilot Tooling に含まれる以下の 3 つの機能にフォーカスします：
-
データ スキーマを簡略化する（Simplify the data schema）：Copilot に認識させるテーブルや列を指定し、ノイズを除去することで精度の高い応答を実現
-
確認済みの回答（Verified answers）：既存レポート上の視覚エレメントを正解として登録し、Copilot の回答を確実なものとする
- AI への指示を追加（Add AI instructions）：Copilot に対して明示的なガイドラインや前提条件を与えることで、より業務に即した回答を得られるようにする
これらの機能は、データ利用者に提供される「Standalone Copilot」（別名「Chat with your data」）体験を最適化するものであり、Copilot をトレーニングするための仕組みでもあります。
※ Copilot の用語
Power BI Desktop を立ち上げ、「AI 用のデータを準備する」をクリックします。
データ スキーマを簡略化する
「データ スキーマを簡略化する」は Schema selection（スキーマの選択）がベースの考え方になります。つまり、Copilot に使わせるテーブルや列（スキーマ）、DAXメジャーを事前に制限・選択する機能です。
🪙効果：
- 不要な情報を除外し、回答の精度が上がる
- 大規模なモデルでも、使いたい部分だけに Copilot の視点を絞れる
- セキュリティや情報漏えいのリスクを減らせる（一部）
🧰使いどころ：
- モデルに多数のテーブルが含まれているとき
- 一部の列だけを質問対象にしたいとき
✅具体例：
以下のスタースキーマがあった場合、dCalendarDailyという日付テーブルがあります。
このテーブルのスキーマ構成のままで以下の質問を行ったところ、期待していた結果とは異なる応答が返されました。
✏️プロンプト：日次売上を出して
先ほどのスタースキーマを見ると、dCalendarDaily テーブルはリレーションシップにおいて「多」の側に位置しており、フィルターされる側（fact side）になります。そのため、dCalendarDaily テーブルを切り口（ディメンション）として売上データをフィルターすることは、通常の一方向のリレーションシップ設定では想定されていません。
しかしながら、Copilot はテーブル名に「Daily（日次）」という語が含まれていたことから、このテーブルを日付ディメンションと誤認し、売上のフィルターに使用しようとしました。その結果、リレーションシップの方向に反して不適切なフィルターが適用され、すべての売上数値が同じになるという誤った結果が返されてしまいました。
※補足
Power BI におけるリレーションシップは通常「1（ディメンション）」→「多（ファクト）」の方向でフィルターが伝播します。そのため、「多」側から「1」側へのフィルターを行いたい場合は、DAX メジャーで明示的に制御するか、リレーションシップを双方向に設定する必要があります。
そこで、下図のように AI データスキーマの設定を行います。具体的には、dCalendarDaily テーブルを分析対象から除外し、そのうえで Copilot による出力結果がどのように変化するかを再度確認してみます。
ご覧のとおり、結果は dCalendar テーブルを使用した正しい内容として返されました。
補足として、今回のデータセットは実際には月次（Monthly）データで構成されており、「日次の売上を出して」というプロンプト自体が不適切であった点を挙げておきます。それにもかかわらず、Copilot（LLM使用）はセマンティックモデルの中身を最大限活用し、可能な限り意味の通る回答を導き出そうとしました。
このように、LLM（大規模言語モデル）はしばしば「ハルシネーション（事実でない内容を生成）」を起こすと言われる一方で、曖昧な問いに対しても柔軟に応答しようとする応用力の高さは見逃せません。
AI データスキーマの副次的効果
AI データスキーマの導入は、Copilot の理解と応答精度を意識した構成を促すことで、最終的には「AI フレンドリーなモデル」、すなわちスリムなスタースキーマへの最適化につながることが期待されます。不要なテーブルや列を除外し、意味的に重要な要素に焦点を当てることで、AI の応答品質を高めるとともに、パフォーマンスやガバナンスの観点でも効果的なモデル運用が可能となります。なお、既に構築されたモデルに対しては、Copilot Tooling を活用し、Copilot にアクセスさせるデータ量を適切に制御することが重要です。
根本的な問題
とはいえ、根本的な課題も存在しています。
- エンドユーザーは、そもそもリレーションシップを意識して質問しない
多くの場合、Copilot を利用するエンドユーザーは、モデルの構造やリレーションシップを理解していないため、的確なプロンプトを入力することが難しいのが実情です。 - モデル設計そのものに課題があるケースも多い
モデルが正しく設計されていなければ、Copilot がどれほど高度であっても、適切な回答を返すことは困難となります。そのため、モデリングの最適化は本質的に重要な要素となります
最終的に、AI フレンドリーなモデルを構築できるかどうかは、モデル開発者の設計力と判断力、そしてある程度のビジネスコンテキスト（業務知識等）を把握しているかどうかに大きく依存します。本質的に使いやすいモデルを構築することこそが、Copilot を有効に活用し、エンドユーザーにとって価値ある体験を提供する鍵となるのです。
AI データスキーマの留意点
現時点での留意点は以下のとおり。
a）最初に設定を行った場合に限り、モデリング段階で既に列が非表示に設定されている場合、「データ スキーマを簡略化する」機能においては、これらの非表示列も一覧に表示されますが、初期状態で選択解除（チェックはオフ）になっています（下図のa）
b）Fact テーブルにおいて、リレーションシップのキー列（外部キー）として使用されている列が表示されていても、「データ スキーマを簡略化する」画面では、これらのキー列も自動的に選択解除になっており、Copilot に渡す対象から除外される状態になっています（下図のb）
c) 日付列については、モデリング段階で非表示に設定していない限り、「データ スキーマを簡略化する」画面で自動的に選択解除になることはありません（aの例）。そのため、不要な日付列（主にFact テーブル側）は明示的に非表示に設定しておく必要があります。なお、こちらはバグではなく、仕様であることが確認されています。
d）「データ スキーマを簡略化する」機能で特定の列を選択解除しても、その列が Power BI モデル上で非表示になるわけではありません。あくまで、Copilot がアクセス・参照する対象から除外されるだけであり、モデルビューやフィールドリスト上の表示状態は維持されます。
a～dまでをまとめた表が下記になります。
| 項目 | 内容 | 備考／補足 |
|---|---|---|
| a）非表示列の扱い | モデリング段階で非表示に設定された列は、「データ スキーマを簡略化する」画面でもチェックが選択解除になる | 列自体は一覧には表示される（モデルで非表示状態であっても） |
| b）Factテーブルのキー列 | リレーションシップのキーとして使用されている列（Factテーブル側）は、自動的に選択解除になる | Dim側に主キーとして存在するため、Fact側の外部キー列は自動的に選択解除される |
| c）日付列の例外 | 日付列は、リレーションシップがあっても、Fact側にある日付列は自動的に選択解除されない | Fact側の日付列をCopilotに使用させたくない場合、基本的に明示的に選択解除をしておく必要あり |
| d）チェックOFFの影響範囲 | 「データ スキーマを簡略化する」画面でチェックをオフにしても、モデル上では非表示にはならない（エンドユーザーは非表示されていない列にはアクセスできる） | Copilot のデータとの対話に使用されるデータから除外されるだけで、ユーザー UI には影響なし |
なお、注意すべきポイントのひとつは、スキーマ選択で不要な列を除外していても、その列に対して DAX メジャーで計算ロジックが定義されている場合、Copilot が意図せずそのメジャーを利用して回答を生成してしまう可能性があるという点です（下図参照）。
非常に厄介な仕様ではありますが、これを防ぐためには、上記の例であれば 「MonthElapsed」 という DAX メジャー自体も除外する必要があります。これらすべてを適切に除外した場合、Copilot の返答は以下のようになります。
上図から、いずれも「経過月」に関する列を使った提案ではないことが分かるため、「スキーマ選択」が正しく機能していることが確認できます。
試しに、意図的に「スキーマ選択」から除外した Inv[MonthPassed] （プロンプトでは「Inv.MonthPassed」）列を指定して計算を実行してみたところ、以下の結果となりました。
「スキーマ選択」が効いていることを改めて確認することができました。
なお、「Copilot tooling」は新機能であるため、一見すると実現できそうに思えても、実際には制限が存在するケースも少なくありません。こうした制限事項を正しく把握しておくことが非常に重要です。
確認済みの回答
次に、「確認済みの回答（Verified answers）」の詳細です。こちらの機能は、ユーザーが頻繁に行う質問に対して、レポート内の最も適切なビジュアル（チャートやテーブル）を指定することで、常にそれらのビジュアルを返すことが出来るものです。設定方法はシンプルで、レポート内でよく参照されるビジュアルを選択し、右上の三点リーダー（…）をクリックして、「確認済みの回答を設定する」を選びます。
その後、Copilot が選択されたビジュアルの内容に基づいて自動的に質問文を生成しますので、必要に応じて修正・調整を行ってください。これにより、ユーザーは毎回一貫性のある、信頼性の高い回答を得られるようになります。
※注意
2025年7月1日時点において、「確認済みの回答」は Power BI Desktop から保存を試みても、保存されない不具合が発生しています（Power BI サービス側でも同様）。この問題は、2025年7月中旬までに修正が期待されています。そのため、当該機能を本格的に活用される場合は、今しばらくお待ちいただくことをおすすめします。
「確認済みの回答」は主に2つの活用ポイントがあります。最大の特徴は、「LLMによる揺れ」*1を抑制するのに良い機能であることです。言い換えれば、この機能は特定の質問に対して常に安定した回答を返したい場合に使用される仕組みになります。
「確認済みの回答」の種類
- 手動更新が必要なタイプ
「現在の社長は誰？」など、定期的に人が更新する必要がある内容 - データに紐づく自動更新型
「過去3ヶ月の売上推移」など、データが自動的に更新され続けるもの
ポイント
- 確認済みの回答はツール上で作成・編集・削除可能
- 一度設定すれば、通常はメンテナンス不要
- 類似する質問に対して優先的に上位表示される
「確認済みの回答」を活用することで、繰り返し聞かれる質問に対して常に信頼性の高い回答を提示できます。特に、よくある問い合わせや社内FAQ的な用途において効果的です。
現時点で「確認済みの回答」は、Power BI Desktop および Power BI Service の両方から設定可能な唯一の Copilot Tooling 機能となっています。Power BI Service から設定するには、セマンティックモデルを選択し、「AI 用のデータを準備する」オプションからアクセスしてください。
動作確認
実際の挙動について見てみましょう。
✏️プロンプト: グループ別在庫推移
このプロンプトを Copilot に投げてみたところ、確かに結果は返ってきましたが、テーブル形式での出力となりました。この形式を求めていた場合は問題ありませんが、そうでない場合には、再度質問を投げ直すことになるかもしれません。
そこで、対象となるビジュアルの三点リーダーから、以下のように設定をします。
設定が完了した後、再度同じプロンプトを投げます。すると、対象のページにはないものの、「確認済みの回答」として設定されたビジュアルが表示されました。
同様に、別のプロンプトも入力してみました。文脈に合致していれば、異なる表現であっても「確認済みの回答」として結果が返されることがあります。
なお、「確認済みの回答」のテキストは、日本語のプロンプトであっても自動的に英語に変換されて処理されるため、無理に英語を日本語に戻す必要はありません。従って、入力言語については開発者にとって分かりやすい形式で日本語・英語どちらでも構いません。
ところで、この限られたチャット空間において、グラフを表示させる意図が分かりづらいと感じる方もいるかもしれません。しかし、ここで行っているのは、たとえば「確認済みの回答」が設定されていないページを閲覧しているユーザーに対して、レポート内から直接的な回答を返すことや、結果の確認作業を含む一連のプロセスです。
こうした作業は、実際には次回解説予定の「Standalone Copilot」（別名「Chat with your data」）体験を最適化するための準備にもなっています。
もう少し例を見てみます。
設定: YrFlag（CY = 今年、PY = 前年）とGroup（A-E...U-Z）
※重要
⑤の「閲覧者が利用できる」フィルターで選択項目を表示させるためには、予めそのビジュアルに対して、フィルターペインに対象となる項目（今回は「YrFlag」と「Group」）を追加してあげる必要があります。これを行わなかった場合、これらの選択肢は出現しません。
Power BI Service側の「セマンティックモデルの詳細」から確認。
Tips: 「確認済みの回答」は非表示タブにて作成
プロンプト: 在庫・利益率のトレンド
✏️プロンプト: PYの在庫・利益率推移
⑤のステップでフィルターに使用する項目を設定したおかげで、年度（CY, PY等）別にフィルターを掛けて「確認済みの回答」を出すことができるようになりました。
✏️プロンプト: 粗利益率と在庫の関係。グループが"K-O"の場合
やや粗いプロンプトですが、Group別にフィルターを掛けることもできました。
✏️プロンプト: PYにおける粗利益率と在庫の関係。グループが"K-O"の場合
最後に、YrFlagとGroupの両方でフィルターを掛けることも出来ました。
「確認済みの回答」のまとめ
「確認済みの回答」は、「データに関する質問に回答」スキルが提供できる応答の一種です。現在の 「確認済みの回答」は、ユーザーの質問に対して「このチャートを見せればOK」というように、あらかじめ設定された固定のビジュアル（図表）を返す動作が主流です。これは、ユーザーの意図を深く理解して柔軟に答えるというより、決まった答えをそのまま提示するスタイルに近いと言えます。
つまり、チャートの“スナップショット”のように、「質問 → このグラフを見せる」という1対1の対応になっています。ユーザーがよく質問するであろうコンテンツに対して、LLMの"揺れ"を排除し、絞り込みを前提としたアウトプットを提供できることから、設定がうまく行ければ非常にパワフルな機能であると言えます。
「確認済みの回答」は、DAX などのセマンティッククエリ（＝ビジネスロジックや意味（セマンティクス）を理解したうえで実行されるクエリ。通常は DAX や MDX の生成に相当し、背後ではモデルの構造、Measure、説明文、リレーションシップなどを理解した AI により自動生成されます）によって実現されます。たとえば今回のケースでは、設定されたビジュアルが異なる期間でフィルター可能であれば、Copilot はその質問に正確に対応でき、「確認済みの回答」として提示される、という仕組みです。
しかし、より柔軟な会話や質問のニュアンスをくみ取るような動作（1対Nの対応）はまだ不十分のため、今後は、ユーザーの多様な質問に対して、意味や文脈を理解しながら適切な形で応答できるような、より高度で動的なふるまいが求められており、そのための開発が期待されています。
「確認済みの回答」のメリットは他にも以下のものが挙げられます。
- Copilot for Power BI では現在作成できない複合チャート（例：売上高と利益率の推移、在庫と利益率の推移など）も追加可能
→ユースケースとしては、「確認済みの回答」専用のレポートページを作成し、その中にエンドユーザーがよく質問する主要なビジュアルを配置するという方法があります。ただし、利用頻度が高い場合は、これらのビジュアルを通常のレポート内に組み込むのが最適でしょう - トリガーフレーズを含む場合、順序が逆になっても成功する（例: 在庫、利益率推移 → 利益率、在庫推移）
- Semantically similar (意味的に類似) したコンテンツであれば「確認済みの回答」となる
- 1つのページで「確認済みの回答」として設定したビジュアルは、そのページが削除されても継続される
また、特に「留意事項」で解説されているコンテンツを理解しておくと、「確認済みの回答」を正しく設定するうえで非常に役立ちます。ぜひ一度、内容を確認してみてください。特に重要なものとして、以下のものが挙げられます。
- レポートレベル メジャー*2はサポートされない
- 2025年7月時点でサポートされているストレージモードがImport, DirectQuery, Composite Modelの3つ（Direct Lakeは年内の予定）
- フィールド パラメーターは「確認済みの回答」では機能しない
- 「確認済みの回答」ごとに 5 ~ 7 個のトリガーフレーズを作ることが推奨される
- 「確認済みの回答」のサポート内容
- モデルごとに最大 250 件 の「確認済みの回答」
- 「確認済みの回答」ごとに最大 15 件 のトリガープロンプト
- トリガープロンプトの文字数上限は 500 文字
- ビジュアルサイズは、レポートビジュアルの制限と同様
AI への指示を追加
「LLMの揺れ」を最も抑止してくれる機能が「AI への指示を追加」となります。「データ スキーマを簡略化する」機能と同じく、2025年7月現在では、Power BI Desktop からしか設定を行うことができません。
「AI への指示を追加」は、自然言語で Copilot に指示を与えることで、通常のプロンプトでは得られにくい場合でも、より期待に近い結果へと導けるようにする機能です。
✏️プロンプト例1: 直近1年の売上高を表示して
「データに関する質問に回答（Answer questions about the data）」と「レポート ビジュアルの分析（Analyze report visuals）」のスキルを有効にした結果、1つの数値だけが返されました。回答の横には小さな脚注番号が表示されており、これをクリックすると、その回答がどの情報源に基づいているかを確認できます。これは「確認済みの回答」ではありませんが、「レポート ビジュアルの分析」スキルによって生成された出力です。
「AI への指示を追加」する前に、まずプロンプトの内容をよく検討することが重要です。今回のプロンプトについては、受け手によってさまざまな解釈が生じる可能性があります。たとえば、以下のようなパターンが考えられます。
- 年間合計の売上高（1つの集計値）
- 直近12ヵ月の売上高（各月ごとの数値、計12個）
- 上記1と2の両方を同時に表示したもの
AIが誤った回答をする理由の一つに、「人間が必要かつ十分で正確な情報を与えていないこと」が挙げられますが、まさにこのケースがそれに該当します。
そこで「AI への指示を追加」に以下の文言を追加します。
設定か完了したら、Copilot ペインを一度クリックして閉じ、再度アクティブにします。
ここで同じスキルを設定し、プロンプトを投げると、以下のアウトプットが返ってきました。
確かに「AI への指示を追加」で記述した通り、12ヵ月の推移及び合計金額になりました。
Tips: 「AI への指示を追加」の効果を確かめる場合、「新しいレポート ページの作成 (Create new report pages)」だけを除外してテストすると良い結果が得やすい（下図）
なお、「Answer questions about the data」スキルだけを有効にした状態で同じプロンプトを入力すると、以下のとおり結果を得ることができませんでした。理由はシンプルで、「Analyze report visuals」、すなわちレポート内のビジュアルを分析するプロセスを省いてしまったため、本来回答の根拠となるビジュアルからデータを抽出できなかったためです。こちらの詳細ついては、次回の「Standalone Copilot」である Chat with your Data (データとの会話）体験に詳しく解説します。
✏️プロンプト例2: summary current report (現在のレポートをサマライズして)
予想どおり、英語でプロンプトを入力すると、結果も英語で返ってきました。これ自体は非常に便利な挙動ですが、たとえば常に日本語でサマリーを返したい場合には、「AI への指示を追加」機能を使って、その条件をあらかじめ指定することで対応可能です。
指示: レポートのサマリーは、常に「日本語」を使用すること
確かに、日本語の形式でサマリーが作成されました。ただし注意すべき点として、その日本語サマリーは英語版の単なる翻訳ではなく、内容が大きく異なっている可能性が高いことを意識しておく必要があります。
ここからもう少し踏み込んでいきます。
✏️プロンプト例3: 日次売上の状況を教えて
日次売上という「存在しないデータ粒度（データは全て月次）」とあいまいなプロンプトにより、Copilot は意図しない結果を返すことになりました。もちろん、この結果は全く無意味である一方、ここではそもそも結果を返さないことが重要ですので、④をクリックし、「AI への指示を追加」に新たな条件を追加していきます。
指示: 「日次売上」や「日別売上」の場合、「このデータセットは月次データだり、日別データはありません。モデルビューから再度データを確認してください。不明な点があれば、モデルオーナーであるxyz@microsoft.comまでご連絡ください」と回答すること
もう一度プロンプトを投げてみたところ、期待どおりの結果が得られることを確認できました（※指示文章の中にタイポが存在したものの、それさえ正しく修正してアウトプットを返してくれました）。さらに注目すべき点として、ユーザーが次に何をすべきか迷わないよう、結果ダイアログの下に3つの追加提案が表示されており、細部までよく考えられていると感じました。
✏️プロンプト例4: 繁忙期の売上状況を教えて
まずまずの結果になった……と言いたいところですが、今回のプロンプトでは「繁忙期」がいつなのかを明示していなかったため、Copilot が独自に判断して回答しており、結果の信頼性に不安が残る内容となっています。
ここでのポイントは、以下の3点です：
- 繁忙期がいつかを明確に指定すること
- 直近の数値だけでなく、比較対象となる期間も含めること
- 単月のデータだけでなく、合計値などの集計情報も提示すること
これらはデータ分析に日常的に関わっている人にとってはごく自然な考え方ですが、比較分析は不可欠であり、AI をチューニングする立場の人にも、単に出力の品質を見るだけでなく、最低限の分析マインドが求められます。
AI が人間の判断を補完する以上、この部分は経験に基づく調整が必要であり、最終的には「慣れ」がものを言う場面も多くなるでしょう。
それでは以下のように、指示を追加します。
指示: 「繁忙期」は4月から6月を指します。この期間の売上推移と、前年同時期の売上推移をそれぞれ表示してください。あわせて、期間中の売上合計および前年比の差分（または増減率）も表示してください。
結果は以下の通り、より分かりやく示唆に富む回答を得ることができました。
通常であれば、ここで処理は完了します。しかし、アナリストの経験がある方であれば恐らく、「この数値は本当に正しいのか？」と疑問を持つはずです。たとえテスト環境であっても、数値の計算結果に対する信ぴょう性は非常に重要であり、それを確認する責任も生じます。そのため、ある程度の“サンプルチェック”を行い、データの品質を確認することが不可欠です。
本来であれば、SalesAmt や SalesAmt.PY というメジャーを用いて、下記のように結果を見ながら突合していくのが一般的ですが、実は今回のケースについては、それよりも効果的な方法があります。
その理由は、注釈1をクリックすることで、表示されているテーブルのデータソースが、すでにレポート内に存在するラインチャートに基づいていることが確認できる点にあります。レポート内のビジュアルは、Copilot が新たに DAX クエリを生成して導き出した結果とは異なり、すでにビジネスロジックが組み込まれたデータを可視化したものです。そのため、こうしたビジュアルをもとに表示された数値は、信ぴょう性が高いと判断することができます。
とはいえ、差分や増減率の計算、合計値の確認は、しっかり行う必要があります。特に Power BI では、個別レコードを1件ずつ加算した合計が、DAX によって算出された合計値と一致しないケースがあるため、細心の注意が求められます。
まとめ
今回は、Copilot Tooling をどのように活用すれば、より品質の高い結果を得られるのかについて、実際の活用事例をもとにご紹介しました。ご覧のとおり、従来の Copilot for Power BI と大きく異なる点は、Copilot に対してトレーニングを行い、より賢くカスタマイズできるようになったことです。
この設定は、次に紹介する CWYD（Chat with your Data） にも大きな影響を与えるものであり、次回は Fabric ポータルからチャット形式でインサイトを得られる CWYD について、詳しく解説していきたいと思います。
