被害が小さかった3つの理由と、AIのAPIキーを守るチェックリスト

連載の第 5 回(最終回)です。前の回は 第 4 回 一台の穴が全台の合鍵に。封じ込めと鍵の打ち直しです。

AI の API キーが 680 行も流出したのに、被害が小さく済んだのはなぜか。この回では、その 3 つの理由と、読み手が明日からできるチェックリストを書きます。チェックリストは、OpenAI・Anthropic・Google の公式の案内、GitHub Docs、IPA(情報処理推進機構)の資料で、2026年10月15日に確かめた内容だけです。編集部の判断で足した項目には、そう書いています。確かめられなかったことは、そのとおり書きます。

なぜ、この回を書くのか。「うちは小さい会社だから、狙われない」「入られた跡がないから、大丈夫」と思っている人に、キーは入られなくても外で使われる、と伝えたいからです。迷ったときに、何から手を付けるかが決められるように、始めやすい順番も示します。

この連載は、編集部が管理しているサーバーで 2026年10月14日から15日に起きた出来事の記録です。調査と封じ込めは Claude Code(AI がパソコンやサーバーの作業を手伝う道具)が、編集長の指示と承認のもとで手伝いました。守りの仕組みの名前や台数など、守りに関わることは書いていません。

被害が小さかった 3 つの理由

ここまでの流れは、前の回で書いています。AI のキーが外の転売の仕組みで使われていたこと(第 2 回)、入口は全台の控えを集める台の管理画面だったこと(第 3 回)です。ここでは数字だけを並べます。

• 集められた AI キーの行は 680 でした。実在のキーとして分類できたのは約 290 本です。
• 提供元の利用の記録で、悪用が確かめられたのは 8 本です。約 580 回、入力 100 万・出力 36 万トークンが使われました。
• 確かめられた被害額は、約 11 ドルでした。

1 大半のキーは、すでに失効していた

流出した束には、過去に作り替えたときに無効にした古いキーが多く入っていました。外の仕組みは、集めたキーに最初の生存確認を送ります。そこで弾かれたキーは、使えません。

2 動いていたキーは、直後に失効した

本番の悪用は 03:12 に始まり、こちらは 03:22 にキーの失効を始めました。外の仕組みは、そこで空回りになりました。確かめたのは提供元の利用の記録の範囲です。ほかの場所での使われ方まで調べ切ったとは言えません。

3 刃が抜かれる前に止まっていた

2 回目の攻撃は、封じ込めた時点で、まだ秘密を集めている段階でした。採掘、居座り用のユーザー pakchoi の作成、ほかの台への横展開は、確かめた範囲では始まっていませんでした。2 回目に外へ送られた物の中に、秘密鍵は含まれていませんでした。

調査を担当した AI の記録には、「『大量流出』は起きたが、『大量被害』には至らなかった」とあります。ただし理由 3 は、運が大きく働きました。理由 1 は日頃の習慣、理由 2 は検知と手の速さです。編集部は、運に頼れない 1 と 2 を、この回の中心に置きます。

調査を担当した AI の記録には、「叩かれていた鍵は、ほんのひと握りだった」とあり、そのあとに、胸をなで下ろした、という一文が続きます。

考察: 被害が小さかったことの意味

確かめたことと、編集部の推測を分けます。

• 確かめたこと: 流出した行は 680、悪用が確かめられたのは 8 本、被害額は約 11 ドルでした。失効が早かったことが、数字に出ています。
• 推測(確かめていません): 古いキーを無効にしていなければ、悪用された本数はもっと多かったと考えられます。失効の習慣が、今回は被害額を直接小さくした可能性があります。
• 一般化: 流出そのものは、防ぎ切れないことがあります。防げないなら、流出した時点で価値を失っている状態、つまり「使えない鍵」にしておくのが現実的です。

「侵入なき流出」はどう起きたか

最初の調査では、外から各サーバーに入られた跡は見つかりませんでした。それでも、キーは外で使われました。

• 平文で散らばった鍵: 掲示板の投稿の本文、コードのサンプル、会話の記録などに、キーがそのまま書かれていました。
• 秘密を一か所に集める台: 全台の控えを持つ台の管理画面が、認証の手前で破られました。散らばった鍵は、そこで一度に拾われました。

調査を担当した AI の記録には、「侵入の痕跡が『なかった』ことが、安心の理由にならなかった」とあります。ログインの履歴を見て「入られていない」と分かっても、鍵が読める場所にあれば、守れたことにはなりません。

明日からやること: チェックリスト

項目ごとに、やることと「なぜ」を書きます。「なぜ」は、今回の出来事のどこに効いた(効いたはずの)項目かです。

A キーを散らかさない・分ける

• A1 コードに書かない。 OpenAI の公式の案内は、キーをコードや公開のリポジトリに置かず、環境変数か秘密の管理サービスで渡すように書いています。なぜ: 今回は、平文で散らばったキーがまとめて拾われました。
• A2 利用者の端末に置かない。 Gemini API の公式の案内は、Web やモバイルのアプリにキーを入れると、利用者が取り出せるため、自分のサーバーを間に置くように書いています。同じページに「Never expose keys client-side in production」とあります。なぜ: 読める場所にあるキーは、読めるだけで盗めます。
• A3 用途ごとに分ける。 OpenAI はプロジェクトごとに、レートと支出の上限を設定できます。Anthropic は、キーがワークスペースに属し、ワークスペースごとに上限を付けられます。なぜ: 悪用されたのは 8 本でした。分けてあれば、止める範囲も、影響を確かめる範囲も、小さくなります。
• A4 期限を付けて入れ替える。 OpenAI は、プロジェクトのキーを作るときに有効期限を付けることと、定期的な入れ替えを強く勧めています。手順は、新しいキーを作り、アプリを切り替え、動くのを確かめてから古いキーを失効させます。Google Cloud も、新しいキーを作って切り替えてから、古いキーを削除する入れ替えを案内しています。なぜ: 今回、被害を小さくした最大の物は、すでに失効していた古いキーでした。

B 上限・通知・キーの制限

• B1 上限と通知を、別々に設定する。 OpenAI の公式の案内には、2 種類あります。金額を超えたら知らせる「spend alerts」と、月の上限で通信を止める「hard spend limit」です。hard spend limit は、上限に達すると対象の API の通信を止めます。有効にする前に、公式の spend limits のガイドを読むように書かれています。Anthropic は、Claude Console の Billing ページの「Spend limits」で、段階ごとの月の上限より低い金額を、自分で設定できます。上限に達すると、リクエストはエラーになります。
• B2 Google Cloud の予算は、止まらない。 Google Cloud の公式の案内は、アラートだけの予算は利用を自動では止めない、と書いています。初期のしきい値は、予算額の 50%・90%・100% です。一部のサービスには、上限に達すると止まる spend cap の予算もある、と書かれています。
• B3 キーの使い道を絞る。 Google Cloud の公式の案内は、API の制限と、アプリケーションの制限(Web サイトのリファラー、IP アドレス、Android アプリ、iOS アプリ)を両方付けるように書き、「制限のないキーは安全でない」とあります。ただし Android と iOS の制限は、回避されやすいとも書かれています。Gemini だけに使うキーは、Google AI Studio の API Keys のページで「Restrict to Gemini API only」を選べます。なぜ: 今回のキーは、社内ではなく外の仕組みから使われました。Google のキーには、使える IP を限る設定があります。ただし悪用が確かめられたのは OpenAI のキーで、同じ制限があるかは編集部は確かめていません。
• 確かめられなかったこと: Anthropic の公式の案内で、金額を超えたときに知らせる通知の設定は、編集部は確かめられませんでした。Console の Usage ページで、利用量のグラフを見られることは確かめています。

なぜ(B 全体): 今回は、提供元の利用の記録を見て、悪用に気づきました。通知を付けていれば、記録を見に行く前に、知らせが届く場合があります。

C 置き場所と更新

• C1 GitHub の秘密のスキャンと、プッシュの保護を使う。 GitHub の secret scanning は、リポジトリに書かれた API キーやパスワードを検出します。公開のリポジトリでは無料で動きます。組織の非公開のリポジトリでは、GitHub Secret Protection(GitHub Team か GitHub Enterprise Cloud)が要ります。push protection は、検出した秘密を含む push を、リポジトリに届く前に止めます。個人のアカウントの「push protection for users」は、公開のリポジトリに対して既定で有効です。なぜ: コードのサンプルに平文のキーが置かれていました。同じ型を、手前で止められます。

  回想: GitHub の公式の告知によると、push protection は 2023年8月から、利用者が任意で有効にできました。2024年2月29日には、公開リポジトリへのすべての push で、既定で有効になりました。同じ告知は、2024年の最初の 8 週間だけで、公開リポジトリ上の漏れた秘密を 100 万件以上検出した、と書いています。数年のうちに、秘密を上げる前に止める備えが、既定の設定になりました。

• C2 控えの鍵を、控えの中に置かない。 これは公式の案内ではなく、編集部の対応から出た項目です。今回は、控えを開ける鍵と控えの中身が、同じ台から一緒に出ました(詳しくは第 4 回)。控えを開ける鍵は、別の場所で守ります。

• C3 管理画面を、公開しない。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026年3月27日公開)は、自社診断の項目に、外部からの不要な通信の遮断を加えました。なぜ: 今回の入口は、認証の手前で破られた管理画面でした。外から開けない場所にあれば、届きにくくなります。

• C4 更新して、公式の告知を見る。 IPA の「情報セキュリティ6か条」の 1 つ目は「OSやソフトウェアは常に最新の状態にしよう！」、6 つ目は「脅威や攻撃の手口を知ろう！」です。フレームワークは、使っている物の公式の告知を、自分で見に行きます。たとえば Next.js のブログには、セキュリティの告知が載っています。なぜ: 今回の入口は、更新を当てる前の版でした。どの欠陥かは、第 3 回で説明しています。

まず何から始めるか: 始めやすい順番

全部を一度にやる必要はありません。かかる時間で、3 つに分けます。

どこから迷う場合も、最初の 1 時間の 3 つだけで構いません。今回いちばん効いたのは、使えなくなったキーと、速い失効でした。

漏れたと分かったときの順番

1. 止める。 悪用されているキーを、先に無効にします。GitHub Docs は、漏れた秘密は侵害されたものとして扱い、失効するように書いています。コードから消す、新しいコミットを push する、リポジトリを消して作り直す、のどれも、悪用を防ぎません。
2. 失効する。 漏れた範囲のキーを全部失効し、新しいキーに入れ替えます。Gemini API の公式の手順は、新しいキーを作り、アプリを新しいキーで動かし、動くのを確かめてから、漏れたキーを無効にする順です。サービスを止められないときの順番は、事情で変わります。今回は、悪用が続いていたため、失効を急ぎました。
3. 利用の記録を見る。 Gemini API の公式の案内は、請求と API の利用の記録を確かめるように書いています。GitHub Docs も、不正な利用が無かったかを確かめる手順を置いています。今回は、提供元の記録を分単位に並べて、外の仕組みで使われたと分かりました。
4. 広げない。 IPA の「セキュリティインシデント対応の手引き」は、被害が広がる可能性があるときは、ネットワークの遮断、機器の隔離、システムの停止を行う、と書いています。今回は、管理画面を止め、外への通信を断ちました。
5. 記録を残す。 同じ手引きは、電源を切るなどの不用意な操作で、残っている記録を消さないように書き、証拠の保全と、発生からの時系列の整理を挙げています。今回は、証拠を退避してから作業を進めました。

この順番のうち、迷いにくいのは 1 と 2 です。止める前に、自分のキーがどのサービスのどのキーかが、一覧で分かっていると動きやすくなります(編集部の考えです)。A3 で分けておく理由は、ここにもあります。

この回で分かったこと

読み手へのひとこと

今日できるのは、いま使っている AI のキーが何本あって、どこに書かれているかを、一覧にすることです。次に、使っていないキーを失効します。この 2 つは、今回いちばん効いたことと、同じ備えになります。

連載は、この回で終わりです。最初から読み返すときは、第 1 回 AIのAPIキーが中国圏から不正利用された朝、まずしたことからどうぞ。