GitHub Advanced Security for Azure DevOps（GHAzDO）とは？機能・料金・使い方・本家GHASとの違いを解説

GitHub Advanced Security for Azure DevOps（GHAzDO）は、Azure ReposとAzure Pipelinesに、GitHub本家と同じシークレットスキャン・CodeQL・依存関係スキャンをネイティブ統合するアプリケーションセキュリティサービスです。

2025年6月にはGHAzDO向けにも、GitHub Secret Protection（$19/active committer/月）とGitHub Code Security（$30/active committer/月）のstandalone製品として購入可能になり、必要な機能だけを段階導入できる料金体系に変わりました。

本記事では、3つの検査機能の技術仕様、bundledとstandaloneの使い分けを含む料金設計、CodeQL default setup／advanced setupの有効化手順、GitHub本家GHASとの機能差分、そして2026年6月に始まったCopilot Autofix limited public preview を含む最新アップデートまで、Azure DevOpsを使い続けるチームの視点で体系的に解説します。

GitHub Advanced Security for Azure DevOpsとは？GHASのAzure Reposネイティブ実装

GitHub Advanced Security for Azure DevOps（GHAzDO）とは、GitHub Advanced Securityの検査機能をAzure DevOpsのGitリポジトリ・ビルドパイプラインにネイティブ統合したセキュリティサービスです。

従来「GitHubに移行しないとGHASの検査能力は使えない」という制約があった中で、Azure DevOpsを使い続けたまま同じ検査品質を得る選択肢として提供されています。

2026年現在、GHAzDOはMicrosoftが2023年10月にGA発表した後、2025年6月にGitHub Secret Protection・GitHub Code Securityの2つのstandalone製品を追加ラインアップした2製品体制へと発展しています。

これにより、Azure DevOps利用組織は「シークレット漏洩阻止」と「コード脆弱性対策」を個別に予算化できる構成が整いました。

対象はAzure DevOps ServicesのGitリポジトリのみ

GHAzDOはAzure DevOps Services（クラウド版・dev.azure.com）専用のサービスで、対象範囲が限定されています。
オンプレ版のAzure DevOps ServerやTFVCリポジトリでGHAS相当の機能を求める場合は別ソリューションの検討が必要です。

• Azure DevOps Server（オンプレ版）
  GHAS相当が必要ならGitHub Enterprise Serverへの移行または本家GHASの直接契約を検討
  
  

• TFVC（Team Foundation Version Control）
  Gitへの移行、またはSnyk・Checkmarx・Veracode等のサードパーティ製SASTツールを検討
  
  

• GitHub・他ベンダーのGitホスティング
  本家GHAS（GitHubリポジトリ対象）を直接契約。GitLab・Bitbucket等は各社の対応ツールを利用

ここでのポイントは、GHAzDOがAzure DevOps Services利用組織向けのGHAS相当ソリューションという明確なスコープを持つ、という点です。

3つの検査領域と料金体系は後段の「GHAzDOが提供する3つの主要機能」「GHAzDOの料金」セクションで詳しく整理します。

---

GHAzDOが提供する3つの主要機能

ここからは、GHAzDOの3つの検査機能を、実装レベルの仕様と検出できる脅威に落として整理します。

各機能はAzure DevOpsのProject settings → Repositoriesからリポジトリ単位で有効化でき、有効化権限は「Advanced Security: manage settings」を持つProject Collection Administratorまたはプロジェクト管理者に限定されます（有効化が課金アクションになるため）。

シークレットスキャンとPush Protection

シークレットスキャンは、リポジトリのコミット履歴を全ブランチ・全履歴にわたってスキャンし、200種類以上のシークレットパターン（AWSアクセスキー、Azure Storage接続文字列、Slackトークン、Stripeキー等）を検出します。

一方でPush Protectionは、プッシュされる直前のコミットをフックしてシークレットを検知した場合はプッシュ自体を拒否する予防的な機能です。

• リポジトリスキャン
  過去のコミットに埋め込まれたシークレット漏洩を発見する。有効化後、初回スキャンで既存のコミット履歴を全部走査する
  
  

• Push Protection
  新規プッシュに対して同期的にチェックする。検出された場合はプッシュがブロックされ、開発者はコミットの修正か「バイパス」でのプッシュ強行を選択する
  
  

• Secret validation
  一部のシークレットタイプについて、実際にAPIエンドポイントに問い合わせて有効性を確認する。有効なシークレットが漏洩したケースを優先的にアラート表示できる

Push Protectionのバイパスは、コミットメッセージに「skip-secret-scanning:true」を含めることで実施でき、バイパス操作は監査ログに残るため運用ルール整備が容易です（バイパス後もsecret scanningアラート自体は生成されます）。

Azure Key Vaultなどのシークレット管理サービスとの併用が前提で、GHAzDOは「漏洩の検知と予防」を、Key Vault側は「シークレット本体の安全な保管」を担う分担になります。

CodeQLによるコードスキャン

CodeQLは、GitHubが2019年に買収したSemmle社が開発した意味論的静的解析エンジンです。コードをデータベース化して独自のクエリ言語（QL）で脆弱性パターンを検索する仕組みで、パターンマッチ型SASTでは検出できない複雑なデータフロー起因の脆弱性を発見できます。

GHAzDOでCodeQLがサポートする言語は、Microsoft Learn公式によれば以下です。

言語	Default setup対応	Advanced setup対応
C#	✅	✅
Java	✅	✅
Kotlin	❌	✅
JavaScript／TypeScript	✅	✅
Python	✅	✅
Ruby	✅	✅
Rust	✅	✅
C／C++	❌	✅
Go	❌	✅
Swift	❌	✅

SwiftはCodeQLでも比較的新しく、2023年後半にAzure DevOps側でも対応が入りました。C／C++・Go・SwiftはDefault setup未対応のため、Advanced setup（YAMLパイプラインで明示的に「buildtype: none」またはカスタムビルドを指定する方式）が必要です。

検出結果は「code-scanning」「security-extended」「security-experimental」「security-and-quality」の4つのクエリスイート（ルールセット）から選択でき、まずはデフォルトのcode-scanningから始めて必要に応じてsecurity-extendedに広げるのが標準的な進め方です。

依存関係スキャン

依存関係スキャンは、リポジトリ内のパッケージマニフェスト（「package.json」／「package-lock.json」／「pom.xml」／「requirements.txt」／「Gemfile.lock」／「go.sum」等）を解析し、既知のCVE（Common Vulnerabilities and Exposures）に該当する脆弱なOSSコンポーネントを検出します。

Microsoft Learn公式の対応エコシステム表で挙げられているのは以下です。

• Cargo（Rust）
• CocoaPods（Swift）
• Go modules（Go）
• Gradle（Java）
• Maven（Java）
• npm（JavaScript）
• NuGet（C#）
• pip（Python）
• pnpm（JavaScript）
• RubyGems（Ruby）
• Yarn（JavaScript）

pnpm v9対応は2025年のSprint 253アップデートで扱われました（公式の対応バージョン表ではpnpmはv7・v8として掲載）。

重要な制約として、GHAzDOの依存関係スキャンはアラート表示までを担い、Dependabotのような自動更新PR発行機能は現時点で提供されません（この差分は「本家GHASとの機能差分」セクションで詳述します）。

---

GHAzDOの料金——bundledとstandaloneの使い分け

GHAzDOの料金は、2025年6月まで単一の「Advanced Security」バンドル製品のみでしたが、現在はSecret ProtectionとCode Securityを個別に購入できるstandalone製品が加わっています。

以下の表で、2026年7月時点の料金体系を整理しました。

プラン	月額単価	含まれる機能	想定シナリオ
Advanced Security（bundled）	$49／active committer	シークレット・CodeQL・依存関係の全部	3機能すべて使いたい既存契約
Secret Protection（standalone）	$19／active committer	Push Protection＋Secret scanning＋Security overview	シークレット検出のみ先に導入
Code Security（standalone）	$30／active committer	CodeQL＋依存関係スキャン＋Security overview	SAST・SCAだけ必要な場合

Secret ProtectionとCode Securityを両方買っても$19＋$30＝$49で、bundledと同額です。つまり「まずSecret Protectionだけ$19で試して、後からCode Securityを$30で足す」という段階導入がコスト的にも合理的な選択肢になりました。

Standaloneは新規契約者向けの提供で、既存のbundled契約者は現行の契約体系を維持できます。

もし既存契約者がstandaloneに切り替えたい場合は、Azure PortalのAzure DevOpsサポート経由で「Billing migration from bundled to standalone products」のチケットを起票する必要があり、この移行は不可逆です。

Active committer課金の仕組み

GHAzDOの課金単位はActive committerで、以下のロジックでカウントされます。

• 90日以内にGHAS有効リポにプッシュしたユーザーが対象
• コミット自体の日時ではなく、プッシュ時点で判定される（90日以前のコミットでもプッシュが直近90日なら対象）
• Azureサブスクリプション単位で重複排除される（同じユーザーが複数リポ・複数組織にプッシュしても1カウント）
• Standaloneでは製品ごとに別カウント（同じユーザーがSecret ProtectionとCode Securityの両方の有効リポにプッシュすると、$19と$30の両方が課金される）

Azure DevOpsのUIから見積もり数を事前確認でき、実際の課金量はAzureサブスクリプションの請求書で日次で反映されます。

「開発者数×単価×12か月」ではなく、「実際にプッシュした人数×単価×稼働月数」で計算するため、たとえば30人開発チームでも直近90日のプッシュが20人だけなら、実効課金は20人分に絞られます。

閉鎖案件で開発が止まったリポジトリは自然に課金対象から外れる設計です。

コスト最小化の実務的な考え方

Active committer課金は「使った分だけ払う」設計ですが、有効化するリポジトリを限定することでさらにコストを絞れます。

• 有効化対象を絞る
  組織内の全リポジトリを一括有効化せず、production系・機密データを扱う系だけ選択的に有効化する。実験用リポジトリを外すことで課金対象committer数を減らせる
  
  

• Standaloneで段階導入
  まずSecret Protection $19だけ全体展開してシークレット漏洩リスクを潰し、Code Security $30は段階的に対象リポを広げる
  
  

• Push Protection優先の運用
  Push Protectionで新規漏洩を止めつつ、既存のシークレット洗い出しは限定リポから段階的に実施する

この構成なら、単発の脆弱性検査ツールで数百万円を掛けるよりも、継続的にCVE・シークレット・コード脆弱性を検知しつづける仕組みを月次単価で得られます。

---

GHAzDOの有効化とパイプライン設定

GHAzDOは、組織・プロジェクト・リポジトリの3階層で有効化スコープをコントロールできます。有効化操作自体は数クリックで完了しますが、CodeQLコードスキャンだけはビルドタスクの追加が必要な場合があります。

3階層の有効化スコープ

有効化スコープは以下の3段階で設定します。

• 組織レベル
  「Organization settings → Repositories → Advanced Security」から、組織配下の全プロジェクト・全リポジトリを一括有効化する。大規模組織で個別リポジトリの取りこぼしを防ぎたい場合に有効
  
  

• プロジェクトレベル
  「Project settings → Repositories → Advanced Security」から、対象プロジェクト配下のリポジトリを一括有効化する。プロジェクト単位で本番用と検証用を切り分けている場合に使う
  
  

• リポジトリレベル
  「Project settings → Repositories → 個別リポジトリ → Advanced Security」から、リポジトリ単位で有効化する。課金対象を絞りたい場合の基本形

いずれの階層でも、有効化のクリック時にActive committerの見積もり数がポップアップ表示され、想定課金額を事前確認したうえで有効化を確定できます。

有効化権限は「Advanced Security: manage settings」を持つProject Collection Administratorまたはプロジェクト管理者に限定され、開発者ロール（Contributor）では有効化・無効化できません。

CodeQL Default setupで最小構成から始める

CodeQLコードスキャンには2つの設定方式があります。

• Default setup
  パイプライン設定を書かずに、「Project settings → Repositories → 対象リポジトリ → Advanced Security」から「Enable CodeQL default setup」チェックボックスをオンにするだけで有効化できる。対応言語（C#／Java／JavaScript／TypeScript／Python／Ruby／Rust）を自動検出し、週次スケジュールで既定ブランチをスキャンする
  
  

• Advanced setup
  YAMLパイプラインに明示的にCodeQLタスクを追加する方式。C／C++・Go・Kotlin・Swiftや、複数ブランチスキャン・カスタムクエリスイート・セルフホストエージェント利用が必要な場合はこちら

Default setupはSprint 268で private preview として提供が始まり、Sprint 275で public preview rollout が完了して全GHAzDO顧客が利用可能となりました。

多くのケースではDefault setupから始めて、要件が固まってきたらAdvanced setupへ移行するパターンで十分です。

リポジトリ設定でCodeQL default setupを有効化する画面（出典：Microsoft Learn）

同じ画面で「Block secrets on push」（Push Protection）と「Scan default branch for vulnerable dependencies」（依存関係スキャン）もチェックボックス1つで有効化でき、3つの検査領域の初期設定は数分で完了します。

Advanced setupでのYAMLパイプライン記述例

Advanced setupでは、Azure Pipelinesに以下の順序でタスクを追加します。

• 1. Advanced Security Initialize CodeQL（「AdvancedSecurity-Codeql-Init@1」）
  CodeQLデータベースの初期化とスキャン対象言語の指定を行う。「languages」パラメータで解析対象を指定（例：「csharp, java, python」）。セルフホストエージェント利用時は「enableAutomaticCodeQLInstall: true」で最新CodeQL Bundleを自動インストールできる
  
  

• 2. カスタムビルドタスク
  言語や構成に応じて、プロジェクトのビルド手順を明示するか、buildless scanning（「buildtype: none」）を指定する。Sprint 268でAutobuildタスクが廃止されて以降は、「buildtype: none」かカスタムビルドの二択
  
  

• 3. Advanced Security Perform CodeQL Analysis（「AdvancedSecurity-Codeql-Analyze@1」）
  初期化とビルドが完了したCodeQLデータベースに対してクエリスイートを実行し、脆弱性アラートをAzure DevOpsのAdvanced Securityタブに転送する

Microsoft Learn公式ドキュメントによれば、タスクの実行順序は「Init → ビルド → Analyze」で固定です。順序を入れ替えるとCodeQLデータベースの構築が正しく完了しません。

なお、2026年前半のSprint 268で**「AdvancedSecurity-Codeql-Autobuild@1」タスクが deprecated（非推奨）**となり、2026年3月1日で完全に動作しなくなることがアナウンスされました。従来Autobuildを使っていたパイプラインは「buildtype: none」（buildless scanning）またはカスタムビルドタスクへ移行する必要があります（詳細は「2026年の主要アップデート」セクションで扱います）。

ブランチポリシーと連携したPR gating

GHAzDOのアラートを「見つけたら修正する」だけでなく、「マージ前にブロックする」運用に組み込むにはブランチポリシーとの連携が有効です。

Azure Reposのブランチポリシーに「Status check」として「AdvancedSecurity/NewHighAndCritical」または「AdvancedSecurity/AllHighAndCritical」を追加すると、High／Critical severityのアラートが存在するPRの完了をブロックできます。

この機能はSprint 275でGA（General Availability）となり、preview段階よりも安定した運用が可能になりました。

設定手順は、公式ドキュメントの通り以下の順序で進めます。

• 1. Build validation policyを追加する
  先にCodeQL・シークレット・依存関係のいずれかのAdvanced Securityタスクを含むパイプラインをBuild validation policyに登録する。これがないとstatus checkのポリシー名が現れない
  
  

• 2. Advanced Securityタスクを1度でも成功させる
  初回パイプラインが成功してアラートを転送した時点で、「AdvancedSecurity/NewHighAndCritical」 や 「AdvancedSecurity/AllHighAndCritical」 がstatus checkとして選択可能になる
  
  

• 3. Status checkをブランチポリシーに追加する
  「Project settings → Repositories → 対象リポジトリ → Policies → Branch policies → 対象ブランチ → Status checks」から該当ポリシーを追加する

ブランチポリシーの「Add status policy」ダイアログでAdvancedSecurity/AllHighAndCriticalをStatus to check に指定する画面（出典：Microsoft Learn）

Policy requirementで「Required」を選択すると、High／Critical severityのアラートが解消するまでPR完了ボタンが押せなくなります。

加えて重要な移行注意点が2026年7月にあります。Sprint 275で「build service identityのAdvanced Securityアラート閲覧権限が削除される」ロールアウトが2026年7月1日開始・7月15日完了の日程で告知されました。

パイプライン内でbuild service accountがアラートを読んで独自にゲートを掛けるスクリプトを組んでいる組織は、この期間中に Advanced Security status checks 経由のGatingへ切り替える必要があります。詳細はSprint 275リリースノートを確認してください。

---

GHAzDOとGitHub本家GHASの機能差分（2026年版）

GHAzDOは「GHASのAzure Repos版」として位置づけられていますが、本家GHASと完全に同じ機能セットではありません。

同じ検査エンジン（CodeQL）を使っていても、GitHub側で提供される周辺機能の一部はGHAzDOでは未対応や機能限定になっています。

以下の表で、2026年7月時点の主要機能の対応状況を整理しました。

機能	GitHub本家GHAS	GHAzDO
シークレットスキャン（履歴＋Push Protection）	✅ GA	✅ GA
Secret validation	✅ GA	✅ GA
CodeQLコードスキャン（全対応言語）	✅ GA	✅ GA
CodeQL Default setup	✅ GA	✅ Public preview rollout completed（全顧客利用可）
依存関係アラート	✅ GA	✅ GA
Dependabot自動更新PR	✅ GA	❌ 非対応
Dependency review PR diff（リッチ表示）	✅ GA	簡略版のみ
Copilot Autofix	✅ GA	⏳ Limited public preview（2026年6月〜）
Secret scanning partner（公開リポ自動連携）	✅ GA	Azure Repos向けの対応
Security overview（組織ダッシュボード）	✅ GA	✅ GA
Work item linking（アラート↔Boards）	❌ GitHub Projects連携のみ	✅ GA（Azure Boards固有）
Service hooks（アラート外部連携）	Webhooks	✅ GA（Sprint 258）

この差分から読み取れる実務的なポイントは3つあります。

Dependabot自動更新PRの不在が最大の運用差

本家GHASでは、Dependabotが検出した脆弱な依存関係に対して、修正版へアップグレードするPRを自動発行してくれます。多くの中小規模チームがGHASの実効価値を「Dependabotで週次パッチが自動的に流れてくる仕組み」として認識しています。

一方でGHAzDOにはこの自動PR発行機能が現時点で存在しません。依存関係アラートは表示されますが、修正PRの発行は開発者側で手動対応する必要があります。この差は、脆弱性検出後の「修正までの時間」を大きく変えます。

Azure Pipelinesで独自の依存関係更新パイプラインを組む、あるいはRenovate等のサードパーティツールをAzure Reposに連携させて自動PR発行を補うのが現実的な回避策です。

Copilot Autofixが2026年6月からGHAzDOにも到来

「本家GHASにあってGHAzDOにない代表機能」として長く挙げられていたCopilot Autofix（CodeQLアラートに対するAIによる修正案自動生成）は、Sprint 275でlimited public previewとしてGHAzDOでも提供が始まりました（初期発表はDev Blog（当時は limited private preview 表記）、その後public previewに昇格）。

まだGA前のpreview段階ですが、GHAzDOと本家GHASの機能差は縮小する方向で動いています。Copilot Autofixの詳細な仕様と設定手順は「2026年の主要アップデート」セクションで扱います。

Work item linkingはむしろGHAzDO側の優位

差分は「GHAzDOが本家より劣る」ばかりではありません。Azure Boardsとの「Work item linking」機能はGHAzDO固有で、GHAS本家にはない機能です。

セキュリティアラートをそのままBoardsのWork itemに紐づけて、担当者アサイン・スプリントプランニング・優先度管理まで一気通貫で扱えます。

Azure DevOps + Boardsを既に業務プロセスに組み込んでいる組織にとっては、GitHub Enterprise Serverへの移行を渋る合理的な理由の1つになります。

---

2026年のGHAzDO主要アップデート

Azure DevOpsは3週間ごとにSprintリリースが行われ、GHAzDOも同じサイクルで機能追加・変更が入ります。2026年に入って特にインパクトが大きかったアップデートを、直近から順に整理します。

Copilot Autofix limited public preview（2026年6月〜）

CodeQL code scanningアラートに対して、AIが修正案を生成しPRを自動作成する機能です。

Microsoft Learn公式ドキュメントによれば、以下の仕様で提供されます。

• 有効化
  「Project settings → Repositories → 対象リポジトリ → Advanced Security → Code Security features」から「Autofix for code scanning alerts」チェックボックスをオンにする
  
  

• 使い方
  Advanced Securityタブの各CodeQLアラート詳細画面に「Generate fix」ボタンが追加され、クリックするとCopilot coding agentが分析を実行して「copilot-autofix/...」ブランチにPRを作成する
  
  

• 対応言語
  CodeQLが解析する全言語（C／C++、C#、Go、Java／Kotlin、JavaScript／TypeScript、Python、Ruby、Swift）
  
  

• 課金
  GHAzDOライセンスに含まれるが、fix生成にはGitHub AI credit（1 credit＝$0.01 USD）が別途消費される。Azureサブスクリプションのメーターで課金され、Cost Managementで日次確認できる

有効化のUIは以下のように、Code Security featuresパネル内の「Autofix for code scanning alerts」チェックボックスをオンにするだけです。

Code Security featuresパネルで「Autofix for code scanning alerts」を有効化する画面（出典：Microsoft Learn）

limited public previewのため、利用にはあらかじめアクセス申請が必要です。SLAは提供されず、preview中に仕様変更・機能削除の可能性があります。

有効化後、CodeQLで検出したアラートの詳細画面には「Generate fix」ボタンが追加されます。以下は「SQL query built from user-controlled sources」（cs/sql-injection、CWE-089）に対する実際のアラート詳細画面です。

CodeQLアラート詳細画面の右上に追加されるGenerate fixボタン（出典：Microsoft Learn）

ボタンを押すとCopilot coding agentがLocationのコードスニペットとDescription／Recommendationを分析し、「copilot-autofix/...」ブランチに修正PRを起こします。生成されたPRは以下のような形で、Descriptionに元アラートID・severity・fix詳細（例：「Replace 'pickle.loads' with 'json.loads' to safely deserialize the data」）が自動記載されます。

Copilot Autofixが自動生成した修正PR「Fix alert #306 for rule py/unsafe-deserialization」画面（出典：Microsoft Learn）

Autofixが生成したPRは通常のPRと同じ扱いで、レビュー・編集・追加テスト実施が必須です。「AI生成のfixは完全でも正確でも安全でもない」とMicrosoftも明示しており、Autofix結果の盲目的マージは避ける運用が前提になります。

CodeQL Autobuildタスクの完全削除（2026年3月1日）

Sprint 268で告知された通り、「AdvancedSecurity-Codeql-Autobuild@1」タスクは既に deprecated 扱いとなり、2026年3月1日で完全に動作を停止しました。

代替は、「AdvancedSecurity-Codeql-Init@1」タスクの「buildtype: none」（buildless scanning）指定またはカスタムビルドタスクの追加です。Autobuildを使い続けていたパイプラインは、パイプラインエラーで停止する前に移行対応が完了している必要があります。

もし自組織のパイプラインで「AdvancedSecurity-Codeql-Autobuild」の記述が残っていないかを確認していない場合、「.azure-pipelines/*.yml」ファイルへの「grep」で洗い出しておくことを推奨します。

CodeQLタスクのNode.js v24必須化

同じくSprint 268で、「AdvancedSecurity-CodeQL-Init@1」と「AdvancedSecurity-Codeql-Analyze@1」の両タスクがNode.js v24を必須とするように更新されました。

Microsoft-hostedエージェントは自動的にNode.js v24が導入されるため影響なしですが、セルフホストエージェント環境ではNode.js v24のインストールが必要です。旧バージョンのままではCodeQLスキャンが失敗するため、セルフホスト運用の組織はエージェントの棚卸しが必要になります。

CodeQL Default setup rollout completed（Sprint 275）

CodeQLのワンクリック有効化（Default setup）は、Sprint 268でprivate previewとして提供が始まり、Sprint 275でpublic preview rollout が完了して全GHAzDO顧客が利用可能となりました。承認申請フォームは不要で、「Project settings」のUIから「Enable CodeQL default setup」チェックボックスで即有効化できます。

Default setupの対応言語はC#／Java／JavaScript／TypeScript／Python／Ruby／Rustで、C／C++・Go・Kotlin・SwiftはAdvanced setupが必要な状態は変わりません。

Multi-repository publishing対応（Sprint 253）

やや古い変更ですが実務影響が大きいのが、Sprint 253で入った「パイプライン定義リポジトリとスキャン対象リポジトリが異なるケース」への対応です。

• パイプライン環境変数「advancedsecurity.publish.repository.infer: true」を指定すると、作業ディレクトリのリポジトリに正しくアラートを転送できる
• または「advancedsecurity.publish.repository: $[ convertToJson(resources.repositories['YourRepositoryAlias']) ]」で明示指定

複数リポジトリを1つのパイプラインで扱う構成（monorepo移行途中や共通ビルド基盤運用）では、この設定がないとアラートがパイプライン定義側のリポジトリに誤送信されます。

Service hooksがGA（Sprint 258）

セキュリティアラートイベント（新規作成／データ変更／状態変更）をservice hooksで外部システムに連携できる機能は、Sprint 253でpreviewとして提供が始まり、Sprint 258（2025年6月）でGA（general availability）に昇格しました。GA後は事前申請なしで利用でき、Slack通知・PagerDuty連携・カスタムSOAR連携等の実装ができます。

Build service identityのアラート閲覧権限削除（2026年7月1〜15日）

Sprint 269で一時的に導入と巻き戻しが繰り返された「build service identityのAdvanced Securityアラート閲覧権限制限」が、Sprint 275で正式に完全削除ロールアウトの開始が告知されました。2026年7月1日にロールアウト開始、7月15日に完了予定です。

これによりロールアウト完了後は、build service accountでアラートを読み取ってパイプライン内で独自ゲート判定するアプローチは動作しなくなります。パイプライン内でアラート閲覧APIを叩いてゲートを組んでいた場合は、Advanced Security status checks（「AdvancedSecurity/NewHighAndCritical」 / 「AdvancedSecurity/AllHighAndCritical」）に切り替える必要があります。

---

GHAzDOを選ぶべきケース／別ツールを検討すべきケース

ここまでの機能・料金・アップデート情報を踏まえて、AI総研の導入支援経験から、GHAzDOが第一候補になるケースと、他ツールを検討すべきケースを整理します。

GHAzDOを第一候補にすべきケース

以下に該当する組織では、GHAzDOはほぼ迷いなく採用できます。

• Azure DevOpsを今後も使い続ける方針
  GitHub移行の計画がない、または6か月以上先の場合、代替ツールと比較する時間ロスよりGHAzDO導入を先行させる方が実効的
  
  

• Azure Boards・Pipelinesとの業務プロセス連携が固まっている
  Work item linkingでアラート管理をBoardsに寄せる価値が大きい。GitHub Projects移行の学習・移行コストと相殺すると採算が合う
  
  

• Microsoft Defender for Cloud等のAzureセキュリティスタックを既に運用
  Defender CSPMでGHAzDOのシークレット検知をアタックパス可視化に取り込める。マルチベンダー統合の複雑さがない
  
  

• 課金予測をActive committerベースで組み立てたい
  CFO・情シス側で「開発者数×単価」の予算感が組みやすい。従来型SASTツールの「ライセンス本数買い切り」より柔軟

特にAzure DevOps + Boardsで開発プロセスが完全に回っている組織にとって、GitHub Enterprise Serverへの移行はセキュリティ機能だけを理由に決断するには重すぎる判断になりがちです。GHAzDOで暫定的にGHAS相当の検査品質を確保する選択が現実的です。

別ツールも比較検討すべきケース

以下のケースでは、GHAzDO単独ではなく他ツールとの比較・併用が必要になります。

• GHASの全機能（特にDependabot自動PR・Copilot Autofix GA）を業務クリティカルに使う予定
  Dependabot自動更新PRの不在は、依存関係パッチ運用の負荷を大きく変える。ここが決定的に重要ならGitHub Enterprise Cloudへの移行を検討する
  
  

• マルチプラットフォーム（GitLab・Bitbucket・Azure DevOpsが並存）
  GHAzDOはAzure Repos専用で、他プラットフォームには適用できない。統一ダッシュボード運用にはSnyk・Checkmarx・Veracode等のクロスプラットフォームSASTが有力な代替
  
  

• 予算制約が厳しくシークレット検出だけ必要
  Standalone Secret Protection $19を選択し、Code Security $30は導入見送り。開発者数が多いほどこの選択差は年間コストで数百万円単位の差になる
  
  

• オンプレAzure DevOps Server利用
  GHAzDOはServices（クラウド版）のみ対応。オンプレ運用ではサードパーティ製ツール（Checkmarx SAST・SonarQube＋Snyk等）が実質的な選択肢

特に「GitLab・Bitbucket・Azure DevOpsが並存する大企業」では、GHAzDOだけを選ぶと片肺運用になりがちです。Snykのようなクロスプラットフォーム型ツールで統一するか、各プラットフォームでネイティブツールを個別導入するかは、体制側の意思決定として整理してから選ぶことをお勧めします。

Snykとの比較——GHAzDOで足りる場合と足りない場合

Snykは代表的なクロスプラットフォーム型のアプリケーションセキュリティツールで、SAST・SCA・コンテナスキャン・IaCスキャンを50言語以上でカバーします。以下の表で、Azure DevOps環境における主な比較軸を整理しました。

比較軸	GHAzDO	Snyk
対応プラットフォーム	Azure DevOps専用	Azure DevOps・GitHub・GitLab・Bitbucket
SAST基盤	CodeQL（意味論的解析）	Snyk Code（AI-powered）
SCA reachability分析	未対応	対応（実行到達性まで判定）
依存関係の自動修正PR	未対応（要Renovate等併用）	Snyk自動fix PR
Azure Boards Work item linking	ネイティブ対応	別連携で対応（Snyk API & WebのAzure DevOps Boards同期）
IDE統合	Azure DevOpsのUI	VS Code・JetBrainsプラグイン
課金モデル	Active committer	開発者ライセンス

Azure DevOps単独運用ならGHAzDOで十分ですが、マルチプラットフォームで統一ダッシュボードを求める場合はSnyk優位です。両方併用も可能で、Snykで開発者フィードバックを速くし、GHAzDOでAzure DevOpsのPRゲートを回す使い分けもあり得ます。

Defender for Cloudとの統合パターン

Microsoft Defender for CloudのDefender CSPMは、Azure DevOpsリポジトリで検出されたシークレット漏洩を「クラウドリソースへの攻撃パス」として可視化できます。

たとえば「Azure DevOpsリポジトリに漏洩したAzure Storage接続文字列 → Storage Account → 機密データ漏洩」というアタックパスをグラフで表示し、影響範囲を経営層に説明しやすい形にできます。GHAzDOで検出したシークレットに対して、Defenderが「実際にアクセス可能なリソース」まで含めて評価する構造です。

Azureセキュリティスタック全体で運用している組織なら、GHAzDO単体よりも「GHAzDO + Defender for Cloud」の組み合わせでROIが最大化しやすい構成になります。

---

開発チームのDevSecOpsから組織のバックオフィス自動化へ

GHAzDOでAzure ReposのDevSecOpsを整えると、Advanced Security・コードスキャン・シークレット検出まわりの開発者側の統制は前進します。次に問題になるのは開発チームの外側——経理・請求書処理・営業バックオフィス・情シスなど、組織全体の業務をAIエージェントに任せていく段階です。

DevSecOpsの土台と、バックオフィス業務のAI Agent運用は同じ製品では解けるわけではありません。組織側では、Teamsから呼び出す業務Agentと、権限・実行ログ・監査を一元管理する基盤を別途持つ設計が現実的になります。

AI総合研究所のAI Agent Hubは、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。Teamsから呼び出す9種の業務Agent(経費申請・請求書受領・AI-OCR・自動入力等)と管理ダッシュボードで、バックオフィス側の自動化を担う位置づけになります。GHAzDOで整えた開発チーム側の統制と並走させて、組織側の業務レイヤーもAIに寄せていきたい場合の選択肢の1つです。

AI総合研究所の専任チームが、Microsoft MVP・Solution Partner認定の実績をもとに、バックオフィス業務エージェント基盤の設計から運用まで伴走支援します。AI Agent HubのLPで、組織側の業務Agent運用の全体像をご確認ください。

---

まとめ

本記事では、GitHub Advanced Security for Azure DevOps（GHAzDO）について、機能・料金・使い方・本家GHASとの差分・2026年アップデート・導入判断まで解説しました。

GHAzDOは、シークレット・CodeQL・依存関係の3系統検査を Azure Repos／Azure Pipelinesにネイティブ統合する唯一の選択肢で、Azure DevOpsを継続利用する組織にとって「GitHub本家GHASと同じ検査品質」を得るための第一候補です。

2025年6月からのGHAzDO向けstandalone製品化により、Secret Protection $19だけを先行導入して段階拡大するコスト設計が可能になりました。Active committer課金は開発規模に応じて費用が自然に上下する仕組みで、従来型SASTのライセンス本数買い切りより柔軟です。

本家GHASとの機能差は縮小傾向で、特に2026年6月からのCopilot Autofix limited public previewはGHAzDOと本家の乖離を埋める重要なアップデートです。一方でDependabot自動更新PRは現時点で未対応のため、依存関係パッチ運用はRenovate等の併用が現実的です。

導入判断では、Azure DevOps + Boardsで開発プロセスが完全に回っている組織はGHAzDO第一候補で、マルチプラットフォーム運用や本家GHAS全機能が必要な場合のみSnykやGitHub Enterprise Cloudを比較する構図になります。本記事の情報を土台に、自社のリポジトリ数・開発者数・GitHub移行方針を踏まえて具体的な採用判断に活用してください。