MoE(Mixture of Experts)とは?仕組み・スパース活性化・採用モデルを図解【2026年版】
この記事でわかること
- MoE とは:モデル全体のうち入力ごとに「一部のエキスパートだけ」を使う設計。巨大なパラメータ数を持ちつつ推論コストを抑える
- 仕組み:通常の1つのフィードフォワード層を多数の「エキスパート」に分け、「ルーター」が token ごとに使うエキスパートを数個だけ選ぶ
- スパース活性化:総パラメータは巨大でも、1 token で実際に計算するのは一部だけ(例:DeepSeek-V3 は総671B中37Bのみ活性)
- メリット:計算量を増やさずに知識容量(パラメータ)を増やせる=同じ推論コストで賢くなれる
- 注意:活性パラメータは小さくても、VRAM には総パラメータ分のロードが必要。GPT-4・Llama 4・DeepSeek 等が採用
結論:MoE は「一部のエキスパートだけ使う」省コスト設計
MoE(Mixture of Experts/混合エキスパート) は、巨大なモデルの中から 入力ごとに必要な「エキスパート」だけを選んで使う アーキテクチャです。モデル全体では数千億〜兆パラメータを持ちながら、1 token の推論で実際に計算するのはその ごく一部 だけ。これにより、計算コストをほとんど増やさずに「知識容量=賢さの上限」を引き上げられます。
GPT-4・DeepSeek-V3・Mixtral・Llama 4 など、近年の高性能 LLM の多くがこの設計を採用しています。この記事では、ルーターとエキスパートの仕組み・スパース活性化・Dense モデルとの違い・実務での選び方を図解します。
仕組み:ルーター + エキスパート + top-k 選択
通常の Transformer では、各層の フィードフォワード(FFN)ブロックを毎回すべて計算 します。MoE はここを次のように置き換えます。
- 1つの FFN ブロックを、多数の「エキスパート」(小さな FFN) に分割する
- ルーター(router) が、各 token に対して使うエキスパートを 数個(top-k)だけ 選ぶ
- 選ばれたエキスパートの出力だけを重み付き合成して、次の層へ渡す
- 選ばれなかったエキスパートは、その token では 計算されない
つまり「token ごとに、その内容が得意なエキスパートにだけ仕事を振る」イメージです。ルーター自体も学習され、どの token をどのエキスパートに送るかを最適化します。
スパース活性化:総パラメータ ≫ 活性パラメータ
MoE の効果を一言で言うと スパース活性化(sparse activation) です。総パラメータは巨大でも、1 token で実際に動くのは一部だけ。代表的なモデルで見ると差は歴然です。
| モデル | 総パラメータ | 1 token の活性パラメータ | 構成 |
|---|---|---|---|
| DeepSeek-V3 | 約 671B | 約 37B | 多数エキスパート + 共有エキスパート |
| Mixtral 8x7B | 約 47B | 約 13B | 8エキスパート中 2つを使用 |
| (一般のDenseモデル) | N | N(全部) | 毎回すべて計算 |
DeepSeek-V3 は 671B の知識を蓄えつつ、推論コストは 37B 規模 で済みます。Mixtral 8x7B も、名前の「8x7B」は8つのエキスパートを意味し、総約47Bですが token あたり2つ(約13B)しか使いません。
なぜ MoE が主流になったのか
LLM の賢さは、おおまかにパラメータ数(知識容量)とともに伸びます。しかし Dense モデルでパラメータを増やすと、推論コストも比例して増えて しまいます。
MoE はここを切り離します。エキスパートを増やせば知識容量は増えるが、token あたりに使う数(top-k)を固定すれば計算量は増えない。「賢さを上げてもコストが比例しない」——この性質が、フロンティアモデルがこぞって MoE を採る理由です。
Dense: パラメータ↑ ⇒ 推論コスト↑(比例)
MoE: 総パラメータ↑(エキスパート追加) ⇒ 推論コストはほぼ一定(活性は固定)
Dense と MoE の違い・使い分け
| 観点 | Dense(従来型) | MoE |
|---|---|---|
| 推論コスト | パラメータに比例 | 活性パラメータ分だけ(安い) |
| 知識容量 | パラメータ数なり | 総パラメータで大きくできる |
| VRAM / メモリ | パラメータ分 | 総パラメータ分(重い) |
| 学習の難しさ | 素直 | ルーティングの負荷分散が難しい |
| 実装 | シンプル | エキスパート並列など工夫が要る |
クラウドの大規模モデルはほぼ MoE に移行済みです。一方、手元の GPU で動かすローカル実行 では、活性パラメータが小さくても 重み全体をメモリに載せる必要がある ため、VRAM 制約から Dense の小型モデルが現実的なこともあります。
よくある誤解
- 「活性パラメータが小さい=省メモリ」→ 誤り。VRAM は総パラメータ分が必要。活性が小さいのは“計算量”が小さいだけ。
- 「MoE は常に Dense より速い」→ 文脈次第。token あたりの計算は少ないが、ロード・通信・ルーティングのオーバーヘッドがある。
- 「エキスパートは分野(法律・医療など)で分かれている」→ 厳密には違う。ルーターは学習で割り当てを決め、人間が解釈できる分野分担になるとは限らない。
実務での選び方(チェックリスト)
- 賢さの上限 を見たいなら → 総パラメータ
- 応答の速さ・API コスト を見たいなら → 活性パラメータ
- ローカルで動かせるか → 総パラメータ(量子化込みサイズ)で VRAM を見積もる
- 同じ活性規模なら、MoE は知識容量で有利になりやすい
DeepSeek の最近の MoE は、補助損失なしの負荷分散・きめ細かいエキスパート分割・共有エキスパートなど、ルーティングを安定させる工夫が進んでいます。アーキテクチャ名だけでなく「総 / 活性」の2値で比較するのが実務的です。
まとめ
- MoE=入力ごとに一部のエキスパートだけ使う設計。総パラメータは巨大でも活性は一部
- ルーターが token ごとに top-k エキスパートを選ぶ=スパース活性化
- 例:DeepSeek-V3 671B総/37B活性、Mixtral 8x7B 47B総/13B活性
- 狙いは「賢さ(知識容量)を上げても推論コストを比例させない」こと
- 注意:VRAM は総パラメータ分が必要。Dense と用途で使い分ける
AIモデルの仕組みを実務に落とす:当サイトの「バイブコーディング実践編」では、こうしたモデル特性を踏まえて Claude Code などのツールを業務に組み込む手順を、提出物テンプレ + 採点ルーブリック付きの演習で扱います。4週間限定で無料公開中。
関連ガイド:
- コンテキストエンジニアリングとは — モデルに何を渡すかを設計する考え方
- AIエージェントとは・基礎 — LLM を「動くシステム」にする仕組み
- Ollama の使い方 — MoE モデルを手元で動かして試す
- MCPサーバーの作り方 — モデルに外部ツールをつなぐ
関連する AI 研修コース・事例
このガイドで解説した内容を、提出物・採点ルーブリック付きの実装演習で 実務レベルまで定着させるためのコースと、国内外の AI 活用事例を見るための入口です。
- バイブコーディング実践編 (vibe_practice)Claude Code を業務コードに使うときの安全設定・許可コマンド・ ログ管理を、提出物付き 40 レッスンで体系化。4 週間限定で無料公開中。
- AIエージェント活用実践編 (agent_practice)Claude Agent SDK と MCP で AI を働かせる実装演習。 Claude Code に慣れた次のステップ。
- サイバーセキュリティ基礎 (cybersec_basic)AI を業務に取り入れる際の社内ガードレール・情報統制と一緒に学ぶ 実務者向けセキュリティ 40 レッスン。
- AI 活用事例集KDDI・SAP・freee・メルカリ等、国内外の企業 AI 導入実例を業種別に確認。
- AI研修 コース一覧概論レーン (経営者向け) + 実践レーン (エンジニア向け) の全 6 コースを一覧。