はじめに

GENDAのインターンで、メーカーごとにフォーマットが異なる注文書・請書から表データを抽出するAIエージェントを開発しました。様々なOCRを比較検討し、最終的に「段階的フォールバック」の仕組みで精度とコストを両立させた話を書きます。

この記事で書くこと

複数のOCRツール（Mistral OCR、PyMuPDF、GPT-4o Visionなど）の比較
コストを抑えつつ精度を確保する段階的フォールバックの設計
GENDAでのインターンについて

自己紹介

株式会社GENDAのFE/BE開発部でインターンをしている入江です。東京大学工学部機械工学科の4年生で、来年GENDAに入社予定となっています。

入社のきっかけ

3年生の夏に東京大学発のエンジニアサークル UTTC（UTokyo Tech Club）に6期生として入り、Webアプリケーション開発について学びました。

その後UTTCのカリキュラムを終えて、UTTC経由でGENDAのインターンをさせていただくことになりました。

インターン先の候補はいくつかあったのですが、裁量が大きくエンジニアとして成長できそうなこと、エンタメ企業なのでユーザー目線でサービスを考えられること、そしてエンタメ業界に興味があったことからGENDAを選びました。

今回の記事では3月から6月まで関わっていた、オンクレ（オンラインクレーンゲーム）のAI Agent開発についてお話していきます。

プロジェクトの背景

GENDAのオンクレ事業では、商品の注文情報を管理する業務があります。

具体的には、商品を注文する際に注文書を送付し、メーカーからは請書が返送されます。
これらの注文書・請書の情報を一つのエクセルフォーマットに集約するという業務です。

しかし、この業務にはいくつかの問題がありました：

課題	詳細
フォーマットがバラバラ	メーカーごとに表の配置・文言・拡張子が異なる
文言の揺れ	同じ意味でも「商品名」「景品名」「摘要」など表記が違う
属人化	特定の担当者しか対応できない
手入力の負荷	手作業で転記するため時間がかかる

そこで、様々なフォーマットから表を抽出するAIエージェントを一から開発することになりました。

開発体制

メンターの方にサポートいただきながら、基本的には一人で要件定義から実装まで担当しました。担当者へのヒアリング → 要件定義 → 実装 → リリースという流れで進め、現在は実際の業務で導入されています。

アプリケーションの仕様

技術スタック

言語: Python
フロントエンド: Streamlit
LLM: GPT-4o

処理フロー

1. ユーザーがファイルをアップロード
2. 拡張子を判別（Excel / PDF / PNG）
3. 拡張子ごとに適切な方法で表を抽出
4. 指定のフォーマットに変換して出力

文言の揺れへの対応

抽出した表データを指定フォーマットに変換する際、「商品名」「景品名」「摘要」といった文言の揺れに対応する必要があります。

LLMに対応関係を判断させることも検討しましたが、以下の理由からconfigファイルで定義する方針にしました：

同じ言葉でもメーカーによって別の項目を指すケースがある
項目がずれると業務に支障が出る
メーカーが新規追加されることは稀

OCRの技術選定

現在はExcel・PDF・PNGの3つの拡張子に対応していますが、ここに至るまでに様々な試行錯誤がありました。

Excelの場合（簡単）

Excelファイルは比較的簡単です。行ごとにテキストを取り出してLLMに渡し、ヘッダー行の位置を特定させることで表を抽出しています。

PDF・PNGの場合（難しい）

問題はPDFとPNGでした。正確なテキストデータを構造を保ったまま抽出する必要があります。

試したこと①：Mistral OCR

当時リリースされたばかりで高性能と話題だったMistral OCRを試しました。
Mistral OCRはマルチモーダルな文書からテキストを抽出しマークダウンとして出力可能なAPIです。

結果: うまくいかず

欲しいデータが画像として出力されてしまう
日本語の文字認識精度が低い

試したこと②：各種OCRライブラリ

PyOCR（Tesseract）など、他のOCRも試しました。

結果: うまくいかず

注文書には半角カタカナが多用されていますが、日本語対応のOCRでも半角カタカナには弱いものが多いです。また、表の枠線が薄いと構造が崩れる問題もありました。

試したこと③：PyMuPDF

PDFのテキストデータを構造化して取り出せるOSSライブラリ「PyMuPDF」を試しました。

RAGの実装でPDFからテキストを抽出する際によく使われるライブラリで、LangChainやLlamaIndexのドキュメントローダーでも採用されています。PDFに埋め込まれたテキストレイヤーを直接読み取るためOCR不要で、page.find_tables()でテーブルを自動検出し構造化データとして取得できます。

結果: めちゃくちゃ使える

メリット

テーブルを自動検出して取り出せる
PDFのテキストデータを使うため文字化けしない（半角カタカナも問題なし）

デメリット

枠線が細い・点線などの場合、テーブルを検出できない
スキャンPDFなどテキストデータがないPDFには対応できない

試したこと④：GPT-4o Vision

そこでGPT-4oに画像を直接渡してOCRさせました。

結果: 非常に精度が高い

表形式を崩さず抽出でき、半角カタカナも問題がなかったです。
ただし、処理速度とコストの点では上記の方法よりは劣っています。

比較まとめ

手法	料金	日本語精度	表構造の維持	備考
Mistral OCR	$1/1000ページ	△	○	マルチモーダルな文書も読み取れるが文字認識精度が低い
PyOCR (Tesseract)	無料	△	×	OSSだが精度は低い
PyMuPDF	無料	◎	△	テキストデータを使用するので文字は正確に抽出できるがテーブル検出できない場合あり
GPT-4o Vision	約2円/回	◎	◎	精度は高いがコスト・速度が課題

結論: どの手法も一長一短があり、単体では完璧に対応できない

段階的フォールバックの設計

そこで最終的に採用したのが、段階的フォールバックという仕組みです。

コストの低い方法から順に試し、失敗したら次の方法にフォールバックすることで、精度とコストを両立させています。

LLMに投げる前にフォールバックするので、APIを呼び出すのは一回で済みます。

Excelの場合：ヘッダー行をLLMが検出

Excelに関しては、ヘッダー行をLLMが検出することで、表データを抽出しています。

prompt_template = """
以下のテキストは商品の注文情報です。このテキストは次の三つの部分から構成されています。
a. タイトル、挨拶、宛先、住所、日付など注文内容に関係のない情報（ない場合もある）
b. テーブルのヘッダー行（カラム名（商品名、商品コード、数量、入数、金額、発売月、出荷日、注文日、など複数の項目）が含まれる行（ただし言い回しが違う場合もあります）、必ず存在、1行目にくることもある）
c. テーブルのデータ（商品名、数量、金額などのデータが含まれる行、ヘッダー行の次に必ず存在）
bのヘッダー行（列名が含まれている行）を特定してください。
ヘッダー行は、通常、列名が含まれており、データ行とは異なる特徴を持っています。
ヘッダー行の行番号の整数値のみを返してください。

テキスト:
{prompt_input_text}

ヘッダー行の行番号（整数値のみ）:
"""

PDF・PNGの場合：段階的フォールバック

Step 1: PyMuPDFでテーブル抽出 → LLMで整形

まずPyMuPDFでテーブルを抽出します。抽出した全テーブルをLLMに渡し、「商品の詳細情報を含む注文情報テーブル」を判別・整形してもらいます。

テーブル以外もテーブルとして認識してしまうことや、複数テーブルが存在すること、検出できてもテーブルの形式が崩れることがあるため、このようにLLMに整形させるようにしています。

prompt = f"""
以下に、PDFから抽出された複数のテーブルが「抽出された全テーブル」として提示されます。
このテーブルは正確に抽出されているものもあれば、複数行や列が結合されているものもあります。

あなたのタスクは以下の通りです。
1. 最初に、提示された複数のテーブルの中から、「商品の詳細情報（品番、品名、数量、金額など）を含んでいる主要な注文情報テーブル」を一つだけ見つけ出してください。担当者名や合計金額のみが記載された、無関係なメタデータテーブルは無視してください。ただし商品の詳細情報が書かれているテーブルが見つからない場合はタスクを中断し、何も出力しないでください。
2. 次に、見つけ出した主要なテーブルだけを使い、複数行や列が結合されている場合は、それを展開して、最終的にクリーンなCSVを出力してください。

【ルール】
- 重要: 出力は必ず「JSON形式の配列の配列（List of Lists）」としてください。
- 1行目（最初の配列）がヘッダー、2行目以降（2番目以降の配列）がデータとなるように構成してください。
- 説明や言い訳は絶対に含めず、JSONオブジェクトのテキストのみを出力してください。
- 金額や数量が空の場合は、空文字 "" もしくは null を使用してください。

【抽出された全テーブル】
{all_tables_text}

【クリーンな出力CSV】
"""

Step 2: テーブル検出失敗 → 全テキストから構造化

PyMuPDFでテーブルが検出できなかった場合（枠線が細いなど）は、抽出した全テキストをLLMに渡してテーブルを構造化してもらいます。

prompt = f"""
以下に、PDFから抽出された生のテキストが「ドキュメント全文」として提示されます。
あなたのタスクは、このテキスト全体を注意深く読み、「商品の詳細情報（品番、品名、数量、金額など）を含んでいる主要な注文情報テーブル」を見つけ出し、その内容をクリーンなCSV形式で出力することです。

【ルール】
- 重要: 出力は必ず「JSON形式の配列の配列（List of Lists）」としてください。
- 1行目（最初の配列）がヘッダー、2行目以降（2番目以降の配列）がデータとなるように構成してください。
- 説明や言い訳は絶対に含めず、JSONオブジェクトのテキストのみを出力してください。
- 金額や数量が空の場合は、空文字 "" もしくは null を使用してください。

【ドキュメント全文】
{full_text}

【クリーンな出力CSV】
"""

Step 3: テキストなし → GPT-4o Vision OCR

テキストデータが含まれないPDFや画像ファイルの場合、最終手段としてGPT-4o Visionで画像を直接OCRします。

messages = [{
    "role": "user",
    "content": [
        {"type": "text", "text": f"""
        以下に提示される画像の中から、商品の注文情報が記載された主要なテーブルを見つけ出し、その内容をクリーンなCSVで出力してください。

        【ルール】
        - 重要: 出力は必ず「JSON形式の配列の配列（List of Lists）」としてください。
        - 1行目（最初の配列）がヘッダー、2行目以降（2番目以降の配列）がデータとなるように構成してください。
        - 説明や言い訳は絶対に含めず、JSONオブジェクトのテキストのみを出力してください。
        - 金額や数量が空の場合は、空文字 "" もしくは null を使用してください。

        【クリーンな出力CSV】
        """}]
}]

for b64_img in base64_images:
    messages[0]["content"].append({
        "type": "image_url",
        "image_url": {"url": f"data:image/png;base64,{b64_img}"}
    })

精度の担保について

最後に残る課題は「本当に正確に読み取れているのか」という点です。

現時点で100%正確なOCRは不可能だと考えています。そこでこのアプリでは、変換元のファイルと変換結果を並べて表示し、人の目で最終チェックしてもらうUIにしました。

この方法は結局工数がかかってしまうため、より良い方法がないか引き続き検討していきたいです。

振り返り

学んだこと

OCRツールの特性: 各ツールの得意・不得意を実際に試して把握できた
一気通貫の開発経験: 要件定義からリリースまでを一人で担当

特にドキュメントを構造化データとして抽出するというのは、RAGの実装など様々な事業領域で発生しうる課題だと思うので、その知見が溜まったのは大きかったです。

反省点

担当者とのコミュニケーション不足が最大の反省点です。

要件を十分に擦り合わせずに開発着手 → 手戻りが発生
メーカーごとの複雑な処理ロジックの理解に時間がかかった
結果としてスケジュールが遅延

もっと早い段階で担当者と擦り合わせておくべきでした、、、ただインターンでこの経験ができたことは、今後に活かせる貴重な学びだと思っています。

成果発表

GENDAでは定期的にインターン生の成果発表会があり、この内容を発表しました。

自分の成果をアピールしつつ、他のインターン生の取り組みも知れる刺激的な場です。

おわりに

今はこのオンクレの経験を活かして、別のプロジェクトを任せていただいています。

GENDAでは要件定義から任せていただけることが多く、自走力や課題解決力が特に身についたと感じています。今後はより大きなプロジェクトに携わり、さらに成長していきたいです。

ここまで読んでいただきありがとうございました！