自社インフラの内側で保険金請求、チケット、KYC 書類を処理する LLM パイプライン:抽出、検証、レビュー、監査

保険金請求の書類、サポートチケット、KYC 書類には、共通の問題がある。人がそれを読んで、別のシステムが必要とするフィールドを埋めているのだ。保険金請求は証券番号、損害発生日、明細行になる。チケットはカテゴリと顧客に、本人確認書類は氏名、生年月日、有効期限になる。この仕事に伴う要件は、たいてい何よりも先に告げられる。文書を OpenAI にも、ほかのどの外部モデルプロバイダーにも渡してはならない、と。

モデルをどこで動かすかは別の判断であり、このブログの以前の記事で比較している。この記事は、あなたのインフラの内側でサービングされるオープンウェイトモデルを前提とし、受け付けから、別のシステムが取り込むレコードまで、それを取り巻くパイプラインを説明する。扱うのは仕組みであり、事例紹介ではない。

七つの段階、そのどれもが内側にとどまる

データを外部プロバイダーから遠ざけておくことは、モデルの呼び出しではなく、パイプライン全体の性質である。OCR エンジン、レビューツール、評価セット、監査ストア、ログのすべてが、文書か、そこから派生したものを保持している。その全体は、パイロットについての以前の記事に列挙してある。

受け付け:何かが文書を読む前に分類する

後に続くすべての段階は、文書の種類に左右される。スキーマ、ルール、レビュアー、保持期間である。だから分類が最初に来て、ルートを決める。メールで届く保険金請求の書類には、保険金請求書、請求書、写真、診断書が含まれうる。添付ファイルはそれぞれ個別に分類し、同じ案件にひも付ける。

• 到着時にチャネル、送り手、コンテンツのハッシュを記録する。二度送られた文書を、二つの案件になる前に見分けるためだ
• 閉じた種類のリストから分類する。vLLM の構造化出力（structured outputs）に関するドキュメントには choice パラメータが挙げられており、これを使うと出力は選択肢のちょうど一つになる。そのため分類器は種類をでっち上げられない
• どの種類にも合わない文書や、一致の度合いが低い文書は、最も近いスキーマに当てはめず、人に回す

先にテキストとレイアウト、言語モデルはその後

ソフトウェアが生成した PDF には、直接読み取れるテキストレイヤーがある。スキャンやスマートフォンの写真にあるのはピクセルだけであり、何かがそれを位置情報付きの文字に変えなければならない。

この段階のオープンソースのエンジンは、ローカルで動く。Tesseract のコマンドラインのドキュメントは、語ごとに信頼度の列を持つ TSV 出力と、語の信頼度を示す属性を持つ hOCR 出力を示しており、これはルーティングの段階が使える語単位のシグナルになる。MIT ライセンスのオープンソースの変換ライブラリである Docling は、PDF の機能としてページレイアウト、読み順、表の構造を挙げ、さらにスキャンした PDF と画像向けの OCR 対応、機微なデータとエアギャップ環境向けのローカル実行を挙げている。

• テキストレイヤーがあればそれを読み、ない場合に限って OCR を使う。きれいな文書に認識の誤りを持ち込まないためだ
• すべての語のページ番号とバウンディングボックスを保持する。抽出した各フィールドを、後で元のページ上でレビュアーに示せるようにするためだ
• 表は表のまま保つ。列を一行のテキストに平たくした請求書では、どの金額がどの品目のものかがわからなくなる

代わりに、視覚言語モデルにページ画像を読ませることもできる。vLLM のマルチモーダル入力に関するドキュメントは、画像入力が OpenAI Vision API に準拠してサポートされていると述べている。どちらがうまくいくかは、あなたの文書で測る。その際、独立した OCR の段階は語の位置と信頼度を返すが、画像を読むモデルは返さないことを念頭に置く。

スキーマで制約された出力:形は強制されるが、中身はされない

文書の種類ごとに専用の出力スキーマを持たせ、コードと同じようにバージョン管理する。vLLM の構造化出力に関するドキュメントは、五種類の制約を挙げている。choice、regex、JSON schema、文脈自由文法、structural tag である。バックエンドには xgrammar、guidance、outlines、lm-format-enforcer などがあり、既定値の auto は、リクエストの詳細に基づいて適切なバックエンドを選ぼうとする。

• すべてのフィールドで「見つからない」を明示的な値にする。損害発生日がなければ、推測されるのではなく、ないものとして記録されるようにするためだ
• 別のシステムが分岐の根拠にするものには、すべて列挙型を使う。保険金請求の種類、チケットのカテゴリ、文書の種類、国コード
• 各フィールドに出典の参照、つまりそれを取り出したページと語を付ける。検証とレビューで文書と照らし合わせられるようにするためだ

出力は、アプリケーションのコードでも、通常の JSON Schema バリデータでもう一度検証する。バックエンドには違いがある。同じページは、xgrammar、guidance、outlines が Rust 風の正規表現を使う一方、lm-format-enforcer は Python の re モジュールを使うこと、そして推論（reasoning）を有効にした Qwen3 Coder モデルでは、推論の内容が別のフィールドにパースされないと、構造化出力が無効になることがあると記している。トークン上限で止まった生成も、レコードの途中で終わる。二度目のチェックは安くつく。

検証:すでにある業務ルールを、コードとして書く

スキーマに合ったレコードでも、なお誤っていることがある。それを捕まえるチェックは、バックオフィスがいま手作業で行っているものを、文書の種類ごとにコードとして書いたものである:

• 保険金請求:証券番号が保険契約システムに存在し、損害発生日が保険期間内に収まり、請求書の明細行の合計が請求書の総額と一致する
• チケット:顧客の識別子が実在するアカウントに解決でき、挙げられた製品が、顧客が実際に持っているものである
• KYC:機械読み取り領域のチェックディジットが正しく、有効期限が過ぎておらず、機械読み取り領域の氏名と生年月日が、目視領域から読み取った同じフィールドと一致する

本人確認書類には、それ専用のバリデータがある。機械読み取り式渡航文書の仕様である ICAO Doc 9303 は、機械読み取り領域のチェックディジットを、7、3、1 の重みを連続して繰り返し適用するモジュラス 10 で計算すると定めており、A から Z の文字は 10 から 35、埋め字はゼロとして数える。また、チェックディジットによって読み取り装置がデータを正しく解釈したことを検証できると述べている。

ルーティング:どのフィールドを人が見るかは、ルールとシグナルが決める

ルーティングは文書ごとではなく、フィールドごとに決める。請求書の総額だけが通らず、ほかはすべて通った保険金請求なら、人に回すのはファイル全体ではなく一つのフィールドだ。シグナルは次のとおり:

• バリデータの失敗すべて。スキーマが必須としているのに、モデルが「見つからない」と記したフィールドも含む
• フィールドの元になった語の OCR 信頼度が低いこと。しきい値はフィールドごとに評価セットで設定する
• 二つの出典の食い違い。たとえば一冊のパスポートの機械読み取り領域と目視領域
• 決して自動化しないと決めたフィールド。たとえば、定めた上限を超える請求額
• すべてを通過したフィールドからの無作為抽出。誰も指摘しなかった誤りの率を、仮定するのではなく測るためだ

モデル自身が述べる確信度は、あえて外してある。それが関門として弱い理由は、このブログの以前の記事で説明している。

レビュー画面は、提案された値の隣にページを表示し、引用された語をハイライトする。レビュアーは読み直すのではなく、確認すればよい。修正はフィールドごとに、古い値、新しい値、レビュアー、短いリストから選んだ理由とともに保存する。二人目が確認すると、修正は評価セットに加わるが、リリースの判断の根拠となる凍結部分には決して入らない。

評価は文書の種類ごと、フィールドごとに。全体で一つのスコアではなく

パイプライン全体で一つの精度の数字は、肝心な結果を隠してしまう。たとえば、ある国の身分証明書で有効期限だけが失敗し、ほかのフィールドはすべて通っている、といった結果だ。測定は、ルーティングが使うのと同じ切り口で行う:

• フィールドごと:正規化後の完全一致。それとは別に、文書がそのフィールドを含む場合と含まない場合に、そのフィールドが見落とされた頻度、でっち上げられた頻度
• 文書の種類ごと、入力の種別ごと。たとえばデジタル PDF、スキャン、スマートフォンの写真。それぞれに固有の誤りのパターンがあるからだ
• ルートごと:自動化されたフィールドの割合と、そこから抜き出したサンプルでの誤り率
• コストで重み付けする。誤った銀行口座番号と、綴りを誤った通りの名前は、同じ誤りではない

新しいモデル、プロンプト、スキーマ、OCR のバージョン、バリデータのどれであれ、リリースは本番に出る前に凍結セットで採点され、関門はフィールドごとに設けられる。平均が上がったとしても、どの文書の種類のどのフィールドも、その合格ラインを下回ってはならない。最初のラベル付きセットの作り方は、本番にたどり着かなかったパイロットについての以前の記事で扱っている。

監査証跡:どのモデルとプロンプトがどのフィールドを生み出したか

争いのある保険金請求や、受け入れた本人確認についての監査人の問いは、一つの文書の一つのフィールドをめぐるものである。それに答える記録は、パイプラインの実行中に、フィールドごとに一件ずつ、追記専用のストアに書き込まれる:

• 文書の識別子とコンテンツのハッシュ、そのフィールドが引用するページと語
• OCR またはレイアウトエンジンのバージョンと、それらの語に対する信頼度
• モデル名と重みのチェックサム、プロンプトテンプレートのバージョン、スキーマのバージョン
• 各バリデータの結果、通ったルート、その理由
• 人が値を変えた場合は、レビュアー、変更前と変更後の値、そして時刻

EU AI Act は、高リスクとみなすシステムにログ記録の要件を課している。第12条(1) は、高リスク AI システムは、システムのライフタイムにわたってイベント（ログ）を自動的に記録することを技術的に可能にしなければならないと定めている。附属書 III は高リスクの用途を列挙しており、その中には、金融詐欺の検出を除く自然人の信用力の評価や、生命保険と健康保険におけるリスク評価と価格設定が含まれる。第6条(3) は、列挙されたシステムがそれでも高リスクとみなされない場合を定めており、たとえば限定的な手続き上のタスクを行う場合がそれに当たる。あるパイプラインが適用範囲に入るかどうかはクライアントの法務チームが判断する問題だが、実行時に書き込むフィールドごとの記録は、どちらにしても役に立つ。

個人データ:各段階は、そのタスクに必要なものだけを見る

パイプラインは、個人データを元のフォルダよりも多くの場所にコピーする。GDPR 第5条(1)(c) は、個人データが、それを処理する目的との関係で、十分であり、関連性があり、必要な範囲に限定されていることを求めている。第25条(2) は、デフォルトで、それぞれの特定の目的に必要な個人データだけが処理されることを確保する措置を求め、それを収集する量、処理の範囲、保存期間、アクセス可能性に適用している。パイプラインに当てはめると:

• モデルが受け取るのは、そのスキーマが必要とするページであり、案件のファイル全体ではない
• レビュアーが見るのは自分のキューにあるフィールドであり、文書全体へのアクセスはロールに応じて付与され、ログに記録される
• アプリケーションログには、文書の識別子、フィールド名、結果を記録し、フィールドの値やプロンプトは記録しない
• プロンプトと出力のトレースは、デバッグのために残す場合、文書と同じ制限付きのストアに置き、それ固有の短い保持期間を設ける
• 評価セットは実際の文書のコピーであり、同じアクセス制御を適用する

OWASP Logging Cheat Sheet は、健康データや政府発行の識別子など、機微な個人データと一部の形態の個人を識別できる情報を、通常はログに直接記録すべきでないデータに挙げ、そうしたデータは代わりに削除、マスク、サニタイズ、ハッシュ化、または暗号化すべきだとしている。

保持期間は文書の種類によって異なり、EU における KYC については資金洗浄対策の法律で定められている。2027年7月10日から適用される Regulation (EU) 2024/1624 の第77条は、義務主体に対し、顧客デューデリジェンスで取得した文書と情報の写しを保持すること、そしてそれらの記録が墨消し（redact）されないよう確保することを求めている。同条は、業務関係の終了日または一時的な取引の日から起算して五年の保持期間を定めており、その後、個人データは削除されるものとする。ただし、同条の例外に服する。KYC の元の記録は、記録システム（system of record）の中で完全なまま残る。パイプライン自身のコピーは、トレースからレビューのスナップショットまで最小化し、それ固有のより短いスケジュールで削除する。

スループット:スパイクにはキュー、定常状態にはキャパシティ

バックオフィスの量は一様ではない。一つの出来事が多くの保険契約者に同時に影響することがあり、障害が起きればチケットのキューが埋まる。キュー、バックプレッシャー、手作業へのフォールバックは、パイロットについての以前の記事で扱っている。セルフホストの文書パイプラインに特有なのは、次の点だ:

• 緊急度でキューを分ける。オンボーディング中に顧客が待っている KYC チェックを、過去の保険金請求のバッチの後ろに並ばせない
• CPU 上の OCR ワーカーと、アクセラレータ上のモデルサーバーを、それぞれ独立にスケールさせる。飽和する量が異なるからだ
• サービングエンジン自身のキューを監視する。vLLM は /metrics エンドポイントで Prometheus のメトリクスを公開しており、処理待ちのリクエスト数や、使用中の key-value キャッシュブロックの割合が含まれる
• ワーカーは CPU 負荷ではなくキューの深さでスケールさせる。KEDA のドキュメントは、処理を必要とするイベントの数に基づいて Kubernetes 上の任意のコンテナをスケールさせることを説明しており、メッセージングシステム向けなどのスケーラーと、ゼロへのスケール（scale-to-zero）も備えている

あなた自身のインフラ内のアクセラレータのキャパシティは、短期的には固定されている。だから、どのキューから順に譲るかは、スパイクの最中ではなく、事前に決めておく。

保険金請求、チケット、KYC:骨格は同じ、ルールが違う

• 保険金請求:一件あたりの文書が多く、請求書には表があり、健康に関する情報を含むことも多い。GDPR 第9条は健康に関する情報を特別な種類のデータに挙げており、同条の例外に当てはまらない限り、その処理は禁止されている。第22条は、法的効果を生じさせる、または同様に重大な影響を及ぼす、自動化された処理のみに基づく決定の対象とされない権利を個人に与えており、その例外は第22条(2) にある。したがって、パイプラインは抽出とチェックだけを行い、判断は保険金請求の査定担当者が下すのかどうかは、エンジニアリング上の既定値ではなく、クライアントのデータ保護責任者とともに下す設計上の判断である
• チケット:短いテキスト、大きな量、そして返信を待っている人がいる。だからレイテンシがより重要になる。出力の多くはカテゴリ、優先度、いくつかの識別子である。チケットのテキストは社外の人が書いたものであり、モデルにとって信頼できない入力である。このリスクは、パイロットについての以前の記事で論じている
• KYC:文書の種類が少なく形式が厳格であり、パスポートや身分証明書がその例である。そのため、ルールに基づく検証が強力に効く。書類の顔写真とセルフィーを照合すると生体データが加わり、GDPR 第9条は、個人を一意に識別するために処理される場合、これも特別な種類のデータとして挙げている。保持は資金洗浄対策の法律に従い、結果は、人または文書化されたルールが下すコンプライアンス上の判断に使われる

文書を外部のモデルプロバイダーから遠ざけておけるかは、モデルがどこで動くかで決まる。パイプラインにそれらを任せられるかは、モデルを取り巻くすべてで決まる。スキーマ、ルール、レビューキュー、そして各フィールドを誰が生み出したかの記録である。

どのエンジニアリング会社が、これをあなた自身のインフラの内側に構築するのか

この問いには三種類の答えがあり、それぞれ売っているものが違う。文書処理のベンダーが売るのはプラットフォームであり、オンプレミスに導入できることもあるが、あなたが自分の文書に合わせて設定する。クラウドプロバイダーが売るのは、自社のインフラで動くマネージドサービスだ。エンジニアリング会社は、オープンなコンポーネントとあなたのルールから、あなたの環境の中にパイプラインを構築する。

どの種類の相手と話すにせよ、次の問いで、そのチームが以前にこれを作ったことがあるかどうかが分かる:

• OCR、監視、エラートラッキング、アノテーションツールを含め、どの段階があなたのネットワークの外にあるサービスを呼び出すのか
• あなたの文書の種類の一つについて、出力スキーマはどのようなもので、「見つからない」はどう表現されるのか
• どのシグナルでフィールドがレビューに回り、しきい値はどう選ばれたのか
• レビュアーの修正は、リリースの判断に使う部分を汚染することなく、どのようにして評価セットに入るのか
• 一つの文書の一つのフィールドについて、その値を生み出したモデル、プロンプト、スキーマ、レビュアーを示せるか
• 仕事が終わったとき、パイプラインのコード、スキーマ、評価セットを所有するのは誰か、そしてどの部分がベンダーの再利用可能なコンポーネントとして残るのか

一つ目と五つ目の問いへの答えが一般論にとどまるなら、データ経路と監査証跡はまだ設計されていないということだ。

この分野での自社の仕事について amBrain が言えること

上の要約で述べた本番のインテグレーション以外に amBrain が公に裏付けられること:amBrain は2019年からソフトウェアを作ってきた。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。クライアントはプロダクトとコードの完全な所有権を保持する。ただし当社の再利用可能なコンポーネントは除く。

この記事は、そうしたパイプラインの仕組みを説明するものである。事例紹介ではなく、どのクライアントの名前も挙げず、amBrain が保険金請求、チケット、KYC のシステムを構築したとも主張しない。上で挙げた本番の仕事は、トレーディングシステムのための、ブローカーと取引所からの通知の抽出である。

だから最初の一歩は、モデルを選ぶことではない。どの文書もパイプラインに届く前に、一つの文書の種類について、スキーマ、それをチェックするルール、そして人が必ず見なければならないフィールドを書き出すことである。