APIキーをAIチャットに貼ってはいけません：安全にAIへ渡す方法

AIにアプリを作ってもらっていると、必ずこの場面が来ます。

AIが「APIキーを教えてください」と言ってくる。あるいは、あなた自身が「うまく動かないから、キーごと見せて相談しよう」と思う。

その手を止めてください。 APIキーをチャット欄に貼るのは、この本の中で最もやってはいけないことの1つです。

なぜダメなのか

理由は3つあります。

1つ目。各社が規約ではっきり禁じています。

OpenAIは公式の案内で「APIキーは秘密です。他人と共有したり、ブラウザやアプリなどのクライアント側のコードに露出させたりしないでください」と書いています。ヘルプセンターには、さらに直接的にこう書かれています。「APIキーの共有は利用規約違反です。」

Anthropicも同じです。「自分のパスワードを他人に教えないのと同じように、APIキーを共有しないでください。」

2つ目。チャットの内容は、学習に使われることがあります。

ここが見落とされがちなところです。2026年11月5日時点の各社の扱いは、こうなっています。

特に1行目と5行目に注目してください。Googleは公式の利用規約に、無料枠については「人間のレビュアーがあなたの入力と出力を読み、注釈を付け、処理することがあります」とはっきり書いています。

つまり、無料枠のチャットに貼ったキーは、あなたとAIだけの秘密ではないということです。

3つ目。共有リンクから漏れます。

2025年の夏、実際に事故が起きました。ChatGPTの会話を共有するときに出る「この会話を検索で見つけられるようにする」というチェックボックスをオンにしたまま共有した会話が、Googleの検索結果に載ってしまったのです。報道では約4,500件が検索エンジンに拾われたとされ、OpenAIはこの機能自体を撤去しました。

会話を誰かに見せるつもりがなくても、うっかりの導線は存在します。

漏れたキーが見つかるまでの時間は、20秒です

数字をお見せします。

セキュリティ企業GitGuardian（ギットガーディアン）の2026年の調査によれば、2025年の1年間に、公開されたGitHubのコードに流出したパスワードやAPIキーは2,864万件。前年から34％増えました。そのうちAIサービス関連のキーは127万件で、こちらは81％増です。

そして、もっと怖いのは「漏れたあと、放置される」ことです。同じ調査は、2022年に「有効」と確認された認証情報を追いかけ直しています。2025年1月の時点で約7割がまだ有効で、2026年1月に調べ直しても6割以上が生きていました（これは2025年に漏れた2,864万件のうち何割が有効か、という話ではありません）。

では、漏れたキーはどれくらいの速さで「誰でも拾える状態」になるのか。学術論文（NDSS 2019）では、研究者が自分で用意した文字列をGitHubに公開し、それが検索機能に出てくるまでの時間を実測しています。中央値は20秒。早いときは0.5秒、遅くても4分ほどでした。

これは「悪用されるまでの時間」ではなく、「世界中の誰でも検索で拾える状態になるまでの時間」です。でも、だからこそ怖いのです。あなたが「あ、まずい」と気づいてブラウザを開くころには、もう拾える状態になっています。

実害も出ています。セキュリティ企業トリュフセキュリティが2026年2月に公表した報告では、盗まれたGemini APIキーで48時間のうちに約8万2,000ドル（1,200万円前後）を使われたという開発者の証言が紹介されています。

そしてもう1つ、この本の読者に一番関係する数字を。GitGuardianの同じ調査で、Claude Codeが関わったコミットのキー漏洩率は3.2％でした。公開されているGitHubのコミット全体の基準値が1.5％ですから、およそ2倍です。

ただし、GitGuardian自身が釘を刺しています。「これをツールの失敗と読むべきではない」。 何を受け入れ、何を直し、何を公開するかを最後に決めているのは人間だからです。同社はその背景を「複雑な仕組みの中で、時間に追われた人が目の前だけを見て判断してしまうこと」と説明しています。昔からある失敗の形が、AIで速くなっただけ、ということですね。

正解は「AIにキーを見せないまま使わせる」ことです

ここが一番大事な話です。

実は、AIはあなたのキーの中身を知る必要がありません。

AIがやるのは「キーを使うコードを書く」ことです。そのコードには、キーそのものではなく「あそこに置いてあるキーを読んできてね」という指示だけを書けばいい。そして本物のキーは、あなたが自分の手で別の場所に入れる。これだけです。

具体的な手順はこうなります。

ステップ1：AIにはこう頼む。

「APIキーは環境変数で管理して。コードに直接書かないで。.envファイルは.gitignoreに入れて、.env.exampleにはダミーの値だけ書いて」

この一言があるかないかで、出来上がりは大きく変わります。キーの中身は一度も伝えていません。 ただしAIも完璧ではありませんので、出来上がったコードに本物のキーが書かれていないか、自分の目で一度は確認してください。

ステップ2：本物のキーは、あなたが管理画面に入れる。

公開先のサービスには、必ずキーを安全にしまう場所があります。

• Vercel：Environment Variables（2026年8月から「Secret型」を選ぶと、保存後は自分でも中身を見られなくなります）
• Cloudflare Workers：wrangler secret put キー名（保存後は管理画面にも表示されません）
• Netlify：Environment variables の Secrets Controller（万一ビルド結果に値が混ざると、ビルドを失敗させてくれます）
• Supabase：supabase secrets set

ステップ3：キーそのものに制限と上限をかける。

キーは「漏れない」ことより「漏れても大したことにならない」状態を作るほうが確実です。

OpenAIはプロジェクト単位でキーを分けられ、組織ごと・プロジェクトごとに月の上限を設定できます。ただし設定しただけでは止まりません。 管理画面で「Enforce a hard limit」というスイッチを自分でオンにして初めて、上限に達したリクエストがエラー（429）を返して止まります。オフのままだと通知が飛ぶだけです。しかもOpenAI自身が「上限の適用は即座ではないため、記録される支出が設定額をわずかに超えることがあります」と明記しています。絶対に超えない壁ではなく、暴走を数分で止める非常ブレーキだと考えてください。また2026年9月からは、OpenAIのキーに有効期限を付けられるようになりました。使い終わったキーが、何年も生きたまま残るのを防げます。Anthropicはワークスペース単位で上限を設定できます。Vercel AI Gatewayは、チーム・プロジェクト・キー・ユーザーの4つの単位で予算を設定でき、キー自体に有効期限も付けられます。

Googleはさらに踏み込んでいて、制限のかかっていない古いキーを受け付けなくなりました。 制限をかけてある古いキー（Standardキー）は今も使えますが、2026年5月28日以降にGoogle AI Studioで作るキーは、最初からGemini API向けに絞られた「authキー」になっています。それとは別に、使えるサイトやIPアドレスを限定する設定もかけておくとさらに安全です。

AIコーディングツールは、あなたの.envを読みます

もう1つ、知っておいてください。AIコーディングツールは、あなたのパソコンの中の.envファイルを読むことができます。

対策の名前は、ツールごとに違います。

• Claude Code：.claude/settings.jsonのpermissions.denyにRead(./.env)を追加する
• Cursor：.cursorignoreファイルを置く（既定で.envは除外されています）
• Gemini Code Assist：.aiexcludeファイルを置く

ここで正直にお伝えしておきます。Codexには、この種の除外ファイルは公式に用意されていません。 ネット上には「.codexignoreを作りましょう」という記事がありますが、公式ドキュメントにそのような仕組みの記載はなく、あるのはサンドボックスと承認設定だけです。

そして、Claude Codeの公式ドキュメント自身が限界を認めています。除外の設定は、AIが直接ファイルを開く場合には効きますが、AIが書いたスクリプトが裏でファイルを読むところまでは止められません。

ですから、こう考えてください。除外ファイルは保険であって、壁ではありません。 本当の壁は、「そもそも本番の生きたキーが、手元のパソコンに置いてある状態を作らない」ことです。

もう貼ってしまった、と気づいたら

順番が決まっています。慌てず、この順で。

1. 真っ先に、そのキーを無効化（revoke）する。

作り直すより先に、まず殺す。OpenAIは公式に「キーの無効化は数秒で反映されます」と案内しています。

GitHubは公式文書でこう断言しています。「漏れた秘密情報は、その瞬間に危険にさらされたものと考えるべきです。」そして「コードから消す、新しくコミットし直す、リポジトリを作り直す——これらはいずれも悪用を防ぎません。」

2. 新しいキーを発行し、正しい置き場所に入れ直す。

3. 利用状況と請求画面を確認し、ついでに上限を設定する。

4. 最後に、コードの履歴から消す。

一度公開した履歴は、コミットを消しただけでは残ります。フォーク、クローン、キャッシュ、プルリクエストの参照——あちこちに残るからです。GitHubが現在推奨しているのはgit-filter-repoというツールです（古い記事にあるBFGは、今の公式ドキュメントには載っていません）。

なお、公開リポジトリであれば、GitHubの「シークレットスキャン」と「プッシュ保護」が無料で働きます。OpenAIやAnthropicはこの仕組みの提携先なので、キーが公開リポジトリに上がると各社に通知が行き、自動で無効化されることがあります。

これは心強い仕組みです。ただし、決定的な弱点があります。

チャット欄に貼ったキーは、この仕組みが一切見ていない場所に行きます。

だからこそ、貼らないことが唯一の対策なのです。