文章を生成せず判断するAI、Liquid AI「d1」の仕組みと端末実行の意味｜2026年10月9日版
問い合わせを担当部署へ振り分けるだけなら、AIに長い回答を書かせる必要はない。Liquid AIが公開した「d1」は、入力と質問を読み、選択肢ごとの確率や評価値を返す判断用モデルだ。文章の生成を省き、必要な判断を一度の推論で取り出すことが設計の中心にある。
同社は10月7日、端末側で動かせる「d1-3B」と、実験段階の「d1-omni-600M」の重みを公開した。2026年10月9日、日本時間時点の公式資料から、仕組みと導入時の確認点を整理する。
- 出力は自由な文章ではなく、はい／いいえ、選択肢、段階評価。
- d1-3Bはテキストと画像を扱い、公開重みを使ってローカル実行できる。
- 最短の処理時間は入力条件付き。長文や画像では測定値が変わる。
d1は何を省いて判断を速くするのか
d1は、候補となる答えを先に定義して使う。
Liquid AIの公式説明では、入力となる文章や画像と、一つ以上の質問を与えると、単一のフォワードパスで答えの確率を返す。フォワードパスとは、入力をモデルに通して結果を計算する処理のことだ。回答文をトークン単位で順に生成する工程はない。
質問形式は三つに分かれる。
- noul：はい／いいえの質問に対し、「はい」の確率を返す。
- choice：名前を付けた選択肢から選び、各候補の確率を返す。
- score：段階ごとの説明を与え、確率で重み付けした評価値を返す。
例えば問い合わせ処理なら、「返金を求めているか」「請求・技術・不正利用のどの担当か」「どれほど急ぐか」を別々の質問として定義できる。これは公式の実装例にも使われている組み合わせだ。
この方式が役立つのは、後段のプログラムが決められた値を必要とする場面だ。回答文から部署名を抜き出す処理を挟まず、選択結果を分岐条件として扱える。
ただし、返された確率を、そのまま業務上の正解率と受け取ってはいけない。例えば「高い確率なら自動処理、それ以外は人に渡す」という運用には、自社データで閾値を確かめる作業が必要になる。
公開モデルは画像対応と小型化で分かれる
今回の公開で、判断用モデルを自分の実行環境に組み込む選択肢が増えた。
10月7日の公開発表によると、二つのモデルは異なる土台から作られている。
d1-3B：画像と言葉を合わせて判断
d1-3Bは、画像言語モデル「LFM2.5-VL-3B」を基にしたモデルだ。モデルカードでは総パラメータ数を31.2億、コンテキスト長を32,768トークンとしている。
画像と説明文を同じ入力に含められるため、画像について選択式の質問をする処理にも使える。一般的なチャットモデルのように、説明文を自由に書く用途とは出力設計が異なる。
d1-omni-600M：音声にも対応する研究版
d1-omni-600Mは、双方向エンコーダーを土台に画像・音声エンコーダーを追加した小型モデルだ。入力は「テキストと画像」または「テキストと音声」に対応する。
こちらは初期の研究リリースとして公開されている。公開発表では処理速度の数値が示されていないため、モデルが小さいことだけを根拠に、d1-3Bより速いと判断することはできない。
「8ミリ秒」はどの条件で出た数値か
速度を見るときは、最短値よりも実際に渡す入力に近い測定列を読む必要がある。
d1-3Bのモデルカードでは、NVIDIA RTX 4090で一つの質問を処理する時間を8ミリ秒と報告している。同じ表でも、3,400トークンの入力では102ミリ秒、384ピクセル画像の条件では17ミリ秒となる。
さらに、8ミリ秒の測定にはCUDAグラフを使うコンパイル設定が含まれる。コンパイルなしでは一つの質問が16ミリ秒となり、新しい入力形状の初回呼び出しには追加の準備時間がかかるという。
つまり、単一パスでも入力を読む計算は残る。長い記録を渡す業務と、短い問い合わせを分類する業務を、同じ最短値で見積もることはできない。
なお、これは開発元による測定だ。日本語の問い合わせを前処理して結果を保存するまでの時間や、複数利用者が同時に使う条件での応答時間を直接示すものではない。
日本の開発現場ではどこから試せるか
導入候補になるのは、答えの種類を限定できる処理だ。
以下は実装上の用途案であり、日本での導入実績を示すものではない。
- 問い合わせの振り分け：部署の定義を与え、日本語の問い合わせを分類する。
- 文書処理の前段：対象外の文書を除外し、詳しい解析が必要なものを次の処理へ渡す。
- 画像確認の補助：条件を満たすかを判定し、曖昧なものを担当者の確認に回す。
公開重みを使う方式なら、自社の端末やサーバー内で実行する構成を検討できる。ただし、公開重みがあることと、利用条件が無制限であることは別だ。両モデルの配布ページには「lfm1.0」ライセンスが表示されているため、採用前に条件を確認したい。
実装もチャット用の呼び出しをそのまま置き換える形ではない。公式例は専用の system_one を使い、質問形式と候補を渡す。必要な依存関係は transformers>=5.14 とされ、モデル付属コードを読み込む trust_remote_code=True を使用する。運用環境へ入れる際は、読み込むコードとモデルの版を固定して確認するのが具体的な作業になる。
継続ウォッチ：日本語精度と保留条件を確かめる
d1の価値は、文章を書く工程が不要な処理を、判断専用の出力で組み立てられる点にある。採用を決める材料は、短いデモの速度だけでは足りない。
次に確認したいのは三点だ。
- 日本語での誤分類：敬語、省略、複数の依頼を含む文章で、担当部署を正しく選べるか。
- 入力全体を含む時間：長文、画像、初回起動、同時実行を含めても必要な応答時間に収まるか。
- 人に戻す条件：確率が拮抗した場合や候補外の依頼を、無理に自動処理しない設計にできるか。
まずは実際の問い合わせに正解ラベルを付け、現在の分類処理と同じ条件で比較する。速さとともに「どの誤りを見逃すのか」を測ることが、業務へ組み込めるかを判断する次の一歩になる。