GitHubのAI secret detectionは、単なるトークン形式の検出ではなく、周辺コードの文脈からパスワードらしい値を見つける方向へ進みました。2026年10月7日の公式発表では、既存のAI-detected Password alertsの新モデル移行、push protectionのAI検査、Copilot CLI/Appの/security-reviewへの追加予定が示されています。管理者は「検出精度」だけでなく、誰が有効化し、どのSKUでAI Creditsを消費し、どのリポジトリに適用するかを先に決める必要があります。
HelloCraftAIでは、AI開発ツールの導入範囲、権限設計、費用監視まで含めた社内展開を支援しています。GitHub CopilotやGitHub Advanced Securityを全社展開する前に、 30日PoCの設計を相談する ことで、検出ルール、予算、開発者体験を同時に確認できます。
何が変わる？3つのAI secret detection
今回の発表は大きく3つに分けられます。1つ目は、GHSPまたはGHASの既存AI-detected Password alertsが、新しいfine-tuned modelへ自動移行される点です。これは追加料金なしで提供され、既存のSecret Protection枠に含まれます。2つ目は、push protectionで非構造化の認証情報をpush時に検査するprivate previewです。3つ目は、Copilot CLIとCopilot appの/security-reviewに、秘密情報分類器のチェックを追加する計画です。
重要なのは、3つの機能で課金と有効化の扱いが異なることです。既存alert scanは含まれますが、push protectionのAI検査と/security-review内の新しいsecret checkは、今後AI Creditsを消費します。つまり、セキュリティ機能として見える一方で、運用上はGitHub Advanced Security、GitHub Secret Protection、Copilot、AI Creditsの境界を整理する必要があります。
対象読者：GitHub管理者が先に確認する範囲
この記事の対象は、GitHub Enterprise Cloud、GitHub Team、GHES、Copilot Business/Enterpriseを管理する情シス、セキュリティ、Engineering Managerです。特に、開発者やAI coding agentがコミット前に/security-reviewを使う組織、またはpush protectionを強めたい組織では、導入前の確認項目が増えます。
GitHubの発表では、GitHub hosting plans、GHSP/GHAS licenses、Copilot subscriptionsは別物だと明示されています。GHECではAI push protectionの対象になり得ますが、GHSPまたはGHASの有償カバレッジが前提です。一方、Copilotの/security-reviewに入る新しいsecret checkは、GHSP/GHASなしでも対象になり得ますが、Copilot側のプラン、招待、管理者ポリシー、AI Creditの制御を受けます。
5項目チェック：有効化前に決めること
1つ目は、対象リポジトリの線引きです。公開、private、internalのどこに適用するか、顧客情報や本番鍵が混ざる可能性が高いリポジトリを優先するかを決めます。2つ目は、push時ブロックとレビュー時検査の役割分担です。push protectionは履歴に入る前の防止、/security-reviewはコミット前後の確認という位置づけで、開発フローに置く場所が違います。
3つ目は、AI Creditsの予算です。GitHubは、opt-in checksがAI Creditsを消費し、organization ownerやCopilot planのbilling accountに計上されると説明しています。4つ目は、誰が有効化できるかです。新しいチェックはoff by defaultで、/security-reviewを実行するだけでは有効になりません。5つ目は、検出後の修正責任です。AI agentが修正できる範囲、開発者承認が必要な範囲、セキュリティチームへエスカレーションする条件を文書化します。
仕様表：無料で含まれる検査とAI Credits対象
既存のAI-detected secret alert scanは、GHSP/GHASの顧客に対して追加料金なしで新モデルへ移行します。ここは既存のSecret Protectionの延長です。一方、AI push protectionとCopilot /security-reviewの新しいsecret checkは、今後のpublic previewやopt-in後にAI Creditsを消費する計画です。予算アラートだけでは利用停止にならない場合があるため、必要に応じてStop usage when budget limit is reachedのような上限制御も確認します。
管理画面では、AI usage insightsでSecret Protection AI Credits SKUを追える設計が示されています。大規模組織では、全リポジトリへ一気に広げるより、月間push数が多い10〜20リポジトリを選び、誤検知率、block率、修正時間、クレジット消費を2週間単位で確認するほうが安全です。
30日PoC：小さく始める導入手順
最初の7日は棚卸しに使います。GHSP/GHASの契約範囲、Copilotプラン、対象リポジトリ、既存のsecret scanning alert数、過去90日のpush protection bypass理由を集めます。次の7日はPoC範囲を決めます。例えば、API連携が多いbackend、IaC、mobileの3領域から各3リポジトリを選び、検出対象と例外承認者を決めます。
15〜21日目は、開発者体験を見ます。push時に止まるほうがよい秘密情報と、/security-reviewで発見してPR前に直せばよいものを分けます。22〜30日目は費用とルールを固めます。AI Credit consumption、誤検知の再現例、修正までの中央値、セキュリティチームの確認時間をまとめ、本番展開のGo/No-Goを判断します。
運用リスク：AI agentに任せすぎない境界
GitHubは/security-reviewについて、read-onlyのレビューであり、既存のCopilot policiesとbillingが適用されると説明しています。ここを誤解すると、AI agentが勝手にセキュリティポリシーや予算を変更するような運用になりかねません。少なくとも、credit-consuming featuresの有効化、budget変更、push protectionの全社展開は、人間の明示承認を必須にします。
また、AI検出は万能ではありません。秘密情報が本物か、テスト用ダミーか、すでに失効済みかは、文脈確認が必要です。検出後は、削除、rotation、履歴からの除去、影響範囲調査、再発防止PRの順に標準手順を作ると、開発者が迷わず動けます。
FAQ：よくある質問
Q. すぐ追加費用が発生しますか。A. 既存のAI-detected secret alert scanはGHSP/GHASに含まれます。ただし、AI push protectionやCopilot /security-reviewの追加secret checkは、opt-in後にAI Creditsを消費する計画です。Q. GHESでも使えますか。A. 新モデルによるAI-detected alertsはGHES 3.23でpublic preview予定ですが、AI push protectionやCopilot security review commandは同Server releaseの対象外とされています。
Q. 最初に何をすべきですか。A. 全社有効化ではなく、重要リポジトリ10本前後で30日PoCを行い、誤検知、ブロック件数、修正時間、AI Creditsの消費を測るのが現実的です。GitHubのAI secret detectionは、漏えい前の検知を強める有力な選択肢ですが、価値を出すにはライセンス、予算、承認フロー、修正責任までセットで設計する必要があります。
