API キーをうっかり GitHub に公開してしまったら、誰かが気づいて止めてくれるのでしょうか。GitHub には「シークレットスキャン」という仕組みがあります。ただ、その仕組みで自分の使っているシステムの鍵まで守られるのか、自分で何か設定する必要があるのかは、あまり知られていません。
この記事では、GitHub・GitLab などの公式文書と、IT連携マップで API があると確かめた業務システム 65 件を GitHub の対応表と照らした結果から、4 つの問いに答えます。冒頭の図は、4 つの問いと答えの一覧です。引用した原文と細かい数字は、調査ページ シークレットスキャンとは — 漏れた鍵は誰が止めるか に 1 行ずつ載せています。
1. まず、言葉をそろえる
| 言葉 | 意味 |
|---|---|
| 鍵 | システムが「使ってよい相手か」を確かめるための、秘密の文字列。パスワード、API キー、アクセストークンなどがある。この記事では、これらをまとめて「鍵」と呼ぶ |
| API キー | 鍵の一種。プログラムが別のシステムの API を呼ぶときに、自分が誰かを示すために送る文字列。API キーを持っている人は、鍵の持ち主と同じ操作ができる |
| GitHub | プログラムの文章（コード）を保管・共有するサービス |
| リポジトリ | GitHub の上の、開発ごとのコードの置き場所。持ち主がリポジトリを公開にすると、世界中の誰でもそのコードを読める |
| コミット・プッシュ | 開発する人が手元でコードの変更を記録することをコミット、記録した変更を GitHub に送ることをプッシュと呼ぶ |
| 提供元 | 鍵を発行した会社。freee、Google、AWS など |
| プッシュ保護 | 鍵を含むコードがプッシュされたときに、GitHub がそのコードを受け取らずに止める働き |
2. シークレットスキャンは、どう動くのか
シークレットスキャンは、GitHub に置かれたコードの中から、API キーの「形」をした文字列を GitHub が探す仕組みです。形とは、鍵の文字の並び方の決まりのことです。鍵を発行した提供元が、自社の鍵の形を GitHub に届けます。
図の上半分は、形が届いている鍵（Slack・Google・HubSpot など）の場合です。GitHub は、プッシュのときに鍵を見つけると、そのコードが送られる前に止めます（プッシュ保護）。また GitHub は、公開されてしまった鍵を見つけると、その鍵の提供元に知らせます。
図の下半分は、形が届いていない鍵の場合です。GitHub はその文字列を鍵だと見分けられません。そのため、鍵はそのまま公開され、提供元にも知らせが届きません。
📎 仕組みの原文（GitHub Docs）は シークレットスキャンとは の「仕組み」 にあります。
3. 見つけたら、止めてくれるのか
GitHub がするのは、提供元に「知らせる」ところまでです。鍵を取り消すかどうかは、鍵を発行した提供元が決めます。たとえば Anthropic（Claude の提供元）は、漏れた鍵を自動で無効にします。一方 AWS は、漏れた鍵に一部の操作を拒む設定を付けるだけで、鍵そのものは使える状態のまま残ります。
しかも、漏れた鍵はなかなか取り消されません。研究者がわざと AWS の鍵を GitHub に置いた実験では、第三者が 1〜5 分でその鍵を使いました。また Truffle Security の調査では、GitHub に漏れた鍵の 74% が、31 日後もまだ使える状態でした。
📎 提供元ごとの対応と実験の原文は シークレットスキャンとは の「止めるのは提供元」 にあります。
4. 使っているシステムの鍵なら、大丈夫か
IT連携マップ編集部は、API があると確かめた業務システム 65 件を、GitHub が公開している対応表と照らしました。対応表に名前があったのは 12 件で、日本の民間 SaaS 41 件はどれも対応表に載っていませんでした。
| 使っているシステム | 公開リポジトリに鍵が漏れたら |
|---|---|
| Google・Microsoft・HubSpot・Notion・Shopify・Slack | GitHub が鍵を見つけて、提供元に知らせる |
| Salesforce | GitHub は鍵を見つけるが、提供元には知らせない。知らせはリポジトリの持ち主にだけ届く |
| freee・マネーフォワード・SmartHR・kintone など日本の民間 SaaS | GitHub は鍵だと見分けられず、提供元にも知らせが届かない |
日本の業務 SaaS の鍵は、漏れても誰からも知らせが来ない前提で、自分たちで管理するのが安全です。
📎 65 件の一覧と、提供元ごとの扱いの違いは シークレットスキャンとは の「使っているシステムの鍵は、大丈夫か」 にあります。
5. 自分で設定は要るのか
| リポジトリ | 何もしなくても動くもの | 自分で設定が要るもの |
|---|---|---|
| 公開 | GitHub が無料で鍵を探し、提供元に知らせる。利用者が鍵を含むコードをプッシュすると、GitHub が止める | リポジトリ全体のプッシュ保護は、リポジトリの管理者が有効にする |
| 会社（組織）の非公開 | シークレットスキャンは動かない | 会社が GitHub Team 以上を契約し、有料の GitHub Secret Protection を有効にする |
| 個人の非公開 | シークレットスキャンは動かない | 企業が管理する Enterprise Managed Users のアカウントでだけ、シークレットスキャンを使える |
会社のコードを非公開リポジトリに置いているなら、GitHub が鍵を探しているとは限りません。会社の契約と設定を一度確かめてください。対応表に無い鍵も、組織のリポジトリなら、組織が鍵の形を自分で書き足して、GitHub に探させることができます。ただし、その場合も知らせが届くのは社内だけです。鍵は、自分たちで取り消す必要があります。
📎 設定の要否の原文は シークレットスキャンとは の「自分で設定が要るか」 にあります。
6. GitHub 以外では、どうか
GitLab にも同じ仕組みがあります。ただし、GitLab が鍵を送る前に止めるのは、最上位の Ultimate プランだけです。GitLab が提供元に知らせるのも、公開または Ultimate のプロジェクトで、AWS・Google Cloud など 4 種の鍵だけです。Bitbucket のクラウド版では、利用者が CI に部品を足して鍵を探します。Azure DevOps では、鍵を探す機能は有料の追加機能です。
Gitleaks や TruffleHog は、手元の PC で鍵を探す道具です。これらの道具はコミットする前に鍵を止められますが、提供元には知らせません。調べた範囲では、日本の業務 SaaS の鍵を提供元に知らせるサービスは見つかりませんでした。
📎 各社の公式文書の原文は シークレットスキャンとは の「GitHub 以外では」 にあります。
7. 漏れる前に、漏れたときに
鍵を使う会社は、次の 5 つをしておきます。
- 使っているシステムの鍵が、GitHub の対応表に載っているかを確かめる
- 会社の非公開リポジトリで、シークレットスキャンとプッシュ保護が有効になっているかを確かめる
- 鍵を取り消す画面と、鍵を取り消すと止まる連携を、漏れる前に書き出しておく
- 鍵が漏れたら、まず鍵を取り消して作り直す。コードの過去の記録から鍵を消すのは、その後でよい
- 権限を絞った鍵や、期限のある鍵を選べる製品では、そちらを使う
鍵の期限と取り消し方は API トークンはいつ切れ、どう取り消すか、鍵がどこから漏れるかは API キーはどこから漏れるのか、AI エージェントに鍵を渡すときの注意は AI エージェントに鍵を渡しても大丈夫か にまとめています。鍵の置き場所は .env の名前を変えれば安全か — 合鍵の置き場所 にまとめています。
一次出典
| 出典 | 内容 |
|---|---|
| GitHub Docs: About secret scanning | 公開リポジトリは無料で自動・非公開は Secret Protection が要る |
| GitHub Docs: About push protection | プッシュ保護の種類と、初めの状態 |
| GitHub Docs: Secret scanning partner program | 提供元が鍵の形を届ける仕組み |
| GitHub Docs: Supported secret scanning patterns | 対応表 |
| GitHub Docs: About GitHub Advanced Security | Secret Protection の購入条件 |
| GitLab Docs: Secret detection | GitLab の 3 つの仕組み |
| GitLab Docs: Automatic response to leaked secrets | 提供元に知らせる条件 |
| Microsoft Learn: Azure DevOps の Secret scanning | 有料の追加機能 |
| Atlassian: git-secrets-scan pipe | Bitbucket Cloud で探す方法 |
| Anthropic: API key best practices | 漏れた鍵を自動で無効にする |
| AWS: AWSCompromisedKeyQuarantineV3 | 一部の操作を拒む設定 |
| Unit 42: 漏れた IAM キーの悪用 | 5 分以内に使われた実験 |
| Truffle Security: 漏れた鍵の多くは取り消されない | 31 日後も 74% が使えた |
引用した原文と出典は、すべて調査ページで 1 行ずつ公開しています。確かめたい方は シークレットスキャンとは — 漏れた鍵は誰が止めるか をご覧ください。
読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。
【転載OK】本記事の転載について
本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として、この記事の完全版 『シークレットスキャンとは』（renkeimap.jp）へのリンクをお願いします。事前の連絡は不要です。
※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。 文中の「編集部」は、筆者が所属する IT連携マップ編集部 のことです。誤りを見つけられましたら 訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。