Clairicとは?Cloudflareの抽出モデルを選ぶ基準・検証手順・実装時の注意点

AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか?
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
Clairicは、CloudflareがWorkers AIでプレビュー提供している抽出モデルです。自由文を生成するLLMとは異なり、入力したテキストや画像から、名前・金額・日付・期間・リストなどの型付きの値を返します。値の抽出だけでなく、入力にある事実からの計算、根拠を伴う推定、時系列の予測も対象です。CloudflareのClairicモデル仕様
先に結論を述べると、Clairicを検討しやすいのは、「自由な文章を書く」よりも「非構造の文書から、後続システムが使える項目を一定の形式で取り出す」処理です。請求書からの金額・支払期日抽出、メールからの受付番号・期限の取得、画像化された帳票からの項目取得などが候補になります。一方、顧客への説明文作成、長い文書の要約、例外理由の記述などは、Clairic単体の担当範囲ではありません。
本記事は、2026年10月20日にCloudflareの公式ドキュメントを確認して編集しています。Clairicはプレビューであり、継続提供は保証されていません。未公開のオープンウェイト版を利用可能とは扱いません。ここで示す評価手順、判定表、テンプレートは、特記がない限りMojiによる実務上の提案です。
Clairicとは:型付きの値を返す抽出モデル
ClairicのモデルIDは@cf/cloudflare/clairicです。Cloudflare-hostedのWorkers AIモデルとして提供され、テキストに加え、PNG・JPEG・WebP画像を入力できます。モデル仕様では、コンテキストウィンドウは65,536トークン、画像は1リクエストあたり最大4枚と案内されています。Clairicの入力上限・APIパラメータ
利用側は、読み取らせる入力をstate、返してほしい項目をfieldsとして定義します。たとえばinvoice_totalを数値・USD・小数点以下2桁、due_dateを日付、と指定する形です。返答には項目ごとの値だけでなく、抽出・計算結果にはconfidenceやp_null、推定・予測には分布やパーセンタイルが含まれます。
Clairicが扱う4種類の処理
処理 | 意味 | 向く例 | 導入時の確認点 |
|---|---|---|---|
抽出 | 入力に明記された値を取り出す | 請求書番号、氏名、明記された合計額 | 原文上の根拠位置と照合できるか |
計算 | 入力の事実を使って値を導く | 発行日と支払条件から支払期日を算出する | 計算が長い連鎖・大量行集計になっていないか |
推定 | 入力の証拠を基に未知の値を見積もる | 支払までの日数の見積もり | 推定を確定値として後続処理へ渡していないか |
予測 | 将来の時点ごとの値を返す | 短期の残高推移の予測 | 専門的な時系列予測の代替にしていないか |
この区別は重要です。「文書に書かれた金額を抽出する」失敗と、「将来の支払日を推定する」失敗は、同じ正解率や承認基準で扱えません。Cloudflareも、型や制約が出力形式を整えても、回答の正しさ自体を保証するものではないと説明しています。Cloudflare: Extraction modelsの概念と制約
LLM・判断モデルとの比較:何を返したいかで分ける
モデル選定では、「どれが高性能か」よりも、最終的に必要な出力が値・選択肢・文章のどれかを先に決めます。これは一般的な設計上の目安であり、実際の結論は入力品質、対象言語、帳票レイアウト、評価指標、許容誤差によって変わります。
選択肢 | 主な出力 | 向く仕事 | 単独利用で避けたい仕事 |
|---|---|---|---|
Clairic | 型付きの値、確信度、推定分布 | 金額・日付・期限・項目の取得、軽い計算 | 自由文の説明、複雑な多段推論、確定処理 |
判断モデル | 事前定義した選択肢からの選択 | 「承認・要確認・却下」などの振り分け | 選択肢にない値の抽出 |
生成AI/LLM | 自由形式の文章・コード・要約 | 説明文、例外理由の整理、対話、要約 | 型の整合だけで正確さが要求される確定処理 |
たとえば請求メールを受ける業務なら、Clairicで金額・支払期日・発注番号を取得し、ルールまたは判断モデルで処理区分を決め、必要な場合だけLLMで担当者向けの説明文を作る、という分離が考えられます。AIエージェントで外部処理まで進める場合は、モデル出力の正確さだけでなく、承認・停止・監査を設計してください。AIエージェントのガードレール設計
Clairicを選ぶための5つの判断基準
- 成果物は項目値か
後続処理で必要なのが「担当者への説明」ではなく、「日付」「金額」「ID」「期間」のような項目なら候補になります。 - 正本となる入力があるか
抽出対象の原文、画像、帳票があり、抽出値を照合できることが望ましい条件です。曖昧なメール本文だけで支払い可否を確定する用途には、そのまま使いません。 - 失敗時に保留へ戻せるか
誤抽出しても下書き・要確認キューへ戻せるなら試験対象にしやすく、送金・契約更新・外部送信のような不可逆操作は人の承認を残すべきです。 - 計算をコードへ分離できるか
多段計算や多数行の合計は、抽出した値をアプリケーションコードで検算する設計を優先します。Cloudflareも、長い依存計算や表の多行集計には注意を促しています。Cloudflare: Extraction modelsの設計・制約 - 評価用の正解データを用意できるか
モデルのデモではなく、自社の文書形式・表記揺れ・例外を含む評価セットで、項目ごとに合否を判定できることが本番判断の条件です。
PoCの進め方:1項目・1業務・可逆な処理から始める
最初から帳票処理全体を自動化せず、1種類の文書から3〜5項目を抽出し、結果を人が確認する小さな範囲で検証します。以下はMojiによる提案です。
手順1:対象業務を「抽出」「判断」「実行」に分解する
- 抽出:原文から何を取るか(例:受付番号、依頼日、金額)
- 判断:どの条件で要確認にするか(例:金額が上限超過、根拠なし、期限切れ)
- 実行:何を更新・送信・登録するか
この3つを同じモデル呼び出しへ任せると、どこで誤りが起きたかを切り分けにくくなります。AIシステムの導入対象・人の確認・ログを含めた考え方は、AIシステムとは?できること・導入事例・開発の流れ・費用の考え方も参照してください。
手順2:フィールド定義を仕様書にする
フィールド名だけでなく、「どの値を」「何を含めて」「どの単位で」返すかを決めます。特に合計額、税額、支払額、請求額のような近い概念は、説明文で境界を明確にします。
// 架空の例:保守依頼メールから値を抽出するfield定義
{
"ticket_id": {
"type": "text",
"instructions": "依頼本文に明記された受付番号。推測しない"
},
"requested_date": {
"type": "date",
"instructions": "依頼者が希望した作業日。年が省略されている場合はreference_dateを基準にする"
},
"quoted_amount": {
"type": "number",
"unit": "JPY",
"decimals": 0,
"instructions": "値引き後・税を含む見積総額。金額が書かれていなければnull"
}
}上記は架空の例です。実装時は、CloudflareのAPI仕様にあるstate、fields、必要に応じてreference_dateを使います。stateが空の場合でも画像を渡す条件、画像形式・容量、リモートURL非対応などの制約は、実装前に公式仕様で確認してください。Cloudflare: Clairic API仕様とリクエスト例
手順3:評価データを3層に分ける
評価層 | 含めるデータ | 見る指標 | 失敗時の対応 |
|---|---|---|---|
通常ケース | 記載位置・表記が標準的な文書 | 項目完全一致率、null判定の正しさ | フィールド指示・前処理を見直す |
境界ケース | 複数の金額、年省略、表記揺れ、複数候補 | 誤採用率、根拠提示の確認率 | 要確認へ送る条件を強化する |
禁止ケース | 記載なし、判読困難、矛盾、対象外帳票 | 誤った非null返却率 | 自動実行を止め、null・保留の経路を修正する |
比較の結論は、モデル名だけでは決まりません。入力品質、対象文書の種類、評価指標、許容誤差、誤りが起きたときの影響で変わります。RAGやLLMを含む評価設計の基本は、AIの評価とは?評価指標や評価方法、その費用についても参考にしてください。
手順4:合否基準を開始前に決める
PoCの開始前に、少なくとも次の4点を文章化します。
- 項目ごとの正解条件:完全一致、日付形式変換を許容、単位換算を許容するか
- nullの扱い:情報がないときにnullを返せた場合を正解とみなすか
- 自動化の境界:どの条件なら下書き作成まで、どの条件なら人の確認必須か
- 停止条件:特定項目の誤り、根拠なしの非null、処理遅延、運用担当者の確認負荷が基準を超えた場合に停止するか
確信度を自動承認の根拠にしない
Clairicは確信度やnull確率を返しますが、それだけで正解が保証されるわけではありません。Cloudflareは、推定・予測の不確実性が保証ではなく、結果が型や制約を満たしていても質問に誤って答える可能性があると明記しています。Cloudflare: 不確実性と正確性に関する注意
そのため、Mojiでは次のように扱うことを提案します。
結果の状態 | 例 | 推奨する次の処理 |
|---|---|---|
高確信・原文照合可能 | 抽出した受付番号が原文spanで確認できる | 下書き・候補データとして登録。重要操作は別途承認 |
低確信またはnull | 金額候補が複数、必要項目が見つからない | 人の確認キューへ送る。推測値で埋めない |
推定・予測 | 修理費や支払日の見積もり | 予測値として表示し、確定値・承認条件には直接使わない |
矛盾・対象外 | 通貨と合計が一致しない、帳票種類が異なる | 処理を停止し、例外として記録する |
料金・提供状況・データ取り扱いの確認項目
2026年10月20日時点で、CloudflareのモデルページではClairicはプレビューで、入力100万トークンあたり0.10米ドルと案内されています。Workers AIの価格表でも@cf/cloudflare/clairicは入力100万トークンあたり0.10米ドル、9,091 Neuronsとして掲載されています。実費は、入力文書量だけでなく、フィールド定義や複数パスを含む実際のusage.input_tokensで見積もってください。Cloudflare Workers AIの価格表
概算式は次のとおりです。
Clairic推論費用の概算(米ドル)
= 実測した input_tokens ÷ 1,000,000 × 0.10これはClairic推論部分だけの架空の計算式です。Worker実行、保存、OCR・文書変換、監視、後段のLLM、ネットワーク転送などの費用は別に評価します。
機密情報を含む文書を扱う場合は、価格だけで決めません。Cloudflareは、標準的なステートレス推論では、入力・出力をリクエスト処理と応答に必要な期間を超えて保持しないこと、顧客コンテンツをAIモデルの学習に使わないことを案内しています。一方、AI Gatewayのログ・キャッシュ、ストレージ、非同期・バッチなど、選んだ機能によっては保存が発生し得ます。自社の設定、契約、データ分類、保存先を個別に確認してください。Cloudflare Workers AIのデータ利用方針
導入前チェックリスト
- 抽出したい値が、文章生成ではなく型付きの項目として定義できている
- 抽出・判断・実行を別工程として設計している
- 各フィールドに、単位、精度、含める範囲、null条件を定義している
- 通常・境界・禁止ケースを含む正解付き評価データを用意している
- confidence、p_null、推定区間を、正解保証ではなく振り分け材料として扱う
- 多段計算・大量行集計はコードまたは別の検算工程へ分離している
- 送金、契約、外部送信、権限変更などの不可逆操作に人の承認を残している
- プレビュー機能であることを前提に、モデル仕様変更・提供終了時の代替経路を決めている
- ログ、キャッシュ、保存先、アクセス権限を含めてデータフローを確認している
- 本番後も、項目別の誤り・null率・確認負荷を監視する担当者と頻度を決めている
まとめ
Clairicは、非構造なテキスト・画像から後続処理に使う値を取り出すためのCloudflare Workers AIの抽出モデルです。重要なのは、型付きの出力を「正しい出力」と混同しないことです。抽出値を原文と照合できるか、null・低確信・矛盾を安全に保留できるか、計算・判断・実行を分離できるかを確認してから、限定的なPoCへ進めてください。
公式仕様として確認できるのは、Cloudflareがホストするプレビューの提供内容です。この記事では、第三者の独立実測値を採用していません。速度・精度・費用対効果は、自社の文書、対象言語、許容誤差、確認フローを用いた評価で判断する必要があります。