VLM Powered OCR

OCR API — 開発者向け文書テキスト・構造化データ抽出

ほとんどのOCR APIは生のテキストと座標を返すだけ — 文書タイプごとに解析コードを書く必要があります。この統合アプローチでは、テキスト抽出とフィールド認識を1回の処理で行い、定義した列名で構造化データを出力します。

Enterprise-grade security · TLS 1.3 encrypted

REST API
PDF/JPG/PNG
JSON + XLSXエクスポート
Basic以上のAPIアクセス

あらゆる文書から抽出できる項目

必要な列名を入力するだけ — AIが各ページの値の意味を理解し、位置に依存せず抽出します。構造化されたJSON結果を取得し、スプレッドシートが必要な場合はバッチでフォーマット済みの.xlsxワークブックとしてエクスポートできます。

文書の生テキスト
請求書番号
日付
合計金額
取引先名
明細項目
発注番号
税額
支払期限
文書種別

OCR APIでは半端な結果しか得られない理由

OCR APIはテキストと座標を返します。検出された単語の中に浮かぶ文字列"INV-2024-0892"ではなく、Invoice Number: INV-2024-0892を取得するには、第二の処理層が必要です。

01
構造のない生のテキストダンプ

OCR APIはフラットな文字列か、座標付きの単語リストを返します。数値 $322.38 とラベル "TOTAL" は、出力内の他のテキストと区別がつきません。コードで、どの数値が合計で、どの数値が小計で、どの数値が明細項目なのかを自力で判断する必要があります。

02
文書レイアウトごとにカスタム解析コードが必要

座標はページに相対的です。位置 (x=100, y=200) で請求書番号を抽出するルールは、別のベンダーのレイアウトが (x=300, y=150) に配置した瞬間に機能しなくなります。ベンダーごとの解析ロジックを維持するのはスケールしません。

03
後処理パイプラインが複雑さとコストを増大させる

Redditの開発者は、OCR出力と利用可能なデータのギャップを「非常にイライラする」と一貫して述べています。APIは仕事をしましたが、データはまだ使用できる状態ではありません。

01
列名で構造化データを出力

必要なフィールド(Invoice NumberTotalVendorなど)を定義するだけで、AIがJSONやスプレッドシートの名前付き列として返します。生テキストのラベル付けや並べ替えは不要です。

02
レイアウトに依存しないセマンティック抽出

AIがInvoice Numberの意味を理解しているため、ページ上の位置に関係なく見つけ出します。ベンダーがテンプレートを変更しても、ルールを更新することなく抽出は機能し続けます。

03
アップロードから構造化出力までワンパイプライン

OCR、パース、フィールド抽出を別々に行う必要はありません。PDFや画像をアップロードし、列を定義するだけで、1つのレスポンスで構造化データを受け取れます。エンドツーエンドの構造化データが必要なチームにとって、この統合アプローチはOCR→パース→抽出のチェーンを維持するよりもシンプルです。

アップロードから構造化データまで一貫フロー

APIで請求書のバッチを処理する際の流れをご紹介します。中間の解析ステップは不要です。

1

APIまたはWebインターフェースでファイルをアップロード

PDF、JPG、PNGを送信 — 単一ドキュメントでも、同一バッチ内で混在フォーマットでも構いません。APIはマルチパートアップロードを受け付け、ステータスポーリング用のタスクIDを即座に返します。各ファイルは非同期でキューイング・処理され、Web UIとAPIエンドポイントは同一のエンジンで動作します。

2

カラムスキーマを定義

必要なフィールドを指定します — Invoice NumberDateVendorLine Items (Description / Quantity / Unit Price / Total)TaxGrand Total。AIが各ドキュメントをセマンティックに読み取り、ページ上の位置に関係なく、値をカラム名にマッピングします。

3

構造化データを取得 — JSONまたはExcel

各ドキュメントは、指定したカラム名に値が格納された状態で返されます。個別の結果はfield:valueペアのJSONとして取得するか、バッチ全体をフォーマット済みの.xlsxワークブックとしてダウンロードしてスプレッドシートワークフローに活用できます。正規表現パターンの記述、座標マッチングのデバッグ、後処理パイプラインの維持は一切不要です。

このアプローチが適しているケース

最適なケース

  • 文書から生のテキストではなく、構造化されたフィールド:値のペアが必要な場合。
  • 異なるレイアウトの文書が複数のソースから届く場合 — セマンティック抽出はルール変更なしで適応します。
  • 後処理パイプラインを省略したい場合 — 抽出結果をそのままデータベース、APIレスポンス、スプレッドシートに読み込めます。
  • チームに抽出ルールを構築・維持する専任のNLPや文書解析エンジニアがいない場合。

注意が必要なケース

  • 自由形式のテキスト再構成のために、文字単位の正確なバウンディングボックス座標付きの生OCRテキストが必要な場合 — このアプローチは名前付きフィールドを出力し、完全なレイアウトジオメトリは提供しません。
  • パイプラインが月間数百万件の文書を1ページあたり1セント未満で処理する場合 — スループット要件に対して従量課金制を評価してください。
  • 極端に筆記体の手書き文字や、物理的な劣化が激しいスキャン文書では抽出精度が低下する可能性があります — 鮮明な印刷文書やスキャン文書で最も高い信頼性が得られます。

よくある質問

APIでスキャンしたPDFから請求書番号合計金額を抽出できますか?

はい。スキャンPDFは画像として扱われます。ビジュアルAIがページを直接読み取るため、テキストレイヤーに依存しません。請求書番号合計金額を列名として定義すれば、PDFがデジタル生成かスキャンかにかかわらず、APIは値を名前付きフィールドとしてレスポンスに返します。

Google Cloud VisionやAWS Textractとどう違うのですか?

Google Cloud VisionやAWS Textractは、フィールドがラベル付けされたドキュメントに対して、生のテキストをバウンディングボックスやキーと値のペアで返します。このAPIは、セマンティックな理解によって、あなたが定義したフィールドを返します。仕入先名を指定すれば、ドキュメントに明示的なラベルがなくても仕入先名を見つけます。ドキュメントではなく、あなたが出力スキーマを定義するのです。

ドキュメントごとに行数が異なる明細項目はどう扱えばよいですか?

明細項目のような列を、ネストされたサブフィールド(説明数量単価合計)とともに定義します。AIは、ドキュメントごとに3行でも30行でも、すべての明細項目を検出し、JSONの配列またはエクスポート時の展開された行として返します。

統合前にOCR APIを評価するにはどうすればよいですか?

API統合を構築する前に、Web UIのゲストデモで出力品質を評価できます。APIアクセスはアカウントのAPIキーを使用し、有料プランで利用可能です。WebインターフェースとAPIは同じ抽出エンジンを共有しているため、テスト出力は統合の判断に役立ちます。

対応している入力形式と出力形式は何ですか?

アップロード:PDF(パスワード保護ファイルを含む)、JPG、PNG、WebP、AVIF。出力:列名をキーとする構造化JSON、およびバッチレベルのダウンロード可能な.xlsxファイルとしてのエクスポート。

📮 contact email: [email protected]