開発者が理解すべきMercury 2と拡散型言語モデル（dLLM）の基本設計思想

開発者が理解すべきMercury 2と拡散型言語モデル（dLLM）の基本設計思想

2026年2月、AI業界に新たな潮流をもたらすモデルが登場しました。Inception Labsが発表したMercury 2は、従来のLLMとはまったく異なる「拡散型言語モデル（dLLM）」というアーキテクチャで構築された推論モデルです。GPTやClaude、Geminiといった主要モデルがすべて自己回帰型の逐次生成方式を採用するなか、Mercury 2は画像生成AIと同じ拡散技術をテキスト生成に応用するという根本的に異なるアプローチを取っています。開発者やAIエンジニアにとって、この新しいアーキテクチャの設計思想を正しく把握することが、今後のモデル選定と実装判断の出発点になります。

Stanford・UCLA・Cornell発の研究チームが商用化に至った拡散型LLMの開発経緯

Mercury 2を開発したInception Labsは、Stanford大学、UCLA、Cornell大学の研究者によって設立されたAIスタートアップです。共同創業者でありCEOのStefano Ermon氏は、画像生成分野における拡散モデルの先駆的研究で知られる人物であり、チームにはFlash Attention、Decision Transformers、Direct Preference Optimization（DPO）といったAI基盤技術の共同発明者も含まれています。もともと画像・動画の生成で実績を積んだ拡散技術を、言語生成という新たな領域に応用するというのが同社の一貫したビジョンでした。

最初の商用モデルであるMercury Coderは2025年初頭にプロトタイプとして登場し、コード生成に特化した拡散型LLMとして注目を集めました。そこからわずか1年で、汎用推論能力を備えたMercury 2へと進化しています。研究から商用化まで一貫したチームが推進したことで、学術的な拡散理論と実運用での最適化が高いレベルで統合された結果、毎秒1,000トークンを超える速度と競争力のある推論品質の両立が実現しました。Menlo VenturesやMayfieldといった主要VCからの出資も受けており、投資家からの評価もアーキテクチャの革新性に裏打ちされたものです。

ノイズから段階的に精製するデノイジング処理が従来の左→右生成と異なる3つの点

Mercury 2の核心は「デノイジング（ノイズ除去）」というプロセスにあります。従来の自己回帰型LLMがテキストを左から右へ1トークンずつ確定させていくのに対し、Mercury 2はまず出力全体の粗いスケッチを生成し、それを複数回の反復処理で洗練していきます。この違いは3つの観点から整理できます。

第1に、生成の並列性です。自己回帰型では前のトークンが確定するまで次のトークンを生成できませんが、Mercury 2は1回のニューラルネットワーク評価で複数のトークンを同時に修正します。第2に、エラー修正の柔軟性です。逐次生成では一度確定したトークンを後から変更できませんが、反復的な精製プロセスでは生成途中でも誤りを修正できるため、ハルシネーションの低減が期待されます。第3に、速度の源泉がモデル自体に内在する点です。従来モデルの高速化は専用チップや圧縮技術に依存していましたが、Mercury 2のスピードはアーキテクチャそのものの特性から生まれています。

画像生成AIと同じ拡散原理をテキストに応用した際に生じる技術的制約と対処法

拡散モデルはMidjourneyやDALL-Eなどの画像生成で広く使われている技術ですが、テキスト生成への応用には固有の課題があります。画像は連続的なピクセル値で構成されるため、ノイズを徐々に除去するプロセスが自然に機能します。一方、テキストは離散的なトークンの列であり、わずかな変更でも意味が大きく変わり得るため、精製プロセスの設計に工夫が必要です。

Inception Labsはこの課題に対し、Transformerモデルをデノイジングの基盤として採用することで対処しています。各反復ステップでTransformerが出力全体を評価し、複数のトークンを同時に改善する仕組みです。また、Mercury 2は現時点でテキスト入力・テキスト出力のみに対応しており、画像入力には非対応です。マルチモーダル対応を見送ることで、テキスト生成に特化した最適化を優先した設計判断といえます。Google DeepMindも同様の拡散型言語モデル「Gemini Diffusion」の研究を進めており、今後この技術領域自体が急速に発展する可能性を示唆しています。

128Kコンテキスト・ツール使用・JSON出力など実務で問われるMercury 2の基本仕様

Mercury 2の実務レベルでの基本仕様を把握しておくことは、導入検討の前提条件になります。コンテキストウィンドウは128Kトークンをサポートしており、長文ドキュメントの処理や会話履歴の保持に十分な容量を確保しています。ツール使用（Tool Use）にもネイティブ対応しているため、外部APIの呼び出しやファンクションコーリングを含むエージェントワークフローに組み込むことが可能です。

また、スキーマに準拠したJSON出力にも対応しており、構造化データの生成が求められるパイプラインとの親和性が高い設計です。APIはOpenAI互換フォーマットで提供されているため、既存のOpenAI SDK向けに構築されたアプリケーションからの移行障壁が低く抑えられています。推論時の調整パラメータとしてtemperature（0.0〜1.0）、top_p、presence_penalty、max_tokensなどが用意されており、ユースケースに応じた出力制御が柔軟に行えます。モデル名はmercury-2として指定でき、エンドポイントはhttps://api.inceptionlabs.ai/v1/chat/completionsです。

自己回帰型モデルが抱える逐次ボトルネックをMercury 2が解消する構造的理由

GPT、Claude、Geminiに代表される主要LLMは、すべて自己回帰型生成という共通のメカニズムに依存しています。このアーキテクチャでは、テキストが厳密に左から右へ、1トークンずつ生成されるため、速度は本質的にシーケンシャルな処理能力に制約されます。推論の深度が増すほど生成に要するトークン数も増大し、サービング（推論提供）のコストとレスポンスタイムが同時に悪化するという構造的な問題を抱えていました。

業界はこれまで、専用チップの開発、推論サーバーの最適化、モデル圧縮という3つのアプローチで速度改善を試みてきましたが、いずれも同じ逐次生成ループの上に成り立つ改善にすぎません。Mercury 2はこのボトルネック自体を取り除くアプローチです。並列的にトークンを精製する拡散アーキテクチャにより、1回のモデル推論でより多くの「有用な仕事」が実行されるため、同じ演算リソースから従来比で5倍以上のスループットが得られます。速度の向上がハードウェアの追加ではなくモデル構造の変革によって達成されている点が、コスト効率にも直結する構造的な強みです。

逐次トークン生成との決別で実現した毎秒1,000トークン超の並列精製メカニズム

Mercury 2の最大の特長は、その圧倒的な推論速度です。NVIDIA Blackwell GPU上で毎秒1,009トークン、独立評価機関Artificial Analysisの計測では毎秒1,196トークンという数値が報告されています。この速度は、同価格帯の次に高速なモデルと比較しても3倍以上の差があり、自己回帰型の最速クラスと比べると10倍以上の開きがあります。なぜこれほどの速度差が生まれるのか、その並列精製メカニズムの詳細を技術的に掘り下げます。

1回のニューラルネット評価で複数トークンを同時修正する並列リファインの仕組み

自己回帰型LLMでは、各トークンの生成に1回のフォワードパス（ニューラルネットワーク全体の評価）が必要です。100トークンの出力を得るには、原理的に100回のフォワードパスが求められます。Mercury 2はこの制約を根本から覆しました。1回のフォワードパスで出力全体の複数トークンが同時に修正・改善されるため、同じ回数の演算でより多くのテキストが確定していきます。

具体的には、まずランダムなノイズに近い初期状態から出力の「下書き」が生成され、次にTransformerベースのデノイジングネットワークがその下書きを全体的に評価します。この評価をもとに、不正確な部分や不自然な表現が同時に複数箇所で修正されます。このプロセスを少数のステップ（数回程度）で繰り返すことで、最終的な出力に収束します。タイプライターが1文字ずつ打つのではなく、編集者が原稿全体を一度に推敲するようなイメージです。この「1ステップあたりの有用な仕事量」の多さが、毎秒1,000トークンを超える速度の源泉となっています。

NVIDIA Blackwell GPUで毎秒1,009トークンを記録した速度の内訳とハードウェア要件

Inception Labsが公表したベンチマークによると、Mercury 2はNVIDIA Blackwell GPU上で毎秒1,009トークンの出力スループットを達成しています。さらに、Artificial Analysisが独立に計測した数値では毎秒1,196.2トークンという結果が出ており、公称値を上回る実績が確認されています。この速度は、Claude Haiku 4.5の約89トークン/秒、GPT-5 Miniの約71トークン/秒と比較すると、10倍以上のスループット差に相当します。

重要な点として、この速度はモデル圧縮や特殊チップへの依存ではなく、拡散アーキテクチャ自体の並列性から得られているということです。NVIDIAのShruti Koparkar氏も、Mercury 2がNVIDIA GPUインフラ上で毎秒1,000トークンを超えた実績を「新しいモデルアーキテクチャとAIインフラの出会いが実現したもの」として評価しています。ただし、Mercury 2の公表ベンチマークはNVIDIA Blackwellという最新世代GPUで計測されたものであることは留意すべきです。なお、前世代のMercury CoderはNVIDIA H100上で毎秒1,000トークン超を達成した実績がありますが、Mercury 2についてはBlackwell GPU以外での公式なパフォーマンスデータは現時点で公開されていません。

生成途中のエラー自己修正が可能になる反復的デノイジングの品質面での実測効果

Mercury 2の拡散アーキテクチャがもたらすのは速度面の利点だけではありません。反復的なデノイジングプロセスには、品質面でも固有のアドバンテージがあります。自己回帰型モデルでは、一度生成されたトークンは確定済みとして扱われ、後続のトークン生成に影響を与え続けます。初期段階で不正確なトークンが生成されると、その誤りが後方に伝播するリスクを構造的に抱えています。

対照的に、Mercury 2は各精製ステップで出力全体を再評価するため、前のステップで生成された不正確な部分を後のステップで修正する機会があります。Inception Labsはこの特性について「生成途中のエラー修正能力」として明示的に言及しており、ハルシネーションの低減につながる構造的要因と位置づけています。実運用においては、リトライやフォールバックの頻度が減少し、出力の予測可能性が向上するという効果が報告されています。この「1回の推論でより信頼性の高い出力が得られる」という特性は、エージェントループのように何度もモデルを呼び出す処理で特に大きな意味を持ちます。

自己回帰型が1トークンずつ確定する方式と比較した際のレイテンシ差が生まれる構造

レイテンシの差が生まれるメカニズムを構造的に理解するために、両者の処理フローを比較します。自己回帰型モデルでは、出力の長さに比例してフォワードパスの回数が増えます。たとえば1,000トークンの応答を生成する場合、1,000回のシーケンシャルな推論ステップが必要であり、各ステップにはモデル全体のパラメータ評価が伴います。推論の深度が増してchain-of-thoughtのトークンが増加するほど、この制約は深刻化します。

Mercury 2では、出力長に対する推論ステップ数の比率が大幅に小さくなります。少数の精製ステップで大量のトークンが同時に確定するため、出力が長くなっても推論時間の増加が緩やかです。Inception Labsはこの特性を「根本的に異なる速度曲線」と表現しています。エンドツーエンドのレイテンシで比較すると、Mercury 2は1.7秒で応答を完了するのに対し、Gemini 3 Flashは14.4秒、推論有効時のClaude Haiku 4.5は23.4秒を要するとされています。この差は、リアルタイム性が要求される音声インターフェースやインタラクティブなコード編集において決定的な体験差を生み出します。

p95・p99レイテンシの安定性で見る高負荷時のスループット維持力と運用上の実績値

本番環境での運用を考える際、平均スループットだけでなく、高負荷時のテールレイテンシ（p95・p99パーセンタイル）の安定性が重要な評価軸になります。Inception Labsは、Mercury 2が「高い並行処理時のp95レイテンシ」「一貫したターンごとの動作」「システムが忙しくなっても安定するスループット」を最適化対象としていると明言しています。

これは自己回帰型モデルにおける既知の課題への対応でもあります。従来モデルでは、同時リクエスト数が増加するとバッチ処理の効率が低下し、テールレイテンシが急激に悪化するケースが少なくありません。Mercury 2の拡散アーキテクチャは、並列トークン生成という構造的特性により、GPU使用効率が高い状態で維持されやすいという理論上の優位性を持っています。実際のプロダクション環境でのデプロイ実績として、SearchBloxやリアルタイム広告最適化企業など複数の顧客がサブ秒レスポンスを安定的に達成したと報告しており、ベンチマーク数値だけでなく実運用でのスループット安定性が裏付けられつつあります。

AIME 91.1・GPQA 73.6など主要ベンチマークが示すMercury 2の推論品質と速度実績

推論モデルの評価にあたっては、速度だけでなく品質面での実力把握が不可欠です。Mercury 2は複数の主要ベンチマークで測定されており、数学的推論、科学知識、コーディング、指示追従といった多面的な能力が数値化されています。同価格帯のモデルと比較して品質面でどの程度の位置にあるのか、また速度重視のアーキテクチャが品質にどのようなトレードオフをもたらしているのかを、具体的な数値をもとに検証します。

AIME 2025で91.1を記録したMercury 2の数学的推論力とその評価条件

AIME（American Invitational Mathematics Examination）は、高度な数学的推論能力を測るベンチマークとして広く使われています。Mercury 2はAIME 2025で91.1というスコアを記録しました。この数値は、数学的な問題解決において高い推論能力を有していることを示しています。同価格帯の速度最適化モデルと比較しても上位に位置する結果です。

ただし、このスコアを解釈する際にはいくつかの条件を考慮する必要があります。Mercury 2は推論モデルであり、拡張された思考プロセス（chain-of-thought）を経て回答を生成します。推論トークンの分量が多い傾向があるため、単純な速度比較だけでなく、推論にかかる総トークン数と回答精度の関係も重要な評価軸となります。また、AIMEスコアは数学特化の指標であり、汎用的な推論品質を単独で判定するものではない点も留意が必要です。数学的推論を多用するワークフロー、たとえばデータ分析エージェントや金融計算パイプラインにおいては、このスコアが直接的な性能予測として機能しやすいでしょう。

GPQA 73.6・IFBench 71.3・LiveCodeBench 67.3の各指標が意味する実務的な強みと弱み

Mercury 2は数学以外のベンチマークでも測定されています。GPQAは73.6、IFBench（指示追従能力）は71.3、LiveCodeBench（コーディング能力）は67.3、SciCodeは38.4、Tau2は52.9というスコアが報告されています。これらの数値は、Claude 4.5 HaikuやGPT-5.2 Miniと比較して「競争力のある範囲」に位置づけられるとInception Labs自身が述べています。

実務観点で特に注目すべきはIFBenchの71.3です。Artificial Analysisの評価によれば、Mercury 2はIFBenchでgpt-oss-120B、GPT-5.1 Codex mini、GPT-5 nanoを上回る指示追従能力を示しています。エージェント型のワークフローでは、モデルが指示に忠実に従うことが安定稼働の前提条件となるため、この指標の高さは実運用での信頼性につながります。一方、SciCode 38.4という数値は科学的コーディングタスクにおいてやや弱みを示しており、科学計算やリサーチ自動化を主目的とする場合には、より高スコアのモデルとの併用を検討する必要があります。

Artificial Analysis Intelligence Index 33点が示す同価格帯モデル内での相対的位置づけ

Artificial Analysisが提供するIntelligence Indexは、推論、知識、数学、コーディングを含む複合的なベンチマーク群で構成される総合指標です。Mercury 2はこのインデックスで33点を獲得しており、同価格帯の推論モデルの中央値17点を大きく上回っています。134モデル中18位という順位は、価格帯を考慮すると際立った知能水準です。

ただし、この33点という数値はフロンティアモデル（GPT-5.2やClaude Opus 4.5など）とは明確な差があります。Mercury 2はリーダーボード上位を狙うモデルではなく、プロダクション環境での速度と品質のバランスを最適化したモデルとして設計されています。評価に際しては、Intelligence Index単体の数値で判断するのではなく、自社のユースケースが求める品質水準とスループット要件のバランスで適合性を判断することが合理的です。特にエージェントループのような「品質がそこそこで速度が決定的に重要」な領域では、Intelligence Index 33点でも十分な実用性を発揮する場面が多いと考えられます。

69Mトークン生成という冗長性傾向がベンチマーク解釈時に注意すべき落とし穴

Mercury 2のベンチマーク結果を解釈する際に見落としやすいポイントがあります。Artificial AnalysisがIntelligence Indexを評価した際、Mercury 2は69Mトークンを生成しました。同価格帯の推論モデルの中央値は17Mトークンであり、Mercury 2は約4倍の冗長性を示しています。つまり、同じベンチマークテストに対して、他のモデルよりも大幅に多くのトークンを出力する傾向があるということです。

この冗長性は2つの実務的な影響を持ちます。第1に、出力トークン数が多いということは、出力課金ベースのコスト計算において見積もり以上の費用が発生する可能性があるという点です。料金体系上の出力単価が安くても、トークン量が多ければ総額は増加します。第2に、推論モデル特有のchain-of-thoughtトークンが冗長になる傾向があるため、最終回答の抽出や後処理パイプラインでの扱いに工夫が必要になる場合があります。ベンチマークのスコアだけでなく、実際のタスクでの出力効率を自社環境でテストすることが、正確なコスト見積もりと品質評価の鍵となります。

Terminal-Bench HardやIFBenchでClaude Haiku 4.5と同等評価を得た具体的な条件

Artificial Analysisの独立評価によると、Mercury 2はTerminal-Bench Hardにおいて Claude Haiku 4.5と同等レベルのパフォーマンスを示しています。Terminal-Bench Hardはエージェント的なコーディングタスクを対象としたベンチマークであり、実際の開発ワークフローに近い条件での能力を測定するものです。また、IFBench 70%超という指示追従能力でも、一部の大型モデルを上回る結果が報告されています。

これらの結果が示すのは、Mercury 2が特定のタスク領域ではフロンティアモデルの軽量版と遜色ない品質を発揮できるということです。ただし「同等評価」の条件を正確に理解しておく必要があります。ベンチマークはInception Labs自身のAPIで実行された結果であり、高負荷の本番環境やカスタムプロンプト設計時の品質安定性とは別の議論です。また、Mercury 2がテキスト入力のみに対応しマルチモーダル入力に非対応である点は、画像やPDFを含むタスクでは直接比較できないことを意味します。同等評価が成立するのは、テキストベースの推論・コーディング・指示追従タスクに限定される、という条件付きの理解が正確です。

Claude Haiku 4.5・GPT-5系モデルとの料金・スループット・品質における定量比較

Mercury 2の導入を検討する際、もっとも実践的な判断材料となるのが、主要な競合モデルとの定量比較です。Inception Labsの公式発表では、推論品質の比較対象としてClaude 4.5 HaikuとGPT 5.2 Miniが、スループットの比較対象としてClaude 4.5 Haiku ReasoningとGPT-5 Miniが挙げられています。加えてGemini 3 Flash（Google）も同価格帯の有力な競合です。料金体系、スループット、推論品質という3つの軸で具体的な数値を並べ、どの条件下でMercury 2が優位になるのかを明確にします。

入力$0.25/出力$0.75がGemini 3 Flash・Claude Haiku 4.5より安価になる損益分岐点

Mercury 2の料金は、入力トークン100万あたり$0.25、出力トークン100万あたり$0.75に設定されています。これをGemini 3 Flashの入力$0.50/出力$3.00、Claude Haiku 4.5の入力$1.00/出力$5.00と比較すると、入力側でGeminiの半額、Claudeの4分の1、出力側でGeminiの4分の1、Claudeの約6.7分の1という大幅なコスト差があります。

ただし、前述の冗長性傾向を考慮すると、Mercury 2は同じタスクでもより多くの出力トークンを生成する可能性があるため、単純な単価比較だけでは実コストを正確に予測できません。特にGPT-5 Miniは入力単価がMercury 2と同額の$0.25ですが、出力単価は$2.00とMercury 2の約2.7倍です。一方、Mercury 2の冗長な出力傾向を加味すると、タスクあたりの実コストは単価差ほど開かない可能性もあります。実際のワークロードを想定したテスト運用で、タスクあたりの総トークン消費量を計測した上で損益分岐点を判断する必要があります。

毎秒1,196トークン対89トークン対71トークンのスループット差が実タスクに与える影響

スループットの差は、単発の質問応答ではそれほど体感に現れません。しかし、AIがバックエンドで大量のリクエストを処理するプロダクション環境では、この差がシステム全体のパフォーマンスを左右します。Artificial Analysisの計測およびInception Labsの公式発表によるスループット比較では、Mercury 2が毎秒1,196.2トークン、Claude Haiku 4.5（推論有効時）が約89トークン/秒、GPT-5 Miniが約71トークン/秒です。なお、品質比較で参照されるGPT 5.2 Miniとは異なるモデルである点に留意が必要です。

たとえば、エージェントが1つのタスクを完了するために10回のLLM呼び出しを行い、各呼び出しで平均500トークンの応答を生成するケースを考えます。Mercury 2なら各呼び出しが約0.4秒で完了し、合計4秒でタスク全体が終わります。同じタスクをClaude Haiku 4.5で処理すると各呼び出しに約5.6秒、合計56秒です。この14倍の時間差は、ユーザー体験だけでなく、同一時間内に処理できるタスク数にも直結します。サーバーリソースの効率利用という観点でも、同じGPUインフラでより多くのリクエストをさばけるため、インフラコストの最適化にも寄与します。

エンドツーエンドレイテンシ1.7秒対14.4秒対23.4秒が体感品質を分ける実例

スループット（1秒あたりのトークン生成数）とは別に、ユーザーが実際に感じる応答の速さを表すのがエンドツーエンドレイテンシです。Mercury 2のエンドツーエンドレイテンシは1.7秒と報告されており、Gemini 3 Flashの14.4秒、推論有効時のClaude Haiku 4.5の23.4秒と比較して圧倒的な差があります。

この差が特に顕著に影響するのが、音声AIインターフェースです。人間の自然な会話では、発話間のポーズが2秒を超えると不自然さを感じるとされています。Mercury 2の1.7秒という応答時間は自然な会話のリズムに収まりますが、14秒や23秒の遅延は会話体験を根本的に損ないます。同様に、コードエディタの補完機能では、開発者がタイピングのリズムを維持できるかどうかが生産性に直結するため、サブ2秒の応答が「思考を中断しない体験」と「待ち時間による集中力の途切れ」の分岐点になります。リアルタイム性が求められるプロダクトにおいて、レイテンシの絶対値は品質以上にユーザー体験を決定づける場合があるのです。

推論品質が同等でも初回トークン生成12.74秒のTTFTが不利に働くユースケース

Mercury 2の性能を評価する際に見逃しやすい弱点があります。Time to First Token（TTFT）、つまり最初のトークンが生成されるまでの時間です。Artificial Analysisの計測によると、Mercury 2のTTFTは12.74秒であり、同価格帯の推論モデルの中央値0.86秒と比較して大幅に長い数値です。

このTTFTの長さは、拡散モデル特有の初期化プロセスに起因すると考えられます。出力全体の粗いスケッチを生成する初期段階に一定の時間を要するため、最初のトークンが出てくるまでの待ち時間が長くなります。ストリーミング表示でユーザーにリアルタイムの進捗を見せるUIでは、約13秒間「何も表示されない」状態が続くことを意味し、チャットインターフェースのようなユースケースではユーザー体験の低下につながります。一方で、バックエンド処理でレスポンス全体を一括で受け取る非同期ワークフローでは、TTFTよりもエンドツーエンドレイテンシが重要となるため、この弱点の影響は限定的です。

マルチモーダル非対応・画像入力不可というMercury 2の機能制約が選定に及ぼす影響

Mercury 2の機能面での最大の制約は、テキスト入力・テキスト出力のみに対応しており、画像入力（ビジョン機能）に非対応である点です。Claude Haiku 4.5やGPT-5 Miniがマルチモーダル入力をサポートし、画像を含むプロンプトを処理できるのに対し、Mercury 2はテキストベースのタスクに限定されます。

この制約は、モデル選定において決定的な分岐点になるケースがあります。たとえば、ドキュメントOCR、スクリーンショット分析、画像キャプション生成、マルチモーダルRAGといったワークフローでは、Mercury 2を単独で使用することはできません。こうした業務では、画像処理部分にマルチモーダル対応モデルを配置し、テキスト処理部分にMercury 2を配置するハイブリッド構成が現実的な選択肢になります。逆に、テキスト処理に完全に特化したワークフロー、たとえばログ分析、テキスト分類、コード生成、チャットボットバックエンドなどでは、この制約が業務上の障壁になることはほとんどありません。

レイテンシが事業成果を左右するエージェント・音声AI・コーディング領域での活用実績

Mercury 2のスピードとコスト効率が最大の価値を発揮するのは、レイテンシがユーザー体験やビジネスKPIに直結する領域です。Inception Labsは、エージェントループ、リアルタイム音声・検索、インスタントコーディング支援という3つの主要ユースケースを掲げています。すでに複数の企業がMercury 2を本番環境に導入しており、抽象的なベンチマーク値ではなく実際の業務成果として速度の恩恵が報告されています。

マルチステップ・エージェントループで累積レイテンシを5分の1に抑えた導入事例

AIエージェントの本番運用では、1つのタスクを完了するためにモデルが何度も呼び出されるマルチステップのループが一般的です。コードエージェント、ITトリアージ、SecOps自動化、バックオフィス業務のオーケストレーションなど、各ステップでLLMの推論が入るワークフローでは、1回あたりのレイテンシがステップ数分だけ累積します。10ステップのループであれば、1ステップの遅延が10倍に増幅されるわけです。

Mercury 2はこの累積レイテンシを構造的に圧縮します。従来の自己回帰型モデルで各ステップに5秒かかっていた処理が、Mercury 2では1秒未満で完了するケースがあり、ループ全体の処理時間は50秒から10秒以下に短縮されます。Inception Labsはこの効果を「エージェントをデモから信頼できるプロダクションシステムに変える」と表現しています。フィードバックサイクルが短縮されることで、エージェントがより多くのステップを実行でき、途中での制御介入も容易になるため、エージェントの信頼性と制御性が同時に向上するという複合的なメリットが生まれます。

音声AIの応答速度SLAをクリアするためにMercury 2が必要とされる技術的背景

音声AIインターフェースは、すべてのAIアプリケーションの中で最も厳しいレイテンシ要件を持つ領域です。人間の自然な会話リズムを維持するには、ユーザーの発話終了から応答開始までの遅延を極力短くする必要があり、p95・p99レベルでのレイテンシがサービスの品質を決定します。従来の推論モデルでは、推論品質を維持しつつこの厳しいSLA（サービスレベル合意）をクリアすることが技術的に困難でした。

Mercury 2は、推論レベルの品質を自然な音声の発話リズムの中で提供することを可能にしています。リアルタイムの顧客サポート、セールスエージェント、インタラクティブな個別指導、リアルタイム翻訳といったユースケースが具体的に挙げられています。あるAIアバター企業は「リアルタイムで実際の人間と会話するAI動画アバターを構築しているため、低レイテンシは必須要件」としてMercury 2を評価しています。また、音声エージェントを開発する別の企業は「Mercury以外のモデルでは実現できない速度」として導入を決定したと報告しています。

コードエディタ補完で開発者の思考フローを中断させない毎秒1,000トークンの体験差

ソフトウェア開発の生産性において、コード補完やエディタ内アシスタントの応答速度は「便利かどうか」ではなく「フローに留まれるかどうか」という次元の問題です。開発者がコードを書きながら補完候補を待つ場合、数百ミリ秒の遅延は気にならなくても、1秒を超える遅延は思考の流れを中断し、集中力の再構築にさらなる時間を要します。

Mercury 2はコード補完に特化したモデル（Mercury Edit）も提供しており、オートコンプリート（FIM：Fill-in-the-Middle）、Apply Edit（編集適用）、Next Edit Suggestion（次の編集提案）の3つのモードに対応しています。毎秒1,000トークンを超える速度でコードが補完されるため、開発者のタイピングに追従する形で提案が表示されます。Inception Labsは「Mercury completionsは開発者自身の思考の一部のように感じられるほど速い」と述べています。コードレビュー、リファクタリング、デバッグなど反復的なコーディング作業において、この応答速度は生産性の実質的な向上につながります。

SearchBloxが検索製品にMercury 2を組み込みサブ秒レスポンスを実現した構成例

具体的な導入事例として、SearchBlox社のケースが公開されています。SearchBloxはエンタープライズ向け検索ソリューションを提供する企業で、顧客サポート、コンプライアンス、リスク分析、アナリティクス、ECなど多様な業務領域にまたがるデータ検索を手がけています。同社はMercury 2を検索プロダクトに統合することで、サブ秒（1秒未満）のインテリジェント検索レスポンスを実現しました。

SearchBloxの担当者は「Inceptionとのパートナーシップにより、すべてのデータにわたるサブ秒のインテリジェンスが全顧客にとって実用的になった」と評価しています。この事例が示唆するのは、Mercury 2が単独の推論タスクだけでなく、既存の検索パイプラインやRAG（Retrieval-Augmented Generation）アーキテクチャに組み込む形で価値を発揮できるということです。検索クエリの解析、関連情報の抽出、回答の生成という一連のフローにおいて、各ステップのレイテンシが短縮されることで、エンドユーザーが体感する応答速度が劇的に改善される構成例として参考になります。

広告配信最適化やリアルタイム翻訳など低レイテンシが直接KPIに効く5つの業務領域

Mercury 2が特に効果を発揮する業務領域を整理すると、いずれも「レイテンシの短縮が直接的にビジネス指標の改善につながる」という共通点があります。広告配信の領域では、ある企業がMercury 2を活用してキャンペーン実行のインテリジェント最適化をリアルタイムで行い、配信効率とクライアント成果の向上を実現しています。

この他にも、レイテンシがKPIに直結する領域として以下の5つが代表的です。リアルタイム翻訳では発話と翻訳のタイムラグが会話品質を左右し、カスタマーサポートコパイロットでは応答待ち時間が顧客満足度とオペレーター生産性に直結します。インタラクティブな教育・チュータリングでは生徒の集中力維持のために即座の応答が求められ、リアルタイム文字起こし・編集ではライブイベントの速報性が付加価値になります。そして、データ抽出パイプラインでは処理速度がバッチ処理のスループットとインフラコストに直接影響します。いずれの領域でも、推論品質が一定水準を超えていることを前提に、速度が競争優位の決定要因となっている点が共通しています。

OpenAI互換APIで始めるMercury 2導入の具体的手順と技術要件

Mercury 2を自社のプロダクトやワークフローに組み込む際、技術的なハードルは比較的低く設定されています。OpenAI互換のAPIフォーマットが採用されているため、既存のOpenAI SDKやライブラリをそのまま利用できるケースが多く、大規模なコードの書き換えなしに導入を開始できます。ここでは、アカウント作成から実際のAPI呼び出し、パラメータ調整、クラウドプロバイダー経由の利用まで、導入に必要な手順と技術的な注意事項を網羅します。

Inception Platformアカウント作成からAPIキー発行までの5ステップ手順

Mercury 2のAPIを利用するための導入手順は明快です。公式ドキュメントに記載された手順を整理すると、以下の流れで数分以内にAPI呼び出しを開始できます。

1. Inception Platform（https://platform.inceptionlabs.ai）にアクセスし、アカウントを新規作成する。既存アカウントがある場合はサインインする。
2. ダッシュボードの「API Keys」セクションに移動する。
3. 新しいAPIキーを作成し、表示されたキーを安全に保管する。
4. 環境変数にAPIキーを設定する（例：export INCEPTION_API_KEY="your-key-here"）。
5. テスト用のAPIリクエストを送信し、接続を確認する。

この手順はOpenAI APIの利用経験がある開発者にとってはほぼ同じフローであり、新たに習得すべき概念はほとんどありません。APIキーの発行後すぐにリクエストを送信できるため、評価目的でのトライアルも迅速に始められます。

OpenAI互換エンドポイントへの接続で既存コードをそのまま使える移行パターン

Mercury 2のAPIはOpenAI互換フォーマットで提供されているため、既存のOpenAI向けコードベースからの移行が極めて容易です。変更が必要なのは原則としてエンドポイントURL、APIキー、モデル名の3箇所のみであり、リクエストボディの構造やレスポンスフォーマットはそのまま流用できます。

具体的な接続例として、curlコマンドでのリクエストは以下の構成になります。エンドポイントはhttps://api.inceptionlabs.ai/v1/chat/completions、認証ヘッダーにAuthorization: Bearer $INCEPTION_API_KEYを指定し、ボディのmodelフィールドにmercury-2を設定します。Python SDKの場合は、OpenAIクライアントの初期化時にbase_urlとapi_keyを差し替えるだけで接続が完了します。既存のプロンプトテンプレート、システムメッセージ、ツール定義もそのまま使用できるため、移行期間を最小限に抑えつつ速度面の恩恵を即座に得ることが可能です。

max_tokens・temperature・top_pなど主要パラメータの推奨設定値と調整指針

Mercury 2のAPIで利用可能な主要パラメータと、ユースケース別の推奨設定値を把握しておくことで、出力品質を効率的にチューニングできます。チャット（chat/completions）エンドポイントでは、max_tokensの範囲は1〜10,000で、タスクに応じた適切な上限設定が推奨されます。

特にコード補完でのpresence_penaltyデフォルト値が1.5と高めに設定されているのは、コード生成における重複表現を抑制するためです。チャット用途ではtemperature 0.3〜0.7の範囲で創造性と正確性のバランスを取り、推論精度を重視する場合は0.0に近い値を設定するのが一般的な指針となります。

AWS BedrockやAzure Foundry経由で利用する際のプロバイダー選定基準と料金差

Mercury 2はInception Labs自身のAPIに加えて、AWS BedrockやAzure Foundry経由でも利用可能です。エンタープライズ環境では既存のクラウドインフラとの整合性が重要な選定基準となるため、プロバイダー選択によって運用のしやすさが大きく変わります。

Inception APIを直接利用する場合は、最新のモデルアップデートが最速で反映される利点があります。一方、AWS Bedrock経由の場合は既存のAWS IAM認証やVPCエンドポイントとの統合が容易であり、セキュリティポリシーの適合性やネットワーク構成の観点でメリットがあります。Azure Foundry経由も同様に、Microsoft Entra ID認証や既存のAzureリソースとのシームレスな連携が可能です。料金面では、プロバイダーによって上乗せ料金が発生する場合があるため、Artificial Analysisの料金比較ページなどで最新の価格を確認することが推奨されます。自社のクラウド契約、データ所在地要件、既存のインフラ構成を総合的に考慮した上でプロバイダーを選定するのが合理的です。

Mercury Editモデルを活用したFIM・Apply Edit・Next Editの3つのコード編集手法

Mercury 2ファミリーにはチャット・推論用のMercury 2に加えて、コード編集に特化した「Mercury Edit」モデルも含まれています。Mercury Editは、低レイテンシが特に重要なコーディングワークフローのコンポーネントとして設計された小型の拡散型LLMです。

Mercury Editは3つの主要なコード編集モードに対応しています。FIM（Fill-in-the-Middle）はカーソル位置の前後のコードを文脈として受け取り、中間部分を補完するオートコンプリート機能です。エンドポイントは/v1/fim/completionsで、promptとsuffixを指定して使用します。Apply Editは、既存のコードに対する変更指示を受け取り、更新後のコード全体を出力する機能で、エンドポイントは/v1/apply/completionsです。Next Edit Suggestionは、最近の編集履歴とカーソル位置を基に次に行うべき編集を予測する機能で、/v1/edit/completionsエンドポイントで利用できます。いずれもMercury 2と同じ拡散アーキテクチャの恩恵を受けており、極めて低いレイテンシでコード編集支援が行われます。

自社プロダクトの特性別に見極めるMercury 2採用の判断基準と移行時の留意点

Mercury 2は万能のモデルではなく、特定の条件下で最大の価値を発揮する特化型の選択肢です。導入判断にあたっては、自社プロダクトの技術要件、ユーザー体験上の優先事項、既存のモデルスタックとの整合性を多角的に検討する必要があります。ここでは、採用すべきケースと見送るべきケースの判断基準を明確にし、移行プロセスで注意すべき技術的・運用的なポイントを整理します。

スループット優先かTTFT優先かで変わるMercury 2と自己回帰型モデルの適正分配

Mercury 2の採用判断における最も本質的な分岐点は、「スループット（単位時間あたりの生成量）が重要か、TTFT（最初の応答までの時間）が重要か」という優先順位の設定です。Mercury 2はスループットでは他を圧倒する性能を持ちますが、TTFTは12.74秒と同価格帯モデルの中央値0.86秒に対して大幅に長い特性があります。

バックエンドのバッチ処理、非同期エージェントループ、レスポンス全体を一括で処理するパイプラインでは、TTFTの長さは実質的に問題になりません。エンドツーエンドの処理時間でMercury 2が圧倒的に有利になるため、こうしたワークロードでは積極的に採用すべきです。反対に、ストリーミング表示のチャットUI、ユーザーが応答の開始を即座に期待するインタラクティブなインターフェースでは、13秒近い沈黙がUXの大きな障壁になります。このような場合は、フロントエンドの初期応答に自己回帰型モデルを使い、バックエンドの重い処理にMercury 2を充てるハイブリッド構成が合理的な選択肢となります。

画像入力が必要な業務では併用が必須となるマルチモーダルモデルとの組み合わせ方

Mercury 2がテキスト入力・テキスト出力のみに対応している以上、画像やPDFなどの非テキストデータを含むワークフローでは、マルチモーダル対応モデルとの併用が不可避です。この制約を前提に、効率的なハイブリッドアーキテクチャの設計パターンを検討する必要があります。

代表的なパターンは「前処理にマルチモーダルモデル、後処理にMercury 2」という分業構成です。たとえば、ドキュメント処理パイプラインでは、まずClaude Haiku 4.5やGPT-5 Miniで画像・PDF内のテキストを抽出・構造化し、その結果をテキストとしてMercury 2に渡して要約・分類・回答生成を行います。画像解析→テキスト処理という直列構成であれば、前段はマルチモーダル対応モデルの品質を活かし、後段はMercury 2のスピードを活かすという最適な役割分担が実現します。モデル間のインターフェースがテキストで統一されるため、パイプラインの設計と保守もシンプルに保てます。

プロプライエタリモデルゆえのパラメータ非公開リスクとベンダーロックイン回避策

Mercury 2はプロプライエタリ（非公開）モデルであり、モデルの重みやパラメータ数は公開されていません。Inception Labsは具体的なモデルサイズを開示しておらず、ユーザーはモデルの内部構造を直接検証・監査することができません。この点は、オープンソースモデル（LlamaやMistralなど）との大きな違いです。

プロプライエタリモデルへの依存にはいくつかのリスクが伴います。料金改定やサービス仕様の変更が一方的に行われる可能性、モデルのアップデートによる出力品質の変動、最悪の場合はサービス終了のリスクです。これらのリスクを軽減するためのベンダーロックイン回避策として、OpenAI互換APIを活用した抽象化レイヤーの設計が有効です。アプリケーションコードがOpenAI互換のインターフェースを介してモデルにアクセスする構成にしておけば、Mercury 2から別のモデルへの切り替えがエンドポイントURLとモデル名の変更のみで完了します。また、複数モデルへの分散配置やフォールバック機構の実装も、ベンダーリスクの軽減に有効な手段です。

ファインチューニング（SFT・RLHF）パイプラインとの互換性を検証する際の確認項目

エンタープライズでのAI導入では、汎用モデルをそのまま使うのではなく、自社データでファインチューニングして特定タスクの精度を向上させるケースが一般的です。Inception Labsは、Mercury 2がSFT（Supervised Fine-Tuning）およびRLHF（Reinforcement Learning from Human Feedback）パイプラインとの互換性を持つと明記しています。

ただし、ファインチューニングの実行環境や手順の詳細は現時点で限定的にしか公開されておらず、エンタープライズ向けの個別対応として提供されている段階です。導入を検討する際には、以下の項目を事前に確認することが推奨されます。まず、ファインチューニング用データの形式要件（入力フォーマット、トークナイゼーション仕様）です。次に、ファインチューニング後のモデルのホスティング方法（API経由のみか、オンプレミスデプロイが可能か）を確認します。さらに、ファインチューニングにかかるコストと所要時間の見積もり、そして性能評価の方法（ファインチューニング前後のベンチマーク比較）についても、Inception Labsの営業チームまたは技術サポートと事前に協議しておくべきです。

Mercury 1からの移行ユーザーが報告した品質変動と移行期に推奨されるテスト手順

Mercury 2はMercury 1（Mercury Coder）の後継モデルですが、アーキテクチャの進化に伴い、出力特性に変化が生じている可能性があります。Mercury 1は主にコード生成に特化していたのに対し、Mercury 2は汎用的な推論能力を備えた上位モデルとして設計されており、得意領域や出力パターンが異なります。Inception Labsはmercury 1を既存顧客向けに引き続きサポートしていますが、新規利用はMercury 2への移行が推奨されています。

移行期のテスト手順としては、以下のプロセスが合理的です。まず、現行のMercury 1（またはその他のモデル）で処理している代表的なタスクを10〜20件抽出し、同一プロンプトでMercury 2の出力と比較します。次に、品質面の差異（精度、指示追従性、フォーマット遵守）を定量的に評価します。さらに、出力トークン数の変化を記録し、冗長性の傾向がコストに与える影響を試算します。最後に、本番環境のトラフィックの一部（5〜10%）をMercury 2に段階的に振り分けるカナリアリリースを実施し、本番負荷での品質安定性とレイテンシを検証した上で全面移行を判断します。このプロセスにより、移行によるリスクを最小化しつつ、Mercury 2のスピードとコスト効率の恩恵を段階的に享受できます。