API Key を GitHub に push しないために：AI コーディング時代のシークレット漏洩対策

AI によるコーディングは、ソフトウェアを作り始めるハードルを大きく下げました。一方で、これまで主に開発チーム内で起きていたセキュリティ問題が、初心者や非エンジニアにも直接降りかかるようになっています。

よくある事故は、API Key、Secret、Token、データベース接続文字列、.env 設定ファイルを公開リポジトリに push してしまうことです。ローカルでは「アプリを動かすための設定」に見えても、GitHub の公開リポジトリに入った瞬間、自動スキャン、自動呼び出し、自動悪用の対象になります。

シークレット漏洩は珍しい事故ではありません。GitGuardian の 2026 年レポートでは、2025 年の公開 GitHub コミットに約 2865 万件の新しいハードコードされた認証情報が含まれ、AI サービス関連の認証情報漏洩は前年比 81% 増加したとされています。これは単なる不注意ではなく、AI コーディング、素早いプロトタイピング、公開ホスティングが重なって規模を拡大している問題です。

初心者が Key を漏らしやすい理由

多くの AI Agent や小さなツールには、ローカルディスク上の「リポジトリ」と、GitHub 上で世界中から見える「リポジトリ」があります。初心者はこの境界を意識できないことがあります。

ローカル実行時には、config.json、.env、settings.yaml に API Key を入れていても、単なる開発用設定に見えます。しかし git add .、git commit、git push を実行すると、それらのファイルがそのままアップロードされる可能性があります。公開されたリポジトリでは、スキャンボットはビジネスロジックを理解する必要がありません。シークレットらしい形式を見つければ十分です。

AI コーディングはこの問題をさらに広げます。

AI が生成するサンプルコードに OPENAI_API_KEY = "sk-..." のような書き方が入ることがある。
初心者は「まず動かす」ために、フロントエンド、スクリプト、設定ファイルへ直接 Key を書きがち。
多くの vibe coding プラットフォームは、GitHub の Push Protection を通らずに直接デプロイできる。
ユーザーは AI が生成したプロジェクト内のファイル、API、既定権限を把握していないことがある。

AI は動くものを速く作る手助けをしますが、セキュリティ責任まで自動で引き受けてはくれません。

`.gitignore` は飾りではない

Git はバージョン管理を行い、GitHub はコードをホストします。.gitignore は、どのファイルを履歴に入れないかを Git に伝えるためのファイルです。

基本的な AI プロジェクトでは、少なくとも次を除外すべきです。

1
2
3
4
5
6
7


.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

ただし .gitignore だけでは不十分です。これは未追跡ファイルが今後追加されるのを防ぐだけです。すでにコミットされたシークレットファイルは、後から .gitignore に書いても履歴から消えません。

安全な習慣は次の通りです。

新規プロジェクトの最初に .gitignore を作る。
API Key は環境変数またはローカル設定だけに置く。
.env.example にはプレースホルダーだけを書き、本物の Key は書かない。
コミット前に gitleaks、trufflehog、GitHub Secret Scanning などでスキャンする。

Key を push したら、ファイル削除だけでは安全にならない

Key を公開リポジトリへ push してしまった場合、最初にやるべきことは「ファイルを消してもう一度コミットする」ことではありません。まず Key を失効またはローテーションします。

Git は履歴を記録します。最新コミットでファイルを削除しても、古いコミット、fork、clone、キャッシュ、スキャンシステムに内容が残る可能性があります。GitHub の公式ドキュメントでも、パスワード、Token、認証情報が漏れた場合は、まず取り消しまたはローテーションすることを勧めています。

推奨手順は次の通りです。

サービス提供元の管理画面で古い Key を失効し、新しい Key を発行する。
請求、利用ログ、不審な IP、異常な使用量を確認する。
ハードコードされた Key を消し、環境変数またはシークレット管理サービスへ移す。
git filter-repo または BFG でリポジトリ履歴から機密ファイルを除去する。
GitHub Secret Scanning と Push Protection を有効にする。
CI/CD、デプロイ基盤、クラウド関数、フロントエンド成果物に古い Key が残っていないか確認する。

OpenAI、Anthropic、DeepSeek、クラウド事業者、決済、メール、データベースなどの Key が漏れると、課金被害だけでなく、データ読み取り、サービス悪用、サプライチェーン汚染、業務アカウント停止につながる可能性があります。

フロントエンドに本物の Key を置いてはいけない

初心者は「画面が動けばよい」と考えて、API Key をフロントエンド JavaScript に書いてしまうことがあります。

1

const apiKey = "sk-xxxxxxxx";

これはほぼ公開と同じです。ブラウザ上のコード、ネットワークリクエスト、Source Map、ビルド成果物は確認できます。秘密にすべき Key はクライアント側に出してはいけません。

正しい構成は、フロントエンドから自分のバックエンド API を呼び、バックエンドが環境変数を読んで外部 API を呼ぶ形です。

1
2
3
4
5


// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

サーバー側で環境変数を使います。

1
2


// server
const apiKey = process.env.OPENAI_API_KEY;

これは形式の問題ではなく、Key をサーバー環境に残し、ページ訪問者全員へ露出しないための設計です。

Vibe Coding でも安全責任は消えない

vibe coding の問題は GitHub 漏洩だけではありません。AI コーディングプラットフォームから直接公開インターネットへデプロイされるアプリも多く、従来のコードレビュー、リポジトリスキャン、セキュリティテストを通らないことがあります。

RedAccess の最近の調査では、AI コーディングツールで生成またはホストされた公開資産が大量に見つかり、その一部が企業データ、個人情報、内部ファイルを露出していました。ここでの教訓は単純です。「公開できる」が簡単になりすぎると、「公開すべきか」「社内限定にすべきか」「権限制御があるか」が見落とされやすくなります。

AI で生成したアプリを公開する前に、少なくとも次を確認します。

このアプリは本当に公開アクセスが必要か。
ログイン、認証、権限分離があるか。
データベース、API Key、Token、Webhook URL がフロントエンドに露出していないか。
外部 API のクォータ、ドメイン、権限、有効期限を制限しているか。
異常発見後に Key を無効化し、デプロイを素早くロールバックできるか。

AI が書いたコードにもセキュリティレビューは必要です。「自分では一行も書いていない」ほど、安全だと思い込むべきではありません。

今すぐ確認すること

まず自分の GitHub アカウントから確認できます。ユーザー名と次のキーワードを組み合わせて検索します。

1
2
3
4
5
6
7
8
9


API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

本物の Key を見つけたら、迷わず先にローテーションし、その後でクリーンアップします。一度でも公開リポジトリに入ったなら、漏洩済みとして扱うべきです。

今後の AI プロジェクトでは、次の流れを固定化すると安全です。

業務コードを書く前に .gitignore を用意する。
.env.example で必要な変数を説明する。
すべての Key は環境変数に置き、ソースコードへ書かない。
API Key には最小権限、クォータ、有効期限を設定する。
GitHub Secret Scanning と Push Protection を有効にする。
公開前に AI にセキュリティチェックを手伝わせても、AI の結論だけを信じない。

AI コーディングの本当の危険は、コードを書き間違えることだけではありません。多くの人が初めて、安全でないアプリを公開インターネットへ素早く出せるようになったことです。速く書くこと自体は問題ではありません。シークレット、データ、権限まで一緒に渡してしまうことが問題です。