Azure DevOps の「Retirement of Azure DevOps issuer in Workload identity federation service connections」は、Azure DevOps自体の廃止ではなく、Workload identity federation（WIF）サービス接続で使われている Azure DevOps issuer の廃止です。対象のサービス接続を使っている場合、移行期限は 2027年7月1日 です。すぐに既存パイプラインが止まるわけではありませんが、2026年7月1日から非推奨扱いとなり、パイプライン実行時やサービス接続画面に警告が表示されるため、早めに Microsoft Entra issuer へ変換しておく必要があります。(Microsoft for Developers)
今回のポイントは、YAMLの書き換えよりも「どのサービス接続が古い issuer を使っているか」「そのサービス接続の背後にあるアプリ登録やマネージドIDを誰が管理しているか」を確認することです。特に本番デプロイ、複数プロジェクトで使う接続、Dockerや拡張機能由来の接続は見落としやすいため、期限直前ではなく、棚卸しから始めるのが安全です。
まず結論：2027年7月1日までに Azure DevOps issuer を Microsoft Entra issuer へ移行する
今回の Retirement は、Azure Pipelines などで Azure リソースへ認証するための Workload identity federation service connection に関する変更です。
従来の一部サービス接続では、フェデレーション資格情報の issuer として次の Azure DevOps issuer が使われていました。
https://vstoken.dev.azure.com今後は Microsoft の標準化方針により、Microsoft Entra issuer が使われます。
https://login.microsoftonline.com/Azure DevOps Blog では、Azure DevOps issuer の非推奨化と、2027年7月1日の廃止予定が案内されています。なお、新しく作成される WIF サービス接続については、すでに Microsoft Entra issuer が既定で使われています。(Microsoft for Developers)
重要なのは、Azure DevOpsのサービス終了ではないという点です。Azure Repos、Azure Pipelines、Boards、Artifactsなどが一括で廃止される話ではありません。影響するのは、WIF サービス接続のうち、古い Azure DevOps issuer を使っているものです。
期限とタイムライン
公式発表の分類は Retirement です。実務上は「今すぐ停止」ではなく、「非推奨期間を経て、2027年7月1日にサポート終了」と理解すると分かりやすいです。
| 時期 | 変更内容 | 管理者が取るべき対応 |
|---|---|---|
| 2025年11月以降 | 新規作成される WIF サービス接続は Microsoft Entra issuer を既定で使用 | 新規接続は基本的に問題なし。ただし自動化や手動作成の手順は確認する |
| 2026年6月22日 | Azure DevOps Blog で Retirement が告知 | 既存サービス接続の棚卸しを開始する |
| 2026年7月1日 | Azure DevOps issuer が非推奨扱いになる | 警告が出る接続を特定し、移行計画を立てる |
| 2026年7月〜2027年6月 | パイプライン実行時やサービス接続画面に警告が表示される | 検証環境から順に Microsoft Entra issuer へ変換する |
| 2027年7月1日 | Azure DevOps issuer がサポート終了 | 未移行の対象サービス接続は認証失敗のリスクがある |
既存の対象サービス接続は、2027年7月1日までは動作を継続すると案内されています。ただし、最終日に近づくほど、権限調整、所有者不明のアプリ登録、複数チームとの調整がボトルネックになります。特に本番リリースで使う接続は、遅くとも数か月前には移行を終えておくべきです。(Microsoft for Developers)
影響を受けるサービス接続
影響を受けるのは、Workload identity federation を使っていて、issuer が Azure DevOps issuer のままになっているサービス接続です。判断基準は、サービス接続の種類ではなく、使用している issuer です。
Microsoft Learn では、対象は Azure Resource Manager サービス接続だけに限らず、Docker サービス接続や拡張機能が作成したサービス接続も含まれる可能性があると説明されています。(Microsoft Learn)
| 区分 | 影響 |
|---|---|
| Azure public cloud の WIF サービス接続 | Azure DevOps issuer を使っている場合は移行対象 |
| 単一テナントの Microsoft Entra アプリ | 移行対象になり得る |
| マネージドIDを使う WIF サービス接続 | 移行対象になり得る |
| Azure Resource Manager サービス接続 | issuer が Azure DevOps issuer なら対象 |
| Docker サービス接続 | WIF かつ Azure DevOps issuer なら対象 |
| 拡張機能が作成したサービス接続 | WIF かつ Azure DevOps issuer なら対象 |
| すでに Microsoft Entra issuer を使う接続 | 対象外 |
| Azure Government、Azure China、Azure Stack など非パブリッククラウド向け接続 | 今回の非推奨対象外 |
| マルチテナントアプリを使う接続 | 今回の非推奨対象外 |
対象外の接続は、今回の移行対象ではありません。ただし、今後別の案内が出る可能性はあるため、「対象外だから何も記録しない」ではなく、対象外理由を棚卸し表に残しておくと後から説明しやすくなります。
課金への影響はあるのか
今回の発表は、Azure DevOps の価格改定や有料化ではなく、WIF サービス接続の認証 issuer の切り替えに関するものです。公式発表の主眼は Retirement と移行期限であり、Azure DevOps の課金体系変更として案内されているものではありません。(Microsoft for Developers)
ただし、実務上の「コスト」はゼロとは限りません。次のような運用コストが発生しやすいです。
| コストになりやすいもの | 内容 |
|---|---|
| 棚卸し作業 | プロジェクトごとのサービス接続確認、利用パイプラインの特定 |
| 権限調整 | Azure DevOps 管理者、Azure 管理者、Entra 管理者の調整 |
| 検証工数 | 変換後のパイプライン実行確認、リリース検証 |
| 例外管理 | マルチテナントアプリ、非パブリッククラウド、拡張機能由来の接続の整理 |
| 手戻り対応 | 所有者不明のアプリ登録、古いサービス接続名、不要な権限の見直し |
移行時に既存のサービス接続を変換できる場合は、基本的に接続名や利用箇所を大きく変えずに済みます。逆に、安易に新しいサービス接続を作り直すと、YAMLやリリースパイプライン側の参照変更、承認設定、権限設定の再確認が必要になり、作業量が増えます。
既存パイプラインはすぐ止まるのか
すぐには止まりません。公式FAQでは、Azure DevOps issuer を使う既存のサービス接続は、Retirement 予定日の 2027年7月1日までは動作を継続するとされています。(Microsoft for Developers)
また、Microsoft Entra issuer への変換中も、変換が検証されるまでは既存の Azure DevOps issuer のフェデレーション資格情報が使われます。新しい Microsoft Entra issuer の資格情報が機能することを確認した後に、パイプラインジョブが Microsoft Entra issuer を使う流れです。(Microsoft for Developers)
そのため、正しく変換できれば、利用者側の YAML やタスクの変更なしで済むケースが多いです。ただし、次のような場合は追加確認が必要です。
| 確認が必要なケース | 理由 |
|---|---|
| Marketplace 拡張機能のタスクを使っている | 拡張機能側の WIF 対応状況に依存する場合がある |
| サービス接続を作り直す予定がある | パイプライン側の参照名、承認、権限が変わる可能性がある |
| アプリ登録やマネージドIDの所有者が不明 | 自動変換に失敗したとき、フェデレーション資格情報を追加できない |
| 複数プロジェクトや複数チームで共有している | 影響範囲の確認と変更タイミングの調整が必要 |
| 組織名、プロジェクト名、サービス接続名を過去に変更している | フェデレーション subject の不一致がトラブルになる場合がある |
まず確認すべきこと
移行作業は、いきなり Update ボタンを押すよりも、先に対象範囲を明確にしたほうが安全です。特に複数プロジェクトを運用している組織では、棚卸しをしないまま対応すると、本番リリース用の接続を見落とす可能性があります。
サービス接続画面で警告を確認する
Azure DevOps で対象プロジェクトを開き、次の場所を確認します。
Project settings
→ Service connectionsAzure DevOps issuer を使っている対象サービス接続は、サービス接続一覧の上部に表示され、対応が必要であることを示す警告が出ます。Microsoft Learn でも、該当するサービス接続は一覧の上部に表示され、既存接続を変換することが推奨されています。(Microsoft Learn)
確認時は、単に警告の有無を見るだけでなく、次の情報を記録しておくと移行作業が進めやすくなります。
| 記録項目 | 記録する理由 |
|---|---|
| Azure DevOps 組織名 | 複数組織を管理している場合の混同防止 |
| プロジェクト名 | サービス接続はプロジェクト単位で確認が必要 |
| サービス接続名 | パイプラインから参照される名前 |
| 接続の種類 | ARM、Docker、拡張機能由来などを区別する |
| issuer | Azure DevOps issuer か Microsoft Entra issuer かを判定する |
| 関連するアプリ登録またはマネージドID | 手動変換時に必要 |
| 管理者・所有者 | 自動変換に失敗した場合の連絡先 |
| 利用しているパイプライン | 変換後のテスト対象を決める |
| 対象環境 | 本番、検証、開発で優先順位を付ける |
| 対象外理由 | 非パブリッククラウド、マルチテナントアプリなどの例外管理 |
issuer だけで判断する
「Azure Resource Manager 接続だから対象」「Docker 接続だから対象外」のように、サービス接続タイプだけで判断するのは危険です。
今回の判断軸は、サービス接続が WIF を使っているか、そして issuer が https://vstoken.dev.azure.com 系かどうかです。Microsoft Learn でも、変換要否はサービス接続タイプではなく issuer に基づくと説明されています。(Microsoft Learn)
移行手順：基本は既存サービス接続を Update する
対象のサービス接続を見つけたら、基本方針は 新規作成ではなく既存サービス接続の変換です。既存接続を変換すれば、パイプライン側で参照しているサービス接続を変更せずに済む可能性が高くなります。
自動変換できる場合
通常の流れは次のとおりです。
| 手順 | 作業内容 |
|---|---|
| 1 | Azure DevOps で対象プロジェクトを開く |
| 2 | Project settings → Service connections を開く |
| 3 | 警告が表示されているサービス接続を選択する |
| 4 | Update を選択する |
| 5 | 再度 Update を選択して変換を開始する |
| 6 | 変換完了後、対象パイプラインを実行して確認する |
自動変換が成功すると、そのサービス接続は Microsoft Entra issuer を使う状態になります。Microsoft Learn では、変換には数分かかる場合があり、完了後に成功ダイアログが表示されると説明されています。(Microsoft Learn)
自動変換できない場合
自動変換に失敗する典型例は、Azure DevOps 側のサービス接続は編集できるが、背後にある Microsoft Entra アプリ登録やマネージドIDにフェデレーション資格情報を追加する権限がないケースです。
この場合、Azure DevOps には手動設定に必要な値が表示されます。管理者はそれを Azure 管理者または ID 所有者に渡し、アプリ登録またはマネージドID側にフェデレーション資格情報を追加してもらいます。
手動対応で主に使う値は次のとおりです。
| 値 | 用途 |
|---|---|
| Issuer | Microsoft Entra issuer の URL |
| Subject identifier | サービス接続とフェデレーション資格情報を対応させる識別子 |
| Audience | 認証時の対象。画面や手順に表示される値に合わせる |
| アプリ登録またはマネージドIDのID | どのIDに資格情報を追加するかを特定する |
| テナントID | Microsoft Entra テナントを特定する |
Microsoft Learn では、Azure DevOps のサービス接続権限と Azure / Microsoft Entra 側の権限は別物であり、Azure DevOps で編集できても、フェデレーション資格情報を追加するには別の権限が必要になる場合があると説明されています。(Microsoft Learn)
必要な権限を事前に確認する
移行が止まりやすいのは、技術的な設定よりも権限です。Azure DevOps 管理者が「Update」を押せても、Microsoft Entra アプリ登録やマネージドIDを更新できないと、変換が完了しないことがあります。
| 領域 | 必要になりやすい権限 |
|---|---|
| Azure DevOps サービス接続 | Service connection administrator または endpoint administrator |
| ユーザー割り当てマネージドID | フェデレーション資格情報を追加できる権限。Managed Identity Federated Credential Contributor や Managed Identity Contributor など |
| アプリ登録 | アプリ登録の Owner、またはフェデレーション資格情報を管理できる Microsoft Entra ロール |
| Azure リソース | サブスクリプション、リソースグループ、対象リソースへの必要な RBAC ロール |
| テナント設定 | WIF が制限または無効化されていないこと |
移行前に、対象サービス接続ごとに「Azure DevOps側の管理者」と「ID側の所有者」を分けて記録しておくと、失敗時の切り分けが速くなります。
見落としやすい注意点
Azure DevOps全体の廃止ではない
検索ユーザーが最も誤解しやすいのは、「Azure DevOps issuer の Retirement」を「Azure DevOps の終了」と受け取ってしまうことです。
今回廃止されるのは、WIF サービス接続の認証フローで使われる Azure DevOps issuer です。Azure DevOps サービスそのものの廃止ではありません。
ARMサービス接続だけを見ればよいわけではない
Azure へのデプロイで使う ARM サービス接続が最も分かりやすい対象ですが、それだけでは不十分です。Docker サービス接続や、拡張機能が作成したサービス接続も、WIF と Azure DevOps issuer を使っていれば対象になり得ます。(Microsoft Learn)
棚卸し時は、次のような観点で確認してください。
- 本番環境へデプロイする ARM サービス接続
- Azure Container Registry や Docker 関連で使う接続
- Marketplace 拡張機能が作成・利用する接続
- 古くから存在するサービス接続
- パイプラインから参照されているが所有者が不明な接続
- 複数チームで共有されている接続
作り直しより変換を優先する
移行対応でありがちな失敗は、既存のサービス接続を変換せず、新しいサービス接続を作って差し替えてしまうことです。
新規作成でも動かせる場合はありますが、次の作業が増えます。
- YAML の
azureSubscriptionや service connection 名の変更 - Classic release pipeline 側の接続差し替え
- パイプラインごとの承認設定
- 環境承認やチェックの再確認
- 権限スコープの再設定
- 古い接続の削除判断
既存接続を変換できるなら、パイプライン側の変更を最小限にできます。サービス接続名を変えずに済むため、移行後の検証も単純になります。
「Grant access permission to all pipelines」を安易に使わない
新しいサービス接続を作る場合や、手動で再構成する場合に注意したいのが、すべてのパイプラインにアクセスを許可する設定です。
Microsoft Learn では、全パイプラインへの一括許可は推奨されず、必要なパイプラインごとに承認する方法が案内されています。(Microsoft Learn)
移行対応を機に、サービス接続の利用範囲を見直すのが現実的です。特に本番サブスクリプションに Contributor 相当の権限を持つ接続は、必要なパイプラインだけに絞るべきです。
対象外の接続を無理に移行しない
非パブリッククラウド向けの接続や、マルチテナントアプリを使う接続は、今回の非推奨対象外です。公式発表でも、これらのシナリオでは Microsoft Entra issuer がサポートされるまで Azure DevOps issuer が引き続きサポートされると説明されています。(Microsoft for Developers)
対象外の接続を無理に変更すると、かえって認証方式やクロステナント運用に影響する可能性があります。棚卸し表には「対象外」と記録し、公式情報の更新を追跡する扱いにしておくとよいでしょう。
トラブル時の確認ポイント
移行時にエラーが出た場合は、エラーメッセージだけで判断せず、issuer、subject、audience、ID所有者、テナント設定を順番に確認します。
| 症状 | よくある原因 | 確認すること |
|---|---|---|
| Update が失敗する | アプリ登録またはマネージドIDに資格情報を追加する権限がない | ID所有者、必要ロール、Azure DevOps側の権限 |
AADSTS70021 系のエラー | issuer または subject が一致していない | Azure DevOps側に表示された値と Entra 側のフェデレーション資格情報 |
AADSTS700213 | subject が一致していない | サービス接続名、組織・プロジェクト変更履歴、subject identifier |
AADSTS700223 / AADSTS700238 | テナント側で WIF が制限または無効化されている | Microsoft Entra のポリシー、テナント管理者への確認 |
| 変換後に一部タスクだけ失敗する | タスクや拡張機能が WIF に対応していない、または古い実行環境を使っている | タスクバージョン、Marketplace拡張機能、エージェント上の Azure CLI など |
| 誰がIDを管理しているか分からない | アプリ登録やマネージドIDの所有者が整理されていない | アプリ登録の Owners、マネージドIDのリソースグループ権限、サブスクリプション管理者 |
Microsoft Learn のトラブルシューティングでは、WIF 関連の問題として、タスクの対応状況、テナントで WIF が有効かどうか、issuer URL と federation subject の一致確認が挙げられています。(Microsoft Learn)
実務でおすすめの移行計画
対象が少ない場合は、サービス接続画面から順に Update して検証すれば十分です。対象が多い組織では、次の順序で進めると安全です。
| フェーズ | 作業 | 目的 |
|---|---|---|
| 棚卸し | 全プロジェクトのサービス接続を確認し、issuer と利用パイプラインを記録 | 対象漏れを防ぐ |
| 分類 | 本番、検証、開発、対象外、所有者不明に分ける | 優先順位を決める |
| 権限確認 | Azure DevOps 管理者と ID 所有者を特定 | 自動変換失敗時に止まらないようにする |
| 検証環境で変換 | 開発・検証用接続から Update | 影響と手順を確認する |
| 本番前リハーサル | 本番と同じ構成の接続で実行確認 | リリース停止を避ける |
| 本番変換 | リリース予定が少ないタイミングで変換 | 影響を最小化する |
| 後片付け | 警告が消えたか、不要な旧設定が残っていないか確認 | 運用負債を残さない |
大規模環境では、スクリプトや REST API を使った棚卸し・作成自動化も検討できます。Microsoft Learn では、複数環境で一貫したサービス接続を作るためにスクリプトを利用する方法が案内されており、ID、サービス接続、フェデレーション資格情報、ロール割り当てを順序立てて作成する考え方が示されています。(Microsoft Learn)
移行後に確認すべきこと
変換が成功しただけで完了にしないことが大切です。移行後は、最低限次の確認を行います。
| 確認項目 | 確認内容 |
|---|---|
| issuer | Microsoft Entra issuer に変わっているか |
| パイプライン実行 | 対象サービス接続を使うパイプラインが成功するか |
| 警告表示 | サービス接続画面やパイプライン実行時の警告が消えているか |
| 権限スコープ | 不要に広い RBAC が付いていないか |
| パイプライン承認 | 必要なパイプラインだけが接続を使えるか |
| ドキュメント | 移行日、対象接続、確認結果、例外理由を記録したか |
本番環境では、変換直後に「軽い確認用パイプライン」を実行して終わりにするのではなく、実際のデプロイに近い処理を通すのが安全です。Azure CLI、Azure PowerShell、ARM/Bicep、Container Registry、Key Vault など、サービス接続を使うタスクが複数ある場合は、それぞれの代表パスを確認してください。
よくある疑問
Azure DevOps が廃止されるという意味ですか？
違います。廃止されるのは、WIF サービス接続で使われている Azure DevOps issuer です。Azure DevOps サービス全体の廃止ではありません。
YAML の修正は必要ですか？
既存のサービス接続をそのまま変換できる場合、YAML の修正は不要なケースが多いです。サービス接続を作り直して別名にする場合は、YAML やリリースパイプライン側の参照変更が必要になります。
既存のシークレット方式のサービス接続も今回の対象ですか？
今回の主対象は、WIF を使っていて Azure DevOps issuer を使うサービス接続です。シークレット方式そのものの廃止告知ではありません。ただし、Microsoft は Azure Resource Manager サービス接続では WIF の利用を推奨しており、シークレット管理を減らす観点では、別途 WIF への移行を検討する価値があります。(Microsoft Learn)
マルチテナントアプリを使っている場合はどうすればよいですか？
今回の非推奨対象外です。無理に Microsoft Entra issuer へ移行しようとせず、対象外として記録し、今後の公式案内を追跡してください。
自動変換に失敗した場合、何を管理者に渡せばよいですか？
Azure DevOps に表示される Issuer、Subject identifier、必要に応じて Audience を渡します。あわせて、対象のアプリ登録またはマネージドID、サービス接続名、Azure DevOps組織・プロジェクト名も共有すると、ID所有者が対応しやすくなります。
今から取るべき対応
まずは、Azure DevOps の各プロジェクトで Project settings → Service connections を開き、Azure DevOps issuer の警告が出ているサービス接続を一覧化してください。次に、本番デプロイで使う接続、権限が強い接続、所有者が不明な接続から優先順位を付けます。
対応の基本は、既存サービス接続を Microsoft Entra issuer へ変換することです。自動変換で済む接続は早めに処理し、失敗する接続はアプリ登録やマネージドIDの所有者と調整します。2027年7月1日までは猶予がありますが、権限調整や例外確認に時間がかかるため、警告が出始める2026年7月以降に棚卸しを始めるのではなく、早い段階で対象を確定しておくのが安全です。
コメント