Cloudflareは2026年10月19日、文書から金額や日付などを取り出すAIモデル「Clairic」を、Workers AIでプレビュー公開した。文章を一語ずつ生成する代わりに、指定された型の値を返し、簡単な計算や将来値の推定も担う。顧客対応のデモでは、抽出と判断を専用モデルに任せることで、すべてをLLMで処理する構成より時間と費用を削減できたという。ただし、日付として正しい形をしていることと、正しい日付を読み取れたことは別だ。どの仕事をLLMから移し、どこに確認を残すかが、Clairicを使う際の判断になる。
値を返すClairic、選択肢を選ぶClef
Clairicが返すのは、注文番号や請求額といった、その場の入力によって変わる値である。Cloudflareが10月1日に発表した「Clef」は、あらかじめ用意した選択肢から判断を返すモデルだった。「返金か修理か」は選択肢を並べられるが、「修理にいくらかかるか」はそうはいかない。Clairicは後者を扱う役目を担う。
Cloudflareは両者を、入力を一度処理して答える「System One」型のモデルとして整理している。Clairicに渡すのは、読み取る本文を入れたstateと、欲しい項目を定義したfieldsだ。各項目に数値や日付といった型を指定し、必要に応じて自然文の指示を添える。回答文や推論の過程をトークン単位で生成せず、指定した項目を並列に処理する設計である。
公式の顧客メール例では、商品代649.00ドルと税52.10ドルから支払総額701.10ドルを求め、9月28日の配達から10月9日の連絡までを11日と算出する。総額も経過日数も、メールにそのまま書かれた数字ではない。一方、注文番号や破損箇所は、原文の文字列とその位置を返す。アプリ側で該当箇所を表示できるため、抽出結果を元の文脈へ戻して確かめやすい。
推定には別の出力を使う。修理費などを尋ねるestimateは、指定した最小値と最大値の間で予測分布を返し、中央値と中央80%の区間を示す。forecastなら、時系列の各将来ステップについて値と区間を受け取れる。読み取った事実、入力から計算した値、まだ分からない結果の予測を、同じ「数字」として扱わずに済む仕組みだ。
19.3秒への短縮後、待ち時間はどこに残るか
Cloudflareは、破損した商品の顧客対応を、Clairic、Clef、文章生成用LLMの順に処理するデモで比較した。Clairicがメールから支払額や破損内容を取り出して修理費を推定し、Clefが会社の規定に沿って返金か修理かを判断する。最後にGLM-5.3が返信を書く構成である。比較相手は、同じメールと規定、プロンプトを使い、全段階をGLM-5.3に任せる構成だ。
| 処理 | Clairic・Clef・GLM-5.3の分業 | 全段階をGLM-5.3で処理 |
|---|---|---|
| 値の抽出 | 0.46秒 | 16.1秒 |
| 対応の判断 | 0.22秒 | 21.9秒 |
| 返信の生成 | 18.6秒 | 16.4秒 |
| 全体の所要時間 | 19.3秒 | 61.7秒 |
| 100万件当たりの費用 | 6,032ドル | 11,740ドル |
出典：Cloudflareの10月19日発表、顧客対応デモの比較表。全体時間は同社の掲載値を用いた。各段階の表示値の合計とは一致しない場合がある。
同社によれば、分業により全体時間は約69%、費用は約49%減った。しかも、この試行では両構成とも事実の抽出と判断に正解しており、違いは主に処理の速さと費用に現れている。開発元が示した一つの業務例であり、あらゆる文書やLLMに対する性能差を測ったものではない。
Cloudflareの比較デモでは、分業後の全体19.3秒のうち返信生成18.6秒が約96.4%を占める。これは上表の18.6を19.3で割って算出した比率である。抽出と判断を合わせて1秒未満に縮めた後は、文章を生成する工程が待ち時間の大部分を占めるわけだ。
つまり、Clairicの速さは、業務のどこまでを値と判断で済ませられるかによって効き方が変わる。数値を次のシステムへ渡す処理なら文章生成を省けるが、顧客への返信が必要ならLLMの時間が残る。モデル単体の速度だけでなく、最終的に何を出力したいかから工程を組む必要がある。
型の保証と、答えの正しさを分ける
公式の抽出モデル解説は、値が見つからない場合と、未知の値を推定する場合を区別している。単一の値を抽出・計算する項目がnullを返すのは、入力だけでは答えを決められないとモデルが判断した場合だ。情報が本当に欠けていることもあれば、モデルが見落としていることもある。nullを「原文に存在しない証明」と読むことはできない。
顧客メール例の追跡番号はnullとなる一方、guess欄には、代わりに選んだであろう税額の文字列が残っている。この候補を確定値として使ってしまえば、欠損を示す仕組みをアプリ側で打ち消すことになる。結果に付く確信度のconfidenceと、値を決められない確率を表すp_nullを、どの値を再確認するかの判断に使う設計だ。
ところが、推定や予測は材料が乏しくても値を返す。抽出時の欠損判定があるからといって、修理費の予測にも十分な根拠があるとは限らない。指定した範囲に収まるという制約も、現実の結果をその範囲に収めるものではなく、返せる値を制限しているにすぎない。
Cloudflare自身も、プレビューの注意点を次のように説明している。
「このアーキテクチャは、すべての回答の形式を整えるが、必ずしも正解にするわけではない」（Cloudflare、原文から訳）
予測区間にも同じ注意が要る。p10からp90までの区間は、予測分布の中央80%を表す。将来の実測値が必ずその中に入る保証ではなく、同社は、見慣れないデータでは区間が狭すぎる場合があると認めている。
発表には、米運輸保安局（TSA）が空港で検査する人数の翌日予測を、21日連続で評価した例もある。同社による平均誤差は3.3%で、21日中17日の実測値が80%区間に入った。ただし、区間を外れた4日のうち3日はColumbus Dayの祝日週末に当たり、過去数週間から見込める人数を上回ったという。系列に表れない祝日要因まで読めるわけではなく、専用の時系列モデルを置き換える結果とは受け取れない。
計算と確認を残して導入する
Clairicの料金は入力100万トークン当たり0.10ドルで、出力トークンへの課金はない。Workersのenv.AI.run()かREST APIから、@cf/cloudflare/clairicとして利用できる。フィールド数に上限は設けていないものの、入力と項目定義が一度の処理に収まらない場合は、複数の並列パスに分けて結果をまとめる。項目を際限なく増やしても常に一度の計算で済む、という意味ではない。
画像も最大4枚まで渡せるが、PNG、JPEG、WebPを埋め込む方式で、画像のURLを指定する方法には対応していない。文書処理への導入では、欲しい項目の定義とともに、手元の資料をどう入力するかを決める必要がある。
計算の役割分担にも線を引いている。Cloudflareは、合計や日付差といった1〜2段階の計算は良好とする一方、長い依存関係を持つ計算や、多数の表の行を集計する処理はまだ苦手だと説明する。その場合はClairicに必要な値を取り出させ、計算自体はコードで行う方針を勧めている。推定には比較事例や履歴が必要で、長期の予測を細かく当てる用途にも向かない。
現在の提供はプレビューであり、モデルのウェイト公開は今後の計画だ。導入を判断する際は、自分の文書で必要な値が拾えるかに加え、欠損を見落とさないか、推定区間が実際の結果と整合するかを確かめたい。支払いなど結果の誤りが大きく響く処理には別の証拠や人の確認を残し、その条件を満たせる工程からLLMとの分業を進められる。
