Subscribe
Share
Share
Embed
Fabricのデータ エージェントでは、グラウンディング プロンプトがクエリの品質を左右します。精度を最も大きく動かす要因は、誰も聞きたがらないあの話。質問からクエリ、回答に至るパイプラインをたどり、精度が本当に宿る場所を探ります。
Episode 26 • 2026-06-26 Duration: 11:32
Fabric Data Agentが読んでいるのは、あなたの意図ではなく列名です。このエピソードでは、精度を左右するグラウンディングパイプラインの内部構造を解剖し、3年前に後回しにしたスキーマ整備がなぜ今、最優先になったのかを掘り下げます。
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
このポッドキャストは AI によって生成されています。どちらの音声も合成です。Matthias はクローン音声、Fabia は設計された AI 共同ホストです。
Brand design based on fabricperiodictable.com.
Microsoft Fabric のア���キテクチャ意思決定。匿名化された実際の顧客シナリオ、コストのリアリズム、反論を含む。Fabric Friday の録画に合わせた週刊エピソード。AIにより生成。
データ エージェントが間違える本当の理由
Episode 26 | 2026-06-26
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: 25行。Fabricのデータ エージェントが返す回答の、ハード上限です。
[00:10] Matthias: しかも、設定で上げる方法がありません。
[00:11] Fabia: 誰かが「ドイツの顧客を全部見せて」と聞いて、25件だけ返ってきて、サポートチケットを切るわけです。
[00:14] Matthias: となると本当の問題は、このツールが何のためにあるか……あの上限が目的を語っていますね。
[00:18] Fabia: それが今回のテーマです。グラウンディング パイプラインが裏で何をしているか、精度がどこで生まれてどこで死ぬか。そして、どんなプロンプトよりも価値のある、たった1つの投資について。
[00:23] Fabia: データ エージェントの実体は、Azure OpenAI Assistant APIが読み取り専用のツールを呼び出す仕組みです。モデルは変更できません。自分で形づくれるのはグラウンディング プロンプトで、このプロンプトがクエリの品質を決めます。
[00:32] Matthias: そのプロンプトには何が入るんですか？
[00:33] Fabia: ユーザーの質問、呼び出し元のEntra IDで取得されたソースのスキーマ、1万5000文字までの指示、ベクトル類似度で上位に来るFew-shotサンプル、そして会話履歴です。
[00:39] Matthias: スキーマというのは、テーブル名と列名ですね。
[00:40] Fabia: ええ。呼び出し元がテーブルを参照できなければ、エージェントはそのスキーマを受け取りません。プロンプトにスキーマがなければ、そのテーブルへのクエリは生成されません。
[00:45] Matthias: セキュリティが生成の上流にある、と。
[00:47] Fabia: その後ツールが言語を選びます。LakehouseかWarehouseならSQL、セマンティック モデルならDAX、EventhouseならKQL。検証して、読み取り専用で実行し、結果を25行×25列に制限します。
[00:54] Matthias: 生成されたクエリはユーザーに表示される……つまり、エージェントが何を書いたか確認できるわけですね。
[00:57] Fabia: それがデバッグの入り口です。答えがおかしいと思ったら、ステップを展開してください。
[01:00] Matthias: 共有はどうなりますか？ このエージェントを組織全体に渡したとき、全員がビルダーと同じデータを見るんですか？
[01:03] Fabia: いいえ。クエリはすべて、質問した本人のIDで実行されます。エージェント自身は資格情報を持ちません。
[01:06] Matthias: セマンティック モデルの行レベルのセキュリティは？
[01:08] Fabia: そのまま適用されます。同じエージェント、同じ質問でも、人によって結果が違います。
[01:11] Matthias: プロンプトで指示を回避しようとしたら？
[01:12] Fabia: 4層の優先順位があります。最上位が組織レベル、その下にワークスペースのガバナンス、次に開発者の設定、最下位がユーザーの質問です。各層は上の層に制約されます。プロンプトでPurviewのポリシーを上書きすることはできません。
[01:19] Matthias: 構造的に堅いですね。そこは認めます。
[01:21] Fabia: ただし注意点があります。新しいクエリ面であることに変わりはありません。Purview監査ですべての操作をログに残せます。コンプライアンス計画に組み込んでください。
[01:26] Matthias: 監査計画上、他のクエリ エンドポイントと同じ扱いにする、と。
[01:28] Matthias: ガバナンスは持ちこたえる。では実際に何がうまくいかないのか。
[01:30] Fabia: 質問をいただいています。「売上のWarehouseにデータ エージェントを構築しました。デモではうまくいったんです。でも部長が少し違う質問をしたら、エージェントが間違ったテーブルを結合して、自信たっぷりに間違った数字を返しました。いつ信頼していいかわかりません」
[01:39] Matthias: まさにこのパターンを何度も見ています。デモでは動くのに、本番の会議で崩れる。
[01:42] Fabia: ここではガバナンスは助けてくれません。クエリは許可されていました。読み取り専用、正しいID、すべてのポリシーを遵守。ただ結果が間違っていただけです。
[01:47] Matthias: 答えは？
[01:47] Fabia: 測定することです。Microsoftがプレビューの評価SDKを提供しています。実際に想定される30から50の質問と、正しいとわかっている回答でベンチマークを作ります。SDKが正解、不正解、判定不能を集計してくれます。
[01:55] Matthias: つまり、数字が出てから公開する……評価がゲートそのものだ、と。
[01:57] Fabia: スキーマを変更するたびに再実行してください。放置されたエージェントは、静かに精度を失います。
[02:00] Fabia: 評価で間違いの場所がわかります。もっと深い問いは、精度を動かしているのは何か。答えは地味ですよ。
[02:03] Matthias: 列名ですか。
[02:03] Fabia: 最も影響の大きい単一の要因です。IsCustomerActiveならモデルに明確なシグナルを与えます。C1では何もわかりません。エージェントは列名を手がかりに推論します。flg_3が何を意味するか、読み取れるはずがないんです。
[02:11] Matthias: AI機能の精度を最も大きく左右するのが、Warehouseの列名の変更、ですか。
[02:14] Fabia: 動画では生成フィルムがこの流れを追っています。エージェントは、こちらが提供した語彙だけを使って質問を言い換えます。マージンは粗利か純利か。会計年度は誰のカレンダーか。
[02:19] Matthias: デモでもありましたよね？ 指示を追加する前と後で同じ質問をした場面。
[02:21] Fabia: 同じ質問です。2013会計年度の地域別マージン。エージェントが暦年と会計年度のどちらを選ぶかで、売上合計に約40%の差が出ました。
[02:26] Matthias: 40%。同じ質問で。それはつまり—
[02:27] Fabia: —使えるツールか、キャリアが終わる数字かの違いです。修正は、3つの用語を定義した1段落だけでした。
[02:30] Matthias: これは怖いですよ。チームがデモを見せて、経営層が感心して、組織に公開する。ところが3つのビジネス用語を定義しなかっただけで、数字が静かに40%ずれています。モデルは指示どおりに動きました。指示がなかっただけです。
[02:37] Fabia: 次にサンプルです。SQLやKQLのソースには最大100件登録できますが、エージェントは質問ごとにベクトル類似度の上位数件だけを取得します。結合、日付フィルター、集計と、クエリの形を網羅してください。セマンティック モデルはサンプルに対応していません。Power BI側ではPrep for AIに投資してください。
[02:48] Matthias: 運用コストはどうなりますか？
[02:49] Fabia: Fabricの容量で動きます。F2以上、またはPower BI Premium P1以上です。裏のAzure OpenAIコンピューティングはMicrosoft管理です。
[02:54] Matthias: 別途AIの請求はないと。
[02:55] Fabia: 見落とされがちなコストは保守です。スキーマが変わると指示やサンプルが陳腐化します。四半期ごとのレビューを見込んでおいてください。
[02:59] Matthias: ここが誰も予算に入れない部分です。スプリントで作って、拍手をもらってリリースする。半年後にスキーマが変わり、指示には誰も触れず、精度が静かに劣化している。偉い人が間違った数字を受け取ったときには、もう何週間もそうだったわけです。
[03:07] Fabia: リージョンまたぎも壁になります。エージェントの容量とソースの容量が同じリージョンにないと、クエリは実行できません。
[03:11] Matthias: これを使わずAzure OpenAIを直接呼ぶ選択肢の、一番強い根拠を聞かせてください。
[03:14] Fabia: 自分のモデル、自分のRAG、自分のオーケストレーション ロジックが必要な場合です。エージェントはLLMが1つ、ソースが5つ、行が25行、英語のみに固定されます。
[03:19] Matthias: すでにFoundryを深く使っているチームで、複数の—
[03:21] Fabia: —ツールを組み合わせているなら、5ソースの上限と固定モデルがアーキテクチャを想定以上に制約するかもしれません。直接呼べば、設計は自分の手にあります。
[03:26] Matthias: その代わり、ガバナンスを自前で再構築することになる。
[03:28] Fabia: IDパススルー、読み取り専用の強制、Purview統合。これがエージェントの提供するものです。自前で作るときに過小評価されるのが、まさにガバナンスです。
[03:33] Matthias: 自分の判断としてはこうです。Fabricデータへの会話型インターフェースを初めて作るなら、そしてガバナンスがスタックで解決していないなら、エージェントを使ってください。ID管理、読み取り専用、Purviewが手に入ります。すでにFoundryでオーケストレーションしていて5ソースの上限がきついなら、直接呼ぶ。何を再構築するかを理解した上で。
[03:44] Fabia: 1つリスクを挙げておきます。FoundryのFabricToolはOn-Behalf-Of認可を使います。サービス プリンシパルには対応していません。
[03:49] Matthias: Foundry経由ではサービス プリンシパルがまったく使えないんですか？
[03:52] Fabia: サービス プリンシパル認証はプレビューで、直接RESTのみです。KQLソースには対応していません。FoundryではユーザーIDを前提にしてください。
[03:57] Matthias: 今週始めるチームに伝えるなら、こうです。エージェント ビルダーを開く前に、列名を見てください。flg_3が何を意味するか自分で説明できないなら、モデルにもできません。それが本当のアーキテクチャ上の判断です。
[04:04] Fabia: スライドで簡単に見えるのと、実際に動かして簡単なのは別の話です。エージェントは簡単そうに見える。その下のスキーマ作業こそが難しいところです。
[04:08] Matthias: その作業をまだしていないチームには？
[04:10] Fabia: 先にスキーマを直してください。エージェントは待ってくれます。
[04:12] Matthias: 今まさにどこかで、データ エージェントが間違ったテーブルを結合しています。列名がまだC1のままだから。そして誰も測定していない。
[04:17] Fabia: その列名こそが、アーキテクチャ上の判断です。
[04:18] Matthias: もしデータ エージェントを構築中で、トレードオフを相談したいと思ったら、LinkedInでDMしてください。Matthias Fallandで見つかります。
[04:23] Fabia: また来週お会いしましょう。
---
End of episode. ~04:24 estimated.