Azure

Azure Managed Identity vs Service Principal 完全比較|認証パターンの選定と実装ベストプラクティス

2026-05-24
更新: 2026-08-30
NicheeLab編集部
目次
  1. 基本的な違い
  2. Managed Identity の詳細
  3. Service Principal の詳細
  4. Client Secret vs Certificate vs Workload Identity Federation
  5. Workload Identity Federation (WIF)
  6. AKS Workload Identity
  7. 対応 Azure サービス
  8. 選定フローチャート
  9. セキュリティベストプラクティス
  10. 関連認定試験
  11. よくある質問

Azure リソースが他の Azure リソースや外部システムにアクセスする際、Managed Identity または Service Principal による認証が必要です。 近年、シークレット管理を不要にする Managed Identity と Workload Identity Federation がベストプラクティスとして定着し、Client Secret ベースの伝統的な Service Principal は徐々に置き換えが進んでいます。 本記事では、両者の違い・選定基準・実装パターンを多角的に整理します。

基本的な違い

項目Service PrincipalManaged Identity
分類アプリ登録ベースの Entra ID 認証エンティティAzure リソースに自動付与される特別な Service Principal
シークレット管理Client Secret / Certificate を自己管理Azure が裏側で自動管理 (シークレット不要)
作成方法App Registration → Service PrincipalAzure リソース作成時に有効化
ライフサイクル独立 (App Registration が親)System-assigned はリソースに紐付き、User-assigned は独立
適用シーンAzure 外システムからのアクセス・複数リソース共通認証Azure リソース間認証 (ほぼ常に推奨)
セキュリティシークレット漏洩リスクありシークレット非存在で漏洩不可

Managed Identity の詳細

Managed Identity は、Azure リソース (VM・App Service・Functions など) に自動付与される特別な Service Principal です。

System-assigned Managed Identity

  • Azure リソースのライフサイクルに紐付き、1 リソースに 1 つ
  • リソース削除時に自動削除
  • シンプル・最小権限原則に従いやすい
  • 適用シーン: 単発リソース・テスト環境

User-assigned Managed Identity

  • 独立した Azure リソースとして作成、複数 Azure リソースに割り当て可能 (1 Identity を 100 VM で共有など)
  • リソース削除時も残る、ライフサイクルが分離
  • 権限管理をテンプレート化したい場合に有効
  • 適用シーン: 本番環境・複数リソースで権限共有・IaC でのデプロイ

新規プロジェクトでは User-assigned が柔軟性で優位、シンプルな単発リソースなら System-assigned で十分。両者は混在可能です。

Service Principal の詳細

Service Principal は、App Registration (アプリ登録) によって作成される Entra ID の認証エンティティ。Azure 外のシステムや、複数 Azure リソースで認証を共有する場合に使用します。

作成手順

  1. Azure Portal『Microsoft Entra ID』→『App registrations』→『New registration』
  2. App Registration を作成 (Display Name・Supported account types・Redirect URI 指定)
  3. これにより App Registration オブジェクトと、それに紐付く Service Principal オブジェクトが自動作成
  4. Certificates & secrets で Client Secret 生成 (1-2 年で期限切れ) または Certificate アップロード (推奨)
  5. API permissions で必要な権限付与 (Microsoft Graph / Azure Service Management 等)、Admin consent が必要なら実施
  6. Service Principal に RBAC ロール割り当て (Subscription / RG / Resource レベルで)
  7. アプリケーションで Client ID + Client Secret (or Certificate) を使って Azure AD トークン取得し、API 呼び出し

Client Secret vs Certificate vs Workload Identity Federation

Service Principal の認証情報は 3 つの選択肢があり、セキュリティ階層が異なります。

方式セキュリティ管理負荷推奨シーン
Client Secret低 (文字列、漏洩リスク高)高 (定期ローテーション必要)レガシー・最終手段
Certificate中 (秘密鍵保護)中 (証明書ライフサイクル管理)オンプレ・3rd party 連携
Workload Identity Federation高 (シークレット非存在)低 (Federated Credential 構成のみ)GitHub Actions / Azure DevOps / Kubernetes / 外部 IdP

Workload Identity Federation (WIF)

Workload Identity Federation は、Azure 外の認証システム (GitHub Actions・Azure DevOps・Google Cloud・AWS・Kubernetes クラスタ・任意の OIDC プロバイダ) から Azure リソースへ認証する仕組み。

  • Service Principal に Federated Credential を構成
  • 外部 IdP の OIDC トークンを Azure AD トークンに交換
  • Client Secret や Certificate の管理が完全不要
  • GitHub Actions の azure/login@v2 アクションで標準サポート
  • CI/CD パイプラインでのシークレット漏洩リスクをゼロ化

Microsoft が強く推奨する 2026 年現在の主力認証パターンで、新規 CI/CD 構成では WIF 一択というのが業界標準です。

AKS Workload Identity

AKS (Azure Kubernetes Service) では Pod から Azure リソースへの認証パターンが進化してきました。

方式状態仕組み
AAD Pod Identity (旧)2024-09 廃止aad-pod-identity Add-on、Pod IP ベース割り当て
AKS Workload Identity (新)推奨 (現役)Kubernetes Service Account + OIDC で Azure AD 連携

2026 年現在の AKS では Workload Identity 一択で、既存 AKS Pod Identity ユーザーは Workload Identity への移行が必須。シンプル・スケーラブル・パフォーマンス改善という利点があります。

対応 Azure サービス

2026 年現在、Azure のほぼすべてのコンピュート系サービスで Managed Identity がサポート。代表例:

  • Compute: Azure VM, VMSS, App Service, Functions, Logic Apps, Container Apps, AKS Pod (Workload Identity), Azure Container Instances, Azure Batch
  • Data: Azure Data Factory, Synapse Analytics, Fabric, Azure Automation
  • Messaging: Service Bus Namespace, Event Hub Namespace, API Management
  • AI: Cognitive Services, Azure OpenAI, Azure AI Search
  • Web: Static Web Apps

選定フローチャート

  1. Azure リソース間認証? → Managed Identity (System or User-assigned)
  2. GitHub Actions / Azure DevOps からのデプロイ? → Service Principal + Workload Identity Federation
  3. AKS Pod からの認証? → AKS Workload Identity
  4. オンプレ Java / .NET アプリから? → Service Principal + Certificate (Key Vault 保管推奨)
  5. 3rd party SaaS 連携? → Service Principal + Certificate or Client Secret
  6. 緊急デモ / プロトタイプ? → Service Principal + Client Secret (短期利用、後で WIF 移行)

セキュリティベストプラクティス

  1. Azure リソース間認証は常に Managed Identityを使う
  2. CI/CD はWorkload Identity Federationに統一
  3. Client Secret は最終手段、使う場合は 90 日以内にローテーション + Key Vault 保管
  4. RBAC は最小権限原則 (Built-in Role を使い、必要なリソーススコープのみ付与)
  5. Service Principal の使用状況を Entra ID Sign-in Logs で監視 (Microsoft Sentinel 連携)
  6. 有効期限切れ予定の Client Secret / Certificate を Microsoft Graph API で定期チェック・アラート
  7. Conditional Access for Workload Identities で Service Principal 自体にもポリシー適用 (Preview 中)

関連認定試験

よくある質問

Managed Identity と Service Principal の違いは?

Service Principal は『アプリケーション登録 (App Registration) によって作成される Microsoft Entra ID の認証エンティティ』で、Client ID + Client Secret (または証明書) で認証する。Managed Identity は『Azure リソース (VM・App Service・Functions など) に自動付与される特別な Service Principal』で、Client Secret 不要 (Azure が裏側で自動的に管理)。Managed Identity は Service Principal の一種だが、シークレット管理が不要というセキュリティ上の優位性があり、Azure リソース間認証ではほぼ常に Managed Identity が推奨。Service Principal は『Azure 外のシステム (オンプレ・他クラウド・GitHub Actions) から Azure 認証する場合』『複数 Azure リソースで認証を共有する場合』『3rd party SaaS 連携』で使用します。

System-assigned と User-assigned Managed Identity の違いは?

System-assigned: Azure リソース (VM・App Service など) のライフサイクルに紐付く Managed Identity、1 リソースに 1 つ。リソース削除時に自動削除。シンプル・最小権限原則に従いやすい。User-assigned: 独立した Azure リソースとして作成、複数 Azure リソースに割り当て可能 (1 つの User-assigned Identity を 100 VM で共有など)。リソース削除時も残る、ライフサイクルが分離。複数リソースで同じ権限を共有したい場合・テンプレート化された権限管理をしたい場合に使用。新規プロジェクトでは User-assigned が柔軟性で優位、シンプルな単発リソースなら System-assigned で十分。両者は混在可能で、1 リソースに System-assigned + 複数 User-assigned を併用可能です。

Managed Identity はどの Azure サービスで使えますか?

2026 年現在、Azure のほぼすべてのコンピュート系サービスで Managed Identity がサポート。代表例: Azure VM・VMSS・App Service・Functions・Logic Apps・Container Apps・AKS Pod (Workload Identity)・Azure Container Instances・Azure Batch・Azure Data Factory・Synapse Analytics・Fabric・Azure Automation・Service Bus Namespace・Event Hub Namespace・API Management・Cognitive Services / Azure OpenAI・Static Web Apps。逆に Managed Identity 非対応 (2026-05 時点) のサービスは Azure Functions for SAP・一部レガシーサービスのみ。Azure リソースから他 Azure リソースへの認証は Managed Identity を使うのがベストプラクティスで、Client Secret や Connection String の管理から完全解放されます。

Service Principal はどう作成しますか?

Service Principal の作成手順: 1) Azure Portal『Microsoft Entra ID』→『App registrations』→『New registration』で App Registration を作成 (Display Name・Supported account types・Redirect URI 指定)。これにより App Registration オブジェクトと、それに紐付く Service Principal オブジェクトが自動作成される。2) 認証情報を設定: Certificates & secrets で Client Secret 生成 (1-2 年で期限切れに注意) または Certificate アップロード (推奨)。3) API permissions で必要な権限付与 (Microsoft Graph / Azure Service Management 等)、Admin consent が必要なら実施。4) Service Principal に RBAC ロール割り当て (Subscription / RG / Resource レベルで)。5) アプリケーションで Client ID + Client Secret (or Certificate) を使って Azure AD トークン取得し、API 呼び出し。

Client Secret と Certificate どちらが推奨ですか?

Certificate (証明書) が推奨です。Client Secret は文字列ベースのシークレットで、漏洩リスクが高い (Git コミット・ログ・メール添付など)。Certificate は秘密鍵がマシン内に保管され、外部漏洩しにくい。さらに Workload Identity Federation (2022 年 GA、2026 年現在は主力推奨) では Certificate も不要で、GitHub Actions / Azure DevOps / Kubernetes 外部 IdP からの OIDC トークンで Azure 認証可能。新規プロジェクトでは: 1) Azure 内サービス → Managed Identity (シークレット完全不要)、2) GitHub Actions / Azure DevOps → Workload Identity Federation (OIDC)、3) その他オンプレ・3rd party → Certificate、4) どうしても Client Secret → 90 日以内ローテーション + Key Vault 保管必須、というセキュリティ階層が標準。

Workload Identity Federation って何ですか?

Workload Identity Federation (WIF) は、Azure 外の認証システム (GitHub Actions・Azure DevOps・Google Cloud・AWS・Kubernetes クラスタ・任意の OIDC プロバイダ) から Azure リソースへ認証する仕組み。Service Principal に Federated Credential を構成し、外部 IdP の OIDC トークンを Azure AD トークンに交換することで、Client Secret や Certificate の管理が完全不要に。GitHub Actions の azure/login@v2 アクションで標準サポートされ、CI/CD パイプラインでのシークレット漏洩リスクをゼロ化。Microsoft が強く推奨する 2026 年現在の主力認証パターンで、新規 CI/CD 構成では WIF 一択というのが業界標準。AKS の Workload Identity も同じ思想で、Pod から Azure リソースへの認証に Kubernetes Service Account の OIDC トークンを使います。

AKS の Workload Identity と Pod Identity の違いは?

AKS Pod Identity (旧方式、2024-09 廃止予定): AAD Pod Identity プロジェクトベースで、aad-pod-identity Add-on をクラスタにインストール、Pod の IP に基づいて Azure Identity を割り当てる仕組み。実装複雑・パフォーマンス課題・既に廃止予定。AKS Workload Identity (新方式、推奨): Kubernetes 標準の Service Account をベースに、Azure AD と OIDC で連携。Pod は Service Account の OIDC トークンを Azure AD に提示してアクセストークン取得。シンプル・スケーラブル・パフォーマンス改善。2026 年現在の AKS では Workload Identity 一択で、既存 AKS Pod Identity ユーザーは Workload Identity への移行が必須です。

関連認定試験は?

SC-300 (Identity and Access Administrator Associate) で Service Principal・Managed Identity・Workload Identity が深く問われ、OAuth 2.0 / OIDC フローと組み合わせて出題。AZ-104 (Administrator) で RBAC 連携、AZ-400 (DevOps Engineer Expert) で Workload Identity Federation の CI/CD 適用、AI-103 (Azure AI Apps and Agents Developer Associate) で Azure OpenAI / AI Search への認証パターン。なお AZ-204 (Developer Associate) はアプリ開発者視点での Managed Identity 活用を扱っていましたが、2026 年 7 月 31 日に認定ごと退役しました (後継は Microsoft Certified: Azure AI Cloud Developer Associate / Exam AI-200)。Azure アプリケーション開発者にとって Managed Identity の使い方は事実上必須スキルです。

関連記事・技術深掘り

Azure Key Vault 完全ガイド|Secret/Key/Certificate 管理・Managed Identity 統合・セキュリティベストプラクティス【2026 年版】

Azure Key Vault の完全ガイド。Standard vs Premium vs Managed HSM ティア選定、Secret / Key / Certificate の使い分け、RBAC ベースアクセス制御、Managed Identity 統合 (シークレットレスアプリ)、Soft Delete / Purge Protection、Private Endpoint、Microsoft Defender for Key Vault、関連認定試験 (AZ-204 / SC-300 / SC-100) を日本語で網羅。

Azure Kubernetes Service (AKS) 入門ガイド|アーキテクチャ・Networking・Ingress・セキュリティ完全解説【2026 年版】

Azure Kubernetes Service (AKS) の入門ガイド。Control Plane と Node Pool の構造、Azure CNI Overlay vs Kubenet の選定、Application Gateway / NGINX Ingress 選定、Workload Identity (新方式)、Private Cluster・Microsoft Defender for Containers・Azure Policy のセキュリティ、関連認定試験 (AZ-104 / AZ-204 / AZ-400 / CKA) を日本語で網羅。

App Service vs Container Apps vs Functions 完全比較|Azure コンピュート選定ガイド【2026 年版】

Azure の主要 PaaS コンピュート 3 サービス App Service・Container Apps・Functions を完全比較。料金・スケーリング・適用シーン・コスト最適化を表形式で整理。AKS との使い分け、Web アプリ新規構築の推奨パターン、関連認定試験 (AZ-204 / AZ-305 / AZ-400) を日本語で網羅。

AZ-104 vs AZ-204 完全比較|Microsoft Azure Administrator vs Developer Associate の違いと選び方【2026 年版】

Microsoft Azure の 2 大 Associate 認定 AZ-104 (Administrator) と AZ-204 (Developer) を完全比較。対象ロール・出題範囲・難易度・学習時間・受験料・キャリアパスを表形式で整理。AZ-204 2026 年 7 月リタイア後の判断材料、両方取る価値、次の認定への進路まで日本語で網羅。

本記事の技術情報は Microsoft Entra Managed Identities Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure、Microsoft Entra は Microsoft group of companies の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。

この記事の内容を、基礎から読む

Azure の管理 (AZ-104) の出題範囲を体系的に扱う教科書があります。全 16 章・図 67 枚、登録なしで全部読めます。

教科書の目次をすべて見る →
この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

Azure 試験対策ページを見る
この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。


関連記事
Azure

AZ-900 完全ガイド|Microsoft Azure Fundamentals 出題範囲・学習リソース・合格戦略

Microsoft Azure Fundamentals (AZ-900) の 2026 年 1 月 14 日改訂版に対...

Azure

Azure 認定資格ロードマップ 2026 完全版|全 26 試験の体系と大型再編 (AI-901/AI-103/SC-500)

Microsoft Azure 認定資格 全 26 試験 (現行 23 + 退役 3) の 2026 年版ロードマップ。...

Azure

AI-901 完全ガイド|Azure AI Fundamentals 新試験

Microsoft Certified: Azure AI Fundamentals (AI-901) の出題範囲・Mi...

Azure

Microsoft Entra ID 入門|旧 Azure AD から学ぶ ID 管理 (AZ-900/SC-900/AZ-104 必須知識)

Microsoft Entra ID (旧 Azure Active Directory) の入門解説。2023 年 7...

Azure

DP-900 完全ガイド|Azure Data Fundamentals 出題範囲・学習リソース・合格戦略

Microsoft Azure Data Fundamentals (DP-900) の完全ガイド。4 ドメインの出題範...

Azureの記事一覧 (103件)
© 2026 NicheeLab All rights reserved.