Copilot Studio + Microsoft Fabric: データレイクを読むエージェントを作る

「うちのデータとそのままチャットできないの?」——これはいまやどのデータチームも毎週のように聞く要望だ。Microsoft の答えは2つの製品を縫い合わせる。Fabric がデータを保持し、Copilot Studio がそれと話すエージェントを構築する。デモは魔法のようだ。本番版には鋭い縁がある。ここではピースが実際どう噛み合うのか——そしてどこで人が切り傷を負うのかを示す。

ピース: Fabric、OneLake、Copilot Studio

Microsoft Fabric は、データエンジニアリング、ウェアハウジング、リアルタイム分析、Power BI を束ねる SaaS の分析プラットフォームだ。OneLake はそのテナント全体で単一のデータレイク——「データ版の OneDrive」と思えばいい——であり、ADLS Gen2 の上に構築され、そして重要なことに、すべてをオープンな Delta-Parquet として保存する。Databricks の lakehouse と同じフォーマットであり、これは偶然ではない。業界はオープンなテーブル層として Delta と Iceberg にほぼ収斂したのだ。

Copilot Studio は、エージェントを構築するための Microsoft のローコードプラットフォームであり、Power Virtual Agents の後継だ。エージェントに指示、ナレッジソース、アクションを与えると、生成 AI を使って応答する。問題は、そのエージェントをどうやってレイクに向けるかだ。

データが住む場所: OneLake と SQL エンドポイント

Fabric の lakehouse または warehouse は、その Delta テーブルをエージェントが使える2つの方法で公開する。SQL 分析エンドポイントはテーブル上の読み取り専用の T-SQL 面であり、SQL を話せるものなら何でもクエリできる。セマンティックモデルはその上に位置し、名前付きのメジャー、リレーションシップ、ビジネスロジックを備え、Direct Lake モードでクエリできる。これは2つ目のコピーをインポートもキャッシュもせず、OneLake から直接 Parquet を読む。ショートカットを使えば、OneLake が S3 や別の ADLS アカウントにあるデータを移動させずに参照できるので、「あなたのデータレイク」は複数のクラウドにまたがれる。

教訓はこうだ。よく作り込まれたセマンティックモデルに支えられたエージェントは、生テーブルに向けられたものよりはるかに信頼できる。なぜならモデルは「顧客」や「売上」が実際に何を意味するのかを符号化しているからだ。

エージェントをレイクに接地する3つの方法

1. Fabric データエージェント(ネイティブな道)。 Fabric には独自の AI エージェント——以前は「AI Skills」——があり、lakehouse、warehouse、あるいはセマンティックモデルの上に構築する。自然言語をあなたのデータへのクエリに翻訳し、Copilot Studio に接続済みのナレッジソースとして追加できる。これは最短ルートであり、Microsoft が投資している道だ。
2. セマンティックモデル上の Copilot Studio ナレッジ。 エージェントを Power BI のセマンティックモデルにナレッジソースとして向ける。定義済みのメジャーに対する質問応答には向いているが、自由な行レベルの検索には弱い。
3. カスタムな grounding。 Power Automate やカスタムコネクタで SQL エンドポイントを叩くか、Azure OpenAI の「自分のデータで」を組む。最大の制御、最大の配管——検索、プロンプト構築、結果の整形はすべて自分持ちだ。

最小限の構築

端から端まで、最も確実に機能する道はこうだ:

1. データを Fabric の lakehouse に着地させ、クリーンな Gold 層を整える——medallion の規律は Databricks とまったく同じようにここでも当てはまる。
2. 名前付きのメジャーとリレーションシップを備えた小さなセマンティックモデルを構築する。精度が勝ち取られるか失われるかはここだ。
3. そのモデルの上に Fabric データエージェントを作り、生成されたクエリを既知の答えに照らしてテストする。
4. Copilot Studio でエージェントを作成し、Fabric データエージェントをナレッジとして追加し、引き締まった指示を書き、Teams かウェブに公開する。

セキュリティがすべてだ

キャリアを終わらせる失敗は、ユーザーが決して見るべきでない行を陽気に返してしまうエージェントだ。出荷する前にこれを正しくやろう:

• アイデンティティが貫通する。 全能アクセスを持つ固定のサービスプリンシパルではなく、サインイン済みユーザー(Entra ID)の代理としてエージェントがクエリするほうを選べ。
• 行レベル・列レベルのセキュリティはセマンティックモデルと lakehouse に宿る——プロンプトではなくそこで強制せよ。プロンプトはアクセス制御の境界ではない。
• OneLake での最小権限。 ショートカットとワークスペースのロールが、エージェントがそもそも何に到達できるかを決める。

どこで壊れるか

• ハルシネーションした、あるいは誤った SQL。 自然言語からクエリへの変換は確率的だ。それを制約するセマンティックモデルがなければ、エージェントはもっともらしいが誤った集計をでっち上げる。常に黄金の質問セットに照らして検証せよ。
• Direct Lake が DirectQuery にフォールバックする。 モデルが大きすぎたり複雑すぎたりすると起こり、レイテンシが静かに悪化する。目を光らせておけ。
• コストの忍び寄り。 Fabric の容量ユニットに生成呼び出しが加わって積み上がる。初日から計測せよ。

---

Fabric の上の Copilot Studio は、非技術者ユーザーにガバナンスの効いたデータとの本物の会話を与える最速の方法だ——ただしセマンティックモデルに投資し、セキュリティをプロンプトではなくデータ層の問題として扱えば、の話である。エージェントがローコードを追い越し、モデルとループを自分で所有する必要が出てきたら、次のピースはオープンなエージェンティックスタック——Hermes と NVIDIA Nemotron を見ていく。