GitHubのプッシュ保護プレビュー、定義済み形式のないシークレットもブロック、既定オフでAIクレジットを消費

GitHubは2026年10月28日、プッシュ保護が、あらかじめ決まった形式のないシークレットもブロックできるようになったと発表した。パブリックプレビューである。Microsoft Applied Sciencesと開発した専用の分類器が、疑わしいシークレットが周囲のコードでどう使われているかを見る。これまでのプッシュ保護は、シークレットの種類ごとに事前定義のパターンに頼っていた。新しい検査はそのパターン検出と並行して動き、既定ではオフで、課金対象のAIクレジットを消費する。

従来の方法には明確な隙間がある。パターン検出がトークンを認識できるのは、サービス提供者の固定の接頭辞のような既知の形があるからだ。パスワード、社内の鍵、小さな事業者のトークンにはそのような形がないことがある。新しい分類器は代わりに文脈を読む。その文字列が近くのコードでどう代入され、渡され、使われているかを見る。GitHubは、これにより既知で認識可能な形式のないシークレットもブロックできると述べる。ページは、モデル、学習データ、誤検知の挙動を詳しく説明していない。

分類器が動くと、新しいプッシュ、GitHubのWeb画面でのコミット、ファイルのアップロードが対象になる。シークレットを検出すると、GitHubは変更を拒否し、場所を知らせる。ブロックを解消するには、開発者がプッシュ内のすべてのコミットからシークレットを取り除き、再度試す。既存のバイパスと委任バイパスの流れは引き続き使える。GitHubは自動化に対する規則も示している。エージェントは、ブロックを回避したり迂回したりする前に承認を得なければならない。コーディングエージェントがコードをプッシュする状況で重要な一文であり、人の承認という段階を明記している。

GitHubは初期結果を慎重な言葉で述べる。分類器により、プッシュ保護がシークレットを見つけたプッシュの数は2倍を超えたとする。数えているのは異なるシークレットの数ではなくプッシュの数で、ページは比較条件や観察期間を明かしていない。また、ユーザーが報告した精度は、シークレットスキャンのパートナーが定義する発行元の検出器に匹敵するとも述べる。ページにはサンプル数も絶対数も誤検知率もなく、これらはGitHub自身の主張で、ページからは確認できない。

有効化には3つの前提がある。リポジトリで「AI検出のシークレット」とプッシュ保護がすでにオンになっている必要がある。機能は、github.comでGitHub Secret ProtectionまたはGitHub Advanced Securityを使う組織が対象だ。そのうえで管理者が「AI検出のシークレットをブロック」をオンにする。リポジトリ管理者はリポジトリ設定のAdvanced Security、Secret Protection、AI検出のシークレットで行う。組織・企業の管理者は、カスタムセキュリティ構成を作成または編集し、AI検出のシークレット、プッシュ保護、AI検出のシークレットをブロックの3つを有効にする。REST APIのフィールドはsecret_scanning_generic_secrets、secret_scanning_push_protection、secret_scanning_generic_secrets_push_protectionである。その構成を保護したいリポジトリに適用する。

費用にも注意が要る。プッシュ保護のAI検出はAIクレジットを消費し、組織がプレビューに参加して機能を有効にした時点から課金が始まる。対照的に、プッシュ後のスキャンによるAI検出シークレットのアラートは、Secret ProtectionとAdvanced Securityに追加料金なしで含まれる。プレビューはgithub.comに限られるので、ほかの提供形態のチームはまだ期待できない。妥当な試し方は、まず少数のリポジトリで、ブロックされたプッシュと誤警報を記録し、そのうえで広い展開の費用と開発者への負担を判断することだ。