Azure DevOpsとは？5サービスの機能・料金・GitHubとの使い分けを解説

Azure DevOpsは、Microsoftが提供するDevOpsライフサイクル統合型のクラウドサービスです。Boards（計画）・Repos（コード管理）・Pipelines（CI/CD）・Test Plans（テスト）・Artifacts（パッケージ管理）の5サービスをひとつの組織で運用でき、企業の開発プロセス全体をカバーします。

2026年に入ってからは、GitHub Advanced Security向けのCopilot Autofix限定パブリックプレビュー、Azure BoardsのGitHub Copilot連携でのCustom Agents対応、Enterprise Live Migrationsによる段階的なGitHub移行支援など、AI連携とハイブリッド運用を前提とした強化が一気に進んでいます。

本記事では、5サービスの機能・料金プラン・始め方・2026年のAIアップデート・GitHubとの使い分け・導入時に見落としやすい選定観点までを、2026年7月時点の公式情報で体系的に解説します。
これから新規導入を検討する企業も、既存のAzure DevOps環境をGitHub連携型に更新したい企業も、自社のフェーズに合う判断軸を持てる構成です。

Azure DevOpsとは

Azure DevOps（アジュール デブオプス）とは、Microsoftが提供する、DevOpsライフサイクル全体をカバーする統合クラウドサービスです。

SaaS型の「Azure DevOps Services」を主軸に、オンプレミス版の「Azure DevOps Server」も並行提供されています。

2026年現在、Azure DevOpsはGitHubとの分業運用を前提とした位置づけに再定義されつつあり、AI-native開発はGitHub、エンタープライズ規模のプロジェクト計画・進捗管理・リリースオーケストレーションはAzure DevOpsという分担がMicrosoft公式ブログで明示されています。

Boards・Repos・Pipelines・Test Plans・Artifactsの5サービス統合で提供され、AI連携強化・GitHub段階移行支援も2026年に一気に整備が進みました。

Azure DevOpsの成り立ち

Azure DevOpsは、Microsoftが2005年から提供してきた「Team Foundation Server（TFS）」を発展・分割して構成されたサービス群です。

2018年に現在の「Azure DevOps」ブランドへ統一され、SaaS版が主軸となる形で再編されました。

• Team Foundation Server時代（2005〜2017）
  オンプレミス製品として、コード管理・ビルド・作業項目管理を統合。企業内開発の標準として広く採用された
  
  

• Azure DevOps時代（2018〜）
  5サービスをブランド分割・SaaS化。GitHubとの並行運用を前提とした位置づけに再編

ここでのポイントは、20年近い運用実績を持つ既存資産と、GitHub時代の新しい選択肢が並列で残っているという点です。

TFS時代からの継続ユーザーは、Azure DevOps Serverでオンプレミスを続けるか、Azure DevOps Servicesへ移行するかの2択が現実的な選択肢になります。

Azure DevOpsを構成する5つのサービス

Azure DevOpsは、独立して利用できる5つのサービスから構成されています。全部をまとめて導入することも、必要なサービスだけを段階的に取り入れることもできる柔軟な設計です。

以下の表で、5サービスの役割と主なユースケースを整理しました。

この5サービスは連動して動きます。Boardsで積んだ作業項目をReposのブランチ・PRに紐付け、PipelinesがビルドとテストをドライブしてArtifactsにパッケージを吐き出し、Test Plansで検証結果まで管理する——一連の流れを1つの組織で追いかけられるのがAzure DevOpsの最大の価値です。

Boardsで作業項目とアジャイル管理を可視化

Azure Boardsは、スクラム・カンバン・独自プロセスに対応した作業項目管理サービスです。

エピック・フィーチャー・ユーザーストーリー・タスクの階層を扱え、バックログ管理・スプリント計画・バーンダウン・ダッシュボードまでを1つのUIで完結できます。

2025年以降の継続的な更新で、GitHubリポジトリを紐付けた場合の連携が強化され、ブランチ作成時に関連PRの自動リンク、マージ後のコミット反映、削除ブランチのリンク解除まで自動化されています。GitHubとAzure Boardsを組み合わせて使う構成では、Boards単体の作業管理より運用負荷が下がります。

Reposで無制限のプライベートGitを利用

Azure Reposは、Gitベースのソースコード管理サービスです。無制限のプライベートリポジトリを提供し、プル リクエスト・ブランチポリシー・コードレビュー・required reviewers・required build passなどのエンタープライズ運用機能を標準搭載します。

直近のアップデートでは、大量コメントが付いたPRでのフォーカス改善、ネストされたブランチ命名に対応するPRテンプレート適用、Git policy configuration APIのパフォーマンス改善などが継続されています。

旧Team Foundation Version Control（TFVC）にも引き続き対応しますが、新規案件では原則Gitを選ぶ運用が標準です。

PipelinesでマルチクラウドのCI/CDを構築

Azure Pipelinesは、あらゆる言語・プラットフォーム・クラウドに対応したCI/CDパイプラインサービスです。

YAMLでパイプラインを定義するモダン構成と、GUIでフロー編集するClassicの両方に対応し、Microsoft-hosted agent（Windows/Linux/macOS）とSelf-hosted agentの両方を組み合わせて使えます。

2025年以降、YAMLパイプラインからAzure Test Plansの自動テストを実行できる連携、包括的なコードカバレッジレポート、キャンセル・スキップされたステージの理由を明示するデバッグ支援などが順次追加されています。

GitHub Actionsとの二者択一というより、既にAzure Boards中心で回している組織にとってはPipelinesが手になじみやすい選択肢です。

Test Plansで手動・探索的テストを管理

Azure Test Plansは、手動テスト・探索的テスト・ユーザー受け入れテスト（UAT）の計画と実行を管理するサービスです。

テストケースをスイートにまとめ、テスト担当者に割り当て、ブラウザ拡張Test & Feedback経由でスクリーンショットや動画付きのバグ報告を作業項目として起票できます。

自動テストはAzure Pipelinesで実行するのが標準ですが、2025年5月のSprint 256以降はYAMLパイプラインをTest Plansから直接呼び出せるようになりました。手動テストと自動テストの実行結果を1箇所で確認したい組織に向く構成です。

Artifactsで社内向けパッケージを配布

Azure Artifactsは、NuGet・npm・Maven・Pythonといった主要パッケージ形式に対応したパッケージレジストリサービスです。

フィード単位でアクセス制御でき、社内向けの内製パッケージ配布と、外部OSSレジストリを「アップストリームソース」としてキャッシュする運用の両方に対応します。

2 GiBまで無料で、以降は階段状に単価が下がっていく従量課金です。CI/CDパイプラインから生成した成果物を直接プッシュし、他プロジェクトが依存として引き込めるため、モノレポで管理しきれない中〜大規模組織の内製ライブラリ流通基盤として機能します。

Azure DevOpsの2026年アップデートとAI連携

Azure DevOpsは、2026年に入ってからMicrosoftの戦略的な位置づけが再定義され、GitHub Advanced Security連携やCopilot連携の強化が集中して進んでいます。

ここ12か月の主要動向を押さえておくと、以降の「GitHubとの使い分け」や「導入時の落とし穴」を読み解きやすくなります。

以下の表で、2025年以降〜2026年7月の主要動向を整理しました。

個別のアップデートを機能単位で追うよりも、「AI連携の強化＝GitHub側」「エンタープライズ運用の統制＝Azure DevOps側」という役割分担が明確化した節目として理解するのが実務的です。

MicrosoftのGitHub／Azure DevOps分業方針

2026年6月2日、Microsoftは公式ブログ「Azure DevOps and GitHub: Journeying into the AI Era」で、GitHubを「AI-native開発プラットフォーム」、Azure DevOpsを「エンタープライズ・オーケストレーション層」と位置づける分業方針を明示しました。

同ブログには「Copilotやエージェント、新しいAIワークフローはGitHub上で最初に投入され、大規模に運用される（GitHub is where Copilot, agents, and new AI workflows ship first and run at scale）」との記述があり、AI機能はGitHubに先行投入される一方、Azure DevOpsにはCopilot Autofix・Copilot Code Review・remote MCP serverなどレビュー・セキュリティ・エージェント連携系のAI機能が限定的に展開される位置づけです。

Microsoft自身のCopilot, Agents, and Platforms（CAP）組織は、Build 2026で「6か月間で1,600以上のリポジトリと3,100人の開発者をAzure ReposからGitHubへ移行した」と公表しています。

移行対象リポジトリの約80%が完了しており、Microsoft自身が自社の推奨モデルを実行している状況です。

GHAS向けCopilot Autofixの登場

Microsoftは、Copilot Autofix for GitHub Advanced Security on Azure DevOpsを発表時点では限定プライベートプレビューとして提供開始し、その後Sprint 275（2026年6月）で限定パブリックプレビューまで展開範囲を広げました。

GHASのCodeQLが検出した脆弱性に対して、Copilot Autofixが自動で修正コードを生成し、既存のPRワークフローに乗せる形で修正提案を返します。

これまでのGHASは「検出まで」で、修正は開発者側の実装工数に依存していました。Autofixが入ることで検出から修正提案までの往復コストが下がり、SAST（静的解析）のROIが跳ね上がります。

GHAS Code Securityを既に契約しているAzure DevOps組織にとって、Autofix機能自体は追加ライセンスなしで利用できます。ただしFix生成の実行はGitHub AI Credits経由の従量課金として別途Azure請求に乗るため、有効化する対象リポジトリと生成頻度に応じたコスト管理は必要です。

Boards×Copilot連携でCustom Agents対応

Azure BoardsのGitHub Copilot連携自体はSprint 268でGA済みで、Sprint 269（2026年2月）でCustom Agentsの選択にも対応しました。

Work Itemの詳細画面からPRを作成する際、GitHub側で作成したカスタムAgent（リポジトリ単位・組織単位）を選択でき、そのAgentがコード変更とPR起票を担当します。

同アップデートでは、Azure DevOps→GitHubリポジトリの接続数上限も2,000リポジトリまで拡張されました。「Boardsで管理・GitHubで開発」のハイブリッド運用を大規模組織にも展開しやすい素地が整った形です。

関連するGitHub Copilot Coding Agentの導入と組み合わせることで、Boardsで積まれたユーザーストーリーを人間がPRとして起票する前段階から自動化するフローが構築可能になります。

ELMで段階的にGitHubへ移行

同じく2026年、MicrosoftはEnterprise Live Migrations（ELM）というプレビュー機能を発表しました。

**現時点の対象は「Azure DevOps Services → GitHub Enterprise Cloud with data residency」**で、Azure Reposに残っている大規模リポジトリ群を、開発チームの作業を止めずに段階的に移行するツールです。

従来のGitHub Enterprise Importer（GEI）が「一括切替型」だったのに対し、ELMは「複数リポジトリを一定期間並行運用しつつ移行完了時に切替」する運用に対応します。

数百〜数千リポジトリを抱える組織が「Reposを維持したままAI機能はGitHub側で活用したい」と考えたときの現実的な移行経路になります。

Azure DevOpsとGitHubの使い分け

Azure DevOpsとGitHubは、Microsoftが2018年にGitHubを買収して以降、同じ傘下の開発サービスとして並存しています。

2026年時点ではMicrosoft公式の分業方針に沿って、両者を組み合わせるハイブリッド運用が主流になりつつあります。ここでは、実際に選定・運用する際の判断軸を整理します。

以下の表で、Azure DevOpsとGitHubの位置づけを整理しました。

この分業を踏まえた実務上の使い分けは、「新規プロジェクトはGitHub中心・既存資産はAzure DevOps継続＋段階移行」の2軸で考えるのが現実的です。

新規はGitHub中心＋Boards補完が有力

これから新規プロジェクトを立ち上げる場合、AI-native開発の恩恵をフルに受けるにはGitHubを中心に据えるほうが有利です。GitHub Enterprise CloudでEntra ID等によりユーザー管理しているEnterpriseアカウントは、対象ユーザーがAzure DevOps Basic相当を追加ユーザー課金なしで利用できます（Azure Boards・Azure Repos・Azure Pipelines・Artifacts 2 GiB枠が対象。

Azure Test Plansの作成・管理を担当者に付与する場合は、別途Basic + Test Plansの$52/ユーザー/月が必要です）。

コード管理・CI/CD・AIコーディング支援はGitHub側で完結させつつ、大規模な作業項目管理やスプリント運用はAzure Boardsを流用する——このハイブリッド構成は、2026年以降の新規事業立ち上げで有力な選択肢になっています。

既存資産はAzure DevOps継続＋段階移行

すでにAzure DevOpsで数百〜数千リポジトリと数万件の作業項目を管理している組織にとって、一括移行は現実的ではありません。

既存ワークフローを止めずに、Azure Boards・Repos・Pipelinesはそのまま継続しつつ、AI機能が必要なリポジトリだけをGitHubへ順次移行する二段構えが推奨されます。

AI総研の支援現場でも、まずは「GitHub Copilotで最も効果が出るリポジトリ（テストが薄い・脆弱性リスクが高い・変更頻度が高い）」から先にGitHubへ移行し、残りをAzure Repos側に置いたまま段階移行するパターンが増えています。

ELMのようなライブ移行ツールが揃ってきた現在は、この二段構えが実行しやすくなっています。

Azure DevOps単独運用が合う組織

一方で、社外との共同開発が少なく、機密性の観点でクラウド接続を最小化したい組織や、「.NET」／Windowsベースのレガシー統合が濃い環境では、Azure DevOps単独運用が依然として合理的な選択肢です。

特にAzure DevOps Serverによるオンプレミス運用は、金融・防衛・公共のように厳格な要件を持つ現場で価値を発揮します。

GitHub側の主要なAI-native機能を諦めるトレードオフを受け入れられるかが判断の分かれ目です。
Copilot Coding AgentやGitHubエージェンティックワークフローのようなGitHub Issue/PR起点のワークフローを、Azure ReposのPR画面にそのまま持ち込めるわけではありません（端末側のCopilot CLIは別途利用可能です）。

この差分を運用でどう補うか（例: Azure OpenAIやMicrosoft Foundry経由の別ワークフロー整備）まで含めて設計しておく必要があります。

Azure DevOpsの料金

Azure DevOpsの料金は、ユーザーライセンス・Azure Pipelinesの並列ジョブ・Azure Artifactsのストレージ・GitHub Advanced Securityのコミッター数の4系統で構成されます。

組織単位で無料枠が用意されていて小規模ならほぼ無料で始められる一方、Test PlansやGHASを本格利用すると単価が跳ねるため、契約前に「どこから課金が始まるか」を押さえておくことが重要です。

以下の表で、Azure公式pricingにもとづく2026年7月時点の主要な料金体系を整理しました。

この表から見えるのは、基本利用は非常に安いが、Test PlansとGHASの2つが料金構造上の跳ねポイントという点です。

ユーザー数が20名程度でも、Test Plans契約者を10名混ぜるだけで月額$520を超えるため、テスト管理をどこまでAzure Test Plansで巻き取るかは早い段階で決めておく必要があります。

Basicプランと利害関係者ライセンスの使い分け

Basicプランは、Azure Boards・Azure Repos・Azure Artifacts（2 GiB枠）・Azure Pipelinesの主要機能を利用できるスタンダードなライセンスです。

開発者・PdM・スクラムマスターなど、実際に作業項目を作成・編集する人はBasicを付与します。

一方、進捗を眺めるだけの経営層や、レビュー観点で覗きに来る他部門メンバーは、無料の「利害関係者」ライセンスで足ります。

作業項目の閲覧・シンプルな編集・投票などが可能で、ダッシュボード共有にも十分に対応します。ここを見誤ってBasicを大量発行すると、料金が跳ねやすい構成になります。

Test Plansが必要なのは誰か

Basic + Testプランは月額$52/ユーザーとBasicの約9倍の単価です。

テストケースの作成・スイート管理・テスト実行結果の集計を担うQAリードや専任テスターに限定して付与するのが定石で、開発者全員にはBasicのままにしておきます。

GHAS課金は「コミッター数」に連動する落とし穴

GHAS for Azure DevOpsの料金は、Code Security $30・Secret Protection $19という単価だけを見ると手頃に感じますが、「対象リポジトリに直近90日のpushで含まれるアクティブコミッター数」に比例して跳ねる構造です（同一Azure subscription内では重複排除されます）。

開発者が100人在籍する組織で全リポジトリに一律有効化すると、月額$3,000（Code Security単体）が発生し得ます。

導入時は、まず「セキュリティリスクが高い主要リポジトリ」からスコープを絞って有効化し、CodeQLスキャンの検出量・Autofixの提案品質を見ながら対象を広げるアプローチが安全です。

全社一律よりも、リポジトリ単位のリスクベースの適用範囲設計を先に決めることを推奨します。

Azure DevOpsの使い方

Azure DevOpsは、Microsoftアカウントさえあれば数分で組織とプロジェクトを立ち上げられます。ここでは、はじめてAzure DevOpsを触るチームがゼロから運用に乗せるまでの手順を整理します。

前提条件と初期設計

Azure DevOpsを組織として使う前に、以下の点を先に決めておくと後戻りが減ります。

• Microsoft Entra ID（旧Azure AD）テナントを組織にアタッチするか、独立の組織として運用するか
• 組織名・プロジェクト名・リージョン（データ保存先）
• バージョン管理システム（原則Gitを推奨。旧TFVCは既存資産がある場合のみ）
• 作業アイテムプロセス（基本 / アジャイル / Scrum / CMMI）

特にEntra IDテナントとのアタッチは、後からSSO・SCIM連携やライセンス管理の統一に大きく効いてきます。

エンタープライズ運用を視野に入れているなら、最初からテナントに紐付けたほうが手戻りが少なくなります。

組織とプロジェクトの作成

dev.azure.comにアクセスし、Microsoftアカウントでサインインすると、初回はガイドに沿って組織を作成できます。組織URLは「https://dev.azure.com/<組織名>」となり、その配下に複数のプロジェクトを配置します。

プロジェクト作成時には可視性（Private / Public）、バージョン管理方式、作業アイテムプロセスを選びます。

一度作ったプロジェクトのプロセス変更は容易ではないため、アジャイル系（Basic / Agile / Scrum）とCMMIのどちらを採用するかは事前にチームで合意しておきます。

GitHubリポジトリとの接続

Azure BoardsをGitHubリポジトリと連携させる場合、Boardsのプロジェクト設定から「GitHub connections」でリポジトリを紐付けます。連携後は、作業項目に「#123」のような番号でGitHubのPR・コミットからリンクを張れるようになり、マージ時に作業項目のステータスが自動更新されます。

2026年のアップデートで接続上限が2,000リポジトリまで拡張されているため、大規模モノレポや多数のリポジトリを持つ組織でも一括接続が可能です。

Custom Agent連携を使う場合は、GitHub側でカスタムAgentを事前に作成しておく必要があります。

初回CI/CDパイプラインの構築

Azure Pipelinesは、YAMLで定義するモダン方式と、GUIエディタで組むClassic方式のどちらでも構築できます。新規案件では、履歴を追いやすくレビューにも乗せやすいYAMLパイプラインを推奨します。

最小構成のYAMLパイプラインの例です。

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'
    displayName: 'Install Node.js'

  - script: |
      npm ci
      npm run build
      npm test
    displayName: 'Build and test'

このYAMLをリポジトリ直下の「azure-pipelines.yml」として配置し、Azure Pipelines側で「Existing Azure Pipelines YAML file」から取り込めば、mainブランチへのpushをトリガーにビルドとテストが自動実行されるようになります。

初回はMicrosoft-hosted agent（無料枠1並列・月1,800分）で問題ありません。

並列度や実行時間が枠を超えるようになった段階で、追加並列ジョブの購入かSelf-hosted agentへの切替を検討します。

Self-hosted agentでCodeQLを使う場合の要件

セキュリティ強化を進める場合、プロジェクト設定からGHAS Code Security / Secret Protectionを有効化します。GHAS for Azure DevOpsはAzure DevOps ServicesのGitリポジトリ（Azure Repos Git）が対象で、Azure DevOps ServerやTFVCは対象外です。

前述のとおりコミッター数に連動して課金されるため、いきなり全リポジトリに適用するのではなく、機密度の高いリポジトリから段階的に広げるのが推奨です。

Azure DevOps選定で見落としやすい観点

Azure DevOpsを導入・拡張していく過程では、機能そのものよりも運用設計や料金の跳ねポイントで詰まるケースが多くあります。ここでは、AI総研の支援現場で頻出する3つの論点を整理します。

GitHub移行のタイミング判断

「今すぐGitHubへ全面移行すべきか」「Azure DevOpsを継続すべきか」の二択で悩むケースは多いですが、実務では「移行対象リポジトリの優先順位付け」から始めるほうが着地しやすい判断です。
すべてを一度に動かす必要はなく、AI活用の効果が最も出るリポジトリから移していきます。

判断軸として使いやすいのは、次の3つです。

• そのリポジトリの変更頻度（Copilotの効果は変更が多いリポジトリで最大化される）
• テストカバレッジの薄さ（Copilot Coding Agentによるテスト補完が効きやすい）
• 脆弱性リスクの高さ（GHAS＋Autofixの恩恵を受けやすい）

ELM（Enterprise Live Migrations）のような並行運用型ツールが揃ってきた現時点では、「1回で全部」ではなく「四半期ごとに20〜30リポジトリずつ」のペースで段階移行を進める設計が現実的です。

GHAS課金がコミッター数で肥大する構造の理解

前述のとおり、GHAS for Azure DevOpsはコミッター数に連動して課金されます。**リポジトリ数ではなく、そのリポジトリに直近90日のpushで含まれるアクティブコミッター数（同一Azure subscription内で重複排除）**が対象です。モノレポで多数の開発者が触れるリポジトリを1つ有効化するだけで、コミッター数が数百人に達することもあります。

導入前に、Azure DevOps側で有効化前に表示されるアクティブコミッター数の見積もりを確認しておき、月額予算内に収まるスコープでの有効化計画を先に立てておくと事故を防げます。

Pipelinesエージェントの選定軸

Azure Pipelinesのビルドエージェントは、Microsoft-hostedとSelf-hostedのどちらかを選びます。単純な単価だけを比較すると「$40/ジョブ」vs「$15/ジョブ」でSelf-hostedのほうが安く見えますが、エージェント運用の人件費とインフラコストを含めた総保有コスト（TCO）で比較する必要があります。

小規模チームや、テスト・ビルドがWindows/Linuxの標準環境で完結する組織は、Microsoft-hosted一択で十分です。Self-hosted agentを積極的に選ぶべきなのは、以下のようなケースに限られます。

• ビルドに数百GBの依存関係キャッシュや大容量アーティファクトが必要でMicrosoft-hostedの制約に収まらない
• 特殊なOS・アーキテクチャ（旧Windows Server・IBM Power等）が必要
• Azure仮想ネットワーク内の閉域リソースにビルド中アクセスが必要

「単価が安いから」を理由にSelf-hosted化して、実際には運用工数で毎月100時間以上を消費する組織も少なくありません。単価だけで判断しないことが重要です。

Azure DevOpsのハイブリッド運用を業務全体のAI化に広げる

Azure DevOpsは、5サービス統合による従来型のエンタープライズ運用の強みに加え、2026年以降はGitHub側のAI機能と組み合わせてハイブリッドに使う形をMicrosoftが強く打ち出しています。

開発プロセスへのAI導入を、コード生成や脆弱性検出にとどめず、要件定義から運用改善まで組織全体で回すには、部門横断の設計が要になります。

AI総合研究所では、PoCから全社展開までの手順、部門別ユースケース、AI運用の統制・セキュリティのチェックポイントを220ページにまとめた「AI業務自動化ガイド」を無料公開しています。

Azure DevOps × GitHub × Copilotの現実的なハイブリッド運用を設計する第一歩として活用ください。

Azure DevOpsとAI活用を業務に定着させる

PoCから全社展開までの設計を1冊で

Azure DevOpsに代表される開発基盤へAIを組み込む動きは、GitHub Copilot AutofixやCopilot Custom Agents連携などで一段加速しています。AI業務自動化ガイド（220ページ）では、PoC段階から全社展開までの進め方、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントを整理しています。

▶ 無料でダウンロード

まとめ

本記事では、Azure DevOpsの定義・5サービスの機能・2026年のアップデート・GitHubとの使い分け・料金・始め方・選定観点までを、2026年7月時点の公式情報で解説しました。要点を改めて整理します。

• Azure DevOpsはBoards・Repos・Pipelines・Test Plans・Artifactsの5サービス統合型で、DevOpsライフサイクル全体を単一プラットフォームで完結できるMicrosoft公式のエンタープライズ開発基盤
  
  

• 2026年6月にMicrosoftが「GitHub＝AI-native／Azure DevOps＝enterprise orchestration」の分業方針を明示。Copilot Autofix・Boards×Copilot連携（Custom Agents対応）・Enterprise Live Migrationsなど、GitHubとハイブリッド運用する前提の強化が集中して進んだ
  
  

• 料金はBasic $6/ユーザー・Test Plans $52/ユーザー・GHAS Code Security $30/コミッター・Secret Protection $19/コミッターの4系統。基本利用は安価だがTest PlansとGHASが跳ねポイント
  
  

• 新規プロジェクトはGitHub中心＋Azure Boards補完・既存資産はAzure DevOps継続＋段階移行のハイブリッド運用が、2026年時点で現実的な構成として広がりつつある。ELMのような並行運用型移行ツールが揃い、二段構えを進めやすい状況
  
  

• 選定で詰まりやすいのはGHAS課金のコミッター単位構造とSelf-hosted agentのTCO判断。単価の見た目より、コミッター数・運用工数を含めた実質コストで比較することが重要

Azure DevOpsは「単独で完結する開発基盤」から「GitHubと組み合わせてAIを組み込むハイブリッド基盤」へと役割を変えつつあります。新規なら最初からハイブリッド前提で、既存資産があるなら価値の高いリポジトリから段階移行で——自社のフェーズに合わせた設計を早めに整えることが、2026年以降のAI活用フェーズで開発生産性を差別化するポイントになります。