GitHubの休眠リポジトリ分析変更：初回検証と週次スキャンを分ける
静かなリポジトリの週次分析を開発活動の証拠と受け取ると、運用判断がずれます。実行数が減っただけで保護がなくなったと考えるのも早計です。
GitHubは2026年10月1日、code scanning default setupとGitHub Code Qualityの予約分析開始条件を変更しました。公式の事実と運用上の提案を分けて紹介します。
初回検証は続く
設定を有効化すると初回検証が実行され、結果が表示されます。週次分析はpushまたはpull requestが分析を起こした後に始まります。有効化前のGit活動ではなく分析履歴で判断します。
code scanningとCode Qualityは活動判断を共有します。Enterprise Cloudに適用され、Enterprise Server 3.24で対応予定です。GitHubは設定変更不要と説明しています。
設定と分析を別に記録
運用上は設定状態、最新の起因、コミット、結果時刻、担当者を別欄に記録することを提案します。有効化しただけで週次実行の証明にしないでください。
初回検証だけの保管用リポジトリは設定適用と初回確認を記録します。push・pull request分析は別の証拠として追加します。これはチームの記録案で、新しいGitHub状態名ではありません。
実行数の減少と脆弱性を分ける
分析回数の減少を安全性の点数に変えないでください。警告の有効性、解消状況、稼働サービスとの関係を確認します。
休眠リポジトリも本番ソースになり得ます。活動量から重要度を決めず、対象範囲、依存関係、担当者も点検しましょう。
小さな読み取り確認から
保守中と保管用を一つずつ選び、設定と分析履歴を読みます。初回検証とpush・pull request分析を区別できるか確認します。
確認目的の無意味なコミットや設定変更は不要です。実際の結果と文書が違えば環境・バージョンを記録します。図は点検順序の説明で、製品画面や実際の分析結果ではありません。