AIに画像や問い合わせを渡す場面では、いつも長い説明文が欲しいわけではありません。「この基板は不良か」「この問い合わせはどの窓口か」「人の確認を挟むべきか」――必要なのは、次の処理を決めるための短い判断です。
Liquid AIが発表したd1は、テキストだけでなく画像も受け取り、文章を生成せずに答えごとの確率を返す判断モデルです。チャットAIの代わりになる製品というより、生成AIやワークフローの手前で、選択・分類・採点を担う部品として見ると役割がつかみやすくなります。
d1の値は「もっともらしい説明」を作ることではなく、決めた選択肢の確率を返すことです。
だからこそ、速い自動処理に組み込めます。ただし、確率が高いだけで重要な承認まで自動化してよいわけではありません。
d1は、生成モデルと何が違うのか
Liquid AIの発表によると、d1はテキスト、画像、または両方と質問を受け取り、1回のforward passで各回答の確率を返します。出力トークンを生成しないため、返すものは会話文ではなく、次の処理で使える判断値です。テキストの判断は同社発表で200〜300ミリ秒とされます。
たとえば商品の写真に傷があるか、問い合わせを請求・技術・配送のどこへ送るか、といった場面です。回答の文章を要約してから別のプログラムで読むより、判定結果を直接扱えるため、画面の分岐や担当者の振り分けを組み立てやすくなります。
d1は「賢い文章を書くAI」と競わせるより、決められた候補の中で次の一手を選ぶAIとして置くと向いている仕事が見えます。説明文、報告書、複雑な対話を出す役は、生成モデルに任せる設計が自然です。
3つの質問型で、何を返せる？
d1が扱う形式は3つです。Noulは「不良があるか」のようなはい／いいえを0〜1の確率で返し、Choiceは複数の候補から最適なラベルを選びます。Scoreは段階評価の確率を加味して、尺度上の位置を返す仕組みです。公式説明では、同じ入力に複数の質問をまとめて送れる点も案内されています。
この違いは実装で効いてきます。配送先の選択ならChoice、目視検査の一次判定ならNoul、対応の緊急度ならScoreというように、先に欲しい出力の形を決められます。プロンプトで自由に文章を書かせる前に、判断をデータ型として固定する発想です。
AIエージェントが必要なツールを選ぶ仕組みは、Pi 1.0の記事とも接点があります。d1はツールを実行する本体ではありませんが、「どの選択肢へ進むか」を速く返す役として、前段に置けます。
画像を見て、どこまで実務に寄せられる？
d1の画像対応で想定される用途の一つが、工場の視覚検査です。Liquid AIは公開デモで、回路基板など4種類のラインを対象に、良品・不良品を85〜97%で分類したと説明しています。ただしこれは同社が示したデータセットとデモ条件での結果であり、現場のカメラや部品で同じ精度を約束する数字ではありません。
画像はbase64のdata URLとして送る例が公開されており、既存の検査カメラ画像や撮影済み写真を判断材料にできる構成です。画像を文章化してから読ませる工程を減らせる一方で、照明、撮影距離、良品・不良品の定義が変われば、判定の意味も変わります。
「画像を読める」ことと「不良品を自動で確定できる」ことは別です。最初は人が検品した正解データと並べ、見逃しと誤検知のどちらを重く見るかを決めてから、しきい値を運用に合わせるのが安全です。
速さや安さの数字は、どう読めばいい？
Liquid AIは6つのアプリケーションでGPT-6.1 SolやClaude Opus 5.5と比較し、d1が4つで同等以上、費用は19分の1から200分の1だったと公表しています。ですが、同じ発表には、比較が2026年10月5日に同社のcomparison script、既定のreasoning設定、リスト価格で行われたことも明記されています。
つまり、これは導入前の候補を絞る手掛かりであって、自社の請求書や検査画像で得られる削減率ではありません。特に複数の質問を一つの入力に掛ける場合は、画像も各質問の入力として課金されると説明されているため、質問数と画像サイズを含めて試算する必要があります。
確率をそのまま承認・拒否の境界にしないことが重要です。
返金、採用、品質保証、権限付与のように誤りの影響が大きい処理では、低信頼度だけでなく、影響の大きい対象を人へ回すルールを先に決めましょう。
判断を速くしても、責任まで渡さない
d1は、生成AIの出力を短くしただけのモデルではありません。文章を作る前に「どの選択肢か」「どの程度か」を確率で返すことで、問い合わせの入口、画像検査の一次判定、エージェントの分岐を軽くする役を狙っています。
一方、判断の後には実行権限が続きます。AIエージェントの権限をどこで止めるかを扱ったNVIDIA Open Agent Safety Platformの記事のように、速い分類と安全な実行は別に設計したいところです。まずは影響の小さい振り分けから精度・遅延・人の確認率を測り、任せる範囲を少しずつ広げる。それがd1を実務に生かす近道になりそうです。
d1を試すときは、生成モデルを丸ごと置き換えるのではなく、「回答を生成する前に決める必要がある一問」を探すのがおすすめです。問いと選択肢を狭くできるほど、評価すべき誤りも運用の責任範囲も見えやすくなります。
