Microsoft Entra のアプリ登録やエンタープライズ アプリを手作業で管理している場合、今後は Microsoft Graph を使った自動化を前提に運用を見直す価値があります。公式ドキュメント「Programmatically Manage Microsoft Entra Apps Using Microsoft Graph」は、アプリの作成、サービス プリンシパルの作成、権限設定、所有者管理、資格情報ポリシーまでを Microsoft Graph で扱うための実務的な手順をまとめた内容です。(Microsoft Learn)
注意点として、確認できる公式ドキュメントのメタデータでは ms.date が 07/03/2025、Microsoft Learn 画面下部では Last updated on 2025-07-04 と表示されています。2026年7月3日付の更新情報として社内展開する場合は、Microsoft 365 管理センターのメッセージセンター、Microsoft Learn の更新履歴、社内で参照している通知元を照合してから反映するのが安全です。(GitHub)
結論から言うと、この情報は「既存テナントに自動で設定変更が入る」という告知ではありません。Microsoft Entra アプリのライフサイクル管理を、管理センター上の手作業から Microsoft Graph API、Microsoft Graph PowerShell SDK、CI/CD スクリプトへ移すための実装ガイドです。ただし、Azure AD Graph から Microsoft Graph への移行が終わっていない環境では、別途、移行対応が必要です。Azure AD Graph は非推奨となり、延長アクセスの終了日も公式ドキュメントで示されています。(Microsoft Learn)
Microsoft Entra アプリ管理で今回押さえるべきポイント
今回の公式情報で重要なのは、Microsoft Entra のアプリ管理を「アプリ登録を作る」だけでなく、関連するサービス プリンシパル、API 権限、アプリ ロール、所有者、証明書・シークレット、テナント単位の資格情報ポリシーまで一連のライフサイクルとして扱っている点です。Microsoft Graph は、Microsoft Entra アプリと関連するサービス プリンシパルを作成・構成・管理する統一 API として説明されています。(Microsoft Learn)
| 確認項目 | 実務での意味 | 管理者が見るべきポイント |
|---|---|---|
| アプリケーション オブジェクト | アプリ登録そのものを表す | displayName、appId、リダイレクト URI、API 権限、アプリ ロールを棚卸しする |
| サービス プリンシパル | テナント内で利用されるアプリの実体 | エンタープライズ アプリ、所有者、割り当て必須設定、資格情報の保護を確認する |
| API 権限 | アプリが要求する権限 | requiredResourceAccess の更新時に既存権限を消さないようにする |
| 所有者 | 障害対応・棚卸しの責任者 | 所有者なし、または所有者1名だけのアプリを検出する |
| 資格情報ポリシー | シークレットや証明書の統制 | 証明書の有効期間、信頼済み CA、ロック設定を設計する |
このドキュメント単体では、全テナントに対する強制的な設定変更や新しい移行期限は示されていません。一方で、Azure AD Graph を使い続けているアプリケーションやサービス プリンシパルは、Microsoft Entra の推奨事項や Microsoft Graph への移行計画として別途対応が必要です。(Microsoft Learn)
アプリ登録とサービス プリンシパルをコードで作成できる
Microsoft Graph では、POST /applications に displayName を指定して Microsoft Entra アプリを登録できます。作成後の応答には、テナント内で一意の id と、Microsoft Entra ID エコシステム全体で一意の appId が含まれます。続いて POST /servicePrincipals に appId を指定すると、そのアプリに対応するサービス プリンシパルを作成できます。(Microsoft Learn)
実務では、次のような場面で効果が出ます。
| 活用シーン | 手作業の課題 | Microsoft Graph 化した場合 |
|---|---|---|
| SaaS 連携アプリの登録 | 担当者ごとに名前や設定がぶれる | 命名規則、タグ、所有者をテンプレート化できる |
| 開発・検証・本番の環境差分管理 | 本番だけ設定漏れが起きやすい | 同じスクリプトで再現性を担保できる |
| 監査対応 | いつ誰が何を作ったか追いづらい | Git、CI/CD、ログで変更履歴を残しやすい |
| グローバル拠点展開 | 地域ごとの手順差が出やすい | 共通ポリシーをコードとして配布できる |
たとえば Microsoft Graph PowerShell SDK を使う場合、開発・検証環境では次のように最小限の作成フローを確認できます。公式例では、多くのアプリ管理操作で委任アクセス許可 Application.ReadWrite.All が最小権限として示されています。(Microsoft Learn)
Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$app = New-MgApplication -BodyParameter @{
displayName = "contoso-sales-api"
}
New-MgServicePrincipal -BodyParameter @{
appId = $app.AppId
}本番運用では、このサンプルをそのまま使うのではなく、管理者同意の手順、実行アカウント、監査ログ、失敗時のロールバックを設計してから適用します。特にグローバル企業では、アプリ名、タグ、サポート窓口、所有者、利用部門、データ分類をテンプレートに含めると、後から棚卸ししやすくなります。
appId、object ID、uniqueName の使い分けが重要
Microsoft Graph では、アプリケーションやサービス プリンシパルを object ID で参照する方法と、appId で参照する方法が示されています。また、アプリケーション オブジェクトでは uniqueName を使った Upsert、つまり存在すれば更新し、存在しなければ作成する操作も紹介されています。(Microsoft Learn)
この違いを理解していないと、スクリプトの移植時に別テナントの object ID を誤って使う、検証環境では動いたのに本番で対象が見つからない、というトラブルが起きます。
| 識別子 | 特徴 | 使いどころ |
|---|---|---|
id | テナント内の object ID | 同一テナント内で確実に対象を指定する |
appId | アプリのクライアント ID。Microsoft Entra ID 全体で一意 | マルチテナント アプリや環境差分の吸収に使いやすい |
uniqueName | Upsert に利用できる名前 | IaC 的に「なければ作る、あれば更新する」運用に向く |
実務では、台帳に displayName だけを残すのは不十分です。最低でも displayName、appId、object ID、所有者、利用システム、権限、シークレット・証明書の期限をセットで管理してください。
API 権限の更新は「追加」ではなく「置き換え」と考える
Microsoft Graph でアプリの API 権限を割り当てる場合、アプリケーション オブジェクトの requiredResourceAccess を更新します。公式ドキュメントでは、既存の権限と新しい権限の両方を含める必要があり、含めなかった権限は削除される可能性があると説明されています。また、権限を割り当てることと管理者同意を付与することは別の操作です。(Microsoft Learn)
ここは失敗しやすいポイントです。たとえば、既存アプリに User.Read.All と Group.Read.All が設定されている状態で、スクリプトから Mail.Read だけを含む requiredResourceAccess を送ると、既存権限を意図せず落としてしまう可能性があります。
安全な更新手順は次の流れです。
| 手順 | 作業 | 目的 |
|---|---|---|
| 事前取得 | 現在の requiredResourceAccess を取得する | 既存権限を把握する |
| 差分作成 | 追加・削除したい権限だけを差分として整理する | 変更内容をレビュー可能にする |
| マージ | 既存権限と新規権限を合わせた完全な値を作る | 意図しない削除を防ぐ |
| PATCH | 完成した値でアプリを更新する | 設定を反映する |
| 同意確認 | 管理者同意が必要な権限を確認する | 権限設定済みだが動かない状態を避ける |
アプリ ロールも同じ発想で扱う必要があります。公式ドキュメントでは、アプリ ロールを追加または更新するときは既存ロールをすべて含める必要があり、既存ロールを省略すると削除されると説明されています。(Microsoft Learn)
所有者なしのサービス プリンシパルを検出する
Microsoft Entra アプリの実務運用で多い問題が、「誰が管理しているか分からないアプリ」です。公式ドキュメントでは、所有者が0人または1人だけのサービス プリンシパルを Microsoft Graph で抽出する例が示されています。このクエリでは $count を使うため、ConsistencyLevel: eventual ヘッダーが必要です。(Microsoft Learn)
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=owners/$count eq 0 or owners/$count eq 1&$count=true
ConsistencyLevel: eventual所有者が0人のアプリは、シークレット期限切れ、証明書更新、権限見直し、インシデント対応で詰まりやすくなります。所有者が1人だけの場合も、その担当者の異動・退職で同じ問題が発生します。
管理者は、少なくとも次の基準で定期点検するとよいでしょう。
| 点検項目 | 推奨する判断基準 |
|---|---|
| 所有者数 | 重要アプリは2名以上。個人ではなく運用チームを含める |
| 所有者の種類 | ユーザーだけでなく、必要に応じて管理用サービス プリンシパルも検討する |
| 退職・異動者 | 所有者が無効ユーザーになっていないか確認する |
| ベンダー管理アプリ | 社内責任者とベンダー窓口を台帳に残す |
所有者の追加は、アプリケーションの owners/$ref にディレクトリ オブジェクトを追加する形で実行できます。公式例では、ユーザーまたはサービス プリンシパルの object ID を @odata.id として指定する方法が示されています。(Microsoft Learn)
サービス プリンシパルの機密プロパティをロックできる
マルチテナント アプリでは、サービス プリンシパルの資格情報やトークン暗号化キーなど、変更されると影響が大きいプロパティを保護する設計が重要です。公式ドキュメントでは、アプリ インスタンス ロック機能により、keyCredentials、passwordCredentials、tokenEncryptionKeyId などの機密プロパティを不正な変更から保護できると説明されています。(Microsoft Learn)
例として、すべての機密プロパティをロックする場合は、servicePrincipalLockConfiguration の isEnabled と allProperties を true に設定します。公式例では、この操作に Microsoft Graph beta エンドポイントが使われています。(Microsoft Learn)
PATCH https://graph.microsoft.com/beta/applications/{application-id}
{
"servicePrincipalLockConfiguration": {
"isEnabled": true,
"allProperties": true
}
}ここで重要なのは、beta API を本番運用に入れる前の検証です。beta エンドポイントは将来仕様が変わる可能性があるため、対象アプリ、影響するプロパティ、変更手順、解除手順を事前に文書化しておくべきです。特に ISV 提供のマルチテナント アプリや、複数国で利用する基幹アプリでは、ロックにより運用作業や証明書更新がブロックされないか確認してください。
信頼済み CA と資格情報ポリシーで証明書運用を統制する
公式ドキュメントでは、テナント内のアプリに追加できる証明書資格情報を、信頼済み証明機関から発行された証明書に制限する方法も説明されています。この制限はアプリに証明書を追加するときに評価され、既存の証明書には、ローテーションされない限り影響しないとされています。(Microsoft Learn)
さらに、作成した信頼チェーンを既定のアプリ管理ポリシーに割り当てることで、テナント内のアプリに対して、準拠しない証明書の追加を拒否する構成例が示されています。公式例では、/policies/defaultAppManagementPolicy に対して、パスワード資格情報の有効期間、証明書の有効期間、信頼済み CA の制限を設定しています。(Microsoft Learn)
この設定はセキュリティを高める一方で、証明書更新の運用に直接影響します。導入前には、次の観点で棚卸ししてください。
| 確認項目 | 失敗しやすいポイント | 対策 |
|---|---|---|
| 証明書の発行元 | 部門ごとに異なる CA を使っている | 利用中の CA と中間 CA を一覧化する |
| 既存証明書 | すぐには影響しないため見落としやすい | 次回ローテーション日を基準に移行計画を作る |
| 自動更新スクリプト | 非準拠証明書を追加して失敗する | 事前に検証テナントでポリシー評価を確認する |
| グローバル拠点 | 国・地域ごとに証明書運用が違う | 例外要件を集約してから共通ポリシー化する |
証明書ポリシーは「設定すれば終わり」ではありません。むしろ、証明書の発行、承認、保管、ローテーション、失効、監査までを含む運用ルールがなければ、更新時に障害の原因になります。
移行期限はどう考えるべきか
今回の「Programmatically Manage Microsoft Entra Apps Using Microsoft Graph」自体は、新しい強制移行期限を告知する内容ではなく、Microsoft Graph でアプリ管理を自動化するための手順です。一方で、Azure AD Graph を使っているアプリについては話が別です。公式の移行ページでは、Azure AD Graph は非推奨で退役パスにあり、延長アクセスは 2025年8月31日に終了し、Azure AD Graph は完全に退役すると説明されています。(Microsoft Learn)
また、Microsoft Entra の推奨事項には、Azure AD Graph API から Microsoft Graph へ移行すべきアプリケーションとサービス プリンシパルを示す2種類の推奨事項があります。アプリ登録側の推奨事項は自社テナントで登録され Azure AD Graph を呼び出しているアプリ、サービス プリンシパル側の推奨事項は他テナントで登録され自社テナントで同意されたアプリを対象にします。(Microsoft Learn)
管理者が取るべき判断は明確です。
| 状況 | 対応方針 |
|---|---|
| すでに Microsoft Graph のみを使っている | 今回の内容を自動化・標準化の改善材料として扱う |
| Azure AD Graph を呼び出している自社開発アプリがある | Microsoft Graph API へ修正し、権限と同意を再確認する |
| ベンダー製アプリが Azure AD Graph を使っている | ベンダーに対応版、更新時期、代替手順を確認する |
| Microsoft Entra 推奨事項に対象が出ている | 影響リソース、過去30日の要求数、最終要求日時を確認する |
| 推奨事項が消えない | Azure AD Graph API の呼び出しが30日間止まっているか確認する |
Microsoft Entra の推奨事項では、影響を受けるリソースの一覧、API 操作名、過去30日の要求数、最終要求日時を確認できます。対象のアプリやサービス プリンシパルは、Azure AD Graph API 活動が30日間なくなると完了扱いになると説明されています。(Microsoft Learn)
管理者が確認すべきチェックリスト
Microsoft Entra アプリを Microsoft Graph で管理する前に、次の順番で確認すると失敗を減らせます。
| 優先度 | チェック項目 | 確認内容 |
|---|---|---|
| 高 | Azure AD Graph 利用状況 | Microsoft Entra 推奨事項で対象アプリとサービス プリンシパルを確認する |
| 高 | アプリ台帳 | displayName、appId、object ID、所有者、利用部門、権限を整理する |
| 高 | 権限更新ロジック | requiredResourceAccess と appRoles は既存値を取得してからマージ更新する |
| 高 | 管理者同意 | 権限の割り当てと管理者同意を別工程として扱う |
| 中 | 所有者 | 所有者なし、1名だけ、無効ユーザー所有のアプリを修正する |
| 中 | 資格情報 | シークレットと証明書の期限、発行元、ローテーション手順を確認する |
| 中 | beta API | servicePrincipalLockConfiguration など beta 機能は検証環境で確認する |
| 中 | グローバル運用 | 国・地域ごとの例外、証明書 CA、サポート窓口を整理する |
| 低 | 表示情報 | ロゴ、サポート URL、プライバシー URL、タグを整備する |
特に優先すべきは、権限更新と所有者管理です。API 権限やアプリ ロールを誤って上書きすると業務アプリが動かなくなります。一方、所有者不明のアプリは、障害発生時に誰も判断できない状態を作ります。どちらも「スクリプト化する前に棚卸しする」ことが重要です。
実務での導入手順
最初から全アプリを自動化しようとすると、例外処理が多くなり失敗します。まずは影響の少ない開発用アプリや社内ツールから始め、テンプレートを固めてから重要アプリへ広げるのが安全です。
| ステップ | 作業 | 成果物 |
|---|---|---|
| 事前調査 | Microsoft Entra 推奨事項、アプリ登録、エンタープライズ アプリを棚卸しする | アプリ台帳、移行対象一覧 |
| 設計 | 命名規則、タグ、所有者、権限、証明書運用を決める | 標準テンプレート |
| 検証 | Graph Explorer や検証テナントで作成・更新・削除を試す | 検証ログ、失敗パターン |
| 自動化 | PowerShell、SDK、CI/CD に組み込む | スクリプト、実行手順 |
| 運用化 | 定期棚卸し、所有者確認、証明書期限監視を行う | 監査レポート、改善チケット |
Graph Explorer を使う場合は、アプリを作成・管理できるアカウントでサインインして API 操作をテストする必要があります。公式ドキュメントでも、API 操作のテストには Graph Explorer と、アプリを作成・管理できるアカウントが前提として示されています。(Microsoft Learn)
まとめ：Microsoft Graph 化は「便利な自動化」ではなく統制強化の入口
Microsoft Entra アプリを Microsoft Graph で管理する最大の価値は、作業を速くすることではありません。アプリ登録、サービス プリンシパル、API 権限、所有者、証明書、ポリシーを一貫したルールで管理できるようにすることです。
今回の公式情報を読むうえでの実務的な結論は、次の3つです。
- 新しい強制設定変更として慌てるのではなく、Microsoft Graph によるアプリ ライフサイクル管理の標準化資料として読む
- Azure AD Graph を使っているアプリが残っていないか、Microsoft Entra 推奨事項で必ず確認する
- 権限、アプリ ロール、所有者、証明書ポリシーは、更新前に既存状態を取得してから変更する
まずは、Microsoft Entra 管理センターの推奨事項で Azure AD Graph 利用アプリを確認し、次に重要アプリの appId、所有者、API 権限、資格情報期限を台帳化してください。そのうえで、開発環境から Microsoft Graph PowerShell SDK や Graph API を使った作成・更新手順を検証するのが、最も安全で実務的な進め方です。
コメント