文章を生成せず、画像と文章から判定する「d1-ultra」の仕組み｜2026年10月18日版
AIに問い合わせの振り分けや画像の確認を任せるとき、長い回答文が必要とは限りません。Liquid AIが10月15日に発表した「d1-ultra」は、文章や画像を受け取り、選択肢や確率を返す判定用のモデルです。
特徴は、回答の文章を生成せずに判定結果を返すこと。 チャット画面で説明を読む用途よりも、問い合わせを担当部署へ送る、といったシステムの分岐に向いています。2026年10月18日・日本時間時点の公式情報から、仕組みと導入時の確認点を整理します。
- 入力はテキストと画像。出力は二択、選択肢、尺度に沿った評価です。
- APIから確率を受け取り、後続のプログラムで処理を分けられます。
- 導入の判断材料は、正答率に加えて「確率の信頼性」と「質問ごとの課金」です。
d1-ultraは「決められた問い」に答えるモデル
自由な文章を書く代わりに、あらかじめ定義した問いを評価します。
Liquid AIの発表によると、d1-ultraはテキストと画像を読み、1回の順伝播で確率を返します。順伝播とは、入力をモデルに通して出力を計算する処理です。回答文のトークンを順番に生成する工程を持ちません。
この違いは、出力を受け取る側に効きます。たとえば問い合わせ対応では、「請求」「配送」「アカウント」といった候補を先に用意できれば、返ってきた選択結果を担当窓口に対応づけられます。
ただし、文章を生成しないという仕様だけで、あらゆる処理が高速になるとは断定できません。実際の待ち時間には、入力の大きさや通信も関係します。
返せる答えは3種類
公式ドキュメントでは、次の形式が用意されています。
- Noul： 「はい」に相当する確率を0〜1で返す二択の問い。
- Choice： 定義した候補から選択し、各候補の確率分布も返す問い。
- Score： 順序のある評価基準に沿って、尺度上の位置を返す問い。
Choiceなら、最有力の候補だけでなく、次点にどれだけ確率が残っているかも見られます。担当部署を一つに絞れない問い合わせを、人の確認へ回す設計につなげられます。
APIでは、判定基準をアプリ側が用意する
使う側が決めるのは、入力する情報と、何を判定してほしいかです。
APIの基本要素は、モデル名を指定するmodel、判断材料を入れるstate、質問を定義するquestionsです。画像を使う場合はimagesも渡します。モデル名にd1-ultraを指定し、POST /decisions/v1/systemoneへ送信する形です。公式ドキュメント
たとえば問い合わせの振り分けを試すなら、次のような準備が必要になります。
- 「請求」「配送」など、送り先の候補を決める。
- 各候補に含める問い合わせの範囲を書く。
- 正しい送り先を付けた過去の問い合わせで評価する。
- 判断が曖昧な場合の確認先を決める。
ここで難しいのは、APIの接続よりも分類の境界です。「配送された商品の返金」は配送担当か、請求担当か。社内でも判断が分かれる入力は、候補名だけでは整理できません。
判定基準と、迷った場合の扱いを先に決める。 これが、返ってきた数値を業務に使える形へ変える作業になります。
「確率90％」を、そのまま正しさの保証にしない
d1-ultraの発表で、もう一つの焦点になっているのが確率の校正です。
Liquid AIは、正答率だけでなく、モデルが返す確率の信頼性を高める訓練を行ったと説明しています。性能比較も公開していますが、発表元による評価として読む必要があります。公式発表
校正を実務に引きつけると、「高い確率を付けた判定が、実際にも高い割合で当たっているか」という問題です。仮に90％前後の値を付けた事例が多数あるなら、その集合の正答率と比べて、過信や過小評価がないかを調べます。
個々の回答に90％と表示されても、その案件が正しいと保証されたわけではありません。日本語の省略表現、社内の製品名、撮影条件が異なる画像でも同じ傾向が保たれるかは、手元のデータで確認する必要があります。
評価では、少なくとも次を分けて数えると判断しやすくなります。
- 自動処理へ回した件数と、その中の誤判定数。
- 人の確認へ回した件数。
- 特定の分類だけで起きている見落とし。
全体の正答率が高くても、重要な問い合わせだけを取り違えていれば、運用上の効果は変わります。
料金は「1回のAPI呼び出し」より質問数を見る
費用を見積もるときは、一つのリクエストに何問入れるかが重要です。
発表時の料金は、入力100万トークンあたり0.042米ドル。出力トークンは生成しません。ただし、各質問について、テキストと渡した全画像が課金対象になります。 複数の問いをまとめて送っても、入力料金が一問分になるわけではありません。公式発表
実務では、次の順番で見積もると取り違えを減らせます。
- 一件あたりの入力文と画像の量を把握する。
- 一件につき必要な質問数を数える。
- 再判定や失敗時の再送も含めて月間件数を置く。
提供経路については、発表時点ではLiquid APIで利用可能と案内されていました。確認時点の公式ドキュメントには、OpenRouterとVercel AI Gatewayも掲載されています。接続先を選ぶ際は、その経路での料金と利用条件を改めて確認してください。提供状況の記載
日本の開発現場では、まず一つの分岐で試す
導入候補になるのは、答えの範囲を定義できる処理です。
問い合わせの担当窓口選択、確認が必要な入力の抽出、優先度の付与などで、現在の処理と比較できます。これは導入方法の提案であり、日本語業務での性能が確認されたという意味ではありません。
試すなら、最初はAIの判定で実際の送り先を変えず、従来の判断と並べて記録する方法が現実的です。取り違えた事例を確認すれば、モデルの誤りなのか、分類基準の曖昧さなのかを切り分けやすくなります。
画面に結果を出す場合も、数値だけでは利用者が迷います。「自動振り分け済み」「担当者の確認待ち」といった処理状態を示し、誤った分類を直せる操作を用意すると、確認作業につながります。
継続ウォッチ
今後見るべきなのは、順位だけでなく、実際の入力条件で使えるかどうかです。
- 日本語での校正： 高い確率を返した案件が、実際にどの程度正しいか。
- 曖昧な入力への対応： 候補外の問い合わせや、複数の用件を含む文章をどう扱えるか。
- 運用全体の費用： 質問数、再送、人の確認まで含めて、既存処理より負担を減らせるか。
d1-ultraを評価する最初の一歩は、文章を生成させている既存処理の中から、答えが数個の候補に収まる箇所を一つ探すことです。その分岐で、誤判定と確認件数がどう変わるかを測れば、置き換える価値を具体的に判断できます。