Microsoft FabricのFabric Data Warehouseでバッチ処理、CI/CD、外部ツール接続を自動化している場合、「Service Principals in Fabric Data Warehouse」は必ず確認しておきたい公式情報です。結論から言うと、Fabric Data Warehouseでサービスプリンシパル（SPN）を使う目的は、個人ユーザーの資格情報に依存せず、Warehouseの作成・管理・接続・クエリ実行を安全に自動化することです。特に、所有者が退職した場合の停止リスク、30日ごとのサインイン要件、COPY INTOやOPENROWSET実行時の初期トークン問題、権限付与の分離が実務上の重要ポイントになります。(Microsoft Learn)
なお、2026年5月8日の公式GitHub履歴では、該当ドキュメントを含むマージが確認できます。一方、Microsoft Learn本文上の最終更新日は2026年3月30日と表示されています。5月8日の差分を見る限り、service-principals.md自体は「data warehouse」を「warehouse」に統一する表記調整、監視ページ名や所有権変更リンク名の修正が中心です。製品仕様が大きく変わったというより、SPN運用で確認すべき前提や制限を正しく理解することが重要です。(GitHub)
Service Principals in Fabric Data Warehouseとは
Service Principals in Fabric Data Warehouseは、Microsoft FabricのWarehouseでサービスプリンシパルをセキュリティIDとして使うための公式ドキュメントです。サービスプリンシパルは、Microsoft Entra ID上のアプリケーションを表す非対話型のIDで、人間のユーザーではなく、アプリケーションや自動化ツールが認証・認可を行うために使います。(Microsoft Learn)
Fabric Data Warehouseでは、SPNを使うことで次のような運用が可能になります。
| 利用シーン | SPNを使うメリット |
|---|---|
| Warehouseの作成・更新・削除 | 個人アカウントではなく自動化用IDでREST APIを実行できる |
| SSMSなどのクライアント接続 | Microsoft Entra Service Principal認証でWarehouseへ接続できる |
| Data Factoryパイプライン | スケジュール実行されるT-SQLやCOPY INTOを人のサインインに依存せず実行しやすい |
| 本番運用の権限管理 | SPNに必要な権限だけを付与し、最小特権で運用できる |
| 監査・モニタリング | クエリ実行者としてSPNを識別しやすい |
従来のように個人ユーザーの資格情報でWarehouseやデータ連携を作成すると、そのユーザーが退職・異動・アカウント停止になったときに、OneLakeへのアクセスや自動化処理が止まるリスクがあります。公式ドキュメントでも、所有者IDに依存する問題を避けるため、WarehouseをSPNで作成することが推奨されています。(Microsoft Learn)
何が変わるのか：個人ID依存からアプリケーションID中心の運用へ
今回押さえるべき本質は、「Warehouseを誰が操作しているか」を個人ユーザーからアプリケーションIDへ移すことです。
Fabric Data Warehouseでは、管理者・メンバー・共同作成者のワークスペースロールを持つユーザーが、SPN認証を使ってFabric REST API経由でWarehouseアイテムを作成、更新、読み取り、削除できます。これにより、プロビジョニングや管理作業をユーザー資格情報に依存せず自動化できます。(Microsoft Learn)
特に注意すべき変化は次の3つです。
| 確認ポイント | これまで起きやすかった問題 | SPN利用時の考え方 |
|---|---|---|
| 所有者 | 個人ユーザーが所有者になり、退職・無効化で処理が止まる | Warehouseの作成や所有権をSPN中心に設計する |
| 認証 | 手動サインインや個人トークンに依存する | OAuth 2.0のクライアント資格情報フローなどで自動化する |
| 権限 | ワークスペース権限だけで済むと誤解しやすい | コントロールプレーン権限とデータプレーン権限を分けて付与する |
ここで重要なのは、SPNを登録するだけではFabric Data Warehouseを安全に使える状態にはならないことです。Entra ID、Fabric管理ポータル、ワークスペース、Warehouse内部のT-SQL権限をそれぞれ確認する必要があります。
対象者：管理者だけでなく開発者・DevOps担当者も確認が必要
Service Principals in Fabric Data Warehouseの影響を受けるのは、Fabric管理者だけではありません。Warehouseを自動展開する開発者、SSMSやData Factoryから接続するデータエンジニア、CI/CDを設計するDevOps担当者も確認対象です。
| 立場 | 確認すべきこと |
|---|---|
| Fabric管理者 | テナント設定でSPNによるFabric API利用が許可されているか |
| Entra ID管理者 | アプリ登録、SPN、シークレット、セキュリティグループが正しく構成されているか |
| ワークスペース管理者 | SPNに適切なワークスペースロールまたはアイテム権限を付与しているか |
| データベース管理者 | GRANTなどで必要なT-SQL権限だけを付与しているか |
| 開発者 | SSMS、スクリプト、Data FactoryパイプラインでSPN認証を使えるか |
| DevOps担当者 | 初期トークン生成、シークレット管理、30日更新、制限事項をパイプラインに組み込んでいるか |
管理者がテナント設定だけを有効化しても、Warehouse側の権限が不足していればクエリは失敗します。反対に、Warehouse側でGRANT SELECTを付与しても、Fabric REST API側の初期化やワークスペースアクセスが不足していれば、外部ストレージアクセスやAPI実行でつまずきます。
事前に確認すべき設定
Fabric Data WarehouseでSPNを使うには、複数のレイヤーを順に確認します。
Microsoft Entra IDでSPNを用意する
まず、Microsoft Entra IDでアプリケーションを登録し、サービスプリンシパル、アプリケーションID、シークレット、テナントIDを用意します。SPN管理はEntra ID管理の範囲に含まれるため、Fabric担当者だけで完結しない場合があります。公式ドキュメントでも、Entra ID管理者からApp ID、Secret、Tenant IDを入手する前提が示されています。(Microsoft Learn)
実務では、SPNを直接全社に許可するのではなく、専用のMicrosoft Entraセキュリティグループを作成し、そのグループにSPNを追加してからFabricのテナント設定に指定するのが管理しやすい方法です。
Fabric管理ポータルのテナント設定を確認する
Fabric側では、サービスプリンシパルがFabric APIを使えるようにする設定が必要です。Developer tenant settingsでは、Fabric public APIsのCRUD操作に対して「Service principals can call Fabric public APIs」を使う説明があり、許可されたセキュリティグループにSPNを含める必要があります。新しい顧客環境では、この設定は既定で有効と説明されていますが、既存テナントや管理ポリシーによって状態が異なる可能性があるため、必ず管理ポータルで確認してください。(Microsoft Learn)
また、管理API向けのSPN認証では、Fabric管理ポータルで対象の設定を有効化し、Specific security groupsに対象グループを追加してApplyする手順が示されています。管理APIとWarehouseの通常操作APIは目的が異なるため、どのAPIを使うのかに応じて必要な設定を切り分けることが重要です。(Microsoft Learn)
ワークスペースまたはアイテム権限を付与する
SPNは、ワークスペースの「Manage access」からワークスペースロールを使ってWarehouseへアクセスできます。加えて、Fabric Item Permissionsを使ってWarehouseアイテムをSPNに共有することもできます。(Microsoft Learn)
ここでの注意点は、ワークスペース管理者権限を安易に付けすぎないことです。CI/CD用SPN、読み取り専用連携用SPN、データロード用SPNを分けると、障害調査や監査のときに原因を追いやすくなります。
Warehouse内部でT-SQL権限を付与する
Fabricのアクセス権限には、コントロールプレーンとデータプレーンがあります。ワークスペースロールやアイテム権限は、主にFabric上のリソース管理やアクセス制御に関わります。一方、実際にどのテーブルを読めるか、どの操作を実行できるかは、Warehouse側でT-SQLのGRANTを使って制御します。公式ドキュメントでも、最小特権の原則に従ってSPNへ必要なデータプレーン権限を付与することが推奨されています。(Microsoft Learn)
例として、特定テーブルの読み取りだけを許可する場合は次のようにします。
GRANT SELECT ON <table name> TO <service principal name>;本番環境では、最初から広い権限を与えるのではなく、用途ごとに権限を絞ることが大切です。たとえば、レポート更新用SPNにはSELECT中心、データロード用SPNには対象スキーマへの必要な書き込み権限、管理用SPNには運用手順で必要な権限だけを付与します。
SSMSやクライアントアプリからSPNで接続する方法
Fabric Warehouseには、SQL Server Management Studio（SSMS）19以降などのツールからSPNで接続できます。認証方式は「Microsoft Entra Service Principal」を選び、ユーザー名にはアプリケーション（クライアント）ID、パスワードにはシークレットを指定します。(Microsoft Learn)
接続確認で失敗する場合は、次の順で切り分けると効率的です。
| 症状 | 主な原因 | 確認ポイント |
|---|---|---|
| SSMSで認証できない | App ID、Secret、Tenant IDの誤り | Entra IDのアプリ登録とシークレット有効期限を確認する |
| 接続できるがテーブルが読めない | データプレーン権限不足 | WarehouseでGRANT SELECTなどを確認する |
| APIでは見えるがSQL実行に失敗する | ワークスペース権限とT-SQL権限の混同 | コントロールプレーンとデータプレーンを分けて確認する |
| 外部ストレージアクセスで失敗する | 初期Fabricトークンが未生成 | REST APIでSPNの初期トークンを確立する |
SSMSで接続できたことは、すべてのデータ操作が許可されたことを意味しません。Warehouse内部の権限を必ず確認してください。
初期トークンと30日更新が最もつまずきやすい
実務で特に見落としやすいのが、SPNのトークン初期化です。Fabricでは、SPNはFabricポータルに対話的にサインインできません。そのため、対話型ユーザーのようにポータル側で暗黙的にControl Planeトークンが初期化されず、API呼び出しによって明示的にFabricトークンを生成または更新する必要があります。(Microsoft Learn)
新しく作成したSPNでは、Fabric REST APIを使って初期のFabricセキュリティトークンを生成する必要があります。SQL分析エンドポイントの接続文字列でWarehouseへ接続しても、SPNのFabricトークンは生成されません。最初に成功したAPI呼び出しが、Fabric内でSPNのトークンを確立します。(Microsoft Learn)
これは、COPY INTOやOPENROWSETで外部ストレージへアクセスする処理では特に重要です。権限があるように見えるのに「ファイルが存在しない」「アクセス許可がない」といったエラーが出る場合、実際にはSPNの初期トークンが確立されていない可能性があります。
公式手順では、Azure CLIでSPNとしてログインし、https://api.fabric.microsoft.com向けのアクセストークンを取得したうえで、ワークスペース内のアイテム一覧取得など任意のFabric APIを呼び出す例が示されています。(Microsoft Learn)
az login --service-principal `
-u <APP_ID> `
-p <SECRET> `
--tenant <TENANT_ID>
$accessToken = az account get-access-token `
--resource https://api.fabric.microsoft.com `
--query accessToken -o tsv
$workspaceId = "<WORKSPACE_GUID>"
$url = "https://api.fabric.microsoft.com/v1/workspaces/$workspaceId/items"
$headers = @{ Authorization = "Bearer $accessToken" }
Invoke-RestMethod -Method GET -Uri $url -Headers $headers自動化する場合、シークレットをスクリプトやリポジトリに平文で置くのは避けるべきです。公式ドキュメントでも、Azure Key Vaultにシークレットを保存し、スクリプトや自動化パイプラインから取得する方法が示されています。(Microsoft Learn)
所有権移行と展開時の注意点
既存のWarehouseが個人ユーザー所有になっている場合は、所有権の扱いを確認してください。Warehouseの所有権は、SPNからユーザー、ユーザーからSPNへ変更できます。ただし、FabricポータルからSPNを所有者として設定することはできず、PowerShellまたはREST APIを使う必要があります。(Microsoft Learn)
SPNへ所有権を移す場合は、次の順で進めると安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状確認 | Warehouse所有者、ワークスペースロール、実行中パイプラインを洗い出す | 個人ユーザー所有の本番Warehouseを優先する |
| SPN準備 | Entra IDアプリ、シークレット、セキュリティグループを整備する | シークレット期限と保管場所を決める |
| Fabric設定 | テナント設定、ワークスペースアクセス、アイテム権限を確認する | 管理API設定とDeveloper設定を混同しない |
| 権限付与 | Warehouse内で必要なT-SQL権限を付与する | 最小特権で開始する |
| 初期化 | REST API呼び出しでSPNトークンを確立する | SQL接続だけでは初期化されない |
| 切り替え | 所有権変更やパイプライン接続を更新する | 本番反映前に検証環境で再現する |
| 監視 | DMV、Query Insights、Data Warehouse Monitor、Capacity metrics appで実行主体を確認する | SPNのClient IDで追跡できるようにしておく |
移行時にやってはいけないのは、「とりあえず管理者権限を付けて動かす」ことです。動作確認は早く進みますが、後から権限を絞るのが難しくなり、監査でも説明しにくくなります。まず用途を分け、読み取り用・ロード用・管理用のSPNを整理してから権限を設計しましょう。
モニタリングで確認すべき項目
SPNがWarehouseでクエリを実行した場合、Fabric Data Warehouse Monitorや関連ビューで実行主体を確認できます。公式ドキュメントでは、sys.dm_exec_sessionsのlogin_name、queryinsights.exec_requests_historyビューのlogin_name、Fabric Data Warehouse Monitorのsubmitter、Capacity metrics appのBackground operations drill through tableにあるUser列などが確認先として挙げられています。(Microsoft Learn)
監視で見るべきポイントは、単に「成功したか」だけではありません。
| 確認項目 | 見る理由 |
|---|---|
| どのSPNが実行したか | 個人ユーザーではなく自動化IDで動いているか確認する |
| 実行時間と頻度 | 想定外のループや過剰実行を検知する |
| 使用容量・コンピュート | SPN実行によるコスト影響を把握する |
| 失敗クエリ | 権限不足、トークン未初期化、外部ストレージ接続エラーを早期に見つける |
| 実行対象テーブル | SPNに不要なデータアクセスが発生していないか確認する |
本番展開後は、少なくとも初回の数日間はSPN単位で実行ログを追跡するのがおすすめです。特に夜間バッチやData Factoryパイプラインでは、失敗が翌営業日まで発見されないことがあるため、アラート設計も合わせて見直してください。
制限事項：Git APIとT-SQL Notebookには注意
Service Principals in Fabric Data Warehouseには、明確な制限事項もあります。公式ドキュメントでは、SPNはGit APIsではサポートされず、Deployment pipeline APIsのみでサポートされること、また現時点ではSPNがFabricのT-SQL Notebooksを実行できないことが記載されています。(Microsoft Learn)
この制限は、CI/CD設計に直接影響します。
| やりたいこと | SPN利用時の注意点 |
|---|---|
| Git連携をSPNで完全自動化したい | Git APIsはSPN非対応のため、別方式を検討する |
| Deployment pipeline APIsを使いたい | SPNサポートの範囲内で設計できる |
| T-SQL NotebookをSPNで実行したい | 現時点では実行できないため、別の実行方法を検討する |
| Data FactoryからT-SQLを定期実行したい | SPN権限と初期トークンを整備すれば現実的な選択肢になる |
開発チームが「SPN対応」と聞いて、すべてのFabric機能をSPNで実行できると誤解するケースがあります。導入前に、対象APIや実行方式ごとのサポート状況を確認してください。
管理者・開発者向けチェックリスト
SPN対応を進める際は、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 完了の目安 |
|---|---|
| Entra IDでアプリ登録とSPNを作成した | App ID、Tenant ID、Secretを管理できている |
| SPNを専用セキュリティグループに追加した | Fabric設定で指定するグループが明確になっている |
| Fabric管理ポータルでSPN利用設定を確認した | 必要なAPI種別に応じた設定が有効になっている |
| SPNにワークスペースまたはアイテム権限を付与した | 対象Warehouseへアクセスできる |
| Warehouse内でT-SQL権限を付与した | 必要なテーブル・操作だけに限定している |
| 初回Fabric REST API呼び出しを実行した | SPNのFabricセキュリティトークンが確立されている |
| 30日更新を自動化した | 手動サインインに依存していない |
| シークレットをKey Vaultなどで管理した | 平文保存やリポジトリ混入を避けている |
| 監視でSPNの実行主体を確認した | DMVやMonitorで追跡できる |
| 制限事項をCI/CD設計に反映した | Git APIやT-SQL Notebookの非対応を考慮している |
よくある失敗と対処法
SPNを作成しただけでWarehouseに接続しようとする
SPNをEntra IDで作成しても、Fabric側のテナント設定、ワークスペースアクセス、Warehouse内部権限がなければ実行できません。まず「Entra ID」「Fabric管理ポータル」「ワークスペース」「Warehouse内部」の4層で権限を確認してください。
SQL接続で初期トークンが作られると誤解する
SQL分析エンドポイントに接続しても、SPNのFabricトークンは生成されません。新しいSPNでは、最初にFabric REST APIを成功させてControl Plane側のトークンを確立する必要があります。COPY INTOやOPENROWSETで原因不明の認証エラーが出る場合は、この点を最初に疑うべきです。(Microsoft Learn)
ワークスペース管理者権限を付けすぎる
動作確認のためにSPNへ広い権限を付けると、本番運用で不要なデータアクセスが残りやすくなります。SPNは人間よりも継続的に動くため、権限の過剰付与は影響が大きくなります。用途ごとにSPNを分け、T-SQL権限も必要最小限に絞りましょう。
CI/CDでGit APIまでSPN化できると思い込む
公式ドキュメントでは、SPNはGit APIsではサポートされず、Deployment pipeline APIsのみでサポートされるとされています。Git連携を含めた完全自動化を設計している場合は、実行方式を事前に見直してください。(Microsoft Learn)
まず取るべき行動
Fabric Data Warehouseを本番運用している場合は、最初に既存Warehouseの所有者と自動化処理を棚卸ししてください。個人ユーザーが所有者になっているWarehouse、個人資格情報で動いているData Factoryパイプライン、手動サインインに依存しているバッチがあれば、SPNへの移行候補です。
次に、テナント設定とワークスペース権限を確認し、検証環境でSPNによるREST API呼び出し、SSMS接続、GRANT後のクエリ実行、COPY INTOやOPENROWSETの動作を確認します。最後に、Key Vaultによるシークレット管理、30日ごとのトークン更新、Monitorでの実行主体確認まで含めて本番展開します。
Service Principals in Fabric Data Warehouseは、単なる認証方式の追加ではなく、Fabric Data Warehouseを個人依存から自動化・監査・最小特権を前提とした運用へ移すための重要な設計ポイントです。管理者はテナント設定と権限設計を、開発者は初期トークンと実行環境を、DevOps担当者は制限事項とCI/CDの実装方法を確認してから展開しましょう。
コメント