「それ、上げちゃダメ！」GitHub管理で絶対守るべきセキュリティルールと対処法

February 23, 2026March 29, 2026

「あ、それ上げちゃダメ！」は突然やってくる

コードレビューで先輩に「これ、今すぐ消して！」と顔面蒼白で言われた経験、ありませんか？

GitHubは世界中に公開される場所です。リポジトリをprivateにしていても、うっかり機密情報を含めてしまうと、チームメンバー全員がアクセスできてしまいます。さらに、一度でもpublicリポジトリにpushしてしまえば、数秒以内に世界中のBotがそれを検知し、悪用される可能性があります。

今回は、GitHub管理で絶対に守るべきセキュリティルールと、万が一流出してしまった時の対処法を実践的に解説します。

絶対にpushしてはいけない「危険ファイル」4選

まずは、セキュリティリスクが極めて高く、うっかりでは済まされないファイルから見ていきましょう。

.envファイル – 危険度MAX

環境変数を管理する.envファイルには、APIキー、データベースパスワード、秘密鍵などが直接記述されています。これを公開すると、数秒以内にBotがスキャンし、あなたのAPIキーを使って高額なクラウドインスタンスを立ち上げ始めます。

プロジェクトを作成したら、真っ先に.gitignoreに追加しましょう。

# .gitignoreに追加
.env
.env.local
.env.*.local

実務のTips： .envを除外すると、他の開発者が「何の環境変数を設定すればいいの？」と迷います。.env.exampleというファイルを作り、キー名だけを記述して値は空にしておくと、チーム開発で感謝されます。

# .env.example（こちらはコミットOK）
DATABASE_URL=
API_KEY=
SECRET_TOKEN=

クラウドサービスの認証ファイル

AWS、GCP、Azureなどのクラウドサービスから発行される認証ファイルも絶対にアップロードしてはいけません。

credentials.csv（AWS）
google-service-account.json（GCP）
aws_access_key_id
azure-credentials.json

これらをダウンロードしてプロジェクトフォルダに置いたままgit add .してしまう事故が後を絶ちません。認証ファイルは必ずプロジェクト外の安全な場所に保管してください。

SSH秘密鍵 – サーバーアクセス権そのもの

id_rsaや*.pemなどのSSH秘密鍵は、サーバーへのアクセス権限そのものです。これを公開するのは、家の合鍵を駅前で配るようなもの。

SSH鍵は~/.ssh/ディレクトリに保管し、絶対にプロジェクトフォルダ内には置かないでください。

データベースファイル – 個人情報が含まれるリスク

db.sqlite3やdump.sqlなどのデータベースファイルも危険です。「テストデータだから大丈夫」と思っていても、本番データが混ざっていたり、個人情報が含まれていたりする可能性があります。

さらに、バイナリファイルや巨大なテキストファイルはGit管理に向きません。差分管理が困難になり、リポジトリサイズが爆発的に増加します。

リポジトリを汚染する「ノイズファイル」4選

次は、セキュリティリスクは低いものの、チームメンバーに迷惑をかけたり、リポジトリを汚染したりするファイルです。

node_modules – リポジトリ肥大化の元凶

Node.jsの依存ライブラリが格納されるnode_modulesディレクトリは、数千〜数万のファイルを含みます。これを含めると、リポジトリサイズが爆発的に増え、cloneやpullに時間がかかるようになります。

package.jsonとpackage-lock.jsonがあればnpm installで復元できるため、Gitに含める必要はゼロです。

# .gitignoreに追加
node_modules/
npm-debug.log

OSが自動生成するファイル

macOSの.DS_StoreやWindowsのThumbs.dbは、フォルダを開いただけでOSが勝手に作成するファイルです。これが含まれていると、コミットログが汚れるだけでなく、「この人、Mac使ってるんだな」とバレます（笑）。

実務のTips： プロジェクトごとに毎回除外設定を書くのは面倒です。PC全体で無視設定をしましょう。

# ~/.gitignore_global を作成
echo ".DS_Store" >> ~/.gitignore_global
echo "Thumbs.db" >> ~/.gitignore_global

# グローバル設定に登録
git config --global core.excludesfile ~/.gitignore_global

ビルド生成物・コンパイル済みファイル

dist/、build/、__pycache__/などのビルド生成物は、ソースコードから自動生成できるため、バージョン管理する必要がありません。

これらを含めると、コードを1行変えただけで大量のバイナリ差分が発生し、Gitが重くなります。

# .gitignoreに追加
dist/
build/
__pycache__/
*.pyc
*.class
*.o

エディタ・IDEの個人設定ファイル

.vscode/や.idea/などのエディタ設定ファイルは注意が必要です。プロジェクト共通の推奨設定（例：.vscode/settings.jsonの一部）は共有すべきですが、個人の好みに属する設定は除外するのがマナーです。

補足： Marpなどのツールを使う場合、.vscode/settings.jsonにカスタムテーマ設定を記述する必要があるため、共有が必要なケースもあります。プロジェクトの性質に応じて判断しましょう。

.gitignoreの正しい書き方と便利ツール

これらのファイルをGitの監視対象から外すには、プロジェクトルートに.gitignoreファイルを作成します。

# .gitignore の基本テンプレート

# セキュリティ関連
.env
.env.local
.env.*.local
*.pem
*.key
id_rsa
credentials.csv
*-credentials.json

# 依存関係
node_modules/
vendor/

# ビルド生成物
dist/
build/
__pycache__/
*.pyc

# データベース
*.sqlite3
*.db
dump.sql

# ログファイル
*.log
npm-debug.log

# OS関連
.DS_Store
Thumbs.db

便利ツール：gitignore.io

「いちいち書くのが面倒くさい！」という方は、gitignore.io を使いましょう。OS（macOS、Windows）や言語（Node、Python、Java）を入力するだけで、最適な.gitignoreの内容を自動生成してくれます。

「やべっ、もう上げちゃった！」緊急対処法

もし.envなどの機密情報をすでにGitHubにpushしてしまった場合、慌ててファイルを削除して再度pushしてもダメです。 Gitの履歴に残っているため、過去のコミットを見ればパスワードが見えてしまいます。

最優先：パスワード・APIキーを無効化する

何よりも先に、流出した鍵を無効化・再発行してください。 履歴から消す作業をしている間にも、攻撃者はBotを使って秒速で鍵を利用してきます。

AWSの場合：IAMコンソールからアクセスキーを無効化
GCPの場合：サービスアカウントキーを削除
APIキーの場合：提供元のダッシュボードで再発行

補足： GitHubや主要クラウドには「シークレットスキャン機能」があり、公開されたコードの中にキーが含まれていないか自動監視しています。「GitHubから警告メールが来た」「AWSからキーを無効化したと連絡が来た」という場合は、この機能があなたを守ってくれた証拠です。

Git履歴から完全に抹消する

ただの削除コミットではなく、過去の履歴そのものを書き換える必要があります。現在推奨されているツールは以下の2つです。

git-filter-repo（Git公式推奨）：Python製で高速
BFG Repo-Cleaner：Java製でコマンドがシンプル

昔はgit filter-branchが使われていましたが、処理が遅く事故りやすいため、現在は非推奨です。

# git-filter-repo を使った例
pip install git-filter-repo
git filter-repo --path .env --invert-paths

# リモートに強制プッシュ（注意：チーム開発では事前共有必須）
git push origin --force --all

初心者向けの最終手段： コマンドでの履歴操作に自信がない場合、チーム開発でなく自分だけのリポジトリであれば、「リポジトリごと削除して作り直す」のが一番確実で安全な場合もあります。