.env を GitHub に上げてしまったら：
消す前にすることと、済んだかの確かめ方

先に答え

.env を GitHub に上げてしまったら、ファイルを消すより先に、中に書いてあったシークレット（APIキー・パスワード・トークンなど、外に出してはいけない値）を無効にして、新しいものに替えます。

GitHub からファイルを消しても、過去のコミット（履歴）には残ります。すでにコピーを取った人の手元からは、消せません。古いシークレットを使えなくすることだけが、確かな対応です。順番は次のとおりです。

1. 中のシークレットを、種類に応じて無効化・更新する
2. .env を Git の管理から外し、これから上がらないようにする
3. 済んだことを確かめる

.gitignore に .env を足しただけ、リポジトリを非公開にしただけでは、済んでいません。

手元の .env は消しません（アプリが動かなくなります）。GitHub の画面で .env を消す操作もしません（2は、5の頼み方で行います）。まだ GitHub に送っていない場合は、送らずに、3の表のいちばん下を見てください。

何が起きているのか

.env は、シークレットやデータベースの接続 URLを書いておく設定ファイルです。アプリは、このファイルから値を読んで、AIのサービスやデータベースにつなぎます。

GitHub は、コードの変更を、過去のコミットもふくめてすべて残します。.env を一度でも送ると、その時点の中身が履歴に入ります。あとから最新のコミットでファイルを消しても、過去のコミットを開けば読めます。

公開（Public）のリポジトリは、だれでも読めます。上げたシークレットを使われると、AIのサービスの利用料を請求されたり、データベースの中身を読まれたりするおそれがあります。

AIに任せていると、気づきにくい所です。AIに「GitHub に上げて」と頼むと、フォルダの中のファイルをまとめて送ります。.env を送らないための設定（.gitignore）がなければ、.env も一緒に送られます。.gitignore は、あとから足しても、すでに送ったファイルには効きません。

まず、自分の状態を見る

ブラウザーで、GitHub のリポジトリのページを開きます。ファイルの一覧に .env（.env.local など、.env で始まる名前もふくむ）があるかを見てください。リポジトリの名前の横に、公開（Public）か非公開（Private）かが出ています。

いちばん上の一覧になくても、下のフォルダ（backend・server など）に入っていることがあります。一覧の上の「Go to file」の欄に .env と入れると、リポジトリ全体から探せます。.env.example など、値を入れない見本のファイルは別です（開いてみて、本物の値が書いてあれば、同じ扱いにします）。

表は横にスクロールできます。

前に上げたかどうかが分からないときは、AIに調べてもらえます。

このリポジトリの Git の履歴に、.env や .env で始まる名前のファイルが入ったことがあるかを調べてください。入っていたら、どのコミットで入り、GitHub に送ったあとかどうかを教えてください。ファイルの中身やシークレットの値は、表示しないでください。

公開のリポジトリなら、点検日和（無料・登録不要）にリポジトリの URL を入れても確かめられます。いまのコミットに .env が入っていれば、「.env がGitHubに入っています」と出ます。見るのはいまのコミットだけで、過去の履歴は見ません。非公開のリポジトリは、GitHub の「Code」→「Download ZIP」で落とした ZIP を選ぶと、同じように確かめられます。

手順1：APIキーやパスワードなどを更新する

GitHub の公式の資料も、シークレットを上げてしまったときの最初の一歩は、種類に応じて無効化・更新することだとしています。

公開のリポジトリに出ていたシークレットで、お金や人のデータにかかわるものは、下の順番を待たずに、先に古いシークレットを無効にします。AIのサービスや決済のAPIキー、データベースのパスワードや管理用のキーなどです。アプリがいったん止まっても、先に無効にしてください。止まっている時間より、シークレットを使われるほうが大きな損になります。そのあと、下の手順で新しいシークレットに入れ替えます。

1. GitHub に上がった .env に入っていたシークレットや接続 URL の設定の名前を、すべて書き出す（例：OPENAI_API_KEY、SUPABASE_SERVICE_ROLE_KEY、STRIPE_SECRET_KEY、DATABASE_URL〈パスワードを含む場合があります〉）。いまの .env だけでなく、過去のコミットにだけ入っていたシークレットや、いまは使っていないシークレットも対象です。AIに「Git の履歴にある .env から、設定の名前だけを取り出して一覧にしてください。値は表示しないでください」と頼むと分かります。シークレットの値は、チャットに貼ったり、人に送ったりしません
2. それぞれのシークレットの種類に応じて更新する（APIキーやトークンは発行元の管理画面、Webhook 署名シークレットは Webhook の設定から更新する。秘密鍵は用途を確認し、鍵ペア・証明書・利用先の設定を更新する）
3. 新しいシークレットを、手元の .env と、公開先の設定の値（Vercel なら「Environment Variables」）に入れる。公開先は、値を変えたあとに、公開先の管理画面から公開し直す（やり方が分からないときは、AIに「GitHub に送らずに、公開先で公開し直す方法を教えてください」と聞きます）。5が終わるまで、GitHub には何も送りません（AIにも「まだ GitHub に送らないでください」と伝えます）。いま送ると、新しいシークレットを書いた .env が、また GitHub に上がります
4. アプリが、新しいシークレットで動くことを確かめる
5. 古いシークレットを、種類に応じて無効化・更新し、古い値が使えないことを確かめる。いまは使っていないシークレットも、無効になっているかを確かめる

DATABASE_URL にパスワードが含まれている場合は、データベースのパスワードを変更し、接続 URL を手元と公開先の設定で更新してください。

もともとブラウザーに公開する前提のキー（Supabase の anon キー・publishable key など）は、作り直さなくても構いません。どちらか迷う値は、シークレットとして扱い、種類に応じて無効化・更新してください。

あわせて、それぞれのサービスの利用の記録（使った量・請求）を見て、身に覚えのない利用がないかを確かめます。あった場合は、そのサービスの窓口に知らせてください。

参考：GitHub「Removing sensitive data from a repository」（英語） ↗

手順2：.env を Git の管理から外す

まだ GitHub に送っていない方（3の表のいちばん下）は、この節の2つの頼み方を両方終えるまで、GitHub に送りません。

.gitignore に .env を足すだけでは、すでに送ったファイルは GitHub に残ります。「Git の管理から外す」作業が、別に要ります。手元のファイルは消しません（消すと、アプリが動かなくなります）。AIに、次のように頼みます。

.env など、シークレットが入るファイルを、手元のファイルは残したまま Git の管理から外してください。.gitignore に、そのファイルの名前を足してください。値を入れない見本（.env.example）が必要なら、名前だけを書いたものを作ってください。ファイルの中身やシークレットの値は、表示しないでください。GitHub には、まだ送らないでください。終わったら、Git がそのファイルを追っていないことを確かめる方法を教えてください。

まだ GitHub に送っていないコミットに .env が入っている場合（3の表のいちばん下）は、上の頼み方に続けて、次も頼みます。上の頼み方だけで送ると、.env の入った前のコミットも一緒に送られます。頼む前に、アプリのフォルダをまるごと別の場所にコピーしておくと、うまくいかなかったときに戻せます（コピーしたほうは、GitHub に送りません）。

手元の .env と、ほかのコード・まだ保存していない変更を残したまま、まだ GitHub に送っていないコミットから .env を取り除いてください。シークレットの値は表示せず、GitHub にはまだ送らないでください。終わったら、これから送る履歴に .env が残っていないことを確かめる方法を教えてください。

送る前に、公開先の設定の値（Vercel なら「Environment Variables」）に、.env に書いてある名前がすべて入っているかを見てください（シークレットではない値もふくみます）。公開先に値を入れず、GitHub に上がった .env で動いていたアプリは、.env を外したあとの公開から動かなくなります。

すでに GitHub に上がっている場合と、上の確かめが済んだ場合は、この変更を GitHub に送ります。GitHub のリポジトリのページを開き直して、ファイルの一覧から .env が消えていることを見てください。

履歴に残った分をどうするか

5まで終えても、過去のコミットには、古い .env が残っています。ただし、GitHub に上がったシークレットを、4ですべて無効にしていれば、残っているのは使えないシークレットです。

GitHub に送ったあとの履歴を書き換えて消す方法もありますが、多くの場合、そこまでは要りません。GitHub の公式の資料も、シークレットを無効にして作り直せば足りる場合は、履歴の書き換えまでは要らないことがあるとしています。履歴の書き換えには、次の注意点があります。

• ほかの人が取った写し（クローン・フォーク）には届かない
• 操作を誤ると、コードや作業の記録を失うことがある

履歴の書き換えを考えるのは、作り直せないもの（お客様の情報など）が入っていたときです。そのときは、Git が分かる人と一緒に行ってください。リポジトリを消す必要はありません。

済んだことを確かめる

1. GitHub に上がったシークレットが、すべて、種類に応じて無効化・更新され、古い値が使えなくなっている（過去のコミットにだけ入っていたシークレットもふくむ）
2. GitHub のリポジトリのページの、いまのコミットに .env がない
3. 手元には .env が残っていて、手元のアプリが動く
4. 公開しているアプリが、新しいシークレットで動く
5. 小さな変更をして GitHub に送っても、.env が上がらない
6. 各サービスの利用の記録に、身に覚えのない利用がない

上の一覧の2は、点検日和でも確かめられます。公開のリポジトリの URL を入れると、いまのコミットに .env が入っていないかを見ます。点検するアプリのソースコードは、あなたのブラウザーの中で読むだけで、預かりません。

手元のフォルダを選んだときに点検日和が見るのは、.gitignore に .env が書かれているかどうかです。Git がすでに .env を追っているかは、確かめられません。指摘が出なくても（「.env は .gitignore に書かれています」と出ても）、Git の管理から外れた証拠にはなりません。上の一覧の5は、先にAIに「Git が .env を追っていないことを確かめてください」と頼み、追っていないと分かってから、小さな変更を送って GitHub のページで見てください。過去の履歴に残っているか、古いシークレットが無効になっているかも、点検日和は見ません。上の一覧の1・3・4・6は、ご自分で確かめてください。

これから上げないために

• 新しいアプリを作り始めたら、最初に .gitignore に .env を入れてもらう
• AIに GitHub へ送ってもらう前に、「送る変更の中に、.env やシークレットの値が入っていないかを確かめてから送ってください」と頼む
• シークレットをコードの中に直接書かない（.env に書いたつもりで、別のファイルに書いていた例があります）

GitHub には、公開のリポジトリに入ったシークレットを見つける仕組みがあります。ただし、見つけるのは GitHub が形を知っているシークレットです。GitHub から通知が来ていないことは、上がっていない証拠にはなりません。

シークレットを無効化・更新したあとに、公開しているアプリが動かなくなって戻せないときは、AI製コードの診断と修復にご相談ください（症状の相談は無料です。受けられるかは、症状を伺って確かめます。相談の欄に、シークレットは貼らないでください）。公開の前後に確かめたいほかの点は、「生成AIで作ったアプリの品質チェック：公開前に確かめること」にまとめています。

よくある質問