短い答え: GLM-5.2 は現在、コーディング向けのオープンソース LLM の中で最も強力です。拡張利用では、その出力品質は Claude Sonnet 級に近く、最難関の問題を任せるモデルです。ただし、動作は遅くトークン消費も多いため、高速な API コーディングエージェントには Kimi K2.7 Code、最小コストなら DeepSeek V4 Flash、自分の 24GB GPU なら Qwen3.6-27B を選びます。
これは、Claude Opus 4.8 をクローズドソースの参照として、同じ 2 つのコーディング課題を 5 つのオープンソースの旗艦モデルに与えた結果から得られた結論です。どれも正しいコードを生成しました。違いが出たのは、そこに至るまでに消費したトークン数であり、その差はコストで最大 48 倍にもなりました。
用語について一言:これらのほとんどは、厳密には open-weight モデルです。重みは公開されていますが、学習データは公開されていません。「open source」と表現しているのは、人々がその言葉で検索するからです。この違いが重要になるのは、下の FAQ の 1 つの回答だけです。
どのようにテストしたか
2つのタスク、すべてのモデルに対して同一のプロンプト、2026年7月17日にデフォルト設定で送信:
- Task 1: tricky edge cases を含む duration パース関数を作成する(12件のテストケース)
- Task 2: バグのある interval マージ関数を修正する(6件のテストケース)
私たちはコードをローカルで採点し、各実行につき3つの数値を記録しました。合格率、出力トークン数、そして経過時間です。コストはトークン数に各ベンダーの定価を掛けたもので、その価格は同日に確認しました。2つのタスクはベンチマークではなくプローブですが、これはあなたが何百回も送ることになるような種類の通常のリクエストです。
結果
すべてのモデルがすべてのテストケースに合格しました。したがって、以下の表が示しているのはただ一つ、効率です:
| モデル | 出力トークン数(両タスク) | タスク1時間 | コスト |
|---|---|---|---|
| Kimi K2.7 Code | 2,183 | 45.2s | $0.0090 |
| DeepSeek V4 Flash | 2,231 | 16.7s | $0.00066 |
| DeepSeek V4 Pro | 2,527 | 37.3s | $0.0023 |
| MiniMax M3 | 5,409 | 36.7s | $0.0067 |
| GLM-5.2 | 7,130 | 99.3s | $0.0318 |
| Claude Opus 4.8 (baseline) | 539 | 8.1s | — |
トークン列こそが物語です。GLM-5.2 と MiniMax M3 は「思考」モデルで、デフォルトでは回答前に長く推論します。その推論は出力として課金されます。同じ正しい関数でも、GLM-5.2 は Kimi K2.7 Code の 3 倍のトークンを書きました。
トークン上限を設定すると、さらに悪化します。応答を2,048トークンに制限したところ、どちらのthinkingモデルも予算の全てを推論に使い切り、コードをまったく返しませんでした。お金は払っても、何も得られません。GLM-5.2は、完了する前に16,384トークンの上限が必要で、その2回の失敗だけで約$0.045かかりました。coding agent内でthinkingモデルを使う場合は、定型的な編集ではmax_tokensを増やすか、thinkingをオフにしてください。
比較のために言うと、Claude Opus 4.8 は両方のタスクを 539 トークンで解決しました。オープンモデルは正確性では追いつきましたが、簡潔さでは、クローズドベースラインが依然として 4 倍先を行っています。
デプロイメント階層別の最良のオープンソースコーディングモデル
モデルが実行される場所で選択してください。価格は1Mトークンあたりで、2026-07-17時点で確認済みです。
最強のモデル、待てるなら: GLM-5.2
難易度が高く、複数ステップにわたるコーディング作業では、GLM-5.2の出力品質は、現時点でオープンモデルとしてはClaudeに最も近いものです。エージェント系ベンチマーク(SWE-Bench Pro、Terminal-Bench 2.1)で先頭に立っており、私たち自身の長期的な利用でも、他のモデルがうまく扱えない問題を任せられるのはこれです。詳しくはGLM-5.2 APIガイドをご覧ください。
その品質の代償は忍耐です。これは私たちのテストで最も遅く、最も多くのトークンを消費したモデルでした(Task 1で99.3秒、5,695 tokens)で、応答の遅さはモデル自体というより、ベンダー側のGPU容量の制約を反映しています。$1.40 in / $4.40 out、1M context、通常のMIT。難題と大きなトークン予算を任せ、簡単な修正は別に回しましょう。
高速なAPIコーディングエージェントに最適: Kimi K2.7 Code
私たちがテストした中で最もトークン効率の高いオープンモデル:そのバグ修正は259トークンで済み、Claudeのような簡潔さでした。また、Kiloのタスク完了ベンチマークでも60.7%で首位です。
料金:入力 $0.95 / 出力 $4.00、キャッシュヒット時は $0.19。唯一の実質的な制限はコンテキストで、262K tokens です。一方、この一覧の他の項目は 1M を提供しています。最も近い競合との比較については、Kimi K2.7 Code vs GLM-5.2 をご覧ください。
最高のコストパフォーマンス: DeepSeek V4 Flash
$0.14 in / $0.28 out、ここで最も安いモデルであり、それでも私たちが試したものをすべて通過し、オープンモデルの中で最速でした。公開されているスコア(79.0% SWE-Bench Verified、91.6% LiveCodeBench)は、上位モデルとの差が2ポイント以内に収まっています。コンテキストは1M tokens、ライセンスは通常の MIT です。
ここから始めてください。複数ファイルの作業で差が見え始めたら、V4 Pro に移行してください。
24GBのコンシューマーGPUで最適: Qwen3.6-27B
1枚の一般向けGPUに収まるモデルでありながらSWE-Bench Verifiedで77.2%を記録する高密度な27Bで、r/LocalLLaMAのスレッドで「VRAMが24GBあります。」という書き出しとともに繰り返し挙がるのはそのためです。
そのより高速な兄弟モデル Qwen3-Coder-Next(総計80B、各トークンでアクティブなのはわずか3B、Apache 2.0)は、コミュニティで選ばれる高速モデルです。あるユーザーはフル262Kコンテキストで、単一の RX 9070 XT 上で約20 tokens/s で実行しました。APIとして使いたいなら、Alibaba Cloud 経由で $0.30/$1.50 から利用できます。
ベストな単一GPU自前運用: Gemma 4 31B
Google の model cardによると、31B は 256K のコンテキストで 1 枚の 80GB H100 に収まり、Apache 2.0 の下で提供されています。12B バリアントは 16GB の VRAM で動作します。
1つのサイズ上の落とし穴: MoEモデルは小さな「アクティブ」パラメータ数をうたっていますが、それでも全体の重みを保存する必要があります。DeepSeek V4 Flashはトークンごとに13Bをアクティブ化しますが、総重量は284Bで、4-bitでも約142GBです。これは単一カードではなく、マルチGPUの案件です。
長時間の自律走行に最適な低予算のおすすめ:MiniMax M3
1Mコンテキストを$0.30/$1.20で提供し、数時間にわたるエージェントセッション向けに構築されています — MiniMaxは12時間の無人リサーチ実行を実証しました。結果表で見た思考モデルの冗長さも共有しているため、トークン予算はそれに応じて見積もってください。長時間の実行でコストより品質が重要な場合、上のGLM-5.2がアップグレード版です。
リーダーボードが教えてくれないこと
ベンチマークの数値は今ではかなり近づいています: Stanford's AI Indexは、1位と10位のモデルの差が1年で11.9%から5.4%に縮小したと報告しています。スコア表が今なお隠している3つのこと:
タスクあたりのコストは、トークンあたりのコストより重要です。 GLM-5.2の出力価格$4.40はKimiの$4.00に近く見えます。しかし、実際のトークン数で見ると、同じ作業のコストは3.5倍高くなります。Kiloのライブ統計は極端な例を示しています。DeepSeek V4 Proは、表示価格$0.87に対して、完了したベンチマーク試行1回あたり平均$15.91です。
同じモデルでも、ハーネスが違えば結果も違う。 適切に構築されたエージェントループ(構造化ツール、リトライ、妥当なトークン上限)の中にあるモデルは、素のチャット呼び出しにおける同じモデルとはまったく異なる振る舞いをします。私たちのGLMのゼロコード失敗は、能力不足ではなく、設定の相互作用によるものでした。
各ベンチマークは異なる仕事を測定します。 LiveCodeBenchはアルゴリズム生成であり、DeepSeek V4 Proは93.5%でこれに勝っていて、クローズドモデルの公開スコアを上回っています。SWE-Bench Verifiedはリポジトリレベルのバグ修正であり、Claude Mythos 5は依然として95.5%でリードしており、オープンモデルは約80%です。ランキングを信じる前に、ベンチマークを自分の実際の作業に合わせてください。
Claude サブスクリプションの置き換え
オープンソースに踏み切るよくあるきっかけは、仕事中にClaudeのサブスクリプション上限に達してしまうことです。計算は成り立ちます。私たちの2タスクのプローブは、DeepSeek V4 Flashで$0.00066かかりました。1日にそのような呼び出しを数百回行っても、まだ1ドル未満に収まります。
切り替えは、以前ほど面倒ではなくなっています。DeepSeek は Anthropic 互換のエンドポイント(api.deepseek.com/anthropic)を公開しているため、Claude Code は環境変数を変更するだけで利用できます。同じ設定は GLM-5.2 にも使えます。さらに、難しい問題には Claude を使い、定型作業はオープンモデルに振り分けたい場合でも、AIReiter のようなプラットフォームなら、同じ Anthropic 互換インターフェースを通じて Claude を定価の 20% で利用できます。
Kimi K3: 注目すべき存在
Moonshotは2026年7月16日にKimi K3をリリースし、frontend作業ではすでに最強のクローズドモデルを上回っています。Frontend Code leaderboardで1,679を記録し、Claude Fable 5の1,631を上回って第1位となっており、初期のハンズオン報告も同じ方向を示しています。
ここでランキングされていないのには1つ理由があります。weightsは7月27日に公開されます。それまでは、$3/$15で利用できるクローズドAPIです。公開されれば、K3はこれまでにリリースされた中で最大のopen-weight modelとなり、上のfrontendの数値を見る限り、この一覧の上位を争うことになりそうです。K3 open-weights releaseについては別途追跡しています。
選び方
1. どこで実行するのか? 16GB VRAM未満: APIを使用する(Gemma 4 12Bはローカルで動作するが、実際の品質低下を覚悟すること)。24GB: Qwen3.6-27B。H100 1台: Gemma 4 31B。API: 不十分だと証明されるまでは DeepSeek V4 Flash。2. どのような作業か? 迅速な編集には簡潔なモデルが向く: Kimi K2.7 Code または DeepSeek。難しい問題や長時間のエージェント実行には、十分なトークン予算を前提に GLM-5.2(予算重視なら MiniMax M3 も) が向く。3. ライセンス制約は? MIT(GLM, DeepSeek)と Apache 2.0(Qwen, Gemma)には制約はない。Kimi の修正版 MIT には、非常に大規模な商用利用のときだけ適用される帰属表示ルールが追加されている。
よくある質問
2026年にコーディングに最適なオープンソースLLMは何ですか?
GLM-5.2は最も高い上限を持ち、難しい問題ではClaude Sonnet級の出力に迫りますが、その代償として速度は犠牲になります。Kimi K2.7 CodeはAPIエージェント向けのトークン効率で勝ち、Qwen3.6-27Bはローカルハードウェア向け、DeepSeek V4 Flashはコスト面で優れています。
これらのモデルをローカルで無料で実行できますか?
重みは無料ですが、ハードウェアはそうではありません。27Bモデルには24GBのGPUが必要で、Gemma 4 31Bは80GBを必要とし、1兆パラメータ級のフラッグシップはAPIまたはクラスター専用です。
オープンソースとオープンウェイトの違いは何ですか?
Open-weight とは、自由に利用できる重みを持ちながら、学習データとコードは非公開であることを意味し、ここにあるほぼすべてのモデルがこれに当てはまります。完全なオープンソースモデル(OpenCoder、StarCoder2、IBM Granite Code)はすべてを公開していますが、性能面では後れを取っています。
コーディングにおいて Claude と同等に優れたオープンソースの LLM はありますか?
アルゴリズムベンチマークでは、はい:DeepSeek V4 Proの93.5%のLiveCodeBenchは、公表されているクローズドモデルのスコアを上回ります。リポジトリレベルの修正では、Claudeが依然としてリードしています(95.5% 対 約80%のSWE-Bench Verified)。私たちのテストでは、オープンモデルは正確性でClaudeに匹敵しましたが、使用トークン数は4〜13倍多くなりました。
C++ やニッチな言語に最適なオープンソース LLM はどれですか?
KimiのK2シリーズは、ニッチ言語における評価が最も高いです(Moonshotは特にZigを挙げています)。C++については、コミュニティの見解ではDeepSeek V4 ProとQwen3 Coder Nextが有力です。どれを選ぶにしても、必ず自分のコードベースでテストしてください。ニッチ言語の品質は、Pythonのベンチマークが示す以上に大きく変動します。
