領収書・請求書に最適なOCRソフトの選び方

紙の書類を扱うすべての会社が、領収書と請求書を扱っています——そしてどちらも手入力するのは本当に苦痛です。OCRが約束するものは明快です。書類を撮影し、構造化データを受け取り、次の作業へ進む。問題は、ほとんどのOCRツールがそれらしい結果で止まってしまうことです。取引先名と合計金額を渡され、あとはそれを信じるしかありません。個人の経費メモならそれで十分でしょう。しかし買掛金管理や経費の突合、あるいは監査の対象になる業務では、「AIがそう言ったから」という説明は、自分の名前で通せる答えにはなりません。

このガイドは選定チェックリストです。派手なデモではなく、領収書・請求書に最適なOCRソフトを本当に分けるポイント——検証可能な精度、明細行の抽出、きれいなエクスポート、Webhookを備えた本物のAPI、監査証跡、そして予測できる料金——を一つずつ確認し、space-ocrがそれぞれをどう実現しているかを、スクリーンショットではなく実際に確認できるライブデモでお見せします。

まずは証拠から：その場で確認できる実際の抽出結果

機能の話に入る前に、多くのベンダーが見せたがらないものをお見せします。それは、すべての値が、ページ上のどこから読み取られたかを正確に指し示す抽出結果です。下のフィールドにマウスを合わせてみてください——領収書上に表示される枠が、その値が読み取られた場所です。

領収書・請求書OCRで見るべきポイント

領収書と請求書は、「簡単そうに見えて最も難しい」書類です。レイアウトは取引先ごとにばらばら、合計金額は小計や税額の行に紛れ、明細は折り返し、スマホ写真は傾いて反射が入って届きます。きれいなPDF1枚なら完璧に処理できるツールが、次のしわくちゃの感熱紙レシートで崩れることも珍しくありません。マーケティング文句に惑わされないよう、次の基準を使ってください。

この記事の残りでは、各行を順番に取り上げていきます。

検証可能な精度は、信頼度スコアに勝る

信頼度スコアは、モデルが「自信あり」と感じていることを教えてくれます。しかし、total: 2,045 が領収書に実際に印字された数字かどうかは教えてくれません。space-ocr はもっと厳しい問いに答えます。業務データは data.values に返り、そこへのパス（total、line_items[0].unit_price）がそのまま data.cells の項目を指します。

• box — 0〜1000に正規化されたグリッド上の軸並行矩形 { xmin, ymin, xmax, ymax }（0,0 = 左上、1000,1000 = 右下）。ピクセルへの換算には、実際に読んだ紙面の寸法を持つ data.image を使います。
• quad — 書類の傾きに沿う順序付きの4点。box と必ず併せて返ります。傾き補正はしないため、斜めのスマホ写真でも枠は紙面どおりに付きます。
• verified — 判定です。検討理由が付いたセルは false、照合が走って何も立たなければ true、照合する相手が無ければ（明細行のユニオンボックスなど）null になります。
• review — null か、確認すべき理由を並べた { reasons } のどちらかです。
• evidence — 判定の裏付けです。文字照合そのものの結果 text_match、値の文字がどれだけ紙面上で見つかったかを表す match_ratio、その座標で OCR が読んだ生の文字 printed_text が入ります。

確認の作業リストは data.review.flagged です。{ path, reasons } の配列で、path は cells のキーと同じ文法なので該当セルをそのまま引けます。位置情報が値とともに付いてくるため、ボックスを描画したり、座標を引用したり、フラグの立ったフィールドを再確認したりするのに、OCRを再実行する必要がありません。これがOCR監査証跡の土台であり、上のデモがモックアップでない理由でもあります。

合計だけでなく、明細行まで

安価な領収書OCRで最も大きく欠けているのが、テーブルです。総合計を拾うだけなら誰にでもできます。価値があるのは明細行——商品ごとの数量、単価、値引きです。space-ocr はこれらを繰り返し行として抽出し、各セルがそれぞれの位置を保持するため、折り返しや結合された明細行でも追跡できます。

明細行は、1行を children で記述した type: "array" のフィールドとしてリクエストします。明細行モデルのより詳しい解説は請求書からの明細行抽出をご覧ください。

必要なフィールドだけ宣言する——決まっていなければ autoFields

抽出スキーマは fields 配列で渡します。自社のデータベースに実際に入る項目だけを名前と型で並べ、明細行は1行分を children で記述した type: "array" として宣言します。どんな項目が載っているか分からない段階では、代わりに autoFields: true を送ればモデルがスキーマを提案します——返ってきた名前をそのまま固定の宣言に移せば、本番用の呼び出しになります。

宣言は精度の調整つまみではありません。required・pattern・min/max・enum・near・not_near はいずれもモデルには渡らないため、抽出される値は宣言してもしなくても同じです。増えるのは二つです。規則を破った値が理由（missing・pattern_mismatch・out_of_range・near_mismatch・near_conflict）とともに data.review.flagged に載ること、そして number・integer・date を宣言すると values の隣に data.normalized が並ぶことです——同じ読みを決定的に解釈した層なので、同じ紙面なら毎回同じ数値になります。near・not_near は、会社名が2社印字された帳票で正しい方を選ばせる機能ではありません。選び間違いを見えるようにする手立てです。

呼び出しはHTTPリクエスト1回だけ——SDKもPDFの前処理も不要です（エンジンが読むのはラスター画像、つまり写真やスキャンです）。

エクスポートとAPI：データの行き先

抽出も、データがツールに閉じ込められたままでは無価値です。space-ocr はきれいな出口を2つ用意しています。

• CSV — シートはUTF-8 BOM付きでエクスポートされるため、Excelが日本語・韓国語・中国語のテキストを正しく開きます。配列（明細行）の行はサブ行に展開され、手作業による修正があれば出力ではOCRの値を上書きします。
• REST経由のJSON — 1件の書類には POST /ocr/fields、画像をそのままシートに投入するには POST /upload、保存済みシートをサーバー側で（where、sort、select、limit で）クエリするには GET /view を使います。OCRを再実行する必要も、再度課金されることもありません。

大量処理の自動化では、/upload はデフォルトで非同期です。ファイルごとにジョブを返し、完了時に Webhook で通知します——スペースごとに1つの署名付き（HMAC-SHA256）エンドポイントで、ocr.completed や ocr.failed といったイベントが届きます。これが、クリックして使うツールと、自分で回るパイプラインの違いです。全体像は請求書データ抽出APIガイドとAPIドキュメントにあります。

監査証跡：機械が読んだ値 vs. 人が変えた値

最良の領収書・請求書OCRは、自分の出力を記録するだけでなく、修正も記録します。space-ocr でセルを編集すると、あなたの値は元のOCRの値とは別に保存され、元の値のツールチップがエンジンの最初の読み取り結果を常に表示します。レビュー担当者は機械の値と人手の上書きを並べて確認できます——これこそ監査が求めるものです。

明朗で予測できる料金

検証可能な精度と誠実な料金は、たいてい同じ姿勢から生まれます。space-ocr は1枚あたり¥10です。クレジットカード不要、月100クレジットの無料枠があり、月額¥8,980のProプランには1,100クレジット、シート数無制限、100GBのストレージが含まれます。フィールド単位の課金もページ単位の追加料金もなく、保存済みシートへのクエリ（GET /view）は無料です。

領収書・請求書を抽出する手順