Azure DevOps の Microsoft Entra ID 認証で、2026年4月更新としてまず押さえるべき結論は「PAT（Personal Access Token）を標準の認証手段として使い続けるのではなく、Microsoft Entra ID トークンを中心に設計し直すべき」という点です。Microsoft Learn の「Authenticate to Azure DevOps with Microsoft Entra ID」は2026年4月22日に更新され、より安全な Microsoft Entra tokens を優先し、PAT は高リスクな認証手段として慎重に扱う方針が明確に示されています。(Microsoft Learn)
特に影響を受けるのは、Azure DevOps を利用するセキュリティ管理者、ID管理チーム、コンプライアンス担当者です。開発者だけの話ではなく、組織全体で「誰が、どのアプリが、どの権限で Azure DevOps にアクセスしているか」を再確認するタイミングと考えるべきです。
2026年4月更新の要点：PAT前提からMicrosoft Entra ID前提へ
今回の更新は、Azure DevOps における認証の考え方を「個人が作成した長寿命トークン」から「Microsoft Entra ID による短寿命・ポリシー適用可能なトークン」へ寄せる内容です。
Microsoft 公式ドキュメントでは、Azure DevOps へのアクセス方法として主に次の2系統が整理されています。1つは、ユーザーがサインインしてアプリに委任する「User delegation（OAuth）」、もう1つは、サービスプリンシパルやマネージドIDを使う「Application identity」です。前者はWebアプリやデスクトップアプリなど人が操作する場面に向き、後者はCI/CD、バックグラウンド処理、自動化ツールに向きます。(Microsoft Learn)
| 利用シーン | 推奨される認証方式 | 実務上の判断ポイント |
|---|---|---|
| ユーザーが操作するWebアプリ、デスクトップアプリ | Microsoft Entra ID OAuth | ユーザー本人の権限で操作させたい場合に適している |
| バックグラウンドサービス、自動化処理 | サービスプリンシパル、マネージドID | 人のアカウントに依存しない運用にしたい場合に適している |
| Azure Functions、App Service などAzure上の単一リソース | システム割り当てマネージドID | リソースとIDのライフサイクルを一致させたい場合に有効 |
| 複数のAzureリソースで同じIDを使う処理 | ユーザー割り当てマネージドID | 共有IDとして一元管理したい場合に有効 |
| Azure Pipelines からAzure DevOpsリソースへアクセス | Azure DevOps service connection + workload identity federation | PATを保存せず、パイプライン単位で権限管理したい場合に有効 |
| 一時的なREST API検証 | Azure CLIで発行したMicrosoft Entraトークン | 短時間の調査や検証に向いている |
| 個人の一時スクリプト、移行中の古い仕組み | PATを限定的に利用 | スコープ・期限・保管方法を厳格に管理する |
重要なのは、「PATをすぐ全廃できるか」ではなく、「PATを使わなくてよい場面を見つけ、順番に置き換える」ことです。Azure DevOps Services の新規アプリケーションでは Microsoft Entra ID 認証が推奨され、PAT は Microsoft Entra ID が利用できない場面に限定して慎重に使うべきとされています。(Microsoft Learn)
Microsoft Entra ID認証が重視される理由
Microsoft Entra ID 認証が重視される最大の理由は、セキュリティ統制を組織ポリシーとして適用しやすいことです。
PATは便利ですが、長期間有効なトークンを個人が発行し、スクリプト、環境変数、設定ファイル、CI/CDの変数などに保存しがちです。スコープを広くしすぎたり、有効期限を長くしすぎたりすると、漏えい時の影響が大きくなります。
一方、Microsoft Entra ID トークンは短寿命で、公式比較では1時間の有効期限と自動更新が示されています。また、多要素認証、条件付きアクセス、組織レベルのポリシー、監査ログなどと組み合わせやすい点がメリットです。(Microsoft Learn)
| 比較項目 | Microsoft Entra IDトークン | PAT |
|---|---|---|
| 有効期限 | 短寿命。公式比較では1時間と整理 | 最大で長期間になりやすい |
| 多要素認証 | ネイティブに組み込みやすい | トークン自体には適用しにくい |
| 条件付きアクセス | 適用しやすい | 適用しにくい |
| 組織ポリシー | Microsoft Entra IDと連携して統制しやすい | 作成者・スコープ・期限の管理が課題になりやすい |
| 監査 | ID基盤と組み合わせて追跡しやすい | 基本的な追跡にとどまりやすい |
| 運用上の弱点 | 実装設計が必要 | 便利なため乱立しやすい |
セキュリティ管理者にとっては、単に「トークンの種類を変える」話ではありません。認証方式を Microsoft Entra ID に寄せることで、退職者アカウント、休眠アカウント、過剰権限、条件付きアクセス違反、監査証跡といった管理課題を、より一貫した形で扱えるようになります。
まず確認すべき対象サービスはAzure DevOps Services
今回の更新で注意したいのは、対象が主に Azure DevOps Services である点です。Microsoft の認証方式ガイダンスでは、OAuth 2.0 と Microsoft Entra ID 認証は Azure DevOps Services 向けであり、Azure DevOps Server には適用されないと説明されています。オンプレミスの Azure DevOps Server では、.NETクライアントライブラリ、Windows認証、PATなどを利用する前提が残ります。(Microsoft Learn)
そのため、グローバル企業や大規模組織では、最初に環境を分けて棚卸しする必要があります。
| 確認項目 | 見るべきポイント |
|---|---|
| 利用形態 | Azure DevOps Services か、Azure DevOps Server か |
| 組織連携 | Azure DevOps organization が Microsoft Entra テナントに接続されているか |
| PAT利用状況 | 誰が、どのスコープで、どの期限のPATを使っているか |
| 自動化処理 | パイプライン、バッチ、外部SaaS連携で個人PATを使っていないか |
| 監査要件 | 認証ログ、アクセス権限、例外承認の記録が残せるか |
特に、海外拠点や買収した組織が独自の Azure DevOps organization を持っている場合、同じMicrosoft Entraテナントに接続されているとは限りません。認証移行を進める前に、テナント構成と管理者権限を確認しておくことが重要です。
認証方式は「人が操作するか」「システムが操作するか」で分ける
Azure DevOps の Microsoft Entra ID 認証では、最初の判断軸をシンプルにすると失敗しにくくなります。
人が操作するアプリなら、User delegation、つまり Microsoft Entra ID OAuth を検討します。ユーザーが Microsoft Entra ID でサインインし、アプリはサインイン済みユーザーの権限で Azure DevOps にアクセスします。多要素認証や条件付きアクセスを利用できるため、社内ポータル、開発者向けダッシュボード、レビュー支援ツールなどに向いています。(Microsoft Learn)
システムが自動で操作するなら、サービスプリンシパルまたはマネージドIDを検討します。バックグラウンドサービス、Azure Functions、Azure Pipelines、夜間バッチ、外部連携処理などで、個人ユーザーの資格情報を使い回す設計は避けるべきです。Microsoft 公式ドキュメントでも、サービスプリンシパルとマネージドIDは自動化ワークフロー向けの安全でスケーラブルな認証手段として位置付けられています。(Microsoft Learn)
サービスプリンシパルとマネージドIDの使い分け
サービスプリンシパルは、Microsoft Entra ID上のアプリケーションを表すIDです。アプリ登録によって作成され、証明書またはクライアントシークレットを使って認証します。クロスクラウド、外部環境、柔軟なCI/CD構成などに向いています。(Microsoft Learn)
マネージドIDは、Azureが管理する特殊なサービスプリンシパルです。開発者がシークレットを管理しなくてよい点が大きな利点です。システム割り当てマネージドIDは単一のAzureリソースに紐づき、ユーザー割り当てマネージドIDは複数リソースで共有できます。(Microsoft Learn)
| IDの種類 | 向いている用途 | 注意点 |
|---|---|---|
| サービスプリンシパル | 外部環境、クロスクラウド、CI/CD、Azure外のアプリ | 証明書またはシークレットの管理が必要 |
| システム割り当てマネージドID | Azure Functions、App Serviceなど単一リソース上の処理 | リソース削除時にIDも削除される |
| ユーザー割り当てマネージドID | 複数リソースで同じIDを使う処理 | IDの権限範囲が広がりすぎないよう管理が必要 |
運用上は、「まずマネージドIDが使えるか」を確認し、Azure外や複雑なデプロイ要件がある場合にサービスプリンシパルを選ぶと整理しやすくなります。
PATからMicrosoft Entra IDへ移行する実務パターン
PAT移行で失敗しやすいのは、すべてのPATを一括で禁止してしまうことです。突然の制限は、Git操作、パッケージ復元、ビルド、外部連携、REST API呼び出しを止める可能性があります。
現実的には、PATの用途ごとに代替手段を選びます。Microsoft公式ドキュメントでも、Git Credential Manager、ビルド・リリースパイプライン、Azure DevOps REST API への一時的なアクセスについて、Microsoft Entra IDベースの代替手段が示されています。(Microsoft Learn)
| 現在のPAT利用シーン | 置き換え候補 | 最初にやること |
|---|---|---|
| Git Credential ManagerでのGit認証 | GCMのOAuth設定 | credential.azreposCredentialType を oauth に変更する |
| Azure Pipelinesから別organizationのリポジトリやArtifactsへアクセス | Azure DevOps service connection + workload identity federation | サービスプリンシパルまたはマネージドIDを対象organizationに追加する |
| REST APIの単発実行 | Azure CLIでMicrosoft Entraトークンを取得 | az account get-access-token で短寿命トークンを使う |
| サービス間連携 | サービスプリンシパルまたはマネージドID | Azure DevOps側にIDを追加し、必要最小限の権限を付与する |
| 既存のAzure DevOps OAuthアプリ | Microsoft Entra ID OAuthへ移行 | トークン互換性とユーザー再承認を前提に移行計画を作る |
Git認証はGit Credential Managerの設定を見直す
Git Credential Manager（GCM）は、Azure Repos Gitリポジトリへの認証を簡単にするツールです。公式ドキュメントでは、Microsoft Entra IDトークンが推奨されており、GCMの既定のGit認証をOAuthに変更する設定例が示されています。(Microsoft Learn)
git config --global credential.azreposCredentialType oauth開発者のローカル環境で古い資格情報がキャッシュされていると、設定変更後も期待どおりに認証方式が切り替わらないことがあります。移行時は、対象OSごとの資格情報マネージャー、Gitクライアント、IDE連携をまとめて確認してください。
パイプラインはworkload identity federationを優先する
Azure PipelinesでPATを使っている場合は、Azure DevOps service connection と workload identity federation の利用を検討します。Microsoft公式ドキュメントでは、パイプラインがPATなしでAzure DevOpsに認証でき、シークレット管理やローテーションを不要にする方法として説明されています。(Microsoft Learn)
この方式は、別organizationのリポジトリをチェックアウトする、Azure Artifactsのフィードへアクセスする、REST APIをスクリプトから呼び出す、Visual Studio Marketplaceへ拡張機能を公開するといったシナリオに対応します。(Microsoft Learn)
パイプラインの認証を移行するときは、次の順番で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | サービスプリンシパルまたはマネージドIDを用意する | 対象organizationと同じMicrosoft Entraテナントか |
| 2 | Azure DevOps organizationにIDを追加する | 必要なaccess levelとプロジェクト権限があるか |
| 3 | Service connectionを作成する | 接続名、対象organization、利用範囲が明確か |
| 4 | パイプラインYAMLを変更する | 既存PAT参照が残っていないか |
| 5 | 監査ログと実行結果を確認する | 認証失敗、権限不足、過剰権限がないか |
REST APIの一時実行はAzure CLIのEntraトークンを使う
一時的にAzure DevOps REST APIを呼び出すだけなら、長寿命のPATを作るより、Azure CLIでMicrosoft Entraトークンを発行するほうが安全です。公式ドキュメントでは、Azure DevOpsのリソースID 499b84ac-1321-427f-aa17-267ca6975798 を使ってアクセストークンを取得する手順が示されています。(Microsoft Learn)
az login
az account set -s <subscription-id>
az account get-access-token \
--resource 499b84ac-1321-427f-aa17-267ca6975798 \
--query "accessToken" \
-o tsv取得したトークンは、AuthorizationヘッダーにBearerトークンとして渡します。検証用スクリプトでPATを作成して放置する運用は避け、短時間で失効するトークンを使うルールに変えると、監査や棚卸しが楽になります。(Microsoft Learn)
実装で見落としやすい注意点
Microsoft Entra ID認証への移行は、単にトークン取得コードを書き換えるだけでは完了しません。ID、権限、テナント、監査、例外運用まで見直す必要があります。
Azure DevOpsの権限はMicrosoft Entraのアプリ権限だけでは決まらない
よくある誤解は、「Microsoft Entra IDでアプリ登録すればAzure DevOpsの権限も自動で付く」と考えることです。公式ドキュメントでは、Azure DevOpsはMicrosoft Entra IDのアプリケーション権限ではなく、Azure DevOps独自の権限モデルでアクセス制御することが説明されています。(Microsoft Learn)
つまり、サービスプリンシパルやマネージドIDを作成した後、Azure DevOps側でユーザーとして追加し、プロジェクト、リポジトリ、パイプライン、Artifactsなど必要な範囲に権限を割り当てる必要があります。
アプリケーションのObject IDとサービスプリンシパルのObject IDを混同しない
サービスプリンシパルをAzure DevOpsに追加する際、アプリ登録のObject IDではなく、Enterprise applications側にあるサービスプリンシパルのObject IDを使う必要があります。公式ドキュメントでも、この点は重要事項として注意されています。(Microsoft Learn)
このミスは移行作業でよく起きます。ID管理チームとDevOpsチームが別組織の場合、チケットには「アプリ登録名」だけでなく、テナントID、クライアントID、サービスプリンシパルのObject ID、対象Azure DevOps organization、対象プロジェクトを明記して依頼すると手戻りを減らせます。
Microsoft Entra IDトークンとAzure DevOpsトークンは互換ではない
既存のAzure DevOps OAuthアプリからMicrosoft Entra ID OAuthへ移行する場合、トークンをそのまま差し替えることはできません。公式ドキュメントでは、Microsoft Entra IDトークンとAzure DevOpsトークンは相互に置き換えられず、移行時にはユーザーの再承認が必要になると説明されています。(Microsoft Learn)
特にSaaS連携や社内ポータルで多数のユーザーが利用している場合、再承認のタイミング、ユーザー通知、ロールバック手順、旧トークンの失効タイミングを事前に設計してください。
トークンの中身を読んでロジックを組まない
認証トークンをデコードし、クレーム値を取り出してユーザー判定や組織判定に使う実装は避けるべきです。Microsoftの認証ガイダンスでは、トークンは不透明なものとして扱い、必要なユーザー情報や組織情報はサポートされたREST APIから取得するよう説明されています。また、Azure DevOpsは2025年夏以降、認証トークンの暗号化を進めており、トークンペイロードを読むクライアントは破損する可能性があるとされています。(Microsoft Learn)
判断ロジックが必要な場合は、トークンから値を読むのではなく、Azure DevOps REST APIやMicrosoft Graphなど、安定したAPI契約に基づく実装へ置き換えましょう。
Microsoftアカウント利用者がいる場合は移行計画を分ける
Microsoft Entra OAuthアプリは、Azure DevOpsリソースに対してMicrosoftアカウント（MSA）ユーザーをネイティブにサポートしていないと公式ドキュメントで説明されています。MSAユーザーを含むアプリや、Microsoft EntraユーザーとMSAユーザーの両方を対象にするアプリでは、Azure DevOps OAuthアプリが引き続き選択肢になる場合があります。(Microsoft Learn)
企業利用ではMicrosoft Entra ID中心に整理しやすい一方、外部コントリビューター、個人アカウント、旧来の連携アプリが混在する環境では、ユーザー種別ごとに認証方式を分けて設計する必要があります。
セキュリティ管理者が取るべきPAT統制
Microsoft Entra ID認証へ移行する間も、PATが完全になくなるとは限りません。だからこそ、移行と並行してPATの作成・スコープ・有効期限を制御する必要があります。
Azure DevOpsには、PATを管理するためのテナントポリシーやorganizationポリシーがあります。公式ドキュメントでは、グローバルPATの作成制限、フルスコープPATの作成制限、新規PATの最大有効期間、PAT作成そのものの制限、漏えいPATの自動失効などが説明されています。(Microsoft Learn)
| 統制項目 | 目的 | 実務での使い方 |
|---|---|---|
| グローバルPATの作成制限 | 複数organizationにまたがる広いトークンを抑制 | 原則としてorganization単位のPATに限定する |
| フルスコープPATの作成制限 | 過剰権限のトークンを防ぐ | 必要なスコープだけを選ばせる |
| PAT最大有効期間 | 長期間放置されるトークンを減らす | 移行期間中は短めの期限を設定する |
| PAT作成制限 | PATを作れるユーザーを限定する | 例外承認されたグループだけを許可する |
| 漏えいPATの自動失効 | 公開リポジトリなどへの流出リスクを下げる | アラート対応手順とセットで運用する |
既存PATは、ポリシーを有効化しても残りの有効期間中は有効な場合があります。したがって、「ポリシーをオンにしたから安全」と考えるのではなく、既存PATの棚卸し、期限短縮、再発行ルール、例外承認を同時に進める必要があります。(Microsoft Learn)
また、allowlistには個人ユーザーではなくグループを使うことが推奨されています。例外ユーザーを個別に登録すると、運用が属人化し、異動・退職・監査時の確認が難しくなります。(Microsoft Learn)
コンプライアンス担当者が確認すべき監査観点
コンプライアンスの観点では、Microsoft Entra ID認証への移行は「技術的な改善」だけでなく、「説明可能性の改善」と捉えると分かりやすくなります。
監査で問われやすいのは、次のような点です。
| 監査観点 | 確認すべき内容 |
|---|---|
| アクセス主体 | 人のユーザーか、アプリケーションIDか、マネージドIDか |
| 権限範囲 | organization、project、repo、feed単位で必要最小限か |
| 認証方式 | PAT、Microsoft Entra OAuth、サービスプリンシパル、マネージドIDのどれか |
| トークン寿命 | 長期間有効なPATが残っていないか |
| 例外管理 | PAT利用が必要な理由、承認者、期限が記録されているか |
| ログ | 認証・アクセス・パイプライン実行の証跡が追えるか |
| 退職・異動対応 | 個人PATや個人アカウント依存が残っていないか |
特に、個人PATをパイプラインや共有スクリプトに使っている環境では、退職や異動のたびに障害リスクが発生します。サービスプリンシパルやマネージドIDへ移行すると、個人ユーザーから切り離したうえで、権限付与・削除・レビューを組織運用として扱いやすくなります。
実務での移行ロードマップ
Azure DevOps の Microsoft Entra ID 認証へ移行する場合、次の順番で進めるとリスクを抑えられます。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | PAT、OAuthアプリ、サービスアカウント、パイプライン変数を棚卸しする | 認証方式一覧、PAT一覧、影響システム一覧 |
| 分類 | 人が操作する処理とシステムが操作する処理に分ける | 認証方式の移行方針 |
| 代替設計 | OAuth、サービスプリンシパル、マネージドID、service connectionを選ぶ | 移行設計書、権限設計 |
| 小規模検証 | 代表的なGit操作、REST API、パイプラインで検証する | 検証結果、エラー対応手順 |
| 段階移行 | 重要度の低い処理から置き換える | 変更履歴、ロールバック手順 |
| PAT制限 | 新規PAT、フルスコープPAT、長期PATを制限する | PATポリシー、例外承認フロー |
| 定着化 | 定期レビュー、監査ログ確認、教育を行う | 運用手順、監査証跡 |
最初の1週間でやるべきことは、コード変更ではなく棚卸しです。Azure DevOps organizationごとに、PATを使っているユーザー、スコープ、有効期限、用途、保存場所を洗い出してください。そのうえで、Git操作、パイプライン、REST API、外部連携、個人スクリプトに分類すると、置き換える順番が見えてきます。
失敗しやすい移行パターン
Azure DevOpsの認証移行でよくある失敗は、技術よりも運用設計の不足から起きます。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| PATを一括禁止する | ビルド、Git操作、Artifacts復元が止まる | 用途別に代替手段を用意してから制限する |
| 個人PATをサービス用途で使い続ける | 退職・異動で処理が停止する | サービスプリンシパルまたはマネージドIDへ移行する |
| フルスコープPATを許可し続ける | 漏えい時の影響範囲が広くなる | スコープ制限と最大有効期間を設定する |
| Microsoft Entraのアプリ権限だけを設定する | Azure DevOps側で権限不足になる | Azure DevOpsの権限モデルでプロジェクト権限を付与する |
| トークンのクレームを読んで実装する | 仕様変更や暗号化でアプリが壊れる | REST APIから必要な情報を取得する |
| 例外ユーザーを個別管理する | 監査・異動対応が煩雑になる | allowlistはグループ単位で管理する |
特に注意したいのは、移行を「開発チームの作業」として閉じないことです。Microsoft Entra ID、Azure DevOps、条件付きアクセス、監査ログ、パイプライン権限が関わるため、セキュリティ管理者、ID管理チーム、DevOpsチーム、コンプライアンス担当者が同じ移行リストを見る必要があります。
次に取るべきアクション
Azure DevOps の Microsoft Entra ID 認証に関する2026年4月更新は、PATを使った従来運用を見直す明確なサインです。新規開発ではMicrosoft Entra ID OAuth、サービス間連携ではサービスプリンシパルまたはマネージドID、パイプラインではworkload identity federationを優先し、PATは例外的・短期間・最小スコープで扱う方針に切り替えましょう。
最初に行うべきことは、PATの棚卸しと用途分類です。その後、Git Credential Manager、Azure Pipelines、REST API、外部連携の順に、Microsoft Entra IDベースの代替手段へ移行します。並行して、PAT作成制限、フルスコープ制限、最大有効期間、allowlist運用を整備すれば、認証リスクを下げながら移行を進められます。
セキュリティ管理者はポリシーを、ID管理チームはIDと権限を、コンプライアンス担当者は例外承認と監査証跡を確認してください。Azure DevOpsの認証は、便利さだけで選ぶ段階から、組織として説明できる認証設計へ移行する段階に入っています。
コメント