Cloudflareは2026年10月19日付の公式発表で、抽出モデルClairicのPreview提供をWorkers AIで始めたと説明しました。モデル名は@cf/cloudflare/clairicです。発表時点ではWorkers AI上のホスト版を利用でき、重みの公開は今後の予定でした。[1]
Clairicは、文書から文字列や数値を取り出すほか、入力中の事実から計算した値や、まだ確定していない値の推定も返します。TypeSafeのJevやCloudflareのClefが事前に用意した質問や選択肢に対する判断を返すのに対し、Clairicは候補をあらかじめ列挙せずに具体値を扱います。[3] ただし、型に合った出力であることと、内容が正しいことは別です。[2]
原文にある値と、計算・推定した値を分ける
同じAPIから返る値でも、根拠の種類は異なります。[9]
| 処理 | 値と入力の関係 |
|---|---|
| 抽出 | 請求書番号など、入力に明記された値を取り出します。 |
| 計算 | 商品代金と送料の合計など、入力中の事実から値を導きます。答えそのものが原文にあるとは限りません。 |
| 推定 | 支払われるまでの日数など、入力だけでは確定しない値を予測します。 |
| 予測 | 今後の各日の値など、系列の将来の値を返します。 |
text型で文字列を抽出すると、入力中の開始・終了位置を示すspanが付きます。これにより、返された文字列が入力stateのどの範囲に対応するか確認できます。一方、計算で求めた合計や将来の推定値は、原文の同じ箇所をコピーした値として扱えません。[10]
入力と、欲しい項目の指定を分ける
リクエストには、読む対象のstateと、返してほしい項目を定義するfieldsを渡します。項目名と型を指定し、必要に応じて単位、小数桁、指示を追加します。[4]
たとえば、請求書番号はtext、送料込みの合計はnumber、支払期限はdateと指定します。合計に税や送料を含めるか、どの日付を基準にするかは、モデル任せにせず、入力と指示で明らかにします。[8] 公式モデル仕様には、請求書の値と支払期限を指定するリクエスト例があります。
Cloudflareは、文章をトークンごとに生成せず、入力と項目を一度のforward passで処理する方式だと説明しています。ただし、入力stateとfieldsが一度の処理に収まらない場合、fieldsを複数の並列パスに分けて処理します。[6, 7]
同社は返品対応メールを例に、Clairicが値を取り出して修理費を推定し、Clefが返金か修理かを選び、GLM-5.3が返信を作る構成も示しました。入力の整理、判断、返答を別々のモデルに割り当てる使い方です。[21]
nullと確信度を、別々に確認する
単一値を抽出・計算するフィールドでvalueがnullの場合、モデルは入力から答えを定められないと判断しています。情報が欠けている場合だけでなく、モデルが見つけられなかった場合も含みます。入力に存在しないことを証明する値ではありません。[12]
応答に付く次の項目は、それぞれ別の情報を表します。
| 項目 | 表すこと |
|---|---|
p_null | 入力だけでは値を決められないとするモデルの確率です。[13] |
confidence | 回答に付く確信度のスコアです。p_nullとは別の指標です。[14] |
guess | nullでなければモデルが選んだであろう候補です。[15] |
公式の請求書の応答例では、存在しない発注番号のvalueはnullですが、guessには請求書番号が入り、confidenceは高い値になっています。確信度だけを見てguessを採用すると、別の番号を発注番号として扱うことになります。
アプリケーション側では、まず実際に返されたvalueを確認し、値が欠けている場合の扱いを決める必要があります。spanで元の文字列を確認できても、その箇所が求めた項目に該当するかは別に確認します。支払いの実行など結果の影響が大きい処理では、別の証拠との照合や人による確認を組み合わせます。[11]
80%区間と、モデルが苦手な計算を読む
推定や予測では、中央値とともにp10からp90までの中央80%区間が返ります。[5] これは予測分布の範囲であり、個別の結果が必ずその範囲に収まる保証ではありません。入力情報が乏しくても推定値が返る場合があり、指定した最小値・最大値の範囲外に実際の値が生じる可能性もあります。[16, 17]
Cloudflareは、多段の依存計算や大きな表の集計には弱さがあり、未知のデータでは予測区間が狭くなり過ぎる場合もあると説明しています。[18, 19] 時系列予測はまだ基本段階です。同社は一般的なパターンの把握を用途として挙げ、詳細な長期予測には向かないと説明しています。[20] 帳票処理では、文字列や数値を取り出した後の合計や照合をコードで行う分担が考えられます。
自社データで、値の正しさと見直し先を確かめる
以下は、本記事で提案する確認方法です。正解や実際の結果が分かる自社の検証用データを用意し、次の点を確かめます。
- 原文と項目を照合する。 抽出した文字列だけでなく、
spanの周囲も見て、請求書番号と発注番号のような似た項目を取り違えていないか確認します。 - 欠損と推定を分ける。 欠けた値を
guessで埋めず、確認先を決めます。予測区間については、実際の結果がどの程度その区間に入るかを自社の対象データで調べます。 - 計算を検算する。 単位や日付の基準を固定し、合計や期日はコードでも照合します。実際に扱う日本語やOCRの誤読、曖昧な記載を含めて評価し、用途ごとに自動処理と確認の分担を決めます。
