この記事の要点
- 外部 Web アプリや Azure Functions などから Dataverse を呼び出すときは、アプリケーション ユーザー（Application User） を使うのが正解です。
- アプリケーション ユーザーは Dynamics 365 / Power Apps のライセンス不要です。
- 人間のユーザーアカウントを使い回す方式は ライセンス・セキュリティ・運用の3つの理由で NG。
- PL-600*（Microsoft Power Platform Solution Architect）の 頻出論点です。本記事では実務シナリオを通じて解説します。
*：2026年6月末廃止のMicrosoft Power Platformの最上位資格
はじめに
「カスタム Web アプリから Dataverse のデータを読みたい」「Azure Functions の夜間バッチで Dataverse に書き込みたい」――こうしたサーバー間連携（Server-to-Server, S2S）は Power Platform Solution Architect の現場で頻出のシナリオです。
ところが、この場面で「とりあえず管理者の ID とパスワードを使えばいいか」と発想すると、ライセンス・セキュリティ・運用の3面で確実に詰みます。
正解は Microsoft が公式に用意している アプリケーション ユーザー（Application User） という仕組みを使うこと。本記事ではこの仕組みを、PL-600 の試験シナリオを題材に、初学者にもわかるよう一気通貫で解説します。
こんな方に向けた記事です
- PL-600（Microsoft Power Platform Solution Architect）の受験を控えている方
- 外部システムと Dataverse を統合する案件を進めている開発者・アーキテクト
- 「Application User って何が嬉しいの？」を腹落ちさせたい方
題材：あるコールセンターの統合シナリオ
仮想の事例で考えてみましょう。
コールセンター 24h 対応シナリオ
ある通信会社の 24 時間コールセンターでは、次の3つの業務要件があります。
- 新人オペレーター：顧客から入電したときに、本人確認テンプレートを画面で参照しながら応対する
- エスカレーション担当：複雑な技術問い合わせの転送状況を、外出先のモバイル アプリで管理したい
- インシデント対応チーム：すでに社内には .NET で構築された既存のコールセンター業務アプリ が稼働している。Microsoft Dataverse の Contact テーブルに保存されている
VIP/Caution/Watchの顧客フラグと、いま着信中の顧客情報を即座に突合したいただし、インシデント対応チームには Dynamics 365 のライセンスが付与されていない。彼らは既存の業務アプリのみを使う運用です。
同社はこの既存業務アプリと Dataverse を統合したいと考えています。
このとき、以下3つの記述の正誤を考えてみてください。
| # | 記述 | 答え |
|---|---|---|
| 1 | インシデント対応チームが Dataverse の顧客データを読み取るには、Dynamics 365 ライセンスが必要である | いいえ |
| 2 | 既存の業務アプリと Dataverse の通信は、Application User を使用して確立できる | はい |
| 3 | インシデント対応チームが顧客データを読み取れるようにするには、Dataverse でチームのメンバー（人間）にセキュリティ ロールを割り当てる必要がある | いいえ |
「なんで人間側にライセンスもロールもいらないの？」――その答えがまさに Application User にあります。順を追って見ていきましょう。
アプリケーション ユーザーとは何か
ひとことでいうと：
Microsoft Entra ID に登録された「アプリそのもの」を主体として、Dataverse 上で動作させるための特殊なユーザー
人間ではなく「アプリ」を Dataverse の世界に登録するイメージです。
普通のユーザーとの違い
| 観点 | 人間ユーザー | アプリケーション ユーザー |
|---|---|---|
| 認証主体 | 人（メール／パスワード／MFA） | アプリ（クライアント シークレットまたは証明書） |
| ライセンス | Dynamics 365 / Power Apps が必要 | 不要（Unlicensed） |
| ログイン | アプリ画面に対話的にログイン | サーバー間（S2S）で OAuth トークンを取得 |
| 退職・異動の影響 | あり | なし（アプリは退職しない） |
| 用途 | エンドユーザー業務 | バックエンド／統合／自動化 |
ポイントは「ライセンス不要」と「人ではなくアプリ」の2点です。
なぜ普通のユーザーで代用してはいけないのか
「Application User を作るのが面倒だから、社内の運用 ID（人間アカウント）を使い回せばいいじゃないか」――この発想で実装している現場、実は少なくありません。なぜ NG なのか、3つの理由を整理します。
理由1：ライセンス費用が無駄になる
人間ユーザーで Dataverse を叩くには、その人間に Dynamics 365 / Power Apps のライセンスが必要です。バッチ処理用に契約するライセンス代は、年間で見ると無視できない金額になります。Application User なら ライセンス0円 です。
理由2：退職・パスワード変更で本番が止まる
人間アカウントは退職・人事異動・パスワード変更で簡単に死にます。「夜間バッチが突然止まった → 担当者が退職して ID が無効化されていた」――これは現場でよくある事故です。Application User は人に紐づかないので、この事故が原理的に起きません。
理由3：資格情報をアプリに埋め込む脆弱性
人間アカウントの ID/パスワードを構成ファイルに書く、コードに埋め込む――これはセキュリティ監査で必ず指摘される重大リスクです。Application User なら、クライアント シークレットを Azure Key Vault に格納し、さらに 証明書ベース認証 に切り替えれば、より強固に運用できます。
認証の仕組み（5分でわかる OAuth 2.0 Client Credentials）
Application User の裏側で動いている認証フローは、OAuth 2.0 Client Credentials Grant と呼ばれるサーバー間専用のフローです。
カスタム Web アプリ
│
│ ① クライアント ID + シークレット（または証明書）を送る
▼
Microsoft Entra ID（トークン発行サーバー）
│
│ ② アクセストークンを返す
▼
カスタム Web アプリ
│
│ ③ Bearer トークンをヘッダーに付けて Dataverse Web API を叩く
▼
Dataverse
│
│ ④ トークンを検証し、対応する Application User の権限でデータを返す
▼
カスタム Web アプリ（結果を画面表示）
注目すべきは ④ です。Dataverse はトークンを検証したあと、Entra ID のアプリ ID から 対応する Application User を引き当てて、その Application User に付与されたセキュリティ ロールの範囲でデータアクセスを許可します。
「アプリを Dataverse の住人として登録しておく」――Application User とは、そういう仕掛けです。
作り方：5ステップ
実際の作成手順を整理します。
Step 1：Microsoft Entra ID でアプリ登録
Azure Portal → Microsoft Entra ID → App registrations → New registration
- アプリ名を入力（例：
Airport-Security-WebApp） - サポート対象アカウントは「シングル テナント」が基本
- Redirect URI はサーバー間連携なら不要
Step 2：クライアント シークレットまたは証明書を発行
登録したアプリの Certificates & secrets から発行。
- 本番運用なら証明書ベース認証を推奨（シークレットより安全）
- シークレットの場合は Azure Key Vault に保管
Step 3：Power Platform 管理センターで Application User を作成
- 環境 から対象環境を選択
- 設定 → ユーザー + アクセス → アプリケーション ユーザー
- + 新しいアプリ ユーザー
- Entra ID で登録したアプリを選択
- Business Unit、Email address を設定
- セキュリティ ロール を割り当てて保存
Step 4：必要最小限のセキュリティ ロールを設計
Application User にも当然ながら Dataverse のセキュリティ ロールを付与します。ここで大事なのは「最小権限の原則」。
- 既存の「System Administrator」を付与するのはやめましょう（権限が広すぎる）
- 業務に応じてカスタム ロールを作る（例：
Airport-Security-Read-Only） - 行レベル（ビジネス ユニット スコープ）も適切に絞る
Step 5：アプリ側のコードで OAuth トークンを取得
.NET / Python / Node.js / Java など、どの言語でも MSAL（Microsoft Authentication Library）を使えば数行で実装できます。
// .NET 例（MSAL.NET）
var app = ConfidentialClientApplicationBuilder
.Create(clientId)
.WithClientSecret(clientSecret)
.WithAuthority($"https://login.microsoftonline.com/{tenantId}")
.Build();
var result = await app
.AcquireTokenForClient(new[] { "https://yourorg.crm.dynamics.com/.default" })
.ExecuteAsync();
// result.AccessToken を Authorization: Bearer ... ヘッダーに付けて
// Dataverse Web API（/api/data/v9.2/contacts 等）を呼ぶ
これで、インシデント対応チームは Dynamics 365 のライセンスを持っていなくても、既存の業務アプリ越しに Dataverse を検索できるようになります。
重要ルール：「1 Entra アプリ : 1 Application User per 環境」
公式ドキュメントに明記されている重要な制約です。
In an environment, you can only have one application user for each Microsoft Entra-registered application.
（1つの環境内で、1つの Entra ID 登録アプリに対して作成できる Application User は1つだけ）
つまり、同じアプリで複数の Application User を環境内に作ることはできません。逆に、用途別にアプリを分けて登録すれば、それぞれを別の Application User として作成でき、ロールも個別に絞れます。
実務では「読み取り専用バッチ用アプリ」「書き込みバッチ用アプリ」のように Entra 側で2つ登録し、Application User もそれぞれ作るのが推奨パターンです。
PL-600 試験でのポイント整理
ここまでの内容を試験対策の視点でまとめます。
| 論点 | 出題されたら覚えておくこと |
|---|---|
| 外部アプリ → Dataverse の認証 | Application User + OAuth 2.0 Client Credentials |
| Application User のライセンス | 不要（Unlicensed） |
| セキュリティ ロールの付与先 | Application User 本体（外部アプリのエンドユーザー人間ではない） |
| 1 環境内の制約 | 1 Entra アプリにつき 1 Application User |
| 推奨される認証情報 | 証明書ベース認証 > クライアント シークレット（本番は証明書） |
| シークレット保管 | Azure Key Vault |
ケース解析：冒頭のコールセンター シナリオを解く
最初のシナリオに戻り、3つの記述の正解を確認します。
記述1：「インシデント対応チームが Dataverse の顧客データを読み取るには、Dynamics 365 ライセンスが必要」→ いいえ
インシデント対応チームのメンバー（人間）は Dynamics 365 アプリに直接ログインしないため、ライセンスを持つ必要はありません。彼らは既存の .NET 業務アプリを使っており、その業務アプリが Application User を介して Dataverse を叩きます。Application User はライセンス不要なので、対応チームのメンバーへのライセンス購入は発生しません。
記述2：「既存の業務アプリと Dataverse の通信は、Application User を使用して確立できる」→ はい
これがまさに本記事の主題。Application User は外部アプリと Dataverse のサーバー間連携のために用意された公式の仕組みです。
記述3：「インシデント対応チームのメンバー（人間）にセキュリティ ロールを割り当てる必要がある」→ いいえ
セキュリティ ロールは Dataverse のユーザー にしか割り当てられません。対応チームのメンバーは Dataverse のユーザーではない（ライセンスを持たない）ため、ロールを直接渡すことができません。ロールを割り当てるべき相手は Application User 本体です。
3問とも、Application User の本質を理解していれば一直線に解けるようになります。
よくある誤解 Q&A
Q1. Application User にも MFA は効きますか？
A. 効きません。Application User はサーバー間専用の認証主体で、対話的なログインを行わないため MFA の概念がそもそも適用されません。代わりに、クライアント シークレットや証明書の安全な保管・ローテーションが責任の中心になります。
Q2. Application User は条件付きアクセス（Conditional Access）の対象になりますか？
A. Workload Identities 向けの条件付きアクセス（Entra ID Premium P1/P2 が必要）に対応できます。位置情報や IP 範囲などで Application User の利用を制限できます。
Q3. Application User の所有レコードはどうなる？
A. Application User が作成したレコードは Application User が「所有者」になります。本番運用ではこれが想定外の影響を生むため、作成直後に所有者を別ユーザーに付け替える設計を入れることがあります。
Q4. Managed Identity でも Application User を作れる？
A. 作れます。Azure リソース（Functions / Logic Apps Standard / App Service など）に割り当てた マネージド ID を、Application User として登録できます。シークレット管理が完全に不要になるため、Azure ホストのアプリでは積極的に検討する価値があります。
Q5. 削除はできる？
A. 一度 非アクティブ化（Deactivate） したあと、削除（Delete） できます。削除前に、その Application User が所有しているレコードを別ユーザーに再割り当てする必要があります。
まとめ
- 外部アプリから Dataverse を呼ぶときは Application User を使うのが Microsoft 公式の正解
- ライセンス不要・サーバー間専用・人に紐づかない という3点が中核の利点
- 認証は OAuth 2.0 Client Credentials。シークレットより証明書ベースを推奨
- セキュリティ ロールは Application User 本体 に最小権限で付与する
- PL-600 では「外部アプリ × Dataverse」の文脈で頻出。反射的に Application User を思い出せるかが分かれ目
「外部アプリと Dataverse を繋ぐ、安全で経済的な架け橋」――それが Application User の正体です。ホテルのコンシェルジュ（Application User）が、ロビーにいる宿泊客（外部アプリのユーザー）の代わりに、奥の金庫室（Dataverse）の鍵を開ける――そんなイメージで覚えると腹に落ちやすいかもしれません。宿泊客（人間）には金庫室の鍵もホテル従業員バッジ（ライセンス）も渡さず、コンシェルジュ（Application User）にだけ必要最小限の鍵（セキュリティ ロール）を持たせる、という設計です。
参考リンク
- Manage application users in the Power Platform admin center | Microsoft Learn
- System and application users | Microsoft Learn
- Create users in the Power Platform admin center | Microsoft Learn
- OAuth 2.0 Client Credentials Grant | Microsoft Identity Platform
最後まで読んでいただきありがとうございました。
為になった、応援して下さる方はいいね・フォローをして下さると嬉しいです。