3行まとめ
このテーマをもう少し広げて見るなら、Copilot CLIに/security-reviewが公開プレビュー：CodeQL・Secret scanningと併用する確認ポイント と GitHubの第三者コーディングエージェント安全検証が一般提供：CodeQL、依存関係、Secret scanningの確認ポイント も合わせて確認してください。定期的なcode scanningとは別に、開発者が変更前に実行できる軽量レビューを確認できます。
6カ月以上pushやpull requestがないリポジトリを、30日ごとに自動スキャンできるようになります。
対象はcode scanningのdefault setupを使うリポジトリです。advanced setupや外部CIは同じ前提で扱いません。
対象リポジトリ、GitHub Actions、GitHub Code Security、通知先、tool status pageをまとめて確認します。
この機能は古いリポジトリの見落としを減らす助けになりますが、アラートを受け止める運用とセットで判断します。
- GitHubは2026年6月9日、6カ月以上pushやpull requestがないリポジトリを30日ごとに自動スキャンできるperiodic code scanningを告知しました。
- 対象はcode scanningのdefault setupを使うリポジトリです。advanced setupや外部CIでCodeQLを運用しているリポジトリまで同じ設定で扱う話ではありません。
- 組織管理者は、Settings > Advanced Security > Global Settingsの設定だけでなく、対象リポジトリ、GitHub Actions、GitHub Code Security、通知先、tool status pageでの確認までセットで見る必要があります。
GitHub code scanningの新機能として、非アクティブリポジトリを30日ごとに自動スキャンする設定が追加されました。対象になるのは、GitHubのChangelogで説明されている通り、6カ月以上pushやpull requestがないリポジトリです。組織に長く触っていないコードベースが残っている場合、コード変更がなくても、新しいCodeQLクエリや解析改善によって見つかる問題を拾いやすくなります。
ただし、この設定を「古いリポジトリを全部守ってくれる自動監査」と読んでしまうと危険です。今回の設定は、code scanning default setupを使うリポジトリに適用されます。advanced setup、外部CIからのSARIFアップロード、所有者不明の退役予定リポジトリは、別に棚卸しが必要です。
この記事では、2026年6月10日JST時点で確認できるGitHub公式情報をもとに、GitHub TeamやGitHub Enterprise Cloudで複数リポジトリを管理する読者向けに、何を有効化前に見るべきかを整理します。直近のGitHub Security文脈としては、第三者コーディングエージェントの安全検証を扱った前回記事と近い領域ですが、今回の主題はエージェントではなく「長く動いていないコードベースの継続スキャン」です。
inactive repositories向けperiodic code scanningとは
- 16カ月以上活動なし
pushやpull requestがない状態が入口です。アーカイブ済みや退役済みを自動判定する意味ではありません。
- 230日ごとにスキャン
新しい変更レビューとは別に、静止したコードベースを定期的に再評価します。
- 3解析改善を反映
CodeQLのクエリや解析エンジンの更新により、同じコードでも新しいアラートが出ることがあります。
- 4重要度は別に判断
非アクティブでも、社内ツール、古いサービス、配布済みライブラリなどは利用が残っている場合があります。
inactive repositoriesは低リスクの同義語ではありません。活動履歴と業務重要度は分けて見ます。
GitHubのChangelogは、今回の対象を「6カ月以上pushやpull requestがないリポジトリ」と説明しています。ここで大事なのは、非アクティブという言葉をアーカイブ済み、削除予定、使っていない実験用コードと同じ意味に広げないことです。GitHubが示している条件は、少なくともChangelog上では活動履歴に基づくものであり、リポジトリの業務重要度や退役状態を自動判定するものではありません。
6カ月以上pushやpull requestがないことが入口
長期間変更されていないリポジトリは、開発チームの目に入りにくくなります。新しいpull requestがないため、通常のレビュー導線でcode scanningのアラートを見直す機会も減ります。今回の30日周期スキャンは、こうした静止したコードベースを定期的に再評価するための設定です。
運用上は、対象リポジトリを「古いから低リスク」とは見ないほうがよいでしょう。社内ツール、サンプル、古いサービス、過去に配布したライブラリなどは、開発頻度が下がっても参照や利用が残ることがあります。コードが動いていなくても、脆弱性情報や解析ルールは更新されます。
30日ごとのスキャンは新規変更レビューとは目的が違う
default setupのcode scanningは、通常、push、pull request、週次スケジュールなどのタイミングでCodeQL分析を走らせます。今回の機能は、長期間活動がないリポジトリにも30日ごとのスケジュールスキャンを維持するためのものです。
この違いはアラート対応で効いてきます。現役リポジトリでアラートが出た場合は、直近の変更やpull requestを起点に原因を追えます。一方、非アクティブリポジトリで新しいアラートが出た場合、コード変更ではなく、CodeQL側の改善、クエリ追加、対応言語の変化、既存コードの再解析がきっかけになっている可能性があります。
古いコードを再評価する意味
セキュリティ担当にとって、この機能の価値は「誰かが触ったから検出する」だけでなく、「誰も触っていないものも再評価する」点にあります。古いリポジトリは、所有者が変わり、通知先が曖昧になり、依存関係やデプロイ状況の記録も薄くなりがちです。
そのため、30日周期スキャンを有効にするなら、アラートを受ける人、対応できる人、対応しない判断を記録する人を先に決めておく必要があります。スキャンを増やすだけでは、古いコードのリスク管理は終わりません。
確認ポイント
- 6カ月以上pushやpull requestがないリポジトリがどれだけあるか。
- その中に、公開リポジトリ、配布済みライブラリ、稼働中サービスのコードが含まれるか。
- 所有者が不明なリポジトリでアラートが出た場合、誰が一次判断をするか。
default setup限定という条件を先に確認する
同じcode scanningでも、設定方式によって見る場所と責任範囲が変わります。
今回のChangelogで最も見落としやすいのは、対象がdefault setupを使うリポジトリに限られる点です。GitHub Docsでは、code scanningにはdefault setupとadvanced setupがあると説明されています。default setupは、GitHub側がリポジトリ内のコードをもとにCodeQLの設定を自動作成し、低い運用負荷で有効化できる方式です。
default setupは低運用でCodeQLを使う入口
default setupは、リポジトリごとに細かいCodeQLワークフローを書かず、GitHubが標準的な分析設定を管理する方式です。GitHub Docsによると、default setupではCodeQL対応言語を対象に、default branchやprotected branchへのpush、対象branchに向けたpull request、週次スケジュールなどで分析されます。
今回の30日周期スキャンは、このdefault setupの延長として読むのが自然です。組織内でdefault setupを広く使っている場合、長く動いていないリポジトリにも継続スキャンをかける意味があります。
advanced setupや外部CIは同じ扱いにしない
advanced setupでは、CodeQLワークフロー、ビルド手順、言語、クエリ、実行タイミングを細かく設定できます。外部CIでCodeQL CLIや第三者の静的解析ツールを動かし、SARIFをGitHubにアップロードする運用もあります。これらは、default setupのGlobal Settingsと同じ前提で扱えません。
たとえば、重要なサービスだけadvanced setupにしていて、古いリポジトリはdefault setupという組織もあります。逆に、古いけれど重要なリポジトリだけ独自CIに残っている場合もあります。今回の設定を有効にする前に、対象リポジトリがどのsetup typeかを確認してください。
eligible repositoriesの条件を見る
GitHub Docsのdefault setup at scaleでは、default setup対象になるリポジトリの条件として、advanced setupが有効ではないこと、GitHub Actionsが有効であること、publicであるかGitHub Code Securityが有効であることが示されています。ここを飛ばすと、組織設定を有効にしたのに期待したリポジトリがスキャンされない、というズレが起きます。
GitHub Code SecurityやGitHub Actionsの利用条件は、組織契約やリポジトリ種別で変わります。この記事では費用増を断定しません。管理者は、自社の契約、Actions利用状況、Code Securityの有効化範囲を、請求画面や組織設定で確認する必要があります。
対象判定の順番
- そのリポジトリは6カ月以上pushやpull requestがないか。
- code scanning default setupを使っているか。
- advanced setupや外部CI運用ではないか。
- GitHub Actionsが有効か。
- publicリポジトリか、GitHub Code Securityが有効な組織所有リポジトリか。
- CodeQL対応言語が含まれるか、今後含まれる可能性があるか。
組織のGlobal Settingsで何を確認するか
設定の有効化だけでなく、どの検出強度で、誰が、どのリポジトリを受け持つかを同時に決めます。
GitHub Changelogでは、今回の設定場所としてSettings > Advanced Security > Global Settingsが示されています。トグル名は「Keep scheduled scans running every 30 days for inactive repositories」です。UI文言は変わる可能性があるため、この記事では2026年6月10日JST時点の確認として扱います。
設定は組織単位で読む
Changelogは、この設定がorganization内の全リポジトリに適用されると説明しています。個別リポジトリに小さく試すだけの設定ではなく、組織全体のセキュリティ方針として読むべき変更です。
有効化の前には、全リポジトリの中にどんな状態のコードがあるかを見ておく必要があります。特に、退役予定、所有者不明、PoC、古いfork、ビルド方法が失われたものは、スキャンが始まっても対応判断が詰まりやすい領域です。
Global Settingsの周辺設定も見る
GitHub Docsのglobal security settingsでは、code scanningの組織設定として、Copilot Autofix for CodeQL、default setupに対するExtended query suiteの推奨、CodeQL model packsによる分析範囲拡張なども説明されています。今回の30日周期スキャンだけを単独で見るのではなく、組織全体でどの程度の検出強度を求めているかも合わせて確認してください。
Extended query suiteは検出範囲を広げる一方、精度や重要度の低いアラートも増える可能性があります。非アクティブリポジトリに対してスキャン頻度と検出範囲を同時に広げるなら、トリアージ体制を先に置くべきです。
除外したいリポジトリを先に棚卸しする
「すべてスキャンすれば安全」という運用はわかりやすいものの、アラート対応の責任が曖昧なままでは長続きしません。削除予定の実験コード、法務確認が必要な古い顧客別コード、所有者が退職したリポジトリ、過去のサンプルだけを置いたリポジトリは、スキャン対象にする前に扱いを決める必要があります。
除外や保留を選ぶ場合も、理由と見直し日を残しておくと、後から監査や引き継ぎがしやすくなります。スキャン設定は技術設定ですが、実際には台帳管理、オーナー管理、例外管理を伴います。
有効化前の確認リスト
| 確認項目 | 見る理由 | 決めること |
|---|---|---|
| inactive repoの一覧 | 対象範囲を把握する | 業務継続、保守のみ、退役予定に分類する |
| setup type | default setup限定のため | advanced setupや外部CIを別管理にする |
| owner | アラート対応の入口になる | チームまたは個人の一次受け先を置く |
| Actions状態 | スキャン実行の前提になる | 無効リポジトリの扱いを決める |
| Code Security条件 | privateやinternalで必要になる | 契約と有効化範囲を確認する |
30日周期スキャンで増える確認作業
- 1スキャン条件を見る
いつコードが変わったかだけでなく、どのスキャンで出たか、どのCodeQL設定だったかを確認します。
- 2過去判断を見る
同種のアラートを過去にdismissしていないか、理由や期限が残っているかを確認します。
- 3通知先を更新する
退職者、古いチーム名、実態と合わないCODEOWNERSがないかを見直します。
- 4実行環境を確認する
GitHub Actions、GitHub Code Security、利用プラン、実行状況を合わせて確認します。
30日周期スキャンは検出機会を増やします。同時に、通知、実行状況、担当者確認の仕事も増えます。
30日周期スキャンは、古いコードの見落としを減らす助けになります。一方で、アラート、通知、実行状況、担当者確認の仕事も増えます。導入判断では、セキュリティ効果と運用負荷を同じ重さで見る必要があります。
アラート増加はコード変更が原因とは限らない
非アクティブリポジトリで新しいcode scanning alertが出ても、誰かが最近危険な変更を入れたとは限りません。CodeQLのクエリや解析エンジンは更新されます。たとえば、CodeQL 2.25.6の更新のように、対応言語や検出モデル、GitHub Actions関連の検出が変わると、同じコードでも見え方が変わります。
対応フローでは、まず「いつコードが変わったか」だけでなく、「どのスキャンで出たか」「どのCodeQL設定だったか」「過去に同種のアラートをdismissしていないか」を見るほうが安全です。
通知先とトリアージ担当を決めておく
長く触っていないリポジトリほど、通知先が古くなりがちです。チーム名が変わっている、退職者がownerのまま、CODEOWNERSが実態に合っていない、ということは珍しくありません。
スキャン有効化前に、アラートの一次受け先を決めてください。全リポジトリを中央セキュリティチームが受けるのか、各プロダクトチームに戻すのか、退役予定コードはアーカイブや削除判断に回すのか。ここが曖昧だと、スキャンは動いていても対応は止まります。
Actions分とスキャン実行の監視を分ける
GitHub Docsでは、code scanningがGitHub Actionsを使い、workflow runがGitHub Actions分を消費することが説明されています。また、default setupでCodeQL対応言語がないリポジトリでは、対応言語が追加されるまでスキャンもActions分の使用も発生しないと説明されています。
今回の30日周期スキャンについて、この記事では費用増を具体額で断定しません。組織ごとにリポジトリ数、言語、Actions分、Code Security契約が異なるためです。管理者は、設定前後でActions利用状況、CodeQL実行数、アラート件数を別々に見てください。
上振れと下振れ
| 観点 | 期待できる効果 | 注意すべき負荷 |
|---|---|---|
| 検出 | 古いコードの既知弱点を拾いやすくなる | コード変更と関係ないアラートが増える |
| 管理 | inactive repoの棚卸しが進む | 所有者不明のリポジトリが表面化する |
| 監査 | 継続スキャンの説明がしやすい | 例外管理やdismiss理由の記録が必要になる |
| 費用 | 既存設定の穴を見つけやすい | Actions分や契約条件の確認が必要になる |
tool status pageで動作確認する
- 1Code scanning alertsへ進む
各リポジトリのSecurity and quality、Code scanningからtool status pageへ進みます。
- 2分析状態を見る
CodeQLの状態、設定上の問題、ファイル分析の詳細レポートを確認します。
- 3重要リポジトリから見る
すべてを一度に見ようとせず、業務重要度が高いリポジトリから確認します。
- 4組織全体は別に見る
default setupの網羅率やinactive repoの数は、Security Overviewやリポジトリ台帳と組み合わせて確認します。
tool status pageはリポジトリ単位の確認に向きます。組織全体の網羅率とは分けて考えます。
設定を有効にした後は、リポジトリごとにスキャンが動いているかを確認する必要があります。GitHub Docsのtool status pageは、code scanning分析の状態、設定上の問題、ファイル分析の詳細レポートを確認するためのページとして説明されています。
repository単位でCodeQLの状態を見る
tool status pageは、各リポジトリのcode scanning alertsページからアクセスできます。GitHub Docsでは、Security and qualityタブ、Code scanning、Tool statusという流れが示されています。ここでは、分析ツールの状態や設定に問題がないかを確認できます。
非アクティブリポジトリの30日周期スキャンを有効にしたら、すべてを一度に見ようとせず、重要度の高いリポジトリからtool status pageで状態を確認するのが現実的です。
組織全体の網羅率とは分けて考える
tool status pageはリポジトリ単位の確認に向きます。組織全体でどれだけのリポジトリがdefault setupになっているか、どれだけinactive repoがあるか、どのチームにアラートが偏っているかは、Security Overviewや社内のリポジトリ台帳と組み合わせて見る必要があります。
「tool status pageで見たから組織全体も問題ない」とは言えません。逆に、組織全体のダッシュボードで数字だけ見ても、個別リポジトリのsetup typeや失敗理由は見落とします。
失敗時はsetup typeとActions状態を切り分ける
スキャンが想定通りに動いていない場合は、まず対象リポジトリがdefault setupなのかを確認します。次に、GitHub Actionsが有効か、CodeQL対応言語があるか、Code Securityの条件を満たしているかを見ます。
外部CIでSARIFをアップロードしているリポジトリは、GitHub側のdefault setupとは別の運用になります。ここを混ぜると、Global Settingsを触っても変化しないものを「設定ミス」と誤解しやすくなります。
tool status pageで見る項目
| 項目 | 見る場所 | 異常時の次の行動 |
|---|---|---|
| Tool status | Code scanningのtool status page | CodeQLが失敗していないか確認する |
| setup type | リポジトリのcode scanning設定 | default setupかadvanced setupかを切り分ける |
| last scan | tool statusまたはalerts周辺 | 30日周期で走っているか履歴を見る |
| warnings or failures | tool status page | 言語抽出、Actions、権限を確認する |
| analyzed files | CSVレポート | 期待した言語やファイルが含まれるか見る |
組織で導入する前の棚卸しチェックリスト
例外は悪ではありません。ただし、理由がない例外は後から監査しにくくなります。
この設定は、単にトグルを入れるだけなら簡単です。難しいのは、出てきたアラートをどう扱うかです。特に非アクティブリポジトリは、誰が直すのか、直せない場合はどう閉じるのか、サービスに影響するのかが見えにくくなっています。
対象リポジトリを分類する
まず、対象リポジトリを5つに分けます。業務継続中、保守のみ、退役予定、アーカイブ済み候補、所有者不明です。この分類だけでも、スキャン後の動きが変わります。
業務継続中や保守のみのリポジトリは、アラート修正につなげやすい領域です。退役予定やアーカイブ済み候補は、修正より削除、アクセス制限、アーカイブ判断が優先される場合があります。所有者不明は、まずオーナーを決めることが先です。
アラート対応の優先順位を決める
すべてのアラートを同じ速度で直すのは現実的ではありません。公開リポジトリ、稼働中サービス、依存元が多いライブラリ、認証や機密データに近いコード、顧客データに触れる可能性があるコードは優先度を上げます。
逆に、古い実験コードや完全に退役済みのものは、修正よりもアーカイブや削除の判断が合理的な場合があります。dismissする場合も、理由、期限、再確認条件を残してください。
例外を作るなら理由を残す
組織設定を一律で有効化しても、リポジトリごとに対応方針は変わります。例外は悪ではありません。ただし、理由がない例外は後から監査しにくくなります。
「退役予定のため修正しない」「サービスから切り離し済み」「所有者確認中」「外部CIで別スキャンを実行中」など、短い理由で構いません。いつ再確認するのかも合わせて残すと、例外が放置されにくくなります。
棚卸しテンプレート
| repo | activity | setup type | owner | scan action | triage owner |
|---|---|---|---|---|---|
| 例: internal-tool-old | 6カ月以上変更なし | default setup | platform | 30日周期スキャン対象 | security-oncall |
| 例: legacy-api | 保守のみ | advanced setup | payments | 既存workflowを確認 | appsec |
| 例: demo-archive | 退役予定 | 未確認 | 不明 | owner確認後に判断 | platform |
直近のGitHub Security文脈とのつながり
言語対応、クエリ、GitHub Actions関連の検出、機微データ検出の変化を古いコードにも反映しやすくなります。
新しいAIエージェントの変更を検証する流れとは別軸で、古いコードベースの再評価を担います。
ネットワーク制御、ユーザー名前空間、開発者環境統制と合わせて、組織全体の管理範囲を見ます。
設定場所、対象、運用担当が異なるため、関連更新をまとめすぎず実務判断を分けます。
今回の主題は、非アクティブリポジトリを30日ごとに再スキャンする実務判断です。
今回の更新は、GitHub Security全体の管理機能強化の一部として読むと理解しやすくなります。ただし、主題を広げすぎると、非アクティブリポジトリの30日周期スキャンという実務判断がぼやけます。
CodeQL更新と組み合わせて読む
CodeQLは継続的に更新されています。CodeQL 2.25.6の記事で扱ったように、言語対応、クエリ、GitHub Actions関連の検出、機微データ検出などは変化します。非アクティブリポジトリでも定期スキャンを続ける意味は、こうした解析側の改善を古いコードにも反映できる点にあります。
第三者コーディングエージェント安全検証とは別軸で読む
第三者コーディングエージェント安全検証の一般提供は、エージェントが作る変更やPRに対して、CodeQL、依存関係、secret scanningをどう使うかという話でした。今回のperiodic code scanningは、誰かが変更を作る前提ではありません。長く動いていないコードを再評価する話です。
この2つを合わせて見ると、GitHubは「新しいAIエージェントの変更」と「古いコードベース」の両方にセキュリティ確認を広げていると読めます。ただし、設定場所、対象、運用担当は別です。
Enterprise管理機能と一緒に確認する
GitHub Enterprise Cloudを使う組織では、セキュリティ設定だけでなく、ネットワーク制御、ユーザー名前空間、開発者環境統制も同時に見ます。たとえばEMUユーザー名前空間のIP許可リスト一般提供は、リポジトリへの到達経路をどう絞るかという話です。
一方、Enterprise-managed plugins in VS Codeは、開発環境で使うツールやMCP、hooks、skillsを企業標準化する話です。今回のinactive repo scanningは、これらと同じGitHub管理領域にありますが、直接の目的は古いコードの継続スキャンです。
読者への実務的な結論
- 1. inactive repoを抽出
6カ月以上pushやpull requestがないリポジトリを一覧化します。
- 2. default setupを確認
対象リポジトリがcode scanningのdefault setupを使っているかを確認します。
- 3. 重要リポジトリを見る
業務重要度が高いものからtool status pageで状態を確認します。
- 4. 担当とルールを合意
通知先、一次受け、dismiss、例外、見直し日の扱いを決めます。
- 5. 有効化後に追跡
30日周期スキャン後のアラートを、担当チームと継続的に確認します。
設定の価値は、スキャン結果を受け止める運用があるときに大きくなります。
この更新は、セキュリティ担当者にとって歓迎しやすい機能です。古いリポジトリを30日ごとに再評価できるなら、忘れられたコードベースのリスクを見つけやすくなります。
同時に、組織管理者は「有効化するか」だけで判断しないほうがよいです。自組織のinactive repo、default setupの利用状況、GitHub Actions、GitHub Code Security、owner、通知先、アラート処理のルールを一度に見てください。設定の価値は、スキャン結果を受け止める運用があるときに大きくなります。
最初の一歩は、リポジトリ一覧の棚卸しです。6カ月以上pushやpull requestがないリポジトリを抽出し、default setupかどうかを確認します。次に、重要度が高いリポジトリからtool status pageで状態を見ます。最後に、30日周期スキャンを有効化した後のアラート対応を、担当チームと合意します。
Microsoft Watch JapanはMicrosoftおよびGitHubとは非提携の情報整理サイトです。この記事は公式情報の確認を目的としており、投資助言や売買推奨ではありません。
次に読むなら
参照した主な情報源
- GitHub Changelog, "Periodic code scanning of inactive repositories"（確認日: 2026年6月10日JST）
Periodic code scanning of inactive repositories
- GitHub Docs, "Configuring global security settings for your organization"（確認日: 2026年6月10日JST）
https://docs.github.com/en/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/configuring-global-security-settings-for-your-organization
- GitHub Docs, "Configuring default setup for code scanning at scale"（確認日: 2026年6月10日JST）
https://docs.github.com/en/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale
- GitHub Docs, "Code scanning"（確認日: 2026年6月10日JST）
https://docs.github.com/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning
- GitHub Docs, "About setup types for code scanning"（確認日: 2026年6月10日JST）
https://docs.github.com/en/code-security/concepts/code-scanning/setup-types
- GitHub Docs, "Use the tool status page for code scanning"（確認日: 2026年6月10日JST）
https://docs.github.com/en/code-security/how-tos/find-and-fix-code-vulnerabilities/manage-your-configuration/use-the-tools-status-page-for-code-scanning
更新履歴: 2026年6月10日JSTに初稿を作成。GitHub Changelogの2026年6月9日告知、default setup限定、30日周期、Settings > Advanced Security > Global Settingsの設定場所、GitHub Docsの対象条件を確認しました。GitHub Enterprise Serverでの提供時期や、組織ごとの課金影響は本文で断定していません。