
こんにちは。ACS事業部の越川です。
- 謝辞
- Fabric を初めて触る方へ
- プロンプト駆動とはどういうことか
- Microsoft Fabric とは何か
- ① Lakehouse: データを集める置き場
- ② Shortcut: コピーせずにつなぐ
- ③ Warehouse: 分析しやすい形に整える
- ④ Semantic Model: 意味を与える
- ⑤ Power BI レポート: 見せる
- AI に任せて触ってみて分かったこと
- 補足: Fabric を操作するスキルとは何か
- まとめ
- 自分の手で試したい方へ(ハンズオン教材) ※掲載終了
- 参考リンク
- 注記
- ACS 事業部のご紹介
先日 Microsoft の Build with GitHub Copilot(Fabric 編)というハンズオンに参加してきました。GitHub Copilot CLI(以下 Copilot CLI)から Microsoft Fabric を自然言語のプロンプトだけで操作する内容です。Fabric 操作用のスキル(Skills for Fabric)はこのイベントで紹介されたばかりの公開プレビューでした。その新しい仕組みをその場で自分の手で動かす機会だったわけです。
謝辞
本記事は日本マイクロソフト主催のこのハンズオンでの体験をもとにしています。記事中の公式図は配布資料「Build with GHCP Fabric 編 DL用資料」から主催者の許諾を得て引用しました。貴重な学びの機会と資料の掲載を快諾いただいた日本マイクロソフトの皆さまに、この場を借りて御礼申し上げます。
Fabric を初めて触る方へ
Microsoft Fabric(以下 Fabric)という名前は聞いたことがあるけれど実際に何ができるのかはよく分からない。そんな方は多いのではないでしょうか。私もそうでした。データ分析の基盤らしい、くらいの理解です。
この記事ではハンズオンで触った Fabric の構成要素を、データが可視化されるまでの流れに沿って紹介します。あわせて、それぞれを GitHub Copilot CLI にどんな日本語で頼んだのかも載せます。Fabric が何でできているのかと、AI にデータ基盤を任せる感覚が同時につかめると思います。
私自身 Fabric をきちんと触るのは今回が初めてでした。なので各構成要素については、自分が触って理解したことを Microsoft の公式ドキュメントで裏を取りながら書いています。関連ドキュメントは本文中と記事末尾にリンクを置きました。もっと詳しく知りたい方はそちらをたどってみてください。
なお AI Credits をどれだけ消費したか、どのモデルが向いているかというコストの話は別の記事にまとめています。本記事は Fabric そのものの紹介に絞ります。
プロンプト駆動とはどういうことか
構成要素の紹介に入る前に今回の操作スタイルを説明します。今回のハンズオンは「プロンプト駆動」と呼ばれるやり方でした。
クラウドのデータ基盤を作るときは普通、画面をぽちぽち操作するかコマンドやコードを書きます。プロンプト駆動はそのどちらでもありません。やりたいことを日本語で GitHub Copilot CLI に伝えるだけです。
GitHub Copilot CLI には Microsoft Fabric を操作するためのスキル群(Skills for Fabric というプラグイン)を入れておきます。すると「Lakehouse を作って」「このデータを変換して」と自然言語で頼むだけで済みます。CLI が裏側で Fabric の REST API や PySpark のコードを自動で生成して実行してくれます。

ハンズオンの手順書もこの考え方で作られていました。各ステップが「何を頼むか(プロンプト)」「Copilot が裏で何をするか」「どうなれば成功か(期待する結果)」の3点セットで書かれています。手でコマンドを打つ手順書ではなく、AI に何を頼むかの手順書です。
人間が言葉で意図を伝え、AI がそれをどう操作に落とすか判断して実行する。手で画面を操作する代わりに言葉で済むわけです。初めて触るサービスでもボタンの位置を探さず、やりたいことを伝えるだけで進められるのは新鮮な体験でした。
ひとつ大事な点があります。Copilot は API やコマンドを実行する前に「これを実行していいですか」と許可を求めてきます。中身を確認して人間が承認する。丸投げではなく要所要所で人間が確認しながら進む形です。
公式のデモ画面でも、自然言語のプロンプトから Lakehouse の作成やデータ投入まで一気に進む様子が示されていました。

(出典: Microsoft「Build with GHCP Fabric 編 DL用資料」)
Microsoft Fabric とは何か
ざっくり言うと、データ分析に必要なものを一箇所にまとめた SaaS です。
データ分析をやろうとすると、これまではデータの保管場所・整理する仕組み・分析する基盤・可視化するツールをそれぞれ別のサービスで用意してつなぎ合わせる必要がありました。Fabric はそれらを一つの製品の中にまとめています。データの置き場から最終的なダッシュボードまで同じ画面の中で完結します。データの土台には OneLake(ワンレイク) という共通のデータレイクがあり、後で出てくる Lakehouse や Warehouse はその上に乗っています。
今回のハンズオンで使ったのは公開されている NYC タクシーの乗車記録(グリーンタクシー風のサンプル)です。乗車・降車の日時や場所・乗車人数・距離・料金などが入った Parquet ファイルでした。これを取り込んで最終的にグラフで見られるレポートにするまでを順に作りました。その流れを図にするとこうなります。

左から順に、集める・つなぐ・整える・意味づけ・見せる。この5つの段階をそれぞれ別の構成要素が担当します。以下ひとつずつ見ていきます。実際に Copilot に頼んだプロンプトも添えます。
ハンズオンの公式資料でも、同じ流れが示されていました。データソースから Lakehouse に取り込み、Warehouse で整え、最後に可視化するという一連のデータの流れです。

(出典: Microsoft「Build with GHCP Fabric 編 DL用資料」)
① Lakehouse: データを集める置き場
最初に作ったのが Lakehouse(レイクハウス) です。これはデータの置き場です。
特徴は、表形式に整ったテーブルもまだ整っていない生のファイルも同じ場所に置けることです。ファイルをそのまま放り込んでおくこともできれば、SQL で問い合わせできるテーブルとして扱うこともできます。データレイクとデータウェアハウスのいいとこ取りと説明されていました。とりあえずデータを集めておく入れ物と考えると分かりやすいです。
ここに対してたとえばこんなふうに頼みます。
taxi_lakehouse という名前の Lakehouse を作って。
これだけで Copilot が Fabric の REST API を呼び出して Lakehouse を作ってくれます。続いてサンプルのタクシーデータを取り込み、変換までまとめて頼みました。
green_tripdata の Parquet を読み込んで、ehail_fee 列を削除して、passenger_count が空の行を削除してから Delta テーブルとして保存して。
すると Copilot は裏側で PySpark のコードを生成し、Spark のセッションを立てて実行します。結果はこうでした。元データは 44,238 行です。乗車人数が空の行を 6,290 行取り除いて 37,948 行のきれいなテーブルができ上がりました。列をひとつ削り、欠けた行を落とす。データ整形の基本をコードも書かず日本語で頼むだけで終えられたわけです。
ちなみにここで保存した Delta というテーブル形式は Fabric の標準のテーブル形式です。更新や履歴に強いのがポイントですが、最初はそこまで意識しなくても大丈夫です。
② Shortcut: コピーせずにつなぐ
次に触ったのが Shortcut(ショートカット) です。
データ分析でよくあるのが、別の場所にあるデータを使いたいというケースです。普通に考えるとそのデータをコピーして持ってくることになります。ですがデータが大きいとコピーは時間もストレージも食います。元のデータが更新されるたびにコピーし直す手間も生まれます。
Shortcut はこのコピーをしません。他のストレージ(今回は Azure のデータ用ストレージ)にあるデータを物理的に複製せず参照だけする仕組みです。Lakehouse から見るとあたかもそこにデータがあるように扱えますが、実体は元の場所にあります。元データが更新されれば参照しているこちら側にも反映されます。
ここも外部ストレージ上の CSV を Lakehouse から参照したいと日本語で頼むと、Copilot が Shortcut を作ってくれました。地味ですがデータ基盤の運用ではとても効いてくる仕組みです。
③ Warehouse: 分析しやすい形に整える
集めたデータは、そのままでは分析に向きません。そこで Warehouse(ウェアハウス) の出番です。こちらは T-SQL で扱う本格的なデータウェアハウスです。集計や結合・分析向けのテーブル設計に向いています。
ここで知っておくと見通しが良くなる考え方があります。メダリオンアーキテクチャ です。生データを一段階ずつきれいにしていく設計パターンで、ブロンズ(生データ)・シルバー(整理済みの信頼できるデータ)・ゴールド(分析やレポート用に集計したデータ)の3層でデータを管理します。Lakehouse に取り込んだ生データを分析に使える形へと磨き上げていく流れです。今回のハンズオンは厳密な層分けこそしませんでしたが「生データを綺麗にして・結合や加工をして・表示できる形にする」という同じ考え方で進みました。

(出典: Microsoft「Build with GHCP Fabric 編 DL用資料」)
Warehouse でやったのはディメンション設計です。これは分析の切り口になる情報(日付・地域・料金区分など)を整理して、後から集計しやすい形に組み直す作業です。たとえばタクシーの売上を時間帯別や地域別で見たいとき、その切り口があらかじめ整っていると分析がスムーズになります。分析の世界では数値そのものを持つ「ファクト」と切り口を説明する「ディメンション」に分けて設計するのが定番です。
ここも「こういうディメンションを作って」「このデータからファクトテーブルを作って」と頼むと、Copilot が T-SQL を生成してテーブルを作ってくれました。
④ Semantic Model: 意味を与える
整えたデータに「意味」を与えるのが Semantic Model(セマンティックモデル) です。
これは少しイメージしづらい層かもしれません。データのテーブルそのものはただの数字や文字の集まりです。Semantic Model はその上に「この列は料金です」「この表とこの表はこのキーでつながっています」「合計や平均はこう計算します」といった意味づけをのせる層です。テーブル同士のつながり(リレーションシップ)や、平均運賃・総乗車件数といった集計式(メジャー)を定義します。
BIツール(後述の Power BI)はこの意味の層を読んで動きます。Semantic Model があるおかげで、利用者は元のテーブル構造を意識せず「料金の合計を見たい」と思った通りに分析できます。データと可視化の間をつなぐ通訳のような存在です。ここもファクトとディメンションをつないでモデルを作ってと頼むと、Copilot が組み立ててくれました。
⑤ Power BI レポート: 見せる
最後が可視化です。整えて意味づけしたデータを、グラフや表にして見せる層が Power BI レポート です。
折れ線グラフで推移を見たり、横棒グラフで内訳を比べたり、KPI を大きく表示したり。ここまでの段階で土台が整っているので、レポートはその上にビジュアルを並べていく作業になります。データ基盤の最終的な出口です。
AI はこのレポート作成も担えます。公式資料では、要件を伝えるだけで AI が Power BI のレポートをゼロから組み上げる例が示されていました。KPI カードやグラフ、明細テーブルが並んだダッシュボードです。

(出典: Microsoft「Build with GHCP Fabric 編 DL用資料」)
実はこの最後の段階で私は少しつまずきました。レポート生成には専用のプラグインが必要だったのですが、それを入れ忘れていたのです。Copilot はレポートを作ろうとして必要なスキルが見つからないことに気づき、正直に「この環境では実行できない」と止まりました。
ここで学びがありました。AI は暴走せず、できないことをできないと教えてくれます。ですが、なぜできないのか(前提プラグインの入れ忘れ)を突き止めて補うのは人間の仕事です。前提条件のドキュメントを読み返し、不足していたプラグインを入れ直すことで先に進めました。AI に任せる時代でも前提条件をそろえることの大切さは変わりません。
AI に任せて触ってみて分かったこと
一通り組んでみて、いくつか感じたことがあります。
ひとつは、Fabric は各部品の役割を押さえると一気に見通しが良くなるということです。集める・つなぐ・整える・意味づけ・見せる。この流れの中でそれぞれの構成要素が何を担当しているかが分かると、最初は複雑に見えた製品の全体像がすっきり整理されます。
もうひとつは、プロンプト駆動のおかげで初めて触る私でも各段階を体験しながら理解できたことです。画面のどこを操作するかを覚える前に「何をやりたいか」を言葉にするだけで進められました。裏で Copilot が API や PySpark を生成してくれるので、操作方法そのものを覚える前にデータ基盤が組み上がっていく流れを体で理解できます。学習の入口を大きく下げてくれたと感じます。
一方で、つまずいた場面が示すように、前提条件をそろえたり・AI が止まった原因を突き止めたり・実行前に内容を確認して承認したりするのは人間の役割でした。AI は触る入口を下げてくれますが、何をやりたいのか・どういう基盤を組みたいのかという意図は人間が持つ必要があります。
補足: Fabric を操作するスキルとは何か
最後に、今回 AI に Fabric を操作させる土台になったスキルについて少し補足します。
スキルとは GitHub Copilot CLI のようなAIに与える再利用可能な指示集のことです。Fabric の各機能の API の使い方やお作法をまとめてあります。これをAIに渡しておくことで、自然言語の指示から実際の作成や分析を実行できるようになります。今回使ったのは Skills for Fabric という公式のスキル群で、公開プレビューとして提供されています。
このスキル群は全部で23個あり、役割ごとに5つのカテゴリに整理されています。作る(作成系)・読む調べる(消費系)・診断する(運用系)・他基盤から移す(移行系)・全体構築など(その他)です。今回のハンズオンでは Lakehouse やテーブルを作る作成系と、データを読み取る消費系を中心に使いました。

(出典: Microsoft「Build with GHCP Fabric 編 DL用資料」)
おもしろいのは、これらのスキルが必要になったときだけ読み込まれる仕組みになっていることです。普段はスキルの名前と短い説明だけがAIから見えています。AIが「これが必要だ」と判断して呼び出した瞬間に、初めて詳しい中身が読み込まれます。スキルを大量に用意してもAIが使うのは必要な分だけ。よくできた設計だと感じました。
まとめ
発表されたばかりの Skills for Fabric を使って、Microsoft Fabric を AI に自然言語で指示しながら一通り触ってみました。
Lakehouse でデータを集める。Shortcut で外部データをつなぐ。Warehouse で整え、Semantic Model で意味を与え、Power BI レポートで見せる。この一連の流れをつかむと Fabric が何でできているのかが見えてきます。
そして印象的だったのは、これらをすべて日本語のプロンプトで進められたことです。コマンドの書き方やボタンの場所を覚える前に、やりたいことを言葉にするだけで形になる。AI は初めてのサービスを触る入口を大きく下げてくれました。Fabric に興味はあるけれど触ったことがないという方は、AI と一緒に始めてみると思ったより早く全体像がつかめるかもしれません。
自分の手で試したい方へ(ハンズオン教材) ※掲載終了
このハンズオンの手順書は、オープンなリポジトリとして公開されています。各 lab が「何をプロンプトで頼むか」「Copilot が裏で何をするか」「どうなれば成功か」の3点セットで丁寧に書かれており、Fabric を自分の手で試したい方の格好の教材です。同じ NYC タクシーのサンプルデータを使って、Lakehouse の作成からレポート作成までを順にたどれます。
- ハンズオン教材リポジトリ: 掲載終了
興味を持たれた方は、ぜひご自身の環境で動かしてみてください。本記事で紹介した構成要素の流れが、手を動かすことで一気に腑に落ちると思います。
参考リンク
本記事を書くにあたり、自分の理解を裏取りするために参照した公式ドキュメントとリポジトリです。Fabric をこれから触る方の次の一歩にもなると思います。
- Microsoft Fabric(製品ページ)
- Microsoft Fabric とは(公式ドキュメント)
- OneLake の概要
- Lakehouse の概要
- OneLake の Shortcut
- Warehouse(データウェアハウス)
- メダリオンアーキテクチャ
- Semantic Model の理解
- Power BI レポートの作成
- Skills for Fabric(GitHub・公開プレビュー)
- GitHub Copilot CLI のセットアップ
- 姉妹記事: AI Credits のコストを実測した話
注記
- 本記事の操作は、すべて筆者が手元の環境で GitHub Copilot CLI に Fabric 操作用スキルを導入して実行したものです。
- 各構成要素の説明は、ハンズオンで実際に触った範囲での理解にもとづくものです。Fabric の正確な仕様は公式ドキュメントをご確認ください。
- 本文中のプロンプトは、実際に使った指示の趣旨を分かりやすく書き起こしたものです。
- 取り込んだデータは公開されている NYC タクシーの乗車記録(グリーンタクシー風サンプル)です。認証情報や環境固有の識別子は記載していません。
- Microsoft Fabric および GitHub Copilot の機能・仕様は変更される可能性があります。利用時点の公式情報をご確認ください。
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering + AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です! ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です