鵜呑みにしなくていいAI OCR
space-ocr はモデルで書類を構造化し、各値をページ上で OCR が検出した文字と照合します。data.cells[path] に box・quad・verified・review が入り、確認すべき項目は data.review.flagged に並びます。
AI OCR は、散らかった書類への答えのように聞こえます。領収書や請求書をモデルに渡せば、きれいな構造化フィールドが返ってくる、と。問題は、モデルが間違ったときに何が起きるかです。言語モデルは、実際にページから読み取ったかどうかにかかわらず、自信ありげに整った値を返します。そしてほとんどのツールは、その違いを見分ける手段を渡さないまま値を渡してきます。
space-ocr は役割を分けます。構造化はマルチモーダルモデルが担いますが、モデルは座標を作りません。座標の出所は、ページを読む OCR パスだけです。抽出された値は、その OCR が検出した文字と一字ずつ突き合わされます。返るデータも同じように分かれています。業務データは宣言したスキーマのまま data.values に、同じパスの box・quad・判定 verified・review の理由・裏づけの evidence は data.cells[path] に入ります。内部でどの OCR やモデルの実装が動くかは変わりうる実装の詳細で、固定しているのはレスポンスの構造です。
AI の出力を、検証済みで見る
下のフィールドにマウスを合わせてみてください——領収書上のボックスは、その値がページ上で実際に見つかった場所であって、モデルが主張した場所ではありません。ここにある値・ボックス・検証表示はすべて、実際の解析結果から読み込んだもので、モックアップではありません。
Each value with a box carries a verified on-page location — in data.cells[path], that is box + 4-point quad + evidence.match_ratio — on a 0–1000 normalized grid (0,0 top-left → 1000,1000 bottom-right), the same shape the live API returns. Hover a field to trace it back to the pixels it came from.
space-ocr での AI OCR の仕組み
POST /ocr/fields に画像を送ります（imageType は url か base64）。まず OCR パスがページを読み、これが座標の唯一の出所です。マルチモーダルモデルは宣言したスキーマに沿って書類を読み、値だけを返します。その値を検出済みの文字と一字ずつ照合した結果が、data.cells[path] の box・quad・evidence になります。
verified は文字スコアではなく判定です。理由の種類を問わず review が立てば false、照合が走って何も立たなければ true、照合する対象がなければ null になります。文字の一致そのものは evidence.text_match にあります。そのため verified: false と text_match: true が同時に立つのは矛盾ではなく、「文字は合っていたが、宣言した規則が捕まえた」という正常な組み合わせです。
こうして黙って通り過ぎる不一致が表に出ますが、すべての誤りを捕まえると約束するものではありません。モデルと OCR パスは独立していても、同じ誤読で一致することはあり得ます。座標は値の出所を示す証拠であって、値が正しいことの証明ではないので、業務側の検算は残してください。
スキーマを書く必要はありません。fields を宣言するか、autoFields を立ててモデルに構造を提案させます。Web アプリは PDF をページごとに画像化してから読み、公開 API はラスター画像を直接受け取ります。
curl -s https://api.space-ocr.com/ocr/fields \
-H "Authorization: Bearer $SPACE_OCR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"image": "https://example.com/receipt.jpg",
"imageType": "url",
"fields": [
{ "name": "store_name", "type": "string", "required": true },
{ "name": "date", "type": "date", "required": true },
{ "name": "total", "type": "number", "required": true, "min": 0 },
{
"name": "items",
"type": "array",
"children": [
{ "name": "name", "type": "string" },
{ "name": "amount", "type": "number" }
]
}
]
}'検証できるAI OCRを動かす手順
- 書類を送る画像を /ocr/fields に送ります（imageType は url か base64）。アプリでは PDF をドロップでき、各ページが先に画像化されます。公開 API はラスター画像を受け取ります。
- スキーマを宣言するname・type・children を持つ fields を渡すか、autoFields を立ててモデルに構造を提案させます。規則が要る箇所には required・pattern・min・max・enum・near を添えます。
- 検証済みの結果を読む業務データは data.values、box・quad・verified・review・evidence は data.cells[path]、宣言したスカラー型の解析値は data.normalized、ピクセル換算の基準面は data.image にあります。
- 確認キューを処理するdata.review.flagged を回し、reasons[0] を代表理由として扱い、そのセルの box または quad をページに重ねて、値の出所を確認できるようにします。
- 保存して照会するPOST /create と POST /upload で結果をシートに残し、GET /view の where・sort・select・limit で読み返します。この読み出しは課金されず、OCR も再実行されません。
シンプルで予測できる料金
1 クレジット = 1 ページ処理 = ¥10（税込）。毎月 100 クレジットは無料で、カード登録は不要です。失敗時は課金なし。保存済みデータの読み出し（GET /space・GET /view・GET /jobs）は無料です。定額プランは月間クレジット数・シート数・ストレージを追加します。