settings.local.jsonに秘密情報｜点検手順
「Claude Codeで『今後は確認しない』を押したコマンドに、APIキーが入っていた気がする」「settings.local.jsonはgitに乗らないはずだけれど、本当に乗っていないのか」——2026年11月5日に、settings.local.jsonから秘密情報が公開リポジトリに漏れているという調査が出て、同じ不安を抱えた方は多いはずです。
結論から言うと、settings.local.jsonには、承認したコマンドが秘密情報ごと保存されることがあります。Claude Codeは最初にこのファイルを書くとき、このパソコンのgitの除外の一覧に1行足しますが、それで防げるのは一部です。手で作ったファイル、別のパソコン、すでにコミットしたもの、名前の違うコピーは素通りします。点検は3つのコマンドで5分ほどで終わり、見つかったら消すより先に鍵を作り直すのが順番です。
株式会社Fyveは、Claude Codeを毎日の業務と無人の定期ジョブで使い、中小企業のAI導入を支援しています。この記事では、公式ドキュメント（2026年11月10日に確認）と調査の報道をもとに仕組みを整理し、私たちが自社のリポジトリで実際に回した点検の手順と、そこで見つかった抜け道をお伝えします。
settings.local.jsonの秘密情報の件で、何が起きたか
セキュリティ企業のApiiroが2026年11月5日に公開した調査です。原文は私たちの環境からは開けなかったため、数字はitWire・Let's Data Scienceなど複数の報道（いずれも11月7日付）で一致している値だけを引きます。
項目 | 報道されている値 |
|---|---|
GitHubの公開リポジトリで見つかったsettings.local.json | 104,185件 |
そのうち本物の秘密情報を含んでいたファイル | 1,122件（約1.1%） |
そのファイルに含まれていた異なる秘密情報 | 1,379個 |
gitの履歴・共有のsettings.json・エージェントの会話記録まで含めた合計 | 1,994リポジトリ・2,539個 |
種類の内訳（報道の一部） | データベースのパスワード379個・SSHのログイン43個・GitHub／GitLab／npmのトークン42個・AWSの鍵23個 |
注意したい点が2つあります。1つは、Apiiroは見つけた鍵が今も使えるかは試していないと報じられていることです。漏れたことは確かでも、悪用できる状態かどうかまでは分かりません。もう1つは、報道の側も数字を独自に確かめてはいないと断っていることです。この記事でも「Apiiroの調査の値」として扱います。
とはいえ、1,000件を超えるファイルに本物の鍵が入っていた以上、「自分のリポジトリは大丈夫か」を確かめる理由としては十分です。確かめ方は後半で手順にします。
「Yes, and don't ask again」がsettings.local.jsonに書き込む仕組み
まず、なぜこのファイルに秘密情報が入るのかを、公式ドキュメントの記述で押さえます。
承認したコマンドがallowの規則になる
Claude CodeがBashのコマンドを動かす前に許可を求めてきたとき、選択肢に「Yes, and don't ask again」（今後は確認しない）があります。これを選ぶと、Claude Codeはその承認をallowの規則として.claude/settings.local.jsonに保存します。公式の権限のページによると、Bashのコマンドの承認は「リポジトリとコマンドごとに永続」で、次の会話からも同じリポジトリの中ならどこでも効きます。
保存先はリポジトリの一番上（ルート）の.claude/です。サブフォルダでClaude Codeを起動しても、worktreeで作業していても、メインのチェックアウトのルートに書かれます。Claude Code 2.1.211より前は起動したフォルダに置いていたので、古い版から使っている方はサブフォルダにも残っていることがあります。
コマンドに鍵を直に書くと、鍵ごと残る
問題になるのは、承認したコマンドの文字列に秘密情報が含まれていた場合です。たとえば次のようなコマンドです（値は伏せています）。
PGPASSWORD=＜パスワード＞ psql -h db.internal -U app -c "select count(*) from orders"
curl -H "Authorization: Bearer ＜トークン＞" https://api.example.com/v1/itemsClaude Codeが確認の画面で「今後は確認しない」の範囲として示す文字列に、こうした値が入っていれば、規則にもそのまま入ります。公式ドキュメントは、確認の画面が許可する範囲を全部見せられるときだけ「今後は確認しない」を出す、と書いています。逆に言えば、画面に出ている文字列がそのまま保存されるということです。押す前に読めば気づけますが、作業の勢いで押すと気づきません。
なお、ファイルの書き換え（Edit・Write）の承認はこのファイルに保存されず、会話が終わるまでで切れます。永続になるのはBashのコマンドとWebFetchのドメインなどです。
settings.local.jsonはgitに乗らないのか（公式と報道の食い違い）
ここが一番混乱しやすいところです。報道の一部は「既定では除外されない」と書き、公式ドキュメントは「Claude Codeが除外する」と書いています。両方を並べると、食い違いの正体が見えます。
公式ドキュメントの記述
公式の設定のページ（2026年11月10日に確認）には、次のように書かれています。
- Claude Codeがgitのリポジトリの中で初めてこのファイルを書くとき、そのリポジトリがまだ除外していなければ、グローバルの除外ファイルに
**/.claude/settings.local.jsonを足す - グローバルの除外ファイルは、gitの設定
core.excludesFileがあればそれ、無ければ~/.config/git/ignoreなど - ファイルを手で作った場合は、自分で.gitignoreに足すこと
「グローバルの除外ファイル」とは、このパソコンのすべてのリポジトリに効く「gitに乗せないファイルの一覧」です。リポジトリの中の.gitignoreとは別物で、リポジトリと一緒には配られません。
報道とApiiroの指摘
報道によると、Apiiroはこの仕組みが次の場合をカバーしないと指摘しています。
- 後からgitのリポジトリになったフォルダ（ファイルを書いた時点ではリポジトリではなかった）
- 別のパソコンにcloneした環境
- すでにコミットされているファイル
そして「リポジトリ自身の.gitignoreには規則が足されない」としています。同じ報道は、Anthropic側の開発者が「作るときにグローバルの除外に足している。漏れたものは手で作ってコミットされた可能性が高い」と答えたとも伝えています。
どちらが正しいか、ではなく「自分の環境で確かめる」
両者は矛盾していません。公式の仕組みはこのパソコンで、Claude Codeが最初に書いたファイルには効きます。Apiiroの指摘は、その条件から外れる場合の話です。さらに、gitの公式ドキュメントにある通り、除外の規則はすでに追跡しているファイルには効きません。一度コミットしてしまえば、後から除外を足しても追跡は続きます。
だから「既定で除外される／されない」をどちらかに決めて安心するのではなく、自分のリポジトリで実際にどうなっているかを見るのが確実です。次の節がその手順です。
settings.local.jsonの点検手順（3段）
私たちが自社のリポジトリで回した順番です。どれも読むだけのコマンドで、ファイルの中身を画面に出さずに済むようにしています。
1段目：除外がどこから効いているかを見る
git check-ignore -v .claude/settings.local.json除外されていれば、どのファイルの何行目の規則で除外されているかが出ます。たとえば~/.config/git/ignore:1:**/.claude/settings.local.jsonと出れば、グローバルの除外の1行目が効いています。何も出なければ、除外されていません（すでに追跡しているファイルも、規則が効かないので何も出ません）。
ここでグローバルの除外が効いていると分かったら、それはこのパソコンだけの話だと覚えておいてください。同じリポジトリを別のパソコンや別の人が使っているなら、リポジトリの.gitignoreにも同じ1行を足しておくほうが確実です。
2段目：追跡しているものを名前で探す
git ls-files | grep settings.local今gitが追跡しているファイルのうち、名前にsettings.localを含むものを全部出します。.claude/settings.local.jsonそのものだけでなく、名前の違うコピーも拾うのがこの段の狙いです。
settings.local.json.bakのようなバックアップ- 配るための雛形（テンプレート）
.claude/の外に置いたコピー
グローバルの除外の規則は**/.claude/settings.local.jsonという名前と場所で当たるので、名前の末尾が変わったり.claude/の外に置かれたりしたファイルには当たりません。過去にコミットされたことがあるかは、次のコマンドで見られます。
git log --all --oneline -- '*settings.local.json*'3段目：中身は数だけ数える
見つかったファイルの中身を確かめるとき、catで開くと秘密情報が画面やログに残ります。私たちは、秘密情報によく出る語を大文字小文字を区別せずに数えるだけにしています。
grep -ciE 'api_key|token|secret|password|bearer' ＜見つかったファイル＞0なら一安心ですが、この語で拾えない形の秘密（接続先のURLに埋め込んだパスワードなど）は0とは言えません。1以上なら、行の位置を確かめて中身を見るのは自分だけにし、次の節の順番で対処します。
私たちの点検の結果：本体は除外、バックアップがすり抜けていた
報道を受けて、2026年11月10日に社内の作業用リポジトリ（日々の業務とClaude Codeの定期ジョブを回している、数千ファイル規模のリポジトリ）で上の3段を回しました。手元のClaude Codeは2.1.296です。
段 | 結果 |
|---|---|
1. 除外の出どころ | 本体の |
2. 追跡中のもの | 名前に |
3. 中身 | 3つとも、秘密情報によく出る語の該当は0件（中身は画面に出していない） |
すり抜けたのは「名前が変わったコピー」だった
本体は守られていました。それでも追跡されていたのは、設定の不具合を直す前に「念のため」と取ったバックアップです。名前の末尾に.bak-日付が付いたことで、**/.claude/settings.local.jsonの規則に当たらなくなり、そのままコミットされていました。
雛形の2つのうち1つは、名前はsettings.local.jsonそのものですが、.claude/の外のフォルダに置いてあるため、やはり規則に当たっていません。こちらは配る前提で意図して追跡しているもので、中身も許可の規則の見本だけでした。
今回は中身に秘密情報が無かったので実害はありません。ただ、除外の決まりは名前で当たることを、自分のリポジトリで確かめられたのは大きな収穫でした。設定ファイルを直すときにバックアップを取るのは良い習慣ですが、そのバックアップが除外から外れることまでは意識していませんでした。
点検の後に変えたこと
- 設定ファイルのバックアップは、リポジトリの外（ホームフォルダの下の作業用の場所）に取る
- リポジトリ自身の
.gitignoreにもsettings.local.json*の形の規則を足し、別のパソコンで使うときにも効くようにする - 点検の2段目のコマンドを、設定を触った日の最後に1回流す
Claude Codeの設定ファイルの置き場所と使い分けそのものは、こちらの記事で詳しく整理しています。
秘密情報が見つかったときの対処の順番
点検で秘密情報が見つかった場合、焦ってファイルを消したくなりますが、順番が大事です。報道で紹介されたApiiroの推奨も、まず鍵の作り直しから始めています。
1. 鍵・パスワードを作り直す（消すより先）
一度コミットした秘密情報は、ファイルを消しても過去のコミット・フォーク・他の人の手元のcloneに残ります。公開リポジトリなら、すでに誰かに読まれた前提で考えます。だから最初にやるのは、その鍵を無効にして新しい鍵を発行することです。データベースのパスワード、APIキー、トークンなど、ファイルに入っていたものは全部対象にします。
2. 追跡をやめる
git rm --cached .claude/settings.local.json
git commit -m "stop tracking settings.local.json"--cachedを付けると、手元のファイルは残したまま、gitの追跡からだけ外せます。Claude Codeの許可の規則はそのまま使い続けられます。
3. リポジトリの.gitignoreに足す
.claude/settings.local.json
.claude/settings.local.json.*グローバルの除外はこのパソコンだけに効くので、リポジトリの.gitignoreにも入れておきます。2行目はバックアップ（.bakなど）を拾うためのものです。
4. 履歴の書き換えは、関係者と相談してから
過去のコミットから秘密情報を消すには、履歴を書き換える必要があります。複数人で使うリポジトリでは、全員のcloneに影響するので、先に相談します。そして、鍵の作り直しが済んでいれば、履歴に残った値はもう使えないので、書き換えは急ぎの作業ではなくなります。順番を守る意味はここにあります。
追跡していると、Claude Codeの扱いも変わる
見落としやすい点をもう1つ。公式の権限のページによると、settings.local.jsonは本来「自分のファイル」として扱われ、そのallowの規則はフォルダを信頼する手順（workspace trust）を待たずに効きます。ところがgitで追跡されていると、リポジトリが用意したファイルとみなされ、信頼の手順を経るまで規則が保留されます。cloneしただけのリポジトリにsettings.local.jsonが入っていた場合、その中の許可を勝手に使われないための仕組みです。追跡をやめることは、漏れを防ぐだけでなく、このファイルを本来の「自分専用」に戻すことでもあります。
そもそも入れないために：Claude Codeでの鍵の渡し方
点検と対処は事後の話です。根っこの対策は、承認するコマンドの文字列に鍵を入れないことです。
鍵はコマンドに直に書かず、環境変数で渡す
シェルの環境変数や、パスワードの管理の道具から読み込む形にしておけば、Claude Codeが組み立てるコマンドはpsql -h db.internal -U app …のように鍵を含まない形になります。承認しても、規則に残るのは鍵の無い文字列だけです。Claude Codeの設定のenvに書く方法もありますが、それは設定ファイルに鍵を書くことになるので、同じ注意が要ります。
APIキーをどこに置くかは、私たちの考え方をこちらにまとめています。
「今後は確認しない」は、文字列を読んでから押す
確認の画面には「Yes, and don't ask again for: …」の形で、保存される範囲が出ます。押す前にこの文字列を読み、鍵やパスワードが見えたら1回だけの承認（Yes）にとどめます。保存された規則は/permissionsで一覧でき、どのファイル由来かも表示されるので、時々見直して不要な規則は消します。
確認の画面の読み方は、こちらの記事で順を追って説明しています。
読ませたくないファイルはdenyで止める
もう1つの入口は、Claude Code自身が秘密情報を読んでしまうことです。公式ドキュメントは、Read(./.env)やRead(./secrets/**)のようなdenyの規則で、Claude Codeのファイルを読む道具から外すことを勧めています。コマンドに鍵が紛れ込む機会そのものを減らせます。
よくある質問
settings.local.jsonをgitignoreに自分で足す必要はありますか？
Claude Codeが最初にファイルを書いた場合は、このパソコンのグローバルの除外に自動で足されます。ただし、手で作ったファイル・別のパソコン・すでにコミットしたファイルには効かないので、複数のパソコンや複数人で使うリポジトリなら、リポジトリの.gitignoreにも足しておくのが確実です。
非公開（private）のリポジトリなら気にしなくてよいですか？
公開リポジトリほど急ぎではありませんが、リポジトリに読める人がいる限り、その人たちには鍵が見えています。退職した人のcloneや、後で公開に切り替えた場合も考えると、見つけたら作り直すのが安全です。
Codexなど他のAIエージェントにも同じ問題はありますか？
今回の調査が対象にしたのはClaude Codeのsettings.local.jsonです。ただ、「承認を設定ファイルに保存する」「その設定ファイルがリポジトリの中にある」という形の道具なら、同じ点検の考え方がそのまま使えます。保存先のファイル名を変えて、2段目のgit ls-filesで探してください。
点検はどのくらいの頻度でやればよいですか？
私たちは、設定ファイルを触った日の最後に2段目のコマンドを1回流すことにしました。毎日やる必要はなく、「設定を直した」「バックアップを取った」「新しいパソコンでcloneした」というきっかけの日に回すのが、手間と効き目のつり合いが取れていると考えています。
まとめ：除外の1行を信じきらず、名前で探す
- 「Yes, and don't ask again」を押すと、承認したコマンドが秘密情報ごとsettings.local.jsonのallowの規則に保存されることがある
- Claude Codeは最初に書くときにグローバルの除外へ1行足すが、効くのはこのパソコンの、Claude Codeが書いたファイルだけ。手で作った・別のパソコン・コミット済み・名前の違うコピーは防げない
- 点検は
git check-ignore -v→git ls-files | grep settings.local→中身は数だけ数える、の3段 - 私たちの点検では、本体は除外されていたが、設定のバックアップが名前の違いですり抜けてコミットされていた（中身に秘密情報は無かった）
- 見つかったら、鍵の作り直し→追跡をやめる→リポジトリの.gitignore→履歴の書き換えの順番
Apiiroの数字は報道経由の値で、Anthropicの公式の見解や修正はこの記事の時点（2026年11月10日）では確認できていません。仕組みは公式ドキュメントで確かめられるので、まずは自分のリポジトリで3段の点検を回してみてください。株式会社Fyveでは、こうしたAIの道具の設定や運用の見直しも含めて、中小企業のAI導入を支援しています。
Claudeのこの5つの設定、今すぐ見直した方がいい
共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ（全28ページ）
2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。
- 見落としやすい共有リストは3つある（3つ目は画面の下）
- 学習をオフにしても残る、公式の例外条項
- 権限モード6つの違いと、Shift+Tabでの切り替え方
- 私が実際に禁止しているコマンド23行を全文公開
メールアドレス登録で他にも様々な資料を閲覧できます
＋11PDF 20点・合計513ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。