AIに社内の小さな道具を作らせる会社が増えると、APIキーを扱う人も増えます。会計ソフトから仕訳を取る、勤怠のデータを集計する、kintoneのレコードをSlackに流す。こういう道具にはAPIキーが要り、キーはコードの近くに置かれます。そのキーがGitHubに上がってしまったとき、誰が気づいて、誰が止めるのでしょうか。
結論を先に書きます。
- GitHubのシークレットスキャンの標準の検出は、提供元が鍵の形を登録したサービスの鍵を見分けます。 提供元への通知とプッシュ保護に対応しているかは、鍵の種類ごとに対応表の列が分かれています。登録がない鍵は、標準の検出では見分けられず、提供元への知らせも届きません
- 国内の業務SaaSの鍵は、対応表にないものが目立ちます。 2026年10月のQiitaの調査では、APIがある業務システム65件のうち登録済みは12件、調査対象の国内の民間SaaS 41件は対応表にありませんでした。当社も対応表を検索し、freee・SmartHR・kintone・LINE・Chatworkの名前がないことを確認しました（2026年10月13日）
- 会社の非公開リポジトリでは、シークレットスキャン自体が有料です。 GitHub TeamかEnterprise Cloudで、GitHub Secret Protectionを買って有効にします。個人アカウントの非公開リポジトリは、企業が管理するアカウント（Enterprise Managed Users）を除いて対象外です。契約すれば、対応表にない鍵の形を独自パターンとして登録し、検出とプッシュ保護の対象にできます。提供元への通知は、それでも届きません
- だから、国内SaaSの鍵は、漏れても提供元から知らせが来ない前提で、自社で止める層を持ちます。 鍵の一覧、失効の手順、鍵の形を見る検査。この3つは自社で作れます
この記事の出発点は、Qiitaで@songchong氏（IT連携マップ編集部）が2026年10月4日に公開した調査記事「『シークレットスキャン』とは？漏れた API キー、誰が止めてくれるのか？」です。調査の数字はこの記事のものを使い、GitHubの仕組みと料金は当社がGitHub Docsと価格ページで確認しました（確認日 2026年10月13日）。
シークレットスキャンは何をしているか
GitHubのシークレットスキャンは、リポジトリに書き込まれたAPIキーやトークンを探す機能です。中心にあるのがパートナープログラムです。サービスの提供元がGitHubに連絡し、自社の鍵の形（文字の並び方の決まり）を正規表現で届け、検出時に通知を受けるHTTPの受け口を用意します。GitHubは、公開リポジトリでその形の文字列を見つけると、提供元の受け口に鍵そのものを送ります。GitHub Docsは、提供元に向けて、送られてきた鍵は公開されて漏れたものとみなすように勧めています。失効させるかどうかは提供元が決めます。
もう1つがプッシュ保護です。プッシュ保護に対応した種類の鍵を含むコミットをプッシュしようとすると、GitHubがその場で止めます。端末には、鍵を含むコミットとファイルと行が表示されます。開発者は、鍵を含むすべてのコミットから鍵を取り除いてプッシュし直します。回避が許されている設定なら、理由（テストで使っている、誤検知、後で直す）を選んで通し、3時間以内にプッシュし直します。承認が要る設定の組織では、承認を待ちます。GitHubの2026年10月7日のブログによると、汎用の秘密も含めた新規検出の全体では、約30%をプッシュ時に止め、残りの約70%は履歴に入った後に見つけています。
対応表では、検出、提供元への通知、プッシュ保護が別の列になっています。登録済みの鍵でも、提供元に通知しない種類や、プッシュ保護に対応しない種類があります。ここで大事なのは、標準の検出が登録された形を前提にしていることです。形が届いていない鍵は、標準の検出では鍵だと認識されません。提供元の名前が入っていない汎用の形（秘密鍵、データベースの接続文字列、一部のパスワード）には別の検出もありますが、国内SaaSの鍵がその形に当たるかどうかは製品ごとに違います。もう1つの道が独自パターンです。組織がSecret Protectionを契約していれば、対応表にない鍵の形を正規表現で登録し、検出とプッシュ保護の対象にできます。この場合も、提供元への通知は届きません。
65件のうち登録は12件。国内SaaSは41件が対応表にない
Qiitaの記事は、APIがあると確かめた業務システム65件を、GitHubが公開している対応パターン一覧と照合しています。
- 対応表に登録済み: 12件（海外7社）
- 対応表にない国内の民間SaaS: 41件
- 対応表にない行政のシステム: 9件
- 対応表にない海外製品: 3件
登録があって提供元に知らせが届く例として、Google、Microsoft、HubSpot、Notion、Shopify、Slackが挙がっています。見つけるが提供元には知らせない例としてSalesforceがあり、知らせはリポジトリの持ち主にだけ届きます。対応表にない例として、freee、マネーフォワード、SmartHR、kintoneが挙がっています。
当社も2026年10月13日に対応表を検索しました。freee、SmartHR、kintone、LINE、Chatworkは見つかりませんでした。AIと基盤の側の例を挙げると、Anthropicは5種類、Cloudflareは3種類、OpenAIは1種類の形が掲載され、提供元への通知とプッシュ保護の両方の列に対応と書かれていました。Slackは4種類のうち、Workflow Trigger URLを除く3種類が両方に対応しています。Googleは多数の形が掲載されていますが、Gemini APIキーは提供元への通知とプッシュ保護の対象外でした。同じ会社でも鍵の種類で扱いが違うので、自社が使う鍵の名前で表を見ることになります。
提供元の対応にも差があります。記事によると、Anthropicは漏れた鍵を自動で無効にします。AWSは、公開されたIAMの認証情報に一部の操作を拒む隔離ポリシーを適用する対応で、ポリシーの適用は鍵の失効ではありません。記事が引くTruffle Securityの調査（2023年に収集した漏洩済みの秘密情報1万件を追跡し、2024年1月に公表）では、74%が31日後もまだ使える状態でした。GitHubのブログも、手動で鍵を失効させるまでの平均は約40日で、5件に1件は90日を超えると書いています。
非公開リポジトリは有料。個人アカウントは対象外
会社のコードを非公開リポジトリで管理している場合、見落としやすい点があります。非公開リポジトリではシークレットスキャンもプッシュ保護も既定では動きません。
GitHub Docsの整理はこうです。公開リポジトリでは、シークレットスキャンが無料で自動的に動きます。公開リポジトリへのプッシュには利用者単位で既定で有効な保護があり、リポジトリ全体のプッシュ保護は管理者が有効にします。組織が持つ非公開リポジトリと内部リポジトリでは、GitHub TeamまたはGitHub Enterprise Cloudで提供されるGitHub Secret Protectionが要ります。価格ページでは、Secret Protectionは1アクティブコミッターあたり月19米ドルでした（確認日 2026年10月13日）。個人アカウントが持つリポジトリで使えるのは、Enterprise Managed Usersを使うEnterprise Cloudか、Secret Protectionを有効にしたEnterprise Serverに限られます。
つまり、少人数の会社が社長や担当者の個人アカウントの非公開リポジトリでコードを管理している場合、GitHub側の検出は買うことすらできません。組織アカウントに移してTeam以上を契約し、Secret Protectionを足す、という手順になります。それで標準の検出の対象になるのは対応表にある鍵で、国内SaaSの鍵を見るには独自パターンを自社で登録することになります。
手元で動く道具もあります。GitleaksやTruffleHogは、コミットの前にPC上で鍵の形を探し、止められます。ただし、提供元には知らせません。見つけた後に鍵を失効させるのは自分たちの仕事です。
鍵を守る4つの層。国内SaaSの鍵はどこで止まるか
ここまでを層に分けると、整理しやすくなります。
第1層: 手元の検査。 コミットやファイル保存の時点で、鍵らしい文字列を見つけて止める。GitleaksやTruffleHog、あるいは自作の検査。対象は自分で決められるので、国内SaaSの鍵の形も足せます。
第2層: GitHubのプッシュ保護。 対応する種類の鍵を、履歴に入る前に止める。非公開リポジトリではSecret Protectionの契約が要ります。対応表にない鍵は、独自パターンを自社で登録すれば対象にできます。
第3層: 公開後の検出と提供元への通知。 公開リポジトリで見つかった鍵を、パートナーの提供元に送る。対応表にない提供元には送られません。
第4層: 提供元による失効。 知らせを受けた提供元が鍵を無効にする。提供元ごとに対応が違い、無効にしない提供元もあります。
対応表にない鍵は、第3層と第4層が働かず、第1層と第2層は自社で形を登録して初めて働きます。残るのは、自社で用意する検出と、漏れた後に自分たちで失効させる手順です。GitHubのブログは、防御は計算資源で伸びるが、後始末は人手でしか伸びない、と書いています。対応表にない鍵については、その後始末が自社に残ります。
当社の作業リポジトリではどうしているか
当社は、業務の自動化をAIのエージェントに任せる作業リポジトリを運用しています。鍵の扱いはこうしています。
値を書かず、参照名を書く。 鍵の値はパスワード管理ソフトの1Passwordに置き、コードや設定ファイルには原則として参照名だけを書き、実行時に値を取り出す運用にしています。
AIが書き込んだ後に形を検査する。 AIのエージェントがファイルを書き込むたびに動く検査が、8本の検出パターンで疑わしい文字列を探し、見つかれば警告してエージェントに差し戻します。OpenAIとAnthropicの鍵、Metaのアクセストークン、AWSのアクセスキー、GitHubのトークン、Slackのトークン、GoogleのAPIキー、秘密鍵の冒頭、そして長い16進数の文字列です。参照名の行と例示の行は除きます。保存そのものを防ぐ仕組みではなく、人がエディタで直接書いた保存は見ていません。第1層の一部にあたります。使うSaaSが増えたら、ここにパターンを足します。
GitHub側は未確認。 当社のリポジトリでSecret Protectionが有効かどうかと、その動作は、2026年10月13日の時点で未確認です。確認して、必要なら有効にするのが当社の次の作業です。
この検査が見ているのは、当社がパターンを書いた8本だけです。国内SaaSの鍵を使い始めたら、その形を調べて検査に足すところから始まります。
自社で確かめる5項目
Qiitaの記事の推奨5つを土台に、当社が確認の順番と担当を足しました。
| 項目 | 何を見るか | 誰が決めるか |
|---|---|---|
| 使っている鍵の一覧 | 社内で発行しているAPIキーとトークンを、サービス名・発行者・使っている道具の名前で書き出す | 情報システムか総務。道具を作った人が報告する |
| 対応表との照合 | 一覧の各サービスがGitHubの対応表にあるか。あれば通知とプッシュ保護の列も見る | 道具を作った人 |
| 非公開リポジトリの設定 | 組織アカウントか個人アカウントか。Secret Protectionとプッシュ保護が有効か。対応表にない鍵を独自パターンで登録しているか | 情報システム。契約は経営者 |
| 失効の手順書 | 鍵を取り消す画面の場所と、取り消すと止まる連携を、漏れる前に書き出す | 道具を作った人が書き、情報システムが持つ |
| 鍵の作り方 | 権限を絞った鍵や期限のある鍵を選べる製品では、そちらを使う。1つの道具に1つの鍵 | 道具を作った人 |
漏れたときの順番も決めておきます。 まず鍵を取り消して作り直す。コードの履歴から鍵を消すのはその後でよい、とQiitaの記事は書いています。履歴から消しても、見た人がいれば鍵は使えるからです。
注意点
- 対応表は更新されます。2026年10月13日時点で名前がないサービスが、後に登録されることはあります。半年に1度は自社の一覧と照合し直すことを勧めます
- GitHubは2026年10月7日のブログで、既存のAIによる秘密検出をModernBERTを基にした分類器へ更新し、プッシュ保護への拡張を同月後半にEnterprise CloudとTeamsのSecret Protection契約組織へ提供予定と発表しました。Copilot CLIの/security-reviewへの追加も案内しています。プッシュ時の検出にはAIクレジットを消費します。国内SaaSの鍵をどこまで拾えるかは公開情報では分からないので、当社は届いてから自社の鍵で試す予定です
- GitLab、Bitbucket、Azure DevOpsの扱いはQiitaの記事に整理があります。当社はそれらを検証していません
- この記事はGitHubの機能と公開資料の読み取りに基づいています
KOIYALの見解
AIで社内の道具を作る担当者が鍵も扱うようになると、鍵の管理手順を共有する必要が出てきます。GitHubのブログは、プルリクエストの3件に1件にAIエージェントが関わり、公開コードには約2秒に1つ新しい秘密が現れると書いています。道具を作るのが速くなった分、鍵を守る仕事も増えています。
当社は、インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）を進める会社ほど、この層を自社で持つべきだと考えています。外部のサービスが黙っていても守ってくれる範囲は、提供元が登録した鍵までです。対応表にない鍵は、使う会社が形を登録し、失効の手順を持つ以外にありません。まず重要な連携を1つ選び、鍵の管理担当と失効手順を確認するところから始められます。
読者の会社が自社でできるようになることを1つ挙げるなら、使っている鍵の一覧を作り、失効の手順を1枚にすることです。誰が決めるかは明確で、道具を作った人が書き、情報システムが持ち、契約が要る部分は経営者が決める。この分担は外注しなくても回ります。
次の行動
- 社内で使っているAPIキーとトークンを、サービス名・発行者・使っている道具で一覧にする
- 一覧の各サービスを、GitHubの対応表で検索する。国内SaaSが対応表にないことを、自社の一覧で確かめる
- コードを置いているリポジトリが個人アカウントか組織アカウントか、非公開リポジトリでSecret Protectionが有効かを確かめる
- 鍵ごとに、取り消す画面と止まる連携を書いた失効手順を1枚作る
- 保存時かコミット時に鍵の形を見る検査を1つ入れる。使うSaaSの鍵の形を足す。Secret Protectionを契約しているなら、同じ形を独自パターンにも登録する
鍵の一覧と失効手順を作る段取りを、自社の体制に合わせて組みたい会社は、AI・DXコンサルティングで情報システムと一緒に進めています。