検証できるバウンディングボックスを返すOCR API
ほとんどのOCR APIはバウンディングボックスを返します——しかし座標系はそれぞれ異なり、ボックスは「どこか」は教えても「どれだけ確かか」までは教えてくれません。ソース座標付きのOCRを扱う開発者向けガイド。各値がページ上で実際にどれだけ見つかったかを示すマッチ率まで解説します。
バウンディングボックスは、OCRを検証するための手段です。素の文字列は、モデルが何を読んだと考えているかを教えるだけ。ボックスは、それをページ上のどこで読んだかを教えてくれるので、あなた（あるいはレビュー担当者やコード）は、その値を盲信せずに原本と照らし合わせて確認できます。請求書、経費、KYC、記録管理など、監査の対象になる何かにOCRを組み込むなら、「モデルが total: 2,045 を返した」だけでは不十分です。その 2,045 がどのピクセルから来たのかを指し示せなければなりません。
朗報は、主要なOCR APIのほとんどがバウンディングボックスを返してくれることです。問題は、いざ構築を始めると効いてくる3つの点で違いがあること——座標系、（生テキストだけでなく）構造化フィールドも得られるかどうか、そして値ごとの信頼度が実際に何を測っているか、です。このガイドではこの3点をすべて解説し、ソース座標と文字カバレッジに基づくマッチ率を返すOCR APIが実際にどのようなものかをお見せします。
まずは証拠：ホバーできるボックス
ここに、すべての値が、それが読み取られた正確な領域を指し示す実際の抽出結果があります。どのフィールドでもマウスを合わせてみてください——領収書上のボックスがその値の出どころであり、それぞれに、値のテキストのうち実際にページ上で見つかった割合を示すマッチ率が付いています。
Every value carries a verified on-page location — bbox + 4-point vertices + 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.
ほとんどのOCR APIはボックスを返す——その違いはここにある
Google Cloud Vision、Tesseract、Amazon Textract、Azure AI Document Intelligence は、いずれもテキストとともにジオメトリ（形状情報）を返します。違いが出るのは、座標系、構造化フィールドが得られるのか生テキスト＋レイアウトだけなのか、そして信頼度の数値が何を意味するか、です。これらはマーケティングではなく検証済みの事実です——自分のスタックでの統合作業量を見積もるのに役立ててください。
| API | 座標系 | 構造化フィールド | 値ごとの信頼度 |
|---|---|---|---|
| Google Cloud Vision | ソース画像のピクセル単位の boundingPoly 頂点 | テキスト＋ジオメトリのみ（構造化されたキー・バリューは別製品の Document AI） | 単語/シンボルごとの認識信頼度（0〜1） |
| Tesseract | ピクセル単位の hOCR / TSV ボックス（セルフホスト、APIなし） | なし——生テキスト＋レイアウト | 単語ごとの認識信頼度（0〜100） |
| Amazon Textract | ページの幅・高さに対して0〜1で正規化された BoundingBox（＋ Polygon） | AnalyzeDocument によるフォーム/テーブル、AnalyzeExpense による領収書 | ブロックごとの認識信頼度（%） |
| Azure Document Intelligence | ピクセル（画像）またはインチ（PDF）単位のバウンディングポリゴン | 事前構築/カスタムモデル | 単語ごとの認識信頼度 |
| space-ocr | 0〜1000で正規化された bbox（＋回転対応の vertices） | 組み込みテンプレート＋カスタムフィールド、明細行対応 | match_ratio——値の文字のうちページ上で見つかった割合——＋ bbox_source |
注目すべき点が2つあります。第一に、座標の単位は移植できないこと——Vision/Tesseract/Azure のピクセルボックスは、送信した画像そのものに紐づきますが、正規化されたボックス（Textract、space-ocr）はリサイズしても有効なままです。第二に、信頼度の列が意味するものは異なること——ほとんどのAPIは認識信頼度（モデルがどれだけ自信を持っているか）を報告しますが、これは、返された値がページ上で実際にどれだけ見つかったかを測ることとは別物です。
ボックスがどう導き出されるかは、その形式と同じくらい重要です。 space-ocr では、言語モデルは各フィールドのテキストと——どの単語トークンを使ったかのヒントを——返しますが、ボックスそのものは決して返しません。エンジンはそのテキストを、ビジョンOCRがページ上で実際に検出したシンボルと文字単位で照合します。だからこそボックスは、それらの文字が見つかった実際のピクセルに配置され、各値にはどれだけ見つかったかを示す match_ratio が付きます。トークンのヒントはノイズを含むことがあり（繰り返し行の間で取り違えることがあります）、そのため鵜呑みにせず、列・行の整合性チェックで検証します。これが、モデルが主張する座標と、ページに対して照合し直した座標との違いです。
space-ocr がすべての値に対して返すもの
抽出された各値とともに4つの情報が返るため、座標が「ただ信じるしかない数字」になることは決してありません。
bbox— 0〜1000で正規化されたグリッド上の、整数からなる軸並行矩形{ xmin, ymin, xmax, ymax }（0,0 = 左上、1000,1000 = 右下）。画像のピクセルサイズに依存しません。vertices— 書類の傾きに沿った回転対応ボックスを形作る、順序付きの4点（左上、右上、右下、左下）。傾いたスマホ写真でもきれいに枠が付きます。match_ratio— その値の文字のうち、実際にページ上で見つかった割合（0〜1）。フィールドは 0.85以上 で確実にマッチしたものとして扱われ、1.0はすべての文字が見つかったことを意味します。bbox_source— 座標がどう導き出されたかを示すラベル（例：文字照合の経路を表すvision_symbol_match、マッチ率がしきい値を下回ったときのlow_confidence）。
{
"total": {
"value": "2,045",
"bbox": { "xmin": 381, "ymin": 803, "xmax": 500, "ymax": 825 },
"vertices": [
{ "x": 380, "y": 804 }, { "x": 500, "y": 801 },
{ "x": 500, "y": 823 }, { "x": 381, "y": 826 }
],
"match_ratio": 1.0,
"bbox_source": "vision_symbol_match"
}
}ピクセルか、正規化か？一度変換すれば、リサイズで壊れなくなる
OCR統合でよく起きるバグが、ピクセル座標がアップロードした画像そのものに紐づいていることです——保存のためにリサイズや再圧縮をしたり、EXIFの回転フラグを見落としたりすると、重ねたボックスがずれたり、切れたり、別のテキストに乗ってしまったりします。正規化座標なら、この種のバグをまるごと回避できます。0〜1000のボックスは、同じページのどんなレンダリングにもマッピングできるからです。
表示中の画像にボックスを描くには、一度だけ変換します。
- SVGオーバーレイ — SVGに
viewBox="0 0 1000 1000"を与え、bbox/verticesをそのまま描きます。 - 絶対配置のdiv —
leftPct = xmin / 1000 * 100、topPct = ymin / 1000 * 100、widthPct = (xmax - xmin) / 1000 * 100、heightPct = (ymax - ymin) / 1000 * 100。 - ピクセルへ戻す —
pixel_x = bbox_x / 1000 * image_width、pixel_y = bbox_y / 1000 * image_height。
エンジンは読み込み時にEXIFの向きも適用するため、返される座標はすでに表示画像と一致しています——回転したスマホ写真（向き 6/8）でも、あなたの側で補正処理をする必要はありません。
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": "vendor", "type": "string" },
{ "name": "total", "type": "string" }
]
}'信頼度スコアとマッチ率は、同じものではない
これは身につけておく価値のある区別です。ほとんどのOCR APIは認識信頼度を提供します——これはフォントの鮮明さや画質などをもとに、エンジンが自分の読み取りにどれだけ自信があるかを表す数値です。有用ではありますが、モデルが自分の答案を自分で採点しているようなものです。マッチ率は、外側の何かを測ります——モデルが返した値の文字のうち、ページ全体のOCRが検出したシンボルの中で実際に見つかったのは何文字か、です。値は認識信頼度付きで返されても、ページ上の何にも一致しないことがあり得ます。低い match_ratio は、まさにそれを捉えます。これをゲートとして使いましょう——match_ratio < 0.85 でソートまたはフィルタリングすれば、すべてを再確認する代わりに、人の目で見るべき一握りの値だけを浮かび上がらせられます。
検証してから、OCRを再実行せずにクエリする
座標は、データが残り続けてこそ最も役立ちます。POST /upload で画像をシートに投入し、GET /view でサーバー側からクエリします——where、sort、select、limit、offset——たとえば match_ratio が低い行や total >= 40000 の行をすべて取り出すといったことが、OCRの再実行も追加課金もなしに行えます。返される各値は bbox/vertices を保持します（boxes=0 で外して軽いペイロードにもできます）。検証ワークフローの詳しい解説は、バウンディングボックスによるOCRの検証とOCR監査証跡をご覧ください。
APIから検証可能なバウンディングボックスを得る手順
- フィールドをリクエストする画像を、imageType を 'url' または 'base64' にして /ocr/fields へPOSTし、templateId か独自の fields 配列のどちらかを指定します。エンジンはラスター画像（JPEG、PNG、GIF、BMP、TIFF、WebP）を受け付けます。
- 座標を読む各値は、0〜1000グリッド上の bbox { xmin, ymin, xmax, ymax }、回転対応の4頂点、match_ratio、bbox_source を返します。
- 重ねる、または変換するSVG の viewBox '0 0 1000 1000' でボックスを描くか、pixel_x = bbox_x / 1000 * image_width でピクセルに変換します。EXIF回転はすでに適用済みなので、ボックスは表示画像と一致します。
- マッチ率でゲートするmatch_ratio が0.85以上なら確実にマッチしたものとして扱い、それを下回るものは、すべての値を再確認する代わりに人の目で見るべきものとして浮かび上がらせます。
- 保存してクエリする/upload で画像をシートに投入し、GET /view（where、sort、select）でクエリします——座標は保持され、OCRの再実行も追加料金もありません。