杜撰なAPIキー管理で300万円請求？漏洩を防ぐ設定・管理方法

2026年2月17日

「とりあえず動けばいい」と、APIキーを発行してそのまま貼り付けていませんか？
そのキーは、パスワードと同じです。管理を一歩間違えれば、あなたの口座から数十万円が不正に引き落とされるリスクと隣り合わせです。
2025年にもOpenAIやAnthropicで高額請求被害が報告されていますが、その多くは「知っていれば防げた」初歩的なミスが原因。

この記事では、今日から実践できるAPIキーの安全な扱い方を解説します。

APIキーの管理が杜撰だとどうなるのか

APIキーの管理について、そこまで深刻に考えていない方は多いのではないでしょうか。しかし、管理がずさんなまま放置すると、ある日突然、数十万円単位の請求が届くことがあります。これは決して大げさな話ではなく、実際に国内外で何度も起きています。

【AWS事例】コードへの直書きが招いた「300万円」の請求事故

代表的な事例がAWSのアクセスキー流出です。あるエンジニアは、学習用に作ったソースコードの中にAWSのアクセスキーを直接書き込み、そのままGitHubの公開リポジトリにアップしてしまいました。

その結果、第三者にキーを悪用され、全リージョンで大量のEC2インスタンスを起動されて仮想通貨のマイニングに使われてしまいます。請求額はおよそ300万円にのぼりました。幸いAWSへの相談を経て請求は免除されましたが、免除されるかどうかはケースバイケースであり、必ず救済される保証はありません。

同様の事例は枚挙にいとまがなく、$6,000（約90万円）の請求が来たケースや、$80,000（約1,200万円）の請求が発生した報告もあります。

しかも、GitHubの公開リポジトリにキーが上がると、悪意のあるBOTがわずか13分で検知して不正アクセスを始めたという検証結果もあり、人間が気づくより先にキーが悪用される危険性があります。

【AI事例】上限設定も無意味？OpenAIで起きた「ソフトリミット」の罠

こうした被害はAWSに限った話ではありません。AIサービスのAPIキーでも同様の事故が起きています。2025年にはOpenAIのAPIキーが流出し、$2,500の利用上限を設定していたにもかかわらず、実際には$6,200以上の請求が発生した事例が報告されました。

OpenAIの利用上限はソフトリミット（警告のみで強制停止されない仕様）であったため、上限を超えても課金が続いたのです。

同じく2025年、AnthropicのAPIキーが流出した事例では、Claude 3.7 Sonnetを大量に使われ、被害額は約30ドルで済んだものの、自動トップアップ（自動チャージ）を有効にしていた場合は数万円以上の被害になっていた可能性がありました。流出経路は特定できず、スパイウェアの可能性が疑われています。

誰もがAPIキーを発行する時代になったからこそ気をつけたい

ChatGPTやClaudeなどのAIツールが普及したことで、エンジニアだけでなく、マーケターや経営者など非技術職の方もAPIキーを発行する機会が増えています。

しかし、APIキーの取り扱いに関する知識がないまま発行し、コードに直接貼り付けたり、チャットで気軽に共有したりしている方が少なくありません。

APIキーが漏洩すれば誰でもあなたのアカウントで課金サービスを使い放題になります。ここからは、そうした事故を防ぐための具体的な管理方法を解説します。

APIキーを安全に保管する方法

APIキーの管理で最も基本的なのが、キーをどこに保管するかという問題です。多くの事故は、キーを不適切な場所に保存していたことが原因で起きています。ここでは、推奨される保管方法と、絶対にやってはいけない保管方法の両面から解説します。

APIキーの正しい保管場所

環境変数（.envファイル）で管理する

プログラムの中でAPIキーを使う場合、最も基本的な方法は環境変数として管理することです。環境変数とは、OSやアプリケーションが参照する設定値のことで、ソースコードの外側にキーを置くことで、コードとキーを分離できます。

具体的には、プロジェクトのルートディレクトリに.envという名前のファイルを作成し、その中にAPIキーを記述します。たとえばOPENAI_API_KEY=sk-xxxxxxxxxxxのように書いておき、プログラムからはこの環境変数を読み込んで使います。Pythonならpython-dotenv、Node.jsならdotenvといったライブラリを使えば、.envファイルの内容を簡単に読み込めます。

ここで重要なのが、.envファイルをGitの管理対象から外すことです。プロジェクトの.gitignoreファイルに.envと記述しておけば、誤ってGitHubにアップロードしてしまう事故を防げます。これはAPIキーを環境変数で管理する際のセットとして、必ず行うべき設定です。

パスワードマネージャーで管理する

プログラムで使うのではなく、手元で複数のAPIキーを管理したい場合は、パスワードマネージャーの利用がおすすめです。1PasswordやBitwardenなどのツールを使えば、APIキーを暗号化された状態で安全に保管できます。

パスワードマネージャーの利点は、キーの一覧性が高いことと、チームでの共有機能を備えている製品が多いことです。1Passwordの場合、APIキー専用のアイテムタイプがあり、どのサービスのキーなのか、いつ発行したのかといった情報もまとめて管理できます。チームで運用している場合は、共有ボールトにキーを保存することで、メールやチャットを介さずに安全に共有できます。

無料で使えるBitwardenでも十分な機能があるため、まだパスワードマネージャーを使っていない方はこの機会に導入を検討してみてください。

やってはいけないAPIキーの保管方法

ソースコードに直接書き込む

最も多い事故原因がこれです。プログラムのソースコード内にAPIキーをそのまま文字列として記述してしまうパターンです。たとえばapi_key = “sk-xxxxxxxxxxxxxxxx”のようにハードコーディングすると、そのファイルが外部に公開された瞬間にキーが漏洩します。

開発中は動作確認のためについ直接書いてしまいがちですが、一度でもコミットしてしまうとGitの履歴に残り続けます。後からファイルを修正してキーを消しても、コミット履歴を遡れば誰でもキーを取得できてしまうため、コードから消しただけでは対策になりません。

GitHubなどのリポジトリにアップする

ソースコードへの直書きと密接に関連しますが、キーを含んだファイルをGitHub等のリポジトリにプッシュしてしまう事故は後を絶ちません。プライベートリポジトリであっても、設定変更で誤って公開してしまうケースや、チームメンバーの入れ替わりでアクセス権が残ってしまうケースがあるため、安全とは言い切れません。

先述の通り、GitHubの公開リポジトリに上がったキーはBOTによってわずか数分で検知されます。GitHubには公開リポジトリのシークレットを自動検知してアラートを出すSecret Scanningという機能がありますが、これに頼るのではなく、そもそもキーをリポジトリに含めないことが大前提です。.gitignoreへの.envの記述と、git-secretsなどのツール導入で二重に防止することを推奨します。

メールやチャットでAPIキーを共有する

チームで作業している場合、APIキーをSlackやTeams、メールで送ってしまうケースがあります。これは非常に危険です。チャットツールのメッセージは検索機能で簡単に掘り起こせますし、アカウントが乗っ取られた場合にメッセージ履歴からキーが流出します。メールも同様で、転送や誤送信のリスクがあります。

チームメンバーにAPIキーを共有する必要がある場合は、前述のパスワードマネージャーの共有機能を使うか、各メンバーが自分専用のキーを発行する運用にするのが安全です。

メモ帳やスプレッドシートに記録する

APIキーをWindowsのメモ帳やmacOSのテキストエディット、あるいはGoogleスプレッドシートやExcelで管理している方もいます。これらのファイルは暗号化されていないため、PCの紛失や不正アクセスがあった場合にキーがそのまま漏洩します。

Googleスプレッドシートの場合、共有設定を誤ってリンクを知っている全員がアクセス可能な状態にしてしまうミスも起こり得ます。APIキーの保管には、必ず暗号化に対応した専用ツールを使いましょう。

APIキー発行時にやるべき設定

APIキーを安全に保管するだけでは十分ではありません。万が一キーが漏洩した場合に備えて、被害を最小限に抑えるための設定を発行時に行っておくことが重要です。

権限を必要最小限に絞る

APIキーを発行する際、多くのサービスではキーに付与する権限（スコープ）を選択できます。たとえばOpenAIであれば、モデルの利用だけに制限したキーや、ファイル操作を含むキーなど、用途に応じた権限設定が可能です。AWSの場合はIAMポリシーで細かく権限を制御できます。

ここで大切なのは、そのキーが実際に使う機能だけに権限を絞ることです。すべての権限を持つキーを発行してしまうと、漏洩した際に攻撃者ができることが大幅に広がります。読み取りだけで十分な用途に書き込み権限まで付与する、本番環境のリソースにアクセスできる権限を開発用キーに持たせる、といった設定は避けてください。

権限設定の画面は一見面倒に感じますが、最小権限の原則はセキュリティの基本中の基本です。発行時に数分かけて適切な権限を選ぶだけで、万が一の被害規模を大きく抑えられます。

用途ごとにキーを分けて発行する

APIキーは1つで済ませるのではなく、用途ごとに別々のキーを発行することを推奨します。たとえば、本番サービス用、開発・テスト用、個人の検証用といった形で分けておくと、いざというときの影響範囲を限定できます。

先述のAnthropic APIキー流出の事例でも、個人開発用とサービス提供用でキーを分けていたことで、被害がサービス全体に波及せずに済みました。仮に1つのキーだけで運用していたら、個人用キーの流出がそのまま本番サービスの停止につながっていた可能性があります。

キーを分けておけば、特定のキーに不審な利用があった際にそのキーだけを無効化でき、他の用途への影響を避けられます。管理するキーの数は増えますが、パスワードマネージャーを使えば運用負荷は最小限に抑えられます。

APIキー運用中にやるべき設定

APIキーは発行して終わりではありません。運用中に適切な設定とメンテナンスを行うことで、被害リスクを継続的に下げることができます。

APIキー管理台帳を作成してゾンビキーを防ぐ

APIキーを複数のサービスで複数の用途にわたって発行していると、時間が経つにつれて「これは何のキーだっけ？」「どこで発行したっけ？」と管理不能に陥ります。これを放置すると、不要になっても削除されないゾンビキーが生まれ、漏洩リスクが膨らんでいきます。

これを防ぐために、キー本体の保管とは別に、以下の情報をセットで記録する管理台帳を作りましょう。

サービス名と管理画面のURL（すぐに無効化しに行けるように）
用途とプロジェクト名（何に使っているキーか）
発行日と担当者（いつ誰が作ったか）
ローテーション予定日（次はいつ再発行すべきか）

この管理には、前述のパスワードマネージャーが最適です。1PasswordやBitwardenには、キー本体だけでなくWebサイトURLやメモを保存する欄があります。そこに管理画面のURLや用途を記載しておけば、キーの利用時にも確認でき、万が一の際の無効化作業もスムーズに行えます。

Excelやスプレッドシートで台帳を作ることも可能ですが、その場合はキー本体（シークレット）は絶対に記入しないことを徹底してください。

この台帳があることで、後述するローテーションや不要キーの削除もスムーズに判断できるようになります。

利用上限を設定する

ほとんどのAPIサービスでは、月額や日額の利用上限を設定できます。OpenAI、Anthropic、Google Cloud、AWSなど、主要なサービスには利用上限の仕組みが用意されているので、キーを発行したら必ず設定してください。

ただし、ここで注意すべきことがあります。サービスによっては利用上限がソフトリミット（警告のみで停止しない）の場合があります。先述のOpenAI APIキー流出の事例では、$2,500の上限を設定していたにもかかわらず$6,200以上の請求が発生しました。利用上限が必ずしも強制停止として機能しなかったためです。OpenAIでは現在Hard limitとSoft limitの両方を設定できますが、サービスや時期によって挙動が異なる場合があります。

利用上限を設定したからといって安心するのではなく、そのサービスの上限設定がハードリミットかソフトリミットかを確認しておきましょう。ソフトリミットの場合は、後述の課金アラートや自動トップアップの無効化と組み合わせて対策する必要があります。

課金アラートを設定する

利用上限と合わせて設定しておきたいのが、課金アラートです。一定の利用額に達した時点でメールやSlackに通知を飛ばすよう設定しておけば、不正利用の早期発見につながります。

AWSならCloudWatchのBilling Alarm、Google CloudならBudgets、OpenAIならUsage limitsの通知設定が利用できます。アラートは上限額の50%、80%、100%など複数段階で設定しておくと、異常な増加傾向に早い段階で気づけます。

普段の利用額を把握していれば、異常値にすぐ反応できます。月に$10程度しか使っていないのに、ある日$50を超えたアラートが来たら、何かがおかしいと即座に調査できるわけです。

自動トップアップ（自動チャージ）を無効にする

OpenAIやAnthropicなどのAIサービスでは、クレジット残高が減ったときに自動的にチャージする自動トップアップ機能があります。通常の利用では便利な機能ですが、キーが漏洩した場合には被害を拡大させる原因になります。

先述のAnthropic APIキー流出の事例では、自動トップアップを有効にしていなかったためにクレジットが尽きた時点でAPIが停止し、被害が約30ドルで済みました。もし自動トップアップが有効だった場合、攻撃者が使い続ける限りチャージが繰り返され、被害額は際限なく膨らんでいた可能性があります。

自動トップアップは無効にしておき、手動でチャージする運用にすることを推奨します。残高管理の手間は増えますが、万が一の際のダメージリミッターとして機能します。

定期的にキーをローテーション（再発行）する

APIキーは一度発行したら永久に使い続けるものではありません。定期的に新しいキーを発行し、古いキーを無効化するローテーションを行いましょう。万が一、気づかないうちにキーが漏洩していたとしても、ローテーションによって漏洩したキーが無効になるため、被害を食い止められます。

ローテーションの頻度はサービスや用途によりますが、3か月に1回程度を目安にするとよいでしょう。頻繁にキーを使い回すプロジェクトや、多人数でキーを共有している場合は、より短い間隔でのローテーションが望ましいです。

ローテーションの手順は、新しいキーを発行してからシステムに反映し、動作確認が取れたら古いキーを削除する、という流れです。先に古いキーを削除するとサービスが停止するため、順序を間違えないよう注意してください。

使わなくなったキーは即座に削除する

プロジェクトが終了した、テスト用に発行した、担当者が退職した、といった理由で使わなくなったAPIキーは、すぐに削除してください。存在するだけで漏洩リスクがあるため、使わないキーを残しておくメリットはありません。

定期的にAPIサービスの管理画面を確認し、発行済みのキー一覧を棚卸しする習慣をつけましょう。いつ発行したか覚えていないキーや、何に使っていたかわからないキーがあれば、削除を検討してください。用途ごとにキーを分けて発行していれば、どのキーが不要になったかの判断もしやすくなります。

APIキーが漏洩したときの対処法

どれだけ注意していても、漏洩のリスクをゼロにすることはできません。万が一APIキーが漏洩した、もしくは漏洩した可能性がある場合は、以下の手順で速やかに対処してください。対応が早ければ早いほど被害を抑えられます。

キーを即座に無効化・削除する

漏洩に気づいたら、最優先でやるべきことは該当するAPIキーの無効化と削除です。どこから漏れたかの調査よりも、まずキーを止めることが先です。キーが有効である限り、1秒ごとに被害が拡大する可能性があります。

ほとんどのAPIサービスでは、管理画面からキーの無効化や削除が即座に行えます。GitHubにキーをアップしてしまった場合、リポジトリを削除したり非公開にしたりするだけでは不十分です。コミット履歴やフォークされたリポジトリにキーが残っている可能性があるため、必ずAPIサービス側でキーそのものを無効化してください。

不正利用がないか利用履歴を確認する

キーを無効化したら、次にAPIサービスの利用履歴やダッシュボードを確認します。通常と異なるリクエスト数、見覚えのないIPアドレスからのアクセス、想定外のAPIエンドポイントへのリクエストなどがあれば、不正利用の証拠としてスクリーンショットや利用ログをダウンロードして保存しておきましょう。

この記録は、次のステップでサービス提供元に連絡する際の重要な資料になります。いつから不正利用が始まったのか、どの程度の規模で悪用されたのかを把握しておくと、返金交渉がスムーズに進みやすくなります。

サービス提供元に連絡する

不正利用による想定外の請求が発生している場合は、APIサービスの提供元に連絡しましょう。AWS、OpenAI、Anthropicなどの主要サービスでは、不正利用による請求について相談窓口が用意されています。

事例を見ると、AWSでは300万円の不正請求が全額免除されたケース、OpenAIでは$6,200の請求が返金されたケースが報告されています。ただし、返金は保証されているわけではなく、サービス側の判断によります。迅速な対応をしていたか、適切なセキュリティ対策を講じていたかなどが考慮されるため、日頃の管理状況も重要です。