Claude Codeの設定ファイルから認証情報が漏えい？原因とGit履歴の確認・対策【2026年11月】

2026年11月5日、セキュリティ企業Apiiroが、AIコーディングツール「Claude Code」の設定ファイルを通じて、APIキーやパスワードなどの秘密情報がGitHub上に公開されている問題を報告しました。

今回問題となったのは、.claude/settings.local.jsonという設定ファイルです。

Claude Codeを使っていると、コマンドの実行時に「Yes, and don’t ask again（今後は確認しない）」という選択肢が表示されることがあります。

実は、この操作によって承認したコマンドが設定ファイルへ保存されます。そのコマンドに認証情報が直接含まれていた場合、パスワードやAPIキーも一緒に記録される可能性があるのです。

今回の記事では、ApiiroとAnthropicの公式情報をもとに、問題の仕組み、Git履歴の確認方法、具体的な対策を解説します。

Claude Codeで何が起きたのか？

Apiiroは2026年11月1日〜3日に、GitHubで公開されているClaude Codeの設定ファイルなどを調査しました。

その結果、次のような秘密情報の公開が確認されました。

調査項目	結果
公開されていたsettings.local.json	104,185件
秘密情報を含むファイル	1,122件
上記ファイルで検出された秘密情報	1,379件
Git履歴や他の関連ファイルを含む秘密情報の総数	2,539件
秘密情報が見つかった公開リポジトリの総数	1,994件

※出典：Apiiro「Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub」（2026年11月5日、8日更新）

検出された秘密情報には、データベースのパスワード、Supabaseのキー、AWSの認証情報、GitHub・GitLab・npmのトークンなどが含まれていました。

さらに、Apiiroは設定ファイルを削除した後でも、Gitの過去のコミット履歴に734件の秘密情報が残っていたと報告しています。

なお、今回の調査で「秘密情報」と判断された値が、すべて現在も利用可能な認証情報とは限りません。Apiiroは資格情報を使って外部サービスに接続する検証は実施していません。

重要なのは、AIが外部へ認証情報を勝手に送信したという話ではなく、ローカルの設定ファイルに認証情報が保存され、それがGitリポジトリ経由で公開されていたという点です。

settings.local.jsonとは？

Claude Codeには、用途に応じて複数の設定ファイルがあります。

主な設定ファイルは以下のとおりです。

ファイル	用途
~/.claude/settings.json	ユーザー個人の共通設定
.claude/settings.json	プロジェクトメンバーで共有する設定
.claude/settings.local.json	プロジェクトごとの個人設定

settings.local.jsonには、Claude Codeの実行許可ルールなどが保存されます。

例えば、次のような設定です。

{
  "permissions": {
    "allow": [
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ]
  }
}

この設定では、指定したテストやLintのコマンドを承認済みとして扱います。

毎回確認する手間を省けるため便利ですが、問題は保存される許可ルールの内容です。

「Yes, and don’t ask again」が危険になる理由

例えば、Claude Codeに次のような依頼をしたとします。

「開発環境のPostgreSQLに接続して、テーブルを確認してください」

Claude CodeがDB接続用のコマンドを生成したとき、そのコマンド内にパスワードが含まれる場合があります。

以下は仕組みを説明するための架空のコマンドです。

PGPASSWORD=DEMO_ONLY psql -h db.example.invalid -U demo -c "SELECT 1"

※DEMO_ONLYは説明用のダミー文字列であり、実在する認証情報ではありません。

このコマンドを恒久的に許可すると、コマンド内容がpermissions.allowに保存される場合があります。

例えば、次のような形です。

{
  "permissions": {
    "allow": [
      "Bash(PGPASSWORD=DEMO_ONLY psql -h db.example.invalid -U demo -c \"SELECT 1\")"
    ]
  }
}

つまり、コマンドに含まれたパスワードがJSONファイル内にも残ることになります。

仮にこれが実在するDBの接続情報だった場合、ファイルを第三者が取得することで認証情報の漏えいにつながります。

ここで理解しておきたいのが、Claude Codeがファイルを保存することと、ファイルがGitHubへ公開されることは別の問題だという点です。

Anthropicの公式ドキュメントによると、Claude CodeがGitリポジトリ内でこのファイルを初めて書き込む際には、通常、開発者のGitグローバル除外設定へパスを追加します。

しかし、以下のようなケースでは、除外設定だけでは防げない可能性があります。

• 設定ファイルを手動で作成した
• すでにGitで追跡している
• 別のPCへリポジトリを複製した
• リポジトリを後から初期化した
• git add -fなどで強制的に追加した

特に注意したいのが、ローカルPCの除外設定が、チームメンバー全員へ共有されるわけではないことです。

そのため、プロジェクト自身の.gitignoreで保護することも重要になります。

自分のGitリポジトリが危険か確認する方法

ここからは、実際にGitコマンドを使って設定ファイルを確認します。

WindowsのPowerShell、Git Bash、Linux、macOSなど、Gitを利用できる環境が対象です。

まず、対象プロジェクトのルートディレクトリへ移動してください。

以下のコマンドは基本的に参照用で、Git履歴の書き換えやファイル削除は行いません。

① 設定ファイルがGitの管理対象か確認

git ls-files -- .claude/settings.local.json .claude/settings.json

このコマンドは、Gitで追跡されている設定ファイルを表示します。

例えば、次のような結果が返ってきた場合です。

.claude/settings.json
.claude/settings.local.json

この場合、両方のファイルがGitの管理対象になっています。

ただし、settings.jsonはチームで共有するためにGitへ登録することも想定されています。

問題は、個人用のsettings.local.jsonが追跡され、秘密情報を含んでいる場合です。

何も表示されない場合、少なくとも現在のGitインデックスでは対象ファイルを追跡していません。

ただし、過去にコミットされていた可能性は残ります。

② .gitignoreが有効か確認

git check-ignore -v --no-index -- .claude/settings.local.json

正常に除外ルールが見つかった場合、次のような結果になります。

.gitignore:3:.claude/settings.local.json  .claude/settings.local.json

この結果から、どの設定ファイルの何行目で除外されているかを確認できます。

出力されない場合は、現在のGit設定で該当ファイルを除外するルールが見つかっていません。

なお、グローバル設定で除外されている場合は、そのファイルの場所が表示されることもあります。

③ Gitのコミット履歴を確認

現在のリポジトリから設定ファイルが削除されていても、Gitの過去のコミットに残っている場合があります。

確認するには、以下のコマンドを実行します。

git log --all --oneline -- .claude/settings.local.json

過去に対象ファイルが追加・編集・削除されていた場合、関連コミットが表示されます。

例えば、次のような結果です。

a1b2c3d Remove local settings
e4f5a6b Update Claude settings

この場合、現在のリポジトリにファイルが存在していなくても、過去の履歴には含まれていたことになります。

共有設定についても確認しておきましょう。

git log --all --oneline -- .claude/settings.json

ただし、git log --allで確認できるのはローカルリポジトリから参照できる履歴です。GitHub上のすべてのPR、削除済みのリモート参照、フォークまで網羅するものではありません。

履歴に存在したことだけで情報漏えいが確定するわけではありません。実際に秘密情報が含まれていたか、公開されていたかを確認する必要があります。

④ 過去のファイル内容を確認する

対象のコミットが見つかった場合、Gitのshowコマンドで過去の内容を確認できます。

git show COMMIT_HASH:.claude/settings.local.json

COMMIT_HASHは、対象ファイルが存在した時点のコミットIDに置き換えてください。

削除済みのコミットではファイルが存在しないため、必要に応じてその直前のコミットを指定します。

このコマンドは過去のファイル内容を出力するため、実際の認証情報が表示される可能性があります。

出力結果をSNS、チャット、Issue、共有ログへ貼り付けないようにしてください。 また、監査ログが収集される共有端末での実行にも注意が必要です。

⑤ Gitへ追加する直前のファイルを確認

コミット前には、次のコマンドも実行するとよいでしょう。

git status --short --untracked-files=all

さらに、ステージング済みファイルの一覧を確認します。

git diff --cached --name-only

ここに.claude/settings.local.jsonが含まれている場合、意図せずコミットしようとしていないか確認してください。

実践できる5つのセキュリティ対策

対策1：.gitignoreに設定ファイルを追加する

まず、プロジェクト直下の.gitignoreに次の内容を追加します。

# Claude Code のローカル設定
.claude/settings.local.json

これにより、まだGitに追跡されていない該当ファイルが、通常のgit addで登録されることを防ぎます。

複数の階層にClaude Codeの設定が存在する構成であれば、以下のように記載することもできます。

**/.claude/settings.local.json

注意点として、.gitignoreはすでにGitで追跡しているファイルには効果がありません。

その場合は、次の対策も必要になります。

対策2：Gitの追跡対象から外す

すでにGitで追跡している場合は、次のコマンドで管理対象から外せます。

git rm --cached -- .claude/settings.local.json

--cachedを指定しているため、ローカルの作業ファイルそのものは残し、Gitの追跡対象から外します。

続いて、.gitignoreの変更を登録します。

git add .gitignore
git commit -m "Stop tracking local Claude Code settings"

ただし、これは現在以降のコミットからファイルを外す操作です。

過去のコミットに含まれる情報は削除されません。

対策3：パスワードやAPIキーをコマンドへ直接書かない

今回の問題を防ぐうえで、特に重要なのがこの対策です。

例えば、以下のように実際の認証情報をコマンドへ直接記述することは避けましょう。

# NG: パスワードをコマンドに直書き
PGPASSWORD=DEMO_ONLY psql -h db.example.invalid -U demo

代わりに、シークレット管理システムや環境変数などを利用して、コマンド文字列自体に認証情報を含めない設計にします。

例えば、認証情報を実行前に安全な方法で設定し、Claude Codeには次のようなコマンドだけを実行させる構成です。

psql -h db.example.invalid -U demo

ただし、環境変数も万能ではありません。

実行プロセスの環境情報やログ、デバッグ出力などから秘密情報が漏れる可能性もあるため、本番環境ではAWS Secrets Managerなどの利用も検討してください。

対策4：許可ルールを必要最小限にする

Claude Codeには、特定のコマンドだけを許可する仕組みがあります。

例えば、以下のような設定です。

{
  "permissions": {
    "allow": [
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ]
  }
}

一方、次のような広範囲の許可ルールには注意が必要です。

Bash(*)
Bash(git *)

これらは必要以上に広い操作を許可する可能性があります。

今回の情報漏えい問題は、許可範囲だけが原因ではありませんが、保存されるルールを限定しておくことは、意図しない操作を防ぐうえでも重要です。

Claude Code内の/permissionsから、既存の許可ルールを確認・整理できます。

設定ファイルに残っている不要なルールは削除しましょう。

対策5：GitHubのSecret Scanningを利用する

GitHubには、リポジトリ内の認証情報を検出するSecret Scanning機能があります。

GitHubを利用している場合は、利用中のプランやリポジトリの種類に応じて、Secret ScanningやPush Protectionの有効化を検討してください。

また、CI/CDにGitleaksやTruffleHogを組み込む方法もあります。

ただし、これらのツールだけに依存することはおすすめできません。

Apiiroの調査では、秘密情報を含む1,122件のファイルのうち、215件がGitleaksとTruffleHogの両方で検出されませんでした。

APIキーのように特徴的な形式を持つ値は検出しやすい一方、普通の文字列で構成されたDBパスワードなどは見逃される場合があります。

そのため、ツールによるスキャンと人による設定確認を併用することが重要です。

すでに秘密情報をGitHubへ公開していた場合は？

もし実際のパスワードやAPIキーがGitHubへ公開されていたことが判明したら、ファイルを削除するだけでは不十分です。

優先順位は次のとおりです。

1. 認証情報を失効・ローテーションする
2. 利用ログを確認し、不審なアクセスがないか調査する
3. 設定ファイルをGitの追跡対象から外す
4. 必要に応じてGit履歴の削除を検討する
5. フォークやクローン、CI/CDログなどへの残存も確認する

特に重要なのが最初の認証情報のローテーションです。

GitHubの公式ドキュメントでも、秘密情報を公開した場合は履歴の書き換えより先に認証情報を失効・変更することが推奨されています。

Gitの履歴を削除する場合、git-filter-repoというツールが利用できます。

ただし、履歴の書き換えはコミットIDの変更、プルリクエストへの影響、既存クローンからの再流入などを引き起こす可能性があります。

チーム開発の場合は、関係者と調整してから実施してください。

また、GitHub上の履歴を書き換えても、第三者のフォークや既存クローンから秘密情報を完全に取り除けるとは限りません。

Anthropicはこの問題に対応している？

2026年11月7日、AnthropicのClaude Code責任者であるBoris Cherny氏がHacker News上で今回の問題についてコメントしています。

Apiiroの11月8日付更新によると、秘密情報の検出機能や自動モードにおける確認方法など、複数の対策案を検討しているとのことです。

ただし、これはHacker News上での担当者の発言であり、正式な修正リリースを発表したものではありません。

また、Anthropicの公式ドキュメントでは、Claude Codeが設定ファイルを作成する際、Gitのグローバル除外設定を利用する仕組みが説明されています。

したがって、Claude Codeがすべての環境で設定ファイルを無防備にコミットするという理解は正しくありません。

今後の改善を待つだけではなく、プロジェクト側でGit管理や認証情報の扱いを見直すことが必要です。

まとめ

今回のApiiroの調査によって、Claude Codeの許可設定が思わぬ情報漏えいにつながる可能性が明らかになりました。

特に注意したいのは、以下の3点です。

• 「Yes, and don’t ask again」によって、コマンドに含まれる秘密情報まで設定ファイルに残る場合がある
• .gitignoreで除外していても、すでに追跡しているファイルや過去のGit履歴は保護できない
• 秘密情報が漏えいした場合、ファイル削除より認証情報の失効・ローテーションを優先する

AIコーディングツールは開発効率を大きく改善してくれます。

しかし、AIが実行するコマンドや設定ファイルも、通常のソースコードと同じように管理する必要があります。

Claude Codeを業務や個人開発で利用している方は、一度.claude/settings.local.jsonとGitの履歴を確認してみてください。

参考資料

• Apiiro公式：Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub
• Anthropic公式：Claude Code Settings
• Anthropic公式：Configure Permissions
• GitHub公式：リポジトリからの機微なデータの削除

※本記事は2026年11月9日時点の公開情報に基づいています。コマンド例は説明用であり、実際の秘密情報を使用した検証は行っていません。