その鍵、どこに残る？ AIのチャットやGitHubに鍵を書いてはいけない仕組み

「Claude Code や Codex のチャットに API キーを書いてはいけない」「GitHub に鍵を置くなんて絶対にだめ」。開発の現場ではよく言われますし、うっかりすると AI に「漏洩しました」と指摘されたり、サービスから警告の通知が届いたりします。

では、具体的にどこで、どのようにだめなのでしょうか。この記事では、鍵の文字がどこへ運ばれて、どこに残るのかという流れで、その仕組みを順に説明します。

まず前提：API キーは「合鍵」

API キーやトークンは、家の合鍵のようなものです。持っている人なら誰でも、本人のふりをしてサービスを使えます。サービスの側は、鍵そのものからは、本人が使ったのか、合鍵を拾った人が使ったのかを見分けられません。

ですから大事なのは、合鍵の複製をどれだけ作らないかです。この先の話は、すべて「どこに複製ができるか」という見方で読んでください。

チャットに書くと、どこへ運ばれるのか

打った文字は、AI会社のサーバーへ送られる

Claude Code や Codex の画面で文字を打つと、手元のパソコンの中だけで処理されるように見えます。実際には、次のように動いています。

1. 入力した文字が、インターネットを通って AI会社のサーバーへ送られる
2. サーバーにある AI の本体が返事を作り、手元へ送り返す
3. 手元のパソコンに、会話の記録が保存される

AI の本体は、Anthropic や OpenAI のコンピューターの中にあります。そのため、チャットに入力した文章は会社のサーバーへ送られます。鍵を書くと、この時点で合鍵の複製が次の2か所にできます。

• AI会社のサーバー：会話は一定期間保存されます。Claude Code の場合、個人向けプランは学習への利用を許可していれば5年、許可していなければ30日。法人向けや API の標準は30日です。会話を削除しても、サーバー側から消えるまでには最大30日かかります。Codex は、サインインの方法で適用されるデータの扱いが変わります。ChatGPT のアカウントで使う場合は ChatGPT 側の設定に従い、個人プランでは学習への利用が既定でオンです
• 自分のパソコンの記録：Claude Code は会話の記録を、暗号化しない普通の文字のまま ~/.claude/projects/ に保存し、既定で30日残します。バックアップを取れば、バックアップにもコピーされます

いちばん怖いのは、AI が書き写すこと

複製は、この2か所で終わるとは限りません。会話が続いているあいだ、AI はその鍵を覚えていて、作業の材料として使えます。鍵を知っていれば、悪気なく次のように動くことがあります。

• プログラムに鍵をそのまま書き込む
• 「このキーで動作を確認しました」とメモに残す
• そのファイルを GitHub に上げる

AI が書き写したファイルは、3つ目の複製になります。

チャットに書いた鍵が、AI の手を経て GitHub に漏れる。これが起こりやすい事故の流れです。

.env を読ませるのも同じ

見落とされやすいのですが、鍵を入れた .env ファイルを AI に読ませたり、AI に cat .env を実行させたりするのも、チャットに貼るのと同じです。AI が読んだ文字は、AI会社のサーバーへ送られ、会話の記録に残ります。

Claude Code では、権限の設定に Read(./.env) や Read(./.env.*) のような禁止ルールを書くと、AI が .env や .env.local を読むのを止められます。ただし、スクリプトが自分でファイルを開く場合などには効かないと、公式の文書にも書かれています。設定だけに頼らず、AI に読ませたくない鍵は作業フォルダの外に置くなど、ほかの工夫と組み合わせます。

通信の途中で盗まれることはないのか

ここまで読むと、「送る途中で盗まれる心配はないのか」と気になるかもしれません。こちらは、普通の使い方ではほぼ心配いりません。

Claude Code と Anthropic のサーバーの間の通信は、TLS という仕組みで暗号化されています。銀行のサイトやネットショップの HTTPS と同じ仕組みで、宅配便にたとえると「暗号の箱」です。TLS には2つの働きがあります。

1. 中身を読めない：箱を開けられるのは、届け先のサーバーだけです。カフェの Wi-Fi や回線の業者が通信をのぞいても、意味のない文字の羅列にしか見えません
2. 届け先が本物か確かめる：通信を始める前に、相手が本物のサーバーかどうかを証明書で確かめます。偽のサーバーが割り込んでくると、そこで接続が止まります

つまり、チャットに鍵を書いてはいけない理由は、途中で盗まれるからではありません。届け先と手元に、読める形で残るからです。

ただし、この守りが効かなくなる場面もあります。

• 会社のネットワークの検査装置：一部の会社は、社員の通信をいったん開けて中身を検査し、もう一度箱に詰め直す装置を置いています。この装置には中身が見えます
• パソコンに不正な証明書が入れられている：怪しいソフトが「偽の届け先を本物だと信じさせる仕組み」をこっそり入れると、途中で箱を開けられてしまいます
• 証明書の警告を無視して進む：「この接続は安全ではありません」という警告を無視すると、偽の相手に送ってしまうおそれがあります
• 暗号化されていない接続先：https ではなく http の接続先や、http で動かしている自作の連携ツールとの通信は箱に入らず、中身が丸見えになります
• パソコン自体が乗っ取られている：箱に入れる前の段階で読まれるので、暗号化は役に立ちません

なお、プログラムが API キーを使ってサービスを呼び出すときも、キーは毎回この暗号の箱で送られています。キーが通信路を通ること自体は、正しい使い方の一部です。問題は通るかどうかではなく、運ばれた先で読める形のまま残るかどうかです。

GitHub に置くと、どうなるのか

Git は「消しゴムで消せない日記帳」

Git は、ファイルを保存（コミット）するたびに、その時点の写しを履歴として残す仕組みです。消しゴムで消したつもりでも、記録そのものは消えません。

• 1日目に鍵を書いて保存すると、その写しがずっと残る
• 2日目に鍵を消して保存しても、「消した」という新しいページが増えるだけ

2日目に消しても、1日目のページはめくれば読めます。しかも、GitHub からダウンロード（clone）した人のパソコンには、日記帳がまるごとコピーされています。GitHub の公式文書も、履歴を書き換えたあとでさえ、ほかの人の clone や fork などに残りうると説明しています。配った写しは回収できません。

公開リポジトリは「見張られている掲示板」

GitHub の公開リポジトリは、世界中から見えます。そして、鍵の形をした文字列を自動で探し続けるプログラムがあります。多くの鍵には、サービスごとに決まった書式があるので、機械で見つけやすいのです。

• 2019年の研究では、push した文字列が GitHub の検索で見つけられるようになるまでの時間は、中央値で約20秒でした。これは誰でも探せる状態になるまでの時間で、悪用されるまでの時間ではありません
• セキュリティ企業の Unit 42 が2023年に公開した調査では、研究者がわざと公開リポジトリに置いた AWS の鍵（おとり）を、攻撃者は5分以内に見つけて使い始めました

「少しのあいだだけなら」は通用しません。

「漏洩しました」の通知が届く仕組み

鍵を探しているのは、悪い人だけではありません。GitHub 自身も、公開リポジトリで鍵の形をした文字列を探しています（secret scanning）。提携しているサービスの鍵を見つけると発行元へ知らせ、発行元が鍵を無効にしたり、利用者へ警告したりします。発行元が自分で見張っている場合もあり、Unit 42 の調査では、AWS がおとりの鍵の権限を2分以内に自動で制限していました（研究者は攻撃者の動きを観察するため、この制限を手で外しています）。

サービスから届く「鍵が漏れています」という通知は、この仕組みから来ています。また GitHub には、公開リポジトリへの push の時点で鍵を見つけて止める仕組み（push protection）もあります。

ただし、どちらにも限界があります。secret scanning が見つけるのは、決まった書式に合う鍵が中心で、どんな秘密の値でも見つかるわけではありません。push protection は、利用者の判断で止めずに通すこともできます。頼れる守りではなく、そもそも置かないことが前提です。

非公開リポジトリなら大丈夫？

安全とは言えません。メンバー全員、連携している外部サービス、辞めた人の手元に残った clone、将来うっかり公開に切り替えたとき、と読める経路がたくさんあります。読める人やシステムの数だけ、漏洩の入り口があると考えてください。

なぜ「消す」ではなく「作り直す」のか

ここまでの仕組みをまとめると、次のようになります。

• チャットに書いたら、AI会社のサーバーと、自分の記録と、AI が書き写したファイルに複製が残る
• GitHub に置いたら、履歴と、ほかの人の手元に複製が残る

どちらも、複製がいくつあり、誰が見たのかを、すべて確かめきる方法はありません。合鍵を落としたとき、「たぶん拾われていない」で済ませる人はいないはずです。錠前ごと交換します。

API キーも同じで、本来の送り先以外に一度でも書いてしまったら漏れたものとして扱い、古い鍵を無効にして新しい鍵を作ります。GitHub の公式文書も、秘密の値が漏れたときは、履歴を消すより先に失効とローテーションを行うよう案内しています。

AI が「漏洩した」と言うのは、誰かに盗まれたと断定しているわけではありません。盗まれていないと言い切れなくなったという意味です。

正しい渡し方

ポイントは、AI に鍵の文字そのものを見せないことです。

• 置き場所を決める：鍵は、公開先のサーバー（デプロイ先）の環境変数や、シークレットの管理機能に置きます。手元で使う鍵は、Git の管理から外したファイル（.gitignore に入れた .env.local など）やパスワード管理ツールに置きます。ファイルの権限を自分だけにしても、AI ツールは自分と同じ権限で動くので、AI からは読めます。先ほどの禁止ルールと組み合わせて、AI に読ませないようにします
• 値は人が書き込む：鍵をファイルへ入れる作業は、人が自分のエディタやターミナルで行うのが確実です。先ほどの禁止ルールを設定していると、AI はそのファイルへの書き込みも止められます。Claude Code の読み取りの禁止ルールは、同じファイルへの書き込みや、コマンドの出力先にも効くためです
• AI に任せる場合も、値を見せない：禁止ルールを設定していないファイルへ AI に書き込ませる場合は、人が発行画面で鍵をコピーし、AI には「クリップボードの中身を、画面に表示せずにファイルへ書き込む」コマンドを使わせます。AI が確かめるのは、書き込めたかどうかと、鍵の書式（先頭の文字列など）が正しいかどうかだけです
• 書き込んだあとも気をつける：どちらの方法でも、書き込みの操作で鍵の文字を表示しなければ、その操作でチャットや会話の記録に値が渡ることはありません。ただし、あとで AI がそのファイルを読めば、値は会話へ送られます。書き込んだファイルは AI に読ませないようにします。また、クリップボードにも一時的な複製ができます。書き込んだらクリップボードを別の文字で上書きし、クリップボードの履歴や端末間の共有を使っている場合は、そこにも残さないようにします
• うっかり貼ってしまったら：会話を消すのではなく、すぐにその鍵を発行元で無効にし、作り直してください

鍵の扱いで迷ったときは、「この操作で、鍵の複製がどこに増えるか」を考えてみてください。複製が自分の管理の外に出るなら、それは避けるべき操作です。