GENERATE OR EXTRACT生成しない抽出
Clairic は値を1回の順伝播で型どおりに返す
LLM の structured output
JSON をトークンで1つずつ書く
- 出力トークンにも課金がある
- 答えが長いほど時間がかかる
- 文章・推論も書ける
Clairic
@cf/cloudflare/clairic(プレビュー)
- 9つの型(数値・日付・リスト・推定など)
- 各値に confidence と p_null
- 推定は中央値と80%区間(p10〜p90)
30秒でわかる Clairic(2026年10月20日時点)
・何か:Cloudflare が2026年10月19日に Workers AI でプレビュー公開した抽出モデル。モデル ID は @cf/cloudflare/clairic。文章を生成せず、入力を1回読んで、型どおりの値を返す
・返すもの:text・number・date・duration・list・estimate・forecast など9つの型。各値に confidence と p_null(入力から決まらない確率)、推定と予測には中央値と80%区間(p10〜p90)が付く
・料金:入力100万トークンあたり 0.10 USD。出力トークンの課金は無い。重みは「近く公開予定」
・Clef との違い:Clef は選択肢から選ぶ決定モデル、Clairic は選択肢を並べられない値を返す。リクエストは questions でなく fields で、Jev 形式のままでは通らない(公式スキーマで確認)
・数字の読み方:処理時間69%減・コスト49%減は Cloudflare 自身の試験。カスケード19.3秒のうち18.6秒は返信を書く LLM だった
Clairic は LLM に請求書や帳票を読ませて JSON を書かせている処理の一部を、生成しないモデルに移すための選択肢だ。LLM 全体の地図はLLMとは?仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版にまとめてある。本記事は Clairic に絞り、公式の仕様を手元で確かめた結果と、Cloudflare が出した数字の前提を整理する。姉妹モデルの Clef はClefとは|Cloudflareの決定モデルの「Jev互換」を両側のJSONを生成して突き合わせたで扱った。
Clairic の仕組みと、返す9つの型
Cloudflare は Clairic を Clef と同じ「System One」のモデルと呼ぶ。推論の文章もトークンも生成せず、1回で答えるモデルを指す。changelog の説明では、Clairic は入力を1回で読み、各フィールドの答えを型の規則に沿って復号する。だから答えは必ず指定した型の値になるか、入力から決まらなければ null になる。
ただし「型どおり」は「正しい」とは違う。公式の概念ページは、型と制約は答えの形を決めるだけで、正しさは保証しないと明記している。
9つの型と、返る不確かさ
| 型 | 返すもの(公式の説明の要約) | 不確かさの出し方 |
|---|---|---|
text |
入力の文字列の一部。文字位置(span)付き | confidence・p_null |
number |
入力から読む・計算する数値。integer・decimals(0〜6)を守る |
confidence・p_null |
date・time・datetime |
実在する日付と時刻(ISO 形式) | confidence・p_null |
duration |
指定した単位の期間 | confidence・p_null |
list |
当てはまる text・number・date を入力の順にすべて | 見つからなければ空のリスト |
estimate |
min〜max の範囲・step の刻みでの分布 |
中央値と p10〜p90。include_quantiles で99分位 |
forecast |
系列の先の各ステップの推定(最大64ステップ) | ステップごとに estimate と同じ |
入力の約束事は次のとおり。
・state は文字列で、画像を送らないなら空にできない。text の答えはこの文字列の一部になる
・画像は PNG・JPEG・WebP を最大4枚、データ URL か Base64 で埋め込む。外部 URL は受け付けない
・フィールド数に上限は無い。8,192トークンの1回に収まらない分は、並列の別の回に分けて処理される
・年の無い日付は文脈から補う。今日の日付に依存するなら reference_date を渡すか、Today: 2026-10-19 のような行を state に足す
・コンテキスト長は65,536トークン、料金は入力100万トークンあたり 0.10 USD
Clairic と Clef・LLM の structured output の違い
Cloudflare の概念ページは、請求書を例に3種類のモデルを分けている。合計と支払期日を読むのが抽出モデル、承認・手動確認・却下のどれにするかを選ぶのが決定モデル、請求書と発注書と納品書の食い違いを要約するのが生成モデルだ。
| Clairic | Clef | LLM の structured output | |
|---|---|---|---|
| 役割 | 値を抜く・計算する・推定する | 決めた選択肢から選ぶ | 文章・推論を含めて JSON を書く |
| リクエストの中心 | fields(型つきの欄) |
questions(noul・choice・score) |
プロンプト+JSON Schema |
state の型 |
文字列だけ | 文字列・オブジェクト・配列 | プロンプトに埋め込む |
| 不確かさ | confidence・p_null・区間 |
選択肢ごとの確率 | JSON の値には含まれない |
| 料金(入力100万トークン) | 0.10 USD・出力課金なし | 0.24 USD・出力課金なし | モデルごと。出力トークンにも課金されるのが一般的 |
| 重み | 近く公開予定 | Hugging Face で公開済み | モデルごと |
Clairic と Clef の料金・コンテキスト長・state の型は、Workers AI のモデルページの元データ(cloudflare-docs リポジトリの clairic.json・clef.json)から読んだ値だ。
LLM で値を抜くには、生成を型で縛るやり方もある。liftとは|PDF 構造化抽出の9BモデルをGitHubのApache-2.0表示だけで判断してはいけないで扱った lift は、JSON Schema に沿って生成を縛る9Bモデルだった。Clairic は縛った生成ではなく、生成そのものをしない。この点が LLM 側との境目になる。
Jev・Clef 形式の質問は Clairic に通らない
当サイトの CI は型つき判定の API である Jev を tools/jev_judge.py から呼んでいる。Clef の記事では、Jev と Clef のリクエストの差が model の値だけだと確かめた。Clairic でも同じことが言えるかを、公式の入力スキーマで確かめた。
| リクエスト | Clairic のスキーマ検証 |
|---|---|
jev_judge.py で組んだ questions をそのまま送る |
不合格:fields が必須 |
questions を fields に名前だけ変える |
不合格:型 noul・choice は Clairic に無い |
包みのキーで共通するのは model・state と、答えの answers・usage だけだった。はい・いいえや選択肢の判定はこれまでどおり Clef(か Jev)に送る。Clairic の型には真偽値も無いので、「承認が要るか」のような問いは Clairic の担当ではない。
Clairic の公式スキーマを手元で確かめた
Clairic 本体は呼んでいない。Workers AI のアカウントで実行して返る値は未検証だ。手元で確かめたのは、リクエストが公式の入力スキーマに合うかどうかで、スキーマは cloudflare-docs リポジトリの src/content/workers-ai-models/clairic.json(production ブランチ 39cb53c)を使った。陽性対照は changelog に載っている呼び出し例で、本文をそのまま JSON にしたものが通るかを見た。
const response = await env.AI.run("@cf/cloudflare/clairic", {
model: "clairic",
state:
"Invoice INV-2291 from Northwind Supply, issued 2026-09-02, net 30. 4 pallets at $250.00 each, shipping $80.00. Contact: Dana Ruiz, Priya Shah.",
fields: {
invoice_number: { type: "text" },
issued: { type: "date" },
due_date: {
type: "date",
instructions: "Issue date plus the net payment days",
},
total: {
type: "number",
decimals: 2,
unit: "USD",
instructions: "Amount due including shipping",
},
contacts: { type: "list", items: "text" },
},
});
上は changelog の例を写したもの(Workers のバインディング env.AI から呼ぶ形)だ。due_date は発行日に支払日数を足す計算、total は単価×数量に送料を足す計算になっている。公式が「信頼できる」とする1〜2段の計算の例だ。
境界の値を変えて、スキーマ検証の結果を並べた(jsonschema 4.26.0・Draft 2020-12)。
| 入力 | 結果 | 読者への意味 |
|---|---|---|
changelog の例(model は clairic・@cf/cloudflare/clairic の両方) |
合格 | 陽性対照 |
フィールド名を日本語(合計) |
不合格 | 名前は英字か _ で始まる64字以内。日本語の項目名はローマ字か英語に直す |
decimals 6 / 7 |
合格 / 不合格 | 小数は6桁まで |
forecast の horizon 64 / 65 |
合格 / 不合格 | 予測は64ステップまで |
| 画像4枚 / 5枚 / https の URL | 合格 / 不合格 / 不合格 | 画像は埋め込みで4枚まで |
state に JSON オブジェクト |
不合格 | Clef と違い、構造化データは文字列にして渡す |
型に boolean |
不合格 | 真偽の判定は Clef へ |
list に items が無い |
合格 | 説明文では必須。スキーマは弾かないので、API がどう返すかは未検証 |
最後の行は、スキーマの検証を通っても API が受け付けるとは限らない例だ。手元のバリデーションは送る前の形の確認にとどめ、実際の応答は Workers AI で確かめる必要がある。
Cloudflare の試験で出た69%・49%の読み方
Cloudflare はブログで、破損した商品の保険請求を処理するパイプラインを2通り組んで比べた。1つは全段を GLM-5.3 に任せる構成、もう1つは Clairic が値を抜き、Clef が判定し、GLM-5.3 が返信を書くカスケードだ。
VENDOR BENCHMARKCloudflare 自身の試験
カスケードの19.3秒のうち18.6秒は返信を書く LLM
報道によると、抽出と判定の2段は GLM-5.3 だと38秒かかり、Clairic と Clef では合わせて0.68秒だった。費用は請求100万件あたり 11,740 USD に対して 6,032 USD だったという。公表された数字を検算すると、時間は (61.7−19.3)÷61.7=68.7%減、費用は 1−6,032÷11,740=48.6%減で、見出しの69%・49%と合う。
読むときの前提は4つある。
・ベンダー自身の試験で、独立した検証ではない。何件の請求で測ったかは、報道の範囲では示されていない
・カスケードの19.3秒のうち18.6秒(96%)は返信を書く GLM-5.3 の時間だ。返信が要らない処理なら、差はさらに開く計算になる。逆に、返信の段が重い処理では差は縮む
・報道によると、両構成とも事実と判定は報告された各回で正しかった。違いは修理費の見込みで、Clairic は毎回同じ値、GLM-5.3 は 250・250・220 USD と回ごとに変わったという
・料金は Workers AI の単価で計算されている。自分の環境の LLM の単価やトークン数が違えば、49%という比率もそのままは当てはまらない
試験が示しているのは、「値を抜く」と「選ぶ」を LLM の生成から外すと、その段が速く安くなるということだ。全体の短縮幅は、生成の段がどれだけ残るかで決まる。
Clairic が向いている処理・向いていない処理
PREVIEW LIMITS公式が挙げた弱点
プレビュー版で公式が書いた3つの弱点
-
1.長い計算・多数行の集計
1〜2段の計算は信頼できるとし、長い連鎖は値だけ抜いてコードで計算するよう勧める
-
2.根拠の無い推定・数段先の予測
根拠が入力に無いと区間が広い。数段先の予測は平均に寄り、時系列モデルの代わりにならない
-
3.見慣れないデータの区間
多くの評価セットで較正されているが、見慣れないデータでは狭くなりうる
公式は現在のエンドポイントを「early checkpoint」と呼び、弱点を書いている。そこから使い方を組み直すと次のようになる。
| 処理 | 任せ方 |
|---|---|
| 請求書・帳票から番号・日付・金額を読む | Clairic の text・date・number。span で原文の位置を確かめられる |
| 支払期日・遅延日数のような1〜2段の計算 | Clairic に任せられる範囲。今日に依存する計算は reference_date を渡す |
| 明細の多数行の合計・長い計算の連鎖 | 値を list で抜き、合計はコードで計算する(公式の勧め) |
| 支払日・修理費の見込み | estimate。比較対象や履歴を state に入れる。根拠が無いと区間が広い |
| 売上などの数段先の予測 | forecast は基本的な予測にとどまる。自社データで学習した時系列モデルの代わりにはならない |
| 承認・差し戻しの判定 | Clef(決定モデル) |
| 食い違いの説明・顧客への返信 | LLM |
もう1点、区間の扱いに注意したい。公式は区間が多くの評価セットで較正されているとする一方、見慣れないデータでは狭くなりうると書いている。概念ページも、80%区間の外に実際の値が落ちることはあり、confidence と区間はアプリ側の確認の代わりにならないとしている。支払いの承認のように取り消せない処理に使うなら、p_null・confidence のしきい値で人の確認に回す経路を先に作っておく。
日本語の帳票で精度がどうなるかは、公式の文書に記載が無く、当記事でも測っていない。導入を考えるなら、自社の帳票を数十件流して、confidence と実際の正誤の関係を先に見るのが順当だ。
参照ソース
・Introducing Clairic, a new System One class of extraction models — Cloudflare Blog(2026-10-19、Alex Reneau・Michelle Chen・Kevin Flansburg)
・Introducing Clairic: an extraction model for typed values, now on Workers AI — Cloudflare Changelog(2026-10-19)
・clairic — Cloudflare Workers AI docs(モデルページ)
・Extraction models — Cloudflare Workers AI docs
・cloudflare/cloudflare-docs:src/content/workers-ai-models/clairic.json(入出力スキーマの元データ)
・cloudflare/cloudflare-docs:src/content/workers-ai-models/clef.json
・Cloudflare bets you’re overpaying an LLM to read your invoices — Help Net Security(2026-10-20)
・Cloudflare’s Clairic model cuts AI pipeline cost 49% in its own test — PPC Land





