Microsoft Build 2026の公式発表でGitHub利用者がまず押さえるべき点は、脆弱性対応の中心が「検出したアラートを順に潰す」運用から、「本番で動いているコードの実リスクを優先して直す」運用へ寄っていることです。特にGitHub Code SecurityとMicrosoft Defender for Cloudの連携が一般提供となり、GitHub上のコードスキャンやDependabotの検出結果に、本番環境の露出状況や機密データの扱いといったランタイム情報を重ねて優先順位を付けやすくなります。Microsoftの発表では、MDASHの拡張プレビュー、DefenderとGitHub Code Securityのネイティブ統合、Copilot AutofixやGitHub Copilot cloud agentによる修正支援が主要な変更点として示されています。(Microsoft)
すぐに全リポジトリを移行する話ではありません。まず管理者は、GitHub Code Securityの有効範囲、Defender for Cloudとの接続、DCSPMの有効化、コードから実行環境への対応付け、Copilot Autofixの許可ポリシーを確認すべきです。開発者は、AIが生成した修正をそのままマージするのではなく、影響範囲・テスト・依存関係・本番リスクを見たうえでレビューする運用に変える必要があります。
GitHubのAI/Copilot更新で何が変わるのか
今回のGitHub関連の変更は、単に「Copilotが便利になる」という話ではありません。セキュリティアラート、AIによる修正支援、本番環境のリスク情報をつなぎ、開発ライフサイクル全体で脆弱性対応を進めやすくする方向性が強く出ています。
| 変更点 | 何が変わるか | 実務上の意味 |
|---|---|---|
| MDASHの拡張プレビュー | 複数モデルと多数のAIエージェントを使い、悪用可能性のある脆弱性の発見・検証を支援する仕組みが拡張プレビューとして提供される | まだ一般的な全社展開機能ではなく、対象組織向けの先行検証領域として扱う |
| Microsoft DefenderとGitHub Code Securityの統合 | GitHub上のセキュリティ検出結果に、本番環境の露出、機密データ、重要リソースなどのランタイム文脈を重ねられる | 「重大そうに見えるが本番に出ていない問題」と「外部公開中の本番サービスに直結する問題」を分けて対応しやすくなる |
| Copilot AutofixとGitHub Copilot cloud agent | 検出されたコードスキャンアラートや課題に対し、AIによる修正案やプルリクエスト作成を支援する | 修正の初動は速くなるが、レビュー、テスト、セキュリティ確認は引き続き人間側の責任になる |
| Security campaignsの活用 | 組織単位で重要なアラートをキャンペーン化し、開発者に修正を促せる | セキュリティチームが「全部直して」ではなく、対象・期限・担当を明確にして依頼しやすくなる |
Microsoftの公式発表では、MDASHは100を超える専門AIエージェントと複数モデルを組み合わせ、コードベース全体で悪用可能性を探索・検証する仕組みとして説明されています。一方で、GitHub Code SecurityとDefenderの連携は一般提供として示されており、日々の運用により近い変更点です。(Microsoft)
重要なのは「検出数」ではなく「本番で悪用される可能性」
従来の脆弱性管理では、GitHubのコードスキャン、Dependabot alerts、コンテナスキャン、クラウド側の推奨事項が別々に見られがちでした。その結果、次のような問題が起きます。
- CVSSが高いアラートから順に対応しているが、本当に本番影響があるか分からない
- 開発用依存関係の更新に追われ、本番公開APIの重大リスクが後回しになる
- セキュリティチームはDefender、開発チームはGitHubを見ており、同じ問題を別の言葉で管理している
- 修正依頼が抽象的で、どのリポジトリの誰が直すべきか分からない
今回のGitHub Code SecurityとMicrosoft Defender for Cloudの統合では、ソースコードと実行中のクラウドワークロードを関連付け、インターネット公開、機密データ、重要リソース、攻撃経路上の位置といった情報を優先度判断に使えるようにすることが狙いです。Microsoft Learnでも、この統合はGitHubのソースコードと稼働中のクラウドワークロードを結び、実際に本番へ届く脆弱性を優先しやすくするものと説明されています。(Microsoft Learn)
たとえば、同じ依存関係の脆弱性でも、次の2つは対応優先度が変わります。
| アラートの例 | 優先度の考え方 |
|---|---|
| 社内検証用ツールの開発依存関係に存在する脆弱性 | 影響範囲を確認しつつ、定期更新や次回スプリントで対応する余地がある |
| 外部公開され、顧客データを扱う決済APIのコンテナイメージに含まれる脆弱性 | 本番影響が大きいため、担当チームを決めて短期で修正・検証・再デプロイする必要がある |
この判断がGitHubの画面やSecurity campaignsに近づくことで、セキュリティチームと開発チームの会話が「危険そうだから直して」から「この本番ワークロードに紐づくこのリポジトリのこの依存関係を直して」に変わります。
影響範囲：対象になる組織と、すぐには影響しにくい組織
今回の更新で影響が大きいのは、GitHubを企業開発基盤として使い、Azureやコンテナ環境、Microsoft Defender for Cloudと組み合わせている組織です。特に、GitHub Code Securityを契約しているGitHub TeamまたはGitHub Enterprise Cloudの組織は、設定確認の優先度が高くなります。GitHubの公式ドキュメントでは、GitHub Code Securityはコードスキャン、CodeQL CLI、Copilot Autofix、Security campaigns、Dependabotの高度な管理、Dependency review、Security overviewなどを含む機能群として整理されています。(GitHub Docs)
| 組織・利用形態 | 影響度 | 確認すべきこと |
|---|---|---|
| GitHub Enterprise Cloudで多数のプライベートリポジトリを運用 | 高 | Code Securityの有効範囲、セキュリティ設定、キャンペーン運用、Copilot Autofixのポリシー |
| Azure上にAKS、コンテナ、Web APIなどを展開しDefender for Cloudを利用 | 高 | GitHub connector、DCSPM、コードとランタイムの対応付け、ランタイムリスクの反映 |
| GitHub Teamで一部リポジトリにCode Securityを導入 | 中 | 重要リポジトリから段階展開し、ライセンス利用量と設定テンプレートを確認 |
| 公開リポジトリ中心の個人・小規模OSS | 低〜中 | CodeQL、Dependabot、Copilot Autofixの利用可否とレビュー体制を確認 |
| GitHubを使っているがDefender for Cloudとは未連携 | 中 | まず連携の必要性を評価。すぐに全社導入するより、重要サービスでパイロットする |
注意したいのは、GitHubとDefender for Cloudの接続そのものと、GitHub Code Security統合による高度な優先順位付けは同じではない点です。Microsoft Learnでは、Defender for CloudとGitHub Advanced Security統合の前提として、GitHub connector、GHASライセンス、Defender Cloud Security Posture Managementの有効化、Azure側とGitHub側の権限が挙げられています。また、この統合は商用クラウド向けとされています。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者は、GitHub側とMicrosoft Defender側の両方を確認する必要があります。片方だけ整っていても、今回の更新の価値は出にくくなります。
GitHub側で確認すること
GitHub側では、まずGitHub Code Securityがどのリポジトリに適用されているかを確認します。GitHubのセキュリティ機能は、Security configurationsでリポジトリ単位に適用し、global settingsで組織全体の動作を制御する形に整理されています。公式ドキュメントでも、Security configurationsはリポジトリに適用できるセキュリティ機能の有効化設定の集合、global settingsは組織レベルの設定として説明されています。(GitHub Docs)
| 確認項目 | 見る場所の例 | 失敗しやすいポイント |
|---|---|---|
| GitHub Code Securityの有効範囲 | Organization Settings、Advanced Security、Configurations | 重要リポジトリだけ未適用、または不要なリポジトリまで有料機能を広げてしまう |
| CodeQL code scanning | リポジトリのSecurity and quality、Code scanning設定 | ビルドが必要な言語で解析が失敗し、アラートが出ていないのに安全と誤認する |
| Dependabot alertsとsecurity updates | Dependabot設定、dependency graph | private registryへアクセスできず、社内パッケージの依存関係が見えない |
| Copilot Autofixの許可設定 | Enterprise、Organization、Repositoryの設定 | AI修正を全面禁止・全面許可の二択にしてしまい、リポジトリの重要度に合わない |
| Security campaigns | OrganizationのSecurity and quality | キャンペーンだけ作り、担当者・期限・問い合わせ先を決めない |
| CODEOWNERSやチーム所有者 | リポジトリ設定、CODEOWNERSファイル | 生成されたIssueや修正依頼が実際の担当者に届かない |
Copilot Autofixは、コードスキャンアラートの説明と位置情報をもとに修正案を生成する機能です。GitHub Docsでは、GitHub Copilotのサブスクリプションがなくても、公開リポジトリやGitHub Code Securityを持つ組織の内部・プライベートリポジトリで利用でき、CodeQLを使うリポジトリでは既定で許可されると説明されています。管理者は、必要に応じてエンタープライズ、組織、リポジトリ単位で無効化できます。(GitHub Docs)
Microsoft Defender for Cloud側で確認すること
Defender for Cloud側では、GitHub connectorが正しく構成されているか、対象のGitHub organizationとリポジトリが見えているか、DCSPMが有効かを確認します。Microsoft Learnのクイックスタートでは、Azure portalのDefender for CloudからEnvironment settingsに進み、GitHub環境を追加してGitHubアプリをインストールし、組織やリポジトリを自動検出する流れが示されています。(Microsoft Learn)
| 確認項目 | なぜ重要か | 補足 |
|---|---|---|
| GitHub connector | GitHubのリポジトリ情報をDefender for Cloudに取り込む入口になる | 1つのGitHub organizationを複数Azureテナントへ重複接続しないよう注意 |
| DCSPMの有効化 | ランタイムリスクや攻撃経路の文脈を使った優先順位付けに必要 | 対象サブスクリプション単位で有効化状況を確認 |
| Security Admin権限とGitHub organization owner | 統合設定、表示、Issue生成、キャンペーン運用に関係する | 初期設定後は最小権限に寄せる運用も検討 |
| agentless scanning | リポジトリや成果物のスキャン・対応付けに関係する | 有効化後すぐに結果が出ない場合がある |
| コンテナイメージ、AKS、レジストリの監視 | コードからランタイムへの対応付けに必要 | ビルド成果物とデプロイ先が追跡できないと優先順位付けが弱くなる |
展開手順のドキュメントでは、環境設定後に結果が見えるまで最大24時間かかる場合があること、リソースをcriticalとして分類した後にDefender for CloudからGitHubへデータが送られるまで最大12時間かかる場合があることも示されています。設定直後に何も出ないからといって、すぐ失敗と判断しないほうがよいでしょう。(Microsoft Learn)
開発者が変えるべき日々の作業
開発者側の変化は、セキュリティ対応がGitHubの通常ワークフローにより入り込んでくることです。Security tab、Issue、Pull Request、Dependabot、Copilot Autofix、Security campaignsを別物として扱うのではなく、同じ修正サイクルの中で見る必要があります。
アラートは「重大度」だけでなく「本番文脈」で見る
GitHub Docsでは、production contextを使うことで、本番に承認・デプロイされた成果物に影響するDependabot alertsやcode scanning alertsを優先できると説明されています。Microsoft Defender for Cloud、JFrog Artifactory、CI/CDワークフローなどからのメタデータを使い、has:deploymentやruntime-riskのようなフィルターで本番影響のあるアラートを絞り込めます。(GitHub Docs)
開発者が実務で見るべき順番は、次のように考えると分かりやすくなります。
| 優先 | 見るべき条件 | 対応例 |
| -: | ——————— | —————————– |
| 1 | 本番デプロイ済み、外部公開、機密データあり | 速やかに担当者を決め、修正PR、テスト、再デプロイまで追跡 |
| 2 | 本番デプロイ済みだが外部公開なし | 攻撃経路や権限境界を確認し、スプリント内で対応 |
| 3 | 本番未デプロイだがリリース予定あり | リリース前のゲートとして修正 |
| 4 | 開発用、検証用、到達不能 | リスク受容、期限付き延期、または次回更新で対応 |
「高 severity だから最優先」ではなく、「本番で誰に何が起きるか」を含めて判断するのが今回の更新の肝です。
Copilot Autofixの修正案は必ずレビューする
Copilot AutofixやGitHub Copilot cloud agentは、修正の初動を速めるための機能です。GitHubのSecurity campaignsでは、コードスキャンアラートに対してCopilot Autofixが自動的に修正案を提示し、Copilot cloud agentへ割り当てることでプルリクエスト作成まで進められる場合があります。(GitHub Docs)
ただし、AI修正は「レビュー不要」の意味ではありません。特に次の点は必ず確認してください。
| 確認項目 | 見落とすと起きる問題 |
|---|---|
| 修正が根本原因を解消しているか | 入力検証や認可漏れを表面的に隠しただけになる |
| 既存仕様を壊していないか | セキュリティ修正が正常系の動作を変える |
| テストが追加・更新されているか | 同じ脆弱性が再発しても検知できない |
| 依存関係の更新範囲が妥当か | 互換性のないメジャーバージョン更新が混ざる |
| 機密情報がプロンプトやログに露出していないか | 修正作業中に別の情報漏えいリスクを作る |
AIが生成したPRは、通常のPRより軽く見るのではなく、むしろ「なぜこの修正で安全と言えるのか」を明文化する対象にしたほうが安全です。
移行・展開は一気に進めず、重要リポジトリから始める
今回の更新は、GitHubの利用方法を変える可能性がありますが、全リポジトリへ同時展開する必要はありません。GitHubの公式ドキュメントでも、GitHub Advanced Securityの大規模導入は、戦略の合意、準備、パイロット、内部ドキュメント作成、コードスキャン展開、シークレットスキャン展開という段階的アプローチで進めることが推奨されています。(GitHub Docs)
| フェーズ | やること | 判断基準 |
|---|---|---|
| 現状把握 | リポジトリ一覧、所有者、言語、デプロイ先、扱うデータ、GitHub Code Security適用状況を棚卸しする | 重要サービスと放置リポジトリを分けられるか |
| パイロット | 外部公開・顧客データ・高頻度リリースのいずれかに該当する少数リポジトリで試す | Defender側のランタイム情報がGitHub側のアラートに反映されるか |
| 設定テンプレート化 | Security configurations、CodeQL設定、Dependabot設定、Copilot Autofixポリシーを標準化する | 新規リポジトリにも同じ基準を適用できるか |
| 開発者向け運用整備 | Issueの受け方、AI修正PRのレビュー基準、キャンペーン対応期限を決める | セキュリティチームの依頼が開発作業に落ちるか |
| 段階展開 | 重要度の高いリポジトリから範囲を広げる | ライセンス、ビルド時間、アラート量、担当者負荷が管理できるか |
| 定着化 | 月次で未対応アラート、キャンペーン進捗、例外、再発傾向を見る | 「設定しただけ」で終わっていないか |
パイロット対象は、単に規模が大きいリポジトリではなく、本番影響が大きいリポジトリを選ぶのが重要です。たとえば、外部公開API、認証・決済・個人情報を扱うサービス、共通ライブラリ、CI/CDテンプレート、ベースコンテナイメージを管理するリポジトリは優先度が高くなります。
管理者・開発者が注意すべき落とし穴
GitHub Code Securityを有効にしただけでは優先順位は整わない
GitHub Code Securityを有効化しても、リポジトリの所有者、デプロイ先、成果物、ランタイム情報がつながっていなければ、アラートの山は残ります。今回の価値は、本番環境の文脈を使ってノイズを減らすことにあります。
まずは、リポジトリと本番サービスの対応表を作るべきです。最低限、リポジトリ名、サービス名、デプロイ先、担当チーム、扱うデータ、外部公開の有無、復旧目標、重要度を一覧化します。これがない状態でキャンペーンを作っても、担当者不明のIssueが増えるだけです。
Copilot Autofixを「自動修正ツール」と誤解しない
Copilot Autofixは、開発者の修正作業を支援する機能です。GitHub Docsでは、コードスキャン分析とコードベースの情報を使って潜在的な修正を生成すると説明されていますが、生成結果が必ず正しいとは限りません。(GitHub Docs)
特に、認可、暗号化、入力検証、SQLインジェクション、ログ出力、ファイル操作、外部API連携の修正では、仕様理解が必要です。AIが提示した差分を見て「テストが通ったからOK」とせず、脅威モデルに照らしてレビューしてください。
private registryや社内パッケージが見えていないと検出漏れが起きる
社内npm、NuGet、Maven、PyPI互換レジストリなどを使っている場合、Dependabotやコードスキャンが依存関係へ適切にアクセスできるか確認が必要です。GitHub Docsでも、private registryを使う組織では、code scanningやDependabotが安全にアクセスできるようにすることで分析や更新の範囲が広がると説明されています。(GitHub Docs)
「Dependabot alertsが少ない」ことは、必ずしも安全を意味しません。見えていない依存関係があるだけかもしれません。
商用クラウド以外や特殊なGitHub構成では可用性を確認する
Microsoft Learnでは、Defender for CloudとGitHub Advanced Security統合について、商用クラウドのみ利用可能で、Azure Government、Azure operated by 21Vianet、その他ソブリンクラウドでは利用できないとされています。(Microsoft Learn)
規制業界や国・地域に依存するクラウド環境を使っている場合は、発表内容だけを見て導入計画を作らず、自社テナント、リージョン、GitHub契約、Defenderプランで実際に使えるかを確認してください。
アラートの例外処理を決めないと、キャンペーンが形骸化する
Security campaignsは、重要アラートをまとめて開発者に届ける有効な方法です。GitHub Docsでは、キャンペーンを作成して開発者と協力し、セキュリティバックログを減らせると説明されています。(GitHub Docs)
一方で、例外処理のルールがないと、期限切れキャンペーンや放置アラートが増えます。次の項目は事前に決めておくべきです。
| ルール | 決める内容 |
|---|---|
| 修正期限 | criticalは何営業日以内、highは何スプリント以内など |
| 例外承認 | 誰が、どの条件で、いつまで延期を認めるか |
| 再評価 | 延期したアラートをいつ見直すか |
| 証跡 | リスク受容の理由、影響範囲、代替策をどこに残すか |
| エスカレーション | 期限超過時に誰へ通知し、どの会議体で扱うか |
どの組織から優先して対応すべきか
今回のGitHub更新は、すべての組織に同じ優先度で効くわけではありません。導入判断は、アラート数ではなく、ソフトウェアの事業影響で決めるべきです。
| 状況 | 優先度 | 推奨アクション |
|---|---|---|
| GitHub上のコードがAzure本番環境へ頻繁にデプロイされる | 高 | Defender連携とproduction contextの検証をすぐ始める |
| セキュリティアラートが多すぎて開発者が対応できていない | 高 | Security campaignsとランタイムリスクフィルターで対象を絞る |
| Copilot Autofixを使い始めているがレビュー基準がない | 高 | AI修正PRのレビューガイドを作る |
| CodeQLやDependabotが未整備 | 中 | 重要リポジトリからCode Security設定を標準化する |
| 個人開発や小規模OSS中心 | 低〜中 | まずDependabot、CodeQL、ブランチ保護、レビュー習慣を整える |
最も効果が出やすいのは、「本番サービスが多い」「アラートが多い」「担当チームが複数に分かれている」「Azureやコンテナ環境を使っている」組織です。この条件に当てはまる場合、GitHub Code SecurityとDefender for Cloudの連携は、単なるセキュリティ機能追加ではなく、開発チームとセキュリティチームの作業分担を見直すきっかけになります。
まず今日やるべき確認リスト
最初にやることは、機能をすべて有効にすることではありません。自社のGitHub運用が、今回の更新を受け止められる状態かを確認することです。
| 今日確認すること | 完了の目安 |
|---|---|
| 重要リポジトリの一覧を作る | 外部公開、顧客データ、基盤ライブラリ、CI/CD関連を区別できる |
| GitHub Code Securityの適用状況を見る | 重要リポジトリにCode Security、CodeQL、Dependabotが入っているか分かる |
| Defender for Cloudとの接続有無を確認する | GitHub organizationとAzureサブスクリプションの対応が説明できる |
| ランタイム情報がGitHub側に届くか確認する | production contextやruntime riskでアラートを絞れる |
| Copilot Autofixの扱いを決める | 許可範囲、レビュー責任、マージ条件が明文化されている |
| Security campaignsの運用責任者を決める | 誰がキャンペーンを作り、誰が進捗を見るか決まっている |
今回のMicrosoft Build 2026におけるGitHub関連の更新は、AIで開発を速くするだけでなく、AI時代の開発ライフサイクルを安全に保つための基盤整備と捉えるべきです。まずは重要リポジトリを10件程度選び、GitHub Code Security、Defender for Cloud、CodeQL、Dependabot、Copilot Autofix、Security campaignsが一連の流れとして機能するかを小さく検証してください。そこで得た設定、レビュー基準、例外ルールをテンプレート化してから全社展開するのが、もっとも失敗しにくい進め方です。
コメント