MicrosoftはAzure DevOpsのSprint 273アップデートをリリースし、大規模リポジトリ運用を妨げていたGitオブジェクト数の上限撤廃をはじめ、プルリクエスト（PR）レビューフローの改善や新しいWindows ARM64エージェントのパブリックプレビュー提供など、開発チームの生産性に直結する機能強化を一括して展開した。

Gitオブジェクト数上限の撤廃：モノレポ時代への対応

今回のアップデートの中で最もインパクトが大きいのが、Azure ReposにおけるGitオブジェクト数上限の完全撤廃だ。

従来、Azure DevOpsのリポジトリにはGitオブジェクト（コミット、ツリー、ブロブなど）の総数に制限が設けられており、長年にわたる開発履歴を持つ大規模リポジトリや、複数プロジェクトを一元管理するモノレポ構成では上限に引っかかるケースがあった。今回この制限が撤廃されたことで、リポジトリの成長を気にせず設計できるようになる。

フロントエンド・バックエンド・インフラのコードを単一リポジトリで管理するモノレポ戦略を取る組織や、CI/CDの履歴が膨大になったレガシーリポジトリを抱える企業にとって、この変更は実質的な制約から解放されることを意味する。

PRリストへの未解決コメント表示：レビュー漏れを防ぐ

これまでAzure DevOpsのPRリストでは、各PRの未解決コメントスレッドの状況がひと目では把握できず、レビューが完了しているのか、まだコメントが残っているのかを個別に開いて確認する必要があった。

Sprint 273ではPRリスト上に未解決コメントスレッドが直接ハイライト表示されるようになり、複数のPRを並行してレビューしているシニアエンジニアや、チームのPRステータスを管理するリーダーが一覧から状況を素早く把握できるようになった。

External バッジ：サードパーティステータスポリシーを明確に区別

PRのステータスチェックに関しても重要な改善が入った。これまで、Azure DevOps標準のブランチポリシー（ビルド検証や必須レビュアーなど）と、SonarQubeやSnykといったサードパーティ製の外部ステータスポリシーが視覚的に区別できず、PRがブロックされた際にどちらの原因かがわかりにくかった。

今回追加された「External」バッジにより、外部ツールによるステータスチェックが明示されるようになった。トラブルシューティングの時間短縮と、開発者の「なぜブロックされているのか」というフラストレーション解消に寄与する、小さいが確実に効く改善だ。

Windows ARM64エージェントのパブリックプレビュー

Azure PipelinesのセルフホステッドエージェントとしてWindows ARM64対応がパブリックプレビュー（Windows 11向け） として提供開始された。

Qualcomm Snapdragon搭載のSurface ProシリーズやCopilot+ PCが普及する中、ARM64ネイティブでビルドとテストを実行できる環境を整えたい組織にとって、待望の機能追加となる。特に、x64エミュレーション経由で発生するパフォーマンスロスを排除したい開発チームには試す価値がある。

その他の改善点

GitHub Advanced Security for Azure DevOpsでは、削除済みまたはAdvanced Securityが無効化されたリポジトリがセキュリティ概要ビューに表示されなくなった。無効なエントリが残り続けてリスクスコアが歪む問題が解消され、実際にスキャンされているリポジトリのみが対象として表示される。

Azure BoardsではWork Itemのコピー機能が改善され、親リンクと子リンクを個別に選択してコピーできるようになった。「親は同じにしたいが子は引き継がない」といったユースケースに柔軟に対応できる。

GitHub統合REST APIのセキュリティも強化され、旧来のOAuthトークンからGitHub App OAuthトークンへ移行。自動トークン更新が可能になり、手動での再認証が不要になった。

日本のエンジニア・IT管理者への実務的影響

Gitオブジェクト上限の撤廃は、特に長期間運用しているエンタープライズ向けリポジトリを持つ組織に恩恵が大きい。従来、上限回避のためにリポジトリを分割したり、historyを刈り込む運用をしていたチームは、その制約を前提とした設計を見直せる可能性がある。

PRレビューの可視化改善は、コードレビューをDevOpsプロセスの中核に置いているチームにとってすぐに活用できる変更だ。Externalバッジと組み合わせることで、「誰がなぜブロックしているのか」の説明コストが下がり、開発テンポが上がる。

Windows ARM64エージェントについては、現時点でパブリックプレビューのため本番環境への即時適用よりも検証環境での評価から始めるのが現実的だ。Copilot+ PCをエンジニアに支給している組織では、ビルド性能の比較検証を行っておく価値がある。

筆者の見解

Gitオブジェクト上限の撤廃は、地味に見えて実は大事な決断だと思う。スケーラビリティ上限というのはいつか必ず踏む地雷であり、「今はまだ大丈夫」と放置していると移行コストが膨らむ。これを先んじて取り除いたことは評価したい。

PRレビューの可視化改善や Externalバッジの追加も、現場の開発者の声をちゃんと聞いた改善に見える。GitHubのUXに慣れたエンジニアが「Azure DevOpsはわかりにくい」と感じがちだった部分を地道に削っている姿勢は正しい方向だ。

Windows ARM64エージェントについては、今後ARM64デバイスが開発機として本格普及した時に「対応済み」である重要性が増してくる。先手を打っていることは間違いなく、あとは正式リリースまでどれだけ丁寧にフィードバックループを回せるかが問われる。

Azure DevOpsはGitHubとの統合深化という大きな流れの中で、自分の立ち位置を再定義している最中にある。エンタープライズ向けの堅牢なデプロイ管理・ガバナンス機能という軸で磨き続ければ、必ず光る領域がある。Sprint 273のような地に足のついた改善の積み重ねが、その土台になると筆者は見ている。

出典: この記事は Azure DevOps Sprint 273 Update – Repository Git Object Limit Removal の内容をもとに、筆者の見解を加えて独自に執筆したものです。