Azure DevOpsの認証方法で最初に押さえるべき結論は、新規のAzure DevOps連携ではMicrosoft Entra IDを基本にし、Personal Access Token（PAT）は使える場面を絞るという方針です。Microsoft公式ガイダンスでも、Azure DevOps Servicesと統合する新しいアプリケーションにはMicrosoft Entra ID認証を使い、PATはMicrosoft Entra IDが利用できない場合に限定して控えめに使うことが推奨されています。(Microsoft Learn)
今回のポイントは、単に「認証方式の一覧を知る」ことではありません。管理者はPAT依存の棚卸し、サービスプリンシパルやマネージドIDの権限設計、Azure Pipelinesのサービス接続を確認する必要があります。開発者は、アプリの種類に応じてMicrosoft Entra OAuth、サービスプリンシパル、マネージドID、デバイスコードフローなどを選び、トークンを解析しない実装へ見直すことが重要です。
Azure DevOpsの認証方法で何が変わるのか
今回の公式情報で重要なのは、Azure DevOpsの認証が「PATを便利に発行して使う」方向から、Microsoft Entra IDを中心にした認証設計へ寄せられている点です。
Microsoft Learnの「Authentication methods for Azure DevOps」では、Webアプリ、バックグラウンドサービス、CLI、Azure Pipelines、Azure DevOps Serverなど、シナリオ別に推奨される認証方式が整理されています。Web/デスクトップアプリにはMicrosoft Entra OAuth、サービスやバックグラウンドアプリにはサービスプリンシパルまたはマネージドID、個人用の一時的なスクリプトにはPATが示されています。(Microsoft Learn)
また、関連するMicrosoft Entra OAuthの公式実装ページは2026年5月8日に更新されており、Azure DevOpsリソース識別子、.defaultスコープ、Microsoft Entra OAuthへ移行する際のID解決など、開発者が実装でつまずきやすい点が明記されています。(Microsoft Learn)
変更点の要点
| 観点 | これまで起こりがちだった運用 | 今後の推奨方針 |
|---|---|---|
| 新規アプリ連携 | PATを発行してAPI呼び出しに使う | Microsoft Entra OAuthを第一候補にする |
| バックグラウンド処理 | 個人ユーザーのPATをサービス用に流用する | サービスプリンシパルまたはマネージドIDを使う |
| Azure Pipelines | PATを変数やシークレットに保存する | Azure DevOpsサービス接続とEntraワークロードIDを使う |
| 個人スクリプト | 長期間有効なPATを使い回す | 必要最小限のスコープ・短い有効期限で限定利用する |
| トークン処理 | JWTの中身を読み取り、ユーザー情報や組織情報を取得する | トークンは不透明な値として扱い、必要情報はREST APIから取得する |
この変更は、すべてのPATが即座に使えなくなるという意味ではありません。むしろ、運用アプリケーションやCI/CD、長期利用する統合でPAT依存を減らし、Microsoft Entra IDベースの認証へ段階的に移行するための実務ガイダンスと捉えるべきです。
影響を受ける対象者
影響を受けるのは、Azure DevOps REST APIを直接呼び出している開発者だけではありません。Azure DevOpsを社内システム、CI/CD、外部SaaS、監視ツール、レポートツールなどと連携している組織全体が対象になります。
| 対象者 | 確認すべきこと |
|---|---|
| Azure DevOps管理者 | 組織内のPAT利用状況、PAT作成ポリシー、サービスプリンシパルやマネージドIDの追加権限 |
| セキュリティ担当者 | 長期トークンの保管場所、過剰スコープ、退職者や異動者に紐づくPATの有無 |
| アプリ開発者 | Microsoft Entra OAuth、MSAL、サービスプリンシパル、マネージドIDへの実装変更 |
| DevOpsエンジニア | Azure Pipelinesのサービス接続、成果物フィード、別組織リポジトリ参照、REST API呼び出し |
| Azure DevOps Server利用者 | Azure DevOps Servicesとの違い、Windows認証や.NETクライアントライブラリの継続利用 |
特に注意したいのは、個人アカウントで発行したPATをシステム連携に使っているケースです。たとえば、ある開発者のPATで夜間バッチがAzure DevOpsのWork Itemsを更新している場合、その開発者の権限変更、退職、PAT期限切れ、条件付きアクセスポリシーの変更によって処理が止まる可能性があります。
認証方式はシナリオで選ぶ
Azure DevOpsの認証方法は、「どれが一番強いか」ではなく「どの処理主体が、誰の権限で、どのリソースへアクセスするか」で選びます。
| 利用シーン | 推奨される認証方法 | 判断基準 |
|---|---|---|
| Reactアプリや.NETデスクトップアプリなど、ユーザーがサインインして操作するアプリ | Microsoft Entra OAuth | 人間のユーザーとしてAzure DevOpsにアクセスする |
| Azure Functions、バックグラウンドサービス、夜間バッチ | サービスプリンシパルまたはマネージドID | ユーザー操作なしで継続的に動く |
| Azure上で動く単一のApp ServiceやFunction | システム割り当てマネージドID | AzureリソースとIDのライフサイクルを一致させたい |
| 複数のAzureリソースで同じIDを共有する処理 | ユーザー割り当てマネージドID | 複数環境・複数リソースで同じIDを使いたい |
| Azure外のCI/CDや外部サービス | サービスプリンシパル | Azureリソース外からアプリIDとして認証したい |
| CLIやヘッドレス環境 | デバイス認証フロー、Azure CLIによるEntraトークン | ブラウザー操作が制限されるが、ユーザー認証が必要 |
| 個人用の一時的なPowerShellやcurl | PAT | Microsoft Entra IDが使えない、または短期・限定用途に限る |
| Azure DevOps Server | .NETクライアントライブラリ、Windows認証、PAT | Microsoft Entra ID OAuthはAzure DevOps Services向け |
Microsoftのガイダンスでは、OAuth 2.0とMicrosoft Entra ID認証はAzure DevOps Services向けであり、Azure DevOps Serverでは利用できないとされています。オンプレミス環境では、.NETクライアントライブラリ、Windows認証、またはPATを使う前提で設計する必要があります。(Microsoft Learn)
Microsoft Entra IDを推奨する理由
Microsoft Entra IDが推奨される理由は、単に「新しいから」ではありません。セキュリティ管理、監査、条件付きアクセス、MFA、トークンの有効期間といった企業運用に必要な要素を統合しやすいためです。
Microsoft Entra ID認証では、ユーザー委任のOAuthと、サービスプリンシパル・マネージドIDによるアプリケーションIDの2つのパターンが整理されています。ユーザー委任は人間のユーザーの代わりに操作するアプリ向け、アプリケーションIDはCI/CD、バックグラウンドサービス、自動化処理向けです。(Microsoft Learn)
PATとMicrosoft Entra IDの違い
| 比較項目 | Microsoft Entra ID | PAT |
|---|---|---|
| 主な用途 | アプリ連携、サービス間認証、ユーザー委任 | 個人用スクリプト、暫定対応、レガシー用途 |
| トークンの扱い | 短時間で更新される前提 | 長期間有効になりやすい |
| MFA・条件付きアクセス | 組織ポリシーを適用しやすい | 直接的な適用は限定的 |
| 監査・統制 | Entra IDとAzure DevOpsの管理に乗せやすい | 発行者個人に依存しやすい |
| 退職・異動時のリスク | アプリIDとして管理しやすい | 個人PATを流用していると停止リスクが高い |
| 推奨度 | 新規・本番利用の第一候補 | 代替手段がない場合の限定利用 |
PATはAzure DevOpsに認証するための代替パスワードのようなもので、発行したユーザーのアクセス権とスコープに基づいて動作します。Microsoftは、より安全な方法が使える場合はPATを避け、Microsoft Entraトークン、マネージドID、サービスプリンシパルを使うことを推奨しています。(Microsoft Learn)
管理者が確認すべき設定と運用ポイント
管理者がまず行うべきことは、Azure DevOps組織内でPATがどこに使われているかを棚卸しすることです。対象はユーザー設定画面で見えるPATだけではありません。Git Credential Manager、Azure Pipelinesの変数、外部SaaSの接続設定、社内バッチ、PowerShellスクリプト、Dockerイメージ内の環境変数なども確認対象です。
確認ポイント
| 確認項目 | 実務上の見方 |
|---|---|
| PATの所有者 | 退職者、異動者、共有アカウントに紐づいていないか |
| スコープ | Code Readだけで足りるのにRead & Writeを付けていないか |
| 有効期限 | 1年など長すぎる期限で発行されていないか |
| 保存場所 | リポジトリ、平文設定ファイル、CI/CDログに漏れていないか |
| 用途 | 本当にPATが必要か、Entra IDへ置き換えられるか |
| 代替方式 | ユーザー委任、サービスプリンシパル、マネージドID、サービス接続のどれが適切か |
サービスプリンシパルやマネージドIDをAzure DevOpsで使う場合は、Microsoft Entra IDに存在するだけでは不十分です。Azure DevOps組織へユーザーとして追加し、アクセスレベルやプロジェクト権限を割り当てる必要があります。(Microsoft Learn)
さらに、Azure DevOpsではMicrosoft Entra IDのアプリケーション権限だけでアクセス制御が完結するわけではありません。Azure DevOps側の権限モデルで、プロジェクト、リポジトリ、パイプライン、成果物フィードなどに対する権限を細かく設定する必要があります。(Microsoft Learn)
開発者が実装で注意すべきポイント
開発者にとって重要なのは、「PATをBearerトークンに置き換えれば終わり」ではない点です。認証方式が変わると、トークン取得、同意、権限、ID解決、更新処理、エラー時の再認証設計まで見直しが必要になります。
Microsoft Entra OAuthを使う場合
ユーザーがサインインするWebアプリやデスクトップアプリでは、Microsoft Entra OAuthとMSALの利用が基本になります。Azure DevOps向けのリソース識別子は 499b84ac-1321-427f-aa17-267ca6975798、リソースURIは https://app.vssps.visualstudio.com とされています。トークン要求では、アプリに許可されたスコープを使うために .default スコープを利用する点も押さえておきます。(Microsoft Learn)
ただし、Microsoft EntraアプリはAzure DevOpsリソースに対してMicrosoftアカウント（MSA）ユーザーをネイティブにはサポートしていないため、MSAユーザーやMicrosoft Entra IDとMSAの両方を対象にするアプリでは、Azure DevOps OAuthアプリが選択肢として残ります。(Microsoft Learn)
サービスプリンシパルとマネージドIDを使う場合
サービス間連携では、個人ユーザーのPATを使うのではなく、サービスプリンシパルまたはマネージドIDを使います。Microsoft公式ドキュメントでは、これらのIDは自動化ワークフローに適した安全でスケーラブルな認証方式として説明されており、短命トークン、自動資格情報管理、企業向けアクセス制御といった利点があります。(Microsoft Learn)
実装時に間違いやすいのは、Azureポータルの「アプリの登録」で見えるアプリケーションオブジェクトIDと、Enterprise applications側のサービスプリンシパルオブジェクトIDを混同することです。Azure DevOpsに追加する際は、サービスプリンシパルのオブジェクトIDを使う必要があります。(Microsoft Learn)
トークンの中身を読まない
既存アプリで特に危険なのが、アクセストークンのクレームをデコードしてユーザーID、組織ID、メールアドレスなどを取り出している実装です。
Microsoftのガイダンスでは、認証トークンは安定したデータインターフェイスではなく、Azure DevOpsはトークンのクレームを変更、削除、暗号化する可能性があると説明しています。2025年夏以降、Azure DevOpsは認証トークンの暗号化を進めており、トークンを解析するアプリは壊れる可能性があります。必要なユーザー情報や組織情報は、Azure DevOps REST APIから取得する実装に変更してください。(Microsoft Learn)
Azure Pipelinesではサービス接続を優先する
Azure PipelinesからAzure DevOpsへアクセスする場合は、PATをシークレット変数に保存するのではなく、Azure DevOpsサービス接続とMicrosoft EntraワークロードIDを使う方式が推奨されます。
公式ドキュメントでは、Azure DevOpsサービス接続により、PATなしでパイプラインからAzure DevOpsへ認証できると説明されています。サービスプリンシパルやマネージドIDはワークロードIDフェデレーションを通じてアクセスし、シークレットの管理やローテーションを不要にできます。(Microsoft Learn)
対応シナリオには、別のAzure DevOps組織にあるリポジトリのチェックアウト、Azure Artifactsフィードへのアクセス、インラインスクリプトからのREST API呼び出し、Visual Studio Marketplaceへの拡張機能公開が含まれます。(Microsoft Learn)
パイプライン移行時の確認事項
| 確認項目 | 注意点 |
|---|---|
| サービス接続の作成権限 | 対象プロジェクトでCreatorまたはAdministratorロールが必要 |
| IDの追加 | サービスプリンシパルまたはマネージドIDをAzure DevOps組織に追加する |
| クロス組織アクセス | 接続先の組織にも対象IDをユーザーとして追加する |
| 権限範囲 | パイプライン単位・リソース単位で最小権限にする |
| セルフホステッドエージェント | Azure CLIやAzure DevOps拡張機能の有無を確認する |
| 監査 | 認証試行やAPI呼び出しのログを確認できるようにする |
PATをパイプライン変数に入れている環境では、移行前に「どのジョブがどのAzure DevOpsリソースへアクセスしているか」を洗い出してください。単にPATを削除すると、別組織リポジトリのチェックアウト、NuGet復元、REST APIによるビルド定義更新などが失敗する可能性があります。
PATを使い続ける場合の現実的なルール
PATは今後使ってはいけないものではありません。個人用の短期スクリプト、Microsoft Entra IDを利用できないツール、Azure DevOps Serverの一部シナリオなどでは、PATが現実的な選択肢になる場合があります。
ただし、使う場合は次のルールを徹底してください。
| ルール | 理由 |
|---|---|
| 用途ごとにPATを分ける | 漏えい時の影響範囲を限定できる |
| 最小スコープだけ付与する | Code Readで足りる用途にWrite権限を与えない |
| 有効期限を短くする | 長期漏えいのリスクを下げる |
| 共有アカウントのPATを避ける | 所有者と責任範囲が不明確になる |
| 定期的にローテーションする | 使われなくなったPATを放置しない |
| リポジトリやログに出さない | シークレット漏えいの典型パターンを防ぐ |
| 代替方式を定期的に再評価する | 将来的にEntra IDへ移行できる可能性がある |
PATは発行したユーザーに紐づきます。ユーザーに十分な権限がない場合は処理が失敗し、逆に過剰な権限を持つユーザーのPATを使うと、漏えい時の影響が大きくなります。Microsoft公式FAQでも、特定ユーザーに紐づかないトークンが必要な場合は、サービスプリンシパルやマネージドIDで発行されるMicrosoft Entraトークンを使うよう案内されています。(Microsoft Learn)
移行の進め方
PATからMicrosoft Entra IDベースの認証へ移行する場合は、一気に置き換えるよりも、用途ごとに段階的に進めるのが安全です。
| 手順 | 作業内容 | 成功の判断基準 |
|---|---|---|
| 棚卸し | PAT、サービス接続、外部連携、スクリプトを洗い出す | 誰のPATがどの処理で使われているか分かる |
| 分類 | ユーザー操作、バックグラウンド処理、パイプライン、個人作業に分ける | 各用途の推奨認証方式を決められる |
| ID設計 | Entraアプリ、サービスプリンシパル、マネージドIDを作成する | 個人ユーザーに依存しないIDへ置き換えられる |
| 権限設計 | Azure DevOps側でアクセスレベル、グループ、リソース権限を設定する | 最小権限で必要なAPI・リソースにアクセスできる |
| 実装修正 | MSAL、Bearerトークン、サービス接続などに変更する | PATなしで同等の処理が通る |
| テスト | 開発・検証環境でビルド、API、成果物取得を確認する | 401/403、同意エラー、権限不足が解消されている |
| 切り替え | 本番に段階展開し、旧PATを失効させる | PAT削除後も処理が継続する |
| 監視 | 監査ログ、失敗ログ、期限切れ、過剰権限を確認する | 継続的に安全な運用ができる |
MicrosoftのFAQでも、PATからモダン認証へ移行する流れとして、現在のPAT利用の特定、代替認証方式の選択、認証コードの更新、PAT依存を削除する前の十分なテスト、移行後の監視と検証が示されています。(Microsoft Learn)
失敗しやすいポイント
Azure DevOpsの認証移行では、実装そのものよりも、権限やID管理の勘違いで失敗することがよくあります。
Microsoft Entra IDの権限だけでAzure DevOpsへアクセスできると思い込む
Azure DevOpsは独自の権限モデルを使います。Microsoft Entra IDでアプリを登録し、トークンを取得できても、Azure DevOps組織やプロジェクト側に追加されていなければ、APIアクセスは成功しません。
サービスプリンシパルのライセンスを見落とす
サービスプリンシパルやマネージドIDは、Azure DevOps組織に参加するIDとして扱われます。公式ドキュメントでは、各IDは参加する組織ごとにライセンスが必要で、グループベースのライセンス規則は自動適用されないと説明されています。(Microsoft Learn)
トークン互換性を前提にする
Microsoft Entra IDトークンとAzure DevOpsトークンは入れ替えて使えるものではありません。Azure DevOps OAuthからMicrosoft Entra ID OAuthへ移行するアプリでは、ユーザーの再承認が必要になる可能性があります。(Microsoft Learn)
Azure DevOps Serverにも同じ方式を適用しようとする
Azure DevOps Serverでは、Azure DevOps Services向けのMicrosoft Entra ID OAuthと同じ設計をそのまま適用できません。オンプレミス環境では、Windows認証、.NETクライアントライブラリ、PATの使い分けを前提にしてください。
まず何をすべきか
Azure DevOpsの認証方法を見直すなら、最初にやるべきことは明確です。本番システム、パイプライン、外部連携で使っているPATを棚卸しし、Microsoft Entra IDへ置き換えられるものから優先順位を付けることです。
優先度は次の順で考えると進めやすくなります。
- 本番アプリやCI/CDで使っている長期PAT
- 個人ユーザーに紐づくサービス用途のPAT
- 過剰スコープを持つPAT
- 有効期限が長いPAT
- 個人用の一時スクリプトで使っているPAT
新規開発では、最初からMicrosoft Entra OAuth、サービスプリンシパル、マネージドID、Azure DevOpsサービス接続を前提に設計してください。既存環境では、PATを禁止することから始めるのではなく、「どの処理主体にどの認証方式が適切か」を整理し、テスト済みの代替手段を用意してから段階的に切り替えるのが安全です。
Azure DevOpsの認証方法は、セキュリティ担当だけのテーマではありません。管理者、開発者、DevOpsエンジニアが同じ方針を共有し、PAT依存を減らしながら、Microsoft Entra IDを中心とした管理しやすい認証基盤へ移行していくことが重要です。
コメント