想定読者
- Microsoft Fabric を使っている / 検討しているエンジニア・データ基盤担当・情シス
- 「Fabric の上でアプリのバックエンドまで作れる」という新機能（Fabric Apps / Rayfin）が気になっている方
- プレビュー機能をいち早く触って、実運用での勘所（特にハマりどころ）を知りたい方
- Claude Code / GitHub Copilot などの AIエージェントで開発を進めている方（今回はほぼ GUI レスで作っています）
TL;DR
- Fabric Apps（プレビュー） は、TypeScript でデータモデルを書くと SQL DB + GraphQL API + 認証 + 静的ホスティングを Fabric 容量上にワンコマンドでデプロイできる新機能。CLI/SDK が Rayfin。2026 年 6 月の Build で発表された。
- 実際に公式サンプル（Todo アプリ）を scaffold → デプロイ まで通したら、最初は
403 The feature is not availableで見事に弾かれた。 - 原因は リージョンだった。Fabric Apps は Japan East / Japan West が未対応。テナント設定を ON にしていても、容量リージョンが対応していないと動かない。
- 解決策は 対応リージョン（Korea Central など）に容量を新設し、ワークスペースをそこに割り当てること。Multi-Geo によって compute/storage は容量リージョンで動くため、テナントのホームリージョンが Japan East でも解禁される。
- ただしできること / 向かないことははっきりしている（後述）。「既存の Lakehouse/Warehouse をそのまま読むアプリ」ではない点に注意。
- そして今回の裏テーマ: scaffold → 容量作成 → デプロイ → 403 の原因診断・回避まで、ほとんど Claude Code（AIエージェント）が CLI/REST で自走し、自分が GUI を触ったのは最後の動作確認くらいだった。Rayfin 自体が「Agents write the code, Fabric ships it」を掲げる agentic な設計。
本記事の機能は プレビュー（preview） です。仕様・対応リージョンは今後変わり得ます。検証は 2026 年 6 月時点のものです。最新情報は必ず公式ドキュメントをご確認ください。
1. Fabric Apps / Rayfin とは
Fabric Apps（公式ドキュメント） は、データモデル・API・認証・ホスティングを1 つの開発ワークフローにまとめて、Fabric 上にデータドリブンなアプリを作るための仕組みです。中核となる CLI / SDK が Rayfin。
ポイントは「TypeScript のクラスにデコレータを付けるだけで、バックエンド一式が生成される」ところです。
import { entity, role, text, boolean, date, uuid } from '@microsoft/rayfin-core';
@entity()
@role('authenticated', '*', {
policy: (claims, item) => claims.sub.eq(item.user_id), // per-user の行レベルセキュリティ
})
export class Todo {
@uuid() id!: string;
@text({ min: 1, max: 100 }) title!: string;
@boolean() isCompleted!: boolean;
@date() createdAt!: Date;
@text() user_id!: string;
}
この 1 ファイルから、
- データベースのテーブル定義
- GraphQL API エンドポイント
- 行レベルの認可ルール
- 型安全なクライアントメソッド
が自動生成されます。デプロイ（npx rayfin up）すると、Fabric 上に以下の子アイテムが作られます。
| 子アイテム | 役割 |
|---|---|
| SQL Database in Fabric | デコレータから生成されたスキーマを持つマネージド SQL DB |
| Authentication | Microsoft Entra ID（SSO）によるブローカー認証 |
| Static Content | フロント資産（HTML/CSS/JS）を OneLake 経由でパブリック URL 配信 |
2. セットアップ〜デプロイ（やったこと）
2.1 前提
- Node.js / npm（今回 Node v24）
- Docker（ローカル開発でフルスタックを Docker で回す設計）
- Fabric 容量が割り当てられたワークスペース
- テナント管理ポータルで 「Fabric Apps（プレビュー）」を Enabled に（管理者作業）
2.2 プロジェクト作成
公式テンプレートから scaffold します。テンプレートには blankapp / dataapp / todoapp などがあり、E2E を一通り通す確認には todoapp（データモデル + GraphQL + RLS + 認証をフルに使う）が向いています。
npm create @microsoft/rayfin@latest -- my-app \
--template todoapp \
--dialect mssql \
--services auth,data,storage \
--auth-methods fabric \
--workspace-id <YOUR_WORKSPACE_ID>
生成される rayfin.yml はこんな構成です。
services:
auth:
enabled: true
fabric: { enabled: true }
data:
enabled: true
dialect: mssql
staticHosting:
enabled: true
folder: dist
buildCommand: npm run build:fabric
indexDocument: index.html
2.3 デプロイ
npx rayfin up
これでバックエンド（SQL DB / 認証 / GraphQL）が Fabric にデプロイされ、フロントもビルド → OneLake にホスティングされて公開 URL が払い出される……はずでした。
3. ハマり: 403 The feature is not available
最初のデプロイで、こう落ちました。
🚀 Deploying project "my-app" to Fabric...
Error making Fabric API request: Fabric API error: 403 Forbidden
Details: The feature is not available
❌ Deployment failed:
Error: Fabric API error: 403 Forbidden
Details: The feature is not available
ポイントは、これは認証エラーではないことです。ログイン自体は通っていて（ワークスペース名まで解決済み）、The feature is not available という機能可用性のエラーでした。
テナント設定の「Fabric Apps（プレビュー）」は Enabled 済み。では何が足りないのか?
原因: リージョン
公式の Fabric リージョン可用性 を確認すると、ワークロードごとに対応リージョンが脚注で示されています。そこに、こうあります。
Fabric App isn't available in these regions.（Fabric App はこれらのリージョンでは利用できません）
そしてこの脚注が付くリージョンの一覧に、Japan East と Japan West が両方含まれていました。
| リージョン | Fabric Apps |
|---|---|
| Japan East | ❌ 未対応 |
| Japan West | ❌ 未対応 |
| Korea Central | ✅ 対応 |
| East Asia / Southeast Asia / Central India / Australia East | ✅ 対応 |
| ※ East US / UK South / North Europe 等の一部メジャーリージョン | ❌ 未対応 |
注意したいのは、「US や西欧なら大丈夫」とは限らないことです。East US / UK South / North Europe など主要どころでも未対応の枠があるので、必ず可用性マトリクスを当たってください。
そして、これは私自身がハマる前に見落としていた観点でもありました。
新しいプレビュー機能は「テナント設定 ON」だけでは不十分で、容量リージョンの可用性を先に確認する必要がある ——これが今回いちばんの学びです。403 The feature is not available は、認証ではなくリージョン / SKU のゲーティングを疑うサインです。
4. 解決: 対応リージョンに容量を作る
私の環境は容量もテナントのホームリージョンも Japan East でした。手元の容量はどれも使えないので、対応リージョンに容量を新設します。
ここで効くのが Multi-Geo の考え方です。公式にこうあります。
After you create a capacity, it remains in that region, and any workspaces created under it will have their content stored in that region.
When you're using Multi-Geo, compute and storage (including OneLake ...) is located in the multi-geo region.
つまり Fabric Apps の実体（SQL DB / GraphQL / OneLake 静的コンテンツ）は容量リージョンで動くので、対応リージョンに容量を作れば、テナントのホームリージョンが Japan East でも機能が解禁されるわけです。
Azure CLI（microsoft-fabric 拡張）で F2 を Korea Central に作ります。
az fabric capacity create \
-n <capacity-name> \
-g <resource-group> \
-l koreacentral \
--sku name=F2 tier=Fabric \
--administration "members=[<your-user-principal-name>]"
ハマりどころ（地味だけど重要）: --administration の members はリスト型で、内側にクォートを入れると principal 文字列にクォートが混入して BadRequest: All provided principals must be existing... になります。members=[user@contoso.com]（内側クォートなし）が正解。指定するのは UPN または Entra のオブジェクト ID で、メールアドレスと UPN が異なる組織では UPN を使ってください。
容量ができたら、ワークスペースをその容量に割り当て直して（空のワークスペースならクロスリージョンの割り当ても問題なし）、もう一度デプロイします。
npx rayfin up
今度は通りました。
✔ Rayfin item ready (ID: ...)
🔗 Workload endpoint: https://koreacentral.pbidedicated.windows.net/.../appbackends/...
✅ Configuration applied successfully!
📄 Deploying static content...
✔ built in 1.34s
🌐 Hosting URL: https://<app>-koreacentral.webapp.fabricapps.net
🎉 Project "my-app" is now deployed to Fabric!
ワークスペースを覗くと、ちゃんと子アイテムが生成されています。
AppBackendSQLDatabaseSQLEndpoint
公開 URL も HTTP 200 で生きていて、Fabric SSO サインインの先に Todo アプリが動いていました。E2E が通った瞬間です。
全体の流れ（図）
5. ほぼ GUI を触っていない — AIエージェント（Claude Code）で回した
ここまで読んで気づいた方もいるかもしれませんが、この PoC で自分が Fabric のポータル GUI を触ったのは、最後のアプリ動作確認くらいでした。それ以外の工程は AIエージェント（今回は Claude Code）が CLI / REST API を叩いて進めています。
| 工程 | 操作 | 主体 |
|---|---|---|
| プロジェクト scaffold | npm create @microsoft/rayfin@latest |
AIエージェント（CLI） |
| ワークスペース作成 | Fabric REST API | AIエージェント（API） |
| デプロイ → 403 | npx rayfin up |
AIエージェント（CLI） |
| 原因診断（リージョン特定） | 公式ドキュメントの可用性マトリクス読解 | AIエージェント |
| 対応リージョンに容量新設 | az fabric capacity create |
AIエージェント（Azure CLI） |
| ワークスペース再割当 | Fabric REST API（assignToCapacity） |
AIエージェント（API） |
| 再デプロイ → 成功 | npx rayfin up |
AIエージェント（CLI） |
| アプリ動作確認 | ブラウザで開いて Todo 追加 | 人間（ここだけ GUI） |
特に効いたのは 403 のトラブルシュートでした。「The feature is not available は認証ではなくリージョン起因では?」と当たりをつけ、公式の可用性マトリクスを読んで Japan East 未対応を特定し、Multi-Geo で対応リージョンに容量を作って解決する——という調査から回避までの一連をエージェントが自走してくれた点が、ただのコード生成とは違う体験でした。
Fabric Apps 自体が "agentic" を志向している
これは偶然ではなく、Fabric Apps / Rayfin の設計思想に沿っています。Rayfin は
"Agents write the code. Fabric ships it quickly and safely."
（エージェントがコードを書き、Fabric がそれを素早く安全に出荷する）
と位置づけられており（Rayfin 公式）、公式ドキュメントでも GitHub Copilot などで開発し、Rayfin CLI で Fabric にデプロイすることが想定ワークフローとして書かれています（overview）。Replit との提携も同じ文脈です。
ここで "agentic" には 2 つの意味があるので、分けて捉えると整理しやすいです。
- エージェントが「作る」: Claude Code / Copilot / Replit などの AIエージェントがコード・構成を書き、Rayfin が Fabric に出荷する（＝今回やったこと）
- エージェントの「ための」アプリ: 永続状態が必要な AIエージェント / AI ネイティブアプリのバックエンドとして使う（公式の用途の 1 つ）
今回は ①。テンプレートが土台とはいえ、scaffold からデプロイ、そして 403 の診断・回避まで人間がほぼ直接操作せずに通せたのは、「エージェントが回す開発」の手応えとして面白い体験でした。次は ② 寄りに、自前のデータモデルを AIエージェントに書かせて小さな業務アプリを作る——という、よりフルにエージェントが書くループに踏み込みたいところです。
6. 触ってみての所感 — 向いていること / 向かないこと
公式ドキュメントの「いつ使うか」と、実際に触った感触を合わせて整理します。
向いていること
- 内部ツール・管理画面: 認証付きの CRUD アプリを、バックエンドの定型コードを書かずに立ち上げられる
- 迅速なプロトタイプ: アイデアから公開 URL まで（前提が揃っていれば）短時間
- AI / エージェントアプリのバックエンド: 永続状態が必要なエージェント向けの構造化バックエンド
向かないこと / 制約（ここは正直に）
「Fabric Apps があれば何でもすぐ内製できる」とは言えません。少なくとも現時点では、次の制約があります。
- 既存の Lakehouse / Warehouse をそのまま参照するアプリではない。スキーマは TypeScript モデルが管理する新規 SQL DB を生成する形。つまり既存の BI / 分析基盤を置き換えるものではなく、その上に乗せる業務アプリ層と捉えるのが正確
-
複合主キー不可（主キーは単一 UUID の
id固定） - 多対多リレーション不可（結合エンティティで表現）
- 生 SQL クエリ不可（データアクセスは GraphQL 経由）
- 認証は Entra SSO のみ（デプロイ後はメール/パスワードやカスタムプロバイダ不可）
- 複数環境（dev/staging/prod）管理は現状未提供
- そして本記事の主役、対応リージョンの制約
裏を返せば、これらの制約に収まる「自前スキーマで完結する、認証付きの軽い内部アプリ / エージェントのバックエンド」には、かなり手早く立ち上がる選択肢だと感じました。
課金について
Fabric Apps は割り当て容量の CU（Capacity Unit）を消費します（SQL のコンピュート / GraphQL クエリ / OneLake 操作など）。ホスティングや認証・デプロイ自体に追加課金はありません。PoC で一時的に容量を立てた場合は、使い終わったら pause / 削除して課金を止めるのを忘れずに。
7. まとめ
- Fabric Apps（プレビュー）は、TypeScript のデータモデルからバックエンド一式を Fabric 上に一発デプロイできる、面白い方向性の新機能
- 触る前に 対応リージョンを必ず確認。
403 The feature is not availableはリージョン / SKU ゲーティングのサイン - Japan East 環境でも、Korea Central 等の対応リージョンに容量を作れば Multi-Geo で解禁できる
- 「BI の置き換え」ではなく「基盤の上に乗せる業務アプリ / エージェント層」として、制約を理解した上で使うと刺さりどころがある
- そして scaffold〜デプロイ〜トラブルシュートまで、ほぼ GUI レスで AIエージェント（Claude Code）が自走できた。Rayfin の「Agents write the code, Fabric ships it」という方向性を、小さいながら実体験できた
プレビューなので対応リージョンは今後広がる可能性が高いです。Japan East 対応が来たら、もっと気軽に試せるようになるはず。続報があればまた書きます。