ブログ一覧

Cloudflare の Clairic で請求書を読み、確信度の低い文書だけ LLM に回す

Cloudflare から、文章を生成せずに値だけを返す抽出モデル Clairic が Workers AI でプレビュー公開されました。文と「型を付けた項目の一覧」を渡すと、文を一度読むだけで項目ごとに型どおりの値を返すモデルです。そこで、日本語の請求書やメールから値を取り出す処理を、LLM に JSON スキーマで答えさせる形から Clairic に替えると、正確さ・速さ・費用がどう変わるのかを確かめてみました。

Clairic だけで読むと速くて安いものの、漢数字や和暦などを混ぜて作った 30件では、正解率が試した LLM に届きませんでした。ただ、この 30件では金額や数量の誤り 6つすべてに 0.9 未満の確信度(答えごとに返る自信の値)が付きました。そこでその文書だけ LLM に回すと、7割の文書は 0.4秒台で返り、正解率は LLM 単独に近い 96.7% まで上がりました。1件ずつ待たせる処理で得になる組み方です。

確信度の低い文書だけ LLM に回す組み方は、正解率が LLM 単独に近く、7割の文書は Clairic 単独と同じ 0.4秒台で返る

同じことを試せるように、作った文と比べ方を並べておきます。

  • 日本語の短い文 30件(請求書・配送の連絡・修理の見積もり)で、文の種類ごとに 4つ、計 120 の項目に正解を用意し、文から決まらない物の正解は null
  • 文に混ぜた書き方は、漢数字、全角数字、和暦(令和のような元号の年)、年の無い日付、「明日」「来週の月曜日」、税抜からの加算、源泉徴収、金額の訂正、宛先の「御中」、別便、金額の幅、2案のどちらか
  • 比べた LLM は、Workers AI の GLM-5.3(Clairic の発表で比べられた LLM)とその安い版の GLM-5.3-flash、Claude Haiku 5.5 の 3つ
  • GLM はどちらも JSON スキーマで型を縛って temperature 0、Haiku は Claude Code の CLI の --json-schema
  • 文と日本語の項目の説明はどれも同じ物で、文の頭には受信日を付け、LLM には「文から値が決まらない項目は null」と指示
  • 数と日付は完全一致、文字列の項目は全角半角と空白をそろえて比較し、「エアコン」と「エアコン(リビング)」のような言い方の揺れは正解
  • 時間は手元から Workers AI の REST を呼んだ往復、費用は Workers AI の定価と返ってきたトークン数から出した額で、Haiku は CLI 経由なので正解率だけを比較

レシートや請求書の写真、長い文書、英語の文は試していません。

Clairic 単独は速くて安いが、正確さは試した LLM 3つが上

1件の時間の中央値は Clairic が 0.38秒で、GLM はどちらも 10秒を超えました。Clairic は同じ文を繰り返し回しても、答えが全部同じでした。

30件の実測から出した 1万件あたりの費用は、Clairic が 0.61 ドル、GLM-5.3 が 38.61 ドルで、安い flash でも Clairic の約 5倍です。Clairic は入力の分だけ課金されますが(Clairic の料金と制限)、GLM は入力と出力の両方に単価があり、答える前に考える分も出力トークンとして数えられます。Clairic の入力の大半は文より項目の定義(型と説明)で、項目を足すほど費用は増えます。

GLM はどちらも、ときどき 502 を返しました。flash はある文だけ何度送っても 502 になり、答えが取れていません。Clairic は一度も失敗しませんでした。

一方、漢数字や和暦などを混ぜて作った 30件での正解率は、GLM-5.3 が 100%、flash が 96.7%、Claude Haiku 5.5 が 95.8%、Clairic が 91.7% でした。flash は答えが取れなかった文を誤りに数えています。Clairic の発表にある「LLM より大幅に正確」という結果は、今回の文では出ていません。

Clairic の誤りの多くは数でした。「金参万三千円也」という漢数字の金額を読み違え、税抜の額に消費税を足す計算を誤り、出張費を足し忘れ、別便の分まで数量に足していました。正解が null の文で値をこしらえた誤りもあり、金額の幅や 2案だけが書かれた文から、決まっていない金額を作っています。Haiku も同じ漢数字の金額を読み違えています。

残りは文字列と日付の取り違えです。宛先の「〜御中」を請求元にした、和暦の年をずらした、「本日発送、お届け予定は〜日」の発送日をお届け予定の日にした、請求書番号に「No.」を付けたまま返した、という誤りがありました。

数の項目は確信度の低い文書だけ GLM-5.3 に回す

Clairic の数の誤りは、確信度が全部 0.9 未満でした。一方、文字列と日付の 4つの誤りは確信度が 0.96 以上と高く、この 4つでは確信度は誤りの目印になりませんでした。

Clairic は誤った金額には低い確信度を付けたが、和暦の年と宛先の取り違えには高い確信度を付けた

そこで、金額・数量・作業時間のどれかの確信度が 0.9 未満なら、その文書を LLM にまるごと読ませ、数の項目だけを LLM の答えに取り替えました。30件のうち 9件が回り、残りの 21件は 0.4秒台で返っています。回った文書には LLM の分の時間が足され、中央値で 10秒前後かかります。

回し先を GLM-5.3 にすると正解率は 96.7% で、1万件あたり 12.27 ドルでした。flash にすると 95.0% で 1.55 ドルですが、502 で答えが取れない文が残ります。

しきい値の 0.9 は、この 30件の結果を見て置いた値で、0.5〜0.99 のどこに置いても正解率は大きく変わりませんでした。しきい値は、手元の文書で確信度と正誤を並べて決めるのが確実です。

レスポンスには項目ごとに、確信度と p_null(文から値が決まらない確率で、0.5 を超えると値は null)が付きます。リクエストの形式は Clairic のモデルのページにあり、fields の名前は英数字だけで、日本語の名前は通りません。

{
  "model": "clairic",
  "state": "件名: ご注文の件\n山田様\nいつもありがとうございます。ご注文いただいたコーヒー豆(200g)を3袋、1袋1,280円(税抜)でお送りします。消費税は10%です。発送は11月5日を予定しており、お届けまで2〜3日かかります。\n株式会社ミドリ珈琲 佐藤",
  "reference_date": "2026-10-21",
  "fields": {
    "total_with_tax": { "type": "number", "decimals": 0, "instructions": "税込の合計金額(円)" },
    "ship_date": { "type": "date", "instructions": "発送予定日" },
    "tracking_number": { "type": "text", "instructions": "配送の追跡番号" }
  }
}

レスポンスは次のようになります(抜粋)。

"total_with_tax": { "value": 4224, "confidence": 0.61 },
"ship_date": { "value": "2026-11-05", "confidence": 0.99 },
"tracking_number": { "value": null, "guess": "2〜3日", "p_null": 0.99 }

税込の合計は単価と袋数と消費税から計算した正しい額ですが、確信度は 0.61 で、回す物にはこのように正しい答えも入ります。文に無い追跡番号は null で、guess には外れの候補が残りますが、使うのは value だけで足ります。

回しても残る和暦の日付は、文字列で受け取ってコードで西暦に直す

回しても、確信度の高い文字列と日付の取り違えは残ります。そのうち和暦は、日付の型で聞くと年がずれました。令和7年は 2025年ですが 2027年にし、請求書の文の中の令和8年も、2026年のところを 2028年にしています。「支払期限 令和8年11月10日」の 1行だけの文では、令和8年は合っていました。項目の説明に「和暦は西暦に直す」と書いて元年の西暦を添えても、令和7年は別の年にずれました。

型を text にして「書かれたとおりの文字列」と聞くと、「令和7年3月31日」「令和8年11月10日」をそのまま、確信度 1.0 で返しました(確かめたのはこの 2つの文)。和暦の日付を読むなら、文字列で受け取って、元号の表を持ったコードで西暦に直すのが確実です。

待たせる処理は組み合わせ、待てるバッチは flash 単独で足りる

受け取ったメールをその場で入力欄に入れるような、1件ずつ人や画面を待たせる処理なら、Clairic で読んで数の項目の確信度が低い文書だけ LLM に回す組み方が合います。この 30件では 7割の文書が 0.4秒台で返り、費用は前の節の 12.27 ドルか 1.55 ドルでした。回る割合は、自分の文で確信度を並べて確かめます。

待てるバッチなら、flash だけで読んでも正解率は 96.7% で、1万件あたり 2.92 ドルです。ただし 1件 10秒前後かかり、ときどき 502 が返ります。

御中・お届け予定・和暦のような取り違えには高い確信度が付くので、確信度では拾えません。支払いのような戻せない処理につなぐなら、文字列と日付は検算か人の目で確かめる必要があります。日付は「発送日が受信日の前後何日以内か」のような検算をコードで足せば、拾える誤りがあるはずです(私は試していません)。

この記事をシェア