この検証の目的

本記事の目的は、次の2つです。

目的1

Fabricライセンスなしで、Power BIデータのAI活用が実用レベルの精度に届くのかを確かめる

Power BI / Fabricのデータを活用できるAI機能として、「Copilot in Power BI」や「データエージェント」がありますが、これには有償のFabric容量(F SKU)が必要です。

一方で、Power BIライセンスのみで使えるAI活用の手段もいくつかあります。

「F SKUは購入していないが、AI活用は始めたい」という組織にとって、これらの手段がどこまで実用になるのかは重要です。

本記事では、正解をあらかじめ仕込んだデータに対する検証で、その到達精度を定量的に確かめます。

目的2

Power BIライセンスのみで使えるAI手段のうち、どれが最もコストパフォーマンスに優れるかを確かめる

同じ「Power BIライセンスのみで使える」手段でも、必要なライセンス(M365 Copilotの有無)、実行ごとのクレジット消費、構築・保守の手間はそれぞれ異なります。

本記事では、同じタスクを同じ条件で3方式に解かせ、到達精度だけでなく、実行コスト・準備の手間まで含めた「どれを選ぶべきか」の判断材料を示します。

Power BIをAIで利用する方法

「Power BIのデータをAIでも活用したい!」と一口に言っても、2026年現在、Microsoftの機能で実現できる選択肢は色々あります。

Power BIのレポート画面に組み込まれたCopilotから、Microsoft 365 CopilotからPower BIデータに質問できるもの、さらにはCopilot StudioからPower BIに接続する仕組みまで、さまざまな方法でAI活用ができます。

これらの機能を検討するとき、最初にぶつかるのがライセンスの壁です。

そのためまず、主要な機能を一覧表に整理してみました。

Power BI / Fabricで使えるAI機能一覧(2026年7月時点)

機能どこで使うか必要なライセンス・容量状態できること
Power BIのCopilotPower BI サービス / デスクトップFabric容量(F2以上)またはPremium容量(P1以上)GA(一部はプレビュー)レポート作成支援、レポートへの質問
スタンドアロンCopilotPower BI サービスFabric容量(F2以上)またはPremium容量(P1以上)プレビュー組織内のレポート・セマンティックモデル等を横断して質問
データエージェントFabric、Microsoft 365 Copilot、Copilot Studio等Fabric容量(F2以上)GA複数のFabricアイテムを横断するQ&Aエージェントを構築
Fabric IQ プラグイン(Cowork)Microsoft 365 Copilot の CoworkMicrosoft 365 Copilotライセンス+Coworkの従量課金設定CoworkはGA、Fabric IQプラグインはプレビューCoworkからPower BIレポートに質問し、文書作成等の後工程に繋げる
Power BI MCPサーバー(リモート)任意のMCPクライアント(Copilot Studio、Visual Studio Code 等)Power BI Pro以上+利用ツールのライセンスプレビューAIエージェントがセマンティックモデルのメタデータ取得・DAXクエリの生成・実行を行うための共通接続口
CopilotのストーリービジュアルPower BIレポート上(説明ビジュアル)有料のFabric容量(F SKU)GAレポート内に、Copilotで作成した説明文のビジュアルを埋め込む

有料のFabric容量による違い

Power BIデータをAI活用できる手段として、有料のFabric容量があるかで、利用できる範囲が変わります。

有料のFabric容量(F SKU)による違い

有料Fabric容量が必須の機能

  • Power BIのCopilot
  • スタンドアロンCopilot
  • データエージェント
  • Copilotのストーリービジュアル

Power BIライセンスのみで使える機能

  • Fabric IQプラグイン(Cowork)
  • Power BI MCPサーバー(リモート)

Power BIを既に活用している組織の中でも、Fabricのライセンスまでは持っていないというケースは多いです。

こういった「Power BIライセンスだけを持っている組織」でも、Power BIのデータをAIで活用したい!という場合に使える方法について、比較・検証してみました。

今回の前提条件

本記事の検証は、次の環境で行います。

前提条件
  • 有償Fabric容量(F SKU)なし
    Power BIコンテンツはProワークスペースの範囲で運用
  • Copilot in Power BI・データエージェントは対象外(使えないため)
  • M365 Copilotライセンスあり(Cowork、Copilot Studio検証用)
  • Coworkが利用できる環境
  • テナント管理者権限あり(プレビュー機能のテナント設定を自分で変更できる)

Microsoft Fabric(F SKU)ライセンスは持っていないが、Power BI Pro以上のライセンスを持っている組織という前提になります。

比較する3つの方式

この前提で使える選択肢から、今回は次の3方式を比較します。

  1. Copilot Studio × Power BI MCP
    Copilot Studioのエージェントに、Power BI MCPサーバーをツールとして接続する構成。
    エージェントがモデルのメタデータを参照しながら、自分でDAXクエリを組み立てて実行します。
  2. Cowork × Fabric IQプラグイン
    Microsoft 365 CopilotのCoworkから、Fabric IQプラグイン経由でPower BIに質問する構成。
    セマンティックモデル等にDAXクエリを実行します。
  3. Copilot Studio × DAXクエリ実行(ワークフロー)
    Copilot Studioからワークフロー(旧エージェントフロー)を呼び出し、動的にDAXクエリを作成し、実行する構成。

③については、今回私が考えて追加した構成です。

①のMCPも②のFabric IQも、内部でやっていることは主に、「DAXクエリを実行してデータを取得する」ことなので、Copilot Studioからワークフローを呼び出し、「DAXクエリ実行」を使い、動的にDAXクエリを作成し、実行することで、同じことができるのではないか?と思ったためです。

この方法であれば、Power BI MCPやCoworkの設定が不要になるため、今回の比較対象に加えました。

ツールから、「DAXクエリ実行」の方も試したのですが、上手くPower BIのセマンティックモデルに接続できなかったため、今回はワークフローの方で検証しました。

結果のサマリー

詳細は後の章で見ていきますが、結論を先に書きます。

  • 3方式すべてが明細レベルでの分析まで到達。有償Fabric容量(F SKU)がなくても、原因調査は実用レベルで機能します。
  • 到達率は3方式でほぼ同じ。追加質問なしで、詳細分析まで達成したのは、どの方式も9回中7回です。
  • 差が出たのは精度ではなく、コストと構築の手間。同じ原因調査タスクで、クレジット消費には5倍前後の開きがありました。
方式原因調査の到達コスト向いている使い方
①Copilot Studio×MCP詳細分析まで可能〇 最も安い継続運用でコストを抑えたい
②Cowork×Fabric IQ詳細分析まで可能△ やや高い分析から資料作成まで繋げたい
③Copilot Studio×DAXクエリ詳細分析まで可能〇 安いアプリ登録が簡単にできない

仮説と検証方法

今回の検証で、どんな質問を、どんなデータに、どんなルールで投げるのかを決めました。

3.1 検証タスクの設計 — なぜ「原因調査」を中心にするのか

単純に、「今月の売上トップ5は?」のような単純な質問の場合、そもそもPower BIレポートを見ればよく、AIを活用するメリットは少ないと思います。

またAI活用方法の差が出るのは、答えに至る経路が事前に決められない、より深い分析が必要な質問だと思います。

たとえば「先月、支出が増えた原因は?」という質問は、カテゴリ別に分解し、怪しい箇所を時系列で見て、明細まで掘るという反復的なドリルダウンが必要で、何回・どの軸で掘るかはデータを見ながらでないと決まりません。

本記事の検証タスクは、次の3種類で設計しました。

3.2 質問セット

①単純な集計

正解が一意に決まる質問(ウォームアップ)。

接続確認を兼ねつつ、「この種の質問なら3方式に差が出ない」ことを確認します。

Q1: 2026年6月の支出合計はいくらですか。

Q2: 直近3ヶ月(2026年5月~7月)で支出が増えているカテゴリ(中項目)はありますか。

②原因調査

反復ドリルダウンが必要な質問。

本記事のメイン実験で、以下いずれかの質問に対する回答を、後述のL1〜L3尺度で採点します。

Q3: 2026年7月の支出が、前月(6月)より増えています。原因を調べてください。

Q4: 2026年7月の収支が、前月(6月)より悪化しています。原因を調べてください。

③予測・提案

正解が存在しない、予測・提案をしてもらう質問です。

分析結果を「次のアクション」に変換できるかを見ます。

Q5: 毎月の支出のうち、見直すべき項目はどれですか。
家計データに基づいて優先順位と削減余地の金額を提案してください

Q6: 5年後に資産を2,000万円にしたいです。
現在のペースが続いた場合の5年後の資産額を踏まえて、収入・支出の何をどれだけ見直すべきか提案してください。
計算の前提と根拠も示してください。

これは採点基準が異なる点に注意してください。

予測や提案に「唯一の正解」はないため、正しさそのものではなく、以下で評価します。

  1. 計算の根拠が実データに接地しているか(検算可能な形で示されているか)
  2. データに存在しない事実を語っていないか(幻覚の有無)

3.3 (原因調査)の評価基準詳細

「原因調査」の到達度は、次の3段階で採点します。

レベル 到達内容
L1大項目レベルの特定「食費が増えています」
L2中項目レベルの特定「外食が増えています」
L3明細レベルの特定「7/30のレストラン1.5万円と7/31のホテルディナー2.5万円が主因です」

また、到達レベルとは別に、幻覚(データに存在しない原因を事実として語る)があった場合は、到達レベルにかかわらず失敗と数えます。

「もっともらしいが間違っている回答」は「浅いが正しい回答」より問題です。

3.4 検証データ: 異常を仕込んだ家計簿モデル

検証には、家計簿分析シリーズで使っているセマンティックモデル(fact_Cashflow / fact_Assets+日付・口座・カテゴリのディメンション)を使います。

【Power BI入門】家計簿分析レポート#1 ~なぜ家計簿をPower BIで分析するのか?~このシリーズでは、家計簿アプリのサンプルデータを使って、Power BIでレポートをゼロから作り上げていきます。 第1回目のこの記事では、このシリーズの全体の流れと、そもそもなぜPower BIで家計簿を分析するのか?についてお話しします。...

異常は、以下の3パターン用意しました。

パターン仕込んだ異常正解(L3)ねらい
A: 支出増(メイン)7月の支出を約+5.3万円に。
うち約4万円は月末2日間の外食2件に集中、残り約1.3万円は小口の増加としてコンビニ・日用品・交通費に分散
7/30「レストラン(誕生日会)」15,000円+7/31「ホテルディナー」25,000円基本のドリルダウン能力を測る
B: 重複記帳7月に保育園費(約4.2万円)とお小遣い(夫)(1.5万円)の完全重複行を注入(日付・内容・金額が同一でIDのみ異なる)2件の二重記帳の特定集計では「教育費が倍増」としか見えない。明細比較まで掘らないと見つけられない。
C: 収入側の欠落支出は6月とほぼ同水準のまま、7月の給与(妻)約20.7万円だけを欠落収入側(給与の未記帳)の特定「支出を調べる」という思い込みで解けない問題。
6月には賞与があるため、このノイズに隠れた給与の未記帳まで特定できるか見る。

実際に検証に使ったデータは以下です。

3.5 仮説

各方式がどう振る舞うかの仮説を立てました。

検証内容①Copilot Studio×MCP②Cowork×Fabric IQ ③Copilot Studio×DAXクエリ
集計質問
(Q1〜Q2)
原因調査:
(A:外食支出増)
L3到達L2〜L3到達L1〜L2止まり
原因調査:
(B:重複記帳)
L3到達L2止まり未到達〜L1
原因調査:
(C:収入欠落)
L3到達L3到達未到達〜L1
応用質問
(Q5〜Q6)
未到達〜L1
再現性(同一質問×3回)到達レベル・経路が揺れる到達レベル・経路が揺れる比較的安定

予想の根拠は、以下です。

①は「メタデータ参照→DAX生成→実行→結果を見て次のクエリ」という反復ループエラー時の自己修正を持ち、②も同様の構造に加えて推論モデルと後工程(文書化・提案)の強みを持ちます。

一方③は、動的にDAXを生成できるものの、複数回反復してDAXクエリ実行→分析をするのは難しいのではないかと考えました。

このため、答えに至る経路を事前に決められない問題(原因調査、特にパターンB・C)ほど大きな差になって現れると考えます。

3.6 検証のルール

各方式での比較を公平にするため、次のルールを設定します。

検証ルール
  • 同一モデル・同一データ・同一質問文
    質問は全方式で一字一句同じものを使う。
  • AIモデルは、Claude Sonnet 5を利用
  • 指示文・プロンプトは事前凍結
    ①のエージェント指示文と③のDAX生成プロンプトは、異常データでの実行前に確定し、結果を見てからの改良はしない。
    ①の指示文には分析手順を書かない(自力で反復到達できるかを検証するため)
  • 各実行は新規会話で開始
    前回の探索結果がコンテキストに残ると、2回目以降の実行が汚染されるため
  • 各方式 × 各パターン3回実行
    1回の成功/失敗で結論しない(再現性測定)

3.7 測定項目

各実行について、次を記録します。

  • 到達レベル(L1〜L3)
  • 正解一致(金額・明細の正確さ)
  • 幻覚の有無
  • コスト(①③はCopilot Credits、②はCoworkのクレジット消費)

「到達できるか」だけでなく「いくらで到達できるか」のコストも合わせて見ていきます。

それでは、検証結果を見ていきましょう。

各構成の詳細設定

①Copilot Studio × Power BI MCP

Copilot Studioから、Power BI MCPに接続する構成です。

1.Copilot Studioのツールで、Power BI MCPを追加(Azureでのアプリ登録、リダイレクトURL登録が必要)

2.Copilot Studioで以下の指示文を設定。

あなたは家計分析アシスタントです。

# 役割
- 接続されたPower BIのツールを使って、家計簿セマンティックモデルのデータを実際に調査し、質問に答えてください。
- 必要に応じて、ツールを複数回呼び出して調査を進めて構いません。

# 回答のルール
- 回答は必ず実行したクエリの結果に基づいてください。データで確認できないことを、事実として述べてはいけません。
- 回答には、結論と、その根拠となる具体的な数値(金額・件数・日付など)を含めてください。
- データから原因や答えが特定できない場合は、どこまで特定できて、何が分からなかったかを正直に述べてください。
- 日本語で回答してください。

# 対象
- モデル名: <モデル名>(ワークスペース: <ワークスペース名を記載>)
- セマンティックモデル ID: <セマンティックモデルモデルIDを記載>
- ツール呼び出しでは常にこの ID を使用し、ユーザーに ID を尋ねないこと。

②Cowork × Fabric IQプラグイン

Microsoft 365 CopilotのCoworkで、Fabric IQプラグインを使い、作業コンテンツから、対象のレポートを追加して質問します。

Fabric IQプラグインの利用設定をしていれば、特に構築などはせずにそのまま使えます。

③Copilot Studio × DAXクエリ実行(ワークフロー)

Copilot Studioで、ワークフローを呼び出し、Power BIセマンティックモデルに対して、DAXクエリを実行する構成です。

1.Copilot Studioで、ツールからワークフローを追加します。

2.引数として、動的に生成したDAXクエリを実行し、実行結果を返り値として受け取るワークフローを作成します。

3.Copilot Studioで以下の指示文を設定します。

あなたは家計分析アシスタントです。

# 役割
- ツール「DAXクエリ実行」(ワークフロー)を使って、家計簿セマンティックモデルのデータを実際に調査し、質問に答えてください。
- 必要に応じて、ツールを複数回呼び出して調査を進めて構いません。前の実行結果を踏まえて、次のクエリを組み立ててください。
- ツールの戻り値が「DAXエラー:」で始まる場合は、エラー内容を確認してクエリを修正し、再実行してください。

# ツールの使い方
- あなた自身がDAXクエリを組み立て、ツールの引数 daxQuery に渡します。クエリは EVALUATE で始まる完全なクエリを1つだけ渡してください。
- 戻り値は、クエリ結果の行をJSON文字列にしたものです。これを読み取って回答に使ってください。
- 結果が大きくなりすぎないよう、明細を取得する場合は TOPN やフィルタで行数を絞ってください。

# データモデルの構造
1.fact_Cashflow(収支明細): 日付, 内容, 金額(円), 保有金融機関, 大項目, 中項目, 収支
金額(円): 整数。支出は負、収入は正
収支: "支出" または "収入"(テキスト)。貯蓄・投資への振替は収支データに含まれない
2.fact_Assets(資産): 口座名, 評価額(円), 評価損益(円), 資産種別, 保有金融機関
3.dim_Date(日付): Date, Year, YearNo, MonthNo, YearMonth(例: "2026/06")
4.dim_Account(口座): 保有金融機関, 口座種別
5.dim_Category(カテゴリ): 中項目, 大項目, 費用種別
6.リレーションシップ: dim_Date[Date] 1-* fact_Cashflow[日付] / dim_Account[保有金融機関] 1-* fact_Cashflow[保有金融機関] / dim_Category[中項目] 1-* fact_Cashflow[中項目] / dim_Account[保有金融機関] 1-* fact_Assets[保有金融機関]
列の参照は 'テーブル名'[列名] の形式で、大文字小文字を正確に記述してください

# 回答のルール
- 回答は必ず実行したクエリの結果に基づいてください。データで確認できないことを、事実として述べてはいけません。
- 回答には、結論と、その根拠となる具体的な数値(金額・件数・日付など)を含めてください。
- データから原因や答えが特定できない場合は、どこまで特定できて、何が分からなかったかを正直に述べてください。
- 日本語で回答してください。

検証結果

到達レベル一覧

それぞれの手法につき、各検証内容を3回ずつ実施した結果です。

検証内容①Copilot Studio×MCP②Cowork×Fabric IQ③Copilot Studio×DAXクエリ
単純な集計(Q1・Q2)
原因調査A:支出増(Q3)L2→L3 / L3 / L3L3 / L2→L3 / L3L3 / L3 / L3
原因調査B:重複記帳(Q3)L2 / L3 / L3L3 / L2→L3 / L3L3 / L3 / L3
原因調査C:収入欠落(Q4)L3 / L3 / L3L3 / L3 / L3L3 / L2→L3 / L2→L3
予測・提案(Q5:見直し提案)接地〇・幻覚なし(すべて)接地〇・幻覚なし(すべて)接地〇・幻覚なし(すべて)(一部の派生計算に誤り)
予測・提案(Q6:5年後の資産)接地〇・幻覚なし(すべて)接地〇・幻覚あり(1回)(存在しないデータへの言及あり)接地〇・幻覚あり(2回)(存在しないデータの言及あり)

到達率と幻覚の発生

原因調査(パターンA・B・C × 3回=9回)を方式ごとに集計すると、次のようになりました。

方式初回回答でL3到達追加質問を含む最終到達幻覚(予測・提案を含む全実行)
①Copilot Studio×MCP7 / 98 / 90件
②Cowork×Fabric IQ7 / 99 / 91件(Q6)
③Copilot Studio×DAXクエリ7 / 99 / 92件(Q6)

初回到達率は、3方式ともまったく同じ7/9でした。

一方でつまずく場所は方式ごとに違いました。①と②はパターンA・Bで1回ずつ取りこぼし、③はA・Bを3回とも一発で当てた代わりに、Cで2回取りこぼしています。

最後まで到達できなかった実行は1件だけで、それは①(MCP)のパターンB・1回目でした。
支出が増えた主要因(教育費)までは特定したものの、それが同一明細の二重記帳であるところまでは辿り着けませんでした。
事前の仮説では①が最も強いと予想していたので、これは意外な結果です。

また、原因調査では3方式とも幻覚が出なかった一方、予測・提案(Q6)では幻覚が出ました。特に③は3回中2回、収入の内訳について実データにない記述が混ざりました。
「原因調査は任せられるが、提案の数字はレビューが必要」という線引きになります。

コスト(暫定値)

各方式の、1回の質問あたりのクレジット消費は次のとおりです。

Microsoft 365 Copilotの有償ライセンスを持っている場合、()内の数値になります。

方式単純な集計原因調査予測・提案
①Copilot Studio×MCP27(0)26(0)97(0)
②Cowork×Fabric IQ115144136
③Copilot Studio×DAXクエリ9(0)29(1)58(4)

原因調査を円換算すると(1クレジット=1.6円とする)、1つの質問あたり、①が約42円、 ②が約230円、③が約46円規模となり、到達レベルがほぼ同じであるにもかかわらず、コストに差が出ました

②は推論と後工程の強さを持つ一方、1回の調査あたりの単価はやや高くなります。

考察

ワークフローのDAXクエリ構成では、指示文が大事

③でもエージェントは、月次比較 → 大項目で分解 → 中項目で分解 → 明細を取得という手順を、自分でDAXクエリを組み立てながら反復していたため、他の構成と比較してもあまり変わらない精度は出ました。

一方でこの構成では、指示文に適切なセマンティックモデルの設計を書いておくことが重要だと分かりました。

指示文に、セマンティックモデルの情報を正しく入力しないと、何度もDAXクエリの実行で失敗してしまうためです。

また、Microsoft 365 Copilotライセンスを持っている場合、この構成なら請求額は0円かと思いましたが、ワークフローの実行に請求額がかかるので注意です。

Power BI MCPのアプリ登録ができるなら、Copilot Studio × Power BI MCPの構成が最も安価になります。

幻覚は「原因調査」ではなく「提案」で出る

原因調査(27実行)では3方式とも幻覚が出ませんでしたが、予測・提案では②で1件、③で2件発生しました。

原因調査の回答はクエリ結果とほぼ1対1で対応するため幻覚が入る隙間が小さく、予測・提案は派生計算と将来の予測が入るため、数字のつなぎ目で崩れるのかもしれません。

実務上は、原因調査は任せられるが、提案の数字はレビュー前提と考えるべきです。

提案を定型業務にするなら、試算ロジックはセマンティックモデル側のメジャーとして固定し、AIには結果の解釈だけを任せるか、AIに提案の根拠の計算まで必ず出力させるのがよいでしょう。

コスト差はCoworkが高め

到達レベルが横並びの一方、②は①③に比べてクレジット消費がやや高くなりました。

ただし今回は、Power BIのデータ分析をチャットで回答してもらうまでの実行にとどまっています。

Coworkの場合は、その後のアウトプット(Teams共有や、ドキュメント作成等)まで実行する活用方法がメインとなるかと思うので、単純なコスト比較はできないかもしれません。

妥当性への脅威

今回の検証の妥当性への脅威をあげておきます。

  • 試行回数が少ない:原因調査は合計27実行で、統計的な優劣を主張できる回数ではありません。
  • モデルが小さい:ファクトテーブル1つ+ディメンションテーブル4つの規模です。特に③はモデル構造を指示文に手書きしているため、この規模だから成立している構成です。
  • プレビュー機能を含む:仕様変更で結果が変わりえます。
  • AIモデルはClaude Sonnet 5固定:結論の多くがエージェント側の能力に帰着したため、モデルを変えると結果も変わりえます。

選定基準

精度で差がつかなかったため、選定は精度以外の軸で行うことになります。

判断軸①Power BI MCP②Cowork③動的DAX
初期構築の手間△ Azureでのアプリ登録が必要△ テナント設定と従量課金の有効化◎ Copilot Studioだけで完結
必要ライセンスCopilot Studio / M365 CopilotM365 Copilot+Coworkの従量課金Copilot Studio / M365 Copilot
1調査あたりのコスト◎ 最も小さい△ 5倍前後〇 中位
想定外の原因への気づき△ 指示文に書いた範囲に依存
モデル規模へのスケール◎ メタデータを自動取得◎ メタデータを自動取得△ 構造を指示文に手書き=保守が発生
後工程(文書化・通知等)〇 ワークフローやツールで実装◎ そのまま資料作成に繋げられる〇 ワークフローやツールで実装

用途別の選び方

各ツールは、以下の基準で選ぶのが良いかと思います。

  1. Copilot Studioが使えて、Power BI MCPのアプリ登録ができる場合
    ➡①Copilot Studio × Power BI MCP(コストも最小限)
  2. Copilot Studioは使えるが、アプリ登録ができない現場で使いたい場合
    ➡③Copilot Studio × 動的DAXクエリ実行(コストは中程度)
  3. 資料作成など、Copilot Studioで難しい後工程に繋げたい場合
    ➡②Cowork × Fabric IQプラグイン

共通の注意として、どの方式も、数値の正確性が問われる意思決定を無レビューで任せる用途には向きません。

原因調査で幻覚が出なかったのは、クエリ結果に直接接地する質問だったからです。

判断の根拠に使うなら、AIが示した金額と明細をレポート側で確認できる状態を保って運用しましょう。

まとめ

有償Fabric容量(F SKU)なしでPower BIデータのAI活用がどこまで実用になるのか、正解を仕込んだ家計簿データを使って3方式を比較しました。

  • 3方式すべてが明細レベルでの分析まで到達。有償Fabric容量(F SKU)がなくても、原因調査は実用レベルで機能します。
  • 到達率は3方式でほぼ同じ。追加質問なしで、詳細分析まで達成したのは、どの方式も9回中7回です。
  • 差が出たのは精度ではなく、コストと構築の手間。同じ原因調査タスクで、クレジット消費は、Coworkがやや高くなった。

Power BIライセンス+Microsoft 365 Copilotライセンスだけの組織でも、十分にPower BIデータのAI活用ができるという結果が出ました。

なお、①で使用したPower BI MCPサーバーの設定手順(Azureでのアプリ登録・リダイレクトURL設定など)は、別記事で詳しく解説する予定です。

また、今回検証した機能の一部はプレビュー段階にあり、条件は変わりやすいかと思います。

導入を検討される際は、必ず各機能の最新情報をご確認ください。

ABOUT ME
パワ実(元Microsoft MVP)
2021年からPower Platformの勉強中。 2023年にIT系・コンサルタントに転職し、仕事でPower Platformを活用したコンサルを行っています。 2025年にMicrosoft MVP for Business Applications 受賞。Power Platformを使っていく中で、知りえた情報をブログ、Youtube、Xで発信しています。 2025年8月~現在は、フリーランスとして、Power Platform系ITコンサルタントとして活動中。 Power Platformに関するご相談は以下のページからお願いします! https://www.powerplatformknowledge.com/contact/