Azure DevOpsのWorkload identity federation service connectionsを利用している場合、今回まず確認すべきことはサービス接続のissuerが https://vstoken.dev.azure.com のAzure DevOps issuerのまま残っていないかです。2026年6月22日にAzure DevOps Blogで公開された更新では、このAzure DevOps issuerがRetirement対象として案内され、2027年7月1日にサポート終了予定とされています。対象のサービス接続は、Azure DevOpsの管理画面からMicrosoft Entra issuerへ更新できます。(Microsoft for Developers)
特に影響を受けやすいのは、Azure PipelinesからAzureリソース、Docker Registry、拡張機能経由の外部サービスへ接続している環境です。既存パイプラインがすぐ停止するわけではありませんが、2027年7月1日以降の認証失敗を避けるため、CI/CD担当者、Azure管理者、Microsoft Entra管理者で早めに棚卸ししておく必要があります。
Retirement of Azure DevOps issuer in Workload identity federation service connectionsで何が変わるのか
今回の変更は、Azure DevOpsのWorkload identity federation、いわゆるWIFを使ったサービス接続において、認証時に使われるissuerをAzure DevOps issuerからMicrosoft Entra issuerへ標準化するものです。
従来の一部サービス接続では、フェデレーション資格情報のissuerとして次のようなAzure DevOps issuerが使われていました。
https://vstoken.dev.azure.com今後の標準は、Microsoft Entra issuerです。
https://login.microsoftonline.com/Microsoftの案内では、2025年11月以降にAzure DevOpsで新規作成されたWorkload identity federation service connectionsは、Microsoft Entra issuerを既定で使用しています。一方で、それ以前に作成された既存のサービス接続にはAzure DevOps issuerが残っている可能性があります。(Microsoft for Developers)
この変更の実務上のポイントは、パイプライン定義のYAMLを大きく書き換える話ではなく、サービス接続とフェデレーション資格情報の設定確認・変換が中心になることです。
影響を受けるサービス接続の条件
すべてのAzure DevOps環境が同じように影響を受けるわけではありません。確認すべき対象は、Workload identity federationを使い、かつAzure DevOps issuerを使用しているサービス接続です。
| 確認項目 | 対象になる可能性 | 実務での見方 |
|---|---|---|
| Azure public cloud向けのサービス接続 | 高い | 通常の商用Azure環境で使っている接続は優先確認 |
| 単一テナントのMicrosoft Entraアプリ | 高い | App registrationのsignInAudienceが単一組織向けか確認 |
| マネージドIDを使うサービス接続 | 高い | User-assigned managed identityを使うARM接続は要確認 |
| Azure Government、Azure China、Azure Stack向け | 対象外 | 今回のRetirement告知の対象外として扱われる |
| マルチテナントアプリを使う接続 | 対象外 | 現時点ではAzure DevOps issuerのサポート継続対象 |
| すでにMicrosoft Entra issuerの接続 | 対象外 | 追加対応は基本不要 |
Microsoft Learnでは、Azure Resource Manager接続だけでなく、Docker接続や拡張機能で作成されたサービス接続も、Azure DevOps issuerを使うWIF接続であれば変換対象になり得ると説明されています。サービス接続の種類だけで判断せず、issuerを確認することが重要です。(Microsoft Learn)
Azure DevOpsの設定場所と管理画面の確認手順
Azure DevOps issuerが残っているかどうかは、Azure DevOpsのプロジェクト設定から確認します。
確認する場所
Azure DevOps
→ 対象プロジェクト
→ Project settings
→ Service connectionsMicrosoft Learnでは、サービス接続の作成・表示・編集はProject settings > Service connectionsから行うと説明されています。対象のサービス接続を開くと、Overview、Usage history、Approvals and checksなどの情報を確認できます。(Microsoft Learn)
今回のRetirement対象になるサービス接続は、サービス接続一覧の上部に警告付きで表示され、対応が必要であることが示されます。警告が出ている接続を開き、UpdateボタンからMicrosoft Entra issuerへの変換を進めます。(Microsoft for Developers)
管理画面で見るべきポイント
| 画面 | 見るポイント | 判断基準 |
|---|---|---|
| Service connections一覧 | 警告付きの接続があるか | 上部にRetirement対象の接続が出ていれば対応対象 |
| 対象サービス接続のOverview | 認証方式・接続種別 | Workload identity federationを使っているか確認 |
| Usage history | どのパイプラインで使われているか | 影響範囲の洗い出しに使う |
| Security | 管理者・利用可能なパイプライン | 変換作業者と影響チームを確認 |
| Approvals and checks | 承認・チェック設定 | 変換後の実行確認で見落としを防ぐ |
単に警告を消すだけでなく、Usage historyで利用中のパイプラインを確認してから作業するのが安全です。特に本番デプロイ用のサービス接続は、変換後にテスト用パイプラインだけで判断せず、本番相当の認証経路で確認してください。
Microsoft Entra issuerへ更新する基本手順
対象のサービス接続が見つかった場合は、既存のサービス接続を削除して作り直すのではなく、まずAzure DevOpsの変換機能を使います。既存接続を変換すれば、YAMLやClassic pipelineで参照しているサービス接続名を変えずに済むため、不要な修正を避けられます。
| 手順 | 作業内容 | 注意点 |
| -: | ——————————————- | ———————— |
| 1 | Project settings > Service connectionsを開く | プロジェクトごとに確認する |
| 2 | 警告が表示されたサービス接続を選択 | Azure DevOps issuer対象か確認 |
| 3 | Updateを選択 | 既存接続の変換を優先 |
| 4 | 確認画面でもう一度Updateを選択 | 作業前に利用中パイプラインを把握しておく |
| 5 | 変換完了後、パイプラインを再実行 | 認証エラーや警告が消えたか確認 |
Microsoftの説明では、変換中も既存のAzure DevOps issuerのフェデレーション資格情報は参照され、Microsoft Entra issuerのフェデレーション資格情報が動作確認された後にパイプラインジョブが新しいissuerを使い始める流れとされています。(Microsoft for Developers)
自動変換できない場合に確認すること
自動更新が失敗する主な原因は、Azure DevOps側の権限と、AzureまたはMicrosoft Entra側の権限が分かれていることです。Azure DevOpsでサービス接続を編集できても、対象のApp registrationやManaged identityにフェデレーション資格情報を追加できるとは限りません。
| 領域 | 必要になりやすい権限 | 確認する相手 |
|---|---|---|
| Azure DevOps | Service connection administrator、Endpoint administrator | Azure DevOpsプロジェクト管理者 |
| User-assigned managed identity | フェデレーション資格情報を追加できる権限 | Azure管理者、リソースグループ所有者 |
| App registration | アプリ所有者、または資格情報を管理できるEntra権限 | Microsoft Entra管理者 |
| 対象Azureリソース | サブスクリプション、リソースグループ、リソースへのロール割り当て権限 | Azureサブスクリプション管理者 |
自動変換ができない場合、Azure DevOps側にIssuer、Subject identifier、Audienceなどの値が表示されます。これらをAzure管理者またはMicrosoft Entra管理者に渡し、App registrationまたはManaged identityのFederated credentialsに手動で追加してもらいます。その後、Azure DevOps側に戻って検証を完了します。(Microsoft Learn)
利用条件で見落としやすいポイント
今回のRetirement対応では、「WIFを使っているか」だけでなく、「どのissuerを使っているか」「どのクラウドに接続しているか」「アプリが単一テナントか」を分けて確認する必要があります。
Azure Resource Manager接続だけを見て終わらない
Microsoft Learnでは、今回の変換対象はAzure Resource Manager service connectionsに限定されないと説明されています。Docker service connectionsや拡張機能で作成されたサービス接続も、Azure DevOps issuerを使っていれば対象になり得ます。(Microsoft Learn)
実務では、以下のような接続を優先的に確認してください。
- 本番環境へデプロイするARMサービス接続
- Azure Container RegistryやDocker Registryへ接続するパイプライン
- Marketplace拡張機能が作成したサービス接続
- 複数プロジェクトで名前を使い回している接続
- 長期間メンテナンスされていないリリースパイプライン
マルチテナントアプリは今回の対象外だが放置は禁物
マルチテナントアプリを使うサービス接続は、今回のRetirement告知では対象外です。ただし、対象外だから確認不要という意味ではありません。
signInAudience: AzureADMultipleOrgsのようなマルチテナント構成は、別の制約や例外設定に影響される場合があります。MicrosoftのFAQでも、マルチテナントアプリに関する組織全体の例外や今後の個別例外の扱いに触れられています。(Microsoft for Developers)
対象外の接続も、台帳に「対象外の理由」を残しておくと、後から監査や障害調査を行う際に迷いません。
パイプライン側で確認すべきこと
issuerの変換そのものはサービス接続側の作業ですが、影響確認はパイプライン単位で行う必要があります。
YAMLでサービス接続名を確認する
YAML pipelinesでは、タスク内でサービス接続名を参照していることがあります。代表例はazureSubscriptionなどの入力値です。
- task: AzureCLI@2
inputs:
azureSubscription: 'prod-arm-service-connection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az group listこの場合、prod-arm-service-connectionが今回のRetirement対象かどうかをService connections画面で確認します。
サービス接続を作り直して名前を変えると、YAML側の修正が必要になります。基本は既存のサービス接続を変換し、参照名を維持する方が安全です。
Classic pipelineやRelease pipelineも確認する
YAMLだけでなく、Classic pipelineやRelease pipelineで使われている接続も確認対象です。古いリリースパイプラインほど、作成当時の認証方式が残っている可能性があります。
確認時は、Service connectionsのUsage historyを使い、どのパイプラインで対象接続が使われているかを確認してください。Microsoft Learnでも、サービス接続のUsage historyで利用履歴を確認できると説明されています。(Microsoft Learn)
ユーザー周知で伝えるべき内容
今回の変更は、開発者全員に詳細なissuerの仕組みを説明するよりも、影響のあるチームに「何が起きるか」「いつまでに何をするか」「作業後に何を確認するか」を伝える方が効果的です。
周知文の例
Azure DevOpsのWorkload identity federation service connectionsで、旧Azure DevOps issuerを使う接続がRetirement対象になりました。
既存パイプラインは直ちに停止するものではありませんが、2027年7月1日に旧issuerのサポート終了が予定されています。
対象のサービス接続は、Project settings > Service connectionsで警告付き表示されます。
各チームは、利用中のサービス接続を確認し、対象がある場合はMicrosoft Entra issuerへのUpdateを実施してください。
変換後は、該当サービス接続を使うパイプラインを再実行し、認証エラーや警告が出ないことを確認してください。周知対象を分けると作業が進みやすい
| 対象者 | 伝える内容 |
|---|---|
| 開発チーム | 利用中パイプラインの再実行確認、失敗時の連絡先 |
| DevOps管理者 | 対象サービス接続の棚卸し、Update作業、利用履歴確認 |
| Azure管理者 | Managed identityやAzureリソース権限の確認 |
| Microsoft Entra管理者 | App registrationの所有者、Federated credentialsの追加 |
| セキュリティ担当 | 長期シークレット削減、認証方式変更の管理記録 |
現場でよく起きる失敗は、Azure DevOps管理者だけで作業を完結しようとして、App registrationやManaged identityの権限不足で止まるパターンです。事前にEntra管理者やAzure管理者を巻き込んでおくと、手戻りを減らせます。
確認チェックリスト
Retirement対応を進める際は、次の順番で確認すると抜け漏れを防げます。
| チェック項目 | 完了条件 |
|---|---|
| Azure DevOpsの全プロジェクトを確認した | Project settings > Service connectionsをプロジェクトごとに確認済み |
| 警告付きのサービス接続を一覧化した | 接続名、プロジェクト、利用パイプライン、所有者を記録済み |
| 対象外の理由を記録した | 非Public cloud、マルチテナント、既にEntra issuerなどを明記 |
| 自動Updateを試した | 成功または失敗理由を記録済み |
| 手動対応が必要な接続を管理者へ依頼した | Issuer、Subject identifier、Audienceなどを共有済み |
| 変換後にパイプラインを再実行した | 認証エラーやRetirement警告が出ないことを確認済み |
| 本番デプロイ前の確認手順を決めた | リリース前チェック項目に追加済み |
| 関係者へ周知した | 開発、Azure、Entra、セキュリティ担当に共有済み |
よくある疑問
既存パイプラインはすぐ止まりますか？
すぐには止まりません。MicrosoftのFAQでは、Azure DevOps issuerを使う既存サービス接続はRetirement予定日である2027年7月1日まで動作を継続するとされています。ただし、警告が出ている状態を放置すると、期限後に認証失敗のリスクがあります。(Microsoft for Developers)
YAMLの修正は必要ですか？
既存のサービス接続をUpdateで変換できれば、通常はサービス接続名を変えずに済むため、YAMLの修正は不要なケースが多いです。ただし、サービス接続を作り直した場合や名前を変更した場合は、YAMLやClassic pipeline側の参照も修正が必要です。
どのエラーを見ればよいですか？
変換後の認証失敗では、AADSTS70021、AADSTS700213、AADSTS70025など、issuer、subject、federated credentialの不一致に関係するエラーが出る場合があります。Microsoft Learnでは、issuer URL、federation subject identifier、フェデレーション資格情報の一致確認がトラブルシューティングの重要項目として案内されています。(Microsoft Learn)
新規作成するサービス接続も確認が必要ですか？
2025年11月以降にAzure DevOpsで新規作成されたWIFサービス接続はMicrosoft Entra issuerを既定で使うと案内されています。ただし、組織の自動化スクリプトや拡張機能で作成している場合は、作成結果のissuerを確認しておくと安全です。(Microsoft for Developers)
まずやるべき実務対応
今回のRetirement対応で最初にやるべきことは、Azure DevOpsの各プロジェクトでProject settings > Service connectionsを開き、警告付きのサービス接続がないか確認することです。
警告がある場合は、すぐに削除や再作成をするのではなく、既存サービス接続のUpdateでMicrosoft Entra issuerへ変換します。自動変換できない場合は、Azure DevOps側に表示されるIssuerやSubject identifierを、Azure管理者またはMicrosoft Entra管理者に渡して手動でFederated credentialsを追加します。
対応の優先順位は、本番デプロイ、共有サービス接続、古いRelease pipelineの順に高く見てください。2027年7月1日のRetirement直前にまとめて対応すると、権限不足や所有者不明のサービス接続で作業が止まりやすくなります。今のうちに対象接続を一覧化し、変換、再実行確認、関係者周知までを一つの作業として進めるのが安全です。
コメント