AIに話しかけながらアプリを作る「バイブコーディング」で、動かすために言われるままAPIキーをチャットに貼ったり、コードに直接書いたりしてしまった。後から「あれは人に見せてはいけないものだった」と知って、慌てて検索している方も多いのではないでしょうか。
「AIで作ったアプリのAPIキーをチャットやコードに書いてしまった。GitHubにも上げた気がする…どうすればいいの？」
先に結論です。まずやるべきことは「書いた場所から消すこと」ではなく、「そのキーを使えなくして、新しいキーに取り替えること」です。消すだけでは、すでに誰かにコピーされていた場合に防げないためです。取り替えたら、利用状況と請求を確認し、今後はコードにキーを書かない仕組みに切り替えます。
この記事では、APIキーの漏洩に気づいた非エンジニアの方に向けて、今すぐやる対処の順番、誰に連絡するか、再発防止の方法、開発会社に頼むべきタイミングを、チェックリストと質問例つきで解説します。
APIキーの漏洩で困ること：短い回答
APIキー（＝外部サービスを使うときに「私です」と証明する合鍵のような文字列）は、パスワードと同じくらい大切な秘密情報です。キーを知っている人は、あなたになりすましてそのサービスを使えてしまいます。
漏れたときに起こりうることは、主に次の3つです。
| 起こりうること | 具体的なイメージ |
|---|---|
| 不正利用 | 他人があなたのキーでAIのAPIや地図・メール配信などのサービスを使う |
| 高額請求 | 従量課金（＝使った分だけ払う料金）のサービスでは、他人の利用分もあなたの請求になりうる |
| データ流出・改ざん | データベースや顧客管理サービスのキーなら、保存されている情報を見られたり書き換えられたりするおそれ |
どのくらいの被害になるかは、キーの種類と与えられている権限によって大きく変わります。だからこそ「どのキーが、どこに、いつから出ていたか」を落ち着いて確認することが大切です。
なぜ「消すだけ」では不十分なのか
「コードからキーを消して保存し直したから大丈夫」と考えがちですが、多くの場合それだけでは足りません。
GitHubに上げた場合は履歴に残る
GitHub（＝コードを保存・共有するサービス）では、ファイルの変更履歴がすべて残ります。最新のコードからキーを消しても、過去の履歴をたどればキーが見える状態です。
さらに、公開リポジトリ（＝誰でも見られる状態のコード置き場）だった場合、すでに第三者にコピーされている可能性もあります。GitHubの公式ドキュメントも、履歴を書き換えるより先に、キーを無効にすることを最初の対応として案内しています。
📰 出典：GitHub Docs「リポジトリからの機微なデータの削除」
同ドキュメントでは、シークレット（＝キーやパスワードなどの秘密情報）を失効またはローテーション（＝古いキーを無効にして新しいキーに取り替えること）すればアクセスには使えなくなり、それで十分な場合もあると説明しています。また、履歴を書き換えて上書きしても、他の人が作ったコピー（クローン・フォーク）やプルリクエストなどから、キーを含むデータにアクセスできる可能性があるとしています。
AIのチャットに貼った場合も「取り替え」が基本
AIチャットに貼ったキーは、会話履歴として保存されている可能性があります。会話を削除できるサービスもありますが、データがどのように保存・利用されるかはサービスや契約プランによって異なり、利用者側で完全に確認するのは難しいのが実情です。
チャットの画面を同僚と共有した、共有リンクを発行した、といった場合はなおさらです。「どこかに書いた・貼ったキーは、漏れたものとして扱い、取り替える」と考えるのが確実です。
今すぐやる対処：5つのステップ
ここからは、気づいた時点ですぐに取りかかる順番です。慌てて一度にやろうとせず、上から順に進めてください。
ステップ1：どのキーが、どこに出たかを書き出す
まずは状況をメモにします。後で開発会社やサービスの窓口に相談するときにも、そのまま使えます。
- どのサービスのキーか（AIのAPI、クラウド、決済、メール配信、データベースなど）
- どこに書いたか（AIチャット、コード、GitHub、社内チャット、メールなど）
- 公開範囲（自分だけ／社内の数人／インターネット上で誰でも）
- いつから出ていたか（分かる範囲で）
GitHubのリポジトリが「公開（Public）」になっていたかどうかは、特に重要です。
ステップ2：キーを無効化して、新しいキーを発行する（ローテーション）
各サービスの管理画面（ダッシュボード・コンソール）で、漏れたキーを削除または無効化し、新しいキーを発行します。これが最優先の対処です。
たとえばAnthropic（Claudeの提供元）のヘルプ記事では、キーが漏れた可能性がある場合は、すぐにコンソールのAPIキーのページでそのキーを削除し、サポートに連絡するよう案内しています。
📰 出典：Claude Help Center「API Key Best Practices: Keeping Your Keys Safe and Secure」
キーを無効にすると、そのキーを使っていたアプリは動かなくなります。新しいキーをアプリに設定し直す作業が必要です。アプリを業務で使っている場合は、短時間止まることを関係者に伝えておきましょう。
ステップ3：利用状況と請求を確認する
管理画面で、身に覚えのない利用がないかを確認します。
- 利用量のグラフに、急な増加や深夜の利用がないか
- 請求額・課金予定額がふだんより増えていないか
- 知らないプロジェクトやユーザーが追加されていないか
不審な利用が見つかった場合は、画面の記録（スクリーンショット・日時）を残したうえで、そのサービスのサポート窓口に連絡し、状況を伝えて対応を相談してください。請求の扱いはサービスや契約によって異なるため、「必ず取り消してもらえる」とは考えず、早めに相談することが大切です。
ステップ4：公開リポジトリなら、履歴の扱いを専門家に相談する
GitHubの公開リポジトリにキーを上げていた場合は、キーを取り替えたうえで、リポジトリを非公開にするか、履歴からキーを取り除く作業を検討します。
ただし、履歴の書き換えはコードの管理に詳しくないと、別のトラブルを招きやすい作業です。前述のGitHub Docsでも、手元で履歴を書き換えた後にGitHubサポートへ連絡し、キャッシュされた表示などの削除を依頼する流れが説明されています。非エンジニアの方は、キーの取り替えまでを自分で行い、履歴の整理は開発会社や詳しい人に依頼するのが現実的です。
ステップ5：顧客データが絡むなら、社内と専門家に報告する
漏れたキーが、顧客情報や従業員情報を保存しているデータベース・サービスのものだった場合は、個人情報の漏えいにつながった可能性も確認が必要です。
📰 出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」
個人情報保護委員会は、不正アクセスによる漏えいなど一定の場合に、委員会への報告や本人への通知が必要になることを案内しています。報告が必要かどうかの判断は状況によって異なるため、社内の責任者に報告したうえで、個人情報保護委員会の案内を確認し、必要に応じて弁護士などの専門家に相談してください。
誰に連絡すればいい？相談先の一覧
状況に応じて、次の相手に連絡します。自分ひとりで抱え込まないことが、被害を小さくする近道です。
| 相手 | 連絡するとき | 伝えること |
|---|---|---|
| 社内の上司・情報システム担当 | 業務で使っているキー・アプリなら必ず | ステップ1のメモ、取り替えの済み・未済 |
| 各サービスのサポート窓口 | 不審な利用・請求がある、キーを消せない | 気づいた日時、キーの種類、利用記録 |
| GitHubサポート | 公開リポジトリの履歴から完全に消したい | 対象のリポジトリ（詳しい人と一緒に） |
| 開発会社・詳しい人 | 取り替え後にアプリが動かない、履歴の整理、原因調査 | どこに何を書いたか、アプリの構成 |
| 個人情報保護委員会・弁護士 | 顧客・従業員の個人情報が関わる可能性がある | 漏えいのおそれがある情報の範囲 |
どこに相談すればいいか分からない場合は、IPA（情報処理推進機構）の「情報セキュリティ安心相談窓口」で、情報セキュリティに関する技術的な相談を受け付けています。
📰 出典：IPA「情報セキュリティ安心相談窓口」
再発を防ぐ4つの方法
キーを取り替えたら、同じことを繰り返さない仕組みを作ります。ポイントは「人が気をつける」だけに頼らないことです。
1. キーはコードに書かず「環境変数」や「シークレット管理」に置く
環境変数（＝アプリの外側に置いておく設定値。コードとは別に保管できる）や、クラウドサービスが用意しているシークレット管理の機能を使えば、キーをコードに書かずにアプリへ渡せます。
前述のAnthropicのヘルプ記事でも、クラウドに公開するときはシークレット管理の仕組みを使って環境変数としてキーを渡すこと、キーを保存した設定ファイル（.env など）をGitHubに上げないよう除外設定に加えることが勧められています。AIに作業を頼むときも「APIキーはコードに直接書かず、環境変数から読み込む形にして」と最初に伝えておくと安心です。
2. キーの権限と使える範囲を絞る
多くのサービスでは、キーごとに「使えるAPI」「使えるアプリやサイト」を制限したり、開発用と本番用でキーを分けたりできます。
📰 出典：Google Cloud「API キーを管理するためのベスト プラクティス」
Google Cloudのベストプラクティスでは、APIキーに制限を加えること、不要なキーを削除すること、キーをコードやリポジトリに含めないこと、定期的に新しいキーへ取り替えることなどが挙げられています。万一漏れても、できることが限られていれば被害は小さくなります。
3. 利用上限と通知を設定する
従量課金のサービスでは、月の利用上限や、一定額を超えたときの通知を設定できる場合があります。Anthropicのヘルプ記事でも、コンソールで利用状況を定期的に確認し、利用上限を設定することが挙げられています。設定できる項目はサービスごとに異なるため、管理画面で確認してください（執筆時点（2026年9月））。
4. GitHubのシークレットスキャンとプッシュ保護を使う
GitHubには、キーなどの秘密情報がコードに含まれていないかを自動で探す「シークレットスキャン」と、秘密情報を含むコードのアップロードを止める「プッシュ保護」という仕組みがあります。
📰 出典：GitHub Docs「シークレットスキャンについて」
GitHub Docsによると、公開リポジトリではシークレットスキャンが無料で自動的に実行されます。また、提携しているサービス事業者のキーが見つかった場合は、その事業者に通知される仕組みもあります（執筆時点（2026年9月））。
プッシュ保護は、ユーザー向けには公開リポジトリへのアップロードに対して既定で有効とされる一方、リポジトリ単位の設定は既定で無効で、管理者が有効にする必要があると説明されています（執筆時点（2026年9月））。社内で使うリポジトリの設定がどうなっているか、一度確認しておくとよいでしょう。
ただし、これらの仕組みですべてのキーを見つけられるわけではありません。「仕組みがあるから大丈夫」ではなく、「書かない」を基本にしたうえでの保険と考えてください。
開発会社に頼んだほうがいいケース
次のような場合は、自分だけで対処しようとせず、開発会社や詳しい人に依頼することをおすすめします。
- キーを取り替えたら、アプリがどう直せば動くのか分からない
- 公開リポジトリの履歴からキーを取り除きたい
- 顧客データを扱うアプリで、不正アクセスの有無を調べたい
- アプリのあちこちにキーやパスワードが書かれていて、全体像がつかめない
- 今後も業務で使い続けるため、安全な構成に作り直したい
依頼するときは、ステップ1で作ったメモを渡すと話が早く進みます。キーそのものをメールやチャットで送るのは避け、新しいキーの受け渡し方法も相談して決めましょう。セキュリティ面で開発会社に何を求めればいいかは、システム開発の発注でどんなセキュリティ対策を求めればいい？でも解説しています。
注意点：やりがちな失敗
- コードから消しただけで安心してしまう：履歴やコピーに残っている可能性があります。取り替えが先です。
- 新しいキーをまた同じ場所に書いてしまう：再発防止の仕組みに切り替えてから設定しましょう。
- 関係者に黙って対処する：アプリが止まる、請求が増えるなど、後から周りが混乱します。
- 「念のため」を先延ばしにする：漏れていないと言い切れない以上、取り替えは早いほど安全です。
どれだけ対策しても「これで絶対安全」とは言えません。大切なのは、漏れたときにすぐ気づき、すぐ取り替えられる状態にしておくことです。
発注者がやることチェックリスト
- ☐ 漏れたキーの種類・書いた場所・公開範囲・時期をメモにした
- ☐ 管理画面で漏れたキーを無効化し、新しいキーを発行した
- ☐ 利用状況と請求に身に覚えのない増加がないか確認した
- ☐ 公開リポジトリだった場合、履歴の整理を開発会社や詳しい人に相談した
- ☐ 個人情報が関わる可能性を確認し、社内の責任者に報告した
- ☐ キーを環境変数やシークレット管理に移し、コードに書かない形にした
- ☐ キーの権限・利用上限・通知を設定した
- ☐ GitHubのシークレットスキャン・プッシュ保護の設定状況を確認した
開発会社への質問例
- 「APIキーをコードに書いてしまい、すでに取り替えました。アプリに新しいキーを安全に設定する方法を教えてもらえますか？」
- 「公開していたリポジトリの履歴からキーを取り除く作業をお願いできますか？費用と期間の目安も知りたいです。」
- 「漏れていた期間に、不正な利用やデータへのアクセスがなかったか、どの記録を見れば確認できますか？」
- 「今後キーをコードに書かないために、環境変数やシークレット管理をどう使う構成にすればいいですか？」
- 「キーの権限や利用上限は、どこまで絞っても業務に支障がないでしょうか？」
まとめ
APIキーをチャットやコードに書いてしまったときは、「消す」より先に「無効化して取り替える」ことが最優先です。そのうえで利用状況と請求を確認し、公開リポジトリだった場合や顧客データが関わる場合は、開発会社・サービスの窓口・専門家に早めに相談しましょう。
再発防止は、環境変数やシークレット管理でキーをコードから切り離し、権限と利用上限を絞り、GitHubの仕組みを保険として使うことが基本です。バイブコーディングは便利な反面、こうした「見えないところの安全」はAIまかせにしにくい部分です。業務で使い続けるアプリほど、一度専門家の目を通しておくと安心です。
あわせて読みたい関連記事
