Cloudflare ClairicとLLM抽出の使い分け

Clairicは、CloudflareがWorkers AIでプレビュー公開した、文章や画像から金額・日付・番号などの値だけを取り出す抽出専用のモデルです。メールから金額と日付を抜くためだけにLLMを呼んで、待ち時間と費用が気になっていませんか？ 本文に書いてある値を写す抽出は任せてよく、何段も重なる計算と日付の引き算、一覧、画像の中の日本語や数量は任せません。架空のメールや書類、画像で試し、LLMとも比べました。

Introducing Clairic, a new System One class of extraction models

Clairic is a new model from Cloudflare that is a System One extraction modeI, capable of extracting, computing, estimating, and forecasting data from unstructured inputs.

blog.cloudflare.com

Workers AIから呼ぶ最短の手順

Clairic は Workers AI のモデルなので、Worker から呼びます。私は Mac から wrangler dev --remote で動かしました。デプロイせずに本番のモデルが使え、起動まで約10秒です。wrangler.toml には次の2行を足します。

[ai]
binding = "AI"

Worker 側では、モデル ID @cf/cloudflare/clairic を env.AI.run で呼びます。

export default {
  async fetch(request, env) {
    const body = await request.json();
    const t0 = Date.now();
    const result = await env.AI.run("@cf/cloudflare/clairic", { model: "clairic", ...body });
    return Response.json({ ms: Date.now() - t0, result });
  },
};

送ったリクエストです。

{
  "state": "件名: 注文番号 AMV-20481 の返品について\n\nお世話になっております。10月12日に注文した電動歯ブラシ（注文番号 AMV-20481）が、10月15日に届きました。使ってみたところ、充電が1日しか持ちません。支払いは代金引換で、商品代金 8,980円 と送料 660円 の合計 9,640円 を支払っています。返品したいので、手順を教えてください。\n\n山田 太郎（架空）",
  "reference_date": "2026-10-29",
  "fields": {
    "order_id": { "type": "text" },
    "amount_paid": { "type": "number", "decimals": 0, "unit": "JPY" },
    "delivered_on": { "type": "date" },
    "days_since_delivery": { "type": "duration", "unit": "days", "integer": true },
    "reason": { "type": "text" },
    "tracking_number": { "type": "text" }
  }
}

state が読ませる本文、fields が取り出す項目です。model: "clairic" は入力の必須キーで、env.AI.run の第1引数と二重に見えますが公式の仕様です。reference_date は、本文の「10月12日」のように年の無い日付の年を決める基準日です。duration は2つの日時の間隔を日などの数で返す型で、コード内の unit: "days", integer: true がそれです。

型は text、number、date、time、datetime、duration、list、estimate、forecast の9種です（推定と予測の型はあとで触れます）。list は { "type": "list", "items": "text" } のように、要素の型（text / number / date）を文字列で書きます。項目の補足は instructions キーに書きます。画像は images キーに data:image/png;base64,… の形の文字列を配列で渡します（最大4枚）。コンテキストは65,536トークンです。

Workers の外からは REST API で、model: "clairic" を足した同じ JSON をアカウント ID と API トークン付きで POST します（公式ドキュメントの形）。

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run/@cf/cloudflare/clairic \
  -H "Authorization: Bearer $TOKEN" \
  -d @request.json

clairic

Clairic is a System One-style model that can extract, compute, estimate, and forecast values from inputs. It is strongly typed and outputs confidence scores and probabilities against its outputs. This model is in preview from the Cloudflare Workers AI team.

developers.cloudflare.com

Clairicに任せていい抽出、任せない抽出

試したのは架空の4つです。注文メール（上のリクエストに載せたもの）、見積書（明細3行、消費税10%、発注日から45営業日の納期）、障害報告書（1,340字、13項目）、レシート画像（合計3,575円、瓶ビール1本など）です。

任せない値は、LLM か Worker のコードで出します。線は「本文に書いてある値を写すか、1回の比較で済むか」で引けます。

ClairicはLLMより速いのか、安いのか？

同じ注文メールの6項目を、Clairic と、Workers AI 上の Llama 3.1 8B、Llama 3.3 70B、それに Anthropic の Claude Haiku 4.5 に3回ずつ通しました。

所要は Worker 内で env.AI.run の前後を計りました。Clairic は1回目だけ遅く、2回目以降は0.2秒前後です。費用は1ドル150円換算で、Clairic は入力1,055トークン（内訳はあとで）、LLM はレスポンスの usage に入る neurons（トークン数をモデルごとの係数で換算した Workers AI の課金単位。1件あたり 8B が3.2、70B が17.5、1,000 neurons で0.011ドル）から出しています。LLM には本文末尾に今日の日付を足し、無ければ null と指示しました。Clairic に渡したのは reference_date だけで、外した1問は経過日数です。Haiku 4.5 だけは Mac から Anthropic の SDK で呼び、ツール使用で同じ6項目を JSON Schema で指定しました。所要に Mac と API の往復が入る点と、1回目だけ15秒かかった点（原因は分かりません）は条件の違いです。費用は入力991トークンと出力149トークンを公式価格（入力1ドル、出力5ドル、いずれも100万トークンあたり）で計算しました。

70B や Haiku 4.5 で2〜3秒かかる抽出が、Clairicなら0.2〜0.4秒で返ります。1通の費用は 8B が最も安く、Clairic はその約3倍、70B の約半分、Haiku 4.5 の約16分の1でした。

結局 8B でいいのでは？ 安さが目的なら足ります。Clairic を選ぶ理由は3つです。所要が0.2〜0.4秒で 8B の0.65〜0.8秒より短いこと、無い確率を p_null の数値で返すこと（このあと説明します）、項目名と型を書くだけで、system prompt やスキーマの説明文が要らないことです。Claude Haiku 4.5 のツール使用による JSON 出力から移すなら、所要は約10分の1（往復込み）、費用は約16分の1になりました。ただし比べたのはメール1通を3回ずつだけです。OpenAI など他の LLM を使っているなら、どれも答えの JSON を書き出す分の時間がかかるので、同じメールで所要と費用を測ってから決めてください。

文章を書き出さないから速い

LLM は答えの JSON を60〜72トークン書き出し、1トークン書くたびにモデルを1回動かします。入力を読む計算の中で各項目の値を決める Clairic には書き出す工程が無く、出力は0トークンです。公式ブログは、速さと正確さを重視して熟考をしない型を System One モデルと呼び、熟考する LLM と対比しています。

1件あたり、円でいくらか

公式の料金は入力100万トークンあたり約15円（0.10ドル）で、課金は入力だけです。出力トークンは常に0でした。項目はいくつかに分けて並列に読まれ、その回数が passes で返ります。入力トークンは実測した例すべてで「本文（画像なら画像）のトークン×passes＋項目定義のトークン」と一致し、短いメール6項目なら本文123トークン×passes 4＋項目定義563トークン＝1,055でした。

使わない項目を定義に残すと、そのぶん高くなります。実測では、項目が1〜3つなら passes は1、6〜13項目では2〜4でした。同じメールで2項目に絞ると本文123×passes 1＋項目定義171＝294トークンで、6項目の1,055トークンの3割以下です。要る項目が6つなら6つでよく、使わない項目は定義から外します。

1,000件なら、短いメール6項目で約16円、障害報告書13項目で約67円です。自分のメールでは、1通流して usage の input_tokens を見てから件数を掛けて見積もります。passes は送る前に分からないためです。

無い項目は、confidenceではなくp_nullで見る

値を1つ返す項目には、value のほかに confidence（値が合っている確からしさ、0〜1。以下、確信度）、p_null（本文に無い確率）、guess（無理に答えるならこれという値）が付きます。text 型には span（値が本文の何文字目から何文字目か。日本語でも文字単位で合っていました）も付きます。末尾の usage は、消費したトークンと passes です。

{
  "answers": {
    "amount_paid": {
      "type": "number",
      "p_null": 0.000004131701189180603,
      "guess": 9640,
      "confidence": 0.9996494862003851,
      "value": 9640
    },
    "tracking_number": {
      "type": "text",
      "p_null": 0.9999381303787231,
      "span": [9, 18],
      "guess": "AMV-20481",
      "confidence": 0.8017310500144958,
      "value": null
    }
  },
  "usage": {
    "state_tokens": 123,
    "image_tokens": 0,
    "schema_tokens": 563,
    "input_tokens": 1055,
    "output_tokens": 0,
    "passes": 4
  }
}

メールに無い追跡番号は、p_null が0.99994で value は null でした。ところが確信度は0.80あり、guess には注文番号が入っています。確信度で有無を決めたり guess で空欄を埋めたりすると、追跡番号の欄に注文番号が入ります。有無は p_null で見ます。

confidenceが0.5を切った値は、ほぼ外れていた

次の表の「補足あり」は、instructions に計算のしかたを書き足して再実行したものです。納期の正解は土日だけを除いた45営業日後です。

補足ありの税込合計は539,000円で正解でしたが、確信度は0.017でした。0.5を切った値は、この表の5件とこの1件、経過日数2件（あとの表の10日と44日）、品名一覧2回、対策一覧1回の計11件で、10件が外れました。

0.5〜0.7は混ざっていて、返品理由0.56と根本原因0.63は正解、レシートの店名0.57は崩れました。目安は「0.5を切ったら LLM かコードに回し、0.5〜0.7は中身を見る」で、数十項目を試した範囲の線です。

confidenceが高くても外れた値

• 注文メールの経過日数「3日」、確信度0.996
• 見積書の小計「450,000円」、確信度0.94
• レシートの品名一覧「替わり定食からげ定定」、確信度1.0

計算と日数、画像の中の日本語は、確信度が高くても検算に回します。

Clairicに配達から何日かを聞くと、なぜ3日と返ったのか？

公式ブログの例と同じ days_since_delivery で配達から今日までの日数を聞くと、3回とも3日でした。正解は14日で、3日は注文から配達までの間隔です。

3日と返した値は「配達から今日まで」ではなく、本文にある注文日と配達日の差と一致していました。項目名ひとつで答えが変わり、同時に足した days_from_order_to_delivery は3日（0.9996）で正解でした。10日と44日は、本文のどの日付の差とも一致せず、由来は分かりません。

公式の reference_date の定義は「年が書かれていない日付の基準」だけで、今日を渡すための欄とは書かれていません。改名で14日が出たのも、仕様で保証された動きではありません。

「今日まで何日か」が欲しいときは？ 確信度0.9999で正解した配達日だけを取り、日数はコードで引きます。本文にある2つの日付の間隔なら、項目名に起点と終点を書きます。

Clairicの相場の推定と、7日先の予測

抽出のほかに、本文に無い値を根拠から出す estimate 型と、数列の先を出す forecast 型もあります。先に判断を書くと、根拠になる相場や過去の数列を本文に入れられるときだけ使い、根拠なしの推定には使いません。どちらも、10回に8回は入る80%区間を、下端の p10 と上端の p90 で返します。

estimate に、定価198,000円、状態の良い中古が11万〜13万円、傷ありが9万〜10.5万円、傷2か所、バッテリー最大容量89%と書いた中古ノートPCの売値を聞くと、中央値106,000円、80%区間95,000〜119,000円でした。

forecast には、架空の日次アクティブユーザーの10月1日から21日までの21日分（日曜と月曜が955〜1,105、ほかの日が1,190〜1,512）を渡しました。22日から28日の予測は 1,542、1,540、1,481、1,194、1,154、1,619、1,619 で、日曜と月曜の落ち込みが再現され、各日に80%区間が付きました。1回の呼び出しは100msでした。

正解の無い値なので、試した範囲で言えるのは、本文に書いた相場の幅に入る中央値と、週の周期を拾う予測が返ったことまでです。

Clairicを動かすまでに出たエラー

3030: field days_since_delivery has unknown key 'description'; duration fields take type, instructions, unit, null_threshold, integer, decimals
3030: images.0: image must be an embedded base64 data URI
5006: enum [object Object] not in text,number,date

• 補足は description でなく instructions キーです
• 画像は data:image/png;base64,… の形にします
• list の items にオブジェクトを渡すと3行目のエラーで、text / number / date のどれかを文字列で書きます

まだプレビューで、公式ブログはオープンウェイト版を近く出す予定としています。Cloudflare は10月1日に、選択肢や yes/no、点数で判断を返す Clef を公開済みで、Clairic のブログも組み合わせて使う例を載せています。gihyo.jp の記事も両方に触れています。

今 LLM に投げている抽出の項目のうち、本文から写すだけの項目はいくつありますか？ それを fields に書いて1通流し、p_null と確信度を見てください。1通約0.016円で試せます。