Azure DevOps の「Retirement of Azure DevOps issuer in Workload identity federation service connections」は、すぐに全パイプラインが停止する不具合ではありません。対象は、Workload identity federation のサービス接続で Azure DevOps issuer、つまり https://vstoken.dev.azure.com を使っている一部の接続です。Microsoft は 2026年6月22日の Azure DevOps Blog で、Azure DevOps issuer を 2027年7月1日に廃止予定と発表しています。既存の対象接続は当面動作しますが、警告表示が出たら Microsoft Entra issuer への変換を計画すべきです。 (Microsoft for Developers)
この記事では、Azure DevOps で起きやすい警告・エラー・表示の違いを、管理者と開発者が確認すべきポイントに分けて整理します。特に「Pipeline に警告が出た」「Update ボタンで変換できない」「AADSTS70021 などの認証エラーが出る」「誰に権限確認すればよいか分からない」という場合は、サービス接続と Microsoft Entra 側のフェデレーション資格情報を順に確認することが重要です。
Retirement of Azure DevOps issuer in Workload identity federation service connections とは
今回の変更は、Azure DevOps の Workload identity federation、略して WIF、で使われる 発行者 issuer の移行です。
従来の一部サービス接続では、フェデレーション資格情報の issuer として Azure DevOps issuer の https://vstoken.dev.azure.com が使われていました。Microsoft はこれを Microsoft Entra issuer、つまり https://login.microsoftonline.com/ に標準化する方針です。 (Microsoft for Developers)
ここで重要なのは、サービス接続そのものが廃止されるわけではない点です。対象となるのは、Workload identity federation を使い、かつ Azure DevOps issuer を利用しているサービス接続です。Microsoft Learn では、Azure Resource Manager 接続だけでなく、Docker 接続や拡張機能が作成したサービス接続なども、issuer が Azure DevOps issuer なら変換対象になり得ると説明されています。 (Microsoft Learn)
まず確認すべき結論
| 確認項目 | 見るべきポイント |
|---|---|
| すぐ壊れるか | 既存の対象サービス接続は 2027年7月1日の廃止予定日までは継続利用可能とされています |
| 何をすればよいか | 対象サービス接続を Microsoft Entra issuer に変換する |
| YAML の修正が必要か | 通常のパイプラインタスクの使い方は変わらないため、多くの場合 YAML 修正は不要 |
| 警告が出たらどうするか | 対象サービス接続を開き、Update で変換できるか確認する |
| 変換できない場合 | Azure 管理者、Microsoft Entra 管理者、アプリ登録またはマネージド ID の所有者に確認する |
対象になるサービス接続と対象外のサービス接続
今回の Retirement は、すべての Azure DevOps 利用者に同じ影響が出る変更ではありません。影響範囲を正しく切り分けることで、不要な対応や誤った再作成を避けられます。
対象になる可能性が高いケース
対象になるのは、主に次の条件に当てはまるサービス接続です。
| 条件 | 内容 |
|---|---|
| Azure DevOps Services を利用している | Azure Pipelines のサービス接続を使っている |
| Workload identity federation を使っている | シークレットではなくフェデレーション認証で Azure などに接続している |
issuer が https://vstoken.dev.azure.com | Azure DevOps issuer を使っている |
| Azure public cloud 向け | Azure Government や Azure China などではない |
| 単一テナントの Microsoft Entra アプリ、またはマネージド ID を使っている | multi-tenant アプリではない |
Microsoft の説明では、この非推奨化は Azure public cloud のうち、単一テナント Microsoft Entra アプリケーションまたはマネージド ID を使うサービス接続に適用されます。非公開クラウドや multi-tenant アプリを使うケースは、今回の非推奨化の対象外とされています。 (Microsoft for Developers)
対象外になりやすいケース
次のようなサービス接続は、今回の移行対象ではない可能性があります。
| ケース | 判断の目安 |
|---|---|
| すでに Microsoft Entra issuer を使っている | https://login.microsoftonline.com/ が issuer になっている |
| Azure Government、Azure China、Azure Stack 向け | Microsoft の発表では対象外 |
| multi-tenant アプリを使っている | signInAudience: AzureADMultipleOrgs のような構成 |
| Workload identity federation を使っていない | 従来のシークレットや別方式のサービス接続 |
ただし、実際の対象判定はサービス接続の種類だけでは決まりません。Azure Resource Manager、Docker、拡張機能によるサービス接続など、種類ではなく issuer が何かで確認するのが安全です。 (Microsoft Learn)
変更スケジュールを正しく理解する
Azure DevOps issuer の廃止は段階的に進みます。警告が出た時点で慌ててパイプラインを作り直すのではなく、期限を意識して計画的に対応しましょう。
| 日付・期間 | 変更内容 |
|---|---|
| 2025年11月以降 | 新規作成される Workload identity federation サービス接続は Microsoft Entra issuer を既定で使用 |
| 2026年7月1日 | Azure DevOps issuer が非推奨化 |
| 2026年7月〜2027年6月 | 対象サービス接続で、パイプライン実行時やサービス接続画面に警告が表示される |
| 2027年7月1日 | Azure DevOps issuer がサポート終了予定 |
既存パイプラインがすぐに停止するわけではありませんが、2027年7月1日以降は Azure DevOps issuer がサポートされなくなる予定です。運用中の本番デプロイ、定期バッチ、インフラ更新パイプラインで使っているサービス接続は、早めに棚卸ししておくべきです。 (Microsoft for Developers)
よくある警告・エラーと対処法
Pipeline に deprecated Azure DevOps issuer の警告が出る
パイプライン実行時に Azure DevOps issuer の非推奨警告が出る場合、そのパイプラインが参照しているサービス接続が古い issuer を使っている可能性があります。
この警告は、直ちに失敗を意味するものではありません。しかし、放置すると廃止予定日以降に認証失敗へつながるおそれがあります。
対処手順は次の通りです。
| 手順 | 作業内容 |
|---|---|
| 1 | 警告に表示されたサービス接続名を確認する |
| 2 | Azure DevOps の対象プロジェクトで Project settings > Service connections を開く |
| 3 | 警告付きで表示されるサービス接続を開く |
| 4 | Update ボタンが表示されていれば変換を実行する |
| 5 | 変換後にパイプラインを再実行し、警告や認証エラーが消えるか確認する |
Microsoft Learn でも、警告が出る場合は対象サービス接続を Microsoft Entra issuer に変換し、変換後にパイプラインを再実行する流れが案内されています。 (Microsoft Learn)
Service connections 画面で対象接続が上に表示される
Azure DevOps の Project settings > Service connections 画面で、対応が必要なサービス接続が一覧の上部に表示され、警告が出る場合があります。これは、Azure DevOps issuer を使う対象接続を見つけやすくするための表示です。 (Microsoft for Developers)
この場合、まずはサービス接続を新規作成し直すのではなく、既存のサービス接続を変換するのが基本です。既存接続を再利用すれば、YAML や Classic pipeline 側で参照している接続名を変更せずに済むため、影響範囲を抑えられます。
Update ボタンを押しても自動変換に失敗する
Update ボタンで変換しようとして失敗する場合、多くは Azure DevOps 側ではなく、Microsoft Entra や Azure リソース側の権限不足が原因です。
代表的な確認点は次の通りです。
| 確認先 | 確認する内容 |
|---|---|
| Azure DevOps | 対象サービス接続の管理権限、または endpoint administrator 権限があるか |
| Microsoft Entra アプリ登録 | フェデレーション資格情報を追加できる所有者または適切な管理権限があるか |
| ユーザー割り当てマネージド ID | Federated Credential Contributor、Managed Identity Contributor など、資格情報を追加できる権限があるか |
| Azure サブスクリプション・リソースグループ | 対象 ID に必要なロールが割り当てられているか |
| 組織の管理分掌 | Azure DevOps 管理者と Entra 管理者が別チームではないか |
Microsoft Learn では、Azure DevOps のサービス接続を編集できても、Azure や Microsoft Entra の ID を更新する権限がなければ、フェデレーション資格情報の追加は別管理者に依頼する必要があると説明されています。 (Microsoft Learn)
Microsoft Entra issuer への変換手順
自動変換できる場合
対象サービス接続で Update が使える場合は、Azure DevOps の画面から変換できます。
| 手順 | 操作 |
|---|---|
| 1 | Azure DevOps で対象プロジェクトを開く |
| 2 | Project settings > Service connections を開く |
| 3 | 警告が表示されているサービス接続を選択する |
| 4 | Update を選択する |
| 5 | 確認画面でもう一度 Update を選ぶ |
| 6 | 変換完了後、サービス接続が Microsoft Entra issuer を使う状態になったことを確認する |
| 7 | 実際のパイプラインを再実行して確認する |
変換中も、既存の Azure DevOps issuer のフェデレーション資格情報は参照されます。Microsoft の FAQ では、新しい Microsoft Entra issuer の資格情報が変換中に検証され、その後パイプラインジョブが Microsoft Entra issuer を使い始めると説明されています。 (Microsoft for Developers)
手動変換が必要な場合
自動変換に失敗する場合や、Azure DevOps 管理者が Microsoft Entra の ID を更新できない場合は、手動でフェデレーション資格情報を追加します。
手動対応では、Azure DevOps 側に表示される次の値を正確にコピーして、アプリ登録またはマネージド ID の Federated credentials に設定します。
| 値 | 意味 |
|---|---|
| Issuer | Microsoft Entra issuer の URL |
| Subject identifier | 対象サービス接続に対応するフェデレーション subject |
| Audience | トークンの対象 audience |
特に Subject identifier は、組織名、プロジェクト名、サービス接続名などに依存する場合があります。手入力で少しでもずれると、No matching federated identity record found 系のエラーになります。
手動変換の基本手順は次の通りです。
| 手順 | 作業内容 |
|---|---|
| 1 | Azure DevOps の対象サービス接続で手動変換に必要な Issuer、Subject identifier、Audience を確認する |
| 2 | Azure Portal または Microsoft Entra 管理センターで、対象のアプリ登録またはマネージド ID を開く |
| 3 | Federated credentials に新しい資格情報を追加する |
| 4 | Azure DevOps に表示された値をそのまま入力する |
| 5 | Azure DevOps に戻り、検証または Try again を実行する |
| 6 | パイプラインを再実行して動作確認する |
Microsoft Learn でも、自動変換できない場合は Azure DevOps で生成された Issuer、Subject identifier、Audience をコピーし、関連する ID にフェデレーション資格情報を追加してからサービス接続のセットアップを完了する流れが示されています。 (Microsoft Learn)
AADSTS エラー別の見方と対処
Azure DevOps issuer の移行時には、Microsoft Entra の認証エラーが表示されることがあります。エラーコードを見れば、どこを確認すべきか絞り込めます。
| エラー例 | 起きやすい原因 | 対処の方向性 |
|---|---|---|
AADSTS700016 | サービス接続で使うアプリケーション ID が存在しない、または設定が違う | appID / clientId、対象アプリ登録の存在、削除有無を確認する |
AADSTS70021 | issuer または subject に一致するフェデレーション資格情報がない | Azure DevOps 側の値と Entra 側の Federated credentials を比較する |
AADSTS700211 | issuer が一致しない | issuer URL が正しいか確認する |
AADSTS700213 | subject が一致しない | 組織名、プロジェクト名、サービス接続名の変更履歴を確認する |
AADSTS700223 | テナント側で Workload identity federation が制限または無効化されている | Microsoft Entra テナント管理者に制約を確認する |
AADSTS70025 | フェデレーション資格情報が未構成 | アプリ登録またはマネージド ID に Federated credentials を追加する |
AADSTS70052 | Microsoft Entra issuer でサポートされない multi-tenant アプリ構成の可能性 | 単一テナント構成やサービス接続分割を検討し、必要に応じて管理者・サポートへ確認する |
AADSTS900382 | クロスクラウドやソブリンクラウドの制約 | 対象クラウドが今回の移行対象か確認する |
Microsoft Learn では、issuer、subject、audience、フェデレーション資格情報の不一致が Workload identity federation の認証失敗につながると説明されています。特に AADSTS70021、AADSTS700211、AADSTS700213 は、値の不一致を疑うべき典型的なエラーです。 (Microsoft Learn)
AADSTS70021 が出たときの実務的な切り分け
AADSTS70021: No matching federated identity record found for presented assertion は、Azure DevOps のサービス接続移行でよく見落とされやすいエラーです。
このエラーが出たら、まず次の順番で確認します。
| 順番 | 確認内容 |
|---|---|
| 1 | Azure DevOps のサービス接続画面に表示される issuer と subject をコピーする |
| 2 | Microsoft Entra のアプリ登録、またはマネージド ID の Federated credentials を開く |
| 3 | issuer が https://login.microsoftonline.com/テナントID 形式になっているか確認する |
| 4 | subject が Azure DevOps 側の値と完全一致しているか確認する |
| 5 | audience が想定値と一致しているか確認する |
| 6 | 最近、Azure DevOps の organization、project、service connection の名前を変更していないか確認する |
特に、手動で作成したサービス接続や、過去に組織名・プロジェクト名・サービス接続名を変更した環境では、subject の不一致が起きやすくなります。表示上は同じ接続に見えても、フェデレーション資格情報側の subject が古い値のままだと認証に失敗します。
管理者に確認すべきポイント
開発者がパイプラインの警告だけを見ても、移行を完了できない場合があります。サービス接続、Microsoft Entra、Azure リソースの管理者が分かれている組織では、早めに確認先を整理しておくことが重要です。
Azure DevOps 管理者に確認すること
| 確認項目 | 理由 |
|---|---|
| 対象プロジェクトの Service connections 一覧 | 警告付き接続を棚卸しするため |
| 対象サービス接続を使うパイプライン | 本番・検証・定期実行の影響範囲を把握するため |
| サービス接続の管理権限 | Update や設定確認に必要なため |
| すべての pipeline に許可しているか | 不要な広範囲許可がないか見直すため |
| 変換後の実行確認方法 | 移行後に失敗を早期発見するため |
サービス接続は YAML では名前で参照されることが多いため、安易に削除・再作成するとパイプライン定義の修正が必要になる場合があります。Microsoft Learn でも、既存のサービス接続を変換すれば、既存パイプライン側の参照更新を避けやすいと説明されています。 (Microsoft Learn)
Microsoft Entra 管理者に確認すること
| 確認項目 | 理由 |
|---|---|
| 対象アプリ登録の所有者 | Federated credentials を追加できる人を特定するため |
| マネージド ID の管理権限 | 自動変換や手動追加に必要なため |
| Workload identity federation のテナント制約 | AADSTS700223 や AADSTS700238 の原因確認に必要 |
| multi-tenant アプリの有無 | 今回の対象外、または別対応になる可能性がある |
| issuer / subject / audience の一致 | 認証失敗の主要原因を潰すため |
Azure DevOps 管理者がサービス接続を編集できても、アプリ登録やマネージド ID のフェデレーション資格情報を追加できるとは限りません。移行作業では、Azure DevOps 側の権限と Microsoft Entra 側の権限を分けて考える必要があります。 (Microsoft Learn)
Azure サブスクリプション管理者に確認すること
| 確認項目 | 理由 |
|---|---|
| サービス接続で使う ID のロール割り当て | 変換後も Azure リソース操作ができるか確認するため |
| Contributor などの権限範囲 | 必要以上に広い権限になっていないか確認するため |
| リソースグループ単位・サブスクリプション単位の違い | デプロイ先によって必要権限が変わるため |
| マネージド ID の配置リソースグループ | 所有者や管理者を特定するため |
issuer の変換自体が成功しても、対象 ID に Azure リソース操作の権限がなければ、デプロイやコマンド実行で失敗します。認証と認可は別物として確認しましょう。
表示の違いで混乱しやすいポイント
新規サービス接続では警告が出ないことがある
2025年11月以降、新しく作成される Workload identity federation サービス接続は Microsoft Entra issuer を既定で使うとされています。そのため、新しいサービス接続では警告が出ず、古いサービス接続だけに警告が出ることがあります。 (Microsoft for Developers)
同じプロジェクト内でも、作成時期によって表示が違う可能性があります。単に「A のパイプラインでは警告が出ないから B も問題ない」と判断せず、サービス接続ごとに issuer を確認してください。
パイプライン YAML は同じでも裏側の issuer が違う
Microsoft の FAQ では、Microsoft Entra issuer への移行後も通常のパイプラインタスクの使い方は変わらず、issuer は通常利用では隠れた実装詳細だと説明されています。 (Microsoft for Developers)
そのため、YAML の azureSubscription やサービス接続名が同じでも、裏側の issuer だけが変わるケースがあります。見た目の YAML 差分がないため、移行確認では UI の警告、実行ログ、サービス接続の状態を確認する必要があります。
multi-tenant アプリでは対応方針が違う
multi-tenant アプリケーションを使うサービス接続は、今回の非推奨化の対象外とされています。Microsoft の FAQ では、AADSTS70052 に関連する組織全体の例外がある場合、サービス接続単位の例外を提供する体験を準備中であり、それまでは体験に違いはないと説明されています。 (Microsoft for Developers)
multi-tenant アプリを使っている場合は、単純に Microsoft Entra issuer へ変換しようとして失敗することがあります。該当環境では、先にアプリの signInAudience、接続先テナント、Azure DevOps 組織の例外設定を確認してください。
移行前にやっておきたい棚卸し
Azure DevOps issuer の移行は、警告が出た接続だけを場当たり的に直すより、サービス接続の棚卸しとして進める方が安全です。
棚卸し項目
| 項目 | 記録しておく内容 |
|---|---|
| Project 名 | サービス接続が属する Azure DevOps プロジェクト |
| Service connection 名 | YAML や Classic pipeline で参照される名前 |
| 接続タイプ | Azure Resource Manager、Docker、拡張機能由来など |
| issuer | Azure DevOps issuer か Microsoft Entra issuer か |
| 認証対象 | アプリ登録かマネージド ID か |
| 管理者 | Azure DevOps 側、Microsoft Entra 側、Azure 側の担当者 |
| 利用パイプライン | 本番デプロイ、検証環境、定期実行など |
| 移行優先度 | 本番影響、実行頻度、復旧難易度で判断 |
| 変換状況 | 未対応、変換済み、管理者確認中、対象外 |
優先度の付け方
すべてのサービス接続を同じ優先度で対応する必要はありません。次の順で優先度を付けると、実務では進めやすくなります。
| 優先度 | 対象 |
|---|---|
| 高 | 本番デプロイ、障害対応、定期実行ジョブ、インフラ変更に使う接続 |
| 中 | 検証環境やステージング環境で継続利用している接続 |
| 低 | 使われていない可能性がある古い接続、検証用の一時接続 |
| 対象外候補 | Microsoft Entra issuer 済み、非公開クラウド、multi-tenant アプリ |
使われていないサービス接続は、移行より先に利用状況を確認しましょう。不要な接続を残すと、警告対応の手間だけでなく、セキュリティ上の管理対象も増えます。
失敗しやすい対応と避け方
サービス接続をすぐ作り直してしまう
警告を見て新しいサービス接続を作成し、古い接続を削除するのは避けた方が安全です。YAML や Classic pipeline、承認とチェック、利用許可、運用手順書などに影響が出る場合があります。
まずは既存サービス接続の Update による変換を検討してください。
Azure DevOps の権限だけで完了できると思い込む
今回の移行は、Azure DevOps の画面だけで完了する場合もありますが、裏側では Microsoft Entra のアプリ登録やマネージド ID の Federated credentials が関係します。
Azure DevOps 側で編集できても、Entra 側の ID を更新できない場合があります。変換に失敗したら、エラー内容だけでなく、誰が対象 ID の所有者なのかを確認しましょう。
issuer だけを見て subject を確認しない
Microsoft Entra issuer に変更しても、subject が一致しなければ認証は成功しません。特に、組織名、プロジェクト名、サービス接続名の変更があった環境では注意が必要です。
手動でフェデレーション資格情報を追加する場合は、Azure DevOps に表示された値をコピーし、余計な空白や古い値を混ぜないようにしてください。
本番パイプラインでいきなり確認する
変換自体は大きなダウンタイムを伴いにくいとされていますが、権限不足や手動設定ミスがあると、デプロイ時に認証エラーが出る可能性があります。
本番接続を変換する前に、同じ構成の検証用パイプラインで以下を確認しておくと安全です。
| 確認項目 | 具体例 |
|---|---|
| 認証 | Azure CLI、ARM デプロイ、Docker push などが通るか |
| 認可 | 対象サブスクリプションやリソースグループに操作権限があるか |
| ログ | Azure DevOps issuer の警告が消えているか |
| 再実行 | 1回だけでなく、手動再実行やスケジュール実行でも問題ないか |
| ロールバック方針 | 失敗時にどの接続・設定を戻すか関係者で合意しているか |
開発者向けの確認チェックリスト
開発者は、まず自分のパイプラインがどのサービス接続を使っているかを確認しましょう。
| チェック | 内容 |
|---|---|
YAML の azureSubscription や service connection 名を確認した | はい / いいえ |
| パイプライン実行ログに deprecated issuer の警告があるか確認した | はい / いいえ |
| 警告対象のサービス接続を管理者に共有した | はい / いいえ |
| 変換後に同じパイプラインを再実行した | はい / いいえ |
| AADSTS エラーが出た場合、エラーコードを保存した | はい / いいえ |
開発者側でできることは、警告と利用箇所を正確に伝えることです。サービス接続や Entra ID の所有権が別チームにある場合、エラーコード、サービス接続名、パイプライン URL、実行日時を添えて依頼すると調査が速くなります。
管理者向けの確認チェックリスト
管理者は、対象サービス接続を一覧化し、期限までに計画的に変換します。
| チェック | 内容 |
|---|---|
Project settings > Service connections で警告付き接続を確認した | はい / いいえ |
| Azure DevOps issuer を使う接続を一覧化した | はい / いいえ |
| 対象外の接続を分類した | はい / いいえ |
| アプリ登録またはマネージド ID の所有者を確認した | はい / いいえ |
自動変換できる接続を Update で変換した | はい / いいえ |
| 手動対応が必要な接続について Issuer / Subject / Audience を共有した | はい / いいえ |
| 変換後のパイプライン実行確認を行った | はい / いいえ |
| 2027年7月1日までの対応計画を作成した | はい / いいえ |
まとめ：警告は放置せず、サービス接続単位で計画的に変換する
Retirement of Azure DevOps issuer in Workload identity federation service connections は、Azure DevOps のサービス接続をより標準的な Microsoft Entra issuer へ移行するための変更です。既存パイプラインが直ちに壊れる変更ではありませんが、Azure DevOps issuer の廃止予定日は 2027年7月1日です。警告が表示されたサービス接続は、期限前に変換しておく必要があります。 (Microsoft for Developers)
対応の基本は、Project settings > Service connections で警告付き接続を確認し、可能であれば Update で Microsoft Entra issuer へ変換することです。自動変換できない場合は、Azure DevOps 側に表示される Issuer、Subject identifier、Audience を Microsoft Entra のアプリ登録またはマネージド ID の Federated credentials に正しく設定します。 (Microsoft Learn)
次に取るべき行動は、警告が出ているパイプラインだけを見るのではなく、プロジェクト単位でサービス接続を棚卸しすることです。本番デプロイや定期実行で使う接続から優先的に確認し、Azure DevOps 管理者、Microsoft Entra 管理者、Azure サブスクリプション管理者の役割分担を明確にしておきましょう。
コメント