0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

迂回路の地図 — MoE、推論時計算量、ツール、そして「SonnetとOpusどっち使う?」問題

0
Posted at

迂回路の地図 — MoE、推論時計算量、ツール、そして「SonnetとOpusどっち使う?」問題

はじめに

Part 1 では事前学習スケーリングの燃料切れとデータ枯渇を、Part 2 ではTransformerの理論的限界と「考えているフリ」問題を見ました。

状況をまとめると:モデルをデカくしても改善しにくくなった。データも尽きかけている。アーキテクチャ自体に数学的な壁がある。CoTは推論モデルにはほぼ無意味で、思考トレースは75%不誠実。

でもAIの進歩は止まっていない。FrontierMathは16ヶ月で2%から50%になった。ARC-AGI-2で84.6%が出ている。何が起きているのか。

答えは:業界はコアモデルを賢くするのを諦めて、周辺技術で迂回している。この記事では、その迂回路の中身と、実務で使う側が知っておくべきことを整理します。


迂回路 1: MoE — 計算しないパラメータを大量に持つ

Mixture of Experts(MoE)は、2024年以降のフロンティアモデルで急速に標準化した技術です。

仕組み

普通のモデル(denseモデル)は、すべてのパラメータをすべての推論で使う。MoEは総パラメータ数を大幅に増やしつつ、1回の推論で使うのは一部だけにする。

DeepSeek V3は671Bパラメータを持つが、1回の推論でアクティブなのは37Bだけ。結果、学習コストは560万ドル。671Bのdenseモデルを普通に学習したら桁違いにかかる。

限界

MoEはモデルが「何を学ぶか」は変えない。同じデータの同じ次トークン予測で学習する。使えるパラメータが増えるだけ。べき乗則のスケーリング関係もdenseモデルと同じ。

つまりコスト効率は劇的に改善するが、能力の天井は上がらない。同じ壁に、安く速くたどり着けるようになった。


迂回路 2: 推論時計算量 — 学習の代わりに考えさせる

事前学習スケーリングが壁に当たった時、業界が見つけた最大の迂回路。

14倍大きなモデルを上回る

Snell et al.のICLR 2025 oral論文は、推論時の計算量を最適に配分すれば、14倍大きなモデルを上回ることを実証した。学習時に知識を詰め込む代わりに、推論時に「もっと考えさせる」。

実際の成果は印象的:

  • o3がARC-AGIで87.5%(GPT-4oの5%から)
  • AIME 2024で96.7%
  • DeepSeek R1が約600万ドルの学習コストでo1に匹敵

でも「考えているフリ」の壁がある

Part 2で見た通り、Appleの研究は推論モデルが特定の複雑さを超えると完全に精度が崩壊することを示した。しかも問題が難しくなると、推論努力を逆に減らす。

Whartonの研究では、推論モデルにCoTプロンプトを追加しても2.9-3.1%の改善にしかならない

推論時計算量は強力な迂回路だが、コアモデルの限界を迂回しているのであって、解決しているのではない。ある論文の表現を借りると「根本的に補償的であり治療的ではない」。


迂回路 3: ツールとエージェント — できないことは外注する

ここが一番考えさせられる話です。

Claude Codeを使っていると、計算ツール、コード実行、ウェブ検索、ファイル読み書き、MCP経由の外部サービス接続——大量のツールが利用できる。これらの一つ一つが何を意味するか、考えてみてください。

  • 計算ツール: LLMが確実に計算できないから
  • コード実行環境: LLMがAPIをハルシネートするから
  • 検索: 知識が静的で不完全だから
  • メモリストア: コンテキストが有限だから
  • ファイル操作: 出力が一回きりで永続しないから

追加されるツールの一つ一つが、モデル自体では解決できなかった限界の暗黙の承認。「モデルが賢くなれば不要になる」と思っていた松葉杖が、むしろ標準装備になっている。

ある分析がうまい表現をしている:LLMは**「認知ハードウェア」——不可解なブラックボックス——として扱われ、スキャフォールディングが限界を補う「ソフトウェア」**を提供する、と。

これは悪いことではない。MoE+推論+ツール+RAGの組み合わせは、どの単一の改善より遥かに高能力なシステムを生んでいる。ただ「モデルが賢くなった」のとは本質的に違う。


代替アーキテクチャ: Transformerを置き換えるか

「迂回ではなく、道自体を作り替える」アプローチもある。

Mamba系: アテンションを捨てる

NVIDIAのNemotron-Hは64層中54層(約84%)をMamba2に置き換え、精度を維持しつつスループットを3倍にした。MicrosoftのPhi-4-mini-flashは最大10倍のスループットを達成している。

2026年3月にはMamba-31が発表され、パリティ/モジュラ演算——Transformerの弱点——を半分の状態サイズで解決。理論的にはTC⁰の壁の一部を迂回できる可能性がある。

JEPA: トークンではなく表現を予測する

Yann LeCunが2025年11月にMetaを離れてAMI Labs2(10.3億ドル調達、欧州史上最大のシードラウンド)を設立し推進しているアプローチ。

通常のLLMは次のトークン(単語の断片)を予測する。JEPAは抽象的な埋め込み空間で次の表現を予測する。ピクセルやトークンのような細部を予測しないので、「無関係な詳細」を無視できる。

LeCunの数学的批判は明快:トークン単位のエラー確率をeとすると、長さnのシーケンス全体が正しい確率は(1-e)^n。100トークンで各トークンのエラーが1%でも、全体が正しい確率は37%しかない。

JEPAの実装はまだ初期段階だが進展は速い。V-JEPA 2(2025年6月)は1.2Bパラメータで動画理解のSOTAを達成。VL-JEPA3(2025年12月)はGPT-4oとClaude 3.5 Sonnetを世界予測タスクで上回った。

でも、まだ勝っていない

2025年の包括的調査4は、ハイブリッドモデルもサブ二次モデルもLMSysリーダーボードのトップ10に入っていないことを報告している。計算量が問題にならない場合、フルアテンションTransformerがまだ勝つ。

代替アーキテクチャはコスト効率とスケーラビリティでは優位。でも品質の天井では追いついていない。LeCunの10.3億ドルの賭けは、これを変えるためのもの。


研究者は何を賭けているか

全員が同意していること

ウェブデータに対する純粋な事前学習は収穫逓減に達した。 AltmanもAmodeiもピボットを認めている。Amodeiですら「スケーリング」の定義を事後学習と推論に拡張した。

意見が分かれるところ

「Transformerを推論やツールで拡張すればAGIに届くか」vs「根本的に新しいアーキテクチャが必要か」。

Amodei(Anthropic CEO)5とHinton(「最後までニューラルネットワーク」)6は前者。LeCun(AMI Labs, 10.3億ドル)2とFei-Fei Li(Stanford教授、World Labs創設者、10億ドル)7は後者。Karpathy(元Tesla AI責任者、「業界がポテンシャルの10%未満しか活用していない」)8とHassabis(Google DeepMind CEO、「あと1-2のブレークスルー」)9は中間。松尾豊(東京大学教授)10は世界モデルを「自然言語の次のフェーズ」として、専門の研究講座を設立した。

合わせて数十億ドルが両側に賭けられている。


で、実務では何が変わるのか

ここまで理論と業界動向の話をしてきましたが、読んでいる人の多くは「じゃあ自分は明日から何を変えればいいのか」が一番の関心だと思います。

SonnetとOpusの差が体感しにくくなっている理由

2026年3月時点で、GPT-5.4、Claude Opus 4.5/4.6、Gemini 3.1 Proはほとんどの評価で2-3ポイント以内のスコア。SWE-bench Verifiedでは上位6モデルが1.3ポイント以内にひしめいている。

Simon Willisonは最上位のOpus 4.5からSonnet 4.5に戻しても「わずかな低下(little drop-off)」しかないと報告した11

これは体感と一致しませんか? Claude Codeで、Opusでないとダメな場面って実際どのくらいありますか。自分の経験では、Sonnetで十分な場面がかなり多い。

この収束は、Part 1で見たスケーリングの壁と直結している。コアモデルの知能差が小さくなっているから、体感差も小さくなる。

モデル選択より重要なこと

コアモデルの差が縮まっている一方で、周辺技術の差は広がっている。具体的には:

1. ツール統合の質

3桁の掛け算を59%しか正解できないモデルに、計算ツールを渡せば100%正解する。検索ツール、コード実行環境、MCP経由の外部サービス——使えるツールの質と組み合わせ方が、モデルの賢さより効く場面が増えている。

2. コンテキスト設計

同じモデルでも、CLAUDE.mdの設計、Hooksの構成、Skillsの有無で出力品質が大きく変わる。これは前のシリーズで書いた迎合対策とも関係する話。モデルが迎合するなら、迎合させない仕組みを作ればいい。

3. 構造分離

実装と検証を別コンテキストで実行する。サブエージェントに独立してレビューさせる。Agent Teamsでwriter/reviewerを分離する。モデルの賢さに頼るより、構造で品質を担保する方向。

4. 推論コストの判断

推論モデル(o3, o4-mini)は中程度の難易度のタスクで最も効果的。簡単な問題では過剰思考で遅くなり、難しすぎる問題では精度が崩壊する。タスクの難易度に応じてモデルとモードを切り替える判断が重要。

CPUクロックの教訓

これは半導体業界が2005年頃に経験したことと似ている。クロック速度のスケーリングが物理的限界に達して、マルチコアにピボットした。

クロック速度が上がらなくなった時、「CPUの進歩は止まった」と思った人もいたけど、実際にはコンピューティング能力は指数的に伸び続けた。ただし、その恩恵を受けるにはプログラムを並列化する必要があった。シングルスレッドのコードを書いていた人は、進歩の恩恵を受けられなかった。

AIも同じことが起きている可能性がある。「もっと賢いモデルを待つ」のではなく、今のモデルの使い方を並列化(ツール統合、構造分離、コンテキスト設計)する人が恩恵を受ける。


おわりに

この3部作の元になった調査はClaude Deep Researchに依頼したもので、ファクトチェックしたら28箇所の修正が必要でした。存在しない人物の発言を捏造、数値の微妙な盛り、単位の取り違え、正反対の主張をする論文を根拠として引用。

ちなみにこのこと自体が、記事のテーマと妙に一致している。モデルは「考えているフリ」をする(Part 2)。もっともらしい数字を出す。引用元を挙げる。でも中身を確認すると、微妙にズレている、あるいは完全に間違っている。

「モデルをデカくすれば賢くなる」は終わった。でもAIの進歩が止まったわけではない。業界は迂回路を見つけた。

問題は、この迂回路が本道に再接続するのか——それとも全く新しい道を作る必要があるのか。LeCunの10.3億ドルとAmodeiの「スケーリングは続く」が、その答えを賭けて競っている。

実務者として自分たちができるのは、モデルの賢さに依存するのをやめて、構造で品質を担保すること。モデルは道具で、道具の使い方の方が、道具自体の性能より効く時代に入っている。


参考文献

  1. Gu, Dao et al. "Mamba-3" (ICLR 2026, arXiv:2603.15569)

  2. Futurum Group "Yann LeCun's AMI Raises $1B Seed Round" (futurumgroup.com) 2

  3. VL-JEPA (arXiv:2512.10942)

  4. "The End of Transformers?" survey (arXiv:2510.05364)

  5. Fortune Davos 2026 (fortune.com)

  6. Hinton interview (business-powerhouse.com)

  7. decodingdiscontinuity "Premature Eulogy" (decodingdiscontinuity.com)

  8. Karpathy Year in Review 2025 (karpathy.bearblog.dev)

  9. Hassabis, Big Technology interview (bigtechnology.com)

  10. 松尾豊, 日経xTECH (xtech.nikkei.com)

  11. Simon Willison via bdtechtalks (bdtechtalks.substack.com)

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?