Azure DevOps Released Featuresの2026年5月6日更新では、Azure Reposの大規模リポジトリ対応、Pull Requestレビューの見える化、GitHub連携APIの認証強化、Windows ARM64セルフホステッドエージェントのプレビュー、Azure Test Plansの手動テスト記録機能などが追加・改善されています。特に管理者は、GitHub連携の再認証、Test Plansの設定変更、Windows ARM64エージェントの導入条件、Azure DevOps ServerからAzure DevOps Servicesへの移行準備を確認しておくべきです。
今回の変更は、すべての利用者に一律で大きな作業を求めるものではありません。ただし、Azure DevOpsを開発基盤として使っている組織では、レビュー運用、セキュリティ監視、CI/CD環境、移行計画に影響する項目があります。この記事では、Microsoft公式のAzure DevOps release notes and server build numbersをもとに、何が変わるのか、誰が確認すべきか、実務でどのように対応すべきかを整理します。(Microsoft Learn)
Azure DevOps Released Featuresとは
Azure DevOps Released Featuresは、Azure DevOps Servicesに追加された主要機能と、それに対応するAzure DevOps Serverのバージョン情報を確認できる公式のリリースタイムラインです。Microsoft公式ページでは、各Service Updateごとに、General、Boards、Repos、Pipelines、Test Plans、GitHub Advanced Security for Azure DevOpsなどの機能領域別に変更点が整理されています。(Microsoft Learn)
実務では、単に「新機能を読むページ」として見るよりも、次の目的で使うと役立ちます。
| 確認目的 | 見るべきポイント |
|---|---|
| Azure DevOps Servicesの変更確認 | 直近のService Updateで自社環境に影響する機能があるか |
| Azure DevOps Serverの更新判断 | Server列に対象バージョンがあるか、FutureやN/Aになっていないか |
| 移行計画の検討 | Data Migration ToolやServer build numbersの更新状況 |
| 管理者向け運用確認 | 認証、権限、セキュリティ概要、エージェント、テスト設定の変更 |
| 開発チームへの周知 | Pull Request、Boards、Pipelines、Test Plansの操作変更 |
注意したいのは、Azure DevOps ServicesとAzure DevOps Serverでは反映タイミングが異なる点です。公式タイムラインのServer列で「Future」と表示されているものは、将来のAzure DevOps Server向け予定として扱われ、現時点のServer環境にすぐ反映されるとは限りません。(Microsoft Learn)
2026年5月6日更新の全体像
2026年5月6日に更新されたリリースノートは、Sprint 273 updateとして公開されています。内容の中心はAzure Reposの改善で、Pull Requestの状態確認をしやすくする変更と、Gitリポジトリのスケーラビリティ向上が目立ちます。(Microsoft Learn)
今回の主な変更は次のとおりです。
| 機能領域 | 変更内容 | 主な対象者 |
|---|---|---|
| General | Azure DevOps Data Migration Toolの最新版 | Azure DevOps Server管理者、移行担当者 |
| GitHub Advanced Security for Azure DevOps | 削除済み・無効化済みリポジトリをSecurity overviewから除外 | セキュリティ管理者、DevSecOps担当者 |
| Azure Boards | Work itemコピー時のリンク選択を改善 | プロジェクトマネージャー、開発チーム |
| Azure Boards | GitHub Integration REST APIsの認証強化 | API利用者、管理者、開発者 |
| Azure Pipelines | Windows ARM64 agentのパブリックプレビュー | CI/CD管理者、ARM64環境の開発者 |
| Azure Repos | Pull Request status checksのExternalバッジ追加 | レビュアー、ブランチポリシー管理者 |
| Azure Repos | 未解決コメントをPull Request一覧に表示 | 開発者、レビュアー |
| Azure Repos | Git object count limitの削除 | 大規模リポジトリ運用者 |
| Azure Test Plans | 手動テストでステップごとのActual Result記録がプレビュー | QA担当者、テスト管理者 |
公式リリースノートでは、これらの機能は今後2〜3週間でロールアウトされると案内されています。組織やリージョンによって表示タイミングがずれる可能性があるため、見えない場合でも即時の障害と判断せず、段階的展開を前提に確認するのが安全です。(Microsoft Learn)
管理者が最初に確認すべきポイント
今回のAzure DevOps Released Featuresで、管理者が優先して確認すべきなのは「認証」「セキュリティ表示」「エージェント」「テスト設定」「移行」の5点です。
| 確認項目 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| GitHub連携API | 初回利用時の再認証が必要なユーザーがいるか | API利用時に一時的な操作停止や問い合わせが発生する |
| Security overview | 表示対象から除外されたリポジトリが想定どおりか | セキュリティ対象外のリポジトリを見落とす |
| Windows ARM64 agent | 対応OS、プレビュー利用の可否、エージェントプール設計 | 不安定な環境を本番CIに組み込む |
| Test Plans | Actual ResultのRequired設定を使うか | テスト実行者の入力負荷や運用混乱が起きる |
| Server移行 | Data Migration ToolとServer build numbersの確認 | 移行前提バージョンの認識違いが起きる |
特にGitHub Integration REST APIsを利用している組織では、GitHub App OAuth tokensへの変更により、変更後の初回利用時にユーザーが再認証を求められます。Microsoftは、この再認証後はAPI操作が通常どおり継続し、自動トークン更新によって手動再認可の頻度を減らせると説明しています。(Microsoft Learn)
Azure Reposの変更点：大規模リポジトリとPRレビューが改善
今回もっとも注目度が高いのはAzure Reposの改善です。大規模なモノレポを運用している企業、Pull Requestレビューを厳格に運用しているチームでは、日常業務の見え方が変わります。
Git object count limitが削除された
Azure Reposでは、従来Gitリポジトリ内のGit object数に1億個の上限がありました。今回の更新でこのハードリミットが削除され、大規模で長期間運用されるリポジトリのスケーラビリティが改善されています。(Microsoft Learn)
これは、次のような環境で特に意味があります。
| 対象環境 | 影響 |
|---|---|
| 長年運用しているモノレポ | 履歴、ブランチ、タグ、オブジェクト増加による上限到達リスクを下げられる |
| 多数の開発者が継続的にコミットする環境 | リポジトリ成長に対する余裕が増える |
| 大規模製品群を単一リポジトリで管理する組織 | リポジトリ分割を急ぐ必要性が下がる場合がある |
ただし、「上限が消えた＝無制限に巨大化しても問題ない」と考えるのは危険です。Git object count limitの削除はスケール上の制約緩和であり、クローン時間、履歴検索、CI実行時間、ストレージ管理、不要ブランチの整理といった運用課題まで自動的に解消するものではありません。
実務では、次の確認をおすすめします。
| 確認項目 | 判断基準 |
|---|---|
| リポジトリサイズ | 開発者の初回cloneやfetchが業務に支障を出していないか |
| ブランチ運用 | 不要な長期ブランチや放置ブランチが増えていないか |
| CI対象範囲 | 変更箇所に応じたパイプライン分岐ができているか |
| 履歴管理 | 大容量バイナリをGitで直接管理していないか |
| 権限設計 | モノレポ内の機密領域をアクセス制御できているか |
大規模リポジトリでは、上限緩和よりも「日々の運用速度」が重要です。上限に余裕ができたタイミングで、リポジトリ分割、Git LFS、パスベースのCI、不要履歴の棚卸しを検討すると効果的です。
Pull Request status checksにExternalバッジが追加
Pull Request status checksでは、外部のカスタムステータスポリシーをAzure DevOps標準のブランチポリシーと区別しやすくするため、Externalバッジが追加されました。これにより、ビルドや必須レビュアーなどの標準ポリシーと、外部システムが管理するステータスチェックの見分けがつきやすくなります。(Microsoft Learn)
この変更は、次のような現場で効果があります。
| よくある困りごと | 改善される点 |
|---|---|
| PRがブロックされているが原因が分からない | 外部ポリシー由来か標準ポリシー由来か判断しやすい |
| セキュリティスキャンや独自検証を外部連携している | どのチェックが外部管理か説明しやすい |
| レビュアーがブランチポリシーの詳細を知らない | PR画面上で確認できる情報が増える |
管理者は、Externalバッジの表示を確認したうえで、社内ドキュメントやレビュー手順書に「外部チェックが失敗した場合の問い合わせ先」を明記しておくとよいでしょう。たとえば、SAST、ライセンスチェック、独自品質ゲートを外部サービスで実行している場合、レビュアーがAzure DevOps管理者に問い合わせるべきなのか、ツール管理者に問い合わせるべきなのかを分けておくと対応が速くなります。
未解決コメントがPull Request一覧に表示される
Pull Request一覧では、未解決のコメントスレッドがあるPRを直接確認できるようになりました。未解決コメント数と全体のコメントスレッド数が「1 / 3」のように表示されるため、PRを開かなくてもレビューの残作業を把握しやすくなります。(Microsoft Learn)
この変更は小さく見えますが、レビュー運用には大きく効きます。特に、次のようなチームではメリットがあります。
- 1日に複数のPull Requestをレビューする
- レビューコメントの解消漏れが多い
- レビュアーと実装者が別タイムゾーンで作業している
- マージ前チェックをスクラムマスターやリードエンジニアが確認している
運用上は、「未解決コメントが0になってからマージする」というルールを明文化すると効果的です。ただし、すべてのコメントを機械的に解決済みにするだけでは意味がありません。設計判断や仕様確認など、後から参照したい議論は、Work itemやWikiに転記してから解決する運用にすると、レビュー履歴が知識として残ります。
GitHub Advanced Security for Azure DevOps：Security overviewが現状に近づく
GitHub Advanced Security for Azure DevOpsでは、削除済みリポジトリやAdvanced Securityが無効化されたリポジトリがSecurity overviewに表示されなくなりました。これにより、risk viewやcoverage viewには実際にスキャン対象となっているリポジトリが表示され、古い有効化状態に由来する不要な項目が残りにくくなります。(Microsoft Learn)
セキュリティ管理者にとって重要なのは、表示がすっきりすること自体ではなく、集計値の意味が変わる可能性がある点です。
| 変更前に起きやすい状況 | 変更後の確認ポイント |
|---|---|
| 削除済みリポジトリがSecurity overviewに残る | 件数が減った理由が削除・無効化によるものか確認する |
| Advanced Securityを無効化したリポジトリが混在 | スキャン対象外リポジトリの管理台帳を別途持つ |
| カバレッジ率が実態とずれる | レポート提出前に対象範囲を説明できるようにする |
失敗しやすいのは、「Security overviewに出ていない＝安全」と誤解することです。表示されないリポジトリには、削除済み、無効化済み、対象外など複数の意味があり得ます。監査や月次報告で使う場合は、Azure DevOps上の表示だけでなく、リポジトリ一覧、Advanced Securityの有効化状態、プロジェクトの棚卸し結果を突き合わせると安全です。
Azure Boards：Work itemコピーとGitHub連携APIが改善
Azure Boardsでは、Work itemコピー時のリンク選択が改善されました。従来は既存リンクを含める場合に親子リンクをまとめて扱う形でしたが、今回の更新で親リンクのみ、子リンクのみ、または両方を選択できるようになっています。(Microsoft Learn)
たとえば、既存のUser Storyをコピーして別スプリントで似た作業を作る場合、親Epicは維持したいが、子タスクまではコピーしたくないことがあります。今回の改善により、このようなコピー後のリンク修正作業を減らせます。
| コピーしたいケース | 選ぶとよい設定 |
|---|---|
| 同じ親Epic配下に類似作業を作る | 親リンクのみコピー |
| 子タスク構成も再利用したい | 子リンクもコピー |
| 完全に独立したWork itemとして作る | 既存リンクをコピーしない |
| 親子関係を維持してテンプレート的に使う | 親リンク・子リンクの両方を必要に応じて選択 |
一方で、Work itemをコピーしすぎると、過去のリンク関係や不要なタスクが残り、バックログが複雑になります。コピー後は、Area Path、Iteration Path、Assigned To、State、親子リンク、関連PRリンクを必ず確認しましょう。
また、GitHub Integration REST APIsでは、ユーザー認証にclassic OAuth tokensではなくGitHub App OAuth tokensが使われるようになります。変更後、ユーザーはGitHub接続の初回操作時に一度再認証を求められます。(Microsoft Learn)
APIや自動化を利用しているチームでは、次の点を事前に確認してください。
| 確認対象 | チェック内容 |
|---|---|
| API利用者 | GitHub接続を操作するユーザーに再認証が必要になる可能性を周知する |
| 自動化処理 | ユーザー操作前提のAPI呼び出しがないか確認する |
| エラー監視 | 認証関連エラーを検知できるようログを確認する |
| 運用手順 | 再認証URLが表示された場合の対応手順を用意する |
Azure Pipelines：Windows ARM64 agentがパブリックプレビューに
Azure Pipelinesでは、Windows 11向けのWindows ARM64 agentがパブリックプレビューとして利用可能になりました。これにより、ARM64ベースのWindowsマシン上で、Azure Pipelinesのセルフホステッドエージェントをネイティブに実行できます。(Microsoft Learn)
公式ドキュメントでは、Windows ARM64 agentはWindows 11のARM64環境向けプレビューとして案内されており、対象OSバージョンとしてWindows 11 26H1、25H2、24H2が記載されています。また、Azure DevOps ServicesまたはAzure DevOps Serverでは4.x agent softwareの利用が推奨されています。(Microsoft Learn)
導入を検討する場合は、いきなり本番パイプラインに組み込まず、次の流れで検証するのが現実的です。
| 手順 | 作業内容 |
|---|---|
| 検証環境を用意 | Windows 11 ARM64マシンを準備し、専用のAgent poolを作る |
| 依存ツールを確認 | ビルドツール、SDK、PowerShell、Subversion利用有無などを確認する |
| 小さいジョブで検証 | 単純なbuild、test、artifact publishから試す |
| x64環境との差分を見る | 実行時間、失敗するタスク、互換性問題を比較する |
| 本番適用範囲を限定 | ARM64向けビルドや検証用途から段階的に使う |
セルフホステッドエージェントでは、セキュリティ面の確認も重要です。公式ドキュメントでは、エージェントのフォルダーにはシークレットが含まれる可能性があるためアクセスを最小限に制限すること、エージェントを実行するIDには必要最小限の権限を与えることが推奨されています。(Microsoft Learn)
特に避けたいのは、個人用PCや共有端末を十分な分離なしにエージェント化することです。セルフホステッドエージェントはパイプライン定義からコードを実行する仕組みであり、権限設計を誤ると、ビルド環境経由で情報漏えいや意図しない操作が発生する可能性があります。
Azure Test Plans：手動テストのActual Result記録がプレビューに
Azure Test Plansでは、手動テスト実行時に各ステップのActual Resultを記録できる機能がパブリックプレビューとして追加されました。Actual Resultは、Pass/Failだけでは分からない実際の実行結果をステップ単位で残すためのフィールドです。監査、障害分析、不具合報告で「何が起きたのか」を説明しやすくなります。(Microsoft Learn)
設定はテストプラン単位で行い、すべてのスイートとテストケースに継承されます。モードはDisabled、Enabled – Optional、Enabled – Requiredの3種類です。(Microsoft Learn)
| モード | 内容 | 向いている場面 |
|---|---|---|
| Disabled | Actual Resultフィールドを表示しない初期状態 | 通常の簡易テスト、入力負荷を増やしたくない場合 |
| Enabled – Optional | フィールドは表示するが入力は任意 | 重要なステップだけ結果を残したい場合 |
| Enabled – Required | Expected Resultがあるステップで入力を必須にする | 監査対応、受入テスト、規制対応が必要な場合 |
設定手順は、対象プロジェクトのTest Plansでテストプランを開き、Test plan settingsからTest result settingsタブを選び、Use ‘Actual Result’ fieldを有効にしてRequiredまたはOptionalを選択します。(Microsoft Learn)
導入時の注意点は、進行中または一時停止中のテストランがある状態で設定を変えないことです。公式ドキュメントでは、設定変更前に進行中または一時停止中のrunがないことを確認するよう案内されています。設定変更中にrunが進行していると、開始時または再開時のロジックが適用され続ける場合があります。(Microsoft Learn)
実務では、いきなりRequiredにするより、まずOptionalで1〜2スプリント運用し、入力内容の粒度をそろえてからRequiredに切り替えるのがおすすめです。たとえば、次のような記録ルールを事前に決めておくと、テスターごとの差が出にくくなります。
| 記録対象 | 良い記録例 | 避けたい記録例 |
|---|---|---|
| 画面表示 | 「検索結果が10件表示され、先頭に商品Aが表示された」 | 「OK」 |
| 入力エラー | 「必須項目未入力時にエラーメッセージ『氏名を入力してください』を確認」 | 「エラー出た」 |
| API連携 | 「注文登録後、管理画面に注文ID 12345が作成された」 | 「登録できた」 |
| 不具合候補 | 「保存ボタン押下後、画面遷移せず500エラーが表示された」 | 「失敗」 |
Actual Resultは、単なるメモ欄ではなく、後から第三者がテスト結果を追跡するための証跡として使うと価値が出ます。
Azure DevOps Data Migration ToolとServer build numbersの確認
今回のリリースでは、2025年末にリリースされたAzure DevOps ServerバージョンからAzure DevOps Servicesへ移行するユーザー向けに、Azure DevOps Data Migration Toolの最新版が利用可能になったことも案内されています。(Microsoft Learn)
Azure DevOps ServerからAzure DevOps Servicesへ移行する場合、公式ドキュメントでは、移行前に重要資産、データサイズ、組織の複雑さを確認し、実移行前にテストランの時間を確保することが推奨されています。(Microsoft Learn)
Data Migration Toolは、中〜大規模の移行で使われる選択肢です。ただし、1つのAzure DevOps Server Collectionを1つの新しいAzure DevOps Services Organizationへ「lift and shift」する前提であり、移行中に構成を変更する用途ではありません。(Microsoft Learn)
移行担当者は、次の観点で事前確認を進めてください。
| 確認項目 | 内容 |
|---|---|
| 現在のServerバージョン | Azure DevOps Server Build Numbersで自社環境のBuildを確認する |
| 移行対象Collection | 1 Collectionを1 Organizationへ移す前提に合うか |
| プロセステンプレート | Hosted XMLやInheritedの扱いを確認する |
| データ量 | ソースコード、Work item、Test Plans、Artifactsの容量を棚卸しする |
| テストラン | 本番移行前に検証移行を行い、所要時間とエラーを確認する |
| 移行後作業 | ユーザー、権限、サービス接続、パイプライン、通知設定を確認する |
Server build numbersでは、Azure DevOps Serverのリリース日とBuild番号を確認できます。公式ページでは、2025年12月9日のAzure DevOps ServerがBuild 20.0.36719.1として掲載されています。(Microsoft Learn)
移行やアップグレードでよくある失敗は、「製品名だけ」でバージョンを判断することです。Azure DevOps Server 2022、2022.1、2022.2、再リリース版などではBuild番号が異なります。サポート問い合わせ、移行ツールの前提条件確認、障害切り分けでは、管理画面やインストール情報からBuild番号まで確認しておくとトラブルを減らせます。
変更の影響範囲をチーム別に整理
今回のAzure DevOps Released Featuresは、組織内の複数ロールにまたがって影響します。全員に同じ周知をするより、担当ごとに確認事項を分けると実行しやすくなります。
| 対象者 | 影響が大きい変更 | 取るべき行動 |
|---|---|---|
| Azure DevOps管理者 | GitHub連携API、Data Migration Tool、Server build numbers | 再認証の周知、Build番号の確認、移行計画の更新 |
| 開発者 | PR未解決コメント表示、Externalバッジ、Git object count limit削除 | レビュー完了基準を確認し、PR運用を見直す |
| セキュリティ担当者 | Security overviewの表示改善 | スキャン対象リポジトリと表示対象の差分を確認する |
| CI/CD担当者 | Windows ARM64 agentプレビュー | 検証用Agent poolを作り、互換性をテストする |
| QA担当者 | Actual Result記録 | Optional運用から試し、入力ルールを整備する |
| 移行担当者 | Data Migration Tool最新版 | テストラン、前提条件、Build番号を確認する |
展開前に使えるチェックリスト
社内でAzure DevOpsを本格利用している場合は、次のチェックリストを使って今回の変更を確認してください。
| チェック | 確認内容 |
|---|---|
| □ | Azure DevOps Services上で新機能が表示されているか確認した |
| □ | GitHub連携APIを使うユーザーに再認証の可能性を周知した |
| □ | Security overviewの対象リポジトリが実態と合っているか確認した |
| □ | 大規模リポジトリのclone時間、CI時間、不要ブランチを棚卸しした |
| □ | Pull Requestの未解決コメントをマージ前確認項目に加えた |
| □ | 外部ステータスチェックの問い合わせ先をレビュー手順に追記した |
| □ | Windows ARM64 agentを使う場合、検証用Agent poolを分けた |
| □ | セルフホステッドエージェントの実行ユーザーとフォルダー権限を確認した |
| □ | Actual Result機能をOptionalで試すテストプランを選んだ |
| □ | Required設定にする前に、進行中・一時停止中のテストランがないか確認した |
| □ | Azure DevOps ServerのBuild番号を記録した |
| □ | 移行予定がある場合、Data Migration Toolの前提条件とテストラン計画を確認した |
今回の変更で特に注意したい失敗パターン
今回の更新は便利な改善が多い一方で、運用ルールを整えないまま使うと混乱を招く可能性があります。
Git object count limit削除をリポジトリ管理不要と誤解する
上限削除は、大規模リポジトリにとって前向きな変更です。しかし、リポジトリ肥大化によるパフォーマンス課題やCI時間の増加まで解消するわけではありません。大容量ファイル、不要ブランチ、過剰な履歴保持は引き続き管理対象です。
Externalバッジを見ても問い合わせ先が分からない
Externalバッジで外部チェックだと分かっても、誰が管理しているか、どう直すかが分からなければレビューは止まります。外部ステータスポリシーごとに、管理者、参照ドキュメント、再実行方法を整理しておきましょう。
Actual ResultをRequiredにしてテスターの負荷を増やす
Actual ResultのRequired設定は、監査や受入テストでは有効です。一方、すべてのテストに必須入力を強制すると、テスト実行速度が落ちたり、形だけの入力が増えたりします。重要なテストプランから段階的に導入するのが現実的です。
Windows ARM64 agentを本番CIに急いで入れる
Windows ARM64 agentはパブリックプレビューです。プレビュー機能は仕様変更や制限があり得るため、まず検証用途で使うべきです。特に、既存のx64向けビルドツールやタスクがARM64環境で期待どおり動くかを確認してください。
まず何から対応すべきか
今回のAzure DevOps Released Featuresを受けて、最初にやるべきことは「自社で使っている機能だけを切り出す」ことです。すべての変更を一度に対応しようとすると、担当者が分散して進みません。
優先順位は次のように考えるとよいでしょう。
| 優先度 | 対応内容 | 理由 |
|---|---|---|
| 高 | GitHub連携APIの再認証周知 | ユーザー操作やAPI利用に直接影響する可能性がある |
| 高 | Test PlansのActual Result設定確認 | Required化するとテスト運用に影響が出る |
| 中 | Security overviewの表示差分確認 | セキュリティレポートの数値解釈が変わる可能性がある |
| 中 | PRレビュー運用の見直し | 未解決コメントやExternalバッジを活用できる |
| 中 | Windows ARM64 agentの検証 | 対象環境がある場合のみ有効 |
| 低〜中 | Git object count limit削除を踏まえたリポジトリ棚卸し | 大規模リポジトリでは有効だが緊急対応ではない |
| 移行予定がある場合は高 | Data Migration ToolとServer build numbersの確認 | 移行計画の前提条件に関わる |
Azure DevOpsは、Boards、Repos、Pipelines、Test Plans、GitHub Advanced Securityが密接に連携する開発基盤です。今回の変更も、単体の新機能として見るより、レビュー、セキュリティ、CI/CD、テスト、移行の運用を少しずつ改善する材料として捉えると効果が出ます。
まずは管理者が公式リリースノートと自社の利用状況を照合し、影響がある機能だけをチーム別に周知しましょう。そのうえで、PRレビュー手順、テスト記録ルール、エージェント運用、移行チェックリストを更新すれば、今回のAzure DevOps Released Featuresを安全に活用できます。
コメント