OpenCode が侵害を通知、Console に預けた API キーが漏れたおそれ:影響を受けるのは誰か、各社の画面で今日やること
ミオ|AI大好きな後輩
この件を報じた OfficeChai の記事は、OpenCode の X の投稿を次のように引いています。前夜にセキュリティ侵害があり、OpenCode Console の利用者の1.4%に影響した。該当者には朝にメールで通知した。メールが届いていなければ影響を受けていない、対象は外部プロバイダを使っていた一部の利用者だった。引用は「external providers」の途中で切れています。
Hacker News に貼られたメール文面は、OpenCode チームからの通知メールとして投稿されたもので、廃止作業中の旧システムへの不正アクセスを挙げ、ワークスペースに保存した OpenAI・Anthropic などのサードパーティのキーが露出したおそれがあるとして、各プロバイダの画面でキーを失効・再発行し、そのキーを使うアプリを更新し、直近の利用に思い当たらない動きがないかを確かめるよう求めています。
Hacker News のスレッドには、Console にキーを預けた人と OpenCode を CLI で使っている人のどちらに関係するのかを問うコメントが並んでいます。どちらの人にも役立つよう、影響を受けるのは誰かと各社の画面でやることを整理します。筆者は開発ツールの提供元の告知を公式資料と照らして追っていて、本稿は上の投稿とメール文面に、OpenCode の docs・status ページ・GitHub の issue、Anthropic・OpenAI・Google の docs を10月18日の朝(日本時間)に取得して突き合わせました。侵害の原因の評価には踏み込みません。
影響を受けるのは誰か
メール文面が挙げているのは、ワークスペースに保存したキーです。OpenCode の v2 docsによると、Console は OpenCode の任意のサービスで、アカウントには、一人で使っていても自分だけの Personal ワークスペースがあります。docs で保存先を見ると、キーの置き場は2か所あります。
- Console に預けたキー:OpenCode の v2 docsによると、Anthropic や OpenAI などの自分のアカウントを Console に接続すると、Console が資格情報を保存して gateway から各プロバイダを提供し、メンバーはプロバイダのキーを見ずにモデルを使えます
- 手元に入れたキー:OpenCode の v1 docsによると、/connect でプロバイダのキーを追加すると、~/.local/share/opencode/auth.json に保存されます
v2 docs は、/connect でワークスペースを選ぶと、Console に接続したプロバイダが「ワークスペース名 / プロバイダ名」として現れると書いています。プロバイダを接続するのはワークスペースの owner と admin で、メンバーはキーを見ずにそのモデルを使えます。CLI で使っていても、チームのワークスペースを選べば、Console に保存されたキーを通ります。Hacker News のコメントには「CLI だけなら影響はない」という読み方が並びますが、OpenCode のメール文面にその一文はなく、書かれているのは「ワークスペースに保存した」キーという範囲です。
次の2つの問いで見分けます。通知のメールは届きましたか。ワークスペースにキーを預けた覚えはありますか。
ここでの「預けた覚え」は、自分で接続した場合に限りません。チームのワークスペースを /connect で選んで使っているなら、管理者が接続したキーも同じ Console に保存されています。心当たりがなければ、管理者に確かめます。管理者が接続したキーなら、失効・再発行と接続の更新を管理者に依頼します。

OpenCode の X の投稿(OfficeChai の記事が引いた文面)とメール文面、OpenCode の docs に基づく図です。通知のメールが届いたかを先に問い、届いていればキーを止める、届いていなくてもワークスペースにキーを預けた覚えがあれば念のため替える、どちらでもなく手元にだけ入れたなら続報を待つ、の3つに分けています。2つ目と3つ目の振り分けは、メールが届いていなければ影響を受けていないという OpenCode の記述と、メール文面が挙げる保存先がワークスペースであることをもとにした、筆者の考える案です。
- 通知のメールが届いた:各社のコンソールでキーを止めます。メール文面の順は、失効と再発行、そのキーを使うアプリの更新、直近の利用の確認です。止める画面は次の節にまとめました
- 通知のメールは届いていないが、ワークスペースにキーを預けた覚えがある:念のためキーを替えます。OfficeChai が引く投稿では、メールが届いていなければ影響を受けていないとされています。一方で、同記事によると侵入の詳細はまだ公表されていません。預けた覚えがあるなら、影響の確定とは別に、安全側に倒してキーを替える選択もあります。アプリの更新は管理者と調整します
- 通知のメールは届いておらず、ワークスペースにキーを預けた覚えもない:続報を待ちます。キーを手元にだけ入れた人はここに当たります。Hacker News に貼られたメール文面では、OpenCode は更新があれば続報を出すと書いています
各社の画面でやること
OpenCode のメール文面の順に、キーを止める場所と使用量を見る場所を、各社の公式資料から拾いました。
- Anthropic:Anthropic のヘルプ記事は、漏れが疑われるときはすぐ失効するよう勧め、Claude Console の API keys のページでキーのメニューから Delete API Key を選ぶと案内しています。利用の確認は、Console でキーごとのログと usage のパターンを見るよう勧めています。Anthropic の API リファレンスには、API でキーの status を inactive などに更新する項目もあります
- OpenAI:OpenAI のヘルプ記事は、漏れたと考えるときは API Keys のページからすぐキーを rotate するよう書いています。使用量は Usage のページで見られ、月次の spend limit にハード上限を付けると、漏れたキーによる想定外の費用を抑えやすいとも書いています
- Google:Gemini API の docsの漏えい時のチェックリストは、新しいキーを作ってアプリを更新し、新しいキーを確かめてから、漏れたキーを Cloud console で無効にする順で、Anthropic が即時失効を勧めるのとは順が違います。古いキーは新しいキーが動くまで削除しないよう書き、使用状況は課金ログと API の使用状況で調べるとしています。Google Cloud の docsは、削除したキーは30日以内なら復元できると書いています。Gemini API の使用量は、Gemini API の課金の docsによると、Google AI Studio の Dashboard の Usage で見られます
- OpenCode の Console:OpenCode の v2 docsによると、provider のページで資格情報をクリックして新しいキーを入れると差し替わります。Disable はメンバーから provider を隠して設定を残し、Remove… は provider とモデルを削除します。この画面の操作が OpenAI などの側でキーを無効にするという記述は、docs にありません。止めるのは上の各社の画面です
OpenCode 側で見えていること
自分が対象かと各社の画面を決めたあとに確かめられる、周辺の状況です。OpenCode のキーの期限切れと偽のインストーラは、どちらも通知との関係が書かれていません。
- ステータス:OpenCode のステータスページは、Console API・Request logs・Inference API を Operational、Free inference を Degraded(理由は上流のプロバイダの問題)と表示しています。表示されている過去の障害は Go や Console API の応答の遅延、Request logs の断続的な可用性の低下などで、侵害に触れた項目はありません
- OpenCode のキー:同じ日のissue #56560に、OpenCode の API キーが期限切れになったという報告があります。エラー文は、キーが期限切れであること、OpenCode Console で新しいキーを作ってクライアントか秘密情報の保管先で置き換えること、サインインし直してもキーは更新されないことを伝えています。OpenCode の bot は、新しいキーを作って opencode auth login で入れ直すよう案内する一方、キーが期限切れになった理由は GitHub の issue では扱わないと書いています。ただし報告者は、試しても同じエラーが出たと返しています。bot は追加の確認項目を示し、それでも失敗する場合は同 issue に記載のサポート窓口へ連絡するよう案内し直しています
- 偽のインストーラ:リポジトリには、「[Easy Install]」と題した偽のインストーラへの誘導の issue が繰り返し立ち、閉じられています。通報の issue #56424は、案内された iex(irm …) が悪意のある PowerShell を取得して実行すると解析しています。OpenCode の bot は、OpenCode は iex(irm …) ではインストールしないと書き、公式の入れ方は README と opencode.ai に載っていると案内しています
まだ分からないこと
- 侵入の詳細:確認できた X 投稿の引用は前夜の侵害、転載メールは旧システムへの不正アクセスと述べています。確認できた引用と転載の範囲には、それ以上の侵入の経路、キーが露出していた期間の長さ、保存していたキーが暗号化されていたか、キー以外のデータが漏れたかの記載はありません
- 呼び方の違い:OfficeChai の記事が引いている X の投稿は、侵害を large scale distillation attack に関連するものと書き、メール文面は廃止作業中の旧システムへの不正アクセスと書いています。2つの関係は説明されていません
キーを替えたあと、エージェントに渡す API キーの使用上限を決めるときは、有料の既刊コーディングエージェントにAPIキーを渡す前に:止まる上限と通知だけの上限を見分け、上限到達で再試行を止めるが、上限が止まるのか通知だけなのかの見分け方を扱っています。
参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。
