2026年8月、Qwenが公開した Qwen3.8-27B は、ローカルLLMを追っている人にとってかなり衝撃的なモデルでした。

パラメータ数は27B。270億です。

決して小さなモデルではありませんが、最先端AIの世界では「コンパクトな側」に入ります。

ところがQwen公式のベンチマークを見ると、とんでもない数字が並んでいます。

Benchmark	Qwen3.8-27B	Opus 4.6 Max
SWE-bench Pro	61.7	53.4
CoWorkBench	70.7	68.2
GPQA Diamond	89.2	91.3
LiveCodeBench v6	90.3	88.8
OSWorld-Verified	84.3	72.7

もちろん、すべてのベンチマークで勝っているわけではありません。

Terminal Bench 2.1では73.0対78.2、GPQA Diamondでは89.2対91.3でOpus 4.6 Maxが上です。

それでも驚くべきなのは、

27Bのオープンウェイトモデルが、最新のフロンティアモデルと同じ表の中で普通に勝ったり負けたりしている

ことです。

1年前なら、かなり考えにくかった光景です。

では、なぜこんなことが起きるのでしょうか。

「最近の27Bは昔の400Bと同じくらい賢くなったから」と考えると、本質を見誤ります。

現在のLLMの性能は、

パラメータ数だけでは決まらない

からです。

より正確には、

学習に使った計算量 × データの質 × 学習方法 × アーキテクチャ × ポストトレーニング × 推論時の計算量 × エージェント環境

まで含めたシステム全体で性能が決まります。

27Bが巨大モデルへ追いついている理由を順番に見ていきます。

---

まず「27B」という数字が表しているものを考える

LLMの「27B」は、だいたい270億個のパラメータを持っているという意味です。

昔はこの数字が、そのままモデル性能の分かりやすい目安になっていました。

7Bより70B。

70Bより175B。

175Bより500B。

モデルを大きくすれば性能が上がる、というスケーリング則が実際に観測されていたからです。

ただし、ここには重要な条件があります。

学習方法や学習量が同程度なら、大きいモデルが有利

という話です。

世代の違うモデルをパラメータ数だけで比較することはできません。

たとえば2022年にDeepMindが発表したChinchillaは70Bでした。

その前のGopherは280B。

モデルサイズだけなら4倍違います。

それでもChinchillaは、Gopherとほぼ同じ学習計算量を使いながら、モデルを小さくして、その代わり大量のデータを学習させることで、ほぼすべての評価でGopherを上回りました。

Chinchillaは70Bで1.3兆トークンを学習しています。

ここでLLM開発における重要な考え方が広まりました。

計算資源を全部モデルサイズに使えばいいわけではない。

小さめのモデルを、もっと長く、もっと大量のデータで学習させたほうが強くなる領域があります。

27B級が強くなっている第一の理由はここです。

---

「何Bか」より「その27Bにどれだけ詰め込んだか」

27Bモデルを作る場合、400Bモデルより1回の学習処理が軽くなります。

そこで余った計算資源を、

• 学習トークン数を増やす
• コードデータを増やす
• 数学データを増やす
• 高品質な問題を増やす
• 重複や低品質データを除去する
• 長文データを学習させる
• ポストトレーニングを強化する

といった方向に投入できます。

イメージとしては、

400Bの脳を一度ざっと勉強させる

代わりに、

27Bの脳へ重要な問題を何度も徹底的に勉強させる

という選択肢が取れるわけです。

もちろん実際の学習はこんな単純ではありません。

ただ、モデルサイズだけを見ると、この「どれだけ学習させたか」が完全に抜け落ちます。

同じ27Bでも、2023年の27Bと2026年の27Bでは中身がまったく違います。

---

AIがAIのための教材を作れるようになった

さらに大きいのが、学習データの作り方そのものが変わったことです。

初期のLLMでは、インターネットから大量の文章を収集し、それを学習する方法が中心でした。

現在は強いAIを使って、

• 数学問題を生成する
• コード問題を生成する
• 模範解答を作る
• 推論過程を作る
• 悪い回答を判定する
• 難しい問題だけ抽出する
• 解けなかった問題を作り直す

といったことができます。

つまり、

AI自身がAI用の教材を大量生産できるようになっています。

これは小型モデルにとって非常に大きな意味があります。

巨大モデルが持っている能力の一部を、小さいモデルへ移すことができるからです。

この考え方は一般に「蒸留」と呼ばれます。

Google Researchが2023年に発表した「Distilling Step-by-Step」では、巨大モデルの答えだけでなく、その理由や推論も教師データとして利用しています。

その結果、特定のタスクでは 770MのT5が540BのPaLMを上回る結果が報告されました。

約700倍のサイズ差です。

もちろん、これは汎用知能全体で770MがPaLMを超えたという意味ではありません。

特定の能力に必要な情報を、小さいモデルへ効率よく圧縮できることを示しています。

そして現在のLLM開発では、この「高品質な教師信号を作る」という技術がはるかに高度になっています。

---

27Bには「全部知っている」必要がない

ここでかなり重要な変化があります。

昔のLLMでは、

モデル内部にどれだけ知識や能力を詰め込めるか

が重要でした。

現在のエージェント型AIでは、必ずしもそうではありません。

モデルは必要になったら、

• ファイルを読む
• コードを検索する
• Webを検索する
• ターミナルを操作する
• Pythonを実行する
• テストを走らせる
• エラーを見る
• もう一度修正する

ことができます。

つまり、

知識を全部暗記しておく重要性が下がっています。

人間でも同じです。

何も見ずにプログラムを書く試験なら、記憶力が非常に重要です。

しかし、

PC使用可 ソースコード閲覧可 ドキュメント閲覧可 テスト実行可 何度修正してもいい

という試験になれば、重要なのは別の能力になります。

何を調べるか。

どのファイルを見るか。

エラーから何を推測するか。

次に何を試すか。

つまり問題解決のループを正しく回す能力です。

27Bでもこの能力を重点的に鍛えれば、巨大モデルとの差をかなり縮められます。

---

Qwen3.8-27Bがまさにそれを示している

Qwen3.8-27Bの公式説明では、特に改善された能力として、

• Coding
• Professional work
• Research
• Long-horizon agentic tasks
• Autonomous planning
• Environment feedbackへの対応

などが挙げられています。

つまり単純な「次の単語を当てる能力」だけを強化しているわけではありません。

AIエージェントとして仕事を完遂する能力を重点的に鍛えています。

これがベンチマークにもかなり露骨に表れています。

Qwen3.6-27BからQwen3.8-27Bへの変化を見ると、

Benchmark	Qwen3.6-27B	Qwen3.8-27B
Terminal Bench 2.1	63.4	73.0
SWE-bench Pro	53.5	61.7
DeepSWE 1.1	13.3	42.2
QwenSWEBench	49.3	79.0
CoWorkBench	61.0	70.7
OSWorld-Verified	63.9	84.3

同じ27Bクラスなのに、DeepSWEでは13.3から42.2まで伸びています。

パラメータ数を増やさなくても、能力はこれだけ変わります。

この事実だけでも、

「何Bか」だけでモデル性能を予測することが難しくなった

ことが分かります。

---

さらに現在のAIは「回答する前に計算する」

もう一つ、昔のLLMとの大きな違いがあります。

推論モデルです。

以前のLLMは、質問を与えると比較的すぐ回答を生成していました。

現在のモデルは、難しい問題ならその前に大量の推論を行います。

Qwen3.8-27Bもthinking modeが標準で有効になっています。

さらに公式実装では、

• xhigh
• medium
• low

という reasoning_effort が用意されています。

標準はxhighです。

つまりモデルサイズが27Bでも、

回答時に追加の計算資源を投入できます。

これが「test-time compute」「inference-time scaling」などと呼ばれる考え方です。

モデルそのものを巨大化する代わりに、

この問題だけ、もっと長く考えさせる

わけです。

---

小さいモデルを長く考えさせると、大きいモデルを超えることがある

これは理論だけではありません。

ICLR 2025で発表された研究では、推論時の計算量を問題ごとに適切に割り当てることで、特定条件下では小さいモデルが14倍大きいモデルを上回ることが報告されています。

ここから非常に面白い構図が生まれます。

以前は、

難しい問題
    ↓
もっと巨大なモデルを使う

でした。

現在は、

難しい問題
    ↓
同じモデルをもっと長く考えさせる

という選択肢があります。

これはLLMの経済性を大きく変えます。

毎回400Bを動かす代わりに、普段は27Bを動かし、難しい問題だけ推論量を増やせばいいからです。

---

そして、ここが一番重要。「ベンチマークスコア」はモデル単体の点数ではなくなっている

Qwen3.8-27Bの数字を見るとき、絶対に見落としてはいけないポイントがあります。

たとえばSWE-bench Pro。

Qwen3.8-27Bは 61.7。

Opus 4.6 Maxは 53.4。

数字だけ見ると、

27BのQwenがOpusよりコーディング能力で上

と思ってしまいます。

しかし、そこまで単純ではありません。

Qwen公式の注記を見ると、Qwen3.8-27Bなどのモデルは Claude Code harness 上で評価されています。

コンテキスト長は256K。

つまりモデルへ問題文を渡して一発でコードを書かせているわけではありません。

エージェントとしてリポジトリを調べ、ツールを利用しながら問題を解かせています。

しかもOpus 4.6 Maxについては、この項目だけ公式報告スコアが掲載されています。

つまり完全に同一条件の直接対決ですらありません。

ここはかなり重要です。

現在のエージェント系ベンチマークで測っているものは、

モデル
+
長いコンテキスト
+
推論
+
ツール
+
エージェントハーネス
+
試行時間

です。

「素の27Bモデルの知能指数」を測っているわけではありません。

---

でも、それはズルではない

「じゃあツールを使っているからベンチマークは意味がないのでは？」

と思うかもしれません。

そうではありません。

実際にAIを仕事で使うときも、モデル単体で使うことは減っているからです。

コーディングAIなら、

• IDE
• Git
• Shell
• ファイル検索
• テスト
• コンパイラ

を使います。

リサーチAIなら、

• Web検索
• ブラウザ
• PDF
• Python
• データベース

を使います。

つまりユーザーが欲しいのは、

「何も持たせなかった状態で一番賢いAI」ではなく、「仕事を一番うまく終わらせるAI」

です。

そう考えると、モデルサイズの重要性はさらに下がります。

---

27Bでも「考える → 試す → 修正する」を何度も回せる

たとえばコード修正を考えてみます。

一発回答型なら、

Issueを読む
↓
コードを書く
↓
終了

です。

エージェント型なら、

Issueを読む
↓
関連ファイルを検索
↓
コードを読む
↓
原因を推測
↓
修正
↓
テスト
↓
失敗
↓
エラーログを読む
↓
仮説を修正
↓
再修正
↓
テスト
↓
成功

となります。

最初の推論能力で多少負けていても、

フィードバックループを正しく回せれば最終正答率はかなり上げられます。

Qwen3.8が公式説明で「environment feedbackへの対応」を強調している理由もここにあります。

エージェント時代の性能は、

最初の一手がどれだけ賢いか

だけでは決まりません。

途中で間違えても最後まで戻ってこられるか

が重要になります。

---

アーキテクチャも昔の27Bとは違う

当然、モデル内部の設計自体も進化しています。

Qwen3.8-27Bは64層、27BパラメータのDenseモデルです。

ただし内部は通常のAttentionだけではありません。

公式モデルカードによると、

Gated DeltaNetとGated Attentionを組み合わせたハイブリッド構造

を採用しています。

さらに、

MTP（Multi-Token Prediction）

も複数ステップで学習されています。

ネイティブコンテキスト長は262,144トークン。

最大100万トークンまで拡張可能です。

画像や動画もネイティブで扱えるVision-Languageモデルです。

同じ27Bという数字でも、

内部で27Bをどう使うか

は世代ごとに変わっています。

---

Qwen3.8-27Bの本当の衝撃

ここまで考えると、Qwen3.8-27Bの何が衝撃的なのかが見えてきます。

「27BがOpusに勝った」という一行だけではありません。

もっと重要なのは、

フロンティアモデル級のスコアが27Bというサイズ帯まで降りてきた

ことです。

27Bなら量子化によって、コンシューマー向けの高メモリGPUやApple Siliconなどでも現実的なローカル運用圏に入ってきます。

クラウド上でも、大型モデルよりはるかに大量のインスタンスを動かしやすくなります。

そしてAIエージェントでは、この違いが非常に大きくなります。

たとえば1つの巨大モデルを動かすコストで、

Agent A：コードを書く
Agent B：コードレビュー
Agent C：テスト
Agent D：仕様チェック
Agent E：セキュリティチェック

という複数エージェント構成を取れる可能性があります。

モデル単体で数ポイント高いことより、

十分に強いモデルを大量に動かせること

のほうがシステム全体では強いケースが出てきます。

---

「巨大モデル1個」対「27Bを何回も使う」という競争になる

ここから先は、LLMの競争そのものが少し変わっていきます。

今までは、

どこまで巨大なモデルを作れるか

という競争でした。

これからは、

一定の計算予算をどう配分すれば最も高い成果が出るか

という競争が強くなります。

たとえば同じ計算予算があったとします。

選択肢A。

400Bモデル
×
1回の推論

選択肢B。

27Bモデル
×
長い思考
×
検索
×
ツール
×
再試行
×
検証

問題によってはBが勝ちます。

さらに、

27Bモデルを5体動かす
↓
5種類の解答を作る
↓
別のモデルに検証させる
↓
最も良い解答を採用

という使い方もできます。

この瞬間、比較対象はもう「27B対400B」ではありません。

AIシステム対AIシステム

になります。

---

だから「27Bなのに最新モデル並み」は本当でもあり、誤解も生みやすい

Qwen3.8-27Bのベンチマーク結果を見て、

「27Bで最先端モデルと戦える時代になった」

と言うのはかなり妥当です。

一方、

「27Bモデルがフロンティアモデルと完全に同じ知能を獲得した」

と考えるのは行き過ぎです。

ベンチマークは能力の一部分しか測りません。

推論量も違います。

ハーネスも違います。

ツールも使います。

評価条件も完全には統一されていない場合があります。

そして難しい未知問題では、依然として大きなモデルの容量が効く可能性があります。

それでも、

小さいモデルが巨大モデルへ追いつける領域が急速に広がっている

こと自体は間違いありません。

---

モデルを見るとき「何B？」だけ聞くのはもう足りない

これからLLMを比較するときは、少なくとも次のように考える必要があります。

モデルサイズ
     ↓
事前学習の質と量
     ↓
ポストトレーニング
     ↓
アーキテクチャ
     ↓
推論時の計算量
     ↓
コンテキスト
     ↓
ツール
     ↓
エージェント設計
     ↓
最終的なタスク成功率

パラメータ数は、一番上にある一要素にすぎません。

27Bという数字を見て、

27Bだからこの程度だろう

と予測できた時代は終わりつつあります。

Qwen3.8-27Bは、その変化を非常に分かりやすい形で見せました。

27BのDenseモデルが、SWE-bench Proで61.7。

CoWorkBenchで70.7。

LiveCodeBench v6で90.3。

OSWorld-Verifiedで84.3。

一部では最新の巨大な商用モデルを上回っています。

これは「パラメータ数が意味を失った」という話ではありません。

AIの性能を作る方法が、モデルを巨大化するだけではなくなった

という話です。

大量の良質な学習。

強力なポストトレーニング。

高効率なアーキテクチャ。

推論時の追加計算。

長大なコンテキスト。

ツール。

フィードバック。

エージェント。

それらを組み合わせれば、27Bでもフロンティア級モデルのスコアへ手が届く。

そしてモデルが小さいぶん、その性能を安く、大量に、ローカルでも使える。

Qwen3.8-27Bの衝撃は、27Bが巨大モデルに勝ったことだけではありません。

「最先端級のAI性能には、超巨大モデルが必須」という前提そのものが崩れ始めたことです。

---

参考資料

1. Qwen, 「Qwen3.8-27B」公式モデルカード
2. Google DeepMind, 「An empirical analysis of compute-optimal large language model training」
3. Hsieh et al., 「Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizes」
4. Snell et al., 「Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Parameters for Reasoning」