【ITニュース解説】I Built a Bilingual Invoice-to-JSON API (Here Is the Whole Stack)
2026年10月05日に「Dev.to」が公開したITニュース「I Built a Bilingual Invoice-to-JSON API (Here Is the Whole Stack)」について初心者にもわかりやすく解説しています。
ITニュース概要
PDFなどの請求書を手入力する課題を解決するため、ベトナム語にも対応した「請求書→JSON変換API」を開発した。Pythonと画像認識技術PaddleOCRで、金額や品目など構造化データを自動抽出し、RapidAPIで提供する。これにより経理業務の効率化に貢献する。
ITニュース解説
このニュース記事では、経理業務における長年の課題を解決する、画期的なAPIの開発について解説している。多くの企業で経理チームは、取引先から送られてくる請求書がPDFファイルや紙をスキャンした画像で届くため、その内容を一つ一つ手作業で表計算ソフトに入力し直すという非効率な作業に直面している。既存のOCR(光学文字認識)サービスも存在するが、これらは費用が高額であったり、英語の書類にしか対応していなかったり、あるいは構造化されていない単なるテキストの塊しか返さないため、実際の業務で活用するには不十分な場合が多かった。
そこで開発されたのが、画像やPDF形式のドキュメントを受け取り、その内容を自動的に解析して構造化されたJSONデータとして返すREST APIである。このAPIの目的は、請求書などのドキュメントから必要な情報を正確に抽出し、データ入力の手間を大幅に削減することにある。具体的には、例えば請求書をこのAPIに送信すると、ベンダー名、日付、合計金額、通貨の種類、そして各明細項目(商品やサービスの説明、数量、単価など)といった情報が、コンピュータが扱いやすいJSON形式で返ってくる。これにより、手作業での入力ミスを防ぎ、経理業務の効率を劇的に向上させることが可能になる。
このAPIの大きな特徴は、最初から多言語に対応している点にある。特に英語とベトナム語の両方に対応しており、ベトナム語の複雑な発音記号(ダイアクリティクス)も正確に処理できる。また、請求書だけでなく、領収書、履歴書、契約書、発注書など、計8種類の多様なドキュメントタイプを認識し、それぞれの形式に応じた情報抽出が可能である。これにより、単一のAPIで幅広いビジネス文書の自動処理に対応できる柔軟性を持つ。
このAPIは、複数の技術要素を組み合わせて構築されている。その中心となるのが「スタック」と呼ばれる技術群だ。まず、APIの「サービス層」として、Pythonプログラミング言語とFastAPIフレームワークが使用されている。Pythonは汎用性が高く、Webアプリケーション開発に適しており、FastAPIは高速なWeb APIを効率的に開発できることで知られている。この組み合わせにより、堅牢で高性能なバックエンドが実現されている。
テキスト抽出の肝となるOCRエンジンには「PaddleOCR」が採用された。開発者が当初検討したTesseractという別のOCRエンジンでは、ベトナム語の特殊な文字や、品質の低いスマートフォンスキャン画像からの文字認識において課題があった。しかし、PaddleOCRはこれらの問題をより正確に処理でき、さらにCPUのみで動作するため、システムをホスティングする際の費用を安く抑えることができるという利点があった。
抽出されたテキストを具体的なデータ項目(例:ベンダー名、合計金額)にマッピングするためには、「カスタムルールと正規表現層」が用いられている。これは、ドキュメントの種類(請求書か履歴書かなど)に応じて、特定のパターンや位置情報を使って必要な情報を識別し、JSONの各フィールドに適切に割り当てる仕組みである。この層が、単なるテキストの塊を意味のある構造化データへと変換する重要な役割を担う。
APIのデプロイ(インターネット上に公開し、利用可能にするプロセス)には「Railway」というサービスが利用された。Railwayは開発者がコードを簡単にデプロイし、インフラの管理を簡素化できるプラットフォームである。これにより、開発者はインフラ構築の複雑さから解放され、アプリケーション開発に集中できた。
APIを広く利用してもらい、さらに収益化するためには「RapidAPI」というプラットフォームが選ばれた。通常、APIを公開する際には、ユーザー認証、APIへのアクセス制限(レートリミット)、APIキーの発行、そして課金システムの構築といった、多くの付帯機能が必要となる。しかし、RapidAPIを利用することで、これらの機能をゼロから構築する手間を省き、APIを公開するための「ストアフロント」と課金機能をまとめて利用できる。RapidAPIはすでに多くの開発者がAPIを探しに来るマーケットプレイスとして機能しているため、単独でプロジェクトを進める開発者にとっては、手数料を支払ってでも利用する価値のある選択だった。
このAPIの開発過程では、いくつかの技術的な困難も存在した。特に難しかった点の一つは、「明細項目の検出」である。請求書全体の合計金額を認識するのは比較的容易だが、複数の商品やサービスが記載されたテーブル部分を正確に読み取り、それぞれの行を個別の明細項目として分割して抽出するのは非常に難しい。多くの既存APIがこの点でつまづくことが多い。開発者はこの問題に対し、OCRが認識した文字や単語の「位置情報」(OCRボックスの座標など)を手がかりにする「位置的ヒューリスティクス」という手法を駆使して解決した。これにより、テーブル構造を正確に解析し、各明細を適切に分離することが可能になった。
また、ベトナム語の処理も課題の一つだった。ベトナム語に特有のダイアクリティクス(声調記号)は、一般的なテキスト解析ツールがうまく処理できないことがあり、テキストを意味のある単位に分割する「トークナイザー」に問題を引き起こすことがあった。この問題に対しては、テキストから固有の名称や固有名詞を認識する「固有表現認識(NER)」を行う前に、ベトナム語のテキストを「正規化」する処理を挟むことで、より正確な解析を実現した。
さらに複雑なのは、「多言語が混在する請求書」の処理である。例えば、請求書のヘッダー部分が英語で書かれている一方で、明細項目はベトナム語で記載されているようなケースが存在する。ドキュメント全体で一つの言語を判断しようとすると、このような混在する情報を正確に抽出できない。この課題に対しては、ドキュメント全体ではなく、個々のフィールド(例:ベンダー名フィールド、明細記述フィールドなど)ごとに言語を検出する方法を適用することで、混在する言語情報を適切に処理できるようになった。
現在、このAPIはRapidAPI上で無料プランも提供されており、実際に試すことができる。開発者は、請求書や履歴書といったドキュメントを扱う開発を行っている人たちに向けて、今後どのような種類のドキュメント対応を望むかというフィードバックを求めている。このAPIは、データ入力の自動化という具体的な問題に対する、実践的なソリューションとして大きな可能性を秘めていると言える。