Azure DevOpsの権限とセキュリティグループでまず押さえるべき結論は、「アクセスレベル」と「アクセス許可」は別物という点です。Stakeholder、Basic、Basic + Test Plansなどのアクセスレベルは利用できるWebポータル機能の範囲を決め、セキュリティグループやロール、オブジェクト単位のアクセス許可は「具体的に何を操作できるか」を決めます。つまり、ユーザーが「リポジトリを見られない」「パイプラインを実行できない」「Boardsの一部操作ができない」といった問題は、ライセンス・グループ所属・継承・Deny設定を分けて確認する必要があります。(Microsoft Learn)
2026年5月時点で確認できる公式情報では、GitHub上のAzure DevOps Docs履歴に2026年5月8日の文言整理コミットがあり、該当ページでは説明文の表現やMicrosoft Entraグループ継承に関する表現が整理されています。一方、Microsoft Learn本文の最終更新表示は英語版で2026年2月20日、日本語版で2026年2月19日です。したがって、今回のポイントは「新しい権限機能が突然追加された」というより、既存のAzure DevOps権限設計を棚卸しし、管理者が誤設定を防ぐための公式整理として読むのが現実的です。(GitHub)
Azure DevOpsの権限管理で今回確認すべき変更点
今回の公式情報で実務上注目すべき点は、権限の考え方が「アクセスレベル」「セキュリティグループ」「継承」「ロールベース権限」に分解して説明されていることです。Azure DevOpsのアクセス制御は、単純な管理者・一般ユーザーの二択ではありません。組織、プロジェクト、オブジェクト、パイプラインやArtifactsなどのリソースごとに権限の効き方が変わります。(Microsoft Learn)
| 確認ポイント | 実務への影響 | 管理者が取るべき対応 |
|---|---|---|
| アクセスレベルとアクセス許可の違い | Basic権限があっても、機能やライセンス範囲外の操作はできない | ユーザー追加時に「ライセンス」と「所属グループ」を別々に確認する |
| Denyの優先順位 | 別グループでAllowされていても、Denyが原因で操作できない場合がある | 広範囲グループへのDeny設定を棚卸しする |
| 権限の継承 | 親ノード、グループ、オブジェクト単位の設定が重なり原因特定が難しい | 「Why?」や権限トレースで有効権限を確認する |
| Microsoft Entra ID連携 | Entraグループ変更後、Azure DevOps側の反映に時間差が出る | サインアウト・サインイン、または権限の再評価を案内する |
| Project-scoped Users | 組織情報の可視性を制限できるが、Webポータル中心の制御である | REST APIやCLI経由のアクセスも考慮して設計する |
特に注意したいのは、Denyを安易に使わないことです。公式情報では、ほとんどのグループとほとんどのアクセス許可でDenyがAllowより優先されると説明されています。あるユーザーが複数グループに属している場合、1つのグループでDenyが設定されているだけで、別グループのAllowが効かないことがあります。(Microsoft Learn)
影響範囲は管理者だけでなく開発者・CI/CD運用にも及ぶ
Azure DevOpsの権限更新や設定見直しの影響は、Project Collection AdministratorsやProject Administratorsだけに限られません。Azure Repos、Azure Pipelines、Azure Boards、Azure Artifacts、Azure Test Plansを使う開発者、QA担当者、外部委託メンバー、Microsoft Entraゲストユーザー、サービスアカウントにも関係します。
公式情報では、プロジェクトレベルの機能を管理するユーザーはProject Administrators、組織またはコレクションレベルの機能を管理するユーザーはProject Collection Administratorsに追加する考え方が示されています。Project Administratorsはチーム、エリア・イテレーションパス、リポジトリ、サービスフック、サービスエンドポイントなどを扱い、Project Collection Administratorsはプロジェクト、ポリシー、プロセス、保持ポリシー、エージェントやデプロイプール、拡張機能などを扱います。(GitHub)
| 対象者 | 起こりやすい影響 | 確認すべき設定 |
|---|---|---|
| 組織管理者 | 組織全体のユーザー、ポリシー、拡張機能、課金まわりに影響 | Project Collection Administratorsのメンバー、組織ポリシー、アクセスレベル |
| プロジェクト管理者 | プロジェクト内の開発・テスト・CI/CD運用に影響 | Project Administrators、Contributors、Readers、カスタムグループ |
| 開発者 | リポジトリ、Boards、Pipelines、Artifactsの操作可否に影響 | Basic以上のアクセスレベル、Contributors所属、個別リソース権限 |
| QA・テスト担当 | Azure Test Plansの利用可否に影響 | Basic + Test Plansなど、テスト管理に必要なアクセスレベル |
| 外部メンバー・ゲスト | 組織情報や他プロジェクトの見え方に影響 | Project-scoped Users、Microsoft Entra IDゲスト設定、明示的なプロジェクト追加 |
| サービスアカウント | ビルド、リリース、デプロイ、拡張機能連携に影響 | サービスアカウント用グループ、パイプライン関連ロール、既定アクセスレベル |
「管理者だからすべてのDenyを上書きできる」と考えるのも危険です。公式情報では、Project Collection Administratorsのメンバーでも、作業項目の削除やパイプライン管理などでは別の場所に設定されたDenyが上書きされない例が示されています。管理者権限を持つユーザーであっても、権限トラブル時はグループ所属とDeny設定を確認する必要があります。(Microsoft Learn)
アクセスレベルとアクセス許可を混同しない
Azure DevOpsでよくある失敗は、「Project Administratorsに入れたのに機能が使えない」「Basicを付けたのに操作できない」といった混同です。アクセスレベルはWebポータル機能への入口を制御し、アクセス許可はタスクやリソース操作を制御します。公式情報でも、アジャイルポートフォリオ管理やテストケース管理機能を使わせたい場合は、アクセス許可ではなくアクセスレベルを変更する必要があると説明されています。(Microsoft Learn)
アクセスレベルで見るべきこと
アクセスレベルは、ユーザーがAzure DevOpsのどの機能を使えるかを大きく左右します。代表的にはStakeholder、Basic、Basic + Test Plansがあります。Basic以上ではAzure Test Plansを除く多くのAzure DevOpsサービスを利用でき、StakeholderはAzure BoardsやAzure Pipelinesの一部機能に限定されます。(Microsoft Learn)
実務では、次のように判断すると無駄な権限付与を避けやすくなります。
| 利用者の役割 | 推奨される確認観点 |
|---|---|
| 要件確認や進捗確認が中心のビジネス部門 | Stakeholderで足りるかを確認する |
| コード、Boards、Pipelines、Artifactsを日常的に使う開発者 | Basic以上が必要か確認する |
| テストケース管理を行うQA担当 | Basic + Test Plansなど、Test Plans利用に必要なアクセスレベルを確認する |
| 組織やプロジェクトの管理者 | アクセスレベルだけでなく、管理者グループ所属も確認する |
アクセスレベル不足をセキュリティグループ変更で解決しようとすると、必要以上に強い権限を付ける原因になります。逆に、Basicを付与してもプロジェクトやリソース側で権限がなければ操作できません。トラブル対応では、まずアクセスレベル、次にセキュリティグループ、最後にオブジェクトやロールの権限を確認する順序が効率的です。
セキュリティグループは「個人」ではなく「役割」で設計する
Azure DevOpsでは、すべてのユーザーが1つ以上の既定セキュリティグループに属し、メンバーは所属グループに割り当てられたアクセス許可を継承します。公式情報では、組織・コレクション、プロジェクト、オブジェクトなど複数レベルでアクセス許可を定義でき、管理者は機能領域ごとにカスタムセキュリティグループを作成できると説明されています。(Microsoft Learn)
よく使われる既定グループは、Readers、Contributors、Project Administratorsです。多くのユーザーはContributorsに追加され、リポジトリ、作業追跡、パイプラインなどへの読み取り・書き込みアクセスを得ます。(Microsoft Learn)
グループ設計の実務例
| グループ設計 | 向いているケース | 注意点 |
|---|---|---|
| Readers | 閲覧中心の監査担当、関係者、レビュー担当 | 作業項目やコードの更新が必要な人には不足する |
| Contributors | 日常的に開発・作業管理を行うメンバー | 広すぎる場合はリポジトリやパイプライン側で追加制御する |
| Project Administrators | プロジェクト設定、チーム、パス、サービス接続を管理する人 | 開発リーダー全員に付けると権限過多になりやすい |
| カスタムグループ | 委託先、QA、運用チームなど職務別に制御したい場合 | グループ名と説明に用途を明記し、Denyを乱用しない |
| Microsoft Entraグループ連携 | 人事異動や入退社に合わせて一元管理したい場合 | 反映遅延や継承の確認手順を運用ルールに入れる |
個人単位でアクセス許可を積み上げると、退職・異動・プロジェクト終了時に棚卸しが難しくなります。基本はMicrosoft Entra IDやAzure DevOpsのセキュリティグループで役割単位に管理し、例外だけを最小限にする設計が安全です。公式情報でも、Azure DevOps ServicesではMicrosoft Entra ID、Azure DevOps ServerではActive DirectoryやWindowsユーザーグループを使う方が、複数環境でメンバーシップと権限を効率的に管理できると説明されています。(Microsoft Learn)
Deny、Not set、継承の違いを理解する
Azure DevOpsの権限トラブルの多くは、Deny、Not set、継承の違いを誤解していることから起こります。
| 状態 | 意味 | 実務上の見方 |
|---|---|---|
| Allow | 明示的に許可する | そのユーザーやグループに直接許可している |
| Allow inherited | グループや親ノードから許可を継承している | どの親設定から来ているか確認する |
| Deny | 明示的に拒否する | 多くの場合、Allowより優先されるため慎重に使う |
| Deny inherited | 拒否を継承している | 親ノードや所属グループの設定を確認する |
| Not set | 明示的に許可も拒否もしていない | 別グループのAllowやDenyが効く可能性がある |
| System allow / System deny | システム側で制御される | 管理画面で変更できない場合がある |
「権限を外したいからDenyにする」という運用は、後から別グループでAllowしても効かない原因になります。特定操作を許可したくないだけなら、まずNot setで足りるかを検討し、Denyは明確な禁止要件がある場合に限定するのが実務的です。公式情報でも、1つの権限変更がグループ内の多数のユーザーに影響する可能性があるため、変更前に影響を考慮するよう警告されています。(Microsoft Learn)
継承とオブジェクト単位の権限で見落としやすいポイント
Azure DevOpsのアクセス許可は階層に従って継承されます。ユーザーは所属グループから権限を継承し、エリア、イテレーション、バージョン管理フォルダー、作業項目クエリフォルダーなどのオブジェクト単位でも親から子へ権限が継承されます。明示的なアクセス許可は継承されたアクセス許可より優先され、競合がある場合はより具体的な設定が優先されます。(Microsoft Learn)
たとえば、親のエリアパスでDenyが設定されていても、子のエリアパスで明示的にAllowが設定されていれば、子側ではAllowが優先されるケースがあります。逆に、親で広くAllowしているつもりでも、下位のオブジェクトでDenyが設定されていると、特定のチームだけ作業項目を編集できないといった問題が起こります。
権限トラブル時の確認順序
| 手順 | 確認内容 | 目的 |
|---|---|---|
| 1 | ユーザーのアクセスレベルを確認する | 機能そのものを使える条件を満たしているか確認する |
| 2 | 所属セキュリティグループを確認する | Readers、Contributors、Project Administrators、カスタムグループを確認する |
| 3 | Deny設定を確認する | 別グループのDenyがAllowを打ち消していないか確認する |
| 4 | オブジェクト単位の権限を確認する | エリア、イテレーション、クエリ、パイプライン、フィードなどの個別設定を見る |
| 5 | 権限トレースを使う | なぜ許可・拒否されているか継承元を確認する |
| 6 | サインアウト・再評価を試す | Microsoft Entraグループ変更や権限変更の反映待ちを切り分ける |
公式のトラブルシューティングでは、アクセスレベル不足、セキュリティグループ所属、明示的なDeny、権限変更の反映待ち、チーム管理者ロール不足、プレビュー機能の未有効化、Project-Scoped Usersグループへの追加などが、よくある原因として整理されています。(Microsoft Learn)
Microsoft Entra ID連携で注意すべき反映タイミング
Azure DevOps ServicesをMicrosoft Entra IDと接続している場合、ユーザーやグループの管理をEntra側に寄せることで、入退社や組織変更に対応しやすくなります。ただし、グループ変更がAzure DevOps側に即時反映されないことがあります。公式情報では、Microsoft Entraグループに加えた変更はAzure DevOpsに1時間以内に登録され、継承されたアクセス許可が更新されると説明されています。反映を促すには、サインアウトして再サインインするか、権限の再評価を実行します。(Microsoft Learn)
開発現場では、次のような案内文を用意しておくと問い合わせ対応が短くなります。
| 状況 | ユーザーへの案内 |
|---|---|
| グループ追加直後にプロジェクトへ入れない | ブラウザーを閉じ、サインアウト・サインインを試してもらう |
| それでも反映されない | User settingsのPermissionsからRe-evaluate permissionsを実行する |
| 特定機能だけ使えない | アクセスレベル、所属グループ、対象リソースの権限を管理者が確認する |
| 1日たっても解消しない | グループルール、Deny、Project-scoped Users、プレビュー機能の状態を確認する |
「Entraグループに入れたから完了」と考えるのではなく、Azure DevOps側で有効権限を確認するところまでを変更手順に含めるのが安全です。
Project-scoped Usersを使う場合の注意点
Project-scoped Usersは、特定ユーザーの可視性をプロジェクト単位に制限したい場合に役立ちます。公式情報では、既定では組織に追加されたユーザーが組織やプロジェクトの情報、設定、ユーザー一覧、プロジェクト一覧、課金情報、使用状況データなどを表示できると説明されています。制限を有効にすると、Project-scoped Usersに追加されたユーザーやグループは、一部を除きOrganization settingsにアクセスできず、追加されたプロジェクトだけにアクセスできます。(Microsoft Learn)
ただし、この機能は万能な情報遮断ではありません。公式情報では、制限付き可視性はWebポータル経由の操作に適用され、REST APIやazure devops CLIコマンドではプロジェクトメンバーが制限付きデータへアクセスできる可能性があるとされています。外部委託先やゲストユーザーの情報可視性を制御する場合は、Project-scoped Usersだけでなく、API利用、PAT、サービス接続、組織ポリシーも合わせて確認する必要があります。(Microsoft Learn)
ロールベース権限はPipelinesやArtifactsで特に重要
Azure DevOpsでは、セキュリティグループだけでなく、ロールベースのアクセス許可も使われます。公式情報では、Artifactまたはパッケージフィードのセキュリティロール、Marketplace拡張機能マネージャーロール、Pipelineセキュリティロール、Team administratorロールが、ロールベース権限の対象として挙げられています。(Microsoft Learn)
たとえば、ある開発者がContributorsに入っていても、特定のパイプラインリソースやフィードのロールが不足していれば、実行・編集・参照が制限されることがあります。CI/CDのトラブルでは、Project AdministratorsやContributorsだけを見るのではなく、対象パイプライン、環境、サービス接続、パッケージフィードなど、リソースごとのロールも確認してください。
CI/CD運用で確認すべき項目
| 確認項目 | 失敗しやすいポイント |
|---|---|
| パイプライン実行権限 | ユーザーはプロジェクトに入っているが、対象パイプラインの権限が不足している |
| サービス接続 | Project Administrators以外のユーザーが編集・利用できない |
| エージェントプール | 組織レベルの管理権限が必要な操作をプロジェクト管理者だけで行おうとしている |
| Artifactsフィード | Contributors所属でもフィード側のロールが不足している |
| 拡張機能 | Marketplace拡張機能の管理ロールが不足している |
開発者から「昨日まで動いていたパイプラインが動かない」と連絡が来た場合は、コード変更だけでなく、サービス接続、環境、フィード、エージェントプール、関連するセキュリティグループの変更履歴も確認する必要があります。
管理者が今すぐ確認すべき設定チェックリスト
Azure DevOpsの権限管理は、問題が起きてから調査すると時間がかかります。公式情報を踏まえると、管理者は次の順序で棚卸しすると効果的です。
| 優先度 | チェック項目 | 判断基準 |
|---|---|---|
| 高 | Project Collection Administratorsのメンバー | 組織全体を管理する必要がある人だけに限定されているか |
| 高 | Project Administratorsのメンバー | プロジェクト設定を変更する役割の人だけか |
| 高 | Contributorsの範囲 | 開発・作業管理を行う人に限定されているか |
| 高 | Deny設定 | 広範囲のグループにDenyが入っていないか |
| 高 | Microsoft Entra IDグループ連携 | 個人追加が増えすぎていないか |
| 中 | Project-scoped Users | 外部メンバーやゲストの可視性制御に使われているか |
| 中 | パイプライン・Artifactsのロール | プロジェクト権限とリソース権限が矛盾していないか |
| 中 | サービスアカウント | 個人アカウントでCI/CDが動いていないか |
| 中 | アクセスレベル | Stakeholder、Basic、Basic + Test Plansが用途に合っているか |
| 低 | プレビュー機能 | 権限画面や可視性制御のプレビュー機能が意図通りか |
Azure DevOps Servicesでセキュリティグループを管理する場合、公式情報ではaz devops security groupコマンドを使って、グループ作成、一覧取得、詳細表示、更新・削除、メンバーシップ管理ができると説明されています。Webポータルで見えないグループ名や大規模な棚卸しには、CLIやREST APIを使った確認も有効です。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
Azure DevOps ServerからAzure DevOps Servicesへ移行する場合や、既存組織にMicrosoft Entra ID連携を導入する場合は、権限設計をそのままコピーしないことが重要です。Azure DevOps ServicesではMicrosoft Entraグループ、Azure DevOps ServerではActive DirectoryやWindowsユーザーグループが中心になります。公式情報でも、Azure DevOps Serverではインストール前にActive Directoryをインストールする必要があると説明されています。(Microsoft Learn)
移行前に確認すること
| 項目 | 確認内容 |
|---|---|
| ユーザーID | Microsoft Entra ID、Microsoftアカウント、ADアカウントの対応関係を整理する |
| グループ | 旧環境のADグループをEntraグループやAzure DevOpsグループにどう置き換えるか決める |
| アクセスレベル | 移行後にBasicやBasic + Test Plansが不足しないか確認する |
| サービスアカウント | 個人アカウントに依存していないか確認する |
| パイプライン | サービス接続、エージェントプール、環境、フィードの権限を確認する |
| Deny設定 | 旧環境の拒否設定が移行後に想定外の制限にならないか確認する |
| ゲストユーザー | Project-scoped Usersや組織ポリシーで可視性を制御するか決める |
展開時は、全プロジェクトへ一括反映する前に、代表的な1プロジェクトで検証するのが安全です。検証では、管理者、開発者、QA、外部ユーザー、サービスアカウントのそれぞれで、サインイン、リポジトリ参照、作業項目更新、パイプライン実行、Artifacts参照、組織設定の可視性を確認してください。
開発者が権限エラーを見つけたときの伝え方
開発者側でも、管理者に問い合わせる前に情報を整理しておくと解決が早くなります。「アクセスできません」だけでは、アクセスレベル不足なのか、Denyなのか、リソースロール不足なのか切り分けできません。
問い合わせ時は、次の情報を添えるとよいでしょう。
| 伝える情報 | 例 |
|---|---|
| 操作した場所 | Azure Reposの特定リポジトリ、Azure Pipelinesの特定パイプラインなど |
| できない操作 | 表示できない、実行できない、編集できない、削除できない |
| エラーの内容 | 画面のエラーメッセージ、発生時刻、スクリーンショット |
| 自分の役割 | 開発者、QA、プロジェクト管理者、外部メンバーなど |
| 直近の変更 | チーム異動、Entraグループ変更、プロジェクト追加、ライセンス変更 |
| 試したこと | サインアウト・サインイン、ブラウザー再起動、権限の再評価 |
公式のトラブルシューティングでも、権限トレースを使うことで、ユーザーがなぜその権限を持つ、または持たないのかを確認できると説明されています。管理者はProject settingsのPermissionsやSecurity画面から対象ユーザーを確認し、継承元のグループをたどって修正します。(Microsoft Learn)
安全な権限変更の進め方
Azure DevOpsの権限変更は、軽い設定変更に見えても影響範囲が広がりやすい作業です。特にContributors、Project Administrators、Project Collection Administrators、Project Valid Users、Project Collection Valid Usersに対する変更は慎重に行う必要があります。
実務では、次の流れで進めると失敗を減らせます。
| フェーズ | 実施内容 |
|---|---|
| 事前確認 | 対象グループ、対象ユーザー、対象プロジェクト、対象リソースを一覧化する |
| 影響確認 | 変更で操作できなくなるユーザー、操作できるようになるユーザーを確認する |
| 検証 | テスト用プロジェクトまたは限定プロジェクトで動作確認する |
| 周知 | 開発者に変更日時、影響、問い合わせ先、再サインイン手順を伝える |
| 反映 | 変更ログを残しながら設定する |
| 確認 | 代表ユーザーでBoards、Repos、Pipelines、Artifactsなどを確認する |
| ロールバック | 想定外の影響が出た場合に戻す設定を準備する |
権限を強化する場合も、緩和する場合も、変更前後のグループメンバーと主要権限を記録しておくことが重要です。Azure DevOpsの権限は継承とロールが重なるため、「誰が何を変えたか」が分からないと、後から原因を特定しにくくなります。
まとめ：まずはDenyと管理者グループを棚卸しする
Azure DevOpsの権限とセキュリティグループは、アクセスレベル、グループ所属、明示的なAllow・Deny、継承、ロールベース権限が重なって有効権限を決めます。今回の公式情報を受けて管理者が最初に行うべきことは、新機能対応ではなく、既存設定の棚卸しです。
まずProject Collection AdministratorsとProject Administratorsのメンバーを確認し、次にContributorsやカスタムグループのDeny設定を見直してください。そのうえで、Microsoft Entra IDグループ連携、Project-scoped Users、パイプラインやArtifactsのロール、サービスアカウントを確認すると、権限トラブルを未然に防ぎやすくなります。
開発者側は、権限エラーが出たときに「どのリソースで、どの操作が、いつ、どのエラーで失敗したか」を整理して管理者に伝えることが大切です。管理者は権限トレースと再評価を使い、アクセスレベル不足、Deny、継承、ロール不足を順に切り分けましょう。
コメント