GitHub Advanced Security for Azure DevOpsを使っている組織にとって、今回のポイントは「CodeQLのコードスキャンアラートに対して、Copilot AutofixがAIによる修正案をPull Requestとして作成できるようになる」という点です。対象はAzure Repos上のリポジトリで、CodeQLによるcode scanningがすでに動いている環境です。
ただし、Copilot Autofix for code scanningは有効化すれば自動的に安全な修正が完了する機能ではありません。Microsoft Learnの公式情報では、生成される修正案はAIによる提案であり、正確性・完全性・安全性は保証されないため、レビューとテストが必須とされています。(Microsoft Learn)
この記事では、GitHub Advanced Security for Azure DevOpsに追加されたCopilot Autofix for code scanningについて、何が変わるのか、どのリポジトリに影響するのか、管理者・開発者が展開前に確認すべき設定や運用上の注意点を整理します。
Copilot Autofix for code scanningとは
Copilot Autofix for code scanningは、GitHub Advanced Security for Azure DevOpsのCodeQL code scanning alertsに対して、AIが修正案を生成する機能です。CodeQLが脆弱性やコーディング上の問題を検出した場合、Advanced Securityタブから修正案を生成し、Copilot coding agentが提案内容を含むPull Requestを作成します。(Microsoft Learn)
従来のcode scanningでは、開発者はアラートの内容、該当箇所、推奨事項を読み、自分で修正方針を考える必要がありました。Copilot Autofixでは、この「初期修正案を作る」工程をAIが支援します。
| 項目 | 従来のcode scanning | Copilot Autofix利用時 |
|---|---|---|
| アラート検出 | CodeQLが検出 | CodeQLが検出 |
| 修正案の作成 | 開発者が手動で検討 | AIが修正案を生成 |
| 変更の反映 | 開発者がブランチ・PRを作成 | copilot-autofix/... ブランチからPRが作成される |
| 最終判断 | レビュー・テスト後にマージ | レビュー・テスト後にマージ |
| 注意点 | 修正漏れや対応遅延が起きやすい | AI提案を過信すると不適切な修正を取り込むリスクがある |
重要なのは、Copilot Autofixは「自動修正を本番コードへ直接反映する機能」ではないことです。あくまでPull Requestとして提案されるため、通常のレビュー、CI、テスト、承認フローに乗せて判断します。
今回の変更点：CodeQLアラート対応の初動が速くなる
今回の更新で実務上大きいのは、セキュリティアラート対応の初動を短縮できる点です。
CodeQLのアラートは、SQLインジェクション、認証バイパス、危険な入力処理など、コードレベルの脆弱性を検出します。GitHub Advanced Security for Azure DevOpsのcode scanningはAzure Reposのコードを分析し、検出結果をAdvanced Securityタブにアラートとして表示します。(Microsoft Learn)
Copilot Autofixを使うと、対応可能なアラートに対して次のような情報を含むPull Requestが作成されます。
- 根本原因に対応するコード変更案
- 修正対象アラートの説明
- アラートID、重大度、変更内容の要約
- 必要に応じて、アラート箇所以外の関連ファイルを含む変更
特に効果が出やすいのは、開発チームが多数のアラートを抱えているケースです。すべてをゼロから調査するのではなく、AIが作ったたたき台をレビューできるため、修正方針の検討にかかる時間を減らせます。
一方で、生成された修正は必ずしも最小変更とは限りません。Microsoft Learnでも、提案は周辺コードの文脈を考慮するため、アラートが出た1行だけでなく、必要に応じて他ファイルへ変更が及ぶ場合があると説明されています。(Microsoft Learn)
影響範囲：Azure ReposとCodeQL code scanningが対象
Copilot Autofix for code scanningの対象は、GitHub Advanced Security for Azure DevOpsまたはGitHub Code Security for Azure DevOpsを有効化し、CodeQL code scanningを設定済みのAzure Reposリポジトリです。GitHub Advanced Security for Azure DevOpsはAzure Reposで動作する機能であり、GitHubリポジトリ向けのGitHub Advanced Securityとはドキュメント上も扱いが分かれています。(Microsoft Learn)
対象範囲を整理すると、次のようになります。
| 確認項目 | 対象になる条件 | 補足 |
|---|---|---|
| リポジトリ | Azure ReposのGitリポジトリ | Azure DevOps Services上のAzure Reposが前提 |
| セキュリティ機能 | GitHub Advanced Security for Azure DevOpsまたはGitHub Code Security for Azure DevOps | Code SecurityにはCodeQL scanningが含まれる |
| スキャン方式 | CodeQL code scanning | default setupまたはadvanced setup |
| アラート | 少なくとも1件のCodeQL code scanning alert | アラートがなければ修正案を生成する対象がない |
| 機能提供状態 | Limited public preview | 申請しても全員が利用できるとは限らない |
注意したいのは、Copilot Autofixがすべてのセキュリティ検出結果に対応するわけではない点です。CodeQL以外のカスタムクエリやサードパーティツール由来のアラートでは、修正案が生成できない場合があります。(Microsoft Learn)
管理者が最初に確認すべき設定
Copilot Autofixを展開する前に、管理者は「利用できる状態か」「誰が設定を変更できるか」「生成されたPRをどうレビューするか」を確認する必要があります。
GitHub Advanced SecurityまたはCode Securityが有効か
まず、対象リポジトリでGitHub Advanced Security for Azure DevOpsまたはGitHub Code Security for Azure DevOpsが有効になっているか確認します。
Microsoft Learnでは、GitHub Advanced Security for Azure DevOpsの機能として、Secret Scanning、Dependency Scanning、Code Scanningが説明されています。Code Securityには、依存関係アラート、CodeQL scanning、サードパーティツールのセキュリティ検出、Security overviewが含まれます。(Microsoft Learn)
Copilot Autofixはcode scanning alertsを前提にするため、少なくともCode Security相当の機能が必要です。
CodeQL code scanningが動いているか
次に、CodeQL code scanningが実際にアラートを生成できる状態か確認します。
Code scanningの設定には、主にdefault setupとadvanced setupがあります。default setupはパイプライン設定なしで自動構成され、既定ブランチを対象にスキャンします。advanced setupはAzure PipelinesにCodeQLタスクを追加し、対象ブランチ、ビルド手順、エージェントプール、カスタムクエリなどを細かく制御できます。(Microsoft Learn)
| 選び方 | default setupが向くケース | advanced setupが向くケース |
|---|---|---|
| 導入速度 | 早く始めたい | 初期設定に時間をかけられる |
| ブランチ対象 | 既定ブランチ中心 | 複数ブランチもスキャンしたい |
| ビルド制御 | 標準的な構成でよい | compiled languageのビルド手順を細かく制御したい |
| エージェント | 組織共通の設定でよい | 特定のエージェントプールを使いたい |
| クエリ | 標準クエリでよい | 特定のCodeQL query suiteやcustom queriesを使いたい |
多くのリポジトリではdefault setupから始め、ビルド制御やブランチ対象に不満が出た段階でadvanced setupを検討するのが現実的です。
Autofix for code scanning alertsをリポジトリ単位で有効化する
Copilot Autofixは、リポジトリごとのCode Security settingsで有効化します。公式手順では、Azure DevOps組織にサインインし、Project settingsから対象リポジトリを選び、Advanced SecurityセクションのCode Security featuresパネルで「Autofix for code scanning alerts」を選択して保存します。(Microsoft Learn)
展開時は、いきなり全リポジトリに広げるより、次のような順番が安全です。
- セキュリティ対応に慣れているチームのリポジトリで試す
- 既存のCodeQLアラートが少数で、影響範囲を追いやすいリポジトリを選ぶ
- Pull Requestレビュー、CI、テストが整っているリポジトリで検証する
- 生成された修正案の品質、レビュー工数、誤修正の傾向を確認する
- ルールを整備してから重要リポジトリへ展開する
プレビュー機能である以上、最初から全社標準として固定するより、検証期間を設けた段階導入が向いています。
開発者が使う基本手順
開発者がCopilot Autofixを使う流れはシンプルです。対象リポジトリで機能が有効化されていれば、Advanced Securityのアラート詳細画面から修正案を生成できます。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| アラートを開く | Repos > Advanced Security > Code scanningからアラートを選ぶ | Location、Description、Recommendationを先に読む |
| 修正案を生成 | Generate fixを選択 | 対応可能なアラートか確認する |
| PRを確認 | Related pull requestsまたはRepos > Pull requestsから開く | copilot-autofix/... ブランチ由来のPRを確認 |
| 差分をレビュー | Filesタブで変更内容を見る | 影響ファイル、例外処理、入力検証、テストへの影響を見る |
| 必要なら編集 | コード規約や設計に合わせて修正 | AI提案をそのまま通さない |
| マージ後に再スキャン | 次回code scanning runを確認 | 脆弱性が解消されればアラートが自動的に閉じる |
Microsoft Learnでは、Copilot Autofixが生成したPull Requestは通常のAzure Repos Pull Requestと同様に扱い、レビュー、編集、承認、完了の流れに乗せると説明されています。マージ後、次のcode scanning runで脆弱性が除去されていれば、アラートは自動的に閉じます。(Microsoft Learn)
対応言語とリポジトリ選定の考え方
Copilot Autofixは、CodeQLがcode scanningで分析する言語に対応します。公式情報では、C/C++、C#、Go、Java/Kotlin、JavaScript/TypeScript、Python、Ruby、Swiftが例示されています。(Microsoft Learn)
CodeQLのAzure DevOps向けドキュメントでは、言語識別子として次の値が示されています。(Microsoft Learn)
| 言語 | CodeQLの言語識別子 |
|---|---|
| C/C++ | cpp |
| C# | csharp |
| Go | go |
| Java/Kotlin | java |
| JavaScript/TypeScript | javascript |
| Python | python |
| Ruby | ruby |
| Swift | swift |
展開候補を選ぶときは、単に対応言語かどうかだけでなく、次の条件も見てください。
- 自動テストが十分にあり、修正案の副作用を検知しやすい
- Pull Requestレビューの責任者が明確
- CodeQLアラートの内容を理解できるメンバーがいる
- 本番影響の大きい認証、決済、個人情報処理などのコードでは慎重に試せる
- generated PRを処理する運用ルールがある
たとえば、JavaScript/TypeScriptのWebアプリで入力検証やXSS関連のアラートが出ている場合、Copilot Autofixは修正のたたき台として役立つ可能性があります。ただし、フロントエンドの表示仕様や既存のサニタイズ方針と合っているかは、人間が必ず確認すべきです。
権限設計で失敗しないためのポイント
Copilot Autofixの導入では、権限設計を軽視しないことが重要です。Advanced Securityには、アラート閲覧、アラート管理、設定管理に関する権限があります。
Microsoft Learnでは、Advanced Securityの主な権限として、アラートを表示する「Advanced Security: Read alerts」、アラートを却下・管理する「Advanced Security: Manage and dismiss alerts」、機能の有効化や無効化を行う「Advanced Security: Manage settings」が説明されています。特にManage settingsは課金につながる可能性があるため、付与には注意が必要です。(Microsoft Learn)
実務では、次のような分担が扱いやすいです。
| 役割 | 推奨権限の考え方 | 理由 |
|---|---|---|
| 一般開発者 | アラート閲覧、PRレビュー参加 | 修正作業に必要な情報を見られるようにする |
| リード開発者 | アラート管理、PR承認 | false positive判断や修正方針の決定を担う |
| セキュリティ担当 | アラート管理、横断レビュー | 重大度や対応優先度を判断する |
| 管理者 | 設定管理 | 機能有効化、課金、展開範囲を制御する |
避けたいのは、全員に設定管理権限を付ける運用です。プレビュー機能をリポジトリ単位で試したい場合でも、誰が有効化できるのか、誰が本番リポジトリへ展開してよいのかを明確にしておきましょう。
Pull Requestレビューで見るべきチェックポイント
Copilot Autofixが作成するPRは、セキュリティ修正の提案です。しかし、AIが生成した変更である以上、レビュー観点は通常の機能追加PRより少し厳しめに設定すべきです。
| チェック項目 | 見るべきポイント | よくある失敗 |
|---|---|---|
| アラートの根本原因 | CodeQLのRecommendationとPR差分が対応しているか | 表面的な条件分岐だけ追加し、根本原因が残る |
| 既存仕様への影響 | 正常系の動作が変わっていないか | セキュリティ対策で既存入力を過剰に拒否する |
| エラーハンドリング | 例外時のログ、レスポンス、再試行が適切か | エラーを握りつぶして障害調査が難しくなる |
| テスト | 脆弱な入力と正常入力の両方を確認しているか | アラートが消えても回帰テストが不足する |
| 変更範囲 | 関連ファイルの変更が妥当か | 影響範囲が広すぎてレビューしきれない |
| コード規約 | 命名、責務分離、既存パターンと合っているか | 一時的な修正が技術的負債になる |
特に、セキュリティ修正では「アラートが閉じること」と「安全な実装になっていること」は同じではありません。スキャン結果上は問題が消えても、別の入力経路や例外ケースで脆弱性が残る可能性があります。
レビュー時は、次の順で見ると判断しやすくなります。
- CodeQLアラートのDescriptionとRecommendationを読む
- PRの説明でアラートID、重大度、修正要約を確認する
- 差分がRecommendationの意図に沿っているか確認する
- 既存のテストを実行する
- 脆弱性を再現する入力と、正常な入力の両方を追加テストする
- 必要に応じてセキュリティ担当者をレビュアーに追加する
Microsoft Learnでも、生成された修正は出発点であり、マージ前にレビュー、テスト、必要に応じた追加レビュアー依頼を行うべきだとされています。(Microsoft Learn)
修正案が生成されない場合の見方
Copilot Autofixは、すべてのアラートに修正案を作れるわけではありません。公式情報では、修正案が利用できない例として、アラートタイプが未対応、Copilotがfalse positiveと判断した、カスタムクエリやサードパーティツールが生成したアラートである、といったケースが挙げられています。(Microsoft Learn)
修正案が出ない場合は、機能不具合と決めつける前に、次を確認してください。
| 状況 | 確認すること | 対応 |
|---|---|---|
| Generate fixが使えない | 対象アラートがCodeQL由来か | サードパーティ検出なら手動対応を検討 |
| 修正案が生成されない | 未対応のアラートタイプではないか | RecommendationとExampleをもとに修正 |
| false positiveの可能性がある | 実際に到達可能なコードか | セキュリティ担当と判断し、必要ならdismiss |
| custom query由来 | 標準CodeQLクエリか独自クエリか | 独自クエリのルール説明を整備 |
| PRが妥当でない | 仕様や設計に合っているか | PRを編集するか、手動修正に切り替える |
このとき、アラートをすぐにdismissするのは避けましょう。false positiveと判断するには、到達可能性、入力経路、既存の防御策、実行環境を確認する必要があります。
default setupとadvanced setupの展開上の注意点
Copilot Autofixはcode scanning alertsを前提にするため、CodeQL scanningの品質がそのままAutofix活用の質に影響します。
default setupは導入が早い一方、既定ブランチ中心のスキャンになります。advanced setupはAzure PipelinesにCodeQLタスクを追加するため手間は増えますが、複数ブランチ、特定のビルド手順、compiled languageのビルド制御、custom queriesなどに対応しやすくなります。(Microsoft Learn)
特に注意したいのは、compiled languageのビルドです。CodeQLのadvanced setupでは、Initialize CodeQL、独自のビルド手順、CodeQL Analysisの順にタスクを配置します。言語指定やビルドモードを誤ると、スキャンが失敗したり、期待した範囲を分析できなかったりします。(Microsoft Learn)
展開時の判断基準は次のとおりです。
| リポジトリの状態 | 推奨アプローチ |
|---|---|
| 標準的なWebアプリで、まずスキャンを始めたい | default setupから開始 |
| Java、C#、C++などでビルド手順が重要 | advanced setupを検討 |
| 複数ブランチを継続的にスキャンしたい | advanced setupを検討 |
| セキュリティチームがcustom queryを運用している | advanced setupを検討 |
| 既存CIの負荷が高い | 専用・複製パイプラインでのcode scanningを検討 |
Code scanningはビルド時間に影響することがあります。公式ドキュメントでも、code scanningタスクは時間がかかる可能性があるため、本番用メインパイプラインの複製や新規パイプラインへの追加が推奨されています。(Microsoft Learn)
PR運用とブランチポリシーをセットで見直す
Copilot Autofixを導入すると、セキュリティ修正用のPRが増える可能性があります。そこで重要になるのが、PR運用とブランチポリシーです。
GitHub Advanced Security for Azure DevOpsには、重大度がhighまたはcriticalの脆弱性がある場合にPull Requestのマージをブロックするstatus checksがあります。既存の重大・高リスク脆弱性すべてを対象にするチェックと、新規の重大・高リスク脆弱性を対象にするチェックが用意されています。(Microsoft Learn)
Copilot Autofixを展開する際は、次のような運用にすると混乱を減らせます。
- Autofix PRも通常のPRと同じレビュールールに通す
- high / criticalの修正PRにはセキュリティ担当者のレビューを追加する
- 生成PRのマージ可否はCI、テスト、CodeQL再スキャンの結果で判断する
- 既存アラートが多い場合は、まず「新規high / criticalを増やさない」方針から始める
- 自動生成PRが放置されないよう、担当者と対応期限を決める
セキュリティ対応では、「PRが作られたこと」より「安全にマージされ、再スキャンで確認されたこと」が成果です。Copilot Autofixは対応を速くする道具ですが、完了条件の定義はチーム側で整える必要があります。
管理者・開発者向けの導入チェックリスト
Copilot Autofix for code scanningを展開する前に、次のチェックリストを確認してください。
| 区分 | チェック項目 |
|---|---|
| ライセンス・対象 | GitHub Advanced Security for Azure DevOpsまたはGitHub Code Security for Azure DevOpsが有効 |
| リポジトリ | 対象がAzure ReposのGitリポジトリ |
| CodeQL | default setupまたはadvanced setupでcode scanningが動作 |
| アラート | CodeQL code scanning alertが存在 |
| プレビュー | Limited public previewであり、利用できない場合があることを関係者に説明済み |
| 権限 | Manage settingsを付与する対象を限定 |
| レビュー | Autofix PRのレビュー担当者と承認条件を定義 |
| テスト | セキュリティ修正を検証できるテスト方針を用意 |
| CI/CD | CodeQL実行時間やパイプライン負荷を確認 |
| ブランチポリシー | high / criticalの扱い、status checksの方針を決定 |
| 運用 | 修正案が出ないアラートの手動対応ルールを用意 |
このチェックリストを満たしていない状態で全社展開すると、「AIがPRを作ったが誰もレビューしない」「修正案が出ないアラートを放置する」「マージ後に仕様不具合が起きる」といった問題が起きやすくなります。
導入時にありがちな失敗
Copilot Autofixは便利な機能ですが、導入でつまずきやすいポイントがあります。
AI修正案をそのまま安全だと考えてしまう
最も危険なのは、AIが作った修正案を「公式機能が出した答え」と受け止めてしまうことです。公式情報では、AIモデルによる提案は正確性、完全性、安全性が保証されないと明記されています。(Microsoft Learn)
Copilot AutofixのPRは、レビューの出発点です。最終的な責任は、通常のコード変更と同じく開発チームと管理者にあります。
CodeQLの設定が不十分なままAutofixだけ有効にする
CodeQL scanningが適切に動いていなければ、Copilot Autofixの効果も限定的です。まずはスキャン対象ブランチ、言語、ビルド手順、アラートの見え方を確認しましょう。
たとえば、default setupで既定ブランチしかスキャンしていないのに、開発ブランチ上の問題も検出できていると思い込むと、対応漏れにつながります。
権限を広く付与しすぎる
設定変更権限を広く付与すると、意図しないリポジトリで機能が有効化されたり、課金・運用範囲が管理しづらくなったりします。Manage settingsは、展開責任を持つ管理者やセキュリティ担当に限定するのが無難です。
生成PRの担当者が決まっていない
Autofix PRが作成されても、誰が見るのか決まっていなければ放置されます。特に複数リポジトリで有効化する場合は、PR作成後の通知、担当割り当て、レビュー期限を決めておきましょう。
まず何から始めるべきか
Copilot Autofix for code scanningを導入するなら、最初にやるべきことは「対象リポジトリを絞った検証」です。
いきなり重要システム全体に広げるのではなく、CodeQL code scanningが安定して動作しており、テストとPRレビューが整っているリポジトリを1つ選びます。そこでCopilot Autofixを有効化し、実際に生成されたPull Requestの品質、レビュー工数、修正後のアラート解消状況を確認します。
そのうえで、次の3つを運用ルールとして明文化してください。
- Copilot Autofix PRを誰がレビューするか
- どの重大度のアラートから優先して対応するか
- 生成された修正案を採用しない場合、どのように手動対応・dismiss判断を行うか
Copilot Autofixは、セキュリティ修正を自動で終わらせる機能ではありません。CodeQLが見つけた問題に対して、初期修正案を素早く作り、通常のPull Requestプロセスで安全に検証するための支援機能です。
管理者は、対象範囲、権限、CodeQL設定、ブランチポリシーを確認しましょう。開発者は、生成された修正案を過信せず、アラートの根本原因、既存仕様への影響、テスト結果を見て判断することが重要です。まずは小さく試し、レビュー基準を整えてから段階的に展開するのが、Copilot Autofix for code scanningを安全に活用する近道です。
コメント