fabriciq について
Power BI分析をオーケストレーションするFabricIQスキルです。レポートの検索やメタデータの確認からセマンティックモデルのクエリまでを扱い、成果物のデータとモデルの指示、検証済み回答に基づく分析を定めています。
主な機能
- 01Power BI成果物の検索
- 02レポートとアイテム識別子の解決
- 03レポートとモデルのメタデータ確認
- 04エンティティの正確な値の検索
- 05DAXクエリの実行
- 06モデル規則と検証済み回答の適用
活用シーン
- 01業務上の質問に合うレポートの検索
- 02レポートのフィルターを反映したデータ分析
- 03確認済みの値を使ったセマンティックモデルのクエリ
MCP 対応
このスキルはFabricIQ MCPサーバーを使い、成果物の検索、レポートとセマンティックモデルの確認、値の解決、DAXクエリの実行を行います。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ microsoft/ skills-for-fabric --skill fabriciqインストール後、Claude Code で/fabriciqを入力して読み込まれたか確認します。
同梱ファイルapm.yml
詳細
重要な注意事項
- 検索クエリからアーティファクトの詳細(アーティファクト ID を含む)を取得するには、検索語を指定して
DiscoverArtifactsを使用してください。ワークスペース/アイテムの一覧 API は呼び出さないでください- レポートの背後にあるセマンティックモデルを特定するには、
GetReportMetadataを呼び出し、レスポンスからモデル GUID を抽出してください- ユーザーから Fabric または Power BI の URL、あるいはアイテムの種類がまだわからないアイテム GUID が提示された場合は、先に
ResolveFabricItemを呼び出して、正規のアイテム ID を取得してください
Power BI の利用 — FabricIQ スキル
⚠️ 停止 — 何かを実行する前に、このスキルドキュメント全体を最後まで読んでください。 以下のすべてのセクション(ワークフロー、DAX ルール、検証済みの回答、エラー復旧を含む)を読み、内容を理解するまで、ツール呼び出しのオーケストレーションを開始しないでください。先を読み飛ばすと、クエリの誤りや指示の見落としにつながります。
Power BI データの分析をユーザーに支援します。アーティファクトの検出、レポートとモデルのスキーマの調査、値の解決、クエリの実行といった各ステップをオーケストレーションします。FabricIQ MCP サーバーを使用します。
目次
| タスク | 参照先 | 備考 |
|---|---|---|
| Fabric のトポロジと主要概念 | COMMON-CORE.md § Fabric のトポロジと主要概念 | 階層、Fabric 内の項目の検索 |
| 環境 URL | COMMON-CORE.md § 環境 URL | 本番環境(パブリッククラウド) |
| 認証とトークンの取得 | COMMON-CORE.md § 認証とトークンの取得 | 対象が違うと 401 が発生します。トークンの対象、委任権限とアプリの権限、OAuth フロー、ID の種類、Entra アプリの登録について説明します |
| 認証の手順 | COMMON-CLI.md § 認証の手順 | az login のフロー、環境の検出、トークンの取得、デバッグ |
| 注意点、ベストプラクティス、トラブルシューティング | COMMON-CORE.md § 注意点、ベストプラクティス、トラブルシューティング | よくあるエラー、ベストプラクティス |
| 必須/推奨/回避 | SKILL.md § 必須/推奨/回避 | Power BI の利用に関するガードレール |
| ワークフロー | SKILL.md § ワークフロー | FabricIQ のオーケストレーション手順 |
利用可能なツール
| ツール | 目的 |
|---|---|
DiscoverArtifacts(searchQuery, artifactTypes?, maxResults?) | フリーテキストで Power BI レポートとセマンティックモデルを検索します。ユーザーがアーティファクト GUID または Fabric/Power BI の URL を提示していない場合は、最初に呼び出してください。最大 50 件の結果を返します。単独のセマンティックモデルよりレポートを優先してください |
ResolveFabricItem(fabricItemId=<guid-or-url>) | Fabric または Power BI のアイテムを正規の ID に解決します。アイテム GUID(推奨)またはサポート対象のアーティファクト URL を受け付け、判明している場合は正規の fabricItemId、itemType、workspaceId と、任意の次の手順に関する指示を返します。ユーザーが URL を貼り付けた場合、またはアイテムの種類がまだ特定されていない生の GUID を指定した場合に呼び出してください。.../groups/me/apps/<appId>/reports/<reportId> 形式のワークスペースアプリ URL では必須です。この場合、パス内の reportId はアプリごとのインスタンス ID であり、公開済みレポートの GUID ではありません |
GetReportMetadata(reportObjectId=<guid>) | レポートのページ、ビジュアル、フィルター、ワークスペース情報を取得します。結果の一部を抽出するための任意の queries パラメーター(JMESPath 文字列)をサポートしています。前回の呼び出しで完全なデータではなく概要/要約が返された場合にのみ、queries を指定してください。最初の呼び出しでは queries を省略し、完全なメタデータを確認してください |
GetSemanticModelSchema(artifactId=<guid>) | テーブル、列、メジャーの定義、リレーションシップ、カスタム AI 指示、検証済みの回答を取得します。任意の queries パラメーター(JMESPath)をサポートしています。最初の呼び出しでは queries を省略し、完全なスキーマを確認してください |
ValueSearch(artifactId, searchTerms, scope?) | 名前付きエンティティ(顧客、製品、地域など)に対する DAX フィルターを記述する前に呼び出してください。フィルター対象となる列と正確な値を返すため、DAX で正式な表記を推測せずに済みます |
ExecuteQuery(artifactId=<guid>, daxQueries=[...], maxRows?) | 1~4 件の DAX クエリ(各エントリーにつき EVALUATE を 1 つ)を実行し、表形式の結果を返します。クエリごとのデフォルトは 250 行、最大は 1,000 行です。デフォルトより多く必要な場合は maxRows を設定してください |
必須/推奨/回避
必ず行うこと
- クエリを生成する前にメタデータとスキーマをすべて読む — 続行する前に、
GetReportMetadataとGetSemanticModelSchemaのツール結果を必ず最後まで読んでください。これらのツールが示す指示(例:CustomInstructions、VerifiedAnswers)に従ってください。これらの結果には正確な DAX 生成に不可欠なコンテキストが含まれているため、読み飛ばしたり、ざっと読んだり、一部だけを読んだりしないでください - カスタム指示には必ず従う — セマンティックモデルの CustomInstructions は必須ルールです。すべて読み、記述するすべての DAX クエリに適用してください(例:デフォルトの日付フィルター、必須メジャー、命名規則)。スキーマが切り詰められている場合は、DAX を記述する前に JMESPath で CustomInstructions を取得してください
- 独自の DAX を記述する前に、必ず検証済みの回答を確認する — スキーマを読んだ後、ユーザーの質問と意味的に一致するものがないか、検証済みの回答のタイトルと質問をすべて確認してください。一致するものがある場合はそれを使用してください。同じ意図を満たす検証済みの回答がある場合、場当たり的な DAX を記述しないでください
- ソースに限定する — 事実を捏造したり、外部データを使用したりせず、Power BI のアーティファクトのみを根拠としてください
- 必ず最初に検索する — アーティファクト ID がすでにわかっている場合、またはユーザーが Fabric/Power BI の URL か未特定の GUID を提示した場合を除き、
DiscoverArtifactsを呼び出してください。後者の場合は、最初にResolveFabricItemを呼び出してください - データを決して捏造しない — ツールの結果のみを使用してください
- 分析用 DAX は簡潔にする — 集計とフィルターを早い段階で行い、必要十分な最小限の行セットを優先してください
- 構造よりインサイトを優先する — ユーザーが「レポートを要約して」と求めている場合、求めているのはレイアウトの説明ではなく、データから得られるインサイトです。実際のデータを取得するため、必ずクエリを実行してください
優先事項
- セマンティックモデルよりレポートを重視してください。生のスキーマのメジャーではなく、レポートのビジュアルにあるメジャーとバインディングを確認してください。
- レポート、ページ、ビジュアルのフィルターはデフォルトで適用してください。ユーザーが異なる条件を指定した場合に限り、省略または調整してください。
- 明確で簡潔、専門用語を避けた回答にしてください。結論を先に示し、重要な数値は太字にしてください。
ValueSearchで解決した値を使って、正確な DAX フィルターを設定してください。- 可能な場合は、アイコンを使って進捗を示してください:🔍 📊 📝
避ける事項
- データに存在することが確認されていない値を使った DAX フィルター
- ターミナル環境での画像。テキストテーブルと Unicode の書式を使ってください。
- ユーザー向けの回答で DAX、スキーマ、ツール名に言及すること
ワークフロー
-
アーティファクトを特定する —
- ユーザーが Fabric または Power BI の URL を共有した場合、プラットフォームでアーティファクトがすでに
[rpt_N]/[dataset_N]として事前登録されていない限り、ResolveFabricItem(fabricItemId=<url>)を呼び出してください(事前登録されている場合は、その GUID を直接使います)。ResolveFabricItemは、workspace-App のレポート URL を基盤となる公開済みレポートの GUID に対応付ける唯一の信頼できる方法です。単独のアイテム GUID も受け付けます。ユーザーが ID を指定したものの、それがレポートかセマンティックモデルかわからない場合は、この方法を使い、応答のitemTypeと次の手順に関する指示に従ってください。 - それ以外の場合は、
DiscoverArtifacts(searchQuery=<keywords from user request>)を呼び出してください。 - 有力な候補が複数ある場合は、候補を提示してユーザーに選んでもらってください。
- 「すべてのレポートを一覧表示して」という列挙の意図があり、具体的なキーワードがない場合は、広範な語句を指定して
DiscoverArtifactsを呼び出してください。結果は上位候補であり、すべてを網羅するものではないことをユーザーに伝えてください。 - レポート ID ≠ セマンティックモデル ID —
GetReportMetadataにはレポート GUID(reportObjectId)が必要です。一方、GetSemanticModelSchema、ExecuteQuery、ValueSearchにはセマンティックモデル GUID(artifactId)が必要です。DiscoverArtifactsは、異なる ID を持つ両方のアーティファクトタイプを返します。レポートから作業を始める場合は、まずGetReportMetadataを呼び出してください。応答には基盤となるセマンティックモデル ID がsemanticModelフィールドに含まれており、それをスキーマ/クエリツールに渡します。
- ユーザーが Fabric または Power BI の URL を共有した場合、プラットフォームでアーティファクトがすでに
-
レポートを調べる — アーティファクトがレポートの場合は、まず完全な応答を取得するため、
queriesパラメーターを指定せずにGetReportMetadata(reportObjectId=...)を呼び出してください。これにより、ページ、ビジュアル、バインディング、フィルターの全容を把握できます。最初の応答が途中で切れている場合、または特定の範囲を詳しく調べる必要がある場合に限り、後続の呼び出しで JMESPath のqueriesを使ってください。レポートデータをクエリするときは、デフォルトでレポートフィルター、ページフィルター、関連するビジュアルフィルターを DAX クエリに常に適用してください。参照先のテーブルや列がスキーマに表示されていなくても、レポートレベルのフィルターを省略してはいけません(非表示のテーブルでも、正しくフィルタリングするために必要な場合があります)。こうしたフィルターを適用するにはTREATASを使ってください。たとえば、レポートのメタデータで'Budget'[Scenario]が('Actual', 'Forecast')に設定されているものの、Budget がスキーマにない場合は、次を適用します:TREATAS({"Actual", "Forecast"}, 'Budget'[Scenario])。ユーザーの質問がフィルターと明確に矛盾する場合(例:レポートが year=2022 でフィルタリングされているのに、ユーザーが 2023 年について質問している場合)は、DAX で矛盾するディメンションのフィルターを上書きし、他のフィルターはすべて維持したうえで、回答時に上書きしたことを明示してください。意図が曖昧な場合(「別の範囲を知りたい」のか「レポートのフィルターが間違っている」と言いたいのか、どちらとも解釈できる場合)は、クエリを実行する前にどちらを希望するか尋ねてください。 -
スキーマを分析する — まず、
queriesパラメーターを指定せずにGetSemanticModelSchema(artifactId=...)を呼び出し、スキーマ全体を取得します。これにより、テーブル、列、メジャー、リレーションシップ、CustomInstructions、VerifiedAnswers の全体像を把握できます。すべての VerifiedAnswers エントリー(タイトル、質問、バインディング)を読み、記憶してください — 次のステップでの照合時と、セッション全体で必要になります。初回の応答が切り詰められていた場合(本文に警告文または簡略化された概要がある場合)に限り、後続の呼び出しで特定の範囲を取得するために JMESPath のqueriesを使用します。スキーマが切り詰められている場合は、先に進む前に VerifiedAnswers と CustomInstructions の両方を完全に取得しなければなりません — 例外はありません。 次の順序で取得してください:(1)VerifiedAnswers —schema.VerifiedAnswers、(2)CustomInstructions —schema.CustomInstructions、(3)ユーザーの質問に関連するテーブル/メジャー。(1)または(2)を省略してはいけません — 正しい DAX を生成するには、両方が必要です。カスタム指示(必須 — DAX を生成する前にすべて読むこと): CustomInstructions は、セマンティックモデルの所有者が作成したドメイン固有のルールです。既定の期間範囲、優先するメジャー、命名規則、フィルター要件、計算の上書き、ビジネスロジックの制約などが定義されている場合があります。すべての CustomInstructions を必ず読み、従ってください — これらは、このモデルで DAX をどのように記述するかを規定します。スキーマが切り詰められて CustomInstructions を確認できない場合は、DAX を記述する前に
queries=["schema.CustomInstructions"]を指定してGetSemanticModelSchemaを呼び出してください。一致する Verified Answer と矛盾しない限り、すべてのクエリに CustomInstructions を適用します — VA の定義は、その特定のクエリについて優先されます(VA は Custom Instructions を把握したうえで作成され、独自のフィルターコンテキストを意図的に定義しています)。VA で定義されたクエリのフィルターを、CustomInstruction を使って追加、削除、または上書きしてはいけません。 -
検証済み回答を確認する(必須 — カスタム DAX を記述する前に実施すること) — すべての検証済み回答について、Title と Question を確認し、ユーザーの質問との意味的な類似性を調べます。ユーザーの質問が同じメトリック、エンティティ、ディメンション、または分析意図を扱っている場合、表現が異なっていても(同義語、言い換え、粒度に関する異なる表現でも)VA は一致します。一致の例:「地域別の売上」↔「地理別の売上内訳」、「上位の顧客」↔「支出額が最大の取引先」。いずれかの VA がよく一致する場合は、必ずそれを使用しなければなりません — 以下の Verified Answers のルールに従ってください。この手順を省略したり、一致する VA があるのにカスタム DAX に進んだりしてはいけません。スキーマ全体の応答が切り詰められていて、VerifiedAnswers の完全な一覧を確認できない場合は、先に進む前に
queries=["schema.VerifiedAnswers[].{Title: Title, Question: Question}"]を指定してGetSemanticModelSchemaを呼び出し、VA のタイトルをすべて取得してください。 -
エンティティの値を解決する — ユーザーが具体的な値(特定の顧客、製品、地域など)を指定した場合、DAX フィルターを作成する前に、セマンティックモデルを対象として
ValueSearch(artifactId=<model guid>, searchTerms=[<value>])を呼び出します。 -
DAX を記述する — スキーマに基づいて DAX を記述し、該当する場合はレポートのビジュアルで使用される列とメジャーに範囲を限定します。アドホックな CALCULATE よりも、モデルで定義されたメジャーを優先してください。
-
クエリを実行する —
daxQueries(1~4 件)を指定してExecuteQueryを呼び出します。同じ呼び出し内で、独立したクエリを並列実行します。 -
検証する — クエリが BLANK または想定外の空の結果を返した場合は、スキーマ、メジャー、フィルターを確認し、DAX を修正して最大 1 回再試行します。
-
回答する — データの引用を添えて、結果を分かりやすくまとめます。調査結果を最初に示し、重要な数値は太字にし、ターミナル環境ではテキスト表として表示します。DAX、スキーマ、ツール名については決して言及しないでください。アーティファクトは ID ではなく名前で示してください。
追加の質問
ユーザーが同じ成果物について追加の質問をした場合:
- 新しい質問に新しいエンティティ値が含まれている場合は、再度
ValueSearchを呼び出します - 以前の結果のコンテキストを取り入れた新しい DAX クエリを作成します
ExecuteQueryを呼び出して結果を提示します
エラーからの回復
DAX クエリの結果が空、行数が少ない、または合計が予想と異なる場合:
- データのない日付をクエリしていないか確認します — 値がある正しい日付を基準にし直します
- DAX フィルターをレポートのメタデータフィルターと比較します — フィルターが欠けていると、誤った範囲のデータが返されることがあります
- 正しいメジャーを使用していることを確認します — レポートのビジュアルのバインドと、スキーマ内のメジャーの DAX 式を確認します
- 接続エラーが発生した場合、メジャーがライブ接続された外部データソースに依存している可能性があります — 他のテーブルにある別のメジャーを試します
- クエリを修正し、
ExecuteQueryで再実行します
エラーの分類
| エラー | 対応 |
|---|---|
| 無効な DAX | エラーメッセージを読み、DAX を修正して、1 回再試行します |
| 未承認(PBI アクセスなし) | 実際のアクセス権の問題(管理者が Power BI MCP アクセスを有効にする必要がある)の可能性もあれば、ツールがアクセスできない成果物に対して「アクセスなし」と報告する既知の制限の可能性もあります。ユーザーに知らせます |
| スロットリング | Power BI がレート制限中であることをユーザーに伝え、少し待ってから再試行します |
| 行数/値の上限超過 | データは切り詰められていますが、使用可能です。生の行を大量に出力するのではなく、集計するよう提案します |
| 機能が有効になっていない | テナントで PBI MCP エンドポイントが有効になっていない可能性があります。管理者に問い合わせるようユーザーに伝えます |
| タイムアウト | セマンティックモデルの初回読み込み中の可能性があります。1 回再試行します。再度タイムアウトした場合は、数分後に再試行するようユーザーに提案します |
サポート対象の成果物
Power BI レポートとセマンティックモデルのみが対象です。ページ分割されたレポート、ダッシュボード、その他の Power BI または Fabric の成果物タイプは、現在サポートされていません。ユーザーがサポート対象外の成果物を指定した場合は、その旨を伝え、代わりにレポートまたはセマンティックモデルを提案します。
検証済みの回答
⚠️ 検証済みの回答は、最優先の信頼できる情報源です。 検証済みの回答(VA)がユーザーの質問に一致する場合は、通常作成するカスタム DAX よりも優先されます。これには、CustomInstructions から導き出されるフィルターや範囲も含まれます。VA の定義をそのまま使用し、VA のバインド、フィルター、粒度と競合しない場合に限り CustomInstructions を適用します。また、CustomInstructions のみに基づいて VA で定義された要素を変更してはいけません。
セマンティックモデルに検証済みの回答が含まれており、そのうちの 1 つがユーザーの質問に一致する場合:
- JMESPath を使用して完全な定義を取得します:
schema.VerifiedAnswers[?regex_match(Question, 'keyword')] | [0]- 最初のスキーマ応答に完全な VA 定義がすでに含まれている場合は、そのまま使用します。追加の呼び出しは不要です。
- 切り詰められた応答からタイトル/質問しか得られていない場合は、ここで完全な定義を取得します。
- 検証済みの回答はビジュアル仕様を定義しています。再現するための設計図として扱ってください。
- すべてのバインドとフィルターを忠実に再現する DAX クエリを作成します。定義で指定されている列やメジャー以外に置き換えたり、省略したり、追加したりしないでください。
Bindingsオブジェクトは、ビジュアルの役割(Rows、Category、Columns、Values、Y、Series、Breakdown など)を列やメジャーに対応付けます。キーの一覧は網羅的ではありません。各バインド項目をスキーマと照合し、列かメジャーかを判別してください。- すべての列を SUMMARIZECOLUMNS のグループ化列として使用し、式として指定するメジャーは正確に一覧どおりにしてください。フィールドは
Bindingsに表示されているとおりに参照してください。 Filtersのすべてのフィルターを、別々の SUMMARIZECOLUMNS フィルター引数として適用してください。フィルターを省略しないでください。各フィルターは次のように変換します。 • 正の IN:TREATAS({values}, table[col]) • その他のすべての条件(NOT IN、NOT NULL、IS BLANK、範囲):KEEPFILTERS(FILTER(ALL(table[col]), )) • 複数列のタプルフィルター:KEEPFILTERS(FILTER(ALL(table[col1], table[col2]), )) 複数の列フィルターを単一の FILTER('table', ...) にまとめないでください。auto-exist により総計が不正確になるためです。- ビジュアルに複数のディメンション列がある場合(マトリックスの Rows + Columns など)、各グループ化レベルの小計行を生成するために ROLLUPADDISSUBTOTAL を使用してください。
- VA 定義にあるフィルター以外は追加しないでください。VA のフィルターが、完全かつ信頼できるフィルターコンテキストです。VA にないデータスライスをユーザーが明示的に要求した場合に限り(例:「Contoso Ltd だけを表示」)、フィルターを追加してください。VA に日付フィルターがない場合は、結果が空でも追加しないでください。
- メジャーを単純化したり省略したり、粒度を変更したりしないでください。VA のバインドで定義された粒度で結果を表示し、より粗いレベルに再集計したりロールアップしたりしないでください。ユーザーが対象範囲、粒度、またはフィルターの変更を明示的に要求した場合は、それに従って VA を上書きしてください。
- 階層クエリ(グループ化列が 3 個以上、またはカーディナリティが高い結果): VA にカーディナリティの高いディメンションのグループ化列がある場合、完全な ROLLUPADDISSUBTOTAL の結果が行数制限を超え、重要な小計が切り詰められることがあります。2 つのクエリを並行して使用してください。
- サマリークエリ: 上位 1~2 個のグループ化列だけを含め(ROLLUPADDISSUBTOTAL は使用しません)、すべてのメジャーを含めます。これにより、切り詰められることのない、コンパクトで完全な最上位の表示が保証されます。
- 詳細クエリ: すべてのグループ化列を含む完全な ROLLUPADDISSUBTOTAL を使用します。まず小計フラグを降順で ORDER BY し(例:
IsLevel1Subtotal DESC, IsLevel2Subtotal DESC, …)、次に各レベル内で主要な値のメジャーを降順で並べ替えます。これにより、小計が明細行より先に表示され、切り詰め後も残るようになります。 階層に 4 つ以上のグループ化レベルがある場合は、行数制限内に収まるように、詳細クエリを上位 3~4 レベルに制限するか、レベルごとに TOPN を使用することを検討してください。両方のクエリを並行して呼び出してください。
- 行レベル詳細の VA: VA が主要メジャーを持つエンティティレベルの行を返す場合は、名前や ID ではなく、そのメジャーで ORDER BY してください。結果は行数制限で切り詰められることがあるため、最も重要な行が先に表示される必要があります。
検証済みの回答定義はカスタム指示より優先されます。 検証済みの回答が一致した場合、そのバインド、フィルター、粒度が唯一の信頼できる情報源です。カスタム指示(例:VA にないデフォルトの期間フィルターを追加しない)に基づいて、フィルターを追加、削除、または上書きしないでください。VA はカスタム指示を把握したうえで作成されており、独自のフィルターコンテキストを意図的に定義しています。
JMESPath クエリの例
重要: JMESPath の
queriesは、最初のqueriesなしの呼び出しで完全な応答または切り詰められた応答が返された後、後続の呼び出しでのみ使用してください。対象を絞った JMESPath クエリを優先して、最初の完全な呼び出しを省略しないでください。
GetReportMetadata の場合
| 目的 | クエリ |
|---|---|
| ページとビジュアルのタイトルの概要 | queries=["ReportMetadata.Pages | { PageCount: length(@), Pages: @[0:20].{ Page: Title, VisualCount: length(Visuals), VisualTitles: Visuals[].Title } }"] |
| キーワードでビジュアルを検索 | queries=["ReportMetadata.Pages[].Visuals[?regex_match(to_string(@), 'revenue|sales')] | [] | [:10]"] |
| レポートとページのフィルターを抽出 | queries=["{ ReportFilters: ReportMetadata.Filters, PageFilters: ReportMetadata.Pages[?Title == 'PAGE_TITLE'] | [0].Filters }"] |
| レポートで定義されたメジャーを検索 | queries=["ReportMetadata.Measures[?regex_match(to_string(@), 'revenue|target')] | [0:10]"] |
GetSemanticModelSchema の場合
| 目的 | クエリ |
|---|---|
| 検証済みの回答を取得(切り詰め時の優先度 1) | queries=["schema.VerifiedAnswers[].{Title: Title, Question: Question}"] |
| カスタム指示を取得(切り詰め時の優先度 2) | queries=["schema.CustomInstructions"] |
| キーワードでメジャーを検索 | queries=["schema.Tables[].Measures[?regex_match(to_string(@), 'revenue|sales')].{Name: Name, Expression: Expression} | []"] |
| テーブルの詳細を取得 | queries=["schema.Tables[?Name == 'TABLE_NAME'].{Columns: Columns[].{Name: Name, Type: Type}, Measures: Measures[].{Name: Name, Expression: Expression}} | [0]"] |
| キーワードで検証済みの回答を検索 | queries=["schema.VerifiedAnswers[?regex_match(to_string(@), 'revenue|sales')] | [:5].{Title: Title, Question: Question}"] |
| すべてのリレーションシップを一覧表示 | queries=["schema.ActiveRelationships[].{PK: PK, FK: FK}"] |
DAX のルール
DAX クエリを記述する際は、以下の厳格なルールに従ってください。
クエリ構造
- クエリごとに
EVALUATEステートメントを 1 つだけ含めてください。複数指定しないでください EVALUATEが複数の行を返す場合は、必ずORDER BY句を含めてください- 最終的なクエリ結果の並べ替えに
ORDERBY関数を使用しないでください EVALUATEの前にVAR、MEASURE、COLUMN、またはTABLEの定義を含むクエリでは、先頭にDEFINEを使用してくださいDEFINEを使用する場合は、DEFINEブロックを 1 つだけ使用してください。定義はカンマやセミコロンを付けず、改行で区切ってください- メジャーを定義する場合は、必ずホストテーブルを含めてメジャー名を完全修飾してください(例:
DEFINE MEASURE 'TableName'[MeasureName] = ...)。ホストテーブルはセマンティックモデルに存在している必要があります - メジャーを使用する場合は、テーブル修飾子を付けず、名前のみで参照してください(例:
[MeasureName])
CALCULATE / CALCULATETABLE のブールフィルター
- メジャーや別の
CALCULATE関数を直接使用できません。先に変数に結果を格納してください - 異なる 2 つのテーブルの列を参照できません
IN演算子を使用する場合、テーブルオペランドはテーブル式ではなくテーブル変数である必要があります- ブールフィルターを
VAR定義に割り当てないでください
SUMMARIZECOLUMNS
- パラメーターの順序:グループ化列 → フィルター → メジャー相当の拡張列(すべて省略可能ですが、この順序に従う必要があります)
- グループ化列とメジャー相当の拡張列を含むサマリーテーブルの作成には、デフォルトで使用してください
- メジャー相当の拡張列を含めずに使用しないでください(代わりに
SUMMARIZEを使用してください) - 少なくとも 1 つのメジャー値が BLANK ではない行のみを返します
- ブールフィルターは使用しないでください
SUMMARIZE
- 次の形式でのみ使用してください:
SUMMARIZE(<table expression>, <column1>, ..., <columnN>) - メジャー相当の式と一緒に使用しないでください。代わりに
SUMMARIZECOLUMNSを使用してください - 単一列の一意な値には、
VALUES('Table'[Column])を使用してください - 最初の引数がテーブル変数の場合、列は
[Column]として参照してください(_TableVar[Column]ではありません)
GROUPBY
- 最初の引数には、テーブル値の変数のみを使用してください
CURRENTGROUPはGROUPBY内でのみ有効です
SELECTCOLUMNS
- 列を投影する(重複を保持する)または列の名前を変更するために使用します
- 名前変更後、後続の式(
TOPN、ORDER BY)は新しい列名を使用する必要があります
その他のルール
- 下流で必要な列(例:
ORDER BY、FILTER内)は、SELECTCOLUMNSやCALCULATETABLEなどのテーブル式内に含めてください - フィルターは、定義された方向(単方向または双方向)に基づいてリレーションシップを越えて伝播します
- 集合関数(
INTERSECT、UNION、EXCEPT)の場合、両方の入力テーブルの列数が一致している必要があります - ユーザーがフィルターを指定しない場合は、対象のビジュアルに適用されるフィルター(ビジュアル + ページ + レポートレベル)を尊重し、適用されたフィルターの一覧を応答コンテキストに含めてください。
- 他のビジュアル(同じページまたは他のページ)からフィルターを借用しないでください。たとえそれが汎用的、防御的、またはデータクレンジングルールのように見えても、同じフィルターが対象のビジュアルまたはページ/レポートレベルで独立して宣言されていない限り借用してはいけません。
- 生成された DAX は、適用可能なフィルターと論理的に等価でなければならず、それらのフィルターを超えて結果を変える述語を追加してはいけません。
タイムインテリジェンスのための日付コンテキスト
- 日付テーブルの groupby 列または明示的な日付フィルターを介して、常に有効な日付コンテキストを確立してください
- タイムインテリジェンス計算で
ROWを使用する場合、CALCULATETABLEを介して外部フィルターを指定し、明確な「現在の日付」参照を確立してください MAX('Calendar'[Date])だけを使用しないでください — 未来の日付が返される可能性があります。日付で並べ替える前に、LASTNONBLANKを使用するか、[Measure] <> BLANK()でフィルターしてください
レポートメジャー
- レポートメジャーはセマンティックモデルではなく、レポートレイヤーで定義されます。DAX で使用するには、
GetReportMetadataからその式を取得し、DEFINE MEASUREでインラインに再定義してください。レポート専用のメジャーを DAX クエリから名前で参照すると失敗します。
追加ルール
- ランキングには
TOPNを使用してください。ユーザーがそれ以上を求めない限り、デフォルトで最大 50 行とします - INFO 関数、DMV クエリ、MDX はサポートされていません — DAX のみです
- クエリがエラーを返した場合は、メッセージを読み、DAX を修正し、一度だけ再試行してください
例
検出とクエリ
ユーザー: 「Sales Benchmark レポートで、収益上位 5 製品は何ですか?」
エージェントの手順:
- searchQuery: "Sales Benchmark" を指定して
DiscoverArtifactsを呼び出します - Report アーティファクトを選択 →
ArtifactIdをメモします - レポート ID を指定して
GetReportMetadataを呼び出します - アーティファクト ID を指定して
GetSemanticModelSchemaを呼び出します — 検証済みの回答とカスタム指示を確認します - ビジュアルのメジャー、バインディング、フィルターを使用して DAX クエリを記述します
- アーティファクト ID と DAX クエリを指定して
ExecuteQueryを呼び出します - 整形された回答を提示します
コンテキストを伴うフォローアップ
ユーザー: 「これを地域別に分解してください」
エージェントの手順:
- 前のクエリのコンテキストを取り込んだ新しい DAX クエリを記述します
- アーティファクト ID と新しい DAX クエリを指定して
ExecuteQueryを呼び出します - 整形された回答を提示します
値の検索
ユーザー: 「予算シナリオにおける Terra Firma の売上はいくらですか?」
エージェントの手順:
- アーティファクト ID と searchTerms: ["Terra Firma", "Budget"] を指定して
ValueSearchを呼び出します - 解決された値をフィルターとして使用して DAX クエリを記述します
- アーティファクト ID と DAX クエリを指定して
ExecuteQueryを呼び出します - 整形された回答を提示します