この記事について
Fabric Apps（プレビュー）を実際に触って、Fabric App から「SQL DB」と「既存の Semantic Model」をどう使えるのかを手を動かして確かめた記録です。想定読者
- Microsoft Fabric / Power BI を触っていて、Fabric Apps で何ができて何ができないのかを実機ベースで知りたい方
- アプリが生むデータ（OneLake への着地）と、既存の分析資産（Semantic Model）の関係を確かめたい方
- Fabric Apps（プレビュー）の立ち位置が気になっている方
TL;DR
Fabric App を実際に触ってみたら、"データ" との関わり方が 2 つあると分かりました。混同しやすいので、この 2 つを分けて報告します。
- ① 書き込み（アプリが生むデータ）→ 新規 SQL DB。 既存 DB は指定できず、TypeScript のデータモデルから新しい SQL データベースが作られます（公式 FAQ どおり）。しかもそのデータは zero-ETL で OneLake に Delta として自動着地します——ここは自分の PoC 環境で実機確認しました（§3）。
-
② 読み取り（分析）→ 既存の Semantic Model に接続。
--template dataappで作るアプリは、既存の Power BI セマンティックモデルに接続して Execute DAX Queries でライブに読めます。メジャー・リレーションはそのまま。これも実際に動かして、既存モデルのダッシュボードを Fabric App 上に再現できました（§4）。 - この 2 つは独立して共存します。「新規データを OneLake に生む」一方で「既存 SM を読む」——どちらもできました。
- 触ってみた実感としての位置づけは、「BI の単純な置き換え」ではなく、Power BI を主役に据えつつ、その隣に業務アプリ層を足す／既存 SM の分析をアプリに埋め込むイメージです。
- ※ Fabric Apps は プレビューです（GA ではありません）。以下は 2026 年 7 月時点、①②とも自分の環境で実機まで動かした記録です。
1. 触ってみて分かった：Fabric App が扱う "データ" は 2 種類
Fabric Apps を紹介する文章では「セマンティックモデルを土台にダッシュボードや業務アプリを作れる」といった表現に出会います。触る前の私は 「既存データはそもそも扱えないの？ それとも使えるの？」 がいまいち掴めていなかったのですが、実際に動かしてみると "データ" が 2 つの意味に分かれていると腑に落ちました。
| ① 書き込み（バックエンド） | ② 読み取り（分析） | |
|---|---|---|
| 対象 | アプリが生む業務データ | 既存の分析資産（セマンティックモデル） |
| 既存資産を使える？ | 不可（新規 SQL DB を生成） | 可（既存 SM に接続して読む・preview） |
| 一次ソース | Fabric Apps FAQ | Power BI data in Fabric Apps (preview) |
「既存 DB は指せない（①）」の一文だけを見て「既存の分析データも一切扱えない」と早合点すると、②を見落とします。以下、①②を順に、実際に動かしながら見ていきます。
2. 軸①：書き込みバックエンドは「新規 SQL データベース」（既存 DB は不可）
アプリが永続化する業務データの置き場所については、公式 FAQ にまさにこの質問がそのまま載っています。
既存のデータベースで Fabric Apps を使用できますか?
No. Fabric Apps は、TypeScript データ モデルに基づいてデータベース スキーマを管理します。定義済みのスキーマを持つ既存のデータベースを指すことはできません。（出典: Fabric Apps FAQ）
データモデルの定義ページも、全編「@entity() などの TypeScript デコレーターで新しいエンティティ（テーブル）を定義する」話で、既存テーブルを import する手段は出てきません。rayfin up すると、デコレーターから新規の SQL データベースが生成されます。
つまり アプリのバックエンド（＝アプリが書き込む先）は、自前スキーマの新しい SQL データベースであって、既存の Lakehouse / Warehouse を書き込み先に転用する仕組みではない、ということです。ここが軸①の結論です。
3. 軸①の目玉：アプリのデータは OneLake に Delta で出る（zero-ETL・実機確認）
軸①でありがちなもう一つの誤読が、標語の "bring the app to the data（アプリをデータのある場所へ）" です。「アプリが既存データを読みに行く」と受け取りたくなりますが、この標語が指しているのは向きが逆の write 方向でした。
Because Rayfin can be deployed directly on Fabric, application data lands directly in OneLake, where it is immediately available to the full Fabric data stack ... bringing applications to the data rather than moving data to applications.
- ❌ アプリが既存データを読みに行く（← これは軸②の話。§4 で扱う）
- ✅ アプリを Fabric 上で動かすので、アプリが生んだデータが最初から OneLake に生まれる（出ていく）
この write 方向の zero-ETL は、実機で見ないと腹落ちしません。そこで、テンプレートの Todo アプリをデプロイした自分の PoC ワークスペースで、バックエンドの SQL データベースが本当に OneLake に出ているのかを確認しました。
Fabric App の子アイテムを見ると、AppBackend / SQLDatabase に加えて SQLEndpoint（SQL 分析エンドポイント）が自動生成されています。これは Fabric の SQL データベースが OneLake 上のミラー（Delta）に対して用意するものです。
さらに OneLake のテーブル API を叩くと、アプリのデータモデルがそのまま出てきました（dbo スキーマ）。
namespace: dbo
tables:
- dbo.Todos ← アプリの Todo エンティティ
- dbo.Users ← 認証ユーザー
Todos は Todo テンプレートのエンティティ、Users は認証ユーザーの表です。アプリで作ったデータが、ETL を一切書かずに OneLake の Delta テーブルとして見える——これが zero-ETL の実体でした。Fabric の SQL データベースは OneLake へ自動レプリケーションされる（Mirroring for SQL database）ので、その恩恵をアプリのバックエンドがそのまま受けている、という理解です。
小さな実務メモ: テーブル一覧は
SQLDatabase本体のアイテムに対して取ると返ってきます。SQLEndpointのアイテム ID で叩くと、名前空間（dbo）は返るのにテーブル一覧が 404 になりました。読みに行くなら本体側 or SQL 分析エンドポイントの接続文字列経由が確実です。
4. 軸②：既存のセマンティックモデルに接続して分析できる（data app template・preview）
ここからが軸②です。軸①（書き込み）で既存 DB が使えないのとは別の話として、読み取り分析目的で既存の Power BI セマンティックモデルに接続する道は、preview で用意されています。
一次ソースは Power BI data in Fabric Apps (preview) と Create an app connected to a semantic model（data app template）（ms.date 2026-06-02・07-07 更新）です。
-
--template dataappで作るアプリは、既存の Power BI セマンティックモデルに接続し、Execute DAX Queries API で live クエリを投げます。SM のメジャー・リレーションはそのまま利用できます（＝分析ロジックを二重定義しない）。 - 接続方法：SM の共有リンク（workspace / model id）を Copilot に渡すと、テンプレートが認証ハンドシェイクを内包し、サインイン画面なしで live データを取得します。エージェントが DAX を生成し、preconfigured なビジュアル（棒／線／面／散布／円／heatmap／waterfall／KPI カード／data grid）に束ねます。cross-highlighting や Playwright での検証も内蔵です。
-
前提条件：
- テナント設定「Semantic Model Execute Queries REST API」が ON
- 接続先 SM に Build ＋ Read 権限（Power BI で query するのと同じ権限）
- SM が Fabric / Power BI 容量上にあること
- ⚠️ 既知の制限（現時点・逐語）：SM 接続アプリは Fabric ポータルの外（独立したブラウザウィンドウ）では開けません（Open すると visual query エラー）。これは一時的で将来対応予定とされています。→ 本番の常用ツール置き換えには時期尚早・PoC 向きです。
実機で確かめた（既存 SM に live DAX が通る）
ドキュメントだけでなく、自分の環境で実際に確認しました。--template dataapp でプロジェクトを scaffold し、すでに公開済みの既存セマンティックモデルを接続エイリアスとして登録（fabric-app-data add semanticModel <alias> --workspace <id> --item <id>）。そのうえで、テンプレートに付属する CLI で DAX を実行しました。
# 疎通
$ npx fabric-app-data query semanticModel <alias> --query 'EVALUATE ROW("test", 1)'
{ "status": "success", "table": { "rows": [[1]] } }
# 既存モデルのメジャーがそのまま効く
$ ... --query 'EVALUATE ROW("人数", [人数])'
{ "status": "success", "table": { "rows": [[3426]] } }
# メジャー × リレーション（会社ディメンション経由）も通る
$ ... --query 'EVALUATE TOPN(5, SUMMARIZECOLUMNS(会社[名称], "人数", [人数]), [人数], DESC)'
{ "status": "success", ... } # 会社ごとの集計が返る
ポイントは、この CLI が アプリのランタイムと同一の SDK パイプラインを通ること（テンプレートの開発ドキュメントに「results are identical to what the app will produce」と明記）。つまり上の結果は、デプロイしたアプリが useSemanticModelQuery({ connection, query }) で受け取るものと同じです。既存モデルのメジャー・リレーションをそのまま再利用でき、status: "error"（401/403 等）も出ませんでした＝テナント設定「Semantic Model Execute Queries REST API」が ON かつモデルに Build+Read があれば通る、を実機で確認。
デプロイして、ポータル内で描画まで確認した
CLI での live DAX 確認に加えて、アプリを実際に Fabric 容量へデプロイし（rayfin up）、Fabric ポータル内で開いて描画されるところまで見ました。既存 SM につないだ dataapp を、KPI カード（人数・平均年齢・平均勤続年数）＋従業員数の月次推移（折れ線）＋年齢構成の推移（100% 積み上げ）、という「よくある BI の 1 ページ」相当に組み、すべて既存 SM の値がそのままライブで描画されました。作りは useSemanticModelQuery({ connection, query }) で DAX を投げ、結果を Vega-Lite 系のビジュアルに束ねるだけ。既存モデルのメジャー・リレーションを一切再定義せずにダッシュボードが立ち上がります。
↑ --template dataapp で作ったアプリを Fabric ポータル内で開いたところ。KPI カード＋従業員数の推移＋年齢構成の推移（100% 積み上げ）を、既存セマンティックモデルのメジャー・リレーションをそのまま使って live に描画している（データはデモ用に匿名化）。
正直に線引き：scaffold した
dataappはバックエンド SQL DB を持たず（data: false）、まさに「読み取り分析」専用でした。そしてrayfin upでデプロイ→ポータル内で開く→ビジュアル描画 まで確認できた一方、ポータル外（スタンドアロン URL）で開くと、テンプレートの認証ゲートに「Opening apps connected to semantic models outside of the Fabric portal is not supported」とハードコードされた通り開けません（§6 の制限そのもの）。preview は月次で動くので、採否判断の前に対象テナントで疎通を確認するのが安全です。
5. だから何が嬉しいか（Power BI との棲み分け・素の Azure アプリとの差）
2軸で見ると、Fabric Apps の使いどころが立体的に見えてきます。
-
単純な BI 置き換えではないが、分析の"埋め込み/補完"は射程に入る。
- 既存ダッシュボードをそっくり代替する製品ではありません。Power BI はレポーティングの主役のまま。
- ただし軸②により、既存 SM の分析を業務アプリの画面に埋め込む（メジャー・リレーションを再利用したまま）ことは preview で可能。「入力する業務アプリ（軸①）」と「その画面内で既存分析を見せる（軸②）」を1つのアプリに同居させられる、という設計余地があります（ポータル外制限は前提）。
-
素の Azure アプリと比べた差は、主にここだと感じています。
- アプリのデータが OneLake に自動着地（zero-ETL・軸①） → Power BI / Direct Lake / Notebook / Data Agent がすぐ消費できる。素の Azure アプリだと、このミラーリング／パイプラインを自分で用意する必要があります。
- 既存の分析資産（SM）に 標準テンプレートで接続できる（軸②）。自前で XMLA / Execute Queries API を叩き込む代わりに、テンプレートが認証込みで面倒を見ます。
- 認証（Entra SSO）・行レベルセキュリティ・容量を Fabric のガバナンスにそのまま乗せられる。
- 課金は割り当て容量の CU 消費で、別建ての App Service / DB を立てなくてよい。
「アプリで入力したものがそのまま分析基盤のデータになり（軸①）、既存の分析はアプリから読める（軸②）」——この一気通貫が刺さるかどうかが、採否の分かれ目だと思います。
6. 注意（プレビュー・制約）
いいことばかり書きましたが、プレビューであることは強調しておきます（GA ではありません）。触ってみて／ドキュメントで効いてくる制約は次のとおりです。
- 軸①（書き込みバックエンド）：既存 DB は参照不可（新規 SQL DB を生成）／主キーは単一 UUID（複合主キー不可）／多対多リレーションシップ不可（結合エンティティで表現）／生 SQL 不可（データアクセスは生成された GraphQL 経由）／認証は Entra SSO のみ（デプロイ後はメール／パスワード不可）／複数環境（dev/stg/prod）の管理は現状ワークスペースを手で分ける
- 軸②（読み取り分析）：SM 接続アプリは Fabric ポータル外の独立ウィンドウで開けない（一時的・将来対応予定）／前提としてテナント設定「Semantic Model Execute Queries REST API」ON ＋ SM に Build+Read が必要
- リージョン：対応状況は月次で動きます。日本リージョンで動かす場合は容量の配置と実機疎通を都度一次ソースで確認してください（region availability）。
まとめ
- Fabric Apps と既存データの関係は 2軸で整理する。軸①（書き込みバックエンド）は既存 DB 不可・新規 SQL 生成、軸②（読み取り分析）は既存 SM に接続して読める（preview）。この2つは独立・共存する。
- 軸①の zero-ETL（アプリのデータが OneLake に Delta で出る）も、軸②（data app template・Execute DAX Queries で既存 SM を読む）も、どちらも自分の環境で実機確認できた。特に軸②は、CLI での live DAX に加え、アプリをデプロイしてポータル内で既存モデルのダッシュボードを描画するところまで確認した。
- 位置づけは「BI の単純な置き換え」ではなく「Power BI を主役にしつつ、業務アプリ層を足す（軸①）＋既存分析をアプリに埋め込む（軸②）」。
- プレビューなので、制約・ポータル外制限・リージョン状況は都度一次ソースで確認を。