拡散言語モデル（dLLM）とは？仕組みや主要モデル、料金を徹底解説

拡散言語モデル（Diffusion Language Model、以下dLLM）は、キャンバス上のノイズ化された初期状態（マスクや代替プレースホルダー）を反復デノイジングで復元する新しいタイプの言語モデルです。LLaDA・ELYZA-LLM-Diffusionはマスクトークンから復元するマスク拡散型、DiffusionGemmaはUniform State Diffusionで256トークン単位のブロックを復元しつつブロック間は自己回帰的に接続する構成、Mercury 2は詳細アーキ非公表の並列リファイン型など、モデルごとに実装は異なります。

TransformerベースのGPT型モデルが1トークンずつ左から右へ生成するのに対し、dLLMは複数のトークンを同時に予測できる設計で、モデル・ハードウェア・生成設定によっては単一GPUで数百〜1,000トークン/秒級のスループットを狙えます。

2025年前半にはLLaDA（2025年2月）とMercury Coder（2025年2月）が公開され、その後Mercury（2026年2月にMercury 2として本格拡張）・ELYZA-LLM-Diffusion（2026年1月）・DiffusionGemma（2026年6月）が続きました。商用APIと研究・検証向けオープンモデルが登場し、併存する段階に入りつつあります。

本記事では、拡散言語モデルの仕組み・主要4モデルの比較・料金構造・自己回帰型LLMとの違い・企業がいま切り替えを検討すべき用途と判断軸を、2026年7月時点の公式一次情報をもとに整理します。

拡散言語モデル（dLLM）とは？──テキスト全体を並列復元する新世代アーキテクチャ

拡散言語モデル（Diffusion Language Model、略してdLLM）とは、画像生成で実績のある「拡散モデル」の枠組みをテキストに適用し、キャンバス上のノイズ化された初期状態（マスクや代替プレースホルダー）からの反復デノイジングで文章を生成する言語モデルです。

現在の主流であるGPTやClaudeなどの自己回帰型LLM（Autoregressive Language Model）が「1トークンずつ左から右に予測」するのに対し、dLLMは「ノイズ化・未確定のキャンバスを反復デノイジングで復元する」設計を取ります。

2026年2月にInception Labsが公開したMercury 2はNVIDIA Blackwell GPU上で1,009トークン/秒を記録し、同帯の速度最適化モデル（GPT-5 Mini・Claude 4.5 Haiku）の10倍以上のスループットを示しました（Inception Labs公表値）。

拡散言語モデルの現代的な役割

dLLMは、単に「速いLLM」ではなく、自己回帰型LLMのアーキテクチャ制約を解くための対抗提案として位置づけられます。

• Inception Labs（米）
  2025年2月のMercury Coder公開を起点に、2026年2月にMercury 2として商用APIへ本格拡張（Inception Labs）
  
  

• Google DeepMind
  2025年5月のGemini Diffusion実験公開に続き、2026年6月にオープンウェイトのDiffusionGemmaを投入
  
  

• GSAI-ML（中国人民大学＋Ant Group）・ELYZA（日）
  LLaDA・ELYZA-LLM-DiffusionをオープンウェイトでHugging Face上に公開

ここでのポイントは、リアルタイム音声応答・コード補完のように「1トークンあたりの遅延がユーザー体験を左右する」領域で、自己回帰型LLMの速度上限が書き換わり始めた、という点です。

Inception Labsが自社トップに掲げる「A new frontier in LLM speed（LLM速度の新境地）」というコピーは、この潮流を象徴する言い回しになっています。

---

自己回帰型（GPT型）と拡散型の根本的な違い

ここからは、GPT型に代表される自己回帰型LLMと拡散言語モデルの技術的な違いを整理します。

両者はどちらも「大規模パラメータのニューラルネットで文脈から次の情報を予測する」点は共通ですが、生成方向・文脈参照の広さ・途中修正の可否という3つの軸で明確に設計思想が異なります。

自己回帰型（タイプライター＝Causal attention）と拡散型（プリンティングプレス＝Bidirectional Attention）の生成方式の対比（出典：Google Developers Blog）

図の左は自己回帰型で、各トークンが「前のトークンだけ」を参照して次を決めます（Causal attention）。

右は拡散型で、全トークンが同時に他の全位置を双方向参照しながら復元される構造です。以下の3つの軸で違いを詳しく見ていきます。

生成方向──「左から右」か「全体を同時に」か

自己回帰型は、文の先頭から末尾まで1トークンずつ順次予測します。「AI」→「エージェント」→「は」→…と、直前までに生成した内容を条件として次の1トークンを決めていく方式です。

この設計はシンプルで学習しやすい反面、生成長に比例して推論時間が伸びるという宿命があります。1,000トークン生成するには1,000回のフォワードパスが必要で、GPU並列性を十分に活かしきれません。

一方、拡散言語モデルは「ノイズ化・未確定のキャンバス」を入力とし、未確定位置を1ステップで並列に予測します。
数十〜数百ステップの反復でキャンバスを段階的に「はっきり」させていくため、1ステップあたり複数トークンを同時更新できます。

マスク拡散型ではキャンバス全体をマスクトークンで埋めるところから始め、DiffusionGemmaはキャンバスを256トークンのブロックに区切り、ブロック内は拡散復元・ブロック間は自己回帰的に接続する構成を取ります。

DiffusionGemmaはGoogle Developers Blogの公式ガイドで、単一H100 GPU上で1,000 tok/s超を達成し、同世代の自己回帰型Gemma系より最大4倍のスループットになると報告されています（測定はGoogle公表条件）。

双方向文脈と「反転の呪い」を緩和する可能性

自己回帰型は左から右への逐次予測なので、未来の情報を参照できないという制約があります。

これは実務で「反転の呪い（Reversal Curse）」と呼ばれる現象を引き起こします。学習データに「AはBの父」と書かれていても、モデルは「Bの父は誰？」に答えられないケースが観察されており、双方向で概念を結び付ける能力が弱くなる傾向があります。

これに対して拡散言語モデルは、未確定位置を同時に文脈参照して復元する（マスク拡散型ではマスクトークンをまとめて予測、DiffusionGemmaではプレースホルダーを一括で置換）ため、双方向のコンテキストを最初から扱えます。

ただし2026年時点の研究では、dLLMにも反転の呪いが残ることを示す論文と、マスク拡散によって程度が緩和される可能性を示す論文の双方が報告されており、「完全に克服した」とは言えない状況です。

穴埋めタスク・スタイル調整・部分書き換えといった編集系のタスクでは、この双方向文脈が構造上のアドバンテージになります。

途中修正と「穴埋め（Infilling）」の扱いやすさ

自己回帰型LLMには、実務上のもう1つの弱点があります。標準的な左→右生成では、一度生成したトークンを後から差し替えるのが苦手という点です。

「文の途中でハルシネーションが混じったので、そこだけ書き直したい」といった編集タスクを行う場合、単純な左→右生成では「その位置以降を最初から生成し直す」しかありません。

ただしFill-in-the-Middle（FIM）のように、学習時に中間穴埋めを組み込んだ自己回帰型モデル（Meta Code Llama等）は、部分書き換えを一定水準までサポートできます。

拡散言語モデルは、反復デノイジングの過程で任意の位置のトークンを未確定化して再予測できる構造を持っています（マスク拡散型ではマスクに戻して再予測、Uniform State Diffusion型ではプレースホルダーに戻して再予測）。
これがコード編集・文書リライト・部分プレースホルダー補完など、業務での「編集タスク」で構造的に扱いやすくなります。

Inception Labsが提供するMercury Edit 2はこの特性を活かして、IDE上でのカーソル位置編集や差分適用に特化した商用モデルとして展開されています。

---

拡散言語モデルの仕組み──マスクから並列復元まで

ここでは、拡散言語モデルが具体的にどのようなプロセスで文章を生成しているのかを、学習と推論の両面から整理します。

現在の主流アーキテクチャは「離散拡散モデル（Discrete Diffusion）」と呼ばれる系統で、Masked Diffusion Language Model（MDLM）が代表格です。

以下の説明はLLaDAやELYZA-LLM-Diffusionのようなマスク拡散型（マスクトークンから復元するタイプ）を単純化したもので、DiffusionGemmaはランダムなプレースホルダーから復元するUniform State Diffusion＋ブロック間の自己回帰的接続、Mercury 2は詳細アーキ非公表の並列リファイン型と、モデルごとに実装は異なります。

DiffusionGemmaのアーキテクチャ：Noisy Canvasを反復デノイジングでUpdated canvasへ変換する構造（出典：Google Developers Blog）

Google DeepMindが公開したDiffusionGemmaのアーキテクチャ図は、拡散言語モデルの学習・推論の全体像を掴むのに役立ちます。

左のNoisy Canvas（マスクに限らず、DiffusionGemmaの場合はランダムなプレースホルダートークンで埋められたキャンバス）は双方向注意のDenoiserで処理され、右のInput Query（プロンプト）は因果的注意のEncoderで処理された上でKV-cacheとしてDenoiserに渡されます。

self-conditioningを挟みながらDenoiserがキャンバスを段階的に復元し、Updated canvasとして出力される流れです。以降のフォワード／リバースプロセスは、マスク拡散型（LLaDA・ELYZA）を例に、この骨格の中で動きを見ていきます。

フォワードプロセス（マスキング）──クリーンな文をノイズ化する（マスク拡散型の例）

マスク拡散型モデル（LLaDA・ELYZA-LLM-Diffusion）の学習時、モデルはまずクリーンな文章を段階的にマスクトークン（「[MASK]」）に置き換えるプロセスを経験します。

たとえば「拡散言語モデルは高速に文章を生成できます」という文があれば、時刻tが進むにつれて次のように壊れていきます。

• 時刻t=0：拡散言語モデルは高速に文章を生成できます
• 時刻t=0.3：拡散言語モデルは[MASK]に文章を[MASK]できます
• 時刻t=0.7：[MASK]言語[MASK]は[MASK]に[MASK]を[MASK]できます
• 時刻t=1.0：[MASK][MASK][MASK][MASK][MASK][MASK][MASK][MASK][MASK][MASK][MASK]
  
  

このように、時刻tを大きくするほどマスク比率が上がり、最終的には全マスクの「純粋なノイズ状態」に到達します。

このフォワードプロセスは学習時のみに使う「壊す側」の操作で、モデル本体はこの逆方向（マスクからの復元）を学びます。

リバースプロセス（デノイジング）──マスクから並列復元する

マスク拡散型の推論時は、マスクで埋められた初期状態から反復的にマスクを埋めていくプロセスで文章を生成します。

各ステップで、モデルは残っているマスク位置のトークンをまとめて予測し、確度の高い位置から順に確定させていきます。数十〜数百ステップを繰り返すと、最終的に全マスクが確定して1つの文章が完成します。

この過程を模式的に書くと、次のような流れです。

• ステップ1：「[MASK][MASK][MASK][MASK][MASK][MASK]」（マスク列）を入力し、モデルが全位置の候補を予測。確度の高い1〜数トークンを確定させる
• ステップ2：確定した位置＋残りのマスクを入力し直し、次の1〜数トークンを確定させる
• ステップN：全マスクが確定し、完成した文章として出力される
  
  

重要なのは、各ステップで残るマスク位置を並列に予測する点です。

GPU上ではこの並列予測が1回のフォワードパスで完了するため、同じ長さの出力を得るのに必要なフォワードパス数が自己回帰型の「1トークン=1フォワードパス」より少なく済む可能性があります（実効的な効率はステップ数・ハードウェア・生成設定に依存）。

Google I/O 2025で公開されたGemini Diffusionの生成例：拡散言語モデルが数学問題を段階的に解く様子（出典：Google）

Google DeepMindが公開したGemini Diffusionの動作例では、「(√(81) * (2/3))^2 + (15 - 3) / (2^2)」 のような数式をプロンプト入力すると、拡散型モデルが7つの計算ステップを順序立てて生成しています。

実行時のUI右下に「Slowed down output」と表記があるとおり、実際の生成速度は目で追えないほど高速です。

生成ステップ数と品質・速度のトレードオフ

拡散言語モデルの実務的な設計自由度として、生成ステップ数を変えることで品質と速度のバランスを調整できる点が重要です。

モデル・設定によっては、ステップ数を多くとることで各位置を段階的に洗練でき、品質が上がる可能性があります。逆にステップ数を減らせば速度は上がりますが、品質への影響はモデルごとに異なります。

LLaDA公式リポジトリはステップ削減による性能低下を明記しており、ELYZA公式は設定次第で最大8分の1にステップを削減しつつ多様性・安定性を維持可能と説明しています。一方でDiffusionGemma公式ガイドは適応的停止を採用しており、ステップ数の扱いはモデル設計ごとに前提が異なる点を押さえておく必要があります。

実務では次のような感覚で使い分けます（具体的な数値は各モデルの推奨に従って個別検証する）。

• 高品質寄り
  Reasoning系タスク・長文生成・厳密性重視のバッチ推論。ステップ数を多めに取って品質を優先する
  
  

• バランス寄り
  一般的なチャット応答・要約・翻訳。速度と品質のバランス点として実務ワークロードの主戦場
  
  

• 超高速寄り
  リアルタイム音声応答・エージェント間通信・コード補完のような1トークン遅延がクリティカルな用途。モデル・設定によっては品質が低下する可能性があるため、体感速度優先で採用する場合も品質評価は個別に実施する
  
  

各モデルで生成単位・推奨ステップ・適応的サンプリング・reasoning設定は異なります。

たとえばELYZA-LLM-Diffusionは公式のHugging Faceリポジトリで「temperatureとalg_tempを0.5以上に設定するとステップ数を約8分の1に削減しつつ生成の多様性と安定性を維持できる」と案内しています。

LLaDA公式リポジトリも「最適なステップ数は応答長などに依存する」と説明しており、モデルごとの推奨設定を検証して固める運用が必要です。

つまり拡散言語モデルは、アプリケーション側で速度と品質のトレードオフを動的に選べるという運用上の柔軟性を持っている点も、自己回帰型との大きな違いです。

---

主要4モデルの比較──Mercury 2/DiffusionGemma/LLaDA/ELYZA-LLM-Diffusion

ここからは、2026年7月時点で実務的に選択候補になる4つの拡散言語モデルを整理します。

以下の表で、4モデルの提供元・パラメータ規模・ライセンス・提供形態・料金をまとめました。

モデル	提供元	パラメータ	ライセンス	提供形態	参考料金/入手方法
Mercury 2	Inception Labs（米）	非公開	商用API	Inception公式API・Azure Foundry・Baseten（Mercury/Mercury CoderはAWS Bedrockでも提供）	Inception API：入力$0.25 / 出力$0.75（100万tok）
DiffusionGemma	Google DeepMind	25.2B（MoE、active 3.8B）	Apache 2.0	HF・Kaggle・Vertex AI	オープンウェイト（自前ホスト）
LLaDA-8B-Instruct	中国人民大学＋Ant Group	8B	MIT	Hugging Face	オープンウェイト（自前ホスト）
ELYZA-LLM-Diffusion	ELYZA（日）	7B	Apache 2.0	Hugging Face	オープンウェイト（自前ホスト）

この表からわかるのは、商用最速の1本と、オープンウェイトの3本という2グループ構造です。

前者は品質と速度を安定運用したい実務向け、後者はセルフホスト・微調整・オンプレ運用が前提のR&D向けと役割が分かれています。以下、それぞれのモデルを個別に見ていきます。

Mercury 2──Inception Labsの商用最速dLLM

Mercury 2は、Inception Labsが2026年2月24日に公開した拡散言語モデルシリーズの最新版です（その後もInception公式ブログでリフレッシュ版が随時展開されています）。

同社は2025年11月に$50Mの資金調達を完了しています。Mercury 2は同社の位置づけとして「最速のReasoning対応dLLM」と紹介されています（開発と資金の直接的な対応関係は公式には明示されていません）。

2026年2月24日にInception Labsが公開した拡散言語モデル「Mercury 2」（出典：Inception Labs）

Mercury 2は以下の特性を持ちます。

項目	内容
推論速度	NVIDIA Blackwell GPUで1,009トークン/秒（Inception公表値）。Artificial Analysisの計測ページ（2026年7月時点で参照）でも同水準の実測値が公開されており、同価格帯の中央値を大きく上回る。 実測値は測定日により変動するためリンク先の最新値を参照
料金	Inception API公式で入力$0.25 / 出力$0.75（100万トークンあたり）。Azure Foundry版はソフトウェア時間料金＋コンピュート料金の別体系
コンテキスト長	128K
Reasoning対応	tunable reasoning（思考ステップの量を調整できる）機能を搭載し、複雑な推論タスクにも対応
API	OpenAI互換API。既存のOpenAI SDKで最小限の書き換えで移行可能
提供チャネル	Inception公式API Azure Foundry Baseten （旧世代のMercury・Mercury CoderはAWS Bedrock Marketplace／SageMaker JumpStartでも提供）

Mercury 2の速度ベンチマーク：同社比較でClaude 4.5 Haiku・GPT-5 Miniより約10倍のスループット（出典：Inception Labs）

Inception Labs公式のベンチマーク図では、Mercury 2が1,009 tok/sを記録する一方、同帯の速度最適化モデルであるClaude 4.5 Haiku（89 tok/s）とGPT-5 Mini（71 tok/s）は10分の1以下のスループットに留まっています。ただし実際の体感遅延はTTFT・出力長・reasoning量・ネットワーク時間を含むE2Eで決まるため、tok/sの差がそのまま体感倍率にはならない点は前提として押さえておく必要があります。

顧客事例としては、SearchBloxが自社の企業内AI検索製品「SearchAI」のバックエンドにMercury dLLMを採用し、サブ秒でのGenAI応答を実現しています。

Mercury 2は、Inception Labs公式が公表する「Mercury導入で要約レイテンシを82%削減、コストを90%削減」という事例が示すように、既存の自己回帰型LLMからの置き換えで直接的なコスト・レイテンシ改善が測れるモデルとして仕上がっています。

Mercury 2の性能ベンチマーク：E2E Latency 1.7秒でGPQA Diamond 74・AIME 91を記録（出典：Inception Labs）

Inception Labs公式のベンチマーク表を見ると、Mercury 2はE2E Latency 1.7秒という圧倒的な速さを維持しつつ、GPQA Diamond 74・LiveCodeBench 67・SciCode 38・IFBench 71・AIME 91・TAU 53を記録しています。精度面はベンチマークごとに優劣が分かれ、AIMEではGPT-5 Mini（Medium・22.8秒・AIME 48）やClaude 4.5 Haiku（Reasoning・23.4秒・AIME 84）を上回りますが、GPQA/LiveCodeBench/SciCode/TAUではGPT-5 Miniにやや届かず、IFBenchは同点です。E2Eレイテンシは大幅に短い一方、精度は項目ごとにトレードオフが残る、という読み方が正確です。

DiffusionGemma──Google DeepMindのオープンMoE dLLM

DiffusionGemmaは、Google DeepMindが2026年6月10日に公開した拡散型のGemmaシリーズ最新版で、「google/diffusiongemma-26B-A4B-it」 としてHugging Faceで配布されています。

Gemma 4アーキテクチャをベースに、MoE（Mixture of Experts）構造を採用しており、総パラメータ25.2Bのうちアクティブは1ステップあたり3.8Bのみです。

DiffusionGemmaの実務価値は以下の3点に集約されます。

• オープンウェイト＋Apache 2.0
  商用利用・改変・再配布すべて可能。企業内オンプレ環境で自前ホストできる
  
  

• 256トークンブロック並列デコード
  1ステップで256トークン単位のブロックをまとめて並列復元し、ブロック間は自己回帰的に接続。単一H100 GPUで1,000トークン/秒超を実現（Google公表条件）
  
  

• エコシステム対応の広さ
  Day-zeroでvLLM・Hugging Face Transformers・MLX・SGLangがサポート。NVIDIA NeMo・Unslothでの微調整も可能。NVIDIA NeMoが最適化したNVFP4版も同時公開
  
  

DiffusionGemmaは、オープンウェイトで一定品質の拡散LLMを自社インフラで運用したいユースケースの本命候補です。ライセンス面でも商用利用に制約がなく、自社データでの継続学習・ファインチューニングも公式サポート下で行えます。

LLaDA──アカデミアが牽引した拡散LLMの起点

LLaDA（Large Language Diffusion Models）は、中国人民大学とAnt Groupの共同研究チーム「GSAI-ML」が2025年2月に公開したアカデミア発の拡散言語モデルです。

Hugging Faceの「GSAI-ML/LLaDA-8B-Instruct」で公開されており、直近1か月のダウンロード数は38万件超（2026年7月時点）と、拡散言語モデルの学術リファレンス実装として広く使われています。

LLaDAの実務的な位置づけは以下のとおりです。

• ライセンス：MITライセンスで商用利用可能
• パラメータ：8B（BF16）で、LLaMA3 8B相当の性能を目標に設計
• ベース：スクラッチから拡散学習した完全独立モデル
• 対応推論エンジン：Hugging Face Transformersでの推論を公式リポジトリで案内。vLLM・SGLangでも動作報告があるが、公式サポート範囲はリポジトリのREADME・Issuesで最新状況を確認
  
  

LLaDA-8Bは2026年7月時点で月間ダウンロード数38万件超を記録しており、拡散LLMのリファレンス実装として研究・実験目的で第一候補になります。

一方、企業の本番運用としては、Mercury 2やDiffusionGemmaと比べて品質・エコシステム対応の成熟度に差があります。LLaDAは「拡散LLMの技術検証」「アーキテクチャ理解」「研究プロトタイプ」用途で選ぶべきモデルです。

ELYZA-LLM-Diffusion──日本語特化のオープンdLLM

日本市場では、ELYZAが2026年1月16日に日本語特化の拡散言語モデル「ELYZA-LLM-Diffusion」を商用利用可能なライセンスで公開しました。

「elyza/ELYZA-Diffusion-Instruct-1.0-Dream-7B」などのHFリポジトリで配布されており、日本語データで継続学習された拡散LLMの有力な公開候補です。

ELYZA-LLM-Diffusionの主要スペックは以下のとおりです。

• ベースモデル：Dream-v0-Instruct-7B
• パラメータ：約70億（7Bクラス）
• 学習データ：日本語約62Bトークンで継続事前学習を実施、指示チューニングは公開元によって記載が異なる（Hugging Faceモデルカードでは日本語1.8Bトークン×10エポック、Zenn技術記事では0.18Bトークン×100エポック）
• ライセンス：Apache 2.0（商用利用・改変・再配布可）
• 想定用途：研究用途および検証用途（同社公式明記）
• ステップ数調整：「temperature」と「alg_temp」を0.5以上に設定することでステップ数を約8分の1に削減しつつ生成の多様性と安定性を維持できる設計
  
  

ELYZA-LLM-Diffusionは、日本語で拡散LLMをオンプレ検証したい・日本語ドメインでの継続学習ベースが欲しいというニーズに応える有力な公開候補として位置づけられます。

公式は「主に研究用途および検証用途での利用を想定」と明記しており、本番投入前のPoC・アーキテクチャ検証・日本語dLLMエコシステム参入の起点として活用するのが現実的な使いどころです。

---

拡散言語モデルの料金相場とコスト構造

拡散言語モデルは、商用APIとオープンウェイトの2系統で料金・コスト構造が大きく異なります。ここでは両者を分けて整理し、実務での試算例まで示します。

Mercury 2の商用API料金と削減効果

Mercury 2は現時点で拡散言語モデル系の商用APIとしては最も安価な部類に位置します。

Inception公式API（docs.inceptionlabs.ai）で公表されている料金は、SaaS型API単価としてリージョン概念なく提示されています。

モデル	入力トークン	出力トークン	提供チャネル
Mercury 2	$0.25 / 100万tok	$0.75 / 100万tok	Inception公式API（Azure Foundry・Basetenは別体系）
Mercury Edit 2	$0.25 / 100万tok	$0.75 / 100万tok	Inception公式API

2026年7月時点のInception公式pricingに基づく。Azure Foundry版はソフトウェア時間料金＋コンピュート料金の別体系、Baseten等パートナー経由も別料金となるため、全チャネル共通単価ではない点に注意。

この単価は、Claude Haiku 4.5やGPT-5 Miniといった主要ベンダーの「速度最適化ミドルレンジモデル」と同程度〜やや安価な水準です。

Inception Labsが公表しているアーリー導入企業の事例では、「Mercury dLLM導入で要約レイテンシを82%削減、推論コストを90%削減」という数値が公表されています（Inception Labs公式）。

ただし削減率は「元のモデル・入出力比率・reasoning設定・工程数」に強く依存するため、自社ワークロードでの実測なしに数値を横展開すべきではありません。

オープンモデル系のセルフホストコスト

DiffusionGemma・LLaDA・ELYZA-LLM-Diffusionのオープンウェイト3モデルは、モデル自体の料金はゼロですが、推論用GPUの調達・運用コストが実質的な支払い先になります。

自前ホストする場合の主要コスト項目は次のとおりです。

• 推論GPU
  DiffusionGemma 26B MoEはH100（80GB）1枚から動作。LLaDA 8B・ELYZA 7Bはより軽量なGPU（A100 40GB・L40S等）でも動作可能。
  
  GPU時間単価はプロバイダー・リージョン・確保方式（オンデマンド／予約／スポット）で大きく異なるため、Google Cloudアクセラレーター料金やAWS EC2 Capacity Blocks料金など、実際に使うクラウドの公式料金ページで確認したうえで試算する
  
  

• 推論エンジン
  vLLM・SGLang・NVIDIA NeMoなどオープンソースの推論サーバーを利用する場合、ライセンス料は不要。ただし運用保守の工数は自社負担
  
  

• モデルのファインチューニング
  Unsloth・NVIDIA NeMoでの追加学習は基本無料だが、学習用GPU（A100複数枚〜H100）は別途調達が必要
  
  

• 監視・SLA運用
  可用性保証・スケーリング・障害対応は自社責任。マネージドAPI（Mercury 2）と比べて総所有コスト（TCO）を必ず試算する
  
  

自前ホストと従量課金APIの損益分岐点は、月間トークン量・GPU稼働率・運用工数・SLA要件に強く依存します。単純な単価比較ではなく、後述の4要素で試算した上で判断するのが実務的です。

TCO試算の考え方──「切り替え効果」の見積もり方

拡散言語モデルへの切り替えを検討する場合、単純な単価比較ではなく「レイテンシ改善による業務効果」まで含めたTCO試算を行うのが実務的です。

試算に含めるべき主な要素は以下の4点に整理できます。

• 推論単価の差分
  現行LLMの入出力単価とMercury 2の単価差から、月間トークン量ベースの純粋なコスト削減額を算出
  
  

• レイテンシ短縮による業務効果
  音声応答・チャット応答での待ち時間短縮が、顧客満足度・離脱率・オペレーターの処理件数にどれだけ効くかを数値化
  
  

• 切り替え工数
  OpenAI互換APIならMercury 2は最小の書き換えで済むが、レスポンス構造・ストリーミング仕様の微差でテストコストが発生
  
  

• 品質劣化リスクの許容度
  高精度が必要なタスクでは拡散LLM切り替えで品質が微減する可能性があり、切り替え可否は用途ごとに評価する必要がある
  
  

これら4要素を合わせた総コスト差分がプラス（＝削減額 - 切り替え工数 > 0）であれば、切り替えの経済合理性は成立します。

実務では、比較元モデル・入出力比率・為替・GPU稼働率・移行工数を具体的に置いた試算表を作り、月間トークン量ベースで回収期間を計算するアプローチが有効です。

数値そのものはワークロードごとに大きく変わるため、汎用的な閾値（月間◯億トークンなら◯ヶ月で回収）を鵜呑みにするのは避けてください。

---

拡散言語モデルを選ぶべき用途と判断軸

拡散言語モデルは万能ではありません。速度が業務体験を左右する用途で第一選択、精度・厳密性優先の用途では慎重評価という切り分けが実務的な判断軸になります。

以下、AI総研の導入支援でも問い合わせが多い4つの領域について、どの拡散LLMを候補にすべきかを整理します。

リアルタイム音声・対話AI──Mercury 2が第一候補

音声エージェント・音声認識後のTTS応答・電話ボット等、1トークンあたりのレイテンシがそのままユーザーの待ち時間になる用途では、拡散言語モデルの高速性が最も効きます。

自己回帰型LLMでは、500トークン応答するのに数秒かかるのが典型で、音声対話のテンポを崩す原因になっています。

この領域では次の推奨が現実的です。

• 本番運用：Mercury 2（Inception公式API・Azure Foundry）が有力候補。高いtok/sは出力全体の生成時間短縮に効きうるが、TTFTはtok/sとは別指標のため、切り替え検証で自社ワークロードのTTFT・出力長・reasoning量・ネットワーク時間を含むE2Eで実測してから判断する
• PoC・技術検証：Baseten経由の従量課金で、既存音声パイプラインを一部差し替える形で検証開始
• オンプレ制約がある場合：DiffusionGemmaを自社GPU上でホストし、同等方向のレイテンシ改善を狙う
  
  

音声対話系は、Inception公式が公開するOpenCallが本番運用するMercury 2ベースの音声エージェント事例が示すように、拡散言語モデルの切り替え効果が最も見える化しやすい第一領域です。

コード補完・IDE統合──Mercury Edit 2やMercury Coder

IDE上でのコード補完・カーソル位置編集・差分適用は、エディタでの入力体感速度を落とさないことが最重要要件です。

自己回帰型のCopilot系モデルでも一定水準は達成できますが、拡散言語モデルの「任意位置編集」「並列生成」の特性は、この領域で理論的にもマッチします。

推奨は以下のとおりです。

• 商用IDE統合
  Mercury Coder（コード特化版）・Mercury Edit 2が公式ドキュメントで想定用途として明示
  
  
• カスタム開発ツール
  DiffusionGemmaを自前ホストしてIDEプラグインに組み込むアプローチも検証可能（ただしDiffusionGemma自体はGoogle公式で「experimental」と位置づけられているため、本番投入前に品質・安定性の評価が必要）
  
  
• セキュリティ制約が強い環境
  LLaDA 8B・ELYZA-LLM-Diffusionでの検証を経由してから、社内オンプレ推論に接続
  
  

コード補完領域では、拡散LLMの「途中修正・穴埋め能力」が自己回帰型より構造的に有利で、切り替え検証の価値が高い領域です。

日本語バッチ推論・オンプレ検証──ELYZA-LLM-Diffusion

日本語で大量文書を処理するバッチ推論、または機密データを扱うためオンプレ環境で拡散LLMを検証したい場合、ELYZA-LLM-Diffusionが日本語データで継続学習された有力な商用利用可能候補になります。

Apache 2.0で商用利用可能・日本語62Bトークンで継続事前学習済み・ステップ数削減による高速化に公式対応という3条件を同時に満たしており、日本語ドメインで拡散LLMを触るなら第一候補です（他候補との比較は各モデルカードで確認してください）。

この領域での判断ポイントは以下です。

• 想定用途は研究・検証：ELYZA公式が「研究用途および検証用途での利用を想定」と明記。本番投入前に品質評価が必須
• 社内オンプレ推論のプロトタイプ基盤に：H100・A100クラスのGPUがある企業なら、機密データを外に出さずに拡散LLMの効果を検証可能
• 本番向けにMercury 2との併用パス：ELYZA-LLM-Diffusionでオンプレ検証→本番はMercury 2 APIに切り替え、というハイブリッド設計も現実的
  
  

日本語ドメインで拡散LLMを扱う場合の第一歩として、まずELYZA-LLM-Diffusionを触ってアーキテクチャ理解と品質評価を進めるのが実務的です。

現時点で切り替えを見送るべきケース

一方、拡散言語モデルの切り替えを2026年時点でも慎重に判断すべき用途があります。

以下のケースでは、拡散型への切り替えを見送り、実績のある自己回帰型LLM（Claude Opus 4.8・GPT-5・Gemini 3 Proなど）を継続するか、拡散型と並行検証しながら段階的に切り替える判断が妥当です。

• 厳密な数値計算・法務文書レビュー
  高精度が必要な用途では、既存の自己回帰型フロンティアモデルを基準にモデル別のベンチマークで評価し、拡散型が同等水準に届くかを個別に判断する
  
  

• 長文（数万〜10万トークン）の一貫性重視タスク
  超長文の論理一貫性は、既存の自己回帰型フロンティアモデルを基準にモデル別で評価する。拡散型モデルの多くは中〜短文のスループット改善が主戦場で、長文コンテキストのサポート範囲・一貫性はモデルごとに検証が必要
  
  

• エコシステム連携が濃い既存パイプライン
  ツール呼び出し・関数呼び出しの複雑な連携を組み込み済みの自己回帰型ワークフローは、拡散LLMへの切り替えで既存の作り込みが壊れる可能性がある
  
  

• ハルシネーション許容度が極端に低い用途
  医療・金融の判断根拠出力のように、1文字のズレも許容できない用途では、生成方式を問わずLLM単独では精度担保が難しく、検証・監査・人手レビューを組み合わせた運用設計が必須
  
  

つまり拡散言語モデルは、速度がボトルネックの用途から段階的に切り替えていくのが2026年時点の現実的な進め方です。既存ワークフロー全部を一気に置き換える意思決定は、投資対効果と品質リスクの両面で慎重に扱うべきです。

---

拡散言語モデル導入で見落としがちな制約と詰まる論点

拡散言語モデルへの切り替えは、単に「速いLLMに置き換える」ではありません。実装レベルで詰まりやすい論点が3つあります。順に整理します。

生成品質のばらつき──ステップ数トレードオフをどう運用するか

マスク拡散型・Uniform State Diffusion型など複数の実装があり、生成ステップ数を減らすと高速化する一方で、モデル・設定によっては品質が低下する可能性がある点は共通の論点です。

挙動はモデルごとに大きく異なるため、実装別に検証する必要があります。

「ステップを大幅に減らすと速度優位が最大化する反面、モデルによっては品質のばらつきが出る」「ステップを増やせば安定するが速度優位が薄れる」というトレードオフに、どのラインで折り合いをつけるかが最初の悩みどころです。

実務的な対応策は以下の3点です。

• ステップ数を用途別に固定
  音声応答・要約・reasoningの各用途で使用モデルの推奨値を検証し、モデルごとに標準値を決めておく（LLaDA公式リポジトリも「最適なステップ数は応答長などに依存する」と明記しており、DiffusionGemma公式ガイドは適応的停止を採用するなど、共通の固定プリセットは存在しない）
  
  

• 品質モニタリングを併走
  出力の品質メトリクス（BLEU・ROUGE・ダウンストリーム精度）を継続計測し、ステップ数変更の影響を可視化する
  
  

• フォールバック経路を用意
  低ステップで生成→品質不十分と判定→高ステップまたは自己回帰型モデルで再生成、という2段構えのパイプラインを持つ
  
  

ステップ数チューニングは、拡散LLM運用の中核パラメータです。切り替え直後に固定値で回し始めるのではなく、用途別のチューニング表を最初に整備するのが安全策になります。

ツール連携・エコシステム未成熟

自己回帰型LLMは、Function Calling・Tool Use・MCP（Model Context Protocol）といった外部ツール連携のエコシステムが成熟しています。

拡散言語モデルはこの領域がまだ発展途上です。

詰まる論点は次のようなものです。

• Function Calling準拠度
  Mercury 2はOpenAI互換APIでtool_calls対応済みだが、拡張仕様（Anthropic Tool Use等）にはまだ対応がまばら
  
  

• エージェントフレームワークとの相性
  LangChain・LangGraph・グラフエンジニアリング系フレームワークの多くは自己回帰型前提で組まれている。拡散LLMへの対応は個別実装が必要な場合がある
  
  

• 観測・デバッグツール
  拡散LLMの内部プロセス（ステップごとの復元途中経過）を可視化するツールは自己回帰型に比べて少ない
  
  

エージェント基盤に拡散LLMを組み込む場合、モデル呼び出し層とエージェント制御層を明確に分離し、モデルの世代交代を吸収できる設計にしておくのが賢明です。

この観点は、AI Agent Hubのようなエージェント統合基盤の存在意義を高める方向に働きます。

既存Transformerパイプラインからの切り替え設計

既に本番運用中のTransformerベースのパイプラインを拡散LLMに切り替える場合、入出力の互換性・レスポンス構造・ストリーミング挙動の微差でつまずくケースがあります。

主な論点は次のとおりです。

• ストリーミング応答
  自己回帰型は「トークンを1つずつ即座に返す」ストリーミングが自然だが、拡散LLMは「ステップごとにキャンバス上の複数トークンが更新される」動きが一般的で、UIへの逐次表示ロジックの再設計が必要な場合がある（Mercury 2はOpenAI互換のストリーミングAPIを提供するなど、モデルごとに実装差もある）
  
  

• 温度・トップkパラメータの意味
  拡散LLMでは「temperature」のほかに「alg_temp」など拡散特有のパラメータが追加されており、自己回帰型と同じ設定値で同等品質を得られるとは限らない
  
  

• プロンプトテンプレートの調整
  指示チューニングの流儀がモデルごとに違うため、既存プロンプトが期待通りに機能するかを再検証する必要がある
  
  

これらの詰まる論点を先回りで整理し、PoC段階で「切り替え可否」ではなく「切り替え設計の型」を確立するのが、拡散LLM導入プロジェクトの成功パターンです。

---

拡散言語モデル世代のLLMを業務プロセスに定着させるなら

Mercury 2・DiffusionGemma・ELYZA-LLM-Diffusionのように、新アーキテクチャの言語モデルが半年サイクルで登場する時代には、モデルを直接呼び出す設計ではなく、Agent層でモデルを差し替えられる構造が有効になります。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、拡散言語モデルを含む複数モデルを業務ワークフローに組み込む実行基盤として機能します。

• モデル世代交代を吸収する業務組み込み層
  自己回帰型LLMから拡散LLMへの切り替えでも、業務Agent側の設計は不変。特定モデル依存のワークフロー陥落を回避できます。
  
  
• 用途別にモデルを使い分けるAgent設計
  音声応答は高速なMercury 2、精度優先の要約は自己回帰型フロンティア、日本語オンプレ検証はELYZA-LLM-Diffusion、と用途ごとにモデル選定を切り替えられます。
  
  
• 使い慣れたMicrosoft環境をそのまま活用
  Teams・Excel・Outlookなど既存ツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  
• データは100%自社テナント内に保持
  Azure Managed Applicationsとして自社テナント内で動作が完結。外部LLMを組み合わせる場合も業務データの往来を管理レイヤーで制御できます。

AI総合研究所の専任チームが、拡散言語モデル世代を見据えたモデル選定からAIエージェント基盤の本番運用まで一貫して伴走支援します。AI Agent Hubのサービスページで、dLLM時代を見据えた業務Agent基盤の全体像をご確認ください。

---

まとめ

本記事では、拡散言語モデル（dLLM）について、仕組み・自己回帰型LLMとの違い・主要4モデル比較・料金構造・用途別判断軸・導入で詰まる論点までを、2026年7月時点の公式一次情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• 拡散言語モデルはマスクや代替プレースホルダーからの反復デノイジングで動く新世代アーキテクチャで、モデル・設定次第で自己回帰型LLMより数倍のスループットを狙える
• 商用APIはMercury 2（入力$0.25/出力$0.75）、オープンウェイトはDiffusionGemma 26B・LLaDA-8B（MIT）・ELYZA-LLM-Diffusion（Apache 2.0・日本語継続学習）が代表格
• 第一候補用途はリアルタイム音声応答・コード補完・大量バッチ推論の3領域で、精度優先タスクは自己回帰型フロンティアモデルとの並行検証を経て段階的に切り替えるのが実務的
  
  

拡散言語モデルは、「速度制約が業務体験のボトルネックになる領域」から自己回帰型を段階的に置き換えていくのが2026年時点の現実的な進め方です。まずは音声応答・コード補完・チャット系の1ワークロードでMercury 2または対応するオープンモデルのPoCを始め、レイテンシとコストの改善効果を数値で確認するところから着手するのが、最も実用的な第一歩になります。