CodeQL の PR insights を追っているなら、今回の変更は見逃さないほうがいいです。2026年3月31日の GitHub changelog で、security overview 上の CodeQL pull request alerts／PR insights は、これまでの default branch 中心ではなく、全 protected branches を集計対象にできるようになりました。対象は 9 つのインサイトタイルと CSV 出力で、Copilot Autofix の効果や未解決のままマージされたアラートの実態を、より現場に近い形で見られるようになります。 (The GitHub Blog)
特に、main だけでなく release/* や hotfix/*、長期保守用ブランチまで保護している開発組織では恩恵が大きめです。今後は「default branch ではきれいに見えるのに、実際の運用ブランチでは対応が遅れている」というズレを、組織レビューや監査で見つけやすくなります。
CodeQL の PR insights で何が変わったのか
まず前提として、GitHub Advanced Security は GitHub Code Security と GitHub Secret Protection を含む製品群で、CodeQL、Copilot Autofix、security overview は GitHub Code Security 側の機能です。CodeQL pull request alert metrics は、組織や enterprise 全体で「PR 上で CodeQL がどれだけ脆弱性を止め、どう解消されているか」を確認するための画面です。 (GitHub Docs)
変更点を先に表で整理すると、次の通りです。 (The GitHub Blog)
| 項目 | これまで | 2026年3月31日以降 |
|---|---|---|
| 集計対象 | default branch のみ | 全 protected branches |
| 影響を受ける表示 | PR insights の 9 タイルと CSV | 同左 |
| Autofix の見え方 | 効果が過小評価されやすい | より代表的な数値になりやすい |
| 過去データ | 既存の見え方のまま | 遡って数値が大きく見える可能性あり |
ここでいう protected branches は、重要ブランチに対して承認レビューやステータスチェックの通過などを要求できる、いわゆる保護ブランチです。GitHub では branch protection rule によって、重要なブランチへの push や merge に条件を課せます。 (GitHub Docs)
実務上かなり大事なのは、2026年4月5日時点では docs の一部本文にまだ「default branches にマージされた PR を追跡する」説明が残っていることです。一方で 3 月 31 日の changelog は、PR insights が all protected branches を集計対象にしたと明記しています。数字の見え方が急に変わったときに「運用が悪化した」と即断せず、まず集計範囲の拡大を疑うべきです。 (GitHub Docs)
何が見えやすくなるのか
CodeQL の PR insights では、アラートの修正数、Copilot Autofix の有無ごとの修正状況、未解決のままマージされた件数、false positive や risk accepted として閉じられた件数、ルール別の発生傾向、修正率、平均修正時間などを確認できます。Copilot Autofix 関連の指標は、Autofix が有効なリポジトリでのみ表示されます。 (GitHub Docs)
今回の変更で見えやすくなるのは、単なる総数の増減ではありません。実際には次のような差が出ます。
| 見えやすくなるもの | 具体例 | 意味すること |
|---|---|---|
| default branch 以外での未解決マージ | release/2026.04 へ警告付き PR が取り込まれていないか | リリース運用の安全性が見える |
| Autofix の実利用 | hotfix 系ブランチで提案修正がどれだけ採用されたか | Copilot Autofix の投資対効果を判断しやすい |
| dismiss の偏り | 特定の保守ブランチだけ risk accepted が多くないか | 例外運用が常態化していないか確認できる |
| 修正速度の差 | main は速いが maintenance branch は遅い、という差 | チーム別・系統別の改善対象が見つかる |
GitHub の changelog でも、今回の拡張によって Autofix suggestions で修正されたアラート数が、より高く、より実態に近い数字になると案内されています。これは、default branch しか見ていなかったために、保護された release 系ブランチでの修正実績が埋もれていた組織ほど効きます。 (The GitHub Blog)
もう 1 つ重要なのが、過去データも遡って変わる可能性がある点です。GitHub は historical data が retrospective に変わることを明記しており、前月レポートや四半期レビューで「突然増えた」ように見えることがあります。これは悪化ではなく、集計母数が広がっただけのケースがあります。 (The GitHub Blog)
protected branches 全体のカバーが組織レビューに効く理由
GitHub の code scanning alerts は、PR 上で check 結果や annotation として表示され、Conversation タブや Files changed タブから確認できます。さらに、コードスキャンの alert に付いた会話も含めて、すべての会話を解決しないと merge できないよう protected branches 側で制御できます。 (GitHub Docs)
つまり、ブランチ保護と CodeQL の PR insights は本来セットで見るべきものです。main だけ厳しく、release/* では「あとで直す」が常態化している組織では、default branch だけの集計ではレビュー体制の弱い場所が見えにくいままでした。全 protected branches をまとめて見られるようになることで、どのブランチ群でレビューの質が落ちているのかを、運用実態に近い粒度で拾いやすくなります。
確認画面の導線も押さえておくと実務で迷いません。組織画面または enterprise 画面の Security and quality タブから、サイドバーの Metrics > CodeQL pull request alerts を開き、日付範囲やフィルターを指定して確認します。日付ピッカーは pull request alert の作成日ベースで集計し、CSV はその時点で表示している条件のままエクスポートできます。 (GitHub Docs)
フィルターも活用すると、単なる全体ダッシュボードで終わりません。security overview では、ビューごとに使える条件は異なるものの、repo:、自由検索、team:、topic: などは広く使え、enterprise レベルでは org: も使えます。 (GitHub Docs)
たとえば、こんな見方ができます。
repo:payments-apiで、重要リポジトリだけを追うteam:platformで、基盤チーム配下の改善速度を見るtopic:customer-dataで、機微データ系の repo 群だけに絞る- enterprise なら
org:commerceで、部門単位に比較する
この切り方ができると、「CodeQL を導入しているか」ではなく、どのチームの、どの保護ブランチ運用で、どの種類のアラート処理が詰まっているかまでレビューしやすくなります。
監査面での利点
GitHub の監査系ドキュメントでは、security overview、alert のタイムライン、audit log、API、webhooks を組み合わせて、セキュリティアラートへの対応を確認できるとされています。各 alert には履歴タイムラインがあり、作成や状態変更は原因を問わず時系列で記録されます。 (GitHub Docs)
さらに、PR 上の code scanning alert を dismiss するときのコメントは alert timeline に残り、監査や報告時の根拠として使えます。単に「閉じた」ではなく、「なぜ false positive と判断したか」「なぜ risk accepted としたか」を残せるので、レビュー会議や監査対応で説明しやすくなります。 (GitHub Docs)
今回の変更で protected branches 全体の数字が見えるようになると、監査での説明も現実に寄ります。たとえば「main はきれいだが、実際に出荷へ使う release ブランチでは未解決 merge が多い」という状態は、default branch だけの集計では説明しづらかったからです。
加えて、CodeQL pull request alerts ページの CSV エクスポート自体が audit/security log に記録されるのも地味に便利です。組織では org.security_center_export_code_scanning_metrics、enterprise 側では business.security_center_export_code_scanning_metrics として記録されるため、「誰が・いつ・どの条件でレポートを出したか」を追跡しやすくなります。 (GitHub Docs)
監査用途でおすすめなのは、月次または四半期ごとに次の 2 点をセットで残す運用です。
- CodeQL PR insights の CSV
- 例外的に dismiss した主要 alert の理由コメント
この 2 つを持っておくと、「全体傾向」と「個別判断の根拠」を分けて説明できます。
まず確認したい設定と見直しポイント
数字を見に行く前に、次の 4 つを確認すると空振りしにくいです。 (GitHub Docs)
| 確認項目 | 何を見るか | 実務上の意味 |
|---|---|---|
| protected branches の棚卸し | branch protection rule の対象ブランチ | main しか保護していなければ、今回の効果は限定的 |
| PR alerts の有効化状況 | Coverage view の code-scanning-pull-request-alerts | そもそも PR を見ていない repo を切り分けられる |
| 閲覧権限 | owner / security manager / write 権限の違い | 「見えていないだけ」を防げる |
| 比較期間の解釈 | date picker と historical data の扱い | 前月比の誤読を避けられる |
特に見落としやすいのが権限です。security overview は権限によって見える範囲が変わり、organization owner や security manager なら全 repo を見られますが、一般メンバーはアクセス可能な repo の範囲に制限されます。さらに、organization メンバー向けの organization-level security overview は、もっとも最近更新された 3,000 repo までに表示が制限される仕組みもあります。大規模組織で「集計が合わない」と感じたら、まずここを疑うべきです。 (GitHub Docs)
よくある誤解と注意点
数字が増えたからといって、運用が悪化したとは限らない
今回の changelog では、全 protected branches を含むことで数値がより代表的になり、しかも historical data が遡って変わる可能性があると説明されています。月次レポートで急増したように見えても、まずは仕様変更の影響を切り分けてください。 (The GitHub Blog)
protected branches 全体をカバーしても、個別 alert 画面の見え方まで同じとは限らない
個別 alert の詳細画面については、GitHub Docs 上で status と details は依然として default branch の状態を反映すると説明されています。非 default branch の状態は Affected branches で確認する形です。つまり、俯瞰メトリクスは広がったが、個票の確認ではまだ branch ごとの見分けが必要です。 (GitHub Docs)
Autofix の数字はどの repo でも必ず出るわけではない
Copilot Autofix 系の指標は、Autofix が有効なリポジトリだけに表示されます。Autofix を使っていない repo が多い組織では、「Autofix 効果が低い」のではなく、「そもそも対象 repo が少ない」ことがあります。 (GitHub Docs)
GitHub Advanced Security と GitHub Code Security の用語が混ざりやすい
最近の GitHub Docs では、GitHub Advanced Security は製品群の総称で、その中の CodeQL・Copilot Autofix・security overview は GitHub Code Security 側の機能として整理されています。運用資料や社内説明では、GHAS と GitHub Code Security を同義で雑に扱わないほうが混乱しません。 (GitHub Docs)
この変更を受けて、次にやるべきこと
CodeQL の PR insights が全 protected branches をカバーするようになったことで、GitHub の security overview はようやく「実際に守っている重要ブランチ群」に近い数字を返しやすくなりました。branch protection を本気で運用している組織ほど、この改善は効きます。 (The GitHub Blog)
まずやることは 3 つです。
- branch protection rule を棚卸しして、どの protected branches を本当に守っているか整理する。 (GitHub Docs)
- Security and quality から CodeQL pull request alerts を開き、同じ条件で CSV を出して、3 月 31 日以降の数字変化に注記を付ける。 (GitHub Docs)
- 重要アラートの dismissal comment と合わせて、月次レビューや監査証跡を残す。 (GitHub Docs)
これをやるだけで、「CodeQL を入れている」状態から、「どの protected branches で、どこまで効いているかを説明できる」状態へ一段進めます。
コメント