Microsoft Fabric の管理 API をサービスプリンシパルで呼び出したい場合、ポイントは「アプリに強い権限を直接付ける」のではなく、Fabric 管理ポータルのテナント設定で、許可した Microsoft Entra セキュリティグループにサービスプリンシパルを入れることです。2026年7月1日時点で確認すべき更新ポイントは、読み取り専用の Power BI 管理 API だけでなく、Fabric の更新系管理 API も対象として整理されている点です。Microsoft Learn 上の該当ページは「Last updated on 2026-06-30」と表示されており、本稿ではこの公式情報をもとに、影響範囲、設定手順、移行期限の有無、管理者が確認すべき実務ポイントをまとめます。(Microsoft Learn)
Microsoft Fabric の「Enable service principal authentication for admin APIs」とは
「Enable service principal authentication for admin APIs」は、Microsoft Fabric や Power BI の管理 API を、ユーザーアカウントではなく Microsoft Entra ID のアプリケーション、つまりサービスプリンシパルで認証して利用できるようにする設定です。
サービスプリンシパルを使うと、管理者個人のサインインに依存せず、棚卸し、監査、メタデータ収集、リスク評価、運用自動化などを安定して実行できます。Microsoft の公式説明では、Power BI の読み取り専用管理 API と Fabric の更新系管理 API に対して、サービスプリンシパル認証を有効化する方法として案内されています。(Microsoft Learn)
特に重要なのは、この設定が「Fabric を画面で操作するためのログイン許可」ではない点です。サービスプリンシパルは REST API 呼び出しには使えますが、サービスプリンシパルの資格情報で Fabric の画面を開くことはできません。(Microsoft Learn)
今回の更新ポイントで押さえるべき結論
今回の公式情報で管理者が最初に押さえるべき点は、次の4つです。
| 確認ポイント | 実務上の意味 |
|---|---|
| 対象は読み取り専用管理 API と更新系管理 API | 監査・棚卸しだけでなく、一部の管理操作の自動化にも関係する |
| 許可はセキュリティグループ単位で制御する | すべてのサービスプリンシパルに開放せず、対象アプリを絞る設計が前提 |
| 有効化には Fabric 管理者権限が必要 | 開発者だけでは完結せず、テナント管理者との調整が必要 |
| 公式ページ上では移行期限や強制切替日は示されていない | ただし、既存の自動化基盤は設定差異による失敗を点検すべき |
Microsoft Learn では、Fabric 管理ポータルの「Admin API settings」で、サービスプリンシパルが読み取り専用管理 API にアクセスできる設定と、更新に使う管理 API にアクセスできる設定を選択できると説明されています。(Microsoft Learn)
影響範囲：誰が確認すべきか
この更新は、Microsoft Fabric を利用しているすべての利用者に直接影響するものではありません。主に影響を受けるのは、管理 API を使ってテナント全体の情報取得や運用自動化を行っている組織です。
影響が大きいケース
次のような運用をしている場合は、早めに設定を確認する価値があります。
| 利用シーン | 確認すべき理由 |
|---|---|
| ワークスペース、レポート、データセット、データフローの棚卸し | 読み取り専用管理 API のサービスプリンシパル認証が必要になる場合がある |
| 監査ログやアクティビティイベントの収集 | ユーザー認証に依存しない定期実行へ移行しやすくなる |
| メタデータスキャン | 自動収集基盤でサービスプリンシパルを使う構成が想定される |
| Microsoft Purview DSPM for AI による Fabric データリスク評価 | 公式情報では、この用途でサービスプリンシパル認証を利用する例が示されている |
| Fabric 管理 API による更新処理 | 更新系 API のサポート状況とテナント設定の両方を確認する必要がある |
Microsoft Learn では、Microsoft Purview Data Security Posture Management for AI のメタデータスキャンや Fabric データリスク評価を実行するアプリが、Fabric 管理 API へのアクセスにサービスプリンシパル認証を使う例として挙げられています。認証方法としては、フェデレーション資格情報が推奨され、代替としてクライアントシークレットも示されています。(Microsoft Learn)
影響が小さいケース
一方で、Fabric の画面上でレポートを閲覧するだけの利用者や、Power BI Desktop から手動で発行しているだけの利用者には、直接の影響は限定的です。
ただし、社内の管理者や外部ベンダーが API 連携で棚卸しや監査を行っている場合、利用者本人が意識していなくても、バックグラウンドの運用に影響する可能性があります。
設定変更の要点：セキュリティグループで対象アプリを絞る
設定の基本的な流れは、Microsoft Entra アプリを用意し、そのアプリのサービスプリンシパルを Microsoft Entra セキュリティグループに追加し、Fabric 管理ポータル側でそのグループに対して Admin API の利用を許可する、というものです。(Microsoft Learn)
設定の全体像
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | Microsoft Entra アプリを作成する | 既存アプリを使う場合もアプリ ID を確認する |
| 2 | Microsoft Entra のセキュリティグループを作成する | グループ種類は Security を選ぶ |
| 3 | アプリ ID をセキュリティグループに追加する | ユーザーではなくアプリをメンバーにする |
| 4 | Fabric 管理ポータルを開く | テナント設定を表示するには Fabric 管理者権限が必要 |
| 5 | Admin API settings の対象トグルを有効化する | 読み取り専用 API と更新系 API を用途に応じて選ぶ |
| 6 | Specific security groups を選択する | 全体許可ではなく対象グループを指定する |
| 7 | Apply で保存する | 保存後、API 呼び出し側で認証と権限を検証する |
ここで避けたいのは、「動かないから一時的に全体へ許可する」という対応です。サービスプリンシパルは人ではなくアプリケーションの実行主体であるため、広く許可すると、どの自動化処理がテナント情報にアクセスできるのか見えにくくなります。最初から専用のセキュリティグループを作り、用途別に分けるのが安全です。
たとえば、読み取り専用の棚卸し用アプリと、ワークスペース復元などの更新系操作を行うアプリは、同じグループにまとめないほうが管理しやすくなります。更新系 API を使うアプリは、誤操作時の影響が大きいため、より厳格にメンバー管理、資格情報管理、実行ログ確認を行うべきです。
読み取り専用管理 API で確認すべきこと
読み取り専用管理 API は、テナント内のアプリ、ダッシュボード、データフロー、データセット、グループ、レポート、ユーザーアクセス、ワークスペース情報などを取得する用途で使われます。Microsoft Learn では、サービスプリンシパル認証をサポートする Power BI の読み取り専用管理 API が列挙されていますが、この一覧は完全とは限らず、最新情報は Power BI REST API ドキュメントで確認するよう案内されています。(Microsoft Learn)
実務では、次の観点で確認すると失敗を減らせます。
| 確認項目 | 判断基準 |
|---|---|
| 使う API が読み取り専用管理 API か | レポート一覧、ワークスペース一覧、アクティビティ取得などの取得系か確認する |
| 公式ドキュメントでサービスプリンシパル対応が明記されているか | 古いブログやサンプルだけで判断しない |
| アプリに不要な API 権限を付けていないか | 管理者同意が必要な権限を付けると想定どおり動かない場合がある |
| セキュリティグループに正しいアプリが入っているか | アプリ登録、エンタープライズアプリ、オブジェクト ID の取り違えに注意する |
| 取得データの保存先が適切か | テナント全体のメタデータを含むため、保管先のアクセス制御も必要 |
特に注意したいのは、読み取り専用管理 API を呼び出すサービスプリンシパルに、Azure ポータル上で Power BI の管理者同意が必要な Application 権限を付与しない、という点です。公式情報では、対象アプリの Permissions を確認し、管理者同意が必要な Application 権限が登録されていないことを確認する手順が示されています。(Microsoft Learn)
更新系 Fabric 管理 API で確認すべきこと
今回の内容で見落としやすいのが、読み取り専用だけでなく Fabric の更新系管理 API も対象に含まれている点です。
Microsoft Learn では、「Service principals can access admin APIs used for updates」設定が、Workspaces – Restore Workspace API などの Fabric 管理 API に適用されると説明されています。特定の Fabric 管理 API がサービスプリンシパル認証をサポートするかどうかは、Fabric REST API リファレンスの「Microsoft Entra supported identities」セクションで確認する必要があります。(Microsoft Learn)
たとえば Workspaces – Restore Workspace API は削除されたワークスペースを復元する API で、API ドキュメント上では Fabric 管理者権限が必要であり、サービスプリンシパルとマネージド ID のサポートが「Yes」と示されています。また、この API はプレビューとして提供され、本番利用には変更可能性への注意が必要です。(Microsoft Learn)
更新系 API は「動くか」より「任せてよいか」で判断する
更新系 API は、単に認証が通ればよいわけではありません。ワークスペース復元、設定変更、管理操作の自動化は、誤ったリクエストがそのままテナント運用に影響します。
導入前に、少なくとも次の基準で判断しましょう。
| 判断項目 | 推奨される確認 |
|---|---|
| 実行主体 | 個人アカウントではなく専用アプリにする |
| 対象範囲 | すべてのワークスペースではなく、必要な範囲に限定する |
| 承認フロー | 復元や更新の前にチケット番号、承認者、対象 ID を記録する |
| ロールバック | 誤更新時に戻せる手順を用意する |
| ログ | API 呼び出しログ、実行結果、エラー内容を保存する |
| 資格情報 | フェデレーション資格情報やシークレットの保管・ローテーションを設計する |
読み取り専用 API は「見えてはいけない情報を見せない」ことが中心ですが、更新系 API は「変えてはいけないものを変えない」ことが中心です。同じサービスプリンシパル運用でも、管理基準を分けるべきです。
Microsoft Entra supported identities の見方
Fabric REST API では、API ごとにサポートされる ID の種類が異なります。Microsoft の ID サポートの説明では、Fabric REST API で利用する認証主体として、Microsoft Entra ユーザー、サービスプリンシパル、マネージド ID が説明されています。サービスプリンシパルやマネージド ID を Fabric REST API で使うには、Fabric 管理者がテナント設定を有効化する必要があります。(Microsoft Learn)
API リファレンスを見るときは、次の順番で確認すると判断しやすくなります。
| 見る場所 | 確認内容 |
|---|---|
| Service | Admin など、どのサービス領域の API か |
| Permissions | Fabric 管理者権限など、呼び出し元に必要な権限 |
| Required scopes | 委任スコープが必要な場合の条件 |
| Microsoft Entra supported identities | User、Service principal、Managed identities がサポートされるか |
| Limitations | レート制限、プレビュー、利用上の制限 |
| Request body | 更新系 API の場合、指定する ID や名前の誤りがないか |
注意点として、ある API 自体がサービスプリンシパルやマネージド ID をサポートしていても、その API が内部的に扱うアイテムや別 API が同じ ID をサポートしていない場合、呼び出しが失敗することがあります。Microsoft Learn の ID サポート説明でも、API 呼び出しが依存する API やアイテムのサポート状況を考慮する必要があるとされています。(Microsoft Learn)
移行期限はあるのか
今回参照している Microsoft Learn の「Enable service principal authentication for admin APIs」ページ上では、特定の日付までに移行しなければならないという移行期限や強制切替日は示されていません。(Microsoft Learn)
ただし、移行期限が明記されていないからといって、確認を後回しにしてよいわけではありません。管理 API を使う自動化は、テナント設定、アプリ権限、API 側のサポート状況、資格情報の有効期限のどれか一つが変わるだけで停止することがあります。
既存運用がある場合は、次のように点検するのが現実的です。
| 対象 | 確認すること |
|---|---|
| 既存の API 連携 | ユーザー認証に依存していないか |
| サービスプリンシパル | どのアプリが何の目的で使われているか |
| セキュリティグループ | 不要なアプリや退役済みアプリが残っていないか |
| Fabric 管理ポータル | 読み取り専用 API と更新系 API の設定が意図どおりか |
| API リファレンス | 利用 API がサービスプリンシパルをサポートしているか |
| 資格情報 | クライアントシークレットの期限切れや保管方法に問題がないか |
移行期限ではなく、「次回の監査」「次回の運用自動化改修」「Purview や棚卸し基盤の導入前」を区切りにして、設定を標準化するのが実務的です。
管理者が確認すべきチェックリスト
設定前後で確認すべき内容を、管理者向けにまとめると次のとおりです。
| チェック項目 | OK の状態 |
|---|---|
| 利用目的が明確か | 棚卸し、監査、メタデータ収集、復元など用途が文書化されている |
| 専用の Microsoft Entra アプリを使っているか | 個人や汎用アプリではなく、用途別アプリになっている |
| セキュリティグループで制御しているか | Specific security groups に対象グループを指定している |
| 読み取り専用と更新系を分けているか | 更新系 API を使うアプリを必要最小限にしている |
| 不要な管理者同意権限がないか | 対象アプリの Permissions を確認している |
| API の対応状況を確認したか | 各 API の Microsoft Entra supported identities を見ている |
| Fabric 管理者権限の扱いを決めたか | 設定変更できる管理者が限定されている |
| 実行ログを残しているか | API 呼び出し元、対象、結果、エラーを追跡できる |
| 資格情報を安全に管理しているか | シークレットの期限、保管場所、ローテーション方針がある |
| 退役ルールがあるか | 不要になったアプリをグループから外し、資格情報を無効化する |
このチェックリストで特に重要なのは、「サービスプリンシパルを作ったら終わり」にしないことです。サービスプリンシパルは自動化に便利ですが、人間のように異動や退職で自然に見直されるものではありません。定期的に棚卸ししないと、使われていないアプリが権限を持ち続ける状態になりがちです。
よくある失敗と対処法
API 権限を付けすぎてしまう
サービスプリンシパルが動かないときに、Azure ポータルで API 権限を追加して解決しようとするケースがあります。しかし、読み取り専用管理 API では、管理者同意が必要な Power BI の Application 権限があると想定どおり動かない場合があります。公式手順でも、対象アプリに該当する権限がないことを確認するよう案内されています。(Microsoft Learn)
対処としては、まず Fabric 管理ポータルの Admin API settings、セキュリティグループのメンバー、アプリ ID の取り違えを確認しましょう。権限を追加するのは、公式ドキュメントで必要性を確認してからにすべきです。
アプリ登録の ID とサービスプリンシパルの ID を混同する
Microsoft Entra では、アプリ登録、エンタープライズアプリケーション、サービスプリンシパルなど似た概念が並びます。設定時にアプリ ID、オブジェクト ID、サービスプリンシパル IDを混同すると、セキュリティグループに追加したつもりでも API が通らないことがあります。
対処として、設定作業の記録に次の値を残しておくとよいでしょう。
| 項目 | 記録する理由 |
|---|---|
| アプリ名 | 運用担当者が用途を判断しやすくする |
| アプリケーション ID | API 認証や設定確認で使う |
| オブジェクト ID | Entra 上の実体確認に使う |
| 所属セキュリティグループ | Fabric 管理ポータルの許可範囲を追跡する |
| 利用 API | 不要になった権限や設定を削除しやすくする |
読み取り用と更新用を同じアプリにしてしまう
小規模な検証では、1つのサービスプリンシパルにすべて任せるほうが簡単です。しかし本番運用では、読み取り専用の棚卸し処理と、更新系の管理操作を同じアプリにまとめると、事故時の影響範囲が大きくなります。
実務では、少なくとも次のように分けるのがおすすめです。
| アプリ種別 | 用途 | 設定方針 |
|---|---|---|
| ReadOnly-Inventory 用 | ワークスペース、レポート、データセットなどの棚卸し | 読み取り専用管理 API のみ許可 |
| Audit-Collection 用 | アクティビティイベントや監査データ収集 | ログ保管先の権限も厳格化 |
| Admin-Update 用 | 復元や管理操作の自動化 | 承認フロー付きで限定運用 |
| Purview-Assessment 用 | Purview DSPM for AI 連携 | Microsoft の要件に合わせて構成 |
導入・見直しの進め方
これからサービスプリンシパル認証を有効化する場合は、いきなり本番テナント全体へ適用するのではなく、小さく検証してから範囲を広げるのが安全です。
推奨手順
| フェーズ | 実施内容 |
|---|---|
| 現状把握 | 既存の管理 API 利用、実行アカウント、スクリプト、連携ツールを棚卸しする |
| 設計 | 読み取り専用と更新系を分け、用途別に Microsoft Entra アプリとセキュリティグループを設計する |
| 検証 | 対象 API の Microsoft Entra supported identities を確認し、最小限の API で疎通確認する |
| 本番設定 | Fabric 管理ポータルで Specific security groups を指定して有効化する |
| 監視 | API 実行ログ、失敗率、資格情報の期限を監視する |
| 定期見直し | 不要なアプリ、古いシークレット、使われていないグループを削除する |
この進め方にすると、サービスプリンシパル認証のメリットである自動化と安定運用を得ながら、テナント全体へ過剰なアクセスを許可するリスクを抑えられます。
まず管理者が取るべき行動
Microsoft Fabric の「Enable service principal authentication for admin APIs」は、単なる認証方式の説明ではなく、Fabric 管理 API を安全に自動化するためのテナント設定です。読み取り専用の Power BI 管理 API、Fabric の更新系管理 API、Purview 連携、メタデータスキャンなどに関係するため、管理者は早めに現在の設定と既存の API 連携を確認すべきです。
まずは、Fabric 管理ポータルで Admin API settings の状態を確認し、許可対象が「Specific security groups」になっているかを見直しましょう。次に、対象グループに入っているサービスプリンシパルを棚卸しし、読み取り専用と更新系の用途が混在していないか確認します。最後に、実際に使っている API のリファレンスで「Microsoft Entra supported identities」を確認し、サービスプリンシパル対応が明記されているかをチェックしてください。
移行期限が明記されていない場合でも、管理 API の自動化は一度止まると監査、棚卸し、運用レポートに影響します。今のうちに、用途別のアプリ設計、セキュリティグループ制御、資格情報管理、実行ログの確認まで含めて標準化しておくことが、Microsoft Fabric 管理の安定化につながります。
コメント