Azure PipelinesからAzureへ安全にデプロイするなら、今後はAzure Resource Manager workload identity service connectionを前提に設計するのが現実的です。2026年4月更新のMicrosoft公式ドキュメントでは、Azure DevOpsで自動設定できない場合に、マネージドIDまたはアプリ登録を使って手動でWorkload identity federationを構成する流れが整理されています。
結論から言うと、まずは自動構成を試し、うまくいかない場合だけ手動構成を選ぶのが基本です。手動構成では「IDを作る」「Azure DevOps側でサービス接続を下書き保存する」「IssuerとSubject identifierをAzure側のフェデレーション資格情報に登録する」「IAMで権限を付与する」「Verify and saveで保存する」という順番を崩さないことが重要です。Microsoft Learnの該当ページも、手動構成の前に自動構成を試すことを案内しています。 (Microsoft Learn)
Azure Resource Manager workload identity service connectionとは
Azure Resource Manager service connectionは、Azure PipelinesからAzure Key Vault、Azure App Service、リソースグループなどのAzureリソースへ接続するためのサービス接続です。従来のクライアントシークレット方式では、シークレットの保管、期限管理、ローテーションが運用負荷になりやすい点が課題でした。
Workload identity federationを使うと、Azure DevOpsとMicrosoft Entra IDの間でフェデレーションされた資格情報を使って認証できます。Microsoft公式ドキュメントでも、Azure Resource Manager service connectionではWorkload identity federationの利用が推奨され、シークレットとシークレット管理を不要にできると説明されています。 (Microsoft Learn)
実務では、次のような場面で特に効果があります。
| 利用シーン | Workload identity federationが有効な理由 |
|---|---|
| 本番環境へのCI/CD | 長期シークレットを置かずに済むため、漏えい時の影響を抑えやすい |
| 複数チームでAzure DevOpsを運用 | サービス接続単位で権限を整理しやすい |
| セキュリティレビューが厳しい環境 | 「誰が、どのパイプラインで、どのAzureリソースへ接続するか」を説明しやすい |
| シークレット期限切れによる障害を減らしたい環境 | クライアントシークレットの更新忘れを避けやすい |
Azure DevOpsのサービス接続は「一度作れば終わり」ではありません。作成後に、どのパイプラインへ利用を許可するか、Azure側でどのスコープにどのロールを与えるかまで設計して初めて、安全に使えます。
2026年4月更新で押さえるべきポイント
今回取り上げるMicrosoft Learnの「Set a Resource Manager workload identity service connection」は、Azure PipelinesでAzure Resource Manager workload identity service connectionを手動構成するための公式手順です。対象としてAzure DevOps Services、Azure DevOps Server、Azure DevOps Server 2022が示されています。 (Microsoft Learn)
注目すべきポイントは、単に「画面で何をクリックするか」ではありません。運用上は、次の4点が重要です。
| 更新ポイント | 実務での意味 |
|---|---|
| 認証方式としてマネージドIDとアプリ登録の両方を扱う | 組織の権限設計に合わせて選べる |
| 自動構成ではなく手動構成が必要なケースを明確化 | 権限不足、別テナント利用、トラブルシュート時の選択肢になる |
| IssuerとSubject identifierの扱いを明示 | フェデレーション資格情報の設定ミスを減らせる |
| 「Grant access permission to all pipelines」を避ける方針を明記 | すべてのパイプラインから使える危険な接続を作らずに済む |
特に重要なのは、Azure DevOps側で生成されるIssuerとSubject identifierを、Azure側のフェデレーション資格情報へ正しく登録することです。ここが一致しないと、見た目上はサービス接続が作成できていても、パイプライン実行時に認証で失敗します。
まず判断すべきは「自動構成」か「手動構成」か
Azure Resource Manager service connectionを新規作成する場合、最初から手動構成を選ぶ必要はありません。Microsoft公式ドキュメントでは、初回設定ではWorkload identity federationを使うことが推奨され、既存のサービス接続がある場合も、まずWorkload identity federationへの変換を試す流れが示されています。 (Microsoft Learn)
判断基準は次のとおりです。
| 状況 | 推奨される選択肢 | 理由 |
|---|---|---|
| サブスクリプションに対する十分な権限があり、標準的なAzure環境で使う | App registrationの自動構成 | Azure DevOps側で必要な設定を自動化しやすい |
| サービスプリンシパルを作成する権限がない | マネージドIDの手動構成 | 既存または新規のユーザー割り当てマネージドIDを使える |
| Azure DevOpsユーザーとAzure側のMicrosoft Entraテナントが異なる | マネージドIDの手動構成 | テナント差異がある環境で選択肢になりやすい |
| アプリ登録を組織のID管理ルールに沿って作成したい | アプリ登録の手動構成 | アプリ登録、フェデレーション資格情報、RBACを個別に管理できる |
| 既存のシークレット方式を使い続けたい | 原則として再検討 | 互換性や例外的事情がある場合を除き、Workload identity federationを優先する |
Microsoft公式ドキュメントでは、マネージドIDは「サービスプリンシパルを作成する権限がない場合」や「Azure DevOpsユーザーとは異なるMicrosoft Entraテナントを使う場合」に有用と説明されています。 (Microsoft Learn)
手動構成の全体像
Azure Resource Manager workload identity service connectionの手動設定は、マネージドIDでもアプリ登録でも基本の流れは似ています。
| 順番 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | Azure側でIDを作成する | 必要な作成権限がない |
| 2 | Azure DevOpsでサービス接続を作成し、下書き保存する | 最後まで保存しようとして失敗する |
| 3 | Azure DevOpsで生成されたIssuerとSubject identifierをコピーする | コピー元の接続を間違える |
| 4 | Azure側でフェデレーション資格情報を追加する | Subject identifierの不一致 |
| 5 | Azureリソースに対してIAMロールを割り当てる | サービス接続は作れてもAzureリソースへアクセスできない |
| 6 | Azure DevOpsに戻ってVerify and saveする | RBAC反映前に検証して失敗することがある |
公式手順でも、マネージドIDでは「マネージドID作成」「サービス接続を下書き保存」「フェデレーション資格情報を追加」「権限付与」「サービス接続保存」の順序で進めるよう説明されています。 (Microsoft Learn)
この順番には理由があります。Azure DevOps側でサービス接続を下書き保存しないと、Azure側へ登録すべきIssuerとSubject identifierが確定しません。反対に、Azure側のフェデレーション資格情報がないままAzure DevOps側で最終保存しようとしても、検証に失敗します。
マネージドIDで手動構成する手順
マネージドIDを使う方法は、Azureリソースに紐づくIDを使って認証する構成です。アプリ登録の作成権限が制限されている組織や、Azure側の権限管理をリソース中心で整理したい環境に向いています。
事前に確認する権限
ユーザー割り当てマネージドIDを作成するには、AzureアカウントにManaged Identity Contributor以上のロール割り当てが必要です。また、パイプラインからAzureリソースへアクセスするには、対象リソースに対してマネージドIDへアクセス権を割り当てる必要があります。 (GitHub)
実務では、次の権限を事前に確認してください。
| 確認項目 | 確認内容 |
|---|---|
| マネージドID作成権限 | 対象サブスクリプションまたはリソースグループでユーザー割り当てマネージドIDを作れるか |
| ロール割り当て権限 | 対象リソースのIAMでロールを割り当てられるか |
| Azure DevOps権限 | Project settingsでService connectionsを作成・管理できるか |
| 利用パイプライン | どのパイプラインに接続利用を許可するか決まっているか |
Azure portalでユーザー割り当てマネージドIDを作成する
Azure portalで「Managed Identities」を開き、ユーザー割り当てマネージドIDを作成します。作成後、後続のAzure DevOps設定で使うために、次の値を控えておきます。
| 値 | 用途 |
|---|---|
| Subscription | サービス接続のスコープ確認に使う |
| Subscription ID | Azure DevOps側のSubscription scopeで入力する |
| Client ID | Azure DevOps側のApplication (client) IDとして入力する |
| Tenant ID | Azure DevOps側のDirectory (tenant) IDとして入力する |
ここで注意したいのは、マネージドIDのObject IDとClient IDを取り違えないことです。Azure DevOps側で求められるApplication (client) IDには、公式手順上、マネージドIDのClient IDを入力します。 (Microsoft Learn)
Azure DevOpsでサービス接続を下書き保存する
Azure DevOpsの対象プロジェクトで、Project settingsからService connectionsを開きます。New service connectionを選び、種類はAzure Resource Managerを選択します。
認証方式では、App registration or Managed identity (manual)を選び、資格情報としてWorkload identity federation credentialを選択します。公式手順でも、この選択がマネージドID手動構成の入口として示されています。 (Microsoft Learn)
入力時の主な項目は次のとおりです。
| 項目 | 入力内容 |
|---|---|
| Service connection name | 例: sc-prod-arm-wif。後で識別しやすい名前にする |
| Environment | Azure Cloud、Azure Stackなど接続先環境を選ぶ |
| Scope Level | Subscription、Management Group、Machine Learning Workspaceから選ぶ |
| Application (client) ID | マネージドIDのClient ID |
| Directory (tenant) ID | マネージドIDのTenant ID |
Securityの項目でGrant access permission to all pipelinesを有効にすると、すべてのパイプラインからその接続を使えるようになります。公式手順ではこのオプションを使わず、各パイプラインを個別に承認することが推奨されています。 (Microsoft Learn)
設定を入力したら、いったんKeep as draftで下書き保存します。この時点でAzure DevOps側がIssuerとSubject identifierを生成するため、次のステップでAzure portalへ登録します。
Azure portalでフェデレーション資格情報を追加する
Azure portalで作成済みのマネージドIDを開き、SettingsからFederated credentialsへ進みます。Add credentialsを選択し、シナリオはOther issuerを選びます。
Azure DevOpsの下書きサービス接続からコピーしたIssuerとSubject identifierを貼り付けます。TypeはExplicit subject identifierを選びます。Microsoft公式手順でも、Azure DevOps側からコピーしたIssuerとSubject identifierをAzure portal側へ貼り付ける流れが説明されています。 (Microsoft Learn)
この作業でよくあるミスは、別のサービス接続で生成したSubject identifierを貼り付けることです。検証に失敗した場合は、Azure DevOps側のサービス接続名、プロジェクト、Issuer、Subject identifierが同じ組み合わせになっているか確認してください。
AzureリソースにIAMロールを割り当てる
フェデレーション資格情報を追加しただけでは、Azureリソースへアクセスできません。対象のリソースグループ、サブスクリプション、または個別リソースでAccess control (IAM)を開き、マネージドIDへ必要なロールを割り当てます。
公式手順では例としてContributorが挙げられていますが、実務では最小権限を優先してください。たとえば、Key Vaultからシークレットを読むだけならKey Vault関連の適切なロール、App Serviceへデプロイするだけなら対象リソースに必要な範囲のロールを検討します。 (Microsoft Learn)
Azure DevOpsに戻ってVerify and saveする
Azure portal側の設定が完了したら、Azure DevOpsの下書きサービス接続へ戻ります。Finish setupを選び、Verify and saveを実行します。
ここで成功すれば、Azure PipelinesからマネージドIDを使ったAzure Resource Manager workload identity service connectionを利用できます。失敗した場合は、先にIssuerとSubject identifierの一致、IAMロールの割り当て、接続先スコープを確認してください。
アプリ登録で手動構成する手順
アプリ登録を使う方法は、Microsoft Entra ID上のアプリケーションをサービスプリンシパルとして扱い、Workload identity federationでAzure DevOpsと連携する構成です。ID管理部門がアプリ登録を統制している組織や、複数の環境で同じ設計パターンを横展開したい場合に向いています。
事前に確認する権限
アプリ登録を作成するには、Azureアカウントがアプリ登録を作成できる必要があります。テナントでアプリ登録の作成が無効化されている場合は、Application Developerロールが必要になると公式手順に記載されています。 (GitHub)
確認すべき項目は次のとおりです。
| 確認項目 | 確認内容 |
|---|---|
| App registrationsの作成可否 | テナント設定でユーザーによる作成が許可されているか |
| Application Developerロール | 必要な場合に付与されているか |
| IAMロール割り当て権限 | 対象Azureリソースにロールを付与できるか |
| 命名ルール | アプリ登録名、サービス接続名、環境名を運用で追跡できるか |
Azure portalでアプリ登録を作成する
Azure portalでApp registrationsを開き、New registrationを選択します。名前を入力し、利用できるアカウント種別を選んでRegisterします。
作成後、次の値を控えます。
| 値 | 用途 |
|---|---|
| Application (client) ID | Azure DevOps側のApplication (client) IDとして入力 |
| Directory (tenant) ID | Azure DevOps側のDirectory (tenant) IDとして入力 |
この段階では、まだシークレットを作成する必要はありません。Workload identity federationを使う目的は、クライアントシークレットを置かずにAzure DevOpsから認証することだからです。
Azure DevOpsでサービス接続を下書き保存する
Azure DevOpsでNew service connectionを作成し、Azure Resource Managerを選択します。マネージドIDの場合と同様に、App registration or Managed identity (manual)を選び、資格情報としてWorkload identity federation credentialを指定します。
Authenticationには、アプリ登録のApplication (client) IDとDirectory (tenant) IDを入力します。Scope LevelはSubscription、Management Group、Machine Learning Workspaceから選べます。公式手順では、Azure Stackを選ぶ場合には環境URLの入力が必要になる例も示されています。 (GitHub)
最後まで保存せず、Keep as draftで下書き保存します。ここで生成されるIssuerとSubject identifierを、後でAzure portal側のフェデレーション資格情報に使います。
アプリ登録にフェデレーション資格情報を追加する
Azure portalで対象のアプリ登録を開き、Certificates & secretsからFederated credentialsへ進みます。Add credentialsを選択し、Other issuer scenarioを選びます。
Azure DevOpsのサービス接続からコピーしたIssuerとSubject identifierを貼り付け、TypeにExplicit subject identifierを指定します。保存後、対象AzureリソースのAccess control (IAM)でアプリ登録に必要なロールを割り当てます。公式手順でも、フェデレーション資格情報の追加後に対象リソースへロールを割り当て、Azure DevOps側でVerify and saveする流れが説明されています。 (GitHub)
マネージドIDとアプリ登録の使い分け
どちらを選ぶべきかは、技術的な好みではなく、組織の権限設計で決めるのが安全です。
| 比較項目 | マネージドID | アプリ登録 |
|---|---|---|
| 向いている環境 | Azureリソース中心でIDを管理したい環境 | Microsoft Entra ID上のアプリとして統制したい環境 |
| 権限面の特徴 | サービスプリンシパル作成権限がなくても選択肢になりやすい | アプリ登録の作成権限やApplication Developerロールが必要になる場合がある |
| 管理しやすいケース | Azureリソースグループやサブスクリプション単位で整理したい場合 | 複数環境・複数プロジェクトで同じID設計を展開したい場合 |
| 注意点 | Client IDとObject IDの取り違えに注意 | シークレットを作らず、Federated credentialsを使う設計にする |
| 代表的な用途 | Azure DevOpsから特定のAzure環境へデプロイ | 組織標準のEntraアプリとしてCI/CD認証を管理 |
迷った場合は、まず自社のID管理ルールを確認してください。開発チームが自由にアプリ登録を作成できない組織では、マネージドIDの方が現実的な場合があります。一方で、ID棚卸しや監査をMicrosoft Entra IDのアプリ登録ベースで統一している組織では、アプリ登録の手動構成が管理しやすいことがあります。
YAMLパイプラインでの利用例
サービス接続を作成したら、Azure Pipelinesのタスクから参照できます。たとえばAzure CLIタスクでは、azureSubscriptionにサービス接続名を指定します。AzureCLI@2はWorkload identity federationをサポートするタスクとして公式のトラブルシュートページに掲載されています。 (Microsoft Learn)
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'sc-prod-arm-wif'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
az group show --name rg-prodこの例では、sc-prod-arm-wifがAzure Resource Manager workload identity service connectionの名前です。実際の運用では、環境名と用途が分かる名前にしておくと、監査や障害対応が楽になります。
命名例は次のように統一すると分かりやすくなります。
| 用途 | 命名例 |
|---|---|
| 開発環境のデプロイ | sc-dev-arm-wif |
| 検証環境のデプロイ | sc-stg-arm-wif |
| 本番環境のデプロイ | sc-prod-arm-wif |
| Machine Learning Workspace用 | sc-ml-prod-wif |
本番環境用のサービス接続は、利用できるパイプラインを絞り込むべきです。便利だからといって全パイプラインへ許可すると、意図しないパイプラインから本番Azureリソースへアクセスできるリスクが生まれます。
よくある失敗と対処法
Azure Resource Manager workload identity service connectionの設定で失敗する場合、多くは「認証」と「認可」を混同していることが原因です。フェデレーション資格情報は認証の設定であり、IAMロールはAzureリソースへの認可です。片方だけ設定しても、パイプラインは正常に動きません。
| 症状 | よくある原因 | 対処法 |
|---|---|---|
| Verify and saveで失敗する | Azure側にフェデレーション資格情報が未登録 | Azure DevOpsで生成されたIssuerとSubject identifierを登録する |
| パイプライン実行時に認証エラーになる | Subject identifierが一致していない | 別のサービス接続の値を貼っていないか確認する |
| Azureリソース操作で403になる | IAMロールが不足している | 対象リソース、リソースグループ、サブスクリプションのIAMを確認する |
| 特定タスクだけ失敗する | タスクがWorkload identity federationに未対応、または古い | 対応タスクや推奨バージョンを確認する |
| すべてのパイプラインから接続が見える | Grant access permission to all pipelinesを有効化している | 個別パイプライン承認に切り替える |
| AADSTS700223またはAADSTS700238が出る | テナントでWorkload identity federationが無効化またはブロックされている可能性 | Microsoft Entraのポリシーやフェデレーション資格情報の制限を確認する |
Microsoftのトラブルシュートページでは、Workload identity federation対応タスクの確認、テナントでWorkload identity federationが有効かどうか、Issuer URLとSubject identifierの正確性をチェック項目として挙げています。また、AADSTS700223やAADSTS700238が出る場合は、Microsoft EntraテナントでWorkload identity federationが無効化されている可能性があると説明されています。 (Microsoft Learn)
セキュリティ設計で外してはいけないポイント
Workload identity federationに移行しても、権限設計を誤ると安全とは言えません。むしろ「シークレットがないから安心」と考えて広い権限を与えると、パイプラインの侵害時に大きな影響が出ます。
サービス接続は環境ごとに分ける
開発、検証、本番で同じサービス接続を使い回すと、権限の境界が曖昧になります。特に本番環境は、専用のサービス接続、専用のID、専用の承認ルールで分離するのが基本です。
おすすめは次の設計です。
| 環境 | サービス接続 | Azure側の権限 |
|---|---|---|
| 開発 | sc-dev-arm-wif | 開発用リソースグループに限定 |
| 検証 | sc-stg-arm-wif | 検証用リソースグループに限定 |
| 本番 | sc-prod-arm-wif | 本番リソースの必要範囲に限定 |
Contributorを安易に広範囲へ付与しない
公式手順では例としてContributorロールが示されていますが、これは説明上の例です。実際には、パイプラインが何をするかに応じて、必要最小限のロールを選ぶべきです。
たとえば、ARMテンプレートやBicepでリソースを作成するならContributorが必要になる場面があります。一方、既存のApp Serviceへコードをデプロイするだけなら、より限定的な権限で足りる可能性があります。権限が分からない場合は、最初からサブスクリプション全体にContributorを付けるのではなく、検証環境で必要操作を洗い出してから本番へ反映してください。
パイプライン承認を個別に管理する
サービス接続の作成画面では、すべてのパイプラインへアクセスを許可する選択肢があります。しかし公式手順では、このオプションを使わず、各パイプラインを個別に承認することが推奨されています。 (Microsoft Learn)
これは本番運用では非常に重要です。たとえば、開発者が新しく作成した検証用パイプラインから、誤って本番用サービス接続を使える状態になると、レビューを経由せず本番リソースへ変更を加えられる可能性があります。
タスクの対応状況を確認する
Azure Pipelinesのすべてのタスクが同じようにWorkload identity federationへ対応しているわけではありません。Microsoftのトラブルシュートページでは、多くのMicrosoft Entra認証タスクが対応している一方で、古いタスクでは新しいバージョンの利用が案内されているものもあります。Marketplace拡張のタスクについては、発行元に対応状況を確認する必要があります。 (Microsoft Learn)
移行前には、既存パイプラインで使っているタスクを棚卸ししてください。AzureCLI@2、AzurePowerShell@5、AzureResourceManagerTemplateDeployment@3などは対応タスクとして確認できますが、古いタスクを使っている場合はバージョンアップが必要になることがあります。
既存のシークレット方式から移行する時の進め方
既存のAzure Resource Manager service connectionがクライアントシークレット方式の場合、いきなり本番パイプラインで切り替えるのは避けた方が安全です。移行は小さく進めるのが現実的です。
| ステップ | 作業内容 |
|---|---|
| 1 | 既存サービス接続の一覧を作る |
| 2 | 利用パイプライン、対象Azureリソース、付与ロールを確認する |
| 3 | 開発環境用にWorkload identity federationのサービス接続を作成する |
| 4 | 代表的なパイプラインで動作確認する |
| 5 | 対応していないタスクや拡張機能を更新する |
| 6 | 検証環境、本番環境の順に切り替える |
| 7 | 旧シークレット方式の接続を無効化または削除する |
このとき、旧接続と新接続を同名にしない方が安全です。移行中は、どのパイプラインがどちらの接続を使っているかを追跡しやすくするため、-wifのような接尾辞を付けると管理しやすくなります。
IT管理者とプロダクトオーナーが確認すべきこと
この更新は、Azure管理者だけでなく、プロダクトオーナーにも関係します。なぜなら、CI/CDの認証方式はリリース速度、障害リスク、監査対応に直結するからです。
IT管理者は、次の点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| アプリ登録の作成ルール | 開発チームに許可するか、管理者が払い出すか |
| マネージドIDの利用ルール | どのサブスクリプション・リソースグループで許可するか |
| サービス接続の命名規則 | 環境、用途、認証方式が分かる名前にする |
| パイプライン承認 | すべて許可ではなく、個別承認を原則にする |
| ロール割り当て | サブスクリプション全体ではなく、必要なスコープに限定する |
プロダクトオーナーは、次の点を確認するとリリース計画を立てやすくなります。
| 確認項目 | なぜ重要か |
|---|---|
| 既存パイプラインの移行対象 | シークレット期限切れによるリリース失敗を減らせる |
| 本番環境への接続権限 | 不要なパイプラインから本番へ接続できないようにする |
| 移行テストの期間 | タスク非対応やRBAC不足を本番前に検出できる |
| 監査ログの確認方法 | 誰がどの接続を使ったか説明しやすくなる |
Workload identity federationは、単なる認証方式の変更ではありません。CI/CDの信頼境界を見直す機会として扱うべきです。
まとめ：まずは自動構成、必要な場合だけ手動構成へ
Azure PipelinesでAzureへデプロイするなら、Azure Resource Manager workload identity service connectionは今後の標準候補です。シークレット管理の負担を減らし、Microsoft Entra IDとAzure DevOpsの連携をより安全に設計できます。
今回の2026年4月更新で実務上押さえるべきことは、次の3つです。
まず、新規作成ではWorkload identity federationを前提にし、可能なら自動構成を使います。次に、自動構成できない場合は、マネージドIDまたはアプリ登録の手動構成を選びます。最後に、手動構成ではAzure DevOps側のIssuerとSubject identifier、Azure側のフェデレーション資格情報、IAMロール、パイプライン承認をセットで確認します。
次に取るべき行動は明確です。既存のAzure Resource Manager service connectionを棚卸しし、シークレット方式の接続が残っていないか確認してください。そのうえで、まずは開発環境の1つのパイプラインからWorkload identity federationへ移行し、タスク対応、RBAC、パイプライン承認の運用ルールを固めるのが安全な進め方です。
コメント