「Microsoft Entraアプリ」は何ができるのか、ユースケースで理解する

2025年12月24日 15時00分更新

文● 西川優一郎／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「ユースケースから見る、Entraアプリでできること(個人的まとめ)」を再編集したものです。

　業務でAzureのMicrosoft Entra IDに触れることがよくあるのですが、「Entraアプリは何ができるのか」かんたん・ざっくりと理解できる記事があまりないような気がしました。というわけで、本記事では、常日頃何気なく使っている「アプリの登録」でできることを面白そうなものに絞ってざっくりお届けしていこうと思います。

事前のご案内

　本記事は、イメージをカジュアルにお伝えしたい意図により「厳密には異なる」表現をしていることがあります。

　また、シークレットトークン等は厳重に管理頂き、アクセス許可は最小限のスコープでご利用いただきますようご留意ください。

　本記事の内容を業務等でご利用される場合は、公式ドキュメントの確認や技術検証を行って最新の情報で実施頂けますと幸いです。

アプリの登録とは

　Microsoft Entra IDの「アプリ」という概念は、ざっくりいうとMSが提供するサービスにアクセスできるBotアカウントと、Oauth2.0のクライアントがセットになった概念です。

　Microsoft Learn(公式ドキュメント)上では、単に「アプリケーション」と表現されます。[link]

　「アプリの登録」タブへは、Azure Portal上のMicrosoft Entra IDページ内にある管理タブの中から飛ぶことができます。

　「新規登録」からアプリを作成すると、アプリの作成後の画面でシークレットトークンを発行することができます。

　よく使われるケースとしては、アプリをテナントと紐づけた状態でシークレットトークンを発行し、BotとしてAzureやMicrosoft製品のAPIを利用するなどがあります。

　こちらが新規登録画面です。

　この画面にある「サポートされているアカウントの種類」は、イメージとしては、新規登録と同時に「自テナント」や「個人Microsoftアカウントのテナント」等のどこで使えるようにするかというものです。

　ここで「自分の組織で使う」選択肢を選ぶと、自分のEntraテナントへは「アプリケーション」が自動で「紐づいた」状態になります。

　また、「リダイレクトURI」の入力ボックスがありますが、こちらはEntra IDでOauth2.0やOIDCを使用するときのパラメータになります。

　特定のユースケース以外では入力の必要はありません。

「紐づける」の正体

　ここまで、アプリケーションとテナントを「紐づける」という表現をしましたが、実は「紐づける」は正しい表現ではありません。
正しくは「使用したいテナントに、実体のBotアカウント(Service Principal ≒ エンタープライズアプリケーション)を作成する」というものになります。

　実は、Entra IDの「アプリケーション」は概念ですので、単体ではどのAzureテナントやMS製品にもアクセスすることは出来ません。

　そこで、操作するリソースがある「Entra IDテナント」ごとにService Principal（Botとしてのアカウント）が作られ、Service Principalが実際にアクセスする・編集するといった挙動をやってくれることになっているのです。

　アクセスするための認証情報は「アプリケーション」が払い出す形ですが、実際にアクセスするのは「Service Principal」なのが、すこしややこしいですね。

（※ 本記事では、わかりやすさのために「紐づける」として表現します）

Entra アプリでできること

　Entra IDの「アプリケーション」でできることを、今回語りたいユースケースに絞って図に起こしてみました。

　「アプリケーション」は、アクセスしたいテナントやサービスを「紐づける」ことで、ひとつのアプリからたくさんのリソースにアクセスできます。

　今回は、こちらの図を基にユースケースをご紹介していきます。

複数のテナントを操作する

　「アプリケーション」を複数のテナントと紐づけることで、ひとつの認証情報を用いて複数のテナントにアクセスすることができます。

　自分では試していないのですが、アプリケーションのIDを控えたうえで、Entra IDの編集権限を持つ組織内にて az ad sp create --id {アプリケーションのID} を打つことで、ログインしているテナントに紐づけられそうです。 [link]

　実際には、紐づけたあとに、操作したいリソースグループやサブスクリプションへ権限を付与する必要があります。

Sharepointを操作する

　「アプリケーション」は、Azureに限らず、Microsoftのだいたいのサービスの認証にも使うことができます。

　SharePointも例外ではなく、スクリプト等を用いてSharepoint内に自動でファイルをアップロードしたり、ダウンロードしたりすることができます。

　このとき注意しておきたいのは、利用するサービスごとに、「アプリケーション」(アプリがあるテナント)と「エンタープライズアプリケーション」(実際に使いたいSharepointがあるEntraIDテナント)、両方への設定が必要な点です。

　「アプリケーション」は、作ったアプリケーションの管理画面にある「APIのアクセス許可」から使いたいサービスの登録をする必要があります。

　また、「エンタープライズアプリケーション」では、アプリケーションが作成したエンタープライズアプリケーションの管理画面にある「セキュリティ」 > 「アクセス許可」から使いたいサービスへのアクセス許可の付与を行いましょう。

　両方設定出来たら、アプリケーションの認証情報を使ってAPIを叩くことが出来るようになります。

委任アクセスとは？

　「アプリケーション」の「APIのアクセス許可」でサービスを追加する際、「委任されたアクセス許可」か「アプリケーションの許可」の選択肢が出ることがあります。

　「アプリケーションの許可」は、普通のBotアプリと同様で、アプリケーション自身(Service Principal自体)にアクセスの許可が与えられる形のものです。

　「委任されたアクセス許可」は、「アプリケーション」で払い出されるClient ID等を用いてOauth2.0認証をユーザにしてもらい、その結果のトークンでアクセスする形のものとなります。こちらだと、ユーザとしてリソースにアクセスすることができます。

他のクラウド・サービスから操作する

　Entra IDのアプリケーションは、リソースの操作も、IdPの操作も、IdPを組み合わせたリソースの操作もできるのですが、ここまで、一律でEntra IDの「アプリケーション」で払い出される認証情報を用いるユースケースをご紹介してきました。

　一方、Entra ID「アプリケーション」の認証情報を用いずに、OIDC Connect対応の別のOIDCから払い出されたシークレットを使って(交換して)Azureのリソースを触ることもできます。

　それが、「ワークロード ID フェデレーション」です。 [link]

　こちらを使うと、「アプリケーション」の認証情報の代わりに、任意の別のIdP(OIDC対応)の認証情報を使ってAzureリソースへアクセスできるようになります。

　この設定は、「アプリケーション」管理ページの「認証とシークレット」タブにある「フェデレーション資格情報」から可能です。
GitHubのGitHub Actions用の設定なら、専用の入力画面が用意されていて簡単に設定できます。

認証機能として活用する

　Entra IDのアプリケーションは、Oauth2.0のクライアントとしても使うことができます。

　これを活用することで、自前でIdPを用意しなくても簡単にログイン機能付きのシステムを作れるようになります。

　また、Entra IDの「アプリケーション」には「アプリロール」という概念があり、任意の名前の「ロール」を複数作成してアプリで活用することもできます。[link]