AIモデル・業務設計

Mercury 3はどこまで待ち時間を減らせるか。速いAIを業務で試す前に

株式会社本質 · 2026.10.20 · 約4分

「この注文は、いつ届く？」。AIがすぐに返事をしても、配送状況が出てくるまで画面を見続けるなら、担当者の待ち時間は残ります。知りたいのは、文字が流れる速さだけではなく、回答を確認して次の作業へ進めるまでの時間です。

Inceptionは2026年10月19日、拡散モデルを使う言語モデル「Mercury 3」を発表しました。同社が公表した生成速度は、NVIDIA GPU上で毎秒1,068トークン。これは提供元の公表値で、本質が業務環境で測定した結果ではありません。公式発表

Mercury 3はすでに同社のAPIから利用でき、公式ドキュメントには呼び出し例もあります。問い合わせ対応や、検索と回答を繰り返す業務で試せる新しい選択肢です。Quick Start

本質としては、こうした高速なモデルを評価するときこそ、「誰が、何を待っているのか」を先に決めたいと考えます。

生成が5秒から1秒になったら、仕事は何秒早くなる？

ここからは考え方を整理するための仮想例です。社内の問い合わせに答える処理が順番に進み、資料の検索に2秒、回答の生成に5秒、通信や画面表示などに1秒かかるとします。全部が終わるまで8秒です。

生成だけを1秒にできれば、合計は4秒になります。モデルの生成は5倍速くても、この例で待ち時間が短くなるのは半分です。検索や通信が長い業務なら、モデルを替えた効果はさらに小さくなるかもしれません。

反対に、一つの仕事でモデルを何度も呼ぶ場合は、一回ごとの短縮が積み重なります。問い合わせを読み、対象の注文を探し、配送システムを確認し、回答を組み立てる。そのうちどの段階でAIの応答を待っているかによって、試す価値は変わります。

拡散型のMercury 3は、途中のテキストを繰り返し整え、最終回答に近づけていく方式を使います。公式文書によると、ストリーミングでは、その整えたテキストをブロック単位で出力します。1トークンずつ文字が増える見え方とは異なります。Streaming & Diffusion

画面に最初の文字が出た時刻は、使い心地を確かめる手がかりです。ただ、「確認します」と出ただけでは、利用者の疑問は解消していません。配送日とその根拠がそろうまでの時間も、別に残す必要があります。

試験では、質問を送った時刻、使える回答が初めて出た時刻、回答が完成した時刻を記録する。その途中で外部システムを呼ぶなら、呼び出しから結果が戻るまでの時間も分けます。そうすれば、改善すべき場所がモデルなのか、検索なのか、画面の実装なのかを話せます。

速度だけを競う試験にすると、必要な説明を省いた短い回答が有利になりがちです。配送日を答えられたか、古い情報を断定していないか、情報がないときに担当者へ引き継げたか。同じ質問について、速さと回答の中身を一緒に確認したいところです。

もう一つ、移行時に見落としやすい違いがあります。公式文書では、推論の設定は「instant」、「low」、「medium」、「high」の4段階。指定を省くとMercury 3は「low」、旧Mercury 2と2.5は「medium」になります。Reasoning Efforts

旧版を使っている場合、モデル名だけ替えた比較では、推論の設定まで変わる可能性があります。設定を記録せずに「速くなった」と判断すると、複雑な問い合わせで何が変わったのか追いにくくなります。

まずは、実際に使う日本語の問い合わせを小さな一組にして、同じ資料、同じ外部処理、同じ回答要件で試す。短い質問だけでなく、確認を一度挟む質問や、すぐには答えられない質問も含めます。モデルごとの設定と回答の品質を残し、中央値に加えて、遅かったケースも見ておくと判断しやすくなります。

Mercury 3の速さが生きるのは、利用者が待っていた部分を短くできたときです。導入の判断材料には、トークンの速度とともに「この問い合わせなら、何秒早く次の仕事へ移れたか」を置きたいと考えます。

AIの待ち時間や確認作業が気になる業務を、流れの整理から一緒に見直します。AI実装・業務変革の支援内容