GENERATE OR EXTRACT生成しない抽出

Clairic は値を1回の順伝播で型どおりに返す

LLM の structured output

JSON をトークンで1つずつ書く

  • 出力トークンにも課金がある
  • 答えが長いほど時間がかかる
  • 文章・推論も書ける

Clairic

@cf/cloudflare/clairic(プレビュー)

  • 9つの型(数値・日付・リスト・推定など)
  • 各値に confidence と p_null
  • 推定は中央値と80%区間(p10〜p90)
出典: Cloudflare Workers AI changelog・モデルページ(2026-10-19)

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

全部 LLM(GLM-5.3)抽出・判定・返信を1つの LLM で

61.7秒

カスケードの合計Clairic → Clef → GLM-5.3

19.3秒

うち GLM-5.3 の返信顧客への返信文を書く段

18.6秒

うち Clairic の抽出請求から値を抜く段

0.46秒

うち Clef の判定承認するかを選ぶ段

0.22秒
出典: Cloudflare ブログ(2026-10-19)と Help Net Security・PPC Land の報道。ベンダー自身の試験で、独立した検証ではない

報道によると、抽出と判定の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.長い計算・多数行の集計

    1〜2段の計算は信頼できるとし、長い連鎖は値だけ抜いてコードで計算するよう勧める

  2. 2.根拠の無い推定・数段先の予測

    根拠が入力に無いと区間が広い。数段先の予測は平均に寄り、時系列モデルの代わりにならない

  3. 3.見慣れないデータの区間

    多くの評価セットで較正されているが、見慣れないデータでは狭くなりうる

出典: Workers AI changelog「Introducing Clairic」の Preview 節(2026-10-19)

公式は現在のエンドポイントを「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