2026.10.24 AI

Clairicとは：Cloudflareの抽出モデルの料金・型・Workers AI実装と採用条件【2026年10月時点】

Clairic（クレアリック）は、Cloudflareが2026年10月19日にWorkers AIでプレビュー公開した、文章を生成せずに型付きの値だけを返す「抽出モデル」です。請求書やメールのテキスト、領収書の画像から、金額・日付・番号・明細といった項目を、信頼度と元の文字位置つきで受け取れます。この記事では、入力100万トークン0.10ドルの料金と無料枠の換算、9種類のフィールド型と入力上限を公式ドキュメントで確認し、WorkersとREST APIで請求書を読ませるコードを示します。AI-OCRやLLMの構造化出力との違い、採用する条件と見送る場面までを判断材料として整理しました。

まとめ：Clairicは帳票やメールから型付きの値を出力課金なしで抜き出す抽出モデル

先に結論です。テキストになった請求書・注文書・問い合わせメールから、決まった項目を大量に取り出す処理なら、Clairicは2026年10月時点で試す価値のある選択肢です。課金は入力だけで、出力トークンは発生しません。Workers AIの無料枠で1日約110万トークンまで読ませられます。

ただし、紙をテキストにする文字認識の代わりではありません。返る「位置」は画像上の座標ではなく、入力テキストの何文字目かを示す範囲です。紙の帳票はAI-OCRで文字にし、そのテキストから値を取り出す段にClairicを置く、という分担が基本になります。

前提として押さえる制約は2つです。公式は「出力は必ず形式どおりだが、正しいとは限らない」と明言しており、多段の計算はまだ弱いとしています。日本語の精度も公表されていません。自社の帳票で正答率を測り、信頼度の低い値を人に回す経路を作ってから本番に入れてください。

Clairicの正体と生成せずに1回の処理で値と根拠の位置を返す抽出モデルの仕組み

Cloudflareの発表記事は、Clairicを「System One抽出モデル」の第1弾と位置づけています。トークンを1つずつ生成せず、入力を読む1回の処理で全フィールドに答えるため、応答は通常1秒未満とされています。

10月19日のプレビュー公開とSystem Oneに属する抽出モデルの位置づけ

公開日は2026年10月19日で、モデルIDは@cf/cloudflare/clairicです。発表記事は現行版を「初期のチェックポイント」と呼び、プレビュー扱いで提供しています。重みのオープンウェイト公開は「近日」とされ、日程は示されていません。

System Oneは、TypeSafeが提唱した「生成しないモデル」の分類です。先行するTypeSafe JevとCloudflare Clefは、候補の中から選ぶ判断を担います。Clairicは選ぶのではなく、数値・日付・テキスト・リストといった値そのものを返します。

stateとfieldsを渡しspan・confidence・p_nullを受け取る形

入力は、読ませるテキストのstateと、名前付きのフィールド定義の集まりfieldsです。各フィールドに型と、何を取り出すかの説明instructionsを書きます。

応答のanswersには、フィールドごとに次の値が入ります。

value：型どおりの答え。入力から決まらないときはnull
confidence：その答えの信頼度
p_null：値が入力に存在しない確率
guess：valueがnullのときにモデルが最も妥当とみた候補
span：テキスト型の答えがstateの何文字目から何文字目にあるか（リスト型はspans）

テキスト型の答えは、必ずstateの一部を切り出したものになります。モデルが言い換えた文字列は返りません。spanで元の文脈に戻れるので、画面上で該当箇所を強調して人に確認させる、といったUIを組めます。

抽出・計算・推定・予測の4機能と判断モデルClefや生成LLMとの分担

抽出モデルの概念ページは、機能を4つに分けています。書かれた値を返す「抽出」、入力の事実から導く「計算」（発行日と支払条件から期限日を出すなど）、入力だけでは決まらない値を分布で返す「推定」、時系列の先を返す「予測」です。

同じページは、値が要るなら抽出モデル、決まった選択肢から選ぶなら判断モデル、文章が要るなら生成モデル、と使い分けを示しています。請求書の処理で言えば、金額と期限の読み取りがClairic、承認か差し戻しかの判定がClef、差異の説明文がLLMの担当です。判断側の仕様はCloudflare Clefの判断モデル3種の料金とWorkers AI実装で解説しています。

Clairicの料金と9種類のフィールド型と画像入力の上限を公式値で確認

この章の数値は、2026年10月24日に取得した公式のモデルページ・入力スキーマ・料金ページの値です。プレビュー中のため、変わる前提で読んでください。

入力100万トークン0.10ドルと1日1万Neuronsの無料枠のトークン換算

Workers AIの料金ページでは、Clairicは入力100万トークンあたり0.100ドル、9,091 Neuronsです。出力の単価は載っておらず、発表記事も「入力にだけ課金する」としています。

Workers AIは1日1万Neuronsまで無料で、超えた分は1,000 Neuronsあたり0.011ドルです。無料枠をトークンに直すと1日約110万トークンになります。フィールド定義と本文を合わせて1件1,000トークンの請求書なら、無料枠だけで1日約1,100件を読める計算です。

見積もりでは、フィールド定義も入力として数える点に注意します。応答のusageにはstate_tokens・image_tokens・schema_tokens・input_tokensが別々に返るので、試験運用の段階で1件あたりのinput_tokensを記録し、月の件数を掛けて費用を出してください。

textからforecastまで9種類のフィールド型と必須パラメータの違い

Clairicのモデルページで公開されている入力スキーマでは、型は次の9種類です。

型	返る値	主な指定項目
text	入力の一部の文字列	説明文のみ
number	読み取った数値・計算した数値	小数桁・整数指定・単位
date／time／datetime	ISO形式の日付・時刻	説明文のみ
duration	指定単位の期間	単位・整数指定
list	テキスト・数値・日付の配列	要素の型（必須）
estimate	範囲内の分布と中央値・p10・p90	下限・上限（必須）・刻み・尺度
forecast	将来の各時点の分布	下限・上限・先の数・間隔

指定項目のパラメータ名は、小数桁がdecimals（0〜6）、整数指定がinteger、単位がunit（期間はsecondsからyearsまで）、要素の型がitemsです。推定と予測ではmin・maxが必須で、刻みはstep、尺度はscale（linearかlog）、予測の先の数はhorizon（1〜64）、間隔はintervalで指定します。

全型に共通するnull_thresholdは、値をnullにする確率の境目で、既定は0.5です。リクエスト全体では、年の書かれていない日付の基準になるreference_dateと、推定に99個の分位点を加えるoptions.include_quantilesを指定できます。

日本語で設計するときに引っかかるのがフィールド名です。入力スキーマの命名規則は「英字か下線で始まり、英数字と_ . -で64文字まで」で、請求金額のような日本語の名前は使えません。名前はtotal_jpyのような英字にし、日本語の意味はinstructionsに書きます。

画像4枚・1枚4MiB・1パス8,192トークンの上限と並列パスの分割

画像はPNG・JPEG・WebPを1リクエスト4枚まで渡せます。1枚4MiB、デコード後の合計8MiB、リクエストボディ全体は16MiBが上限です。URLを渡して取得させることはできず、data URLかbase64で埋め込みます。

文脈長は65,536トークンです。フィールド数に上限はありませんが、本文と並べて1回の処理（8,192トークン）に収まらないフィールドは、並列の処理に分けて答えを合わせます。応答のusage.passesで分割回数が分かり、truncatedがtrueなら入力が切り詰められています。長い契約書を丸ごと渡すときは、この2つを必ずログに残してください。

Workers AIとREST APIでClairicに請求書の値を抜き出させる実装手順

呼び出し方は2通りです。Cloudflare Workersの中からAIバインディングで呼ぶ方法と、既存の業務システムからREST APIで呼ぶ方法があります。

wrangler.jsoncのAI設定とenv.AI.runで請求書の項目を取り出す例

Workersから使う場合は、Workers AIのバインディング設定に従い、wrangler.jsoncにAIバインディングを足します。

{
  "name": "invoice-extract",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-01",
  "ai": { "binding": "AI" }
}

次のsrc/index.tsは、請求書のテキストを受け取って6項目を取り出し、1つでもnullか信頼度0.9未満の値があれば人の確認に回す印を付けるWorkerです。

export interface Env { AI: Ai }

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { text } = await request.json<{ text: string }>();
    // 応答の型は出力スキーマに合わせて自前で定義する
    const res = (await env.AI.run("@cf/cloudflare/clairic", {
      model: "clairic",
      state: text,
      reference_date: new Date().toISOString().slice(0, 10),
      fields: {
        invoice_number: { type: "text", instructions: "請求書番号" },
        vendor: { type: "text", instructions: "請求元の会社名" },
        issue_date: { type: "date", instructions: "請求書の発行日" },
        due_date: { type: "date", instructions: "支払期限。書かれていなければ発行日と支払条件から計算する" },
        total_jpy: { type: "number", integer: true, unit: "JPY", instructions: "消費税を含む請求金額の合計" },
        items: { type: "list", items: "text", instructions: "明細の品名" },
      },
    })) as any;

    const answers = res.answers;
    const review = Object.entries(answers)
      .filter(([, a]: [string, any]) => a.value === null || (a.confidence ?? 1) < 0.9)
      .map(([name]) => name);

    return Response.json({ needs_review: review.length > 0, review, answers, usage: res.usage });
  },
};

modelはモデルIDと別に必須で、入力スキーマではclairicか@cf/cloudflare/clairicだけを受け付けます。reference_dateを明示しているのは、概念ページが「基準日はモデルに推測させず渡す」ことを推奨しているためです。Workersの料金や無料枠の全体像はCloudflare Workersの料金・無料枠・Workers Paidの中身で確認できます。

curlでのREST呼び出しと日本語の請求書テキストを渡すリクエスト例

Workersの外から呼ぶ場合は、Workers AIのREST API手順でアカウントIDとAPIトークンを用意し、モデルのエンドポイントにPOSTします。

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clairic \
  -X POST \
  -H "Authorization: Bearer $CLOUDFLARE_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "clairic",
    "state": "請求書番号 INV-2026-1042 株式会社サンプル商事 発行日 2026年10月1日 お支払条件 月末締め翌月末払い ご請求金額 132,000円（税込）",
    "reference_date": "2026-10-24",
    "fields": {
      "invoice_number": { "type": "text", "instructions": "請求書番号" },
      "due_date": { "type": "date", "instructions": "支払条件から求めた支払期限" },
      "total_jpy": { "type": "number", "integer": true, "unit": "JPY", "instructions": "税込の請求金額" },
      "po_number": { "type": "text", "instructions": "発注書番号" }
    }
  }'

REST APIの応答はCloudflare共通の形式で包まれ、抽出結果はresultの下に入ります。この例では発注書番号が本文に無いため、po_numberのvalueはnullになるはずです。存在しない値を埋めずにnullで返す点が、生成型のLLMとの大きな違いです。

支払期限のように「計算」が入る項目は、結果をそのまま信用しません。発行日と支払条件も別フィールドで取り出し、期限日はアプリ側のコードでも計算して突き合わせると、モデルの計算違いを拾えます。

領収書の画像をbase64で埋め込みp_nullとconfidenceで人へ回す実装

画像を読ませる場合はimagesにbase64で埋め込みます。stateは画像があれば空でもかまいませんが、補足の文脈を書いておくと読み取りの手がかりになります。

import base64, os
import requests

ACCOUNT_ID = os.environ["CLOUDFLARE_ACCOUNT_ID"]
URL = f"https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/cloudflare/clairic"
HEADERS = {"Authorization": f"Bearer {os.environ['CLOUDFLARE_AUTH_TOKEN']}"}

def read_receipt(path: str) -> dict:
    with open(path, "rb") as f:
        b64 = base64.b64encode(f.read()).decode()
    payload = {
        "model": "clairic",
        "state": "経費精算用の領収書",
        "images": [{"content_type": "image/jpeg", "base64": b64}],  # URLは不可
        "options": {"return_state_text": True},  # spanが指す文字列も受け取る
        "fields": {
            "paid_on": {"type": "date", "instructions": "支払日"},
            "amount_jpy": {"type": "number", "integer": True, "unit": "JPY",
                           "instructions": "支払った税込金額", "null_threshold": 0.2},
            "store": {"type": "text", "instructions": "店名"},
        },
    }
    r = requests.post(URL, headers=HEADERS, json=payload, timeout=30)
    r.raise_for_status()
    ans = r.json()["result"]["answers"]
    amount = ans["amount_jpy"]
    if amount["value"] is None or amount["confidence"] < 0.9:
        # 読めない金額は経理担当へ。guessは確認画面の初期値にだけ使う
        return {"route": "human", "hint": amount.get("guess"), "answers": ans}
    return {"route": "auto", "answers": ans}

金額のnull_thresholdを既定の0.5から0.2に下げています。値が無い確率が20%を超えた時点でnullになるので、かすれた金額を推測で埋めず人に回す側へ倒せます。支払いに直結する項目ほど閾値を下げ、表示用の項目は既定のままにする、という差を付けるのが実務的です。

ClairicとLLM構造化出力やAI-OCRの違いと苦手な計算の見極め

同じ「帳票から値を取る」でも、LLMに型を守らせる方式、AI-OCR製品、Clairicでは得意な範囲が違います。ここでは性能の主張と苦手な処理を、公式の記述から切り分けます。

LLMの構造化出力と比べたときの速度・費用と正しさの保証範囲

発表記事の計測では、顧客対応メールから事実を抜き出す工程が、GLM-5.3の16.1秒に対してClairicは0.46秒でした。Clairic→Clef→GLM-5.3と分担した流れ全体は19.3秒で、GLM-5.3だけの61.7秒より短く、100万件あたりの費用は6,032ドル対11,740ドルで約49%安いとされています。どちらの流れも全試行で事実と判断を正しく出したと書かれていますが、いずれもCloudflare自身の計測で、第三者の再現はまだありません。

形式の保証は両者で似ています。LLMの構造化出力もJSON Schemaで形を守らせられます。違いは、Clairicがテキストの答えを入力の切り出しに限り、p_nullとconfidenceを数値で返す点です。一方で公式は「どの答えも形式は正しいが、正しいとは限らない」と明記しています。LLM側の方式と実装はLLM構造化出力の仕組みとBedrock・各社APIの実装で比べられます。

Clairicに表の複数行の集計や多段計算を任せず読み取りに絞る設計

発表記事はプレビュー版の制約として、読み取りは強い一方で多段の計算はまだ弱いと書いています。合計・差・単位換算・日付の加算のような1〜2段の計算は任せられても、明細の全行を足して小計と照合するような処理は向きません。

そこで設計は次の分担にします。

Clairicには、明細の金額をlist型の数値で、合計欄の金額をnumber型で、それぞれ「書かれた値」として取らせる
明細の合算と合計欄との照合は、アプリ側のコードで行う
一致しない帳票と、どれかの値がnullの帳票を、人の確認キューに入れる

推定と予測の機能も、業務の数値の代わりにはしません。発表記事は予測について、個別データで学習した時系列モデルを置き換えるものではないとしています。

Clairicの日本語対応が未公表な状態で自社帳票の正答率を測る手順

モデルページ・概念ページ・発表記事のどれにも、対応言語や日本語の精度の記載はありません（2026年10月24日時点）。発表記事の例もすべて英語です。日本語の帳票を流す前に、次の順で評価します。

人が正解を入力した過去の請求書・注文書を、取引先の書式が偏らないよう100〜200件そろえる
instructionsを日本語で書いた版と英語で書いた版の2通りで投げ、項目ごとの正答率を比べる
正解と不正解に分けてconfidenceとp_nullの分布を描き、不正解が集まる帯を確かめる
その帯より下を人へ回す閾値を項目ごとに決め、自動で処理できる割合と月の費用を見積もる

1件1,000トークンなら200件で約20万トークンです。無料枠の1日約110万トークンに収まるので、評価そのものに費用はかかりません。

Clairicを採用する業務条件とAI-OCRや汎用LLMを選ぶ見送りの場面

料金・仕様・制約を踏まえ、採用と見送りの線を引きます。

メールや問い合わせ文から項目を大量に抜き出す処理でのClairic採用条件

採用してよいのは、入力がすでにテキストか鮮明な画像で、取り出す項目が事前に決まっていて、同じ処理を大量に繰り返し、信頼度の低い分を人に回す経路を作れる処理です。具体的には次のような業務が当たります。

受注メール・問い合わせフォームの自由記述から、注文番号・希望納期・数量を取り出す
電子で届く請求書PDFのテキストから、請求元・金額・支払期限を取り出して会計システムへ渡す
Cloudflare Workersで動くシステムの中で、外部のLLM APIを増やさずに項目を抜き出したい

判定まで自動化するなら、Clairicで抜いた値をClefに渡す構成が発表記事の想定です。決まった選択肢から選ぶ判断を担う系統の比較はTypeSafe Jevの料金・API実装・採用条件にまとめています。LLMで同じ抽出を組む方式はLangExtractの使い方と日本語抽出の落とし穴が比較の材料になります。

紙の帳票の文字認識・説明責任・本番の不可逆処理が要件なら見送る判断

次のどれかに当たるなら、Clairic単体では採用しません。

紙をスキャンした帳票が中心で、手書きや傾き・かすれへの対応が要る（文字認識はAI-OCRの役割）
帳票の画像上で項目の座標を返し、枠に重ねて表示する必要がある（返るのは文字位置で、画像座標ではない）
抽出の根拠を文章で説明する必要がある
プレビュー版の仕様変更を許容できない本番の支払処理に、人の確認なしで直結させる

最後の点は、概念ページも「重要で取り消せない操作の前には、他の根拠との照合や人の確認を検討する」と書いています。抽出した金額で振込を実行するような処理では、Clairicを一次の読み取りにとどめ、照合と承認を必ず挟みます。

紙の非定型帳票を扱う場合、全体の精度の上限を左右するのはOCRで文字にする段の精度です。読み取りの仕組みと項目マッピングの考え方はAI-OCRで非定型帳票を読み取る仕組みと精度確保の判断基準で解説しています。OCRとClairicのような抽出モデルをどう組み合わせ、既存の業務システムへどうつなぐかから相談したい場合は、AI-OCR導入支援のページで対応範囲を確認できます。

Clairicの料金・日本語・AI-OCRとの違いについてよくある質問

検索されることの多い疑問に、2026年10月24日時点の公式情報で答えます。

Clairicは無料で使えますか？

Workers AIの無料枠の範囲なら使えます。1日1万Neuronsまで無料で、Clairicは入力100万トークンが9,091 Neuronsにあたるため、1日約110万トークンまでが無料です。出力トークンは課金されません。無料のWorkers Freeプランは1日1万Neuronsを超えて使えないので、本番の量を流すならWorkers Paidに登録し、超過分を1,000 Neuronsあたり0.011ドル、入力100万トークンで0.10ドルの単価で支払います。

Clairicは日本語の帳票やメールを読み取れますか？

公式のモデルページ・概念ページ・発表記事のいずれにも、対応言語や日本語の精度の記載はありません。発表記事の検証例も英語です。入力スキーマ上は日本語のテキストをstateに渡せますが、フィールド名は英数字に限られます。正解付きの自社帳票を100〜200件用意し、項目ごとの正答率とconfidenceの分布を測ってから、自動で処理する範囲を決めてください。

ClairicはAI-OCRの代わりになりますか？

なりません。役割が違います。Clairicは画像も受け付けますが、返る位置情報は入力テキストの文字位置で、帳票画像上の座標ではありません。手書き・傾き・かすれへの対応や読み取り枠の定義といった文字認識の機能も持っていません。紙の帳票はAI-OCRでテキストにし、そのテキストから必要な項目を型付きで取り出す段にClairicを使う、という組み合わせが現実的です。

ClairicとCloudflare Clefは何が違いますか？

どちらも文章を生成しないSystem One型のモデルですが、返すものが違います。Clefは定義した選択肢から選ぶ判断モデルで、選択肢ごとの確率を返します。Clairicは金額・日付・テキスト・リストといった値そのものを返す抽出モデルです。請求書なら、金額と期限の読み取りをClairic、承認か差し戻しかの判定をClefに任せる分担になります。料金はClairicが入力100万トークン0.10ドル、Clef-flashが0.038ドルです。

Clairicを自社のサーバーで動かせますか？

2026年10月24日時点では動かせません。提供はWorkers AIのホスト版だけで、発表記事は重みのオープンウェイト公開を「近日」としているものの、日程は示していません。機密性の高い帳票を外部に送れない要件なら、公開と同時にライセンスと動作環境を確認するまで、オンプレミスのAI-OCRなど別の方式で組むのが安全です。