身分証明書を読み取るAI（文書理解マルチモーダルLLM）が、画像に写っていない項目まで「学習時に覚えた項目同士の関係」から推測して出力してしまう——そんな研究が2026年8月13日にarXivで公開されました。氏名と証明書番号のように、ひも付いた複数の個人情報がまとめて出てくる点を「関係漏えい（relational privacy leakage）」と名付けて指摘しています。
eKYCや窓口業務でAI-OCRを使っている、あるいは導入を検討している組織にとっては、「読み取れなかった欄をAIが勝手に埋めていないか」をベンダーに確認する材料になります。
この記事でわかること
- 「関係漏えい」とは何か、従来のAI情報漏えい論と何が違うのか
- なぜ視覚的な根拠がないのにAIが個人情報を出力してしまうのか
- 検証に使われたモデル・データと、報告された漏えいの度合い
- この研究の限界（日本の証明書は対象外です）
- 情シスがAI-OCR/eKYCのベンダーに確認すべきこと
そもそも「文書理解MLLM」とは何者か
文書理解MLLM（マルチモーダル大規模言語モデル）とは、書類の画像を丸ごと読み込んで、「氏名は？」「有効期限は？」といった問いに文章で答えるAIです。従来のOCR（画像から文字を切り出して読む）と違い、レイアウトそのものを解釈して「これは氏名欄」「これは証明書番号」と意味のある項目として抜き出します。この処理はKIE（Key Information Extraction＝重要情報抽出）と呼ばれ、身分証や請求書の自動処理の中核になっています。
「うちはMLLMなんて導入していない」と思うかもしれません。しかしこの種のモデルは製品名として表に出ず、業務SaaSの一機能として動いていることがあります。心当たりがあるとすれば、次のような業務です。
- オンライン本人確認（eKYC）での運転免許証・在留カードの読み取り
- 経費精算・請求書処理サービスに付いている「AI-OCR」機能
- 入退社手続きや契約書チェックの自動化ツール
- 複合機・スキャナと連携するクラウド仕分けサービス
どの製品が内部で何を使っているかは公開されていないことが多く、推測で決めつけるのは危険です。該当判定は後述の「ベンダーへの確認項目」で行うのが現実的でしょう。
関係漏えいとは何か？
関係漏えいとは、AIが学習時に覚えた「項目同士のつながり」を頼りに、画像に写っていない個人情報まで補って出力してしまう現象です。
身分証には氏名・生年月日・証明書番号・発行地といった項目が並び、これらは互いに強くひも付いています。モデルは学習の過程で、個々の文字だけでなく「この氏名にはこの番号」という組み合わせごと記憶してしまう。すると画像がぼやけていたり、その欄が写っていなかったりしても、モデルは「読めません」と答えず、記憶から埋めにいきます。
厄介なのは、出てくる値が2種類ありうることです。
- 学習データに実在した個人の値 ── そのまま個人情報の漏えいになる
- もっともらしいでたらめ ── 誤った情報が「正しい抽出結果」の顔をして業務に流れ込む
どちらも困りますが、実務では後者のほうが厄介かもしれません。返ってきた証明書番号が、実際に読み取った結果なのか記憶から埋めた推測なのかは、出力を眺めただけでは区別がつかないからです。AIの出す確信度そのものが当てにならない問題は、以前AIの確信度は信用できない 監視の穴を示す研究でも取り上げました。
どう検証したのか
論文タイトルは「Beyond Visual Evidence: Revealing and Mitigating Relational Privacy Leakage in Document MLLMs」。著者らはarXivの注記でACM Multimedia 2026採録としています（arXiv版は著者版のため、最終版と細部が異なる可能性があります）。
著者らは DocPrivacyBench という評価用ベンチマークを新たに作り、公開されている3つの文書理解MLLM（LLaVA-1.5系、Idefics2、xGen系）に対して、2通りの引き出し方を試しています。
| 手口 | モデルに与えるもの | 見ているもの |
|---|---|---|
| 画像ベース（Image-Driven） | 該当欄の視覚的な根拠がない身分証画像 | 画像を見ずに記憶から答えてしまうか |
| プロンプトベース（Prompt-Driven） | 質問形・指示形・人物を特定する形など約1,300通りの問いかけ | 聞き方次第で機微な項目を吐き出すか |
使われた身分証画像はすべて合成データです。架空のデザインの身分証・パスポートを集めた DocXPand-25k と、米国の州および欧州各国を模した運転免許証などの IDNet を組み合わせ、合計1万5千枚規模とされています。いずれも実在しない人物の架空の証明書で、プライバシー配慮のために作られた公開データセットです。
報告された結果
論文によれば、視覚的な根拠のない画像を与えても、モデルは「氏名と証明書番号」という機微な組み合わせを高い割合で出力しました。ただし漏えいのしやすさはモデルによって大きく違います。DocXPand-25kでの画像ベース評価では、LLaVA-1.5系が0.874、Idefics2が0.196（数値が大きいほど漏れやすい、論文独自の指標）と、4倍以上の開きが報告されています。「AIだから一律に危ない」のではなく、どのモデルを使っているかで実際のリスクが変わるということです。
対策として提案されたのが DRUF（Dynamic Relational Unlearning Framework） です。危険な項目の組を動的に更新しながら、そのつながりだけを切り離して忘れさせる（アンラーニング）手法で、KIE本来の抽出性能は保ったまま漏えいを抑えられる、と著者らは主張します。既存の6種類のアンラーニング手法と比較し、最も強い手法に対して抑制率を4.8ポイント改善したとのことです。
この研究の限界（重要）
実務判断に使う前に、次の点は押さえておく必要があります。
- すべて合成データである：実在の個人情報がそのまま出力された、という実証ではありません。ただし「モデルが項目間の関係を覚え、根拠なく埋める」という挙動そのものは、実データで学習した商用モデルでも起こりうる構造的な問題です。
- 日本の証明書は対象外：使われたのは架空の欧州系デザインと米国州・欧州各国を模したものです。日本の運転免許証・マイナンバーカード・在留カードで同じことが起きるかは、本研究では確認されていません。
- 評価は公開モデル3種のみ：商用のAI-OCR/eKYCサービスが同じ挙動を示すかは別途検証が必要です。
- arXiv公開版のため、最終版で数値や記述が変わる可能性があります。
身分証まわりのAIリスクとしては、読み取る側だけでなく作る側の問題もあります。生成AIで偽造身分証を作られる懸念については生成AIによる身分証偽造、eKYC本人確認の限界を研究に学ぶを参照してください。
情シスはどうすべきか
まず押さえたいのは、これがまったく新しい論点ではないということです。個人情報保護委員会は2023年6月2日の「生成AIサービスの利用に関する注意喚起等について」で、生成AIに入力した情報が学習に利用され、統計的に関連する他の情報とともに（正確または不正確に）出力される可能性があると明示しています。今回の研究は、その一般論が身分証の読み取りという具体的な業務で実際に起きうることを、数字で示したものと読めます。
ベンダーに確認すべきことは？
自前で長いチェックリストを積み上げるより、既存の委託先管理・システム選定の質問票に次の項目を足すのが現実的です。
- 読み取れなかった項目は「空欄」で返るのか、推測値が入るのか。項目ごとの信頼度スコアは返るか
- 入力した書類画像や抽出結果が、モデルの学習に使われることはあるか。オプトアウトできるか
- 抽出結果を人が原本と突き合わせる工程が、業務フローの設計に組み込まれているか
- 基盤モデルは自社開発か外部APIか。外部なら第三者提供・越境移転の整理はどうなっているか
個人データを外部サービスに委ねる際の基本的な考え方は、上記の個人情報保護委員会の注意喚起と、IPA「中小企業の情報セキュリティ対策ガイドライン」にまとまっています。まずはここを土台に、AI-OCRが委託先管理の対象に入っているかを見直すのが早道でしょう。あわせて、現場に「AIの読み取り結果は必ず原本と突き合わせる」を根づかせる地道な啓発も効きます（IPA「対策のしおり」）。
現場目線の所感
AI-OCRは、情シスが把握しないまま業務部門が導入してしまう典型的なSaaSです。稟議を上げるのは人事や経理で、情シスの出番はアカウント発行とSSO連携だけ、という現場は珍しくないでしょう。そして扱うのが、よりによって身分証という最も機微なデータです。
今回の研究が示す挙動が本当に厄介なのは、異常として観測できない点だと感じます。エラーも出ず、監査ログにも「この欄は推測で埋めました」とは残らない。整った抽出結果が返ってくるだけです。限られた人員でSaaSの棚卸しをしている身としては、「動いているように見えるものほど確認が後回しになる」という現実がこたえます。
だからこそ、技術的な防御を待つ前にできることとして、契約・調達の段階で「読めなかった欄はどう返るのか」を一言聞いておく価値があります。答えられないベンダーがいたら、それ自体が判断材料です。
まとめ
- 身分証を読むAIは、視覚的な根拠がなくても学習時に覚えた項目の関係から欄を埋めることがあり、氏名と証明書番号のような機微な組み合わせがまとめて出力されうる（漏えいのしやすさはモデルによって4倍以上の差）。
- 検証は合成データ・公開モデル3種に限られ、日本の運転免許証やマイナンバーカードでの再現性は確認されていない。過度な一般化は禁物。
- 情シスの実務としては、AI-OCR/eKYCを委託先管理の対象に含め、「読めなかった欄は空欄で返るか」「入力データが学習に使われるか」をベンダーに確認するところから始める。
出典
- Beining Xu ほか「Beyond Visual Evidence: Revealing and Mitigating Relational Privacy Leakage in Document MLLMs」arXiv:2608.12911（2026年8月13日公開、ACM Multimedia 2026採録との注記あり）https://arxiv.org/abs/2608.12911
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- DocXPand-25k（合成身分証データセット）arXiv:2407.20662 https://arxiv.org/abs/2407.20662
- IDNet（合成身分証データセット）arXiv:2408.01690 https://arxiv.org/abs/2408.01690
- IPA「中小企業の情報セキュリティ対策ガイドライン」https://www.ipa.go.jp/security/guide/sme/index.html
