Build 2026 で発表された Fabric App（コードネーム: RayFin）は、Microsoft Fabric の内側に生まれた、AI 駆動開発に最適化されたアプリ開発プラットフォーム です。本記事では、Fabric App が「何を変えるのか」、そして「どんなときに使うべきで、どんなときには使うべきでないのか」を整理します。
紹介動画 (YouTube 1分ちょっと)
Build のセッション動画 (30分ちょっと)
公式の動画は、音声翻訳もできるようにしてあるので便利ですね。
RayFin て、コードネームのくせに前に出過ぎ･･･
アプリ開発者の方は、こちら↓で主要機能を確認してください。
Fabric Apps では、データ モデル、クライアント コード、アプリケーション ロジックの言語として TypeScript がサポートされます。
TL;DR (要点)
- Fabric App (RayFin) は、Fabric のデータ基盤の"上"ではなく"中"でアプリを構築するための新しいプラットフォーム。
- データベース、Entra（認証・認可）、ストレージ、ガバナンスといったFabric のテクノロジーが裏側で自動的に統合されるため、開発者は配管ではなくアプリのロジックと体験そのものに集中できる。
- セマンティック モデルを土台に、自由度の高いダッシュボードや業務アプリを素早く構築できる。
- ただし万能ではない。向いているユースケースと、別のサービスを選ぶべきユースケースがはっきりある。
生成AIに下書きを作ってもらうと出てくる「TL;DR」って何だ？と思ったら、"Too Long; Didn't Read"（長すぎて読まなかった）の略なんですって。「長文なので、要点だけ最初にまとめておきます」という意味だとか。へぇー
なぜ Fabric App が必要だったのか
これまで「データに基づくアプリ」を作ろうとすると、開発者は本質的でない作業に多くの時間を奪われてきました。
- データソースへの接続文字列とコネクション管理
- 認証・認可（誰がどのデータを見てよいか）の作り込み
- API レイヤー、キャッシュ、スケーリングの設計
- データモデルとアプリの間で繰り返される ETL とコピー
- セキュリティ・コンプライアンス・監査ログの後付け
これらは「アプリの価値」そのものではありません。にもかかわらず、プロジェクト工数の大半を消費してきました。
Fabric App の発想はシンプルです。データがすでに Fabric の中にあるなら、アプリもその中で動かせばいい。 データを動かしてアプリに合わせるのではなく、アプリをデータのある場所に持っていく ―― これが Fabric App の出発点です。
個人的には、Power BI レポートでも頑張ればかっこいいダッシュボードを作れるけど、GitHub Copilot とか Claude とか使ってサクッとかっこいいダッシュボード作れるようにしたい。Fabric で実現するからこその価値として、インフラ部分の面倒をかけさせないってことだったんだと思います。
あとは何より、多くの企業で既に使われているセマンティック モデルという資産を活かしたいという思いもあるだろうなぁ、と想像します。
Fabric App の核心: Fabric が"裏側"でつながっている
Fabric App の最大の特徴は、Fabric を支えるテクノロジー群が最初から、見えない形で統合されていることです。
| 開発者が普段やること | Fabric App での扱い |
|---|---|
| DB 接続・接続文字列・シークレット管理 | OneLake / SQL エンドポイントに自動接続。資格情報の手当ては不要 |
| 認証・ユーザー管理 | Microsoft Entra がそのまま効く。サインインも権限も最初から |
| 行レベル/列レベルのアクセス制御 | Fabric 側で定義したガバナンスをアプリが継承 |
| データのコピー・同期 | 不要。アプリはライブのデータに対して動く |
| 監査・コンプライアンス | Fabric の監査ログ・機密ラベルを引き継ぐ |
開発者から見ると、これらは「設定する対象」ではなく「すでにそこにある前提」になります。配管（plumbing）は Fabric が持ち、開発者はアプリを書く。 これが Fabric App の体験の本質です。
AI 駆動開発に最適化されている
Fabric App は、人がゼロから手で書くことを前提にしていません。AI とともに作ることを前提に設計されています。
- スキーマとセマンティック モデルを AI が理解するため、「先月比で解約率が上がった顧客セグメントを表示する画面を作って」といった意図ベースの指示から、アプリの骨格を生成できる。
- セマンティック モデルによって、データの型・リレーション・メジャーが明示されているので、AI の生成結果が根拠を持ち、ハルシネーションしにくい。
- 生成 → 確認 → 修正のループが Fabric の中で完結するため、プロンプトから動くアプリまでの距離が短い。
AI に正しく仕事をさせるには、AI が参照できる「正しく構造化されたコンテキスト」が要ります。Fabric App にとってそれが セマンティック モデル です。
セマンティック モデルで、自由度の高いダッシュボードを
従来のダッシュボードツールは、便利な一方で「決められた枠の中での自由」にとどまりがちでした。Fabric App は セマンティック モデルを土台にすることで、この制約を外します。
- ビジネスの言葉でデータを扱える: 売上、解約率、LTV といったメジャーやディメンションがモデル側で定義済み。アプリ側は SQL の詳細を意識せず、意味のある単位で組み立てられる。
- 指標の一貫性: 同じ「売上」がどの画面でも同じ定義。ダッシュボードごとに計算がばらつく問題を防ぐ。
- 高い表現の自由度: 既製のビジュアルに縛られず、独自のインタラクション・レイアウト・業務フローを持つアプリとして作り込める。レポートというより業務アプリとして成立する。
- ライブデータ: モデル経由で常に最新のデータを参照。エクスポートやスナップショットのズレがない。
「決まったレポート」ではなく、「セマンティック モデルの上に自由に建てるアプリ」。ここが Fabric App がダッシュボード体験で目指す地点です。
向いているユースケース
Fabric App が特に強みを発揮するのは、次のようなケースです。
- Fabric にすでにデータがある、データドリブンな社内・業務アプリ
- セマンティック モデルを核にした、インタラクティブで自由度の高い分析アプリ／ダッシュボード
- Entra による認証・権限管理を前提とする、組織内向けのアプリ
- 役割ごとにデータの見え方を変える、ガバナンスが重要なアプリ
- データチームとアプリ開発者が同じ基盤の上で協働したいケース
- AI を使って素早くプロトタイプから実用アプリへ持っていきたいケース
ひとことで言えば、「Fabric のデータを中心に据えた、組織内のデータアプリ」 が最も得意な領域です。
向いていないユースケース（重要）
Fabric App はすべてのアプリのための汎用プラットフォームではありません。次のような場合は、他の選択肢を検討すべきです。
-
匿名・大規模一般公開のコンシューマー向けアプリ
Entra ベースの認証とFabric ガバナンスを前提とするため、不特定多数に開かれた一般消費者向けの大量トラフィックには適しません。Azure App Service / Container Apps などの汎用 PaaS が適切です。 -
Fabric にデータがない／データ中心でないアプリ
Fabric App の価値はデータとの近さにあります。データ基盤が Fabric の外にある、あるいはそもそもデータ駆動でないアプリでは、統合の利点が活きません。 -
高頻度トランザクション（OLTP）の基幹システム
Fabric は分析（解析・集計）の基盤です。注文処理や決済のような、強い整合性と低レイテンシな書き込みが要る OLTP には、Azure SQL Database / Cosmos DB などを使うべきです。 -
複雑な独自バックエンド・マイクロサービス群
細かなインフラ制御、特殊なランタイム、複雑な非同期処理などをフルにコントロールしたい場合は、汎用のアプリ基盤の方が自由度が高くなります。 -
Fabric / Power BI ライセンスを前提にできない外部配布
ライセンスとテナントの境界を越えた配布が必要なケースでは、前提条件が合わないことがあります。
判断の目安:
- このアプリの価値の中心は Fabric の中のデータか？
- ユーザーは Entra で管理された組織内の人か？
両方が YES なら Fabric App の出番です。どちらかが NO なら、別の道具を検討しましょう。
既存ツールとの関係
- Power BI: レポーティングとビジュアル分析の主役は変わりません。Fabric App は、その セマンティック モデルを土台にした"アプリ" を作る層。レポートを超えた業務フローやインタラクションを持たせたいときに Fabric App を選びます。
- Power Apps: ローコードの業務アプリ作成は引き続き有効。Fabric App はFabric のデータとセマンティック モデルに密着し、AI 駆動・コード中心の開発体験に最適化されている点が違いです。
- Azure の汎用 PaaS: 一般公開・OLTP・フルカスタムなバックエンドはこちら。Fabric App は「Fabric の中のデータアプリ」に特化しています。
これらは競合ではなく、役割分担です。
はじめ方（概念ステップ）
- データを Fabric に集約する ―― OneLake にデータを置く。
- セマンティック モデルを整える ―― 指標・リレーション・アクセス制御を定義。これがアプリと AI の共通言語になる。
- Fabric App でアプリを作る ―― AI に意図を伝えて骨格を生成し、磨き込む。認証・接続・ガバナンスは Fabric から継承される。
- 公開と運用 ―― Entra の権限のもとで組織内に展開。監査・機密ラベルもそのまま効く。
まとめ
Fabric App (RayFin) は、「データとアプリの距離をゼロにする」というアイデアの実装です。
- SQL も Entra もガバナンスも裏側で統合済み。開発者は配管から解放され、アプリそのものに集中できる。
- セマンティック モデルを土台に、一貫性のある指標の上で自由度の高いダッシュボード／業務アプリを作れる。
- AI 駆動開発に最適化され、意図から動くアプリまでの距離が短い。
- ただし万能ではない。一般公開アプリ、OLTP 基幹系、Fabric 外のデータ中心でないアプリには、別の道具を。
Fabric の中にデータがあるなら、アプリもその中で育てればいい ―― Fabric App が示すのは、そんな新しい開発のかたちです。
※ 本記事は Build 2026 での発表内容（コードネーム RayFin）に基づく解説です。製品名・機能・提供範囲は今後のアップデートで変更される可能性があります。最新情報は公式ドキュメントをご確認ください。