読み取れない生年月日を“推測”してしまうOCRモデル

フィンテックのスタートアップにおけるKYC（本人確認）パイプラインを想像してみてほしい。ユーザーが運転免許証の写真をアップロードしたが、生年月日の上に親指が重なっており、交付年月日のある角はカメラの画角から切れてしまっている。しかし、各項目を抽出する文書AIモデルはエラーを吐かない。それどころか、一見すると極めてもっともらしい数字でその空白を埋めてしまうのだ。

ここで本当に恐ろしいのは、その数字が時に「正解」してしまうことだ。「良い当て推量」という意味での正解ではない。モデルが見てすらいない実際の生年月日に、なぜかピタリと一致してしまうという意味での正解である。中国とインドの研究機関の研究者らによる、ACM Multimedia 2026に採択された新しい論文が、その理由を解き明かしている。文書理解モデルは、項目が読み取れないときに必ずしも「分からない」と答えるわけではない。学習に使われた文書群の中で「どの項目とどの項目がセットになりやすいか」という記憶を手繰り寄せ、空白を埋めようとする。その推論プロセスが、学習データに含まれていた実在の個人情報を漏洩させてしまうのだ。

この論文のタイトルは「Beyond Visual Evidence: Revealing and Mitigating Relational Privacy Leakage in Document MLLMs」であり、今や静かに社会インフラ化しつつあるツールのカテゴリ――すなわち、パスポートやIDカード、運転免許証などの身分証明書を読み取り、構造化データを抽出するようにファインチューニングされたマルチモーダル大規模言語モデル（MLLM：画像とテキストの双方を入力とするモデル）――を真っ向から標的にしている。このタスクは文書AIの世界では主要情報抽出（Key Information Extraction）、略してKIEと呼ばれている。写真をモデルに投入すれば、氏名、住所、生年月日、身分証番号などが整ったJSON形式で返ってくる。これは多くのユーザー登録（オンボーディング）フローの根幹を担っており、まさにOCRベンダー各社がその精度を競い合っている領域そのものである。

モデルは画像を読んでいるのではない、パターンを記憶しているのだ

ほとんどの人は、OCRや文書AIの失敗といえば、滅茶苦茶な出力――数字の入れ替わり、文字化け、あるいは空欄のまま放置されること――を想像するだろう。それこそが誰もがテストで検証する障害モードだ。しかし本論文が扱っているのはそれらとは異なり、出力自体は完璧に見えるものの、はるかに危険な形で誤っているケースである。

そのメカニズムは、一度理解してしまえば単純明快だ。これらのモデルは膨大な数の実在する身分証明書で学習されている。身分証上の各項目は互いに独立しているわけではない。氏名、住所、国籍、ID番号のプレフィックス、生年月日はすべて統計的に強く結びついている（相関している）。これは、官僚的な事務処理の都合（発行地域や年次に関連付けられたID番号の範囲など）による場合もあれば、単に学習セット内に同一人物や類似した人物のデータが繰り返し含まれていることによる場合もある。こうしたデータで徹底的にファインチューニングされたモデルは、「生年月日の欄にあるピクセルを読み取る」ことだけを学習するのではない。「この地域特有の、この形式の文書なら、生年月日はこの範囲に収まる傾向がある」、あるいはさらに悪いことに「この氏名と住所の組み合わせは以前見たことがある。その後に続く値も覚えている」といったパターンまで学習してしまうのだ。

そのため、ある項目に対する視覚的根拠（visual evidence）が乏しい場合――隠れていたり、ぼやけていたり、見切れていたり、低解像度だったりする場合――モデルの選択肢は2つしかない。「不確実である（分からない）」と報告するか、記憶した事前知識（memorized priors）に頼るかだ。本論文の核心的な発見は、現在のモデルが圧倒的多数で後者を選択し、しかもそれを「無言で」行うという点にある。出力に「信頼度：低」のようなフラグが付くことはない。モデルが実際に画像から読み取った項目のすぐ隣に、正しくフォーマットされた完全な値が平然と並ぶのだ。後続のシステムから見れば、記憶に基づく当て推量と、正当に抽出されたデータは全く区別がつかない。

ここで少し立ち止まって考えてみてほしい。これは、目の前にある画像には一切写っていなかった情報のプライバシー漏洩なのだ。現在処理している文書内の相関する項目との部分的な一致をトリガーとして、学習時に別の誰かの文書から記憶した情報を漏洩させているのである。これは「モデルが読み取るべきではないものを読み取ってしまった」という脅威モデルとは根本的に異なる。テキストLLMで懸念されるメンバーシップ推論（membership-inference）や学習データ抽出（training-data-extraction）攻撃に近いが、決定的な違いは、誰もモデルを攻撃しようとしていない通常の運用環境下で、副次的に自然発生してしまっているという点だ。

意図して探さなければ見つからないバグのためのベンチマーク構築

測定できないものを修正することはできない。そしてここで厄介なのは、この障害モードが一見正常な精度スコアの背後に隠れてしまう点だ。鮮明で全体が欠落なく写っている文書を用いたKIEベンチマークでモデルが96%の精度を達成していたとしても、画像が劣化しているときにモデルがどう振る舞うかについては、その数字は何一つ教えてくれない。なぜなら、画像が劣化した過酷な条件下こそが、モデルが「読み取り」から「推測」へと切り替わるまさにその瞬間だからだ。

著者らがDocPrivacyBenchを構築したのは、まさにこのギャップを埋めるためだ。そのアプローチは、1つ以上の項目について視覚的根拠が存在しないか極めてわずかしかないテストケースを意図的に作成し、次の2点を確認するというものである。すなわち、「モデルは（分からないと認めるのではなく）それでもその項目の値を出力してしまうのか」、そして「もし出力する場合、その値は画像単体からは知り得ないはずの機密情報と相関しているか」だ。このベンチマークは、プライバシーの観点で本質的な意味において敵対的（adversarial）になるよう明示的に設計されている。それは「モデルをクラッシュさせられるか」ではなく、「現実的でありふれた条件下でモデルが情報漏洩を起こすか」を問うものだ。スマートフォンの手ブレ写真や半分隠れた項目こそが、現実世界でアップロードされる文書の日常的な姿だからである。

著者らは3つの異なるMLLMをこのベンチマークで評価し、この傾向が単一のアーキテクチャ特有の癖ではなく、広く一般的に見られるパターンであることを確認した。すなわち、視覚的根拠が乏しくなるにつれて情報漏洩率は上昇し、ノイズの多いデータセットでは顕著に悪化する。この最後の詳細は、実際のプロダクトを開発しているすべての人にとって極めて重要だ。開発チームが用意するテストセットは、本番環境のトラフィックよりも確実に綺麗であるはずだ。現実のユーザーは、劣悪な照明の下で、斜めの角度から、反射や折り目がついた状態で文書を撮影する。もし情報漏洩がノイズに比例して増大するのであれば、この問題に関する本番環境でのエラー率は、QAテストで測定したどのような数値よりも高くなる可能性が高い。

DRUF：すべてを忘れさせるのではなく、特定の関係性だけを忘れさせる

一見もっともらしい解決策である「モデルに学習データを忘れさせる」というアプローチは、あまりに大雑把な手段だ。ここで登場するのが、機械忘却（machine unlearning）に関する一連の研究である。これはモデルを一から再学習することなく、特定の学習サンプルや挙動の影響を事後的に除去する技術群だ。しかし、既存の忘却手法の多く（本論文ではベースラインとして6つの手法を検証している）が抱える問題は、その効果が広範に及びすぎることにある。氏名と住所の関連性の漏洩をやめさせようとモデルに強い忘却をかけると、KIEの処理能力そのものが全体的に低下してしまうことが多い。これには、大半は見えているわずかに擦れた数字を復元するなど、部分的な視覚的根拠から妥当な推論を行うべき項目までもが含まれてしまう。

これに対する著者らの答えが、Dynamic Relational Unlearning Framework（DRUF）である。これは除去対象を外科手術のようにピンポイントで狙い撃ちしようとするアプローチだ。DRUFは主に2つの要素で構成されている。第一に、Relational Decoupling Unlearningモジュールは、モデルの一般的な世界知識や文書読取能力を丸ごと消去しようとするのではなく、ベンチマークによって相関的な情報漏洩が最も発生しやすいと判明した特定の高リスクな項目ペアを標的にする。第二に、動的セット更新機構（dynamic set update mechanism）は、これを単発の場当たり的な修正に終わらせないための仕組みだ。事前に固定リストを決めてしまい新たな漏洩パターンを見逃したり実際には問題のない項目まで過剰修正したりするのを防ぐため、学習の進行に伴って依然としてリスクの高い項目ペアの関係性を追跡し、忘却対象のセットを動的に調整する。

概念としては、「誰に関することであれ一切の噂話を金輪際するな」と人に教え込むのと、「偶然知ってしまった特定の2つの事実を関連付けて話してはならない」と教えるのとの違いである。前者のアプローチでは、その人は会話そのものが成り立たなくなってしまう。後者はより適用範囲が狭く、適切に実現するのは困難だが、本来維持したい能力を損なわずに残せる可能性がはるかに高い。

数字が物語るもの、そして物語らないもの

主要な実験結果として、DRUFは漏洩抑制において6つのベースライン忘却手法の中で最も強力なものを4.8パーセンテージポイント上回った。さらに論文によれば、その過程でKIEの性能が維持されており、正当に読み取れる項目の抽出という本来のタスクにおいてモデルの性能が実質的に劣化しないことが示されている。従来の「実用性の低下という代償（ユーティリティ・タックス）」を払うことなく、より優れたプライバシー保護を実現する――これが本作のセールスポイントだ。

ただし、この4.8ポイントという数字は「問題が解決した」というよりは「実質的で有意義な改善」として受け止めるべきだろう。これは同じ研究チームが設計したベンチマークにおける、既存の最良ベースラインに対する差分（デルタ）である。この種の研究論文としては標準的な手法だが、それは依然として不完全な出発点からの相対的な進歩を測定しているに過ぎず、絶対的な漏洩率がゼロに近づいたことを意味するわけではない。アブストラクト自体でも、こうした対策を講じた後でさえモデルは「一貫してプライバシー漏洩を示す」と述べられている。問題を5ポイント近く低減させたのは素晴らしい成果だが、問題を根絶したのとは同義ではなく、論文自体もそこまでは主張していない。

DRUFがデファクトスタンダードの手法になるかどうかとは無関係に、ここで真に価値があるのはDocPrivacyBenchそのものだ。現在、文書AIベンダーを評価・選定する立場にあるなら、この種の問題を検証する術はほぼ確実に持っていないだろう。標準的な精度ベンチマークは鮮明な文書を用い、自信満々に出力された回答を高スコアとして評価する。視覚的根拠が劣化した条件を意図的にテストし、確信を持った誤答を「惜しいニアミス」ではなく「重大な障害」として採点するベンチマークは、現在ベンダー各社が公表している指標とは次元が異なり、間違いなくそれらよりも重要なテストである。

本人確認用OCRの開発や選定においてこれが重要な理由

もしあなたのプロダクトが身分証明書やパスポート、運転免許証などを扱っているなら、本論文が指摘する障害モードは標準的な精度指標では検知できないものであり、DRUFのコードに直接触れることがなくとも深く心に留めておく価値がある。なお、本論文は主に英数字中心の文書を前提としており、OCRやVLMにとって最難関とされる複雑な漢字や縦書きレイアウトへの影響が網羅されていない点には、日本の実務者として留意が必要だ。

具体的な要点は以下の通りだ。

• ベンダーが謳う看板の精度数値を、実際の不完全なアップロード画像に対する性能の代用として信用してはならない。項目が一部隠れていたり、低解像度だったり、見切れていたりする場合にシステムがどう振る舞うかを具体的に問い詰めるべきだ。特にKYCやコンプライアンスの判定に関わる場合、確信を持った誤答は、「読み取り不能」としてフラグが立てられるよりもはるかに危険である。
• もし顧客データを用いて自社の文書モデルをファインチューニングしているなら、実在の身分証でファインチューニングを行うこと自体が、本論文で検証されたような「相関する項目」という条件をまさに生み出してしまうという点に留意すべきだ。学習セットに実在する人物の文書が含まれている場合、このリスクは決して机上の空論ではない。
• ベンダーに対し、視覚的根拠が劣化したシナリオでのテストを実施したことがあるかを問い質し、ベンチマーク画像がどのようなものか把握できるまでは「自社ベンチマークで96%を達成」という言葉を不完全な回答として扱うべきだ。綺麗で照明の行き届いた、全体が完全に見えているテスト文書は、ユーザーから実際に送られてくる乱雑な画像に対してモデルがどう振る舞うかを何一つ教えてくれない。
• モデルがある項目の値を返す場合、確信度（confidence）や根拠の品質に関する指標も併せて提示されるかを確認すべきだ。どれだけ視覚的に確認できたかに関わらず綺麗なJSONを返すだけのシステムよりも、「これは読み取ったもの」「これは推論したもの」と明示できるシステムのほうが、監査可能性の面でもコンプライアンス上の信頼性の面でも根本的に優れている。

論文ではモデル学習レベルでの解決策に焦点が当てられているため、信頼度フラグの付与といった運用・デプロイ側での緩和策については深く掘り下げられていない。しかし、これは自然な補完関係にある。自社でモデルを再学習できない場合でも、視覚的根拠が乏しい条件下で抽出された項目には疑いの目を向け、出力を盲信せずに人手による目視確認（マニュアルレビュー）へとルーティングするパイプラインを設計することは可能だ。

本研究が抱える率直な限界

率直に指摘しておくべき点がいくつかある。本論文では3つのMLLMと6つの忘却ベースラインを評価している。これはベンチマーク論文のスコープとしては妥当な規模だが、文書AIのエコシステム全体から見ればごく一部に過ぎない。異なるアーキテクチャや学習方針を採用しているものも含め、あらゆる商用文書AIシステムにこれが一般化できるかどうかは、本論文では完全に答えきれておらず、未解決の問いのままだ。またDRUFは忘却手順を適用するためにモデルの内部構造へのアクセスを必要とするため、自前でモデルの学習やファインチューニングを行う組織向けの修正策であり、外部のクローズドなAPIを呼び出しているだけの環境に後付けできるものではない。

さらに、論文内でも率直に認められつつも完全には解決されていない構造的なジレンマが存在する。「関係性のコンテキストを利用して空白を埋める」こと自体が、そもそも文書AIを実用的なものにしている要因でもあるという点だ。フォームの項目が汚れていても、周囲のコンテキストから正しい値が明白であるなら、通常はモデルに推論して補完してほしいはずだ。「有用なコンテキスト推論」と「プライバシーを漏洩させる記憶の再生」との境界線は明確ではなく、DRUFのターゲットを絞ったアプローチはその境界線上を慎重に歩もうとする試みであって、問題が完全に解決されたことを証明したわけではない。

それでも、ここで最も重要な貢献は4.8ポイントという数字そのものではない。白日の下に隠れていた障害モードに名前を与え、それを実際に測定する手段を構築したことにある。DRUFが最終的に定着する解決策になるかどうかにかかわらず、身分証明書を取り扱うプロダクトを開発している者であれば、今すぐにでもベンダーに対してこの問いを投げかけるべきである。