シークレットスキャンとは｜業務システム65件中53件が対象外

2026年10月5日2026年10月18日

スクリプトにAPIキーを書いたまま、うっかりGitHubへ送ってしまったらどうなるのか。誰かが気づいて止めてくれるのか、それとも自分で気づくしかないのか。そんな不安を感じたことはありませんか。

この記事では「シークレットスキャン」という仕組みと、その限界がわかります。結論から言うと、シークレットスキャンは「形を知っている鍵」しか見つけられません。有名な海外サービスの鍵は守られやすい一方で、国内の業務システムの鍵は対象外のことが多くあります。止めてもらえる前提ではなく、自分で止める手順を先に用意しておくことが大切です。

シークレットスキャンとは?漏れたAPIキーを自動で見つける仕組み

シークレットスキャンは、コードにまぎれこんだ鍵を自動で見つける機能です。

ここでいう鍵(シークレット)とは、APIキーやパスワード、トークンなどの認証情報を指します。APIキーは、サービスを外から操作するための合言葉のようなものです。

GitHubの公式ドキュメントによると、この機能はリポジトリ(コードの保管場所)のすべてのブランチで、Gitの履歴全体を調べます。調べる対象はコードだけではありません。Issueのコメントやプルリクエストの説明文、Wikiなども含まれます。

たとえるなら、空港の手荷物検査です。検査員は「危険物の形の一覧」を持っていて、荷物の中に同じ形がないかを見ています。

つまりシークレットスキャンは、鍵の形の一覧と照らし合わせて見つける検査だと言えます。

シークレットスキャンで守られる範囲は?65件を調べた記事の数字

守られる範囲がどのくらいなのかを、具体的な数で示した記事が2026年10月5日にQiitaで公開されました。

投稿したのは「IT連携マップ編集部」です。記事では、APIがあると確かめた業務システム65件を、GitHubが公開している対応表と照らし合わせています。対応表に名前があったのは12件(18.5%)でした。のこりの53件(81.5%)は載っていませんでした。内訳は、日本の民間SaaSが41件、行政のシステムが9件、海外の製品が3件と報告されています。

シークレットスキャンが見つける鍵と見つけない鍵の図。GitHubへ送ったコードの中の鍵は、形が登録ずみなら見つけて知らせる(調査では65件中12件)、形が未登録なら素通りする(調査では65件中53件) — 図: シークレットスキャンが見つける鍵・見つけない鍵(筆者作成・件数はQiitaの調査記事より)

同じ投稿者は、鍵が漏れる経路を7つに分けた記事も同じ日に公開しています。自分たちのサイトの22日分の記録に、.envというファイルを探す要求が1,566件以上届いていたそうです(.envを置いていないので、中身を返したものは0件とのことです)。.envは、鍵などの設定を書いておくファイルです。

鍵は日常的に探されていて、しかも自動で守られる範囲は思ったよりせまい。2本の記事から読み取れるのは、この2点です。なお、65件という数字はこの編集部が選んだシステムについての結果で、世の中のすべてのサービスの割合ではありません。

シークレットスキャンの2つの働き:あとで見つける・送る前に止める

シークレットスキャンには、大きく2つの働きがあります。

あとで見つけて知らせる

1つ目は、すでに置かれた鍵を見つけて知らせる働きです。公式ドキュメントでは、知らせ先が2通りに分かれています。

パートナー向け:鍵を発行したサービスの会社へ直接知らせる。リポジトリの画面には出ない
ユーザー向け:リポジトリの「Security and quality」タブに警告を出す。対応するのは利用者自身

パートナーとは、鍵の形をあらかじめGitHubに届けている会社のことです。知らせを受けた会社が、鍵を取り消すなどの対応をとれるようになります。実際に取り消すかどうかは、その会社の判断です。

送る前に止める(プッシュ保護)

2つ目は、プッシュ保護と呼ばれる働きです。プッシュとは、手元のコードをGitHubへ送る操作です。

公式ドキュメントによると、送る途中で鍵らしきものを見つけると、プッシュそのものを止めます。止めた理由もメッセージで教えてくれます。プッシュ保護には2種類あります。個人のアカウントにつく「ユーザーのプッシュ保護」は、公開リポジトリへ送るときに最初から有効です。リポジトリ単位の「リポジトリのプッシュ保護」は、最初は無効で、管理者が有効にします。

あとから見つけるより、送る前に止めるほうが被害は小さくなります。履歴に残ってしまった鍵は、消しても安心できないからです。公式ドキュメントも、警告を受けたらまず鍵をすぐ入れ替える(ローテーションする)よう案内しています。

シークレットスキャンの限界:守られない鍵が3種類ある

シークレットスキャンにまかせきりにできない理由は、守られない鍵があるからです。

公式ドキュメントとQiitaの調査をもとに、筆者なりに3つに整理しました。

形が登録されていない鍵:対応表にないサービスの鍵は、検査の一覧に形がない
非公開リポジトリの鍵:公式ドキュメントでは、公開リポジトリは無料で自動実行される。組織の非公開リポジトリでは、GitHub TeamまたはGitHub Enterprise Cloudで有料の「GitHub Secret Protection」を有効にした場合に使えるとされている
GitHubの外で漏れる鍵:サーバーの公開フォルダやログ、AIとの会話記録などは検査の外にある

職場のリポジトリは、非公開で運用していることが多いはずです。つまり、会社が有料の機能を入れていなければ、検査そのものが動いていない可能性があります。

さらに、プッシュ保護は回避もできます。公式ドキュメントには、リポジトリのプッシュ保護について、初期の設定では書き込みの権限を持つ人なら理由を指定して回避できると書かれています。回避すると警告や監査ログが残りますが、止める力は絶対ではありません。

「GitHubが見ているから大丈夫」とは言えない、と覚えておきましょう。

筆者の考察:運用の現場でシークレットスキャンをどう当てはめるか

運用・監視の担当にとって大切なのは、自分があつかう鍵が「どの区分か」を知っておくことです。

区分によって、漏れたときに誰が動くのかが変わるからです。現場でよく見る鍵を、筆者の見立てで表にしました。公式の分類ではありません。実際の対応状況は、GitHub公式の対応表(サポートされているシークレットスキャンパターン)で確かめてください。

鍵の種類	自動で見つかる見込み	漏れたときに動く人
大手クラウドのアクセスキー	高い(形が登録されていることが多い)	発行元の会社と自分たち
海外の有名SaaSのトークン	サービスによる	発行元の会社と自分たち
国内の業務SaaSのAPIキー	低い(調査では多くが対象外)	自分たちだけ
社内システムのパスワード	ほぼ見つからない	自分たちだけ
監視ツールや通知先のURL	ものによる	自分たちだけ