OpenCodeのAPIキー流出で今やること：OpenAI・Anthropic・Geminiの失効手順と、支出上限で止められる範囲

OpenCodeのWeb版「OpenCode Console」に、自分のOpenAIやAnthropicのAPIキーを登録したことはありますか。あるなら、この先を読む前に各社の管理画面でそのキーを止めてください。OpenCode側でキーを消しても、すでに持ち出されたキーは使えてしまうからです。

OpenCodeは日本時間10月18日2時56分、公式Xの投稿でセキュリティ侵害を公表しました。影響を受けたのはConsole利用者の1.4%です。利用者からは身に覚えのない請求の報告も出ています。

失効の手順は各社の公式資料どおりに進めれば済みます。私がそれ以上に知っておくべきだと考えたのは、支出上限を設定しても、流出したキー1本の被害だけを止める仕組みはOpenAI・Anthropic・Googleのどこにもないという点です。3社の上限がどの単位で、どのくらい遅れて効くのかを公式資料で比べました。

公式に確認できた事実は3つ。原因と被害額はまだ分からない

OpenCodeが自ら公表したのは次の3点です。前夜に「大規模な蒸留攻撃」に関連する侵害があったこと。影響はOpenCode Console利用者の1.4%で、対象者には当日朝にメールで通知したこと。調査は続いており、Anthropic・OpenAI・Googleと対応していることです。

通知メールの内容は報道で伝えられています。DEVの記事によると、廃止作業中だった古いシステムへの不正アクセスが見つかり、ワークスペースに保存していた外部プロバイダーのキーが流出した可能性があると書かれていたそうです。メールの原本は確認できていません。侵入の経路も、何人分のキーが実際に使われたかも、公表されていません。

ここで言う蒸留攻撃とは、他社のモデルに大量の質問を投げて回答を集め、自分のモデルの学習に使う行為です。他人のキーを使えば、料金はキーの持ち主に請求されます。Anthropicが以前に主張したAlibabaによる大規模な蒸留攻撃と同じ種類の問題で、狙われたのはデータではなく計算資源と請求先だったと私は見ています。

対象かどうか：Consoleにキーを保存したことがあるか

報道によると、流出の恐れがあるのはConsoleのワークスペースに保存したキーです。手元のPCで動かすOpenCodeのCLIだけを使い、/connectでキーを登録した場合、キーは公式ドキュメントにあるとおり~/.local/share/opencode/auth.jsonに保存されます。今回の発表でこのファイルが漏れたとは説明されていません。

OpenCodeは、メールが届いていなければ影響はないと説明しています。それでも私は、Consoleに一度でもキーを保存した人には作り直しを勧めます。キーを作り直しても費用はかかりません。迷惑メールフォルダに入った通知を見落としていた場合のほうが、損失はずっと大きくなります。

CLIだけを使っている人も、Consoleに保存したのと同じキーをPCの環境変数やCIにも設定しているなら、すべての設定場所でキーを入れ替える必要があります。どこに置いたかの探し方は後の節で紹介します。

失効は各社の管理画面で行う。OpenCode側の削除では止まらない

先にやることは3つです。キーを止める、新しいキーに入れ替える、10月17日以降の利用明細を見る。ブックマークか手入力で各社の管理画面を開き、通知メールのリンクはたどらないでください。事件の直後には、通知を装ったフィッシングメールが出回りやすいからです。

OpenAI

管理画面のAPI keysで該当するキーを削除し、新しいキーを作ります。再発防止の設定もこのとき済ませます。本番運用の推奨事項では、プロジェクトAPIキーに有効期限を付けて定期的に入れ替えること、本番と検証を別のプロジェクトに分けることが勧められています。外部ツール用のキーを専用のプロジェクトで作っておけば、次の節で紹介する上限をそのプロジェクトだけにかけられます。

Anthropic

Claude ConsoleのAPI keysで該当キーを無効化または削除します。報道によると、Anthropicは影響を受けたと見られるClaude APIキーをすでに失効させています。それでも、自分の手で作り直しておくのが確実です。

どのキーをOpenCodeに登録したか分からない場合は、キーの名前と、先頭と末尾だけを表示した文字列を手がかりにします。Admin APIの仕様では、この文字列がsk-ant-api03-R2D...igAAのような形で返されます。全部がそろっていない文字列でも、手元の記録と照らし合わせれば候補を絞れます。

Google（Gemini API）

Googleの公式資料は、手順の順番が2つに分かれています。Gemini APIのキーの説明は、新しいキーで動くことを確かめてから古いキーを無効化する順番です。サービスを止めないことを優先しています。一方、Google Cloudブログの5月22日の記事は、流出したキーをすぐ削除するよう勧めています。削除したキーは、30日以内ならgcloud services api-keys undeleteで元に戻せます。

流出が確実か、その可能性が高い今回のようなケースでは、私は先に削除するほうを選びます。数分サービスが止まる損失よりも、その間に積み上がる不正な請求のほうが大きくなるおそれがあるからです。新しいキーを作るときは、使えるAPIを「Gemini API」だけに制限してください。

支出上限は「キー1本」には効かない。3社の違い

キーを作り直したら、支出上限も見直します。3社の公式資料を読み比べると、上限をかける単位も、上限に達したときの動きも違いました。

この表は10月18日時点のOpenAIのSpend limits、Anthropicのレート制限と支出上限、Gemini APIの請求ガイドをもとに作りました。上限を実際に超えさせる試験は、私はしていません。

OpenAIでは、Project settingsのLimitsからEdit spend limitを開き、Enforce a hard limitをオンにします。オンにしなければ通知が届くだけで、APIは使えたままです。上限に達するとproject_spend_limit_exceeded付きの429エラーが返ります。

Anthropicでは、SettingsのBillingページで組織の上限を設定します。ワークスペースの説明によると、ワークスペースごとの上限とアラートはWorkspacesページで設定します。ただし、最初からあるDefault Workspaceには上限を設定できません。外部ツール用のキーは、上限を付けた専用のワークスペースで作るのが安全です。

Gemini APIの上限は、AI StudioのSpendページから設定します。Google Cloudの予算アラートは通知だけで利用は止まらないため、混同に注意してください。また、請求アカウント全体の上限に達すると、そこにつながるすべてのプロジェクトが翌月1日まで止まります。

3社とも、キー1本ごとの上限はありません。私が勧めるのは、外部ツールに渡すキーごとにプロジェクトかワークスペースを分け、そこへ小さめの上限をかける方法です。キーと上限を1対1にすれば、流出したキーの被害額をその上限までに抑えられます。

上限は遅れて効く。被害額の天井を見積もる式

上限は、設定した金額ちょうどで止まるとは限りません。OpenAIは、上限の反映は即時ではなく、記録される請求額が設定額をわずかに超えることがあると明記しています。Geminiは、請求データの処理が最大10分ほど遅れると書いています。

被害額の天井は、次の式でおおよそ見積もれます。

最大請求額 ≈ 上限額 + 不正利用の速度（ドル/分） × 反映の遅れ（分）

仮に、上限50ドルのプロジェクトで1分あたり10ドル使われ、反映に10分かかったとします。この場合は10 × 10 = 100ドルが上乗せされ、請求は最大150ドルほどになります。数字はどれも仮定です。それでも、上限を低くするだけでは被害を抑えきれないことが分かります。高価なモデルを短時間に大量に呼ばれると、反映の遅れのあいだに請求が膨らみます。遅延の時間を公表しているのはGoogleだけで、OpenAIとAnthropicの遅れは分かっていません。

もう一つ注意したいのは、上限に達すると正規の利用まで止まることです。Googleの開発者フォーラムの7月の投稿では、271.48ユーロの不正利用で月の上限を使い切った人がいます。キーを失効させた後も、本番の通信が429エラーで止まったままになっていました。本番のサービスと外部ツールの実験で、同じプロジェクトを使い回さないでください。

手元に同じキーが残っていないか、値を表示せずに探す

キーを入れ替えたら、古いキーの設定が残っている場所を探します。OpenCodeのCLIを使っている場合は、CLIのドキュメントにある次のコマンドで、認証済みのプロバイダーを一覧できます。

opencode auth list

GitHubで公開されている開発版のソースを読んだかぎり、このコマンドが表示するのはプロバイダー名と保存の種類で、キーの値は表示しません。私の環境にはOpenCodeを入れていないため、実行はしていません。

シェルの設定ファイルや作業フォルダに残ったキーは、次のコマンドで探せます。-lを付けているので、表示されるのはファイル名だけで、キーの値は画面に出ません。探す場所は自分の環境に合わせて書き換えてください。

grep -rlE '(ANTHROPIC|OPENAI|GEMINI|GOOGLE)_API_KEY|sk-ant-' \
  ~/.zshrc ~/.bashrc ~/.config ~/work 2>/dev/null

このコマンドは、macOSのzsh 5.9で動作を確かめました。キーを書いたダミーの.envとrun.shを用意して実行したところ、2つのファイル名だけが表示されました。キーを含まないフォルダでは何も表示されません。sk-ant-はAnthropicのキーの先頭の文字列です。OpenAIとGoogleのキーは文字列の形を公式資料で確かめられなかったため、環境変数の名前で探しています。CIのシークレットや、チームで共有しているパスワード管理ツールは、このコマンドでは探せません。それぞれの画面で確認してください。

Claude Codeで環境変数を使って別のプロバイダーにつないでいる人は、そちらの設定も見直してください。設定の例はDeepSeek V4.1-FlashをClaude Codeで試す記事で紹介しています。

本物のキーを渡すサービスを減らす

今回の件で私が考えを改めたのは、APIキーを外部のサービスに預けるたびに、そのサービスが自分の請求先になるという点です。OpenCodeのCLIそのものは、キーを手元に置けばサーバーへ預けずに使えます。便利だからとWeb版にも同じキーを登録すると、守る場所がもう1つ増えます。

今日やることは2つです。1つ目は、Consoleに登録したことのあるキーを3社の管理画面で作り直し、10月17日以降の利用明細を確かめること。2つ目は、外部ツールに渡すキーを専用のプロジェクトかワークスペースで作り、そこへ小さな上限をかけることです。こうしておけば、次にどこかのサービスで同じことが起きても、被害はおおむね上限と反映の遅れの範囲に収まります。