Microsoft Entra IDにおける Enterprise Applications と App Registrations

Microsoft Entra ID（旧Azure Active Directory）は、クラウド時代のアイデンティティ管理の中心的存在です。しかし実際に運用を始めると、「Enterprise Applications」と「App Registrations」という、よく似た2つのメニューに戸惑う人も多いのではないでしょうか、自分もはじめよくわかっていませんでした。

どちらも「アプリケーションをEntra IDで管理するための仕組み」ですが、実際には役割と視点がまったく異なります。今日はこの2つの違いをわかりやすく整理して解説します。

Enterprise Applications（エンタープライズアプリケーション）とは

Enterprise Applications は、Entra IDテナント内で実際にユーザーが利用するアプリケーションを管理する機能です。組織で導入しているSaaS（Microsoft 365、Salesforce、ServiceNowなど）や、自社開発アプリをここに登録し、シングルサインオン（SSO）やアクセス制御を統一的に行います。

主な役割

• ユーザーやグループへのアプリ割り当て
• シングルサインオン（SSO）の設定
• 条件付きアクセスや多要素認証（MFA）の適用
• 利用ログ／監査ログの確認
• 自動プロビジョニング（SaaSとのアカウント同期）

これらは「アプリを使う側の管理」にあたります。
すでにEntra Application Galleryに登録されたSaaSアプリを導入する場合は、ほとんどがここで完結します。

App Registrations（アプリ登録）とは

App Registrations は、Entra IDで認証・認可を使うために、アプリを登録する仕組みです。主に開発者やシステム管理者が、自社アプリをEntra IDと連携させるときに利用します。

登録で得られる情報

• アプリケーション（クライアント）ID
• ディレクトリ（テナント）ID
• リダイレクトURI（認証後の戻り先URL）
• 認証証明書やクライアントシークレット
• APIアクセス権限（Microsoft Graphなど）

これらを設定することで、アプリケーションがOAuth 2.0やOpenID Connectを用いて安全に認証・認可を実行できます。App Registrationsで作成された「アプリケーションオブジェクト」は、Entra IDテナント内に対応する「サービスプリンシパル」として反映されます。このサービスプリンシパルこそが、Enterprise Applicationsの一覧に現れるアプリです。

メニューごとの説明

Microsoft Entra IDの App Registration（アプリ登録） は、アプリケーションがEntra IDを「認証プロバイダ」として使うための設定領域です。ここで登録されたアプリは、OAuth 2.0 や OpenID Connect を用いて「ユーザーを認証」したり、「Microsoft GraphなどのAPIへアクセス」したりできます。

登録後は、次のようなサイドメニューが表示されます：

Branding & Properties（ブランディングと基本プロパティ）

このセクションでは、アプリの表示名・ロゴ・リダイレクト先情報・発行者情報など、ユーザーに見える部分を定義します。

項目	内容
Name	アプリの表示名（サインイン時や同意画面で表示される）
Publisher Domain	発行者ドメイン（例：yourcompany.com）
Logo	サインイン時に表示されるアプリのアイコン
Home Page URL / Terms of Service / Privacy Statement	組織ポリシーに応じたリンク設定
Assignment Required	管理者がユーザー割り当てを明示的に行う必要があるかを制御

Microsoft 365 や Teams と連携するアプリの場合、ここで設定したロゴや発行者情報がユーザーの同意画面やTeamsタブ上で表示されるため、信頼性を示す重要な設定です。

Authentication（認証）

アプリがどのようにサインインを処理するかを定義するセクションです。OpenID ConnectやOAuth 2.0の仕様に基づき、リダイレクトURIやログアウトURL、許可するフローなどを設定します。

項目	内容
Redirect URIs	認証後にユーザーが戻るURL。Webアプリやモバイルアプリごとに設定。
Front-channel / Back-channel Logout URL	サインアウト後の遷移先。SSO環境では重要。
Implicit Grant & Hybrid Flows	トークンを直接ブラウザ経由で受け取るかどうかを指定。
Supported account types	サインイン可能なアカウント範囲（自組織／複数組織／個人MSアカウント）

たとえばBlazorやASP.NET CoreアプリでMSAL（Microsoft Authentication Library）を使う場合、この設定が正しくないと 「invalid_redirect_uri」 などのエラーが出ます。

Certificates & Secrets（証明書とシークレット）

アプリがEntra IDと安全に通信するための「資格情報（クレデンシャル）」を設定します。サーバーサイドアプリやバックエンドAPIがアクセストークンを取得する際に使用されます。

項目	内容
Client Secrets	アプリ用の共有シークレット（パスワードのようなもの）
Certificates	公開鍵証明書を登録し、非対称鍵で認証する場合に利用

クライアントシークレットは最も一般的な方法ですが、有効期限切れに注意。 証明書ベース認証はセキュリティが高く、自動化ジョブやデーモンアプリに適しています。

Token Configuration（トークン構成）

Entra IDが発行する IDトークンやアクセス トークンに含まれるクレーム（claims） を定義します。
クレームとは、ユーザーID、メール、役職などの属性情報です。

トークンのサイズやAPI設計に関係するため、最小限の必要情報のみを含めるのが推奨です。

API Permissions（APIアクセス許可）

アプリがMicrosoft Graphや他のAPIにアクセスする際の権限スコープを指定します。
例えば、ユーザーのプロフィールを取得したり、メールを送信したりする場合に設定します。

種類	意味
Delegated permissions	サインインしたユーザーの権限で動作（ユーザーの代理）
Application permissions	サインインなしで動作（バックエンドや自動ジョブなど）

管理者承認が必要な権限（例：User.Read.All, Mail.Send）は、“Grant admin consent” を押すことで全社的に許可できます。

Expose an API（APIを公開する）

自社で作成したWeb APIを、他のアプリケーションが呼び出せるように スコープ（Scopes） を定義する機能です。たとえば "api://{client-id}/read" のように独自スコープを定義し、クライアントアプリに許可できます。

• Application ID URI：APIを一意に識別するURI。
• Scopes defined by this API：呼び出し権限（例：read, write）を作成。
• Authorized client applications：アクセスを許可するクライアントアプリを指定。

複数の内部サービスを構築する企業では、ここを正しく設計することで社内API連携を統一的に認可管理できます。

App Roles（アプリロール）

アプリケーション内で利用する「ロール」をEntra ID側に定義できます。これにより、「管理者」「閲覧者」「編集者」などの役割をEntra ID上で付与・制御できます。

• ユーザーやグループに直接ロールを割り当て可能。
• トークンに roles クレームが含まれるので、アプリ側でロールベース認可を実装可能。
• 企業向けマルチテナントアプリでは特に有効。

Manifest（マニフェスト）

App Registrationのすべての設定は、JSON形式のマニフェストファイルとして表現されます。
GUIから設定できる内容だけでなく、より細かい制御（例えばカスタムロールや独自の許可設定）もここで編集可能です。慣れてくるとここだけで完結します。

• 設定のバックアップ・テンプレート化に便利。
• インフラ自動化（IaC）やデプロイスクリプトでも活用できる。

両者の関係

App Registration (開発者が登録)
│
├──> Application Object（アプリの設計図）
│
└──> Service Principal（テナントごとの実体）
│
└──> Enterprise Applicationとして表示される

• App Registrations：アプリを定義する“設計図”
• Enterprise Applications：その設計図をもとにテナント内で実際に動く“インスタンス”

という関係です。この構造を理解しておくと、アプリ開発と管理の両面で混乱がなくなります。

使い分け

Entra IDでは、アプリの「登録」と「利用」が明確に分離されています。
同じアプリでも、提供する側（開発者・ベンダー）と利用する側（顧客・テナント管理者）　では見える画面も役割も異なります。

たとえば自社でTeamsアプリやSaaSを開発し、Microsoft App SourceやMarketplaceで公開して課金する場合、開発者側は App Registration を作成してアプリを定義します。一方、そのアプリをインストール・購入した企業のEntra IDテナントには、自動的に Enterprise Application が生成され、ユーザー割り当てやアクセス制御を行えるようになります。

言い換えると、

「App Registration」は“アプリを作る人”のもので、
「Enterprise Application」は“アプリを使う人”のもの。

シナリオ	使用する機能	解説
SalesforceやServiceNowなどの外部SaaSをSSOで導入したい	Enterprise Applications	既存のギャラリーアプリを追加し、ユーザーを割り当てて利用開始。SSO・条件付きアクセスなどを設定。
自社で開発したWebアプリをMicrosoftアカウントやEntra IDで認証させたい	App Registrations	開発者が新規登録し、クライアントID・シークレットを取得してOAuth認証を構築。Graph APIやTeams統合にも利用。
他社が開発したアプリを自社テナントに導入したい	Enterprise Applications（自動生成）	相手側のApp Registrationに基づくサービスプリンシパルが自動的に生成され、自社側でアクセス管理が可能に。
自社で開発したTeams／WebアプリをMicrosoft Marketplaceで販売したい	App Registrations（開発者側） ＋ Enterprise Applications（購入者側）	開発者はApp Registrationでアプリを定義し、Marketplaceに公開。購入・インストールした顧客テナントでは、その登録に基づくEnterprise Applicationが生成され、ユーザー割り当て・課金・アクセス制御を行う。
自社内で複数の内部システム間（API連携など）を安全に認証させたい	App Registrations（内部API）＋Enterprise Applications（利用側）	API提供側でスコープをExposeし、利用側がそれを承認して呼び出す。システム間通信に最適。

視点	管理対象	表示場所	典型的な操作
アプリ提供者（開発者・ISV）	アプリの定義・認証設定	App Registrations	クライアントID・スコープ・証明書・API公開
アプリ利用者（顧客企業・管理者）	実際にテナント内で動作するアプリ	Enterprise Applications	ユーザー割り当て・SSO・条件付きアクセス・監査

次

次回（予定は未定）はOAuth2.0とEntraIdで実際にアプリを作るところを紹介したいと思います。

そして仲間募集中

一緒に仕事する仲間を絶賛募集しています、募集内容はこちらを参照くださいませ。