別テナントでアプリ登録したのに、利用先テナントの「エンタープライズ アプリケーション」にサービス プリンシパルが出てこない――Microsoft Entra IDでよくあるつまずきです。本記事では、App registrations と Enterprise applications の違いから、見つからない原因の切り分け、Graph/PowerShellでの確認方法まで実務目線で解説します。
結論：別テナントで使うアプリの実体は「サービス プリンシパル」で、探す場所は Enterprise applications
Microsoft Entra ID（旧 Azure AD）では、同じ“アプリ”でもテナントをまたぐと見え方が変わります。別テナントでアプリ登録（App Registration）した場合、利用先テナントに存在するのはアプリケーション オブジェクトではなく、そのテナントに作成されるサービス プリンシパル（Enterprise applications 側の実体）です。
そのため、利用先テナントで「App registrations（アプリの登録）」を検索しても見つからない／一部しか見えないのは珍しくありません。まずはMicrosoft Entra ID → Enterprise applications（エンタープライズ アプリケーション）でサービス プリンシパルを追う、これが最短ルートです。
テナントをまたぐと何がどこに作られるのか
「どこに何が存在するか」を最初に整理しておくと、探す場所がブレません。
| 場所 | 存在するもの | 代表的な操作 | 備考 |
|---|---|---|---|
| ホームテナント（アプリを登録したテナント） | アプリケーション オブジェクト（App registration） | リダイレクトURI、証明書/シークレット、APIアクセス許可、マルチテナント設定 | “設計図”を持つのはここ |
| 利用先テナント（アプリを使うテナント） | サービス プリンシパル（Enterprise application） | ユーザー/グループ割り当て、同意（Consent）、条件付きアクセス、SAML設定など | “実体”を持つのはここ |
この構造のため、利用先テナントで起こるトラブルは、ほぼすべて「サービス プリンシパル側の可視性・同意・割り当て」で説明がつきます。
App registrations と Enterprise applications は“管理対象”が違う
混乱の原因はここに集約されます。管理画面の名称が似ていても、実際に管理しているオブジェクトが異なります。
| 管理画面 | 主に管理しているもの | 対象になる典型例 | よくある勘違い |
|---|---|---|---|
| App registrations（アプリの登録） | アプリケーション オブジェクト（設計図） | 自分のテナントで作ったアプリ、リダイレクトURI、証明書/シークレット、APIアクセス許可 | 他テナントで使うときもここに出ると思い込む |
| Enterprise applications（エンタープライズ アプリケーション） | サービス プリンシパル（各テナント内の実体） | ギャラリーアプリ、SAML/OIDC連携、マルチテナントアプリの利用実体、同意・割り当て | “アプリ登録＝ここにも自動で出る”と思い込む |
イメージとしては、App registrations が「アプリの設計図」、Enterprise applications が「そのテナントで稼働する個体」です。別テナントで登録されたアプリを利用する側では、設計図を直接いじることはできません。利用側でできるのは、サービス プリンシパルに対して「同意」「割り当て」「条件付きアクセス」「プロパティ制御」などを行うことです。
まずはこれ：ポータルでサービス プリンシパルを探す手順
“見当たらない”の多くは、実は検索の起点（テナント/画面/フィルター）がズレています。次の流れで、機械的に潰していくと迷いにくいです。
- Azure ポータル（または Microsoft Entra 管理センター）にサインインする
- 右上のアカウントメニューで利用先テナントに切り替わっていることを確認する（ディレクトリの切り替え）
- Microsoft Entra ID を開く
- Enterprise applications（エンタープライズ アプリケーション）を開く
- 一覧で「すべてのアプリケーション」など、対象が狭くならないフィルターになっていることを確認する
- 検索欄にアプリ名、可能ならApplication (client) IDも使って該当のサービス プリンシパルを探す
検索がヒットしないときのコツ
- 表示名（Display name）だけに頼らない：表示名は変更されることがあります。可能なら後述の「Application (client) ID（= appId）」で探します。
- フィルターを疑う：画面上部に「すべてのアプリケーション」「自分が所有するアプリ」「ギャラリーのみ」などの絞り込みがある場合、意図せず対象外になっていることがあります。
- “アプリの種類”の違いを意識する：Microsoft が提供する既定アプリ、ギャラリーアプリ、独自アプリ（Non-gallery）で表示上の分類が変わることがあります。
- “最近追加したはず”でも焦らない：同意や作成の直後は、管理画面の反映タイミングや検索インデックスの都合で見つけにくいことがあります。ID検索（Graph/CLI）で先に存在確認すると早いです。
一覧に出てこない／一部しか見えないときの切り分け早見表
現場で遭遇しがちな原因と、最短で確認できるポイントを表にまとめます。上から順にチェックすると、手戻りが減ります。
| 症状 | よくある原因 | 最初に見る場所 | 対処の方向性 |
|---|---|---|---|
| App registrations には見えない | 利用先テナントにはアプリケーション オブジェクトが無い（正常） | Enterprise applications | サービス プリンシパルを探す/同意を確認する |
| Enterprise applications にも見えない | まだサービス プリンシパルが作られていない（同意未実施/未使用） | 同意URL、または Graph/PowerShell | 管理者同意でサービス プリンシパルを生成する |
| 一部の人だけ見えない | ロール/閲覧権限の差、一覧の絞り込み | ユーザーのロール、フィルター | 適切な管理ロール付与、フィルター解除 |
| 昔はあったのに消えた | サービス プリンシパルが削除された（論理削除を含む） | Enterprise applications の削除済み | 復元、または再同意で再作成 |
| 別名で存在するように見える | 表示名変更、複数のサービス プリンシパル、同名アプリの混在 | Application (client) ID / appId | IDベースで突合して正体確認 |
「権限は付与したはずなのに…」が起きる理由
この手の相談で多いのが、「App registrations で API permissions を設定して、管理者同意も押した。なのに利用先テナントでサービス プリンシパルが見えない」というケースです。
ホームテナントでの“権限設定”と、利用先テナントでの“同意”は別物
App registrations で設定する API permissions は、あくまでアプリ（アプリケーション オブジェクト）がどの API を要求するかという宣言です。これだけでは、別テナントにサービス プリンシパルが自動作成されるとは限りません。
利用先テナント側にサービス プリンシパルが作成される代表的なタイミングは次のとおりです。
- 管理者が管理者同意（Admin consent）を実行したとき
- ユーザー同意が許可されている環境で、初回サインイン時に同意が行われたとき
- ギャラリーアプリとして追加したとき（SAML/OIDC等）
逆に言うと、利用先テナントで同意が一度も行われていない場合、サービス プリンシパルが存在しない/見えないことがあります。特に、検証環境で「設定だけしたが実際のサインインや同意をしていない」場合に起こりがちです。
テナント切り替えミスを防ぐチェックポイント
“別テナントの話”になると、実は画面を見ているテナントが違うだけ、というケースが非常に多いです。以下を確認してください。
- ポータル右上のアカウントメニューでディレクトリ名が想定通りか
- 複数ディレクトリに所属している場合、検索結果が「現在のディレクトリ」に限定されていないか
- B2Bゲストとしてサインインしている場合、ゲスト権限の範囲内の情報しか見えていない可能性がある
アプリが“マルチテナント”でないと、そもそも別テナントに実体が作れない
別テナントで利用する前提なら、アプリ登録側（ホームテナント側）でサポートされるアカウントの種類（Supported account types）がマルチテナントになっている必要があります。
- シングルテナント：そのテナントのユーザーのみ（他テナントで同意しても使えない/作れないことがある）
- マルチテナント：任意の組織ディレクトリのユーザー（別テナントにサービス プリンシパルが作られる前提）
「別テナントで使う想定なのに、登録時にシングルテナントのままだった」というのは定番の落とし穴です。アプリの目的が社内限定か、外部テナントでも利用させるかで、設計自体が変わります。
削除された可能性を確認する（論理削除・復元）
“以前は見えていたのに突然見えない”場合、サービス プリンシパルが削除された可能性があります。Entra ID では削除後もしばらく復元できる（論理削除）ことがあるため、まずは削除済みを確認します。
サービス プリンシパル（Enterprise applications 側）を削除していないか
- Microsoft Entra ID
- Enterprise applications（エンタープライズ アプリケーション）
- 削除済み（Deleted applications / Deleted enterprise applications などの項目）を確認
アプリケーション オブジェクト（App registrations 側）を削除していないか
ホームテナント側でアプリ自体が削除されていると、利用先テナントでの運用にも影響します。ホームテナントで次を確認してください。
- Microsoft Entra ID
- App registrations（アプリの登録）
- Deleted applications（削除済みアプリ）
復元できる期間や条件はテナントの状態や操作により異なるため、「削除済みに見当たらない＝完全に消えた可能性」もあり得ます。その場合は、後述の方法でサービス プリンシパルを再作成するのが現実的です。
GUIで見つからないときは“IDで突合”するのが最短（client ID / appId）
表示名検索は便利ですが、同名アプリが存在したり、表示名が途中で変わったりすると沼に入ります。確実に正体を確認するなら、次の ID を押さえます。
| 名称 | 別名 | どこで取れる | 用途 |
|---|---|---|---|
| Application (client) ID | clientId / appId | ホームテナントの App registrations → 対象アプリの概要 | 別テナント側でサービス プリンシパルを特定する最重要キー |
| Directory (tenant) ID | tenantId | Microsoft Entra ID → 概要 | 同意URL、トークン発行先の指定 |
| Object ID | – | App registrations / Enterprise applications の各オブジェクトに存在 | Graph/PowerShellでの操作対象（※アプリとSPで別ID） |
Microsoft Graph PowerShell でサービス プリンシパルの存在を確認する
ポータルで見えなくても、Graph で検索すると存在が分かることがあります。利用先テナントに対して、appId（= clientId）でサービス プリンシパルを引くのが定番です。
# 例：Microsoft Graph PowerShell（利用先テナントに接続した状態で実行）
# 必要に応じて Connect-MgGraph -TenantId {tenantId} -Scopes "Application.Read.All" などを実施
Get-MgServicePrincipal -Filter "appId eq 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'" |
Select-Object Id, AppId, DisplayName結果が返れば、そのテナントにはサービス プリンシパルが存在します。ポータル検索やフィルター、閲覧権限を疑ってください。結果が空なら、未作成か削除済みの可能性が高いです。
Azure CLI でサービス プリンシパルを検索する
# 例：表示名で検索（同名がある場合は注意）
az ad sp list --display-name "アプリ名" --query "[].{displayName:displayName, appId:appId, id:id}" -o table
# 例：appId で検索（確実）
az ad sp list --filter "appId eq 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'" --query "[].{displayName:displayName, appId:appId, id:id}" -o tableこちらも、利用先テナントにログインしていることが前提です。意図せずホームテナントで実行すると、別の結果が返ります。
サービス プリンシパルが無い場合：作成（同意）する方法
「存在しない」ことが確認できたら、次は作成です。多くのケースでは、利用先テナントで管理者同意を実行するとサービス プリンシパルが生成されます。
管理者同意（Admin consent）を使う
管理者同意は、ユーザー任せにせずテナント管理者が一括で同意する方法です。利用先テナントの管理者権限を持つアカウントで実施します。
- 同意の対象：要求している API アクセス（委任/アプリケーション権限）
- 結果：利用先テナントにサービス プリンシパルが作成され、同意が記録される
管理者同意用 URL の代表例（プレースホルダー）は次のような形です。{tenant-id} は利用先テナント、{client-id} はアプリの Application (client) IDを指定します。
https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}この URL を利用先テナントの管理者で開き、同意を完了すると、Enterprise applications にサービス プリンシパルが作成されるのが一般的です。もし同意画面に進めない場合は、アプリがマルチテナントになっていない、同意ポリシーでブロックされている、発行元が未検証のため制限されているなど、別要因の可能性があります。
Azure CLI でサービス プリンシパルを作成する（作成できる場合）
権限とアプリの設定条件を満たしていれば、利用先テナントでサービス プリンシパルを作成できることがあります。
# 例：利用先テナントで appId を指定してサービス プリンシパルを作成
az ad sp create --id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx作成後は Enterprise applications に表示されるか、Graph で確認してください。作成できない場合は、アプリがマルチテナントではない、もしくはテナント側の制約（同意ポリシーや権限）によりブロックされている可能性があります。
“一部しか見えない”の正体：権限（ロール）と可視性の問題
同じテナントを見ているのに、Aさんには見えてBさんには見えない場合、原因はほぼロールかポータルの可視化設定です。
| やりたいこと | 必要になりやすいロール（例） | 補足 |
|---|---|---|
| Enterprise applications の全体を管理/閲覧したい | Global Administrator / Cloud Application Administrator / Application Administrator | テナントの設定により閲覧だけでも制限される場合があります |
| 特定アプリだけを運用したい | アプリの所有者（Owner）や、限定された管理ロール | “所有者のみ見える”絞り込みや、アクセス権の差に注意 |
運用上は、「誰がサービス プリンシパルを管理するか」を決め、最低限のロールで回すのが理想です。ただしトラブルシュート時は、まずは管理者ロールを持つアカウントで存在確認を行い、“本当に無いのか／見えていないだけか”を切り分けるのが近道です。
よくある勘違い集（ハマりどころを先回り）
- 「別テナントのアプリは App registrations に出るはず」：基本は出ません。出るのはそのテナントで作ったアプリ（アプリケーション オブジェクト）です。
- 「権限を付けた＝利用先にも反映される」：権限の“要求”と“同意”は別です。利用先テナントでの同意が必要になります。
- 「表示名で検索すれば一意に決まる」：同名や改名で混乱します。clientId（appId）で突合するのが確実です。
- 「サービス プリンシパルを消しても影響は小さい」：同意情報や割り当てが消えるため、実運用では影響が大きいです。削除前に影響範囲を確認しましょう。
再発を防ぐための運用メモ
最後に、同じ問題を繰り返さないための“地味だけど効く”運用ポイントです。
- clientId（appId）とtenantIdを必ず台帳化：表示名よりも ID を一次情報として残す
- サービス プリンシパルの所有者（Owner）を設定：退職/異動で管理不能にならないようにする
- 同意の実施履歴を残す：いつ、誰が、どの権限に同意したか
- 不要になったら“削除”ではなく“無効化/アクセス遮断”も検討：急な削除は障害の元。段階的に止める
- トラブルシュート手順を固定化：ポータル → ID突合（Graph/PowerShell）→ 同意/再作成 の順で迷いを減らす
「サービス プリンシパルが見つからない」は、Entra ID の概念（アプリケーション オブジェクトとサービス プリンシパル）を一度理解すると、再現性をもって切り分けできるようになります。まずは Enterprise applications を起点に、IDベースで淡々と確認していくのが最短ルートです。
コメント