Azure DevOpsのアクセスレベルで最初に押さえるべきことは、これは「権限そのもの」ではなく、ユーザーが使える機能範囲と課金対象を決める設定だという点です。Reposに入れない、Test Plansが表示されない、ユーザー追加後に想定外の課金が発生する、といったトラブルは、アクセスレベルとセキュリティグループを混同したときに起こりがちです。Microsoft Learnの「About access levels」では、Azure DevOpsのアクセスレベルがWebポータル機能を制御し、セキュリティグループによる許可・拒否を補完するものだと説明されています。(Microsoft Learn)
2026年5月時点で管理者が見るべきポイントは、単に「Basic」「Stakeholder」を選ぶことではありません。2026年5月8日更新の公式情報では、有料アクセスの割り当て、既定アクセスレベル、グループルール、未使用ユーザーの見直し、複数組織の課金管理が実務上の確認対象になっています。(Microsoft Learn)
Azure DevOpsのアクセスレベルとは何か
Azure DevOpsのアクセスレベルは、ユーザーがAzure DevOps ServicesまたはAzure DevOps Serverで利用できる機能を決める設定です。たとえば、コードを扱う開発者にはAzure Reposが必要ですが、進捗確認や作業項目へのコメントだけを行う関係者には、より限定的なStakeholderで足りる場合があります。
ここで重要なのは、アクセスレベルと権限は別物だということです。
| 項目 | 役割 | 例 |
|---|---|---|
| アクセスレベル | 使える機能範囲と課金対象を決める | Reposを使えるか、Test Plansを使えるか |
| セキュリティグループ | 操作の許可・拒否を決める | Contributors、Readers、Project Administrators |
| 個別権限・ACL | 特定リポジトリやパス単位で操作を制御する | ブランチポリシー、Area Path、Iteration Path |
Microsoftの公式説明でも、アクセスレベルはセキュリティグループを補完するものであり、ユーザーやグループをチーム・プロジェクトへ追加すると、既定のアクセスレベルとセキュリティグループに応じた機能を利用できるようになるとされています。多くの一般ユーザーには、BasicアクセスレベルとContributorsグループの組み合わせで大半の機能を利用できます。(Microsoft Learn)
今回の確認ポイントは「仕様変更」よりも「運用見直し」
「About access levels – Azure DevOps」で理解すべき変更点は、アクセスレベルの名称が大きく変わるというより、ライセンス・課金・グループルール・外部ユーザー管理まで含めた運用確認が重要になっている点です。
| 確認ポイント | 管理者への影響 | 開発者・利用者への影響 |
|---|---|---|
| アクセスレベルと権限の分離 | ライセンスを付けても、権限設定が不足すると操作できない | ReposやBoardsが見えない原因を切り分けやすくなる |
| Basic、Stakeholder、Basic + Test Plansの使い分け | 不要な有料ライセンスを減らせる | 必要な機能だけを利用できる |
| Visual Studioサブスクライバーの自動認識 | 有効期限切れユーザーの棚卸しが必要 | サブスクリプション失効時に機能が制限される可能性がある |
| GitHub Enterpriseライセンスの認識 | Entra IDやGitHub側のライセンス状態確認が必要 | Basic相当のアクセスが自動付与される場合がある |
| グループルール | Microsoft Entraグループ単位で割り当てを自動化できる | 所属グループ変更によりアクセスレベルが変わる |
| Public projectの廃止予定 | 公開プロジェクト前提の運用を見直す必要がある | 匿名アクセスや公開リンクが使えなくなる可能性がある |
特に注意したいのは、アクセスレベルを下げると「ログインはできるが、必要な機能が見えない」という状態が起こり得ることです。たとえばStakeholderは無料で使いやすい一方、プライベートプロジェクトではAzure Reposへアクセスできません。(Microsoft Learn)
Azure DevOpsで使われる主なアクセスレベル
Azure DevOps Servicesでは、主に次のアクセスレベルを使います。
| アクセスレベル | 向いているユーザー | 主な用途 | 注意点 |
|---|---|---|---|
| Stakeholder | 進捗確認者、業務部門、短期のレビュー担当者 | 作業項目の閲覧・編集、ダッシュボード確認、リリース承認など | プライベートプロジェクトではReposやTest Plansに制限がある |
| Basic | 開発者、スクラムメンバー、運用担当者 | Repos、Boards、Pipelines、Artifactsなどの基本機能 | 6人目以降は課金対象になる場合がある |
| Basic + Test Plans | QA担当、テスト設計者、受け入れテスト担当 | Basic機能に加えてTest Plansを利用 | テスト計画・手動テストを使う人に限定するのが基本 |
| Visual Studio Subscriber | Visual Studioサブスクリプション保有者 | サブスクリプション特典に応じたAzure DevOps利用 | サブスクリプションの有効性が検出される |
| GitHub Enterprise | GitHub Enterpriseライセンス保有者 | Basic相当のAzure DevOps利用 | Test Plansが必要なら追加の割り当てを検討する |
公式ドキュメントでは、Basicは多くの機能を利用できるアクセスレベル、Basic + Test PlansはBasicにAzure Test Plansを加えたアクセスレベル、Stakeholderは制限付きアクセスとして説明されています。また、Visual StudioサブスクライバーやGitHub Enterpriseユーザーは、サインイン時にサブスクリプションやライセンスが認識される仕組みです。(GitHub)
管理者が最初に確認すべき設定
Azure DevOps管理者は、アクセスレベルを変更する前に次の順番で確認すると失敗しにくくなります。
| 手順 | 確認する場所 | 見るべき内容 |
|---|---|---|
| 現在のユーザー一覧を確認 | Organization settings > Users | Access level、Last Access、割り当て元 |
| 役割ごとに必要機能を整理 | チーム構成、業務内容 | Repos、Boards、Pipelines、Test Plansの要否 |
| 既定アクセスレベルを確認 | Organization settings > Billing | 新規ユーザーに何が付与されるか |
| グループルールを確認 | Users > Group rules | Entraグループとアクセスレベルの対応 |
| 直接割り当てを確認 | Users画面 | グループルールと競合していないか |
| 不要ユーザーを見直す | UsersのLast Access | 退職者、長期未使用者、不要なBasicユーザー |
公式情報では、Users画面でアクセスレベルやサービス拡張を確認・変更でき、複数ユーザーをまとめて編集したり、Last Accessを見て不要または低いアクセスレベルに変更すべきユーザーを探したりできます。(Microsoft Learn)
BasicとStakeholderの判断基準
アクセスレベルの判断で迷いやすいのが、BasicとStakeholderの使い分けです。費用だけを見てStakeholderに寄せると、開発・レビュー・テストの現場で必要な機能が使えなくなる可能性があります。
| ユーザーの役割 | 推奨アクセスレベル | 理由 |
|---|---|---|
| Gitリポジトリをclone、push、pull requestレビューする開発者 | Basic以上 | StakeholderではプライベートプロジェクトのReposを利用できない |
| バックログを更新し、スプリント計画に参加するスクラムメンバー | Basic | Boardsを本格的に使うにはBasicが安全 |
| 作業項目の確認・コメント・簡単な更新だけを行う業務部門 | Stakeholder | 作業項目中心ならコストを抑えられる |
| リリース承認だけを行う管理職・承認者 | Stakeholderで足りる場合がある | Pipelinesの表示・承認用途なら十分なケースがある |
| テスト計画やテストスイートを作成するQA担当 | Basic + Test Plans | Test Plans管理機能が必要 |
| Wiki、ダッシュボード、チャートを作成・編集するメンバー | Basic | Stakeholderでは作成・構成に制限が出やすい |
Stakeholderは無料で無制限に割り当てられる便利なアクセスレベルですが、「制限付きの共同作業者」です。公式のStakeholderクイックリファレンスでは、StakeholderはAzure Boardsの作業項目作成・更新などが可能な一方、コードベースに貢献するユーザーには少なくともBasicアクセスを割り当てる必要があるとされています。(Microsoft Learn)
課金面で確認すべきポイント
Azure DevOpsのアクセスレベルは、課金にも直結します。Azure DevOps Servicesの料金ページでは、Basic Planは最初の5ユーザーが無料で、その後はユーザー単位の月額課金、Basic + Test Plansはユーザー単位の月額課金として示されています。Visual StudioサブスクライバーはAzure DevOpsへのアクセスが含まれ、5人の無料Basicユーザー枠にはカウントされないと説明されています。(マイクロソフトアジュール)
管理者が特に確認すべきなのは、次の3点です。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| Basicユーザー数 | 6人目以降が課金対象になっていないか | 退職者や休眠ユーザーがBasicのまま残る |
| Basic + Test Plans | 本当にTest Plans管理が必要な人だけか | QA以外にも広く付与してしまう |
| Visual Studio / GitHub Enterprise | 自動認識されるライセンスが有効か | 無効化後にStakeholderへ下がり、Reposが使えなくなる |
公式の有料アクセス管理ページでは、Visual StudioサブスクライバーやGitHub Enterpriseユーザーはサインイン時に自動検出され、Stakeholderは無料の制限付きアクセス、Basicは最初の5ユーザーが無料、Basic + Test Plansは有料アクセスとして整理されています。(Microsoft Learn)
既定アクセスレベルを見直す
新規ユーザー追加時の既定アクセスレベルは、運用コストとセキュリティの両方に影響します。たとえば、開発者が多い組織で既定をStakeholderにしていると、参加直後にReposが使えずオンボーディングが止まることがあります。逆に、外部レビュー担当者が多い組織で既定をBasicにしていると、不要な課金が発生しやすくなります。
公式情報では、新しいユーザーがプロジェクトへ直接追加された場合は無料のStakeholderアクセスを取得し、既定アクセスレベルを変更するにはOrganization settingsのBillingで設定すると説明されています。(Microsoft Learn)
実務では、次のように決めると管理しやすくなります。
| 組織の状況 | 既定アクセスレベルの考え方 |
|---|---|
| 開発者中心で、参加者の大半がReposを使う | Basicを既定にし、不要ユーザーを定期的にStakeholderへ下げる |
| 外部関係者や閲覧者が多い | Stakeholderを既定にし、開発者だけBasicを付与する |
| Entraグループで職種管理できている | 既定は低めにし、グループルールでBasicやTest Plansを付与する |
| 短期プロジェクトや委託先が多い | Stakeholderまたは期限付きの棚卸し運用を前提にする |
グループルールでアクセスレベルを自動化する
ユーザー単位でアクセスレベルを変更していると、異動・退職・プロジェクト参加のたびに設定漏れが起きます。Microsoft Entra IDを使っている組織では、グループルールでアクセスレベルとプロジェクトメンバーシップをまとめて管理すると効果的です。
公式ドキュメントでは、Azure DevOpsのグループルールにより、Microsoft EntraグループやAzure DevOpsグループ単位でアクセスレベルを割り当てられると説明されています。複数のルールに所属するユーザーには、より高いアクセスレベルが適用されます。(Microsoft Learn)
| Entraグループ例 | 割り当てるアクセスレベル | プロジェクト権限の例 |
|---|---|---|
| Dev-AzureDevOps-Contributors | Basic | Contributors |
| QA-TestPlans | Basic + Test Plans | Contributors |
| PM-Stakeholders | Stakeholder | ContributorsまたはReaders |
| Project-Admins | Basic | Project Administrators |
| External-Reviewers | Stakeholder | Readersまたは限定的なContributors |
グループルールの注意点は、反映タイミングです。公式情報では、Microsoft Entra IDのグループメンバーシップ更新はAzure DevOps側で定期的に反映され、動的グループの更新に時間がかかる場合があると説明されています。また、サービスプリンシパルやマネージドIDにはライセンス用グループルールが適用されないため、直接割り当てが必要です。(Microsoft Learn)
Visual Studioサブスクリプション失効への対応
2026年の運用で特に見落としやすいのが、Visual Studioサブスクリプションの失効です。公式FAQでは、2026年2月から管理者が期限切れサブスクリプションのユーザーを確認できるようになり、2月・3月の猶予後、4月以降は期限切れユーザーがStakeholderアクセスへ移行し始めると説明されています。(Microsoft Learn)
影響は小さくありません。これまでVisual Studio Enterpriseなどの特典でBasic + Test Plans相当の機能を使っていたユーザーが、失効後にStakeholder相当になると、ReposやTest Plansが使えなくなる可能性があります。
確認手順は次のとおりです。
| 手順 | 操作 |
|---|---|
| 影響ユーザーを抽出 | Organization settings > UsersでAccess levelフィルターを使い、Invalid表示のVisual Studioサブスクリプションを確認 |
| 必要機能を確認 | Repos、Pipelines、Test Plans、Artifactsの利用有無を確認 |
| 代替アクセスを付与 | 必要に応じてBasicまたはBasic + Test Plansを割り当て |
| グループルールを整備 | サブスクリプション失効後も必要なアクセスが維持されるようにする |
| 開発者へ通知 | 失効後にReposやTest Plansが見えなくなる可能性を事前共有 |
公式FAQでは、Visual Studioサブスクリプションが検出されなくなったユーザーは新規ユーザーのように扱われ、既定アクセスレベル、グループルール、GitHub Enterpriseライセンスの有無に応じてアクセスが決まるとされています。(Microsoft Learn)
GitHub Enterpriseユーザーの確認ポイント
GitHub Enterpriseを利用している組織では、Azure DevOps側のアクセスレベルにも影響があります。公式FAQでは、GitHub Enterprise Cloudユーザーが同じMicrosoft EntraテナントでGitHubとAzure DevOpsへアクセスしている場合、Azure DevOpsでGitHub Enterpriseライセンスが認識されると説明されています。(Microsoft Learn)
ただし、GitHub EnterpriseはBasic相当のアクセスであり、Test Plansが必要なユーザーにはBasic + Test Plansを割り当てる必要があります。また、GitHub Enterpriseライセンスが検出されなくなった場合は、既定アクセスレベルやグループルールに従って再評価されます。(Microsoft Learn)
| 状況 | 確認すべきこと |
|---|---|
| GitHub Enterpriseを導入済み | Azure DevOpsとGitHubで同じEntra IDを使っているか |
| Azure DevOpsでBasic課金が増えている | GitHub Enterpriseとして認識されていないユーザーがいないか |
| QA担当がGitHub Enterpriseユーザー | Test Plansが必要ならBasic + Test Plansを別途検討 |
| ライセンス解除・退職者がいる | Stakeholderへ下がるか、組織から削除されるかを確認 |
Azure DevOps Serverの場合の注意点
Azure DevOps ServicesとAzure DevOps Serverでは、アクセスレベルの管理画面や前提が異なります。公式の「Change access levels」はAzure DevOps Server向けであり、Azure DevOps Servicesのアクセス管理は「Add organization users and manage access」を参照するよう案内されています。(Microsoft Learn)
Azure DevOps Serverでは、コレクション単位でアクセスレベルを管理し、既定アクセスレベルが全プロジェクトに影響します。公式ドキュメントでは、ユーザーやグループがチーム、プロジェクト、コレクションへ追加されると既定アクセスレベルを取得し、別のアクセスレベルを与えるには非既定のアクセスレベルへ追加する必要があると説明されています。(Microsoft Learn)
Server環境で特に注意すべきなのは、既定アクセスレベルをStakeholderにする場合です。公式情報では、サービスアカウントが既定アクセスレベルへ追加されるため、既定をStakeholderにする場合はAzure DevOpsサービスアカウントをBasicまたは上位レベルへ追加する必要があるとされています。(Microsoft Learn)
開発者が確認すべき影響範囲
アクセスレベルの見直しは管理者だけの作業ではありません。開発者やQA担当も、自分の作業に必要な機能がどのアクセスレベルに依存しているかを把握しておく必要があります。
| 作業内容 | 必要になりやすいアクセスレベル | 確認ポイント |
|---|---|---|
| Git clone、push、pull requestレビュー | Basic以上 | StakeholderではプライベートReposにアクセスできない |
| Boardsで作業項目を追加・更新 | Stakeholderでも可能な範囲あり | 優先順位変更、スプリント割り当てなどは制限に注意 |
| Pipelineの確認・承認 | Stakeholderでも可能な場合あり | YAML編集やリポジトリ操作が必要ならBasic |
| Test Plansの作成・管理 | Basic + Test Plans | Basicだけではテスト計画管理が不足する可能性 |
| Wikiやダッシュボードの編集 | Basic推奨 | Stakeholderでは作成・構成に制限がある |
| 拡張機能の利用 | Basic以上が必要な場合あり | Marketplace拡張の説明を確認 |
公式FAQでは、Stakeholderアクセスのユーザーは作業項目やダッシュボードなどを扱える一方、プライベートGitリポジトリの閲覧、clone、push、pull requestレビューはできないと説明されています。(Microsoft Learn)
CLIやAPIで管理する場合のマッピング
ユーザー管理を自動化している組織では、Azure DevOps CLIやREST APIでアクセスレベルを扱う場面があります。UI上の表示名とCLI/APIの値は一致しないため、スクリプト作成時はマッピングを確認する必要があります。
| UI上のアクセスレベル | CLI/APIで使う値の例 |
|---|---|
| Stakeholder | stakeholder |
| Basic | express |
| Basic + Test Plans | advanced |
| Visual Studio Subscriber | msdn / eligible |
| Visual Studio Enterprise | msdn / enterprise |
| GitHub Enterprise | gitHub / enterprise |
公式のアクセスレベル解説では、Azure DevOps Servicesでaz devops user addやUser Entitlement REST APIを使ってアクセスレベルを管理でき、UI上のアクセスレベルとAccountLicenseType、licensingSource、msdnLicenseType、GitHubLicenseTypeの対応が示されています。(GitHub)
たとえば、Basicアクセスのユーザーを追加するCLIの考え方は次のようになります。
az devops user add \
--email-id [email protected] \
--license-type express \
--org https://dev.azure.com/yourorganizationStakeholderへ変更する場合は次のように指定します。
az devops user update \
--user [email protected] \
--license-type stakeholder \
--org https://dev.azure.com/yourorganization公式のユーザー管理ページでも、az devops user addやaz devops user updateでstakeholder、express、advancedなどのライセンスタイプを指定できると説明されています。(Microsoft Learn)
移行・展開時の実務チェックリスト
アクセスレベルの見直しを一括で行う場合は、いきなり全ユーザーへ適用しないことが重要です。特に、BasicからStakeholderへ下げる作業はコスト削減につながる一方、開発やテストを止めるリスクがあります。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 棚卸し | ユーザー、アクセスレベル、Last Access、所属プロジェクトを一覧化 | 不明な直接割り当てが見える |
| 役割定義 | 開発者、QA、PM、閲覧者、外部委託先を分類 | 必要な機能とアクセスレベルが対応している |
| 小規模検証 | 1チームまたは一部ユーザーで変更を試す | Repos、Boards、Pipelines、Test Plansが想定どおり使える |
| グループルール適用 | Entraグループ単位で割り当てを自動化 | 手作業の割り当てが減る |
| 直接割り当て削除 | グループルール運用へ移行 | 例外ユーザーだけが直接割り当てで残る |
| 監視 | 課金、Last Access、問い合わせ内容を確認 | 不要なBasicやTest Plansが減る |
公式のグループルールドキュメントでは、グループルールで管理する場合、直接割り当てを削除してグループルール中心の運用へ移行できると説明されています。ただし、グループルールが付与するより高いアクセスレベルを手動で持っているユーザーは、その高いアクセスレベルが維持されます。(Microsoft Learn)
よくある失敗と対策
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| Stakeholderを「読み取り専用」と誤解する | 作業項目の編集などが可能な範囲を見落とす | 権限制御はReadersや個別権限で行う |
| Basicを付ければ何でもできると思い込む | リポジトリやプロジェクトの権限不足で操作できない | セキュリティグループとACLも確認する |
| Test Plans利用者をBasicに下げる | テスト計画作成や手動テスト管理ができなくなる | QA担当はBasic + Test Plansの要否を確認する |
| グループルールだけでサービスプリンシパルを管理する | 自動割り当てされない | サービスプリンシパルやマネージドIDは直接割り当てる |
| Visual Studioサブスクリプション失効を放置する | ReposやTest Plansが使えなくなる | Invalid表示のユーザーを定期確認する |
| Public project前提でStakeholder運用する | 2027年以降の非公開化で外部公開運用が崩れる | GitHub移行またはPrivate前提の認証設計にする |
特にPublic projectは注意が必要です。Microsoftは、Azure DevOpsの新しいPublic projectを作成できなくなり、2027年には既存のPublic projectがPrivate projectへ自動変換され、匿名アクセスが無効化されると説明しています。(Microsoft Learn)
Conditional Accessはアクセスレベルとは別に設計する
アクセスレベルは「Azure DevOps内の機能範囲」を決めるものであり、MFA、デバイス準拠、IP制限などのサインイン条件を直接管理するものではありません。これらはMicrosoft Entra IDのConditional Accessで設計します。
公式ドキュメントでは、Azure DevOpsを対象リソースにしたConditional Accessポリシーを作成でき、MFA要求、ユーザーやワークロードID、ネットワーク条件、デバイス条件などを組み合わせられると説明されています。(Microsoft Learn)
実務では、次のように分けて考えると整理しやすくなります。
| 管理したいこと | 使う設定 |
|---|---|
| ReposやTest Plansを使えるか | Azure DevOpsのアクセスレベル |
| プロジェクトで何を操作できるか | Azure DevOpsのセキュリティグループ・権限 |
| どの端末・場所からサインインできるか | Microsoft Entra Conditional Access |
| APIやPAT利用をどこまで許可するか | Azure DevOps組織ポリシー、Conditional Access、PAT管理 |
| 外部ユーザーをどこまで見せるか | Entra ID、Project-Scoped Users、プロジェクト権限 |
まず実施すべきアクション
Azure DevOpsのアクセスレベル見直しでは、最初から全ユーザーを変更するのではなく、棚卸し、分類、検証の順で進めるのが安全です。
まず、Organization settings > Usersでユーザー一覧を確認し、Basic、Basic + Test Plans、Stakeholder、Visual Studio Subscriber、GitHub Enterpriseの割り当て状況を把握します。次に、Last Accessで長期間使っていない有料アクセスユーザーを洗い出します。そのうえで、開発者はBasic、QA担当はBasic + Test Plans、閲覧・承認中心の関係者はStakeholderという形で役割別の基準を作ります。
グループルールを使える組織では、Entraグループを起点にアクセスレベルを自動化しましょう。直接割り当てを残す場合は、例外理由を記録しておくと、後から課金や権限の棚卸しがしやすくなります。
最後に、変更後は開発者に次の4点を確認してもらうと、影響を早期に見つけられます。
| 確認項目 | 見るべき結果 |
|---|---|
| Repos | clone、push、pull request確認ができる |
| Boards | 作業項目の作成・更新・スプリント操作ができる |
| Pipelines | 必要なパイプラインの閲覧・実行・承認ができる |
| Test Plans | QA担当がテスト計画・テストケースを扱える |
Azure DevOpsのアクセスレベルは、単なるライセンス設定ではなく、開発体験、セキュリティ、コスト管理を同時に左右する重要な管理項目です。まずは現在の割り当てを可視化し、役割別の基準を決め、グループルールで継続管理できる状態にすることが、2026年時点の最も現実的な対応です。
コメント