想定読者

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!

ワークスペースを覗くと、ちゃんと子アイテムが生成されています。

AppBackend
SQLDatabase
SQLEndpoint

公開 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 対応が来たら、もっと気軽に試せるようになるはず。続報があればまた書きます。

参考リンク