【ITニュース解説】OpenCode's leak was Console, not your CLI

2026年10月17日にOpenCodeで発生したセキュリティインシデントは、多くのシステムエンジニアを目指す初心者を含む開発者の間で大きな波紋を呼んだ。当初、「OpenCodeがハッキングされ、ユーザーの認証情報が流出した」という情報が広まったことで、多くの人々が日頃から利用しているOpenCode CLI（コマンドラインインターフェース）の安全性を懸念し、自分のシステムが危険に晒されていないか確認に追われた。しかし、実際に情報が漏洩したのはOpenCode CLIではなく、「OpenCode Console」という別のサービスだった。この二つの製品の違いを理解することが、今回のインシデントがなぜこれほど混乱を招いたのかを理解する上で非常に重要となる。

OpenCode ConsoleとOpenCode CLIは、その名称が似ているため混同されがちだが、機能と認証情報の取り扱い方において根本的な違いがある。OpenCode Consoleは、外部のプロバイダー（例えばOpenAIやAnthropicなど）のアカウントを接続し、その認証情報（APIキーなど）をOpenCodeのシステム側で保存・管理し、チーム内で共有することを目的としたホスト型のサービスである。つまり、Consoleを利用するということは、プロバイダーの認証情報をOpenCodeのサーバーに預けることを意味する。これはチームでの共同開発には便利だが、認証情報の管理がOpenCode側に委ねられる。

一方、OpenCode CLI、またはローカルコーディングエージェントと呼ばれるツールは、ユーザー自身のローカルマシン上で動作する。このローカルエージェントは、プロバイダーの認証情報をユーザーのPCのディスク上に保存し、その認証情報を使って、ユーザーが設定したエンドポイントにリクエストを送信する。そのエンドポイントは、ユーザーのローカルで動作するプロキシかもしれないし、OpenCodeベンダーのホスト型ゲートウェイかもしれないし、プロバイダーのAPIに直接接続するものかもしれない。認証情報がどこに送られるかは、ユーザーのローカル設定に完全に依存する。つまり、OpenCode CLIを使っているからといって、必ずしもOpenCodeのホスト型サービスに認証情報が渡されているわけではないのだ。この違いが明確に伝わらなかったために、「OpenCode」という共通の名前が、多くの開発者に自身の認証情報も漏洩したのではないかという不安を与え、混乱を招いた。

ベンダーからの公式声明も、当初は不明瞭な点が多かった。声明では、「廃止作業中のレガシーシステムへの不正アクセス」があり、「ワークスペースに保存されていたサードパーティプロバイダーのキーが露出した可能性がある」と述べられた。そして、ユーザーに対しては、プロバイダー側でキーを取り消し、新しいキーに交換し、最近の使用状況を確認するよう指示が出された。これは、AIモデルが誤作動したといった類のものではなく、認証情報を保管するシステム自体が不正にアクセスされ、認証情報が流出したという典型的なセキュリティインシデントだった。もし最初から「OpenCode Consoleというホスト型サービスから認証情報が漏洩した」と明確に伝えられていれば、多くの開発者は自分の環境への影響をより迅速に判断できたはずだ。

では、自分の認証情報が今回のインシデントで影響を受けたOpenCode Consoleに保存されていたかどうかをどう確認すればよいのだろうか。記事の筆者は、自身が影響を受けていないことを確認するために、以下の四つのチェックを行ったと説明している。

まず、最も重要な確認は「保存されているキーがどのエンドポイントに認証を行うか」である。これは、ローカルエージェントの設定ファイルを開き、各プロバイダーのbaseURL設定を確認することで判断できる。もしそのURLが 127.0.0.1 や localhost など、ローカルで動作するプロセスを指している場合、認証情報はユーザー自身のマシン上で処理されており、OpenCodeのホスト型サービスには渡されていない可能性が高い。しかし、もしベンダーのゲートウェイURLなど、外部のホスト型サービスを指している場合は、OpenCode Consoleを利用していた可能性が高く、直ちにキーの取り消しと交換を行うべきだ。

次に、「ディスク上にいくつの認証情報が保存されているか」を確認する。これは、認証情報ファイルを調べて、いくつのプロバイダーのエントリがあるかを確認する作業だ。

三つ目は、「同じキーの余分なコピーがどこかにないか」を徹底的に検索することである。これは非常に見落とされやすいが重要なステップで、プロジェクトファイル、スキル定義ファイル、ドットファイル（設定ファイル）、さらにはシェル履歴ファイルなど、広範囲にわたって正確なキー文字列を検索する。過去に誤ってバージョン管理リポジトリにコミットされて削除されたり、バックアップファイルとして残されていたりする可能性もあるため、これらのコピーが存在しないか慎重に確認する必要がある。ローカルでキーを扱っていたとしても、このように複数の場所に複製されたキーが存在すれば、それが別の経路で流出するリスクも考えられるからだ。

最後に、「設定リポジトリにキーがコミットされていないか」を確認する。Gitなどのバージョン管理システムを使っている場合、認証情報ファイルが誤ってリポジトリに含められてしまっていないかを git ls-files コマンドなどでチェックする。認証情報ファイルは通常、バージョン管理の対象外とするべきだが、不注意によって公開リポジトリにコミットされてしまう事故も実際に発生し得るため、この確認も怠ってはならない。

これらのチェックによって、多くのユーザーは自分のキーがOpenCode Consoleに保存されていなかったことを確認できたかもしれない。しかし、ローカルモードが完全に「安全」であると考えるのはまだ早計だ。ローカルに保存された認証情報にも、いくつかのリスクが存在する。例えば、多くのケースで認証情報はプレーンテキストのJSON形式で保存されており、ユーザー自身の権限で実行される任意のプロセスから簡単に読み取ることができてしまう。ファイルパーミッション 600 は、他のユーザーからのアクセスを防ぐが、悪意のあるソフトウェアが自身のユーザーIDで実行された場合は、認証情報を読み取ることが可能になってしまう。また、古い認証情報がバックアップファイルなどに残存しているケースもある。一度キーを更新したとしても、古い値がディスク上に残っていれば、それが後にインシデントの原因となる可能性もゼロではない。さらに、設定ディレクトリが公開リポジトリとして管理されている場合、不注意な git add -A コマンド一つで、本来公開すべきではない認証情報ファイルがパブリックな場に流出するリスクも常にある。

今回のインシデントから得られる教訓として、ホスト型キーサービスを利用するユーザーが今後取るべき五つのステップが示されている。

まず、自分が実際にどの製品（CLIかホスト型サービスか）を使っていたのかを、記憶ではなく設定ファイルなどの具体的な情報に基づいて明確に判断することが重要だ。次に、もしプロバイダーをホスト型サービスに接続していた場合は、そのプロバイダーのダッシュボードにアクセスしてキーを取り消し、新しいキーを発行する必要がある。ホスト型サービス側でキーを無効にするだけでは不十分であり、プロバイダー側での操作が最終的な権限を持つ。三つ目に、各プロバイダーの過去二週間分の使用状況グラフを詳細に確認し、不審な使用量の急増がないかを探す。認証情報が漏洩した場合、通常はすぐに不正利用の兆候が現れるため、これが重要な手がかりとなる。四つ目に、リポジトリ、バックアップ、シェル履歴、CI/CDのシークレット管理、古いブランチの.envファイルなど、認証情報の二重コピーが存在しないか徹底的に確認する。そして最後の五つ目として、エージェントがキーを使用するようなシステムにおいては、エージェント自体がキーを直接保持しない経路を優先すべきだ。例えば、ネットワークレイヤーで認証情報を注入するローカルプロキシを利用する方式は、エージェントが侵害された際の被害範囲を、認証情報そのものではなく、せいぜい認証情報を使ったリクエストに限定できるため、より安全性が高いと言える。エージェントをサンドボックス化するだけでは、キーがエージェントからアクセス可能なサービス内にあれば意味がない。エージェントがキーそのものにアクセスできないようにすることが、根本的なセキュリティ強化につながるのだ。今回のインシデントは、システムの名称と実際の機能、そして認証情報の保管場所が明確に伝わっていなかったことが、ユーザーの不安と混乱を招いた一例と言えるだろう。