OpenCodeは2026年10月17日、クラウド上の管理サービス「OpenCode Console」でセキュリティ侵害が発生し、Console利用者の1.4%が影響を受けたと発表した。対象者に送られた通知では、Consoleに保存されていた外部AIサービスのAPIキーが流出した可能性があると説明している。運営側は今回の事件を「大規模な蒸留攻撃」に関連するものとしているが、具体的な侵入経路は明らかにしていない。チームでAIを利用するために預けた認証情報が侵害された可能性があり、APIキーの保管方法や、侵害時に不正利用を止めるための仕組みが問われている。

AD

影響範囲を左右するAPIキーの保管場所

OpenCodeが公表した1.4%という数字は、OpenCode Consoleの利用者全体に占める割合だ。OpenCodeアプリの全利用者に占める割合でも、流出したAPIキーの割合でもない。影響を受けた具体的な人数やキーの総数は公表されていない。運営側によると、外部AIサービスを連携させていた利用者の一部が対象で、該当する全利用者にはメールで通知済みだという。また、通知を受け取っていない利用者は影響を受けていないと説明している。

今回の事件を理解するうえで重要なのは、利用者の端末で動作するOpenCodeアプリと、クラウド上の管理サービスであるOpenCode Consoleを区別することだ。開発者のDax Raad氏は補足投稿で、今回の侵害はConsoleで発生したものであり、OpenCodeアプリ自体は対象ではないと明言している。また、アプリから外部AIサービスへ直接接続する際に使用するAPIキーは、OpenCodeの運営側には送信されないという。

実際、OpenCodeの接続設定に関する公式文書とConsoleのプロバイダー管理に関する説明を確認すると、外部AIサービスへの接続方法によってAPIキーの保管場所が異なることが分かる。

利用方法 外部AIサービスのAPIキーの保管場所 今回の侵害との関係
OpenCodeアプリから外部AIサービスへ直接接続 利用者の端末。/connectで登録したキーはローカルの認証ファイルに保存される 開発者が今回のConsole侵害とは区別している利用方法
Consoleに外部AIサービスを登録し、ワークスペース内で共有 Consoleがキーを保管し、ゲートウェイ経由で外部AIサービスへの要求を中継する 外部サービスを連携させていた利用者の一部が影響を受けたと公表されている

この違いは、同じOpenCodeを利用していても、外部AIサービスの認証情報を誰が管理しているかが異なることを意味する。APIキーを利用者の端末だけに保存する場合と、Consoleに登録してチームで共有する場合では、認証情報を保護する責任の所在が変わる。また、/connectという操作名だけでは、どこにキーが保存されているかを判断できない。Consoleのワークスペースを選択して利用する方法もあるため、重要なのは、外部AIサービスのAPIキーをどの接続先に登録したかという点だ。

廃止作業中の旧システムにAPIキーが残存

利用者が公開した通知メールの画像によると、OpenCodeは廃止作業を進めていた旧システムへの不正アクセスを確認したという。その結果、Consoleのワークスペースに保存されていたOpenAIやAnthropicなどの外部AIサービスのAPIキーが、第三者に露出した可能性があると説明している。ただし、対象となったすべてのAPIキーが実際に持ち出されたり、不正利用されたりしたと確認されたわけではない。

通知では、影響を受けた利用者に対し、各AIサービスの管理画面で該当するAPIキーを失効させ、新しいキーへ交換するよう求めている。また、交換したキーを使用するアプリケーションの設定を更新するとともに、最近のAPI利用履歴に不審な活動がないか確認することも推奨している。今回問題になっているのは、外部AIサービスのAPIを呼び出すための認証情報だ。OpenCodeへのログインパスワードや、Console自体が発行するAPIキーとは異なるため、対処する際には混同しないよう注意が必要となる。

通知を受け取ったMartin Bowling氏が公開した追加の案内には、影響を受けた旧Consoleに保存されていたAPIキーが、ワークスペース名とキーの末尾を使って列挙されていた。その通知では、最も早い流出の可能性がある時刻として、10月17日00時30分（UTC、日本時間の同日9時30分）が示されている。ただし、これは特定の利用者に対して通知された時刻であり、すべての対象キーが同時刻に侵害されたことを意味するものではない。

追加の案内では、その時点でAPIキー以外のデータが露出した形跡は確認されていないとも説明されている。ただし、これは調査途中の報告であり、被害範囲が最終的に確定したわけではない。OpenCodeも最初の発表で事件への対応を継続していると説明しており、侵入に悪用された脆弱性や、保存されていたAPIキーの暗号化方式などは明らかにしていない。廃止作業中の旧システムが侵害されたという情報だけで、APIキーが平文で保存されていた、あるいは特定の実装ミスが存在したと断定することはできない。

それでも、廃止予定の環境に有効な認証情報が残っていた可能性は、システム移行時のセキュリティ管理について重要な問題を提起している。新しいシステムへの移行が完了しても、旧環境に有効なAPIキーが残されていれば、その環境が侵害された際に認証情報が悪用される危険性は残る。システムの廃止には、単に利用者向けの機能を停止するだけでなく、保存されていた認証情報を確実に無効化・削除する管理も必要となる。

AD

「大規模な蒸留攻撃」とは何を意味するのか

OpenCodeは今回の侵害について、大規模な蒸留攻撃に関連する事件だと説明している。AIにおける蒸留とは、あるモデルが生成した出力を学習データとして利用し、別のモデルに知識や能力を移す技術だ。Anthropicによる解説にもあるように、蒸留自体は自社モデルの小型化や効率化など、正当な目的でも広く利用されている。問題となるのは、他社のモデルから許可なく大量の応答を収集し、別のモデルの開発や性能向上に利用する行為だ。

ただし、APIキーの流出と蒸留攻撃は、同じ出来事を指すわけではない。仮に攻撃者が第三者のAPIキーを入手すれば、キーの正規所有者に利用料金を負担させながら、AIモデルに大量の要求を送って応答を収集できる。その出力を別のモデルの学習に利用すれば、不正に取得した認証情報を使った蒸留攻撃につながる可能性がある。しかし、APIキーをどのように入手したのか、どのシステムに侵入したのか、実際に収集した出力を学習に使用したのかは、それぞれ別に確認する必要がある。

現時点でOpenCodeが公表した内容には、露出したAPIキーが大量のAPI要求に利用されたことを裏付ける記録や、収集した出力が別のモデルの学習に使われたことを示す具体的な証拠は含まれていない。また、攻撃者の身元についても説明していない。運営側が「蒸留攻撃」と説明していることだけでは、旧システムが侵害された原因や、APIキーがどのように悪用されたかまでは判断できない。

この区別は、セキュリティ対策を考えるうえでも重要となる。AIモデルの出力が無断で学習に利用されることを防ぐ対策と、外部サービスの認証情報が不正に取得されることを防ぐ対策では、保護すべき対象が異なるためだ。今回の事件については、蒸留攻撃との関連性だけでなく、旧システムへの具体的な侵入経路や、露出した可能性のあるAPIキーをどのように特定したのかについても、運営側からの説明が求められる。

Consoleの予算制限では、流出したAPIキーの直接利用を止められない

OpenCode Consoleの現行仕様では、管理者が外部AIサービスのAPIキーを登録すると、ワークスペースのメンバーは元のキーを直接確認することなく、そのAIモデルを利用できる。各メンバーに個別のAPIキーを配布する必要がなく、接続設定や利用状況を一元管理できることが利点だ。一方、外部AIサービスのトークン利用料金は、原則としてそのサービスの提供元から利用者へ請求され、Consoleは要求ごとの費用を記録する仕組みとなっている。

Consoleには月次予算を制限する機能も用意されている。料金情報が設定された持ち込みプロバイダーの利用も集計対象となり、設定した予算上限に達すると、新たなAPI要求を拒否する。ただし、予算の確認は要求の開始時に行われるため、すでに処理中の要求によって最終的な利用額が上限をわずかに超える場合はある。

重要なのは、Consoleの予算制限が適用されるのは、Consoleを経由する要求に限られるという点だ。外部AIサービスのAPIキーそのものが流出し、攻撃者が発行元のAPIへ直接アクセスした場合、その要求はConsoleの予算管理を通過しない。したがって、Console側の設定だけでは不正利用を防げない可能性がある。

ConsoleのAPIキー管理と課金に関する仕様を踏まえ、各操作で制御できる範囲を整理すると次のようになる。

操作 制御できる対象 外部APIキーが流出した場合の効果
Consoleの予算上限を設定 Consoleを経由するAPI要求 外部AIサービスへの直接要求には適用されない
Consoleからプロバイダーを削除 Consoleに登録されたプロバイダーとモデルの利用設定 発行元のAPIキーまで失効するとは公式文書に記載されていない
外部AIサービス側でAPIキーを失効 発行元での該当APIキーによる認証 旧キーを使った今後のアクセスを防げる。ただし、すでに発生した料金は取り消されない

この比較は、2026年10月19日時点のConsoleの公開仕様に基づき、API要求が通る経路ごとに制御範囲を整理したものだ。今回の攻撃で実際に外部AIサービスへの直接要求が使われたと確認されたわけではなく、侵害された旧システムの内部構造を示すものでもない。

こうした仕組みの違いがあるため、OpenCodeが利用者に求めているのは、外部AIサービスの発行元でAPIキーを失効させ、新しいキーへ交換する対応だ。Console上でプロバイダーを削除したり、予算上限を変更したりしても、発行元のAPIキーが有効なままであれば、そのキーを使って直接アクセスできる可能性が残る。流出した認証情報の悪用を防ぐには、実際に認証を行うサービス側で旧キーを無効化する必要がある。

AD

Anthropicは該当キーを失効、利用者にも交換を要請

AnthropicのLydia Hallie氏は10月17日の投稿で、OpenCodeと連携し、今回の事件で影響を受けたと考えられるClaude APIキーを失効させたと説明している。ただし、これは疑わしいキーを対象とした措置であり、OpenAIやGoogleなどを含むすべての外部AIサービスのAPIキーについて、失効処理が完了したことを意味するものではない。また、OpenCodeが対応への協力先としてGoogleの名前を挙げていることも、それだけでGoogleのAPIキーが流出したと確認されたことにはならない。

OpenCodeから通知を受け取った利用者は、通知で対象とされた外部AIサービスのAPIキーを発行元で失効させ、新しいキーを作成する必要がある。そのうえで、該当キーを使っているアプリケーションや自動処理、各種連携サービスの設定も更新しなければならない。不審なAPI利用や想定外の請求が発生していないか確認する際には、Consoleの利用記録だけでなく、実際に料金を請求する外部AIサービス側の利用履歴や請求情報も照合することが重要だ。

一方、通知を受け取っていない利用者については、今回の侵害による影響はないというのがOpenCodeの説明だ。利用者の端末にAPIキーを保存し、OpenCodeアプリから外部AIサービスへ直接接続していた場合まで、今回の侵害対象だったと考える根拠はない。ただし、自分がどちらの接続方法を利用していたか分からない場合は、Consoleに外部APIキーを登録した履歴と、OpenCodeからの通知の有無を確認しておくとよい。

今回の事件は、AIゲートウェイを利用する際の利便性と、認証情報を外部サービスに預けるリスクの両面を浮き彫りにした。チームのメンバーにAPIキーを直接配布せずに済む仕組みは管理上の利点があるが、その分、ゲートウェイを運営するサービス側の保管体制が重要になる。特に、旧システムから認証情報をいつ削除するのか、侵害が発生した際に対象キーをどのように特定し、発行元での失効まで確実につなげるのかは、企業がサービスを選ぶうえで確認すべき点だ。今後、OpenCodeが侵入経路や被害範囲、APIキーの管理・失効対応についてどこまで具体的に説明するかが、同サービスのセキュリティ体制を評価する重要な判断材料となる。