ローカル環境でテスト済みの OpenCode 向けベスト LLM
OpenCode LLM テスト — コーディングと精度の統計
OpenCode が、ローカルでホストされているいくつかの Ollama LLM とどのように連携するかをテストしました。また比較のために、OpenCode Zen から Free モデルもいくつか追加しています。
OpenCode は、現在の AI 開発者ツール エコシステムにおいて、最も有望なツールの一つです。
TL;DR - OpenCode に最適な LLM
ローカル環境における明確な勝者：llama.cpp 上の Qwen 3.5 27b Q3_XXS
IQ3_XXS 量子化レベルの 27b モデルは、私の 16GB VRAM 環境（CPU と GPU の混合使用）で、すべての 8 つの単体テストが合格し、完全な README を備えた機能する Go プロジェクトを生成しました。推論速度は 34 トークン/秒でした。星 5 つ、条件なし。これが私のローカル OpenCode セッションのデフォルト選択です。
Qwen 3.5 35b on llama.cpp — コーディングには高速だが、すべてを検証せよ
35b モデルは、高速なエージェント型コーディングタスクに優れています。しかし、マイグレーションマップのテストで重大な信頼性の問題が露呈しました。IQ3_S の 2 回の実行において、63〜73% のスラッグ（URL 末尾の識別子）不一致が発生しました。また、IQ4_XS 量子化では、ページのスラッグ自体を完全に忘れてしまい、異なる 8 つのページをすべて同じ URL にマッピングしてしまうカテゴリパスを生成してしまいました。IndexNow タスクにおけるコーディングの質自体は確かに良かったため、このモデルの使用価値はあると言えますが、構造化されたタスクやルール遵守タスクにおいては、出力をそのまま信頼してはいけません。必ず検証が必要です。検証はオプションではありません。
意外にも優秀：Bigpicle（OpenCode Zen 提供）
タスク完了に最も高速でした（1 分 17 秒）。より重要なのは、コーディングを開始する前に、Exa Code Search を使って IndexNow プロトコル仕様を実際に検索する時間を取った唯一のモデルだったことです。初回試行で正しいエンドポイントをすべて見つけました。OpenCode Zen にアクセスできる場合、このモデルは期待以上の性能を発揮します。
良好だが、高思考モードでのみ有効：GPT-OSS 20b
デフォルトモードでは GPT-OSS 20b は失敗します。WebFetch コールが行き詰まり、そこで止まってしまいます。しかし、高思考モード（high thinking mode）に切り替えると、実際に能力のあるコーディングアシスタントへと変貌します。フラグのパーシング、正しいバッチ処理ロジック、単体テストの通過など、すべて高速に完了します。すぐに切り捨てる前に、この点を念頭に置いてください。ただし、GPT-OSS 20b は高思考モードでも構造化タスクでは失敗しました。
エージェント型コーディングには不向き：GPT-OSS 20b（デフォルト）、Qwen 3 14b、devstral-small-2:24b
これらは以前、チャットや生成タスクの速度において私の最爱でした。しかし、エージェントモードではすべて実質的な問題を抱えています。Qwen 3 14b は、何かを見つけられなかったと認めるのではなく、ドキュメントをハルシネート（幻覚）します。GPT-OSS 20b（デフォルト）は WebFetch が失敗すると停止します。Devstral は基本的なファイル操作で混乱します。OpenCode においては、生速度よりも、指示遵守能力とツール呼び出しの質がはるかに重要です。
テストについて
opencode で実行される各モデルに、以下の 2 つのタスク（プロンプト）を与えました。
私のウェブサイトの更新を通知するために、bing や他の検索エンジンの indexnow エンドポイントを呼び出す Go の CLI ツールを作成してください。- ウェブサイトのマイグレーションマップを準備してください。
Indexnow プロトコルが何かご存知ですよね？
2 つ目のタスクについては、このウェブサイトの古い投稿を、ブログ URL 形式（例：https://www.glukhov.org/post/2024/10/digital-detox/）から、トピッククラスター形式（この記事の URL のように：https://www.glukhov.org/ai-devtools/opencode/llms-comparison/）へマイグレーションする計画を立てています。そこで、OpenCode の各 LLM に、私の戦略に従ってマイグレーションマップを準備するように依頼しました。
LLM の多くは、ローカルでホストされた Ollama で実行し、他のいくつかはローカルでホストされた llama.cpp で実行しました。Bigpicle や他の非常に大きな言語モデルは OpenCode Zen から提供されました。
各モデルの結果
qwen3.5:9b
最初のタスクで完全に失敗しました。モデルは思考プロセスを経て、関連するサービス（Google Sitemap、Bing Webmaster、Baidu IndexNow、Yandex）を正しく特定しましたが、実際にはどのツールも呼び出しませんでした。単一のファイルも触れずに「ビルド」サマリーを生成するだけで、ツール呼び出しはゼロでした。
qwen3.5:9b-q8_0
デフォルトの量子化からの一歩前進です。少なくとも go.mod と main.go は作成されました。しかし、すぐに立ち往生し、欠落しているインポートを追加する必要があると認め、シェル here-doc を使ってファイルを全体書き換えようとして失敗しました。機能しないものをビルドするのに 1 分 27 秒かかりました。
Qwen 3 14b
プレッシャー下での典型的なハルシネーションです。3 回連続で IndexNow ドキュメントの取得を試みましたが、すべて誤った URL（github.com/Bing/search-indexnow）からの 404 エラーに直面しました。何も見つけられなかったと認める代わりに、自信満々な答えを捏造しました（誤った API エンドポイント、誤った認証方法）。再度検索を促すと、また別の 404 を返す URL を示す、2 番目の捏造された答えを生成しました。報告された情報は誤りでした。これは私が最も避けたい失敗モードです。
GPT-OSS 20b
少なくとも行動は正直で体系的でした。長い WebFetch コールのチェーンを試みました — indexnow.org、さまざまな GitHub リポジトリ、Bing 自身のカテゴリなど — ほとんどすべてで 404 または Cloudflare のブロックに遭遇しました。各失敗を透明に記録しました。結局のところ、機能するツールを構築するための十分な情報を集めることはできませんでしたが、Qwen 3 14b と異なり、事実に基づかないものを捏造しませんでした。ただ、突き抜けられなかっただけです。
GPT-OSS 20b (high thinking)
デフォルトモードとは意味をなすほど異なる物語です。高思考モードを有効にすると、モデルは同じ行き止まりのフェッチから回復し、完全で機能するツールを構築することに成功しました。IndexNow 仕様に従い、適切なフラグパーシング（--file、--host、--key、--engines、--batch、--verbose）、単一 URL への GET、複数 URL への POST バッチ処理を実装しました。
ドキュメントと単体テストを求めると、両方を提供しました。テストはすべて合格しました：
=== RUN TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok indexnow-cli 0.002s
高速でもありました — 初期ビルドは 22.5 秒。高思考モードにより、gpt-oss:20b は実際に使用可能になりました。
qwen3-coder:30b
最も興味深い失敗例です。実際にツールをコンパイルして、実エンドポイントに対して実行し、Bing、Google、Yandex からの実際の API エラーを確認しました。そして修正を開始しました：
Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"
これは良い本能です。問題は、CPU 使用率が 720%、GPU 使用率が 7% という極めて非効率な状態で稼働していたことです。22GB のモデルとしては非常に非効率でした。11 分 39 秒かかり、最終出力も「完全に期待通りではありません」でした。また、README.md を作成してくれたのは良い点です。悪いモデルではありませんが、私のセットアップでは非常に遅く、IndexNow プロトコルフォーマットを完全に理解できていませんでした。
qwen3.5:35b (Ollama)
結果は確実ですが、遅いです。適切な Go プロジェクトを作成し、テストを書き、すべてが合格しました：
=== RUN TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN TestGetPublicKeyName/standard_root
--- PASS
=== RUN TestGetPublicKeyName/custom_root
--- PASS
欠点は、ビルド時間が 19 分 11 秒かかったことです。CPU/GPU 分割比が 45%/55% で実行される 27GB モデルとしては、対話的な使用には遅すぎます。品質はありますが、レイテンシがワークフローを殺しています。
Bigpicle (big-pickle)
最初のタスクにおける目覚ましいパフォーマンスでした。一行のコードを書く前に、Exa Code Search を使って IndexNow プロトコルを実際に調査しました：
◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"
そして正しいエンドポイントを見つけました：
- グローバル：
https://api.indexnow.org/indexnow - Bing：
https://www.bing.com/indexnow - Yandex：
https://webmaster.yandex.com/indexnow - Yep：
https://indexnow.yep.com/indexnow - Amazon：
https://indexnow.amazonbot.amazon/indexnow
cobra インポートの問題をクリーンに解決（go mod tidy）し、ツールは 1 分 17 秒で完成しました。テスト中に Bing から返されたレートリミット応答は、無効なテストキーに対する予想される挙動であり、モデルはこれを正しく「ツールが機能している」と特定しました。印象的でした。
devstral-small-2:24b
基本的なレベルで混乱しました。シェルコマンド（go mod init indexnowcli、go mod tidy）を直接 go.mod ファイルに書き込もうとし、パースエラーをトリガーしました。それでも何らかの形でバイナリ（7.9M）をビルドしましたが、結果の CLI はあまりにも単純でした。単に indexnowcli <url> <key> であり、フラグ処理もマルチエンジンサポートも何もない状態でした。2 分 59 秒 + 1 分 28 秒をかけて、実用的ではないツールを完成させました。
qwen3.5:27b (llama.cpp, IQ3_XXS 量子化)
これは、すべてのローカルランナーの中で最も私を驚かせました。llama.cpp（主に CPU）上で Qwen3.5-27B-UD-I3_XXS.gguf として実行され、完全なテストカバレッジ（8 つのテストすべて合格）を備えた完全なツールを作成しました。インストール手順とプロトコル説明を含む適切な README も作成されました：
PASS indexnow 0.003s
対応エンジン：Bing、Yandex、Mojeek、Search.io。ビルド時間：ツール 1 分 12 秒、テストとドキュメント 1 分 27 秒。速度：34 トークン/秒。品質：星 5 つ。CPU+GPU で実行される量子化モデルとしては驚異的な結果です。
qwen3.5:35b (llama.cpp, IQ3_S 量子化)
llama.cpp 上で Qwen3.5-35B-A3B-UD-IQ3_S.gguf として実行されました。ここでの私のメモは短いです：「素晴らしい！」 — それで全てを物語っています。同じ量子化レベルのより大きなモデルは、27b バリエーションと同じか、それ以上にもっと良い結果をもたらしました。
マイグレーションマップの結果
2 つ目のタスクでは、別々のバッチで 7 つのモデルを実行しました。すべてのモデルに同じ指示、サイト構造、ページリストを与えました。制約は明確でした：スラッグ（最後のパスセグメント）は変更してはいけません。例えば、/post/2024/04/reinstall-linux/ は /.../reinstall-linux/ にならなければなりませんが、それ以外にはなりません。
各モデルが生成したスラッグ不一致の数を測定しました — 生成されたターゲットスラッグがソーススラッグと異なるケースです。
| モデル | 行数 | スラッグ不一致 | エラー率 |
|---|---|---|---|
| minimax-m2.5-free | 80 | 4 | 5.0% |
| Nemotron 3 | 78 | 4 | 5.1% |
| Qwen 3.5 27b Q3_XXS (llama.cpp) | 80 | 4 | 5.0% |
| Qwen 3.5 27b Q3_M (llama.cpp) | 81 | 6 | 7.4% |
| Bigpicle | 81 | 9 | 11.1% |
| mimo-v2-flash-free | 80 | 42 | 52.5% |
| Qwen 3.5 35b IQ3_S - 2 回目実行 (llama.cpp) | 81 | 51 | 63.0% |
| Qwen 3.5 35b IQ4_XS (llama.cpp) | 80 | 79 | 98.8% |
7 つのモデルすべてが同一のことをしました：古い 2022 形式の URL には、スラッグに月プレフィックスが含まれていました（例：/post/2022/06-git-cheatsheet/ → スラッグ 06-git-cheatsheet）。すべてのモデルがこのプレフィックスを取り除き、新しいスラッグとして git-cheatsheet を使用しました。上位 3 つのモデルでは、これが 4 つの一貫した不一致となっています — つまり、ベースラインは 0 ではなく、それぞれ 4 つのエラーです。
本当の分岐は、そのベースラインから始まります。minimax-m2.5-free、Nemotron 3、Qwen 3.5 27b Q3_XXS は、その 4 つのレガシーパス以外でスラッグルールを違反したことはありません。Qwen 3.5 27b Q3_M はさらに 2 つ追加しました（cognee 記事のスラッグを改名し、Base64 を小文字化）。Bigpicle はさらに 5 つ追加し、主に長いスラッグを短縮しました。
外れ値は別のカテゴリーに属します。Qwen 3.5 35b IQ3_S は、ソースを保存する代わりに、ページタイトルからスラッグを一貫して書き換えました（例：executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux、file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24）。2 回目の実行はわずかに良くなりました（59 対 51）が、同じ挙動を示しました。また、ソースパスをハルシネートしました：comparing-go-orms-gorm-ent-bun-sqlc を comparing-go-orms-gorm-ent-bun-sql に静かに変更しました（c を削除）、そのためその行の両側は互いに一致しましたが、どちらも誤っていました。mimov2 も同様に、短縮に積極的でした：gnome-boxes-linux-virtual-machines-manager → gnome-boxes、vm-manager-multipass-cheatsheet → multipass。
35b の IQ4_XS 量子化は、完全に異なる失敗カテゴリーです：98.8% のスラッグ不一致 — しかし、問題は間違ったスラッグではなく、モデルがスラッグ自体を含めるのを忘れたことです。/new-section/page-slug/ ではなく、/developer-tools/terminals-shell/ や /rag/architecture/ のようなカテゴリパスを生成しました。8 つのソースページがすべて /developer-tools/terminals-shell/ にマッピングされ、すべてが同じ URL を指しました — これを使用すれば壊滅的な結果になります。/developer-tools/ だけで 5 つの別々のページが集積しました。出力は完全に使用不能です。
このタスクでは、小さい量子化モデルである Qwen 3.5 27b Q3_XXS が、最も優れたパフォーマーに匹敵しました — 一方、2 つの 35b 量子化は、それぞれ異なる方法でひどく失敗しました。
結論
私は、llama.cpp 上で量子化された重みで Qwen 3.5 35b と Qwen 3.5 27b の両方をローカルで実行することに満足しています — ハードウェアの制約は現実的なものですが（16GB VRAM には IQ3/IQ4 量子化が必要）、ワークフローは堅牢です。
27b Q3_XXS は信頼性の高い日常運転車です。 指示を正確に遵守し、完全な出力を生成し、対話的な使用に十分な速度を誇ります。マイグレーションマップタスクでは、最も優れたクラウドモデルに匹敵しました。
35b は能力はあるが、構造化タスクでは予測不可能です。 自由なコーディングタスク（ツールを書いて、これを構築して）には良く機能します。しかし、タスクに厳格なルールがある場合（「スラッグは変更してはいけない」など）、私がテストしたすべての量子化レベルで自由なハルシネーションを行います：タイトルからスラッグを書き換える、スラッグを完全に削除する、誤った出力を自己一貫性に見せるために静かにソースパスを編集するなど。35b を、直接使用する構造化出力を生成する何かに使用する場合は、ワークフローに検証ステップを組み込んでください。出力が妥当に見えるからといって、正しいと仮定しないでください。
これらの LLM がどの速度でパフォーマンスを発揮するか気になる場合は、16GB VRAM GPU 用の Ollama に最適な LLM をご覧ください。
