AIセキュリティ

APIキーを誤って公開してしまったときの対処｜GitHub・AIサービスの公式手順で、無効化から再発防止まで

OpenAIやClaudeなどのAPIキーを、うっかりGitHubに載せてしまった。気づいた直後に、何をどの順番でやるかを整理します。GitHubの公式ドキュメント「漏洩したシークレットへの対処」と、OpenAIの公式ドキュメントの内容をもとにしています。結論は、履歴から消す前に、まず無効化することです。

先に結論：5分でやる順番

そのキーは「漏れたもの」として扱う。GitHubは、一度リポジトリにコミットされたシークレットは、侵害されたものとみなすよう勧めています。
発行元の管理画面で、キーを無効化（取り消し）する。OpenAIなら、新しいキーを作って切り替え、古いキーを無効にします。
新しいキーを発行し、使っている場所を更新する。環境変数やシークレット管理に入れ、動作を確認します。
漏れていた期間に、不正な利用がなかったか確認する。利用状況（Usage）や、提供元・GitHubのログを見ます。
最後に、コミット履歴を整理し、再発を防ぐ。

いちばん多い間違い：履歴から消せば安全だと思うこと

GitHubのドキュメントでは、コードベースからシークレットを消す、新しいコミットをプッシュする、リポジトリを削除して作り直す、といった対応だけでは、シークレットの悪用は防げないと説明されています。公開された時点で、第三者に取得されている可能性があります。先に、キーそのものを使えなくしてください。

この記事で使った情報源

GitHub Docs「漏洩したシークレットへの対処」「プッシュ保護について」「ファイルの無視」、OpenAIの開発者向けドキュメント（Production best practices）、Claude APIのドキュメントです（2026年10月18日に確認）。各社の管理画面の見た目や項目名は、変わることがあります。

なぜ、すぐに無効化するのか

APIキーは、「そのアカウントとして、サービスを使える鍵」です。第三者がキーを手に入れると、あなたの料金で、AIを使われる（請求が増える）おそれがあります。キーに権限が多く付いている場合は、保存したデータの閲覧や変更につながる可能性もあります。

誤って公開した直後は、「まだ誰にも見られていないはず」と思いがちです。ですが、GitHubの公式ドキュメントは、コミットされたシークレットは侵害されたものと考えるよう勧めています。「見られたかどうか」を調べるより先に、「無効にする」ことが、被害を止める最短の手段です。

手順1：キーを無効にして、新しいキーに切り替える

OpenAIの場合（公式ドキュメントの手順）

OpenAIのドキュメントは、キーの入れ替え（ローテーション）を、次の4つの手順として説明しています。

置き換え用の新しいキーを作成する
アプリケーションを、新しいキーに更新する
新しいキーで動作を確認する
古いキーを無効化（取り消し）する

誤って公開した場合は、動作確認に時間をかけすぎず、古いキーの無効化を急いでください（手順3と4の間の待ち時間が、そのまま漏れている時間になります）。

Claude API（Anthropic）の場合

Claude APIのキーは、Claude Consoleの「API keys」ページから作成します。作成するときに、キーの種類と有効期限を選べます。無効化の具体的な操作画面は、今回確認できていないため、Consoleのキー管理ページで、該当のキーを探して取り消してください。

そのほかのサービス

GitHubのドキュメントでは、「プロバイダーの手順に従って取り消し、必要に応じて代わりのシークレットを発行する」としています。各サービスの管理画面で、キーを取り消す機能を探します。

GitHubのトークンだけは、GitHubが取り消してくれる場合があります

GitHubのドキュメントによると、非公開リポジトリで検出されたGitHubの個人アクセストークンは、GitHubに報告すると、GitHub側で取り消しの対応をしてもらえる場合があります。ただし、これはGitHubのトークンに限られます。AIサービスやクラウドのキーは、発行元で、自分が取り消す必要があります。

手順2：新しいキーを、安全な場所に入れる

OpenAIのドキュメントは、キーをコードやリポジトリに入れず、実行時に、環境変数かシークレット管理サービスから読み込むことを勧めています。具体的には、次のようにします。

キーをソースコードに書かない（ハードコードしない）
キーを、ソース管理（Git）にコミットしない
環境変数（たとえば OPENAI_API_KEY）や、シークレット管理の仕組みに保存する

.envファイルを使う場合：Gitの対象から外す

開発中は、.envのようなファイルにキーを書く方法がよく使われます。このファイルは、.gitignoreに書いて、Gitの管理から外してください。

.env
.env.*

注意点があります。GitHubのドキュメントによると、.gitignoreに追加しても、すでに追跡されているファイルには効きません。すでにコミット済みなら、先に追跡を外す必要があります。

git rm --cached .env

--cachedを付けているため、手元のファイル自体は消えません。そのあとで、.gitignoreに追加して、コミットします。ただし、これは「これ以上、追跡しない」ための設定で、過去の履歴に残ったキーを消すものではありません（キーの無効化は、手順1で済ませておきます）。

手順3：不正な利用がなかったか確認する

GitHubのドキュメントは、漏れていた期間に、未承認のアクセスがなかったか、GitHubの監査ログと、提供元（プロバイダー）側のログで確認するよう説明しています。

OpenAI：管理画面のUsageページで、利用状況を確認できます。ただし、ドキュメントによると、利用の追跡が有効になっているキーに限られます。2023年12月20日より前に作成したキーは、既定では追跡されていない場合があり、過去の利用が「Untracked」と表示されることがあります。
そのほかのサービス：各サービスの利用履歴・請求ページで、身に覚えのない利用や、急な増加がないかを見ます。
GitHub：リポジトリや、アカウントの監査ログを見ます。

不審な利用が見つかった場合は、そのサービスのサポートに連絡してください。請求の扱いは、サービスによって異なるため、公式の案内に従います。

手順4：コミット履歴の整理は、最後に

GitHubのドキュメントでは、コミット履歴に残ったシークレットを削除することを「検討する」としていますが、履歴の書き換えは、チームの作業を妨げることがあるため、慎重に判断するよう書かれています。

個人のリポジトリで、ほかに共同作業者がいないなら、影響は小さいでしょう。ただし、履歴を書き換えても、無効化の代わりにはなりません。履歴の整理は、無効化・入れ替え・ログの確認が済んだあとの、仕上げの作業です。やり方は、GitHubの公式ドキュメント「リポジトリから機密データを削除する」を、確認しながら進めてください。

再発を防ぐ：プッシュ保護と、公開前の確認

GitHubのプッシュ保護

GitHubの「プッシュ保護」は、シークレットやトークンなど、コードに直接書かれた資格情報が、リポジトリに届く前に、ブロックする機能です。公式ドキュメントによると、個人のGitHubアカウントに紐づく「ユーザーのプッシュ保護」が、GitHub.comで、既定で有効になっています（公開リポジトリへの流出を止める役割です）。一方、「リポジトリのプッシュ保護」は、GitHub Secret Protectionの有効化が前提で、既定では無効です。料金や詳しい条件は、公式ドキュメントで確認してください。

プッシュ保護は、万能ではありません

検出できるのは、GitHubが認識できる形式のシークレットです。自分で決めた合言葉や、形式が独自のキーは、見逃される可能性があります。「キーを、そもそもコードに書かない」習慣が、いちばん確実です。