GitHubのAI秘密情報検出を導入する前に確認したい範囲と課金

公開日2026.10.21

約8分で読めます

※本ページのリンクにはプロモーションが含まれています。

コード内の秘密情報の候補を送信前に検査し利用量も確認する様子を表したオリーブ色背景のフラットな概念イラスト

AIに設定ファイルやテストを作らせる機会が増えると、コードの品質だけでなく、認証情報が紛れ込む経路も点検したくなります。人がコピーした値でも、エージェントが編集した値でも、リポジトリへ送る前に気付けることが理想です。しかし「AIで秘密を検出する」という機能名だけでは、どこで検査され、誰が費用を負担するのかまでは分かりません。

GitHubは2026年10月7日に秘密情報検出向けモデルと関連機能の提供計画を公表し、10月13日の技術記事で仕組みを説明しました。後者は10月14日更新です。本記事は10月21日に確認した一次資料を基に、AIによる検出を安全に導入する判断点を整理する解説です。当日発表された新製品や、情報漏えい事件の速報ではありません。

文章を生成するAIではなく候補を分類するAI

GitHubの技術解説：秘密情報検出モデルによると、新しい仕組みは正規表現で候補を拾い、その周辺のコードや変数名などを学習済みの分類器で判断する二段構成です。分類器には調整したModernBERTを使います。固定形式のキーだけでなく、通常の文字列と見分けにくい秘密を扱うための設計であり、汎用チャットに全コードを貼って診断させる話ではありません。

例えば、長い文字列が設定値として使われている場合と、同じような文字列が画像のハッシュとして使われている場合では意味が異なります。これは仕組みを理解するための説明例です。文脈を使う検出は、このような区別を助ける可能性がありますが、文字列の用途を推定しただけで実際の権限や有効性まで確認できたことにはなりません。

導入する側は「AIだから従来の検査を置き換えられる」と考える必要はありません。決まった形式を見つける処理と、曖昧な候補を分類する処理には別の役割があります。どの段階が候補を見逃したのかを追える構成の方が、検査全体を一つの賢い判定へまとめるより、改善点を説明しやすくなります。以下の運用手順は本サイトの提案です。

アラートと送信前の防止とレビューを分ける

GitHubの提供状況・課金に関する告知では、既存のAI検出アラートは新モデルへ移行し、GitHub Secret Protection（GHSP）・GitHub Advanced Security（GHAS）の対象機能として追加料金なしで継続するとされています。一方、AIによるpush protectionはプライベートプレビュー、Copilotの/security-reviewに加わる新しい秘密情報チェックはプライベートプレビュー予定と案内されています。これらは同じ提供段階ではありません。

ここで分けたいのは、リポジトリに入った情報を後から知らせる検査、pushの受け入れ前に止める検査、手元の変更をレビューする検査です。一つを使っただけで、すべての段階が有効になるわけではありません。管理者は対象の契約、利用可能な画面、実際の設定を確認し、どの検査が動くかを開発者へ伝えます。

特に、エージェントへ「レビューしてから送信して」と頼む運用と、サーバーがpushを制御する運用は区別します。前者ではレビューを呼ばなかった場合の扱いが残ります。後者でも検査対象や制約があります。任意の確認手順と、送信を受け付ける仕組みの条件を混ぜないことが重要です。

導入前に対象と担当者を一枚にまとめる

最初の作業は機能の有効化ではなく、対象を絞ることです。どの組織のどのリポジトリに適用するか、アラートを誰が調べるか、検査で止まったpushの相談を誰が受けるかを決めます。委託先が参加する開発や、個人のアカウントで動くエージェントがある場合は、設定を管理できる主体も確認してください。

説明用のWeb開発チームでは、公開サイトのリポジトリを一つ選び、通常の開発者とCIからの送信の両方を確認します。管理者だけが試して終わらせると、日常の実行主体に同じ検査が適用されるかが分かりません。実際の権限と契約で使える範囲を確認し、利用できない機能は予定として管理します。

一度にすべてのリポジトリへ広げるより、アラート量と担当者の処理能力を見て段階的に適用する方が現実的です。検査対象を増やしても、通知先が不明なままなら問題が積み残されます。逆に、誤検出の解除手順がないと、正当な作業を急いで通すために検査自体を弱める動機になります。

止まらなかったpushを安全の証明にしない

GitHub Docs：secret scanningの検出範囲には、対象の秘密の種類、古いトークン形式、大きなpushなどによる制約が説明されています。push時の検査がタイムアウトして受け入れられた場合も、後から必要に応じて検査とアラートが行われるとされています。送信前と送信後の検査は、役割が重なる一方で同一ではありません。

そのため、運用上の結果は「問題なし」「問題あり」だけにしないことを提案します。対象外、未実行、判定不能、停止、検出ありを区別し、どの状態なら人へ戻すかを決めます。利用している機能が返す実際の状態とログを確認し、存在しないエラー区分を想像して実装しないでください。

また、秘密の値を見つける検査は、アプリケーションの認可や依存パッケージの安全性を保証しません。検出がなかったという結果は、その検査範囲における結果です。CIの緑色の表示一つへ、コード全体の安全性や本番公開の承認まで背負わせないようにします。

試験に本物の認証情報を使わない

動作確認には、無効なテスト用データを使い、専用の検証場所で試すことを提案します。本番キーを一度pushして検査が働くかを見る方法は避けてください。阻止されるはずという前提が外れたときに、試験そのものが情報露出になります。テスト用と明示した値が抑制される可能性もあるため、一つの例が通っただけで検出機能が壊れているとも断定できません。

比較用のケースには、秘密に似た非機密の識別子、説明用のプレースホルダー、意図的に無効化した認証形式のサンプルを分けて用意します。期待する結果と、実際の結果が違ったときに理由を調べる担当者を決めます。サービスの提供条件や公式の試験方法がある場合は、それを優先します。

AIが編集した設定ファイルでも、人が作ったファイルでも、同じ受け入れ条件で扱います。「AIが作ったので危険」「人が書いたので安全」と分類するより、どの経路でどの値が入り、どこで検査したかを記録する方が再発防止につながります。本記事では検出率の実測やGitHub機能の有効化は行っていません。

誤検出の解除は値ではなく根拠を残す

検査が日常のpushを止めるなら、誤検出を調べる時間も導入費用の一部です。ただし、止まった理由を確認せず、定型的に例外を承認する運用では防止機能の意味が薄れます。例外を認める対象、根拠、承認者、見直す時点を残す方法を提案します。

相談時に秘密の文字列をチャットへ貼り直す必要はありません。リポジトリや対象の場所、検査結果の識別情報など、権限のある担当者が元の情報を確認できる手掛かりを共有します。エージェントへ解除操作まで任せる場合も、コード修正の許可と検査の例外を認める許可は別に扱います。

実際の秘密だと分かった場合は、検出器の調整より先に影響を抑えます。値を取り除く修正だけで完了とはせず、発行元での失効や差し替えの要否を確認します。詳細な対応は、本サイトのAPIキー漏えい対策の記事と切り分け、本記事では検出を業務へ組み込む条件に焦点を当てます。

検出機能の費用と停止条件も安全設計に含める

10月7日の告知では、新たに任意で有効化するチェックのAI Credits消費が案内されています。既存アラートの料金条件を、新しいpush protectionやレビュー追加機能へそのまま当てはめないでください。検査を実行して止めるべき情報がなかった場合も消費し得るため、ブロック件数だけで予算を見積もるのは不十分です。

GitHub Docs：従量課金製品の予算設定は、予算に関する通知と、上限到達時の利用停止を区別しています。通知を受け取るだけの設定では、必ずしも利用が止まりません。管理対象の製品やSKU、組織・ユーザー等の範囲を確認し、どの予算が適用されるかを把握してください。

本サイトからは、試験期間の上限、通知先、上限到達時の開発フローを先に決めることを提案します。検査が利用できない状態を自動で合格にしない一方、業務を永久に停止させないよう、権限を持つ担当者による判断経路を用意します。エージェントが費用上限を引き上げたり、有料機能を勝手に有効化したりする構成にはしません。