秘密のAPIキーが漏れると、そのキーに許された範囲でサービスを不正に使われるおそれがあります。ファイルや投稿から文字列を消しても、誰かがコピーしたキーまで消えるわけではありません。発行元で、そのキーを使えなくする「無効化」が別に必要です。
すでに漏れた疑いがある場合は、詳しい仕組みを読み終えるのを待たず、発行元の公式案内で対象キーの無効化を確認してください。 仕事で使うキーなら、管理担当にもすぐ知らせます。キー全体を相談文や画面の画像へ貼り直す必要はありません。
APIキーの役割と秘密にするキーの違い
APIは、あるソフトから別のソフトの機能を呼び出すための窓口です。たとえば、自分のアプリから外部の翻訳サービスへ文章を送り、翻訳結果を受け取る、といった使い方があります。窓口そのものの説明はAPIとはで扱っています。
その際に、利用者やアプリを識別したり、利用を認めたりするために渡す文字列がAPIキーです。人が毎回ログイン画面で操作する代わりに、プログラムがキーを使う仕組みがあります。
ただし、APIキーという名前のものが、すべて同じ扱いとは限りません。
| キーの種類の例 | 役割と扱い |
|---|---|
| 公開を前提にしたキー | 配布するアプリやWebページに置く設計の場合がある。使える範囲や制限は公式仕様で確認する |
| 秘密にするキー | 他人に渡すと、そのキーを使って操作されるおそれがある。公開するコードや相談文に載せない |
| 権限を制限した秘密のキー | 必要な機能だけ使えるようにしたもの。制限があっても公開してよい意味ではない |
たとえばStripeのAPIキーの説明では、公開できるキーと、秘密にすべきキー、権限を絞れるキーを分けています。ここで説明する漏えいへの対処は、主に秘密にすべきキーが対象です。
見た目が長い英数字だから、名前に「キー」とあるから、という理由だけで種類を判断しないようにします。分からなければ、公開する前に発行元の説明を確認します。
APIキーの漏えいで起こり得る不正利用
影響は、どのサービスのキーか、何を許可しているか、どんな制限があるかで変わります。一つのキーが漏れたからといって、すべてのアカウントを操作できるとは限りません。
考えられるのは、次のような影響です。
- 利用量を勝手に増やされる：従量制のサービスでは、利用枠の消費や料金の発生につながる場合があります。
- 情報を読まれる：読み取りが許可されたデータに、アクセスされる可能性があります。
- 情報や設定を変えられる：更新や削除の権限があれば、その範囲の操作をされるおそれがあります。
- 自分のアプリが使えなくなる：利用上限に達したり、対処のためキーを無効化したりすると、正常な利用にも影響する場合があります。
どこまで起きたかは、利用履歴やサービス側の調査で確かめます。「公開した」と「実際に悪用された」は別のことです。一方、身に覚えのない請求がまだないことだけで、悪用されていないとも言い切れません。
ログインのパスワードを変えれば止まる？
APIキーとログイン用パスワードは、別に管理されている場合があります。パスワード変更でキーも無効になるかはサービス次第です。「パスワードを変えたので終わり」とせず、対象キーの状態も確認します。
ログインの仕組みで使う本人確認と、プログラムに渡している利用の許可を、分けて考えると理解しやすくなります。
APIキーをファイルから消すことと無効化は違う
紙に書いた鍵の番号を消しても、すでに作られた合鍵は使えるままです。APIキーでも、文字の掲載をなくすことと、その文字列をサービス側が受け付けなくすることは別です。
ファイルや投稿から文字を取り除く。取得済みのコピーは残り得る。
発行元で、そのキーを新たに使えなくする。
新しいキーへ設定を更新し、古いキーの無効化も確認する。
対応の仕組みを示す図です。画面名や交換方法はサービスによって異なります。
| 対処 | 変わること | それだけでは変わらないこと |
|---|---|---|
| ファイルや投稿から削除する | その場所で新たに見られる機会を減らす | 取得済みのコピーや、キーの有効性 |
| 発行元で無効化する | そのキーで新たに利用することを止める | すでに行われた操作、取得されたデータ、発生済みの利用 |
| 必要に応じて再発行する | 正常なアプリへ渡す新しいキーを用意する | 新しいキーを作っただけで古いキーも止まるとは限らない |
GitHubの機密情報を削除する案内でも、秘密情報が含まれた場合は、まず取り消しや交換を行うことが説明されています。Gitはファイルの変更履歴を残すため、最新版から消しただけでは、過去の版に残ることがあります。さらに、他の人が作ったコピーを全部消せるとは限りません。
履歴の削除は共同作業にも影響します。仕組みを知らないまま削除コマンドを試すより、キーを止める対応を進め、履歴の扱いは管理担当や公式案内で確認してください。
漏れた疑いがあるときに確認すること
- 発行元の正規の管理画面で、対象キーを無効化する。画面では「削除」「取り消し」などと表示される場合もあります。
- どこへ、いつから載っていたかと、キーの名前・用途などを記録する。調査に必要な履歴を不用意に消さないようにします。
- 利用履歴や料金、許可していた操作を確認し、不審な点を運営元や管理担当へ伝える。
- 継続利用が必要なら新しいキーを安全に発行し、使っているアプリの設定を更新する。古いキーが無効になっていることも確認する。
Claudeの公式案内も、漏えいの疑いがあるキーの取り消しと、新しいキーの発行を分けて説明しています。具体的な操作や交換方法は、利用先の案内に従ってください。
無効化すると、そのキーで動いていた正常なアプリも止まり得ます。仕事用なら担当者と共有して対応します。止まるのが心配だからと、漏れたキーを放置する判断を一人で抱えないことが大切です。
APIキーをAI・画面共有・Gitへ載せる前の確認
エラーをAIに相談するとき、設定ファイルや画面を丸ごと渡したくなることがあります。しかし、エラーの説明に秘密のキーそのものは通常必要ありません。
共有前には、次の三か所を見ます。
- 本文：貼り付けるコード、設定、エラーの記録に、秘密のキーやトークンが混ざっていないか。
- 画面：画像や画面共有に、管理画面、設定欄、キーを保存したメモが映っていないか。
- 公開するファイル：今のファイルだけでなく、変更履歴や公開先へ送る設定に秘密が入っていないか。
「環境変数へ入れたから絶対に漏れない」とも言い切れません。環境変数はプログラムへ設定値を渡す方法の一つで、表示や記録の仕方によっては中身が外へ出ます。保存場所の名前より、誰に見えるか、どこへ送られるかを確かめます。
利用先が対応していれば、必要な操作だけに権限を絞る、用途ごとにキーを分ける、利用状況を確認する方法も役立ちます。制限を付けることは、秘密を公開してよい理由にはなりません。
まずは、使っているキーの発行元で、無効化する場所を確認しておくと安心です。誤って載せたときにも、「消したから大丈夫」で止まらず、使えなくする対応へ進めます。
