.gitignore と .env とは何か、なぜ最初のコミット前に作らなければならないのか

なぜこの二つが初日なのか

バイブコーディング（自分でコードを書かず AI に指示してソフトウェアを作るやり方）で初めて何かを作るとき、順番はたいてい同じです。AI に画面を作らせ、Claude や ChatGPT の API をつないで機能を入れ、うまく動くので GitHub（コードを保管・共有する場所）に上げる。事故は最後の一歩で起きます。

AI が書いたコードには、API キーがそのまま埋まっていることがよくあります。sk-ant- や sk- で始まるあの長い文字列です。画面上は問題なく動くので、そのままにしてしまう。ところが GitHub の公開リポジトリは文字どおり誰でも見られ、新しく上がったコードからキーらしい文字列だけを探して拾う自動スキャナーが常時回っています。人が漁るのではなく機械が走査するので、露出は分単位です。

他人の手に渡ったキーで API を呼べば、料金はキーの持ち主に請求されます。クラウドアカウントのキーなら、サーバーを立ち上げるのにまで使われます。だからこの二つのファイルは「あとでセキュリティをやるとき」に足すものではなく、プロジェクトを始めた日に作るものです。

.env とは何か — 値をコードの外に出すファイル

.env は environment（環境）の略です。プロジェクトフォルダの一番上に置く普通のテキストファイルで、中には「名前=値」の形式で一行に一つずつ書きます。ここに入れるのは、コードに埋め込んではいけない値 — API キー、データベースのパスワード、外部サービスのトークンです。

コードは値を直接持たず、名前で取り出します。JavaScript なら process.env.名前、Python なら os.environ に名前を渡す形です。こうするとコードに残るのは値ではなく名前だけになります。実際の違いが下です。

// 悪い例 — キーがコードにそのまま埋まっている
const key = "sk-ant-api03-9f2b7c...";

fetch(url, {
  headers: { "x-api-key": key },
});
// このファイルが GitHub に上がればキーも一緒に公開される


// 良い例 — 値は .env から取り出す
const key = process.env.ANTHROPIC_API_KEY;

fetch(url, {
  headers: { "x-api-key": key },
});
// コードには名前だけが残り、実際の値はリポジトリに入らない

# 名前=値、一行に一つずつ。引用符は通常不要
ANTHROPIC_API_KEY=sk-ant-api03-9f2b7c...
DATABASE_PASSWORD=b8Kd2mQx

.gitignore とは何か — 上げないファイルの一覧

git はフォルダ内のファイルがどう変わったかを記録する道具で、GitHub はその記録をインターネットに置く場所です。git は既定でフォルダ内のすべてのファイルを記録対象と見なします。だから何もしなければ .env も一緒に上がります。

.gitignore はその例外一覧です。プロジェクトフォルダの一番上に置き、上げてはいけないファイルとフォルダの名前を一行に一つずつ書きます。ここに書かれたものは、git にとって最初から存在しない扱いになります。

# 機密を含むファイル — 絶対に上げない
.env
.env.local
.env.*.local

# いつでも取り直せるもの — 上げる理由がない
node_modules/
.next/
dist/
build/

# OS やエディタが残すゴミ
.DS_Store
*.log

.env.example — 他人には名札だけ渡す

一人で使う分には .env 一つで足ります。ですが誰かと一緒に作業したり、別のパソコンで続きをやったりすると問題が出ます。.env はリポジトリに上がらないので、受け取る側にはそのファイル自体がなく、どの値が必要かも分かりません。

そこで .env.example を一緒に置きます。値を空にして名前だけ書いた見本です。機密ではないので、このファイルはリポジトリに上げます。受け取った人はこれをコピーして .env に名前を変え、自分の値を埋めます。

ここに実際の値を書いてしまうと、.env を止めた意味がなくなります。見本には常に空の値と形式だけを残します。

# 値は空にする。どの名前が必要かだけを伝える見本
ANTHROPIC_API_KEY=
DATABASE_PASSWORD=

すでに上げてしまったら — 削除ではなく交換

いちばん多い勘違いがこれです。キーが上がったと後から気づき、.gitignore に .env を足して安心してしまう。効きません。.gitignore は「まだ追跡していないファイルを、これからも追跡するな」という意味でしかなく、すでにコミットされたファイルは追跡され続けます。しかも git は過去の履歴を丸ごと持ち歩くので、今ファイルを消しても古いコミットを開けばキーがそのまま見えます。

だから順番は決まっています。第一に、そのキーを発行元（Anthropic・OpenAI・AWS など）のコンソールで失効させ、新しいキーを発行します。露出したキーはすでに他人の手にあると考えます。第二に、追跡から外します。第三に、新しいキーは .env にだけ入れます。

# 1) 発行元のコンソールでそのキーを失効させ、新しいキーを発行する — 何より先に

# 2) 追跡一覧から外す（自分のパソコン上のファイルは残る）
git rm --cached .env

# 3) .gitignore に .env があるか確認してコミット
git commit -m "chore: stop tracking .env"

# 過去のコミットには古いキーが残ったまま — だから 1 が先

バイブコーディングでやってはいけないこと

初心者が繰り返し踏む地雷は多くありません。次の六つを避けるだけで、事故のほとんどは起きなくなります。

バイブコーディングでどう管理するか

毎回口で指示する代わりに、規則をファイルに書いておけば毎回の対話に自動で適用されます。プロジェクトフォルダの一番上の CLAUDE.md（複数のツールを併用するなら AGENTS.md）に次の数行を入れておきます。

## 機密値の扱い
- API キー・パスワード・トークンを絶対にコードへ直接書かないこと。.env に置き、名前で読み出すこと。
- 新しい機密値が出たら .env.example に空の名前を追加し、.gitignore に .env があるか確認すること。
- コミット前に、追跡一覧へ .env やキーらしい文字列が入っていないか確認すること。
- 私にキーの値をチャットへ貼るよう求めないこと。ファイルには私が自分で入れる。

本当に防げているかの確認

規則を書いただけでは証明になりません。コマンド三つで確認できます。AI に「今、上げてはいけないファイルが追跡されていないか確認して」と言えば同じ確認をしてくれます。

# 今回のコミットで上がる一覧 — ここに .env が見えてはいけない
git status --short

# .env が本当に無視されているか確認（規則の行が出れば正常）
git check-ignore -v .env

# すでに追跡中のファイルに env を含むものがないか
git ls-files | grep env

デプロイまで行ったら — 値が住む場所は二か所

作ったものを他人に使ってもらうにはデプロイサービスを通します。ここでもう一つ引っかかる点があります。.env はリポジトリに上がらないので、デプロイされたサーバーにはそのファイルがありません。

解決は簡単です。Vercel や Railway のようなサービスの設定画面には環境変数（Environment Variables）を入力する欄があります。.env に書いたものと同じ名前と値をそこに入れれば、デプロイされたサーバーがその値を読みます。ローカルは .env、サーバーはダッシュボード — 値が住む場所は二か所だと覚えておけば十分です。.env ファイル自体をサーバーに上げる方法は取りません。

今すぐ始める

五段階で終わります。(1) プロジェクトフォルダの一番上に .gitignore を作り、.env と一行書く。(2) .env ファイルを作ってキーを移す。(3) コードに埋まったキーを消し、名前で取り出すよう変える — AI に「コードにあるキーを .env に移して」と言えば済みます。(4) .env.example に名前だけ残す。(5) git status で .env が一覧にないことを確認してからコミットする。

ファイル二つ、十分で終わる作業です。そしてこの十分が、漏洩事故と請求書をまるごと消してくれます。