| 公開GitHubの許可ファイルで本物の鍵が見つかった数 | 1,122個 |
|---|---|
| AI求人2,697件のうちClaude Codeの名前が出た数 | 464件 |
- 「今後は聞かない」を選ぶと、許可したコマンドはリポジトリ直下の.claude/settings.local.jsonに残る
- 11月5日の調査で、GitHubに公開されたこのファイル104,185個のうち1,122個に本物の鍵があった
- 自分のリポジトリに入っていないかを確かめる3つのコマンドと、Claude Codeに頼むプロンプト
- 編集部の再現では、全体の除外リストが無いMacで git add . をするとダミーのパスワードごと入った
- 主要5本の開発AIのうち、許可をリポジトリの中に書くのはClaude Codeだけ
- ClaudeとChatGPTに保存先を聞いた結果と、今日やっておく5つの手順
米国のセキュリティ会社Apiiroが11月5日に、Claude Codeの許可の記録から鍵が漏れていたと公表しました。GitHubに公開された.claude/settings.local.jsonは、調べた時点で104,185個です。
そのうち1,122個に本物の鍵やパスワードが入っていました。Anthropicの公式の対策は、11月8日時点でまだ発表されていません。
AInformationは11月8日にAnthropicの公式ドキュメントを読み、編集部のMacで同じ状況を再現しました。まず自分のリポジトリを確かめる方法から書きます。
Claude Codeの許可が漏れていないかは3つのコマンドで確かめられる
確かめるのは、リポジトリの直下にある.claude/settings.local.jsonです。Claude Codeで許可したコマンドは、ここに貯まっていきます。
リポジトリのいちばん上のフォルダで、次の3つを順に打ってください。どれもファイルの中身は画面に出しません。
git ls-files .claude/settings.local.json
git log –all –oneline — .claude/settings.local.json | head
git check-ignore -v .claude/settings.local.json || echo 除外の設定なし
- 1行目で名前が出たら、そのファイルはいまGitに入っています。何も出なければ入っていません
- 2行目で1行でも出たら、過去にコミットされています。いま入っていなくても昔の版は残ります
- 3行目で「除外の設定なし」と出たら、除外の設定がありません。このままだと git add . で一緒に入ります
1行目と2行目で何も出なければ、Gitに入ったことはありません。3行目で「除外の設定なし」と出た人は、リポジトリの.gitignoreへの追記も済ませてください。
Claude Codeに確かめさせるプロンプト
自分で打つのが不安なら、Claude Codeに頼んでもかまいません。ただし中身を表示させると、鍵が会話の画面に出てしまいます。数と場所だけを答えさせるのがコツです。
このリポジトリの .claude/settings.local.json について、次の3つを確かめてください。
1. git ls-files で、いまGitに追跡されているか
2. git log –all で、過去のコミットに入ったことがあるか
3. git check-ignore -v で、除外の設定があるか
ファイルの中身は画面に出さないでください。allow の中にパスワード・APIキー・トークンらしい文字列が何本あるかだけを数え、見つかったら行番号だけを教えてください。
1つでも当てはまったら、次の順で直します。先に鍵を作り直し、そのあとでファイルをGitから外します。
- 鍵やパスワードを発行元で作り直し、古いものを止める
- git rm –cached .claude/settings.local.json でGitから外す。手元のファイルは消えない
- リポジトリの.gitignoreに.claude/settings.local.jsonの1行を書いてコミットする
鍵を先に作り直すのは、Gitから外しても昔の版に残るからです。このことは後半の再現の章で確かめています。
Apiiroが数えた104,185個のうち1,122個に本物の鍵があった
Apiiroは11月1〜3日に、公開GitHubにある.claude/settings.local.jsonを集めました。見つかったのは104,185個で、入っていたリポジトリは103,617です。
そのうち1,122個、割合で1.1%に本物の鍵やパスワードがありました。重なりを除いた秘密の数は1,379件です。
いちばん多いのはデータベースのパスワードで、379件ありました。Supabaseのサービスキーが122件で、Supabaseのアカウントトークンが103件と続きます。
ほかにSSHのログインが43件、GitHubやGitLabやnpmのトークンが42件ありました。AWSの鍵は23件で、秘密鍵も6件見つかっています。
鍵が入っていた1,105のリポジトリのうち539では、Claudeが共同作成者に入ったコミットがこのファイルを変えていました。
Apiiroの数字で分かっていないこと
- 本物の鍵かどうかは、Apiiroが形式や接続先から判断したもの。実際に使える鍵かは確かめていない
- この鍵で被害が出た件数は、公表されていない
- 1,122個のうち日本の利用者のものが何個あるかは分からない
つまりこの数字は、使えそうな形で公開の場所に置かれていた件数です。被害の件数ではありませんが、置かれていた間は誰でも読めました。Claude Codeの情報漏洩は、会話ではなく許可の記録という意外な場所から起きていたことになります。
「今後は聞かない」の許可はsettings.local.jsonに文字で残る
Anthropicの公式ドキュメントの設定のページには、保存先がはっきり書かれています。Bashのコマンドの許可で「Yes, and don’t ask again」を選んだ場合です。
するとそのコマンドが、allowルールとして.claude/settings.local.jsonに保存されます。日本語にすると「はい、次からは聞かないで」という選択です。
Bashのコマンドの許可はリポジトリごとに永久に効く
許可がいつまで効くかは、権限のページに表で載っています。Bashのコマンドは、リポジトリとコマンドごとに永久に効きます。ファイルの編集の許可は、セッションが終わるまでです。
v2.1.211からは、サブフォルダで起動してもファイルはリポジトリの一番上に置かれます。許可はリポジトリ全体に効き、それより前の版は起動したフォルダに置いていました。
Gitから外す仕組みはパソコン全体の除外リストだけ
Claude Codeは初めてこのファイルを書くとき、パソコン全体のgitの除外リストに1行足します。リポジトリの.gitignoreには書きません。
- 足す1行：**/.claude/settings.local.json
- 足す場所：gitの設定のcore.excludesFile。決めていなければ~/.config/git/ignore
- 手で作ったファイル：Claude Codeがまだ書いていないなら、自分で.gitignoreに足す
守りは、そのパソコンの中の1行だけです。リポジトリには何の印も残らず、この1行が無いパソコンでは git add . で一緒に入ります。
VS Codeの拡張なら、許可のカードで保存先のファイルを選べる作りです。チームで共有する.claude/settings.jsonを選ぶと、全員のルールが変わります。
編集部の再現では5つの場面のうち3つでGitに残った
11月8日に、編集部のMacで空のリポジトリを作って試しました。許可の画面で押す代わりに、Claude Codeが書くのと同じ形でファイルを作っています。
allowの中身は、ダミーのパスワードを入れたpsqlのコマンドです。除外リストがある場面では、Claude Codeが足すのと同じ1行を入れて比べました。
5つの場面でダミーのパスワードがGitに入ったか
| 場面 | git statusの表示 | Gitに入ったか |
|---|---|---|
| ① 全体の除外リストが無い（編集部のMac） | 未追跡のファイルとして出た | 入った（git add .で一緒に） |
| ② 全体の除外リストに1行ある | 出なかった | 入らなかった |
| ③ 先にコミットしてから除外リストを足す | 変更ありと出た | 入った（足した許可もコミット） |
| ④ git rm –cachedで外したあと | 出なかった | 過去の版にそのまま残った |
| ⑤ リポジトリの.gitignoreに書く | 出なかった | 入らなかった |
①は、編集部のMacそのままの状態です。このMacには全体の除外リストのファイルが無く、git add .でダミーのパスワードごと入りました。
いちばん気をつけたいのは③です。一度でもコミットされたファイルは、除外リストに書いても追跡が続きます。あとから許可したコマンドも、次のコミットで一緒に上がりました。
④は、git rm –cachedでGitから外した場面です。それでも過去のコミットを開くと、ダミーのパスワードはそのまま読めました。
Apiiroの調べでも過去の版に734件が残っていた
- ファイルの過去の版に残っていた本物の秘密：734件
- そのリポジトリの数：509
- いまのファイルから消えていても、履歴を開けば読める
⑤のように、リポジトリの.gitignoreに書けば入りません。この1行はリポジトリと一緒に配られるので、チームの全員に効きます。
編集部のMacでは20個のうち14個がGitに入っていた
同じ11月8日に、編集部のMacにあるsettings.local.jsonを全部数えました。結果は次のとおりです。
- 見つかったファイル：20個。許可のルールは合わせて565本
- Gitに追跡されていたもの：14個。社内の2つの非公開リポジトリの写し
- 鍵やパスワードらしい文字列：過去の版も含めて0本
- 作業フォルダの場所を丸ごと書いたルール：80本
14個は、作業のたびにリポジトリを取り込んだ写しでした。もとのリポジトリにファイルが入っていたので、写しにも最初から入っています。
どちらのリポジトリでも、このファイルを変えたコミットにClaudeが共同作成者として入っていました。Apiiroが539のリポジトリで見たのと同じ形です。
鍵は0本でしたが、それは許可したコマンドにパスワードが無かっただけです。1回でもパスワード入りのコマンドを許可していれば、社内のリポジトリに上がっていました。
鍵が無くてもフォルダの場所と案件名が読める
565本のうち80本は、作業フォルダの場所を丸ごと書いたルールでした。フォルダ名には案件名や取引先の名前が入りがちです。外に出れば、何の仕事をしているかが読まれます。
Bashのルール476本のうち132本は、*を使わずにコマンドを丸ごと写した形でした。許可した瞬間の文字が、そのまま残ると考えてください。
もう1つ分かったのは、このMacに全体の除外リストが無かったことです。Claude Codeは毎日動いていますが、公式に書かれた1行はどこにもありませんでした。理由は分かっていません。
主要5本のうち許可をリポジトリの中に書くのはClaude Codeだけだ
ほかの開発AIも、許可したコマンドを記録します。違うのは置き場所で、11月8日に各社の公式ドキュメントで確かめました。
AInformationのツールデータベース508本のうち、開発のAIは49本です。そのうち求人で名前の多い4本に、Gemini CLIを足した5本を比べています。
主要5本の開発AIの許可の保存先
| ツール | 許可を押したときの保存先 | リポジトリの中か |
|---|---|---|
| Claude Code | .claude/settings.local.json | 中（リポジトリの直下） |
| Codex | ~/.codex/rules/default.rules | 外（ホーム） |
| Gemini CLI | ~/.gemini/policies（ユーザーの層） | 外（作業フォルダの層は今は無効） |
| Cursor | 画面の設定 | 外（手で作るpermissions.jsonは作業フォルダにも置ける） |
| GitHub Copilot（VS Code） | ユーザー設定のchat.tools.terminal.autoApprove | 外（ユーザー設定） |
Codexはホームのdefault.rulesに書く
Codexは画面で許可リストに足したコマンドを、ホームの~/.codex/rules/default.rulesに書きます。リポジトリの.codex/rulesは、そのフォルダを信頼したときだけ読みます。
Gemini CLIは作業フォルダの層が今は動かない
Gemini CLIの許可のルールは、ホームの~/.gemini/policiesに置きます。作業フォルダの層もありますが、公式は今は動かないと書いています。
「今後のセッションでも許可」を選んだときのファイル名は、公式には書かれていません。ユーザーの層に入るとだけあります。
CursorとGitHub Copilotは画面の設定に持つ
- Cursor：許可リストは画面の設定にある。ファイルなら~/.cursor/permissions.jsonと、作業フォルダの同じ名前のファイルを読む
- GitHub Copilot：VS Codeで端末の「Always Allow」を押すと、ユーザー設定が書き換わる。書き換わるのはchat.tools.terminal.autoApproveという設定
Cursorで「Always run」を押した許可がどのファイルに残るかは、公式に書かれていませんでした。VS Codeのページは、手元の端末の許可はユーザー設定とそろうと書いています。
ホームやユーザー設定に置くなら、git add .で拾われる心配はほぼありません。作業の中で書いたファイルをリポジトリの中に置くのは、5本のうちClaude Codeだけです。
AI求人2,697件のうち464件がClaude Codeの名前を出している
日本でもClaude Codeを仕事で使う会社は多くあります。AInformationのAI求人2,697件を11月8日に数えると、464件にClaude Codeの名前が出ていました。
- Claude Code：464件
- ChatGPT：397件
- Cursor：336件
- GitHub Copilot：244件
- Codex：163件
求人に名前が出る開発AIの中では、Claude Codeがいちばん多い結果でした。ChatGPTの397件より多く、開発の現場で広く使われているのが分かる数字です。
使う人が多いほど、同じ設定のまま社内のリポジトリが増えていきます。誰か1人が押した許可も、コミットされればリポジトリを見られる全員に見えます。
とくに気をつけたいのは、業務委託や副業で複数の会社のリポジトリを触る人です。パソコンごとに設定が違うので、除外リストの1行があるとは限りません。
ClaudeとChatGPTは保存先を当てたがClaudeは除外の仕組みを外した
11月8日に、ClaudeとChatGPTへ同じ質問を投げました。「Yes, and don’t ask again」の許可はどこに保存され、GitHubに上がることはあるかという質問です。
保存先は、どちらも.claude/settings.local.jsonと答えました。差が出たのはGitから外す仕組みです。
Claudeは、作るときに「.gitignoreに追加する」と答えました。公式はリポジトリの.gitignoreではなく、パソコン全体の除外リストに足すと書いています。
ChatGPTは、全体の除外リストに足す1行まで公式どおりに答えました。ただ答えが出るまでに200.4秒かかり、Claudeは39.1秒でした。
ClaudeとChatGPTの答えを公式と比べた結果
| 質問と答えたAI | 保存先 | Gitから外す仕組み | 公式と違った所 |
|---|---|---|---|
| Claude Codeの保存先（Claude） | ○ .claude/settings.local.json | × .gitignoreに足すと答えた | 除外の場所 |
| Claude Codeの保存先（ChatGPT） | ○ .claude/settings.local.json | ○ 全体の除外リスト | なし |
| Codexとの違い（ChatGPT） | ○ ~/.codex/rules/default.rules | ○ 全体の除外リスト | 信頼の条件に触れず |
| DBのパスワードの渡し方（Claude） | × 許可の記録に触れず | × 触れず | 4点のうち1点だけ |
どちらの答えも、11月5日のApiiroの公表には触れていません。ChatGPTは平文で残る危険を書きましたが、出典は公式でない日本語のサイトでした。
データベースのパスワードの渡し方は4点のうち1点だけ
Claudeには、データベースのパスワードを使うコマンドの安全なやり方も聞きました。答えの中心は、.pgpassや.my.cnfのような認証ファイルを使う方法です。
編集部が見た4つの点と比べると、入っていたのは環境変数で渡すことの1つだけでした。許可の記録にコマンドが残ることには触れていません。
- 許可したコマンドがsettings.local.jsonに残る：触れず
- パスワードを環境変数で渡す：触れた
- Bash(npm run *)のような型で許可する：触れず
- Read(./.env)の拒否のルールで読ませない：触れず
ChatGPTにはCodexとの違いも聞きました。Codexの保存先は~/.codex/rules/default.rulesと公式どおりでした。ただリポジトリの.codex/rulesを信頼したときだけ読む条件には触れていません。
settings.local.jsonに秘密を残さない許可の書き方は4つある
秘密を残さないコツは、許可するコマンドに秘密を入れないことです。次の4つを組み合わせます。
- パスワードはコマンドに書かず、$DATABASE_URLのような環境変数の名前で渡す
- 許可はBash(npm run *)のような型で書き、毎回違う長いコマンドを丸ごと許可しない
- .envやsecretsのフォルダは、Read(./.env)のような拒否のルールで読ませない
- リポジトリの.gitignoreに.claude/settings.local.jsonを書き、チームの全員に効かせる
Claude Codeに足してもらう設定の例
チームで共有する.claude/settings.jsonに足す例です。Bash(npm run *)とRead(./.env)の形は、Anthropicの権限のページに載っている書き方です。
.claude/settings.json の permissions に、次のルールを足してください。ほかの設定は変えないでください。
allow に足す：Bash(npm run *)
deny に足す：Read(./.env) と Read(./secrets/**)
足したあと、ファイルの permissions の部分だけを見せてください。
Claude Codeにこの文で頼めば、設定に書き足してくれます。このファイルはリポジトリに入るので、中に秘密は書きません。許可を足すときも型だけを書くようにしましょう。
Claude Codeに渡しておく決まりのプロンプト
毎回の会話で気をつけてもらうなら、CLAUDE.mdに決まりを書いておきます。次の文をそのまま貼れます。
このリポジトリでは、パスワード・APIキー・トークンをコマンドの中に直接書かないでください。接続や認証が要るときは、$DATABASE_URL のような環境変数の名前だけを使います。.env と secrets/ の中身は読まないでください。許可を求めるときは、npm run のような決まったコマンドにまとめてから聞いてください。
- 決まりを書いても、Claudeが必ず守るとは限らない。最後は人が許可の画面でコマンドを読む
- コマンドの中にパスワードやトークンが見えたら、「Yes, and don’t ask again」は押さない
- そのときは1回だけ許可するか、断って環境変数で書き直させる
検出ツールは215個を見逃したので鍵の作り直しを先にする
鍵がGitに入っていたら、最初にやるのは鍵の作り直しです。Gitから外しても、昔の版に残るからです。
Apiiroは秘密を探すツールも試しています。鍵が入った1,122個のうちgitleaksが見つけたのは564個です。TruffleHogは643個で、215個はどちらも見逃しました。
ツールで何も出なくても、鍵が無いとは言い切れません。allowの中身は、自分の目でも1行ずつ読んでください。
- データベースのパスワード：管理画面で変え、古いもので接続できないか確かめる
- Supabaseのサービスキーとトークン：作り直して古いものを止める
- GitHub・GitLab・npmのトークン：取り消してから作り直す
- AWSの鍵と秘密鍵：止めてから新しいものを発行する
履歴からの削除は、鍵を作り直したあとで行えば十分です。公開のリポジトリだったなら、すでに誰かが写した前提で動いてください。
11月8日時点でAnthropicの対策は無く今日やる手順は5つだ
Anthropicの公式の対策は、11月8日時点でまだ出ていません。秘密を自動で見つける仕組みが入るのか、入るならいつかも公表されていません。送信の前の確認の機能のように、試験の版から安定版まで時間がかかる例もあります。
対策を待つより、手元を先に確かめるほうが早く済みます。今日やっておくことは次の5つです。
- 使っているリポジトリごとに git ls-files .claude/settings.local.json を打つ
- 出てきたらallowの中身を読み、パスワードやトークンの入ったルールを探す
- 見つかった鍵は発行元で作り直し、古いものを止める
- git rm –cachedでGitから外し、リポジトリの.gitignoreに1行書く
- 次からはパスワードを環境変数で渡し、許可はBash(npm run *)のような型で書く
チームで使っているなら、同じ確認を全員に頼んでください。除外リストは各自のパソコンの中にあるので、1人が直しても他の人には効きません。
Codex・Gemini CLI・GitHub Copilotは、許可をホームやユーザー設定に置きます。ただしCursorも作業フォルダのpermissions.jsonを読むので、そこに秘密を書かない点は同じです。
※記事の事実とは分けて、筆者の考えを書いています。
分析・考察許可の画面で「今後は聞かない」を押すのは、作業を止めないための普通の操作です。問題は押した中身がリポジトリの中に残り、守りが各自のパソコンの設定に頼っている点にあります。
会社で使うなら、パスワードをコマンドに書かない決まりを先に作るのがいちばん効きます。そのうえで月に1回、git ls-filesで確かめる習慣を付けておくと安心です。
- Claude Codeの「Yes, and don't ask again」は押さないほうがいいですか？
- 押してもかまいませんが、コマンドの中身を読んでからにしてください。許可したコマンドは.claude/settings.local.jsonに文字のまま残ります。パスワードやトークンが見えるコマンドは1回だけ許可するか、環境変数で書き直させます。npm runのような決まったコマンドなら、押しても秘密は残りません。
- 非公開のリポジトリなら鍵が入っていても大丈夫ですか？
- 外の人には見えませんが、安心はできません。リポジトリを見られる社員や外注先には、鍵がそのまま読めます。編集部のMacでも、社内の非公開リポジトリの写しで20個のうち14個がGitに入っていました。鍵が入っていたら、非公開でも作り直すのが安全です。
- .gitignoreに書けば過去にコミットした分も消えますか？
- 消えません。編集部の再現では、先にコミットしたファイルは除外の1行を足しても追跡が続きました。git rm –cachedで外す必要があります。外しても過去のコミットには残るため、入っていた鍵は先に作り直してください。
- CodexやCursorに乗り換えれば安全ですか？
- 保存先だけ見れば、Codexはホームの~/.codex/rules/default.rulesに書くのでGitに入りにくい作りです。ただしCursorは作業フォルダの.cursor/permissions.jsonも読みます。どのツールでも、コマンドにパスワードを書かないことがいちばんの対策です。乗り換えより先に、手元のリポジトリを確かめてください。
