MoEとは？Mixture of Expertsの仕組みをわかりやすく解説

2026年7月31日

MoE・混合エキスパート（受付が入力を見て、複数の専門家のうち一部だけに処理を振り分ける仕組み）

この記事でわかること

生成AIの新しいモデルが発表されるたび、「MoEを採用」「Mixture of Experts構造」といった言葉が技術記事に並びます。経営者や導入担当者の立場では、この種の内部構造の話は読み飛ばしても実務に支障はありません。

ただ、MoEについては一つだけ知っておく価値があります。大規模なモデルで、一回あたりの計算量を抑えるために使われる代表的な考え方の一つだからです。なお、生成AIの提供価格がどう決まるかは、設備・実装・運用方針など他の要因と合わせて決まるもので、MoEの採用だけで説明できるものではありません。

この記事では、MoEとは何かを、数式やコードを使わずに整理します。エンジニア向けの実装解説ではなく、「経営者として、モデルの内部構造をどこまで知っておけばよいか」という目線でまとめました。

この記事で扱う主な内容は、次のとおりです。

MoE（Mixture of Experts）とは何か
MoEの仕組み（ルーターとエキスパート）
従来のモデル構造との違い
MoEのメリットと課題
経営者として、どこまで知っておけばよいか

そもそも大規模言語モデルという言葉があいまいな場合は、LLMとはを先に読むと、この記事の内容がつかみやすくなります。

MoE（Mixture of Experts）とは

MoEとは、Mixture of Experts（混合エキスパート、専門家の混合）の略で、一つの大きなモデルの内部を複数の専門家（エキスパート）に分け、入力に応じてその一部だけを動かすという設計の考え方です。

従来のDense型では、入力ごとに基本的に同じ密な層・パラメータ群を使って処理します。MoEでは、入力の内容に合った一部のエキスパートだけを選んで動かします。

この設計の狙いは、モデル全体の規模を大きくしながら、一回の処理で実際に動く部分は小さく保つことにあります。知識の総量を増やしつつ、一回あたりの計算量を抑えるための工夫だと考えると、位置づけが分かりやすくなります。

なお、MoEという考え方自体は生成AI以前から研究されてきたもので、近年、大規模言語モデルの規模拡大にともなって、あらためて注目されるようになりました。

MoEとはわかりやすく（総合病院の受付が専門医へ振り分ける）

もう少しイメージしやすく説明します。MoEは、総合病院の受付にたとえると分かりやすいです。

総合病院には、内科・外科・皮膚科・眼科と、多くの専門医が在籍しています。患者が訪れると、受付が症状を聞いて、適した診療科へ案内します。

このとき、すべての専門医が全員で一人の患者を診るわけではありません。担当する医師だけが対応し、他の医師は別の患者を診ています。病院全体としては幅広い症状に対応できる一方、一人の患者にかかる人手は限られている。この構図がMoEに当たります。

対して、従来型のモデルは、すべての医師が全員で毎回すべての患者を診るような状態です。確実ではありますが、規模を大きくするほど負担が増えていきます。

用語に置き換えると、専門医がエキスパート、受付がルーター（ゲート）にあたります。ルーターが入力の内容を見て、どのエキスパートに処理させるかを決めます。

ただし、たとえで表せない部分もあります。MoEのエキスパートは「内科」「外科」のように人間が意味づけした専門分野に分かれているわけではありません。学習の過程で自動的に役割が分かれていくもので、それぞれが何を担当しているかを人が明確に説明できるとは限りません。

MoEの仕組み

MoEは、大きく二つの部品でできています。

エキスパートは、それぞれが計算を担当する部分ネットワークです。数個から数十個、モデルによってはそれ以上が用意されます。

ルーター（ゲート）は、入力を見て、どのエキスパートに処理させるかを決める部分です。多くの場合、上位いくつかのエキスパートだけを選びます。

処理の流れは次のようになります。

入力が入ってくる
ルーターが、その入力に適したエキスパートを選ぶ
選ばれたエキスパートだけが計算する
その結果をまとめて、出力とする

このように、用意されている部品のうち一部だけが実際に動く点が、MoEの特徴です。この性質は、専門用語ではスパース（疎）な活性化と呼ばれます。

なお、大規模言語モデルでMoEが使われる場合、モデル全体をエキスパートに分けるのではなく、内部の特定の層を置き換える形で組み込まれるのが一般的です。基盤となる構造そのものはTransformerとはで整理しています。

従来のモデル（Denseモデル）との違い

MoEと対比されるのが、Denseモデル（高密度モデル）と呼ばれる従来型の構造です。

	Denseモデル	MoEモデル
処理のしかた	各入力の処理で、基本的に同じ密な層・パラメータ群を使う	入力ごとに、一部のエキスパートだけを動かす
パラメータ	各入力で基本的に同じ密なパラメータ群を使う	全体は大きいが、一回で使うのは一部
設計の狙い	構造が単純で扱いやすい	規模を大きくしつつ、一回あたりの計算量を抑える
主な課題	規模拡大にともない計算量が増える	学習の安定性、メモリ、負荷の偏り

※ どちらが優れているという関係ではありません。用途・規模・運用環境によって選ばれ方が変わります。

ここで混同されやすい点を一つ補足します。MoEは「モデルが小さい」わけではありません。全体としては大きく、一回の処理で動く部分が小さいという構造です。活性化するパラメータが少なくても、モデル全体の重みを保存・配置する必要があるため、計算量と同じ比率でメモリ要件が下がるとは限りません。実際の必要量は、分散やオフロードといった実装のしかたによって変わります。

MoEのメリット

MoEが採用される理由は、主に次の点にあります。

規模を拡大しやすい：エキスパートを増やせばモデル全体の容量を増やせますが、一回で動かす数は変えずに済みます。
計算効率を高められる可能性がある：一回あたりの計算量を抑えられるため、同じ計算資源でより大きなモデルを扱える場合があります。
役割分担が生まれる：学習の過程で、エキスパートごとに得意な入力の傾向が分かれていきます。

ここで注意が必要なのは、「一部しか動かさない」ことと「常に速く安い」ことは別だという点です。

実際の処理速度や費用は、ルーターの判断にかかる時間、複数の計算機にまたがる場合の通信、まとめて処理する量、メモリの使い方、動かすハードウェア、実装のしかたによって変わります。仕組みとしては計算量を抑えられる設計ですが、それが速度や料金にどう表れるかは、動かす条件によって差が出ます。

MoEの課題

MoEには、設計上の難しさもあります。

一つ目は、学習の安定性です。どのエキスパートに割り振るかをルーターも同時に学習していくため、学習が不安定になりやすいことが知られています。

二つ目は、メモリの使用量です。先に触れたとおり、一回で動くのが一部でも、モデル全体の重みは保存・配置しておく必要があります。設備要件が計算量と同じ比率で下がるとは限らず、実際の必要量は分散やオフロードなどの実装によって変わります。

三つ目は、負荷の偏りです。ルーターが特定のエキスパートばかり選ぶようになると、他のエキスパートが十分に学習されず、設計の狙いが崩れます。これを避けるための工夫が併せて行われます。

こうした難しさがあるため、MoEを採用するかどうかは、モデルを設計・構築する側の判断になります。生成AIサービスを使う立場で、画面から切り替えられるものではありません。

なぜ今MoEが注目されているのか

MoEが話題になっている背景には、大規模言語モデルの規模拡大が抱える壁があります。

モデルを大きくすれば性能が上がりやすいことは経験的に知られてきました。しかし、Denseモデルのまま規模を大きくすると、一般に学習時・推論時の計算資源も増えます。これは設備費や運用費、応答速度に影響する要因の一つですが、提供料金や実際の速度は、ハードウェア、実装、稼働率、事業者の価格方針などによっても変わります。

MoEは、この関係を緩めるための設計です。全体の規模を大きくしても、一回あたりに動く部分を抑えられれば、計算資源の増え方を抑えられる可能性があります。

研究として公開されている例では、GoogleのSwitch Transformerが、Transformer内部の層をスパースなエキスパート層に置き換え、入力の単位ごとに選ばれたエキスパートへ振り分ける仕組みを論文で示しています。また近年は、複数の企業が自社モデルにMoE構造を採用したことを公表しています。ただし、どのモデルがどの構成を採っているかは、公表されている範囲にとどまり、詳細が明かされていないものもあります。特定のモデルの内部構造について断定的に語られている情報は、出所を確かめて受け取るのが安全です。

経営者として、どこまで知っておけばよいか

結論から言えば、生成AIサービスを使う立場では画面から選べる項目ではないため、詳細を理解する必要はありません。それでも、次の五点を押さえておくと、技術者やベンダーとの話が噛み合うようになります。

第一に、これはモデルの内部構造の話であり、生成AIサービスの画面から設定できるものではないということ（自社運用やモデル開発では、採用するかどうかが技術側の検討項目になります）。「MoE対応のAIを導入しましょう」という提案があれば、何を指しているのかを確認したほうがよい領域です。

第二に、MoEは規模と計算量の関係を緩める工夫であって、性能を直接保証するものではないということ。構造だけでモデルの良し悪しは決まりません。

第三に、実際の速度や料金は動かす条件で変わるということ。「MoEだから速い・安い」という説明を受けたら、どの条件での話かを確かめます。

第四に、自社で動かす場合はメモリ要件を確認すること。一回で動く部分が小さくても、モデル全体の重みは保存・配置する必要があり、計算量と同じ比率でメモリが減るとは限りません。この論点はLLMの量子化とはと併せて検討する領域です。

第五に、判断材料は構造ではなく、実際の業務での試用結果に置くこと。自社の実データで試し、応答の質・速度・費用を確かめるほうが、内部構造の比較より確実です。

モデルの内部構造を、経営者へどこまで説明するか——私の線引き

AI導入の相談をしていると、経営者から「生成AIは、内部でどのように考えているのですか」と聞かれることがあります。

ニューラルネットワークやTransformer、パラメータの話を詳しくすることはできます。しかし私は、最初から技術講義を始めません。

先に確認するのは、何を判断するために仕組みを知りたいのかです。AIの回答をどこまで信用してよいか。外注先の説明が妥当か。業務を任せてよい範囲はどこか。目的によって、必要な説明の深さは変わるからです。

最初に伝えるのは、数式ではなく、この一文です。

「生成AIは、人間と同じ意味で内容を理解して答えているというより、与えられた文章の流れから、次に続く可能性の高い言葉を選びながら回答を作っています」

これだけでも、経営上重要な性質が見えてきます。自然で説得力のある文章でも、間違うことがある。分からないことを推測で補う場合がある。指示と与えた資料によって、結果が変わる。

だから、AIは最終判断者にはなれず、重要な事実は人間が確認する必要がある。経営者に最初に必要なのはこの実務上の性質であって、内部構造の詳細ではありません。

モデル比較の場面では、「パラメータ数が多い」「最新モデルを採用」という説明を受けることもあります。パラメータ数が多ければ自社の業務で優れている、とは限りません。

そこで私は、その種の説明を聞いた後、必ず業務テストへ戻します。自社の実際の資料と質問で、どんな結果になるか。この記事の結論と同じです。

そのうえで、説明の深さを三段階で線引きしています。

第一段階は、経営判断に必要な基本。AIは続きを予測して答える、自然でも誤る、人間の確認と責任が要る——ここまでは、すべての経営者に必要です。

第二段階は、導入設計に必要な理解。モデル・指示文・参照データは別の要素であること。社内資料を参照させることと、モデルを再学習させることは違うこと。ここを押さえると、外注先との話が噛み合うようになります。

第三段階は、開発・調達に必要な専門知識。この記事で扱ったMoEのような内部構造の詳細は、ここに属します。自社開発や大きな投資判断、仕様協議の段階で初めて深く踏み込めば十分で、全員に必要なものではありません。

技術に詳しい支援者ほど、正確に説明しようとして話が複雑になりがちです。しかし、詳しく説明した結果、経営者が「難しいので専門家へ任せます」と判断を手放しては意味がありません。

かといって、「AIは人間のように考えている」と単純化しすぎれば、今度は誤った期待を生みます。

私は経営者へ、最後にこう伝えています。

「エンジンを設計できなくても、車は選べます。ただし、ブレーキの限界や燃料、運転者の責任を知らずに使うことはできません。AIも同じです」

内部構造の説明は、技術力を見せるためのものではなく、経営者が過信せず、過度に恐れず、AIを自社の業務へ正しく配置するために行うもの。その判断に必要なところまで説明し、それ以上の詳細は、必要になった段階で深める。この線引きが重要だと考えています。

MoEについてよくある質問

MoEとは何ですか？

Mixture of Experts（混合エキスパート）の略で、モデルの内部を複数のエキスパートに分け、入力に応じて一部だけを動かす設計の考え方です。モデル全体の規模を大きくしながら、一回の処理で動く部分を小さく保つことを狙っています。

MoEを使うとAIは速くなりますか？

仕組みとしては一回あたりの計算量を抑えられる設計ですが、実際の速度は、ルーターの処理、通信、まとめて処理する量、メモリ、ハードウェア、実装によって変わります。構造だけで速度が決まるわけではありません。

MoEのモデルは軽いのですか？

一回の処理で動く部分は小さくなりますが、モデル全体の重みは保存・配置する必要があるため、計算量と同じ比率でメモリ要件が下がるとは限りません。実際の必要量は分散やオフロードなどの実装で変わります。「動く部分が小さい」ことと「モデルが小さい」ことは別だ、と押さえておくのが安全です。

エキスパートはそれぞれ何の専門ですか？

人間が「内科」「外科」のように意味づけして分けているわけではありません。学習の過程で自動的に役割が分かれていくもので、それぞれが何を担当しているかを人が明確に説明できるとは限りません。

利用者側でMoEを設定できますか？

一般の生成AIサービス利用者が、画面上でMoEを有効・無効にすることは通常できません。一方、自社運用やモデル開発では、MoEモデルを選ぶことも、構成を検討することも技術側の検討項目になります。

この記事を書いた人

西俊明（トシゾー）中小企業診断士／AI実践戦略士／IT講師・著者

中小企業診断士／AI実践戦略士（商標出願中）／IT講師・著者。富士通で17年間、IT製品の営業・マーケティングに従事した後、独立。中小企業を中心に270社超を支援し、研修・セミナーへの登壇は250回を超える。現在は、生成AI・ITを経営や業務に生かす実践的な方法と、ITパスポート、情報セキュリティマネジメント、基本情報技術者試験などの学習法・過去問解説を発信している。著書に『改訂7版 ITパスポート最速合格術』など。