Claude Code「今後は聞かない」で情報漏洩？settings.local.json対策

やっほー、ぼくてんびん丸！

Claude Code を使っているなら、今日は自分のプロジェクトを1つ開いてほしいんだ。 確認画面で何気なく押している「Yes, and don't ask again」（今後は聞かない）が、パスワードを公開リポジトリに残す入口になっていた、という調査が出たよ。何が起きたのか、自分が当てはまるかの確かめ方、どう防ぐかを順に整理するね。

何があったの？

2026年11月上旬、アメリカのセキュリティ企業 Apiiro が、公開されている GitHub のリポジトリを調べた結果を出したよ。Claude Code の設定ファイル .claude/settings.local.json に、データベースのパスワードやクラウドのキーがそのまま入ったまま公開されている、という内容なんだ。

仕組みはこうだよ。Claude Code に「ステージング環境のログインを調べて」と頼むと、Claude は接続のためのコマンドを作る。そのコマンドに、きみの設定ファイルにあるパスワードが入ることがある。実行の前に確認画面が出て、そこで「Yes, and don't ask again」を選ぶと、そのコマンドの文字列がそのまま許可ルールとして保存される。パスワードも一緒にね。

上の画像が、実際に公開されていたファイルの中身だよ（伏せ字は Apiiro が入れたもの）。"allow" の一覧に、パスワード入りのコマンドが1行まるごと入っているのが分かるね。

Apiiro が出した数字を表にするとこうなるよ。

中身でいちばん多いのはサービスの API トークン（398件）とデータベースのパスワード（379件）。データベースを直接開けるものだけで 501件あったんだ。Apiiro は、これはモデルではなく Claude Code というツールの動きで、最新の Opus 5.5 や Fable 5.1 でも同じことが起きると書いているよ。

settings.local.json とは？

settings.local.json は、Claude Code の「このプロジェクトで、自分だけに効く設定」を書くファイルだよ。 プロジェクトの .claude フォルダの中にある。

たとえるなら、職場の机の引き出しに入れた自分用のメモ帳。チームで共有する .claude/settings.json が「職場の掲示板」だとすると、settings.local.json は自分しか見ない前提のメモなんだ。だから気軽に書き込まれる。問題は、そのメモ帳を机ごと公開の場所に運んでしまうと、中身も全部見えちゃうこと。

公式ドキュメントでは、Claude Code はこのファイルを最初に作るとき、PC全体の git の除外リスト（~/.config/git/ignore など）に **/.claude/settings.local.json を足して、コミットされないようにすると書いてある。でも Apiiro によると、これで守れないケースが3つあるんだ。

設定ファイルの全体像（4つのファイルの関係や、.env を読ませない設定）は、Claude Code の設定ガイドにまとめてあるよ。

自分が当てはまるか、確かめる方法

プロジェクトのフォルダで、次の3つを順に見てね。

GitHub に公開しているリポジトリなら、組織やアカウントの中を .claude/settings.local.json と .claude/settings.json で検索するのも、Apiiro が勧めている方法だよ。

見つかったら、どうする？

順番が大事なんだ。先にパスワードやキーを作り直して、片付けはそのあと。 ファイルを消しても、git の履歴、ほかの人の fork や clone には残ったままだからね。

1. パスワード・キーを作り直す（無効にする）。 そのファイルに一度でも入ったものは全部。
2. git の追跡を外す。 git rm --cached .claude/settings.local.json を実行して、リポジトリの .gitignore に .claude/settings.local.json を足す。
3. ファイルの中の、秘密の入った許可ルールを消す。 コミットしていなくても、PC の中に平文で残っているから。

これからの使い方で変えたいのは2つだよ。

• コマンドに秘密を直接書かない。 パスワードは環境変数に入れて、コマンドでは $DB_URL のように名前で呼ぶ。こうすれば、許可ルールに残るのは $DB_URL という名前だけになる。
• 許可はコマンド丸ごとではなく、形で出す。 公式ドキュメントにあるとおり、Bash(npm run *) のように * を使ったルールを自分で書いておけば、毎回の確認も減らせるよ。

API キーを「合鍵」だと思うと分かりやすい。合鍵をメモ帳に書き写しておくと、メモ帳が人の手に渡った瞬間に家に入られちゃう。合鍵そのものは金庫（環境変数や秘密の管理ツール）に置いて、メモには「金庫の何番」とだけ書く、というイメージだね。

Claude Code の情報漏洩、X の反応は？

日本の X では11月7日ごろから話題になっていて、ほとんどが「自分のファイルを確かめて」という注意の呼びかけだったよ。そのうえで、「承認を書き残す仕様の問題」と見る声と、「秘密を直接書いた使う側の問題」と見る声に分かれている。

仕組みを順番に説明していたポスト。

「便利な承認の裏で鍵が平文で残る」と、仕様の落とし穴として受け止めた声。

「基本的には利用者の秘密情報の管理の問題」としつつ、承認の記録も漏れる道になると指摘した声。

ほかにも「Claude Code に git の操作を任せている人は確かめて」という呼びかけが多かったよ。

11月8日時点で、実在を確認できた X のポストから選んだよ。

ぼくの見解

この件で一番こわいのは、「自分は大丈夫」と思っている人ほど当てはまりそうなところだと思う。

Apiiro は、16種類のコーディング用 AI の資料を比べて、承認したコマンドを丸ごとプロジェクトの中のファイルに書くのが確認できたのは Claude Code だけだったと書いている。このサイトで最近まとめた3つのツールと並べると、こうなるよ。

Copilot にも自動承認の設定はあって、Apiiro はその設定ファイルからも9リポジトリで秘密を見つけている。だから Claude Code だけの話ではない。ただ、Claude Code は「今後は聞かない」を押すだけで自動でファイルに書かれるから、自分で書いた覚えがないまま溜まっていく、という違いがあるんだ。

それと、大きなファイルほど危ないというデータも気になった。8KB を超える settings.local.json は10本に1本に秘密が入っていて、500バイト未満だと500本に1本未満。「今後は聞かない」を長く押し続けてきた人ほど、ファイルに溜まっていくってことだね。ぼくの感覚だと、毎日使っている人ほど一度は中身を開いたほうがいい気がする。

Apiiro によると、この動きは2025年8月から GitHub の issue で何度か報告されていたけど、Anthropic からの返事は無かったそう。公式の対応が出るまでは、使う側で守るしかないかもしれないね。

まとめ

「Yes, and don't ask again」は、確認の手間を減らしてくれる便利なボタンだよ。悪いのはボタンじゃなくて、パスワードをコマンドに直接書くことと、メモ帳が自分の机から出ていくことなんだ。

今日やることは3つだけ。自分の settings.local.json を開く、秘密が入っていたらまず作り直す、リポジトリの .gitignore に1行足す。5分で終わるから、次に「今後は聞かない」を押す前にやっておこうね。