カスタムAI-OCRの精度を継続的に高める仕組み｜帳票のパターン別に、AIが自動でモデルを振り分ける

取引先ごとにフォーマットの違う注文書やFAXを、1つのAI-OCRで全部きれいに読み切れるのか。

現場でよく突き当たるこの壁を越える考え方が、「様式を自動判定し、その様式専用のモデルで読む」というモデル自動切り替えの仕組みです。

弊社は、帳票の読取りからシステム入力までを自動化する「AI-OCRプライベート」を、お客様専用の環境で構築しており、本記事では、その中核機能である「様式ごとに読み分け→モデル構築→精度向上」の自動サイクルを、汎用的な技術の話として実務目線で解説します。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

なぜ「1つのモデルで全帳票」は無理が出るのか

受発注の現場では、届く帳票の様式が取引先ごとに異なり、その数が数十種類にのぼることも珍しくありません。項目の位置、表組みの形、罫線の有無、手書きの混在——見た目のばらつきは想像以上です。ここに汎用モデル一本だけで臨むと、ある取引先ではよく当たるのに別の取引先では読み違える、といったムラが避けられません。学習に含まれた様式には強い一方、外れた様式では読み違えが増える、という偏りが生まれるからです。かといって、すべての様式を1つのモデルに詰め込もうとすると、様式の特徴が互いに打ち消し合い、全体の精度がかえって伸び悩むこともあります。

Microsoft も、カスタムモデルの学習に関する推奨のなかで、「フォーマットが異なる文書を1つのモデルでまとめて解析すると、モデルの精度が下がることがある。データセットを様式ごとのフォルダに分け、1様式につき1モデルを学習して、それらを1つのエンドポイントに束ねる（composeする）ことを検討するとよい」という趣旨の指針を示しています。つまり「様式ごとに分けて読む」という発想は、現場の勘ではなく、Document Intelligence の設計にもとづく王道の進め方なのです。

分類→抽出の二段構え｜様式を判定して専用モデルへ自動ルーティング

この課題に対する Azure AI Document Intelligence の標準パターンが、「分類してから抽出する（classify then extract）」という二段構えです。処理の流れは、受け取った帳票をまず①カスタム分類モデル（classifier）で「これはどの様式・どの取引先の帳票か」を判定し、その判定結果にもとづいて②その様式専用の抽出モデルへ自動的に振り分け、項目を読み取る、という形になります。読み取ったあとは③構造化（LLM）で項目を整え、基幹システムへ連携します。

Microsoft はこの仕組みを「合成モデル（composed model）」として提供しています。とくに 2024-11-30（GA）版のモデル合成（model compose）では、以前の「暗黙の分類」が明示的な分類ステップと条件付きルーティングに置き換えられ、次のような制御ができるようになりました。「様式が事前に分からない帳票が届く」「複数の帳票が1つのファイルにまとまってスキャンされている」といった、まさに受発注の現場で起きる状況を想定した仕組みです。

できること	内容
様式ごとの自動振り分け	分類モデルが判定した様式にもとづき、その様式に最適な抽出モデルへ自動でルーティングする。「A社様式はA用、B社様式はB用」と、帳票ごとに最も適したモデルで読む
信頼度によるルーティング	分類の確からしさ（信頼度）にしきい値を設け、確信が持てない帳票は特定の抽出モデルへ回さない、といった制御ができる
1ファイル内の複数帳票の分割	分割の指定（splitMode）と組み合わせ、1つのファイルに複数の帳票が含まれる場合に、それぞれを別の帳票として切り出して処理できる
多数の様式への対応	1つの合成モデルに、多数の抽出モデル（最大500）を束ねられる。様式が増えても同じ仕組みで拡張できる

ポイントは、アプリケーション側で「どのモデルを使うか」を手作業で選ぶ必要がないことです。帳票を渡せば、分類から抽出までを1つのモデルIDで一気通貫に処理し、結果には「どの様式のモデルで読んだか」の情報も返ります。運用する人にとっては、様式を意識せずに「読み取りにかける」だけで済みます。

様式ごとに独立して育てられる｜弱点だけを追加学習

二段構えのもう一つの利点は、様式ごとのモデルを、それぞれ独立して改善できることです。全体を作り直すのではなく、読み違えが多い様式のモデルだけをサンプルを足して再学習すれば、その様式の精度をピンポイントで引き上げられます。ほかの様式のモデルには影響しません。「弱点の様式だけを狙って鍛える」ことができるわけです。

分類モデルの側も同様に育てられます。Microsoft は新しいモデル合成の利点として「継続的な漸進改善（continual incremental improvement）」を挙げており、サンプルを追加して分類器を段階的に改善（増分学習）できると説明しています。これにより、帳票が正しい抽出モデルへ確実に振り分けられるよう、分類の精度も運用しながら高めていけます。

抽出モデル自体も、少ない元手で始められます。Microsoft の公式ドキュメントによれば、カスタム抽出モデルは同じ様式の文書が5例あれば学習を始められるとされています。様式のばらつきに強い「ニューラルモデル」と、同じレイアウトを前提に高速に学習できる「テンプレートモデル」の2種類があり、用途に応じて選べます。いずれも、最初から完璧を目指す必要はなく、実際に届いた帳票が貯まった様式から順に、専用モデルを起こしていけるのが実務上の強みです。

モデルの種類	向いている帳票	特徴
カスタム分類モデル (classifier)	様式・取引先の判定	「どの様式か」を見分けて振り分ける。1つの分類につき最低5文書・最低2種類の分類から学習でき、サンプル追加で継続改善できる
カスタム抽出モデル（ニューラル）	様式に多少のばらつきがある帳票	同じ情報でもレイアウトが異なる文書を1つのモデルで扱える。構造化・半構造化・非構造の文書に対応
カスタム抽出モデル（テンプレート）	レイアウトが一定の帳票	視覚的な様式が一定な文書に向き、短時間で学習できる。様式のバリエーションごとにモデルを用意する

汎用で即日スタート、育てるほど賢くなる

ここまでの話を、導入から運用までの時間軸で並べ直すと、無理のない進め方が見えてきます。図版の下段に示したロードマップの通りです。

育て方の4ステップ

STEP 1｜汎用モデルで即日開始
まずは既成の読取りモデルで運用を始め、日々の帳票を処理し始めます。作り込みを待たずにスタートできます。
STEP 2｜実様式を収集
実際に届く帳票を、様式ごとのサンプルとして蓄積します。現場を止めずに、育てるための素材が自然に貯まっていきます。
STEP 3｜様式別カスタムモデルを作成
サンプルが貯まった様式から順に、その様式専用の抽出モデルを起こし、分類→抽出のルーティングに組み込みます。
STEP 4｜弱点様式を追加学習し継続向上
読み違えが残る様式だけをサンプルを足して再学習します。全体を作り直さず、弱点をピンポイントで底上げし続けます。

大切なのは、これらがアーキテクチャを組み替えることなく、設定変更を中心に実現できる点です。分類→抽出という骨格は最初から変わらず、そこに様式別モデルを足し、弱点を鍛え直していくだけ。「最初に完璧なモデルを作らないと使えない」のではなく、「使いながら賢くしていける」ことが、現場に根づく仕組みの条件だと弊社は考えています。

構造化（LLM）の側も様式別に最適化できる

読み取った項目を、基幹システムに合う形へ整える「構造化」の工程でも、同じ「様式別に最適化する」という考え方が使えます。抽出した文字を、商品名・数量・単位・納品日などの項目に振り分け、表記のゆれを吸収してコードに突き合わせる——ここに生成AI（LLM）を用いる場合、様式ごとに指示（プロンプト）を調整したり、必要に応じてより上位のモデルや調整済みのモデルへ設定を差し替えたりすることができます。

読取り（OCR）の段で様式ごとに最適なモデルへ振り分け、構造化の段でも様式ごとに整え方を最適化する。この二段階で、「様式のばらつき」という受発注現場の最大の難所に、正面から向き合えるようになります。なお、精度が実際にどこまで出るかは、帳票の質や様式のばらつきに左右されます。数値をあらかじめ約束するのではなく、実際のデータで確かめていただくのが確実です。

弊社の支援｜お客様専用のAI-OCRプライベートで、育てながら使う

弊社は、ここで述べた「様式ごとに読み分け、育てて賢くする」仕組みを、お客様専用のAI-OCRとして構築しています。お客様専用のセキュアなAI基盤SaaSサービス「AIプライベート」の一つ、「AI-OCRプライベート」です。共有型のサービスに出来合いの機能を借りるのではなく、Azureの基盤の上に、お客様の帳票と業務にフィットした読取り環境を一社ごとに構築します。

様式ごとに読み分ける構成
分類→抽出のルーティングで、取引先ごとに異なる帳票を、それぞれ最適なモデルで読み取ります。1ファイルに複数帳票が混在する場合の切り出しにも対応します。
使いながら育てる運用
汎用モデルで即日始め、実際の帳票が貯まった様式から順に専用モデルへ。読み違えが残る様式だけを追加学習し、精度を継続的に高めていきます。
読み違いを止める安全設計
マスタに突き合わない項目は、AIに勝手に埋めさせず「未照合」として人の確認に回します。自動化の速さと、取り違えを防ぐ確実さを両立します。
まず動くものを、無料トライアルで実測
いきなり作り込むのではなく、実際の帳票で読み取りを試していただき、精度と手応えを確かめたうえで導入へ進めます。

「取引先ごとに様式がバラバラで、AI-OCRは自社に合うのか」——受発注の自動化でよく聞かれるこの不安に対して、弊社は様式ごとに読み分け、使いながら育てるという設計でお応えします。サービスの詳細は「AI-OCRプライベート」を、電話での受発注を自動化する対の仕組みは「AI-Voiceプライベート」をご覧ください。

よくあるご質問

こちらをクリックして「よくある質問」を表示

帳票の様式ごとにAIモデルを自動で切り替えることは本当にできますか？

できます。Azure AI Document Intelligence の標準的なパターンで、まずカスタム分類モデル（classifier）で帳票の様式・取引先を判定し、その結果にもとづいて様式専用の抽出モデルへ自動で振り分けます（分類→抽出／classify then extract）。これらを「合成モデル（composed model）」として1つのモデルIDにまとめられるため、アプリケーション側でモデルを手作業で選ぶ必要はありません。帳票を渡すだけで、分類から抽出までを一気通貫で処理します。

1つのモデルで全部の様式を読ませるのと、何が違うのですか？

1つのモデルにすべての様式を詰め込むと、様式の特徴が互いに干渉し、全体の精度が伸び悩むことがあります。Microsoft も、フォーマットの異なる文書を1モデルでまとめて解析すると精度が下がる場合があるとし、様式ごとにモデルを分けて束ねることを推奨しています。様式ごとに分ければ、それぞれを独立して改善でき、読み違えが多い様式だけを狙って鍛え直せる、という運用上の利点も得られます。

カスタムモデルを作るには、どのくらいのサンプルが必要ですか？

Microsoft の公式ドキュメントでは、カスタム抽出モデルは同じ様式の文書が5例あれば学習を始められるとされています。分類モデルは、1つの分類につき最低5文書・最低2種類の分類から学習できます。最初から大量のサンプルを揃える必要はなく、実際に届いた帳票が貯まった様式から順に専用モデルを起こし、サンプルを足しながら精度を高めていく進め方が現実的です。

精度はどのくらい出ますか？

精度は、帳票の質、手書きの有無、様式のばらつきによって変わるため、あらかじめ数値をお約束することはしていません。弊社では、実際の帳票で読み取りを試していただく無料トライアルをご用意しています。まず動くものをお客様のデータで確かめ、精度と手応えを見たうえで導入をご判断いただくのが確実だと考えています。読み違いのおそれがある項目は、AIに埋めさせず人の確認に回す設計で、取り違えを防ぎます。

1枚のファイルに複数の注文書がまとまっている場合も処理できますか？

対応できます。2024-11-30（GA）版のモデル合成では、分割の指定（splitMode）と組み合わせることで、1つのファイルに複数の帳票が含まれる場合に、それぞれを別の帳票として切り出して処理できます。複合機やクラウドFAXでまとめて届いた帳票を、様式ごとに判定し、それぞれ最適なモデルで読み分ける、という運用が可能です。

読み取ったデータは基幹システムに取り込めますか？

はい。読み取って構造化した結果は、CSVやAPIの形で基幹システム（販売管理など）へ連携できます。項目の並び・列名・文字コードはお客様の基幹システムに合わせて調整します。表記のゆれはマスタに突き合わせて吸収し、突き合わないものは「未照合」として人の確認に回すため、誤ったコードのまま登録される事故を防ぎます。

取引先ごとに様式の異なる帳票の読取り自動化、AI-OCRの導入のご相談は、お問い合わせよりお気軽にご連絡ください。まずは実際の帳票を使った無料トライアルで、読み取りの手応えをご確認いただけます。

参考（一次情報）：Microsoft Learn「Composed custom models – Document Intelligence」／「Custom document models – Document Intelligence」／「Custom classification model – Document Intelligence」（いずれも v4.0 2024-11-30 GA、公開時点の内容にもとづく）。