7月20日、wren.wtfが「Stop Using OpenCode」と題した記事を公開した。GitHubで16万スター超えを誇るAIコーディングエージェント「OpenCode」について、セキュリティ設計の根本的な欠陥を指摘し、「使っている全員が今すぐ使用をやめるべきだ」と断言する内容だ。
Claude CodeやGemini CLIなどのAIコーディングエージェントが相次いでリリースされ、ローカル環境でのLLM活用が急速に広まった2025〜2026年。その流れの中でOpenCodeは急速にスターを集めたが、本記事はその人気ぶりに警鐘を鳴らす。指摘は「腹立たしいこと（Annoying Things）」と「警戒すべきこと（Alarming Things）」の2層構造で展開され、単なる不満ではなくコードレベルの根拠を伴っている点が特徴だ。
OpenCodeとは何か
OpenCode（GitHubリポジトリ）はオープンソースのAIコーディングエージェントで、ローカルLLMを含む各種モデルと接続し、ファイル操作やコマンド実行をエージェントに委譲できるツールだ。記事の筆者はM4 MaxマシンでQwen3.6-27Bのローカル推論環境を用いて検証しており、参照したのはgitバージョンbaef5cd4のソースコードだ。
腹立たしいこと：ツールとして壊れている
プロンプトキャッシュの無駄遣い
ローカルLLM推論の最大のボトルネックはプリフィル（既存のコンテキストをGPUで再評価する処理。キャッシュが効かないと全トークンを処理し直すため、長いコンテキストでは非常に時間がかかる）だ。筆者の環境では、キャッシュミスが発生すると応答開始まで10分間のGPU全力稼働を強いられる。
OpenCodeはこのキャッシュを至る所で無効化する：
- セッションのターン0のシステムプロンプトに現在の日付を埋め込み、毎回のターンで再評価する。深夜0時を跨ぐだけでフルキャッシュミスが発生する。
AGENTS.mdをファイルシステムのglobで毎ターン再読み込みする。- コンテキストプルーニング（古いツール呼び出し結果の削除）を「エージェント→ユーザー」の遷移ごとに実行し、プレフィックスの大部分を無効化する。プルーニングの保護範囲は
const PRUNE_PROTECT = 40_000トークン固定で、これは長編小説1冊分に相当する。
プルーニングの設計破綻
プルーニングは全ツール呼び出し結果に等しく適用される（skillツールのみ例外）。実際の破綻シナリオはこうだ：
- 仕様書をコンテキストに読み込む
- 関連コードを読み込み、40kトークンの閾値を超える
- エージェントが脱線したので割り込んで軌道修正する
- 割り込みのタイミングで仕様書全体がコンテキストから削除される
- エージェントは仕様書なしでコードを書き始める
TUIの惨状
OpenCodeはターミナルUI（TUI）を持つが、その実装にも問題が多い：
- RAMを1GBも消費するテキスト表示
- Shift+Enterによる改行入力が壊れており、開発者は「自分の環境では動く」としてissueをクローズした
^Cでセッションが即座に終了する（通常の対話型シェルは^Cで実行中コマンドを割り込み、^Dで終了する）- 長いメッセージのMarkdown再レンダリングが2乗オーダーの計算量になっており、ストリーミング中に数秒のラグが発生する
筆者はメッセージをエディタで書いてペーストするという回避策を取らざるを得なかったと記している。
警戒すべきこと：セキュリティが根本的に壊れている
ここからが本題だ。
デフォルトでリモート接続する
- OpenCodeはデフォルトでリモートモデルに接続する。
- ローカルモデルの設定ドキュメントに明確な例がなく、設定を誤ると気づかないままリモートモデルに繋がる。
- ローカルモデルを正しく設定した場合でも、起動後にインタラクティブに選択するまでリモートモデルが接続済みになっている。
ツール権限の管理が崩壊している
OpenCodeはLLMにファイル操作やコマンド実行を許可するRPCを提供しているが、その制御機構が機能していない。
プロジェクトディレクトリ外へのアクセス要求が検出された場合、Yes/No/Alwaysの選択肢が表示される。**Neverという選択肢が存在しない。さらに、サブエージェントが/tmpへのアクセスを要求した際にNoを選択すると、そのサブエージェントごと強制終了され、途中まで積み上げたコンテキストが全消滅する。結果として「Yesと答え続けるしかない」**状況に追い込まれる。
また、ファイルパスの検出をアドホックな文字列パースで行っている実装上の問題もあり、筆者は「人間の疲労や不注意をセキュリティの最終防衛ラインにしてはいけない」と指摘する。
llm | bashというアーキテクチャの限界
筆者はOpenCodeを「llm | bashを繋ぐパイプ」と表現し、そのパイプ部分の実装に根本的な問題があると指摘する。bashコマンドの副作用を実行前に静的に推論することは不可能であり、grepやglobをbashとは別個のツールとして実装しているという事実自体が、この問題の自己告白だと述べている。
OpenCodeはもともとWebスタックを対象とした開発フローを念頭に設計されており、ローカル実行環境のセキュリティモデルとは根本的に相性が悪いというのが筆者の結論だ。
何を使えばいいか
記事の主旨はOpenCodeへの批判であり、代替ツールの包括的な比較は行っていない。ただし、AIコーディングエージェント全般の選択肢としては、AnthropicのClaude CodeやGoogleのGemini CLI、コミュニティ主導のAiderなどが挙げられる。筆者は「LLMを使うこと自体の是非」と「使うなら安全に使えるか」は分けて議論すべきというスタンスを取っており、ローカルLLM活用そのものを否定しているわけではない。
詳細はStop Using OpenCodeを参照していただきたい。
