取引先から届く請求書のPDFや注文メールを開き、請求番号・金額・支払期日を会計や販売管理のシステムへ手で打ち直す。生成AIにJSONで出させる方法を試しても、項目が抜けたり、日付が「来月末」のまま返ってきたりして、結局すべてを人が見直すことになる。こうした転記の自動化を検討している業務システムの担当者に向けた記事です。
Cloudflareは2026年10月19日、AI推論サービスのWorkers AIに、抽出モデル「Clairic」（モデル名 @cf/cloudflare/clairic）をプレビューとして追加しました。変更履歴（changelog）では、Clairicを「文章ではなく値で答えるモデル」と説明しています。
Clairic is the first extraction model: a System One model that answers with values instead of text.
この記事では、Cloudflareの変更履歴、モデルのリファレンス（入出力の定義）、抽出モデルの解説ページ、料金とデータの扱いのページをもとに、何ができて何はまだ任せられないのか、どこに人の確認を残すかを整理します。編集部はCloudflareのアカウントで実際に呼び出してはいません（資料調査）。
文章を生成するLLMと何が違うのか
一般的な生成AIは、指示に従って文字（トークン）を1つずつ生成します。JSONで答えるよう指示しても、出てくるのは「JSONらしい文字列」で、型が崩れたり余計な文章が混ざったりする余地が残ります。
Clairicは、入力（ドキュメントでは state）と、欲しい項目とその型の一覧（fields）を受け取り、項目ごとに1つの値を返します。変更履歴には、トークンを生成しないことと、返る値が指定した型に必ず収まることが書かれています。
Clairic does not generate tokens. It reads your input in one pass and decodes each answer under the rules of its type, so every answer is a valid value of the type you asked for, or
nullwhen the input does not determine it.
指定できる型は、テキスト（入力中の該当箇所をそのまま返し、文字位置も付く）、数値、日付・時刻、期間、リスト、推定（estimate）、予測（forecast）です。変更履歴の例（架空の英文請求書）では、請求番号を text、発行日と支払期日を date、合計額を小数2桁の number として定義し、支払期日には「発行日に支払いサイトの日数を足す」という指示を付けています。
抽出モデルの解説ページは、用途の違いを請求書の例で次のように分けています。
| モデルの種類 | 向いている用途 | 請求書での例（解説ページの例） |
|---|---|---|
| 抽出（Extraction） | 金額・日付・期間などの値を取り出す、計算する、推定・予測する | 合計額と支払期日を読み取る |
| 判定（Decision） | あらかじめ決めた選択肢から選ぶ | 承認・人の確認・差し戻しのどれにするか決める |
| 生成（Generative） | 自由な文章を作る | 請求書・発注書・納品書の食い違いを要約する |
転記の自動化で言えば、「値を取り出す」のがClairic、「どの処理に回すか決める」のが判定モデル（Cloudflareは10月1日に判定モデル「Clef」を公開しています）、「差異を文章で説明する」のが生成モデル、という分担です。
返ってくる「確からしさ」をどう使うか
Clairicの回答には、値と一緒に2つの数値が付きます。p_null（入力からはその値が決められない確率）と confidence（返した答えの確信度）です。モデルのリファレンスによると、p_null が既定では0.5を超えると値は null になり、このしきい値は項目ごとに null_threshold で変えられます。テキストの答えには、入力中の位置（span）も付きます。
ただし、型に収まっていることは、正しいことを意味しません。解説ページははっきりこう書いています。
Typed output does not guarantee correctness. A result can satisfy its type and constraints while still answering the question incorrectly.
さらに、確信度や区間も「保証ではない」とし、取り返しのつかない処理の前には、別の根拠との照合か人の確認を求めています。
Before consequential or irreversible actions, check results against other evidence or require human review.
ここからは編集部の整理です。転記の自動化では、次のように扱いを分けると、Clairicの数値を判断に使いやすくなります。
- 値が
nullの項目：自動で埋めず、人の確認に回す。解説ページによると、nullは「文書に書かれていない」場合と「モデルが見つけられなかった」場合のどちらもありえるため、nullだけではどちらか判断できません - テキストの項目：返ってきた
spanで元の文書の該当箇所を表示し、確認する人がすぐ照合できるようにする - 支払いや計上に直結する金額：確信度が高くても、発注書や見積書の金額との突き合わせをコードで行い、一致しないものだけを人に回す
- しきい値：最初から固定せず、過去の請求書を数十件流して、確信度と実際の誤りの関係を見てから決める
プレビューで「任せない」と書かれていること
変更履歴には、現在のエンドポイントは初期の段階のもので、今後改善すると書かれています。そのうえで、次の点を注意として挙げています。
- 計算：合計・差額・換算・日付の計算など、1〜2段階の計算は信頼できる。一方、依存する計算が長く続くものや、表の多数の行にまたがる集計はまだ苦手で、「入力値をClairicで取り出し、計算はコードで行う」よう案内している
- 推定・予測：入力に根拠（比較対象、履歴、説明）がない推定は区間が広くなる。数ステップ先の予測は平均に寄り、祝日のような系列に現れない出来事は見込まない
- 日付：年のない日付は文脈から決める。現在の日付に依存する項目は、
reference_dateを指定するか、入力に「Today: 2026-10-19」のような行を加える - 確信度：すべての答えは型として正しい形をしているが、内容が正しいとは限らない
明細行が何十行もある請求書の合計を「明細から計算させる」使い方は、プレビューの時点では避けるべき、ということです。明細の金額をリストで取り出し、合計はプログラムで計算して、請求書に印字された合計額（これもClairicで取り出せます）と照合する形が、変更履歴の案内に沿った設計になります。
料金と、入力の上限
料金は入力100万トークンあたり0.10ドルで、出力トークンの料金はかかりません（変更履歴と料金ページ。料金ページでは100万入力トークンあたり9,091 Neuronsと換算）。Workers AIには、無料プラン・有料プランとも1日10,000 Neuronsの無料枠があり、料金ページで有料の支払い方法が必要と明記されたモデルの一覧に、Clairicは含まれていません（2026年10月22日時点）。
モデルのリファレンスに書かれている主な仕様は次のとおりです。
| 項目 | 内容 |
|---|---|
| コンテキスト長 | 65,536トークン |
| 1回の処理 | 入力と項目の定義は8,192トークン単位で処理し、収まらない項目は並列の処理に分ける（項目数の上限はなし） |
| 画像 | PNG・JPEG・WebPを最大4枚。1枚4MiB、合計8MiBまで（デコード後）。URLでの指定は不可 |
| リクエストの大きさ | 最大16MiB |
| 予測 | 最大64ステップ |
入力した内容の扱いについて、Workers AIのデータ利用のページは、通常の推論では処理に必要な間しか入力・出力を保持せず、顧客のコンテンツをモデルの学習に使わないとしています。ただし、AI Gatewayのログやキャッシュ、R2などの保存先を自分で使う場合は、その機能の保存期間に従います。取引先の請求書を扱う場合は、ログに本文を残す設定になっていないかも確認対象です。
なお、変更履歴には、モデルを近くオープンウェイト（重みの公開）で出す予定とも書かれています。
採用を判断する前に確かめること
公式資料からは確認できなかった点があります。日本語の請求書を検討する場合は、ここを先に確かめます。
- 日本語の対応：変更履歴・リファレンス・解説ページ・公式ブログのいずれにも、対応言語の記載がありません。例はすべて英語です。和暦、「月末締め翌月末払い」のような支払条件、全角数字や「¥」「円」の表記で正しく値が取れるかは、自社の請求書のサンプル（個人情報や取引先名を伏せたもの）で試すまで分かりません
- 画像の読み取り精度：画像は最大4枚まで渡せます。公式ブログにはレシートの写真1枚から値を取り出した例がありますが、スキャンした請求書の読み取り精度を示す数値はありません
- プレビューの期間と変更：正式提供の時期や、仕様・料金の変更の予定は書かれていません。モデルのページの利用条件には、提供の継続を保証せず、提供を止める場合があることも書かれています。本番の業務に組み込む場合は、モデルの更新で結果が変わる前提で、検証用の請求書を残しておき、定期的に同じ結果になるかを確かめます
転記の自動化は、AIの精度だけでなく、照合のルールや確認画面の設計で使いやすさが決まります。承認を「AIへの指示」ではなくプログラム側に置く考え方は、AIに価格を触らせる会社が、承認をプロンプトではなくコードに置く理由で取り上げています。社内でAIのAPIを使う場面が増えてきた場合のキーやログの管理は、社内AIにゲートウェイを1枚挟むかを、既存のPythonの処理をCloudflare上で動かす選択肢はPython Workersが正式提供にを参照してください。
確認した範囲
2026年10月22日に、Cloudflareの公開ドキュメント（developers.cloudflare.com）で、変更履歴「Introducing Clairic: an extraction model for typed values, now on Workers AI」（2026年10月19日付）、Clairicのモデルのページ（入出力のスキーマ、コンテキスト長、料金、利用条件）、抽出モデルの解説ページ（Extraction models）、Workers AIの料金ページとデータ利用のページを確認しました。あわせて、Cloudflareのブログ記事とドキュメントの原稿（cloudflare/cloudflare-docs リポジトリ）も確認しています（資料調査）。Clairicの実際の呼び出し、日本語の文書や画像での精度、応答速度は確認していません。本文の「人の確認に回す」扱いの分け方は、公式の注意事項から編集部が整理した提案です。
請求書や受発注データの転記を業務システムに組み込む設計・開発は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Introducing Clairic: an extraction model for typed values, now on Workers AI（Cloudflare changelog, 2026-10-19）
- Clairic model reference（Cloudflare Workers AI docs）
- Extraction models（Cloudflare Workers AI docs）
- Introducing Clairic, a new System One class of extraction models（Cloudflare Blog, 2026-10-19）
- Pricing（Cloudflare Workers AI docs）
- Data usage（Cloudflare Workers AI docs）
