【30分点検】.gitignoreに入れたはずの.envが漏れていないか、5か所で確かめる手順

Posted at 2026-10-14

秘密の鍵が漏れる経路を5か所に分けて、点検するコマンドと、見つかったときの順番をまとめました。
GitHubでコードを管理し、Next.jsをVercelなどへ載せている個人開発者を想定しています。SupabaseやFirebase、Stripe、OpenAIやAnthropicの鍵を使っている人なら、30分ほどで一通り点検できます。

この記事は、【2026年版】Webアプリ公開前チェックリスト42項目にある「.envと秘密鍵」の深掘りです。

Who am I?

BPR Prot. という、AIで作ったWebアプリの公開前の確認を手伝うサービスを作っています。
Xでは、セキュリティや公開前に見落としやすいポイントを日々発信しています。よければご覧ください！ @BPR_Prot

漏れて困る鍵と、公開しても大丈夫な鍵

最初に、名前に「API key」と付いていても、公開を前提にした鍵と秘密にする鍵があることを整理します。

サービス	公開してよい	公開してはいけない
Stripe	Publishable key（`pk_`）	Secret key（`sk_`）、Restricted key（`rk_`）
Supabase	publishable（旧anon）	secret（旧service_role）
Firebase	Web用apiKey	Gemini APIの鍵
OpenAI	ー	APIキー
Anthropic	ー	APIキー

FirebaseのWeb用apiKeyは、Security RulesとApp Checkで守る前提のため、隠す必要はありません。同じGoogleの鍵でも、Gemini APIの鍵は秘密にする側です。
OpenAIとAnthropicのAPIキーは、どれもリポジトリやブラウザに置かない鍵として扱います。

Supabaseの旧キーであるanonとservice_roleは、2026年末に廃止予定です。旧キーを使っている場合は、新しいpublishableとsecretへの切り替えも予定に入れておくと安心です。

1. 今の.envがGitの追跡対象に入っていないか調べる

.gitignoreへ.envを書いても、すでに追跡中のファイルには効きません。練習用リポジトリで試したところ、.gitignoreへ追加したあとも.envは追跡されたままでした。

次のコマンドで、今の.envが追跡されているかを確認できます。

git ls-files .env

.envが表示されたら追跡中です。反対に、git check-ignore -v .envは追跡中の.envに対して何も表示しません。「何も出ないから無視されている」と判断しないようにします。

次のコマンドで、.envの追跡をやめられます。

git rm --cached .env

これで現在の追跡対象からは外せますが、過去の履歴に入った.envまでは消えません。

2. Gitの履歴に.envや鍵の文字列が残っていないか調べる

今のファイルが安全でも、以前のコミットに秘密が残っていることがあります。

次のコマンドで、.envを変更したコミットが履歴にあるかを確認できます。

git log --all --oneline -- .env

次のコマンドで、指定した文字列が追加または削除されたコミットを確認できます。探す文字列は、自分の変数名や鍵の一部へ置き換えます。

git log --all --oneline -S"探す文字列"

次のコマンドで、sk-proj-を含む行をコミットごとに確認できます。

git grep -n "sk-proj-" $(git rev-list --all)

練習用リポジトリでは、追跡をやめたあとも3つのコマンドすべてで過去の.envや偽物の鍵を見つけられました。

履歴を丸ごと調べる専用ツールもあります。gitleaks（MIT）は、新機能の追加を終えて今後はセキュリティ修正のみになっています。
trufflehog（AGPL-3.0）には、見つけた鍵を各サービスへ送って本物か確かめる機能があります。鍵を外に送ることになるので、使う前に設定を確認しておくと安心です。

3. 公開サイトのJavaScriptに秘密の値が入っていないか調べる

Next.jsでNEXT_PUBLIC_を付けた環境変数は、ビルド時にブラウザ向けのJavaScriptへ埋め込まれます。秘密にする値には付けません。

公開したサイトを開き、ブラウザの開発者ツールから読み込まれたJavaScriptを検索します。sk_やsk-proj-など、使っている鍵の先頭文字を検索語にすると探しやすくなります。

公開を前提にしたStripeのpk_やSupabaseのpublishableが見つかることはあります。表と照らし合わせ、秘密にする鍵だけを切り分けます。

4. VercelとGitHubの秘密情報に関する設定を見直す

Vercelの環境変数にはConfigとSecretがあります。秘密の値はSecretとして保存すると、保存後は書き込み専用になり、32文字以上の値はビルドログで伏せ字になります。

GitHubでは、公開リポジトリのsecret scanningが無料で既定オンです。個人のpush protectionも既定オンで、右上のプロフィール画像からSettingsを開き、Code securityの「Push protection for yourself」で状態を確認できます。

一方、リポジトリ単位のpush protectionは既定オフです。パートナーへの自動通知は公開リポジトリとnpmが対象で、非公開リポジトリについての記載はありません。「非公開だから安心」とは判断せず、自分でも履歴を調べます。

5. AIエージェントが.envを読める設定になっていないか見直す

Claude CodeやCodexは、設定しなければ作業フォルダの.envを開けます。詳しい検証は、Claude Code に .env を読ませない設定を入れても、読めてしまう場面があった（Codex と比較）にまとめています。

ここで押さえる点は2つです。

.envを読ませない設定を入れる
Bashをすべて許可しない

設定を入れたあとは、その設定が効く範囲もZennの記事で確認できます。

見つかったときは、鍵の無効化と再発行が先

GitHub公式は、最初の対応として漏れた秘密を無効化またはローテーションするよう案内しています。履歴を先に直している間も古い鍵が使えるため、順番が大切です。

発行元で古い鍵を無効化し、新しい鍵を発行します。StripeはAPI keysから対象のメニューを開いてRotate keyを選べます。AnthropicはConsoleのAPI keysからDisableまたはDeleteを選べます。
新しい鍵へ差し替えたあと、必要ならGitの履歴を書き換えます。GitHub公式の手順ではgit filter-repoを使い、.envを履歴から消す場合は次の形になります。細かい手順は出典のGitHub Docsを見てください。

git filter-repo --sensitive-data-removal --invert-paths --path .env

履歴を書き換えても、forkや他人のclone、キャッシュに残ったコピーまでは消せません。古い鍵を止める作業を省かないでください。

コピーして使えるチェックリスト

git ls-files .envで、今の.envが追跡されていないことを確認した
Gitの履歴を.envのパスと鍵の文字列で検索した
公開サイトのJavaScriptを鍵の先頭文字で検索した
Vercelの環境変数とGitHubのsecret scanning、push protectionを見直した
AIエージェントに.envを読ませない設定を入れ、Bashをすべて許可していない
漏れた鍵があれば、履歴の修正より先に無効化して再発行した

全部を一度に完璧にする必要はありません。まず今のファイルとGitの履歴から始めると、手元だけで進められます。

わたしたちについて

公開前の点検を一つずつ手で進めるのは、正直なかなか大変ですよね。

BPR Prot. は、AIで作ったアプリ・Webサービスのローンチ前の最終確認から、公開後の見守りまでを、ひとつのツールで伴走するサービスです。

URLを入れるとWebサイトのセキュリティをA〜Fで採点
コードの脆弱性診断
ファイルのマルウェア検査

無料で使えるので、公開前後の点検にお役立てください。

Xで話しかけてもらえるとめちゃ嬉しいです！ @BPR_Prot

最後まで見てくださり、ありがとうございました。
それでは良い開発ライフを！ﾉｼ

出典

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up