Microsoft Entraの「Use Service Principals and Managed Identities – Azure DevOps」でまず押さえるべき結論は、Azure DevOpsの自動化認証を個人アカウントやPATに依存させず、サービスプリンシパルまたはマネージドIDで管理する考え方がより明確になったことです。特に重要なのは、サービスプリンシパルをMicrosoft Entraグループに追加しただけではAzure DevOps組織へアクセスできず、Project Collection Administratorまたは条件を満たすProject Administratorが、Azure DevOps側へ明示的に追加して必要な権限を付与する必要がある点です。公式ページの更新日は2026年5月15日で、GitHub上の履歴でも同日に権限要件と最小権限の記述が更新されています。(Microsoft Learn)
この記事では、2026年5月16日時点で確認すべき変更点、影響を受ける管理者・開発者、設定時に失敗しやすいポイント、PATから移行する際の実務的な手順を整理します。
Microsoft Entraの「Use Service Principals and Managed Identities – Azure DevOps」は何が変わるのか
今回の更新は、「新機能が突然追加された」というより、Azure DevOpsでサービスプリンシパルやマネージドIDを使う際のアクセス管理ルールが、より実務向けに明文化された更新と見るべきです。
公式ドキュメントでは、サービスプリンシパルとマネージドIDを、Azure DevOpsの自動化ワークフロー向けの安全でスケーラブルな認証方式として説明しています。Microsoft Entraトークンは短命で、マネージドIDでは資格情報のローテーションをAzure側が管理できるため、長期間有効なPATをコードや設定ファイルに置く運用よりもリスクを下げやすい構成です。(Microsoft Learn)
実務上の変更点は、次のように整理できます。
| 確認ポイント | 2026年5月更新で特に強調された内容 | 実務上の影響 |
|---|---|---|
| Azure DevOpsへの追加 | サービスプリンシパルはAzure DevOpsに自動表示されない | Microsoft Entraで作成しただけでは使えない |
| Entraグループ連携 | Entraグループへ追加しただけではAzure DevOps組織アクセスにならない | Azure DevOps側で明示的な追加が必要 |
| 追加できる管理者 | Project Collection Administrator、または招待ポリシーが許可するProject Administrator／Team Administrator | 誰が追加作業を行うか事前に決める必要がある |
| 権限設計 | 必要なプロジェクト、チーム、セキュリティグループに限定する | 広すぎるPCA付与を避ける |
| ライセンス | 各IDにアクセスレベルの割り当てが必要 | コストと権限をセットで確認する |
特に注意したいのは、「Microsoft Entraでアプリ登録したからAzure DevOpsにも認識される」と誤解しやすい点です。Azure DevOpsには独自の権限モデルがあり、Microsoft Entraのアプリケーション権限だけでAzure DevOps内のRepos、Boards、Pipelines、Artifactsなどのアクセス権が決まるわけではありません。(Microsoft Learn)
対象となる管理者・開発者
この更新の影響を受けるのは、Azure DevOpsを手作業で使う一般ユーザーよりも、Azure DevOpsをAPI、CI/CD、バックグラウンド処理、外部システム連携で利用しているチームです。
| 対象者 | 確認すべきこと |
|---|---|
| Azure DevOps組織管理者 | サービスプリンシパルやマネージドIDを誰が追加できるか、アクセスレベルをどう付与するか |
| Microsoft Entra管理者 | アプリ登録、サービスプリンシパル、マネージドID、証明書・シークレットの管理方針 |
| DevOpsエンジニア | PATを使っているビルド、リリース、スクリプト、外部連携の棚卸し |
| アプリ開発者 | REST API呼び出し時のトークン取得方法、Bearerトークンの扱い |
| セキュリティ担当者 | 最小権限、監査、条件付きアクセス、長期シークレットの削減 |
たとえば、Azure FunctionsからAzure DevOps REST APIを呼び出してプロジェクト情報を取得する処理、外部のバッチサーバーからWork Itemsを登録する処理、NuGetフィードへ発行する自動化などは、サービスプリンシパルやマネージドIDの利用候補になります。公式ドキュメントでも、NuGetフィード、Marketplace公開、Azure Pipelines、Git操作などの連携シナリオが例示されています。(Microsoft Learn)
サービスプリンシパルとマネージドIDの選び方
サービスプリンシパルとマネージドIDはどちらもMicrosoft EntraのIDを使う仕組みですが、向いている場面が異なります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| サービスプリンシパル | Azure外のアプリ、外部CI/CD、複数環境をまたぐ自動化、クロステナントに近い構成 | 証明書またはクライアントシークレットの管理が必要 |
| システム割り当てマネージドID | 単一のAzure Functions、App Service、VMなどからAzure DevOpsへアクセスする場合 | Azureリソースを削除するとIDも削除される |
| ユーザー割り当てマネージドID | 複数のAzureリソースで同じIDを共有したい場合 | ライフサイクルを個別に管理する必要がある |
判断基準はシンプルです。Azure上で動く単一リソースなら、まずシステム割り当てマネージドIDを検討します。複数リソースで同じIDを使いたいならユーザー割り当てマネージドIDが候補です。Azure外で動くアプリや、証明書ベースで明示的に資格情報を管理したいCI/CDならサービスプリンシパルを選びます。公式ドキュメントでも、サービスプリンシパルはCI/CDやAzure外のアプリ、マネージドIDはAzureホストのアプリに適していると説明されています。(Microsoft Learn)
設定の全体像
Azure DevOpsでサービスプリンシパルまたはマネージドIDを使う流れは、次の5段階で考えると整理しやすくなります。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| IDを作成する | Microsoft Entraでアプリ登録、またはAzureリソースでマネージドIDを有効化する | アプリケーションIDとサービスプリンシパルのオブジェクトIDを混同する |
| Azure DevOpsへ追加する | Organization settings > UsersからIDを追加する | Entraグループに入れただけで完了したと思い込む |
| アクセスレベルを付与する | Basicなど、用途に応じたアクセスレベルを割り当てる | StakeholderではRepos操作などができない場合がある |
| 権限を設定する | プロジェクト、リポジトリ、フィード、チームなどに必要最小限の権限を付与する | Project Collection Administratorsに安易に入れる |
| トークンを取得して利用する | Microsoft Entraトークンを取得し、Azure DevOps REST APIへBearerトークンとして渡す | トークンを解析したり、長期保存したりする |
サービスプリンシパルをAzure DevOpsに追加する際は、アプリ登録画面のオブジェクトIDではなく、Microsoft Entra管理センターの「Enterprise applications」側で確認できるサービスプリンシパルのオブジェクトIDを使う必要があります。これはAzure DevOps連携で非常に起きやすいミスです。(Microsoft Learn)
管理者が確認すべき設定
Azure DevOps組織が接続しているテナントを確認する
サービスプリンシパルやマネージドIDは、Azure DevOps組織が接続している同一テナントから追加するのが基本です。公式ドキュメントでは、接続済みテナントのIDのみ直接追加できると説明されています。クロステナント構成では回避策が示されていますが、証明書、Key Vault、アプリ登録をまたぐ構成になるため、標準運用として扱うには設計レビューが必要です。(Microsoft Learn)
招待ポリシーと追加権限を確認する
サービスプリンシパルやマネージドIDをAzure DevOpsへ追加するには、Project Collection Administratorsグループのメンバー、または招待ポリシーが許可しているProject Administrator／Team Administratorが必要です。組織によっては、プロジェクト管理者がユーザー追加をできないよう制限している場合があります。(Microsoft Learn)
運用では、次のように役割分担すると事故を減らせます。
| 担当 | 役割 |
|---|---|
| Entra管理者 | ID作成、証明書・シークレット管理、条件付きアクセスの確認 |
| Azure DevOps組織管理者 | 組織へのID追加、アクセスレベル付与、請求影響の確認 |
| プロジェクト管理者 | プロジェクト、Repos、Artifacts、Pipelinesなどの権限設定 |
| 開発者 | トークン取得、API実装、PAT削除後の動作確認 |
ライセンスと課金を見落とさない
サービスプリンシパルとマネージドIDは、Azure DevOps組織に参加する各IDごとにアクセスレベルが必要です。公式ドキュメントでは、サービスプリンシパルにマルチ組織課金が適用されないこと、グループベースのライセンスルールが自動適用されないこと、アクセスレベルを直接割り当てる必要があることが説明されています。(Microsoft Learn)
つまり、「人間のユーザーではないから無料で無制限に使える」とは考えない方が安全です。自動化ごとにIDを増やす場合は、権限管理だけでなくコスト管理の対象にも含めます。
開発者が確認すべき実装ポイント
PATではなくMicrosoft Entraトークンを使う
Azure DevOpsの認証ガイダンスでは、新しいアプリケーションではMicrosoft Entra ID認証を使用し、PATはMicrosoft Entra IDが使えない場合に限定して控えめに使う方針が示されています。特にサービスやバックグラウンドアプリでは、サービスプリンシパルやマネージドIDが推奨されます。(Microsoft Learn)
サービスプリンシパルでトークンを取得する場合、公式ドキュメントではクライアント資格情報フローや証明書認証の例が示されています。マネージドIDでは、Azure.IdentityのManagedIdentityCredentialを使ってAzure DevOps向けのトークンを取得する例があります。(Microsoft Learn)
az login --service-principal \
--username <client-id> \
--password <client-secret-or-cert> \
--tenant <tenant-id>
az account get-access-token \
--scope https://app.vssps.visualstudio.com/.default実装時は、トークンを設定ファイルやログに出力しないでください。アクセストークンはAPI呼び出し時にAuthorizationヘッダーへ渡すだけにし、アプリ側で中身を解析してユーザー情報や権限判定に使う設計は避けるべきです。Azure DevOpsの認証ガイダンスでも、トークンのクレームは安定したデータインターフェイスではなく、トークンを不透明な値として扱うべきだと説明されています。(Microsoft Learn)
Azure DevOpsの権限はAzure DevOps側で設定する
よくある誤解は、「Microsoft Entraのアプリケーション権限を付ければAzure DevOpsのReposやBoardsにアクセスできる」というものです。Azure DevOpsは独自の権限モデルを使うため、Repos、Pipelines、Artifacts、BoardsなどのアクセスはAzure DevOps側で設定します。(Microsoft Learn)
実務では、用途別にAzure DevOpsグループを作ると管理しやすくなります。
| 用途 | グループ例 | 付与する権限の考え方 |
|---|---|---|
| リポジトリ読み取り | ado-sp-repos-read | 対象リポジトリのReadのみ |
| NuGetフィード発行 | ado-sp-feed-publish | 対象Artifactsフィードへの発行権限 |
| Work Items登録 | ado-sp-workitems-write | 対象プロジェクトのWork Items更新権限 |
| 管理自動化 | ado-sp-admin-limited | 必要な管理操作だけに限定 |
最初からProject Collection Administratorsへ入れると設定は簡単ですが、漏えい時の影響範囲が大きくなります。検証時でも、本番相当の最小権限グループを使って動作確認する方が移行後の手戻りを減らせます。
PATから移行する手順
PAT移行は、単に認証コードを書き換える作業ではありません。棚卸し、権限設計、ライセンス、テスト、削除までを1つの変更管理として扱う必要があります。
| ステップ | 実施内容 |
|---|---|
| PAT利用箇所を棚卸しする | Azure DevOps REST API、Git操作、NuGet、スクリプト、外部サービス連携を確認する |
| 用途を分類する | 人間の代理操作か、サービス単独の処理かを分ける |
| ID方式を選ぶ | Azure上の処理はマネージドID、Azure外やクロス環境はサービスプリンシパルを検討する |
| Azure DevOpsへ追加する | Organization settings > UsersでIDを追加し、アクセスレベルを割り当てる |
| 権限を最小化する | プロジェクト、リポジトリ、フィード単位で必要権限だけ付与する |
| 実装を変更する | PAT文字列ではなくMicrosoft Entraトークンを取得してBearer認証する |
| 並行稼働で検証する | 非本番プロジェクトでAPI、Git、Artifactsなどを確認する |
| PATを削除する | 移行完了後、不要になったPATと保存済みシークレットを削除する |
| 監査する | 使われていないID、過剰権限、期限切れ証明書を定期確認する |
公式ドキュメントでは、Microsoft EntraトークンはPATより短い寿命であり、マネージドIDでは資格情報ローテーションを自動化できる点が利点として挙げられています。一方で、サービスプリンシパルでクライアントシークレットを使う場合は、シークレットの期限切れや漏えい対策を自組織で管理する必要があります。(Microsoft Learn)
よくあるエラーと対処法
Azure DevOpsでサービスプリンシパルやマネージドIDを使う場合、エラーの原因は認証トークンそのものより、Azure DevOps側の追加漏れ、ライセンス不足、権限不足であることが多いです。
| エラー・症状 | 主な原因 | 対処法 |
|---|---|---|
| Gitリポジトリが存在しない、または権限がないと表示される | BasicライセンスやRepos権限が不足している | アクセスレベルと対象リポジトリ権限を確認する |
| サービスプリンシパル作成に失敗する | アプリ登録のオブジェクトIDを使っている | Enterprise applications側のサービスプリンシパルのオブジェクトIDを使う |
| ユーザー追加権限がない | PCAではない、または招待ポリシーで制限されている | Project Collection Administratorに依頼する |
| Graph APIの一覧が空に見える | ページングを処理していない | continuationTokenを使って全ページ取得する |
| TF401444やサインイン要求が出る | IDがAzure DevOps組織に正しく追加されていない | Organization settings > Usersと権限を確認する |
これらのエラーは、公式ドキュメントの「Common errors and solutions」でも整理されています。特にBasicライセンス不足とオブジェクトIDの取り違えは、移行初期に起きやすい問題です。(Microsoft Learn)
展開時の注意点
いきなり本番のPATを置き換えない
PATからサービスプリンシパルやマネージドIDへ移行する場合、まず非本番プロジェクトで同じAPI操作を再現します。特にRepos、Artifacts、Pipelinesは必要権限が異なるため、「プロジェクト一覧は取れるがリポジトリは読めない」といった状態が起こります。
ID名と用途を分かるようにする
サービスプリンシパルやマネージドIDはメールアドレスで招待されるユーザーではありません。表示名はMicrosoft Entra IDから継承されます。運用では、sp-ado-feed-prod、mi-func-ado-workitems-devのように、用途、環境、対象サービスが分かる名前にしておくと監査が楽になります。(Microsoft Learn)
証明書認証を優先して検討する
サービスプリンシパルではクライアントシークレットも使えますが、長期的な本番運用では証明書認証を優先して検討する方が安全です。公式ドキュメントでも、サービスプリンシパルの資格情報として証明書が推奨され、クライアントシークレットは定期的なローテーションが必要な代替手段として示されています。(Microsoft Learn)
Azure DevOps Serverと混同しない
Microsoft Entra ID認証やOAuth 2.0は、Azure DevOps Services向けの前提で説明されています。オンプレミスのAzure DevOps Serverでは、.NETクライアントライブラリ、Windows認証、PATなど別の認証方式を検討します。(Microsoft Learn)
まず確認すべきチェックリスト
導入前に、次の項目を確認してください。
| チェック項目 | 確認結果 |
|---|---|
| 対象はAzure DevOps Servicesか | Azure DevOps Serverでは同じ前提で扱わない |
| Azure DevOps組織の接続テナントを確認したか | 別テナントIDを直接追加しようとしていないか |
| サービスプリンシパルの正しいオブジェクトIDを取得したか | App registrationsではなくEnterprise applications側を確認 |
| IDをAzure DevOps組織へ明示的に追加したか | Entraグループ追加だけで終えていないか |
| アクセスレベルを直接割り当てたか | Basicなど必要なレベルを確認 |
| Azure DevOps側の権限を最小化したか | PCA付与を常用していないか |
| PAT保存場所を棚卸ししたか | Key Vault、環境変数、CI/CD変数、設定ファイルを確認 |
| トークンをログ出力していないか | Bearerトークンを保存・解析しない |
| 証明書やシークレットの期限管理を決めたか | 更新担当と期限アラートを設定 |
| 移行後にPATを削除する手順を決めたか | 並行稼働後に残骸を消す |
まとめ：Azure DevOps自動化は「ID作成」ではなく「Azure DevOps側の権限設計」まで確認する
「Use Service Principals and Managed Identities – Azure DevOps」の更新で最も重要なのは、Microsoft EntraでIDを作成するだけではAzure DevOpsのアクセス権は完成しない、という点です。サービスプリンシパルやマネージドIDは、Azure DevOps組織へ明示的に追加し、アクセスレベルを割り当て、Azure DevOps側の権限モデルに沿って最小権限を設定して初めて利用できます。
管理者は、誰がIDを追加できるか、どのアクセスレベルを付与するか、どのプロジェクトやリポジトリに限定するかを確認してください。開発者は、PATを置き換えるだけでなく、Microsoft Entraトークンの取得、Bearer認証、トークンを不透明な値として扱う実装に切り替える必要があります。
次に取るべき行動は、既存のPAT利用箇所を棚卸しし、Azure上で動く処理はマネージドID、Azure外や複数環境をまたぐ処理はサービスプリンシパルとして分類することです。そのうえで、非本番のAzure DevOpsプロジェクトにIDを追加し、最小権限でAPIやGit操作が通るか検証してから、本番移行を進めましょう。
コメント