本文へスキップ

AI運用の判断と根拠を引く

トップへ戻る

日本語・日本業務特有のAI問題 — 敬語、縦書き、和暦、帳票、住所、人名、表記揺れ、日本語OCRを「日本語対応」の一語で潰さず、業務データ型・文書レイアウト・文字体系・社会言語的適切性ごとに検証する

用語・参照用語・参照公式仕様のみ公式仕様のみ鮮度未確認鮮度を確定できない

記事状態: 公開 · 最終確認: 未確認

要点

「日本語を生成できることと、日本の業務データを正確に処理できることは別である。住所の表記揺れ、人名の異体字、縦書きや帳票レイアウト、和暦、敬語などは独立した失敗条件を持つ。重要項目は生成モデルのもっともらしさだけで確定せず、公的・業務上の参照データ、決定的な変換規則、文書種別ごとの評価、人による訂正を組み合わせる。」

現在の判断

  • JAPAN_LOCALIZATION_CONTRACTをCoreの候補とする。最低限必要なフィールドは、タスク、ドキュメント/データ型、スクリプト/レイアウト、正規化対象、正式な参照先、モデル/OCRバージョン、ロケール/カレンダー、入力の出典・来歴、生の出力、正規化された出力、検証結果、人による修正、最終的な成果物。
  • 日本語能力は少なくとも (A) generation/style、(B) OCR/layout、(C) character 相互運用性、(D) address normalization、(E) name matching、(F) date/calendar、(G) structured form extraction に分ける。
  • 住所・郵便番号・氏名等は、LLMがもっともらしい正規形を生成するだけでは確定しない。ABR、日本郵便、文字情報基盤等のauthoritative/reference 出典との照合結果と出典 バージョンを残す。
  • 日本語OCRは縦書き、複数段、漢字、混在script、手書き、処理結果の受領記録/table/layoutをfixture別に測る。単一CER/WERまたは英語中心比較評価から日本語帳票性能を推定しない。
  • 敬語はgrammar correctnessだけでなく、相手/役割/場面/組織規約に依存するpragmatic appropriatenessであり、自動評価だけで閉じず代表業務fixtureとhuman reviewを置く。
  • 和暦は表示形式と内部の正式な日付(正式な date)を分離する。生成テキストの「令和N年」を業務システムへ直接コミットせず、カレンダー変換と範囲検証を決定論的なレイヤーで行う。

どこまで当てはまるか

企業AI運用の共通原則: localization 評価、structured extraction、normalization、出典・来歴、human review。 Japan overlay: 住所/氏名/文字/和暦/敬語/帳票/縦書き。 実装/non-LLM component: OCR、address registry、postal data、name matching、Unicode/character mapping。 ベンチマーク:日本語特有のOCR/VLM用固定テストセット。

詳しく理解する

なぜ重要か

日本語を生成できることと、日本の業務データを安全に処理できることは同義ではない。住所には表記揺れと行政上の階層、人名には異体字・外字・読みの曖昧性、文書には縦書き・複数段・帳票レイアウト、日付には西暦/和暦、対人文書には敬語・役職・定型がある。汎用LLM/VLM/OCRの総合スコアだけでは、これらの失敗 利用機能・接続経路を十分に表現できないため、Japan-specific fixtureと正規化/検証層が必要である。

対象範囲と前提

企業AI運用の共通原則: localization 評価、structured extraction、normalization、出典・来歴、human review。 Japan overlay: 住所/氏名/文字/和暦/敬語/帳票/縦書き。 実装/non-LLM component: OCR、address registry、postal data、name matching、Unicode/character mapping。 ベンチマーク:日本語特有のOCR/VLM用固定テストセット。

検討ポイント

Q1. 「日本語対応」を単一利用可能な機能として扱わず、language generation / typography-layout / OCR / entity normalization / calendar / business-registerの別能力として評価すべきか。 Q2. 住所・人名等は生成モデル単独で正規化せず、authoritative/reference dataと照合する設計が必要か。 Q3. 縦書き・混在文字種・漢字・帳票は一般multilingual 比較評価では不足し得るか。

根拠資料の対応表

  • 資料の種類: official government base registry 原資料の題名: アドレス・ベース・レジストリ org: デジタル庁 原資料の正式なURL: https://www.digital.go.jp/policies/base_registry_address publication/update/access: updated 2026-03-30 / 参照日 2026-09-16 バージョン: 町字正式版は2025-06-01公開 裏付ける該当箇所: 取組の概要、町字データ、整備状況 根拠の分類: VERIFIED_SPEC 対応関係: 裏付け / 文脈・入力情報 established: 住所・所在地を公的基礎情報データベースとして整備し、町字データを正式公開している。住所は単なる自由文字列ではなく参照可能な公的データとして扱える。
  • 資料の種類: official government explanatory publication 原資料の題名: 住所の「表記揺れ」解決で官民の負担削減、災害支援も アドレス・ベース・レジストリが目指す「データを自動的に使える未来」 org: デジタル庁 原資料の正式なURL: https://digital-agency-news.digital.go.jp/articles/2025-10-31-0 publication/access: 2025-10-31 / 参照日 2026-09-16 裏付ける該当箇所: 「東京都千代田区紀尾井町1-3」「1-3」「一の三」の例、ABRジオコーダー説明 根拠の分類: VERIFIED_SPEC + SOURCE_REPORT 対応関係: 裏付け / failure-envelope 確立済み:同一住所に複数の表記が存在し、文字列の一致のみでは別データとして扱われる可能性がある。ABRジオコーダーは住所文字列をレジストリと照合し、正規化された住所、町字ID、緯度経度等を出力する。
  • 資料の種類: official postal data/API 原資料の題名: 郵便番号データダウンロード / 郵便番号・デジタルアドレスAPI org: 日本郵便 原資料の正式なURL: https://www.post.japanpost.jp/service/search/zipcode/download/ ; https://lp-api.da.pf.japanpost.jp/ publication/update/access: 現在の; postal change notice updated 2026-08-31 / 参照日 2026-09-16 バージョン:現在のAPIインターフェース。2026-03-19にビジネスデジタルアドレスのサポートを追加、2026-07-30に入口の緯度・経度を更新。 裏付ける該当箇所: UTF-8 1-record-1-line data、漢字/カナ/ローマ字、公式API 根拠の分類: VERIFIED_SPEC + PRODUCT_VOLATILE 対応関係: 裏付け / availability-context established: 日本郵便は郵便番号住所データを複数形式で提供し、公式APIは最新郵便番号データと連携する。住所補完・検証は生成モデルの記憶だけに依存させる必要がない。
  • 資料の種類: official 相互運用性/character infrastructure 原資料の題名: 文字情報基盤 org: IPA / IMI 原資料の正式なURL: https://imi.ipa.go.jp/mj/ 公開/アクセス:現在のページ / 閲覧日 2026-09-16 バージョン: 約6万文字の行政人名漢字等を整備 裏付ける該当箇所: 文字情報基盤の取組み 根拠の分類: VERIFIED_SPEC 対応関係: 裏付け / limit established: 行政で用いられる人名漢字等約6万文字を対象に標準化を進め、住基ネット統一文字、JIS、常用漢字に含まれない文字等の相互運用を扱う。人名処理を「一般的な常用漢字だけ」の問題へ縮小できない。
  • 資料の種類: official government service/評価 原資料の題名: 氏名突合支援サービス よくある質問 org: デジタル庁 原資料の正式なURL: https://developers.digital.go.jp/documents/name-matching-support/faq/ publication/update/access: initial モデル 2025-10; 参照日 2026-09-16 バージョン: FAQ 現在の 利用機能・接続経路 裏付ける該当箇所: 精度、score threshold、文字範囲、日本国外利用 根拠の分類: VERIFIED_SPEC + PRODUCT_VOLATILE 対応関係: 裏付け / limit 確立済み: 初期モデルの評価は日本人名が95%以上、外国人名が80%以上とされるが、業務特性に応じてしきい値を調整可能と明記されており、常用漢字や人名用漢字以外の文字も返される可能性がある。単一のしきい値や「人名の一致=確定」という考え方を、すべての業務にそのまま当てはめてはならない。
  • 出典の分類:公式ライブラリの研究開発/実装 原資料の題名: NDLOCR-Liteの公開とその背景 org/author: 国立国会図書館 次世代システム開発研究室 / 青池亨 原資料の正式なURL: https://current.ndl.go.jp/e2891 publication/access: 2026-06-25 / 参照日 2026-09-16 バージョン: NDLOCR-Lite, リリース済み 2026-02-24 裏付ける該当箇所: 2026年現在のNDLOCR/NDL古典籍OCR/Lite系統 根拠の分類: VERIFIED_SPEC + OSS_PRACTICE 対応関係: 裏付け / 実装 確立事項: NDLは日本語資料のOCRに関する継続的な研究を行い、NDLOCR/古典籍OCRおよびLite版を公開している。Lite版は、一般的なPCでGPUを必要とせずに実行できることを目的としており、英文や手書き文字にも実験的に対応している。
  • 資料の種類: primary research 比較評価 原資料の題名: JaWildText: A 比較評価 for Vision-Language Models on Japanese Scene Text Understanding 著者:前田 昂輝、岡崎 直昭 原資料の正式なURL: https://arxiv.org/abs/2603.27942 publication/access: 2026-03-30 / 参照日 2026-09-16 バージョン: arXiv 2603.27942 裏付ける該当箇所: abstract; dataset/task/error analysis 根拠の分類: RESEARCH 対応関係: 裏付け / counter / 比較評価 確立された内容: 日本語のシーンテキストには、混在する文字、縦書き、膨大な文字インベントリが存在し、一般的な多言語ベンチマークでは十分に捉えきれない問題を指摘。3,241のインスタンス、1.12Mによって注釈付けされた文字、3,643種類のユニークな文字タイプを用い、STVQA/レシートKIE/手書きOCRの3つのタスクにおいて14のオープンウェイトVLMを評価。最良の平均0.64を示したが、特に漢字認識が主要なボトルネックであると報告している。
  • 出典クラス:公式言語リソース 原資料の題名: データベース・コーパス・資料 / BCCWJ2 org: 国立国語研究所 原資料の正式なURL: https://www.ninjal.ac.jp/resources/ ; https://clrd.ninjal.ac.jp/ publication/update/access: BCCWJ2 partial 公開・提供 2026-03-24 / 参照日 2026-09-16 バージョン: BCCWJ2 staged 公開・提供; 完了 planned through FY2028 裏付ける該当箇所: 書籍・雑誌・新聞・白書・Web・法律等、BCCWJ2公開案内 根拠の分類: VERIFIED_SPEC + RESEARCH 対応関係: 裏付け / evaluation-context established: 日本語の書き言葉・話し言葉を評価/研究するための専門コーパス群が存在する。敬語・文体・語彙の妥当性は、LLMの自己申告だけでなく検索対象の文書群/専門レビューへ接続可能。

利用できる条件

ABR: 公開データの整備粒度・更新日・対象地域/住所階層。 日本郵便API: 現在の API仕様・利用条件・rate/利用可能性・返却粒度。 氏名突合: 国内利用前提、一部機能の国外IP制限、現在の モデル/threshold。 OCR: OS/hardware、モデル/公開・提供、文書種、縦横/手書き、入力画質。 Language resources: 検索対象の文書群 license/access、genre/time coverage。

実装・運用

住所、郵便、文字、人名、OCR、検索対象の文書群の各基盤は実在し、Japan-specific 評価/normalization layerを構成可能。統合条件・契約自体はPROPOSAL。生成LLM単独でなく 決まった規則に従う parser + authoritative lookup + OCR/VLM + rule 妥当性の検証 + human review のcomposite architectureを推奨候補とする。

確認・評価方法

後続TEST_PROFILE: ①縦書き/横書き/二段組、②請求書・領収書・申請書、③漢字/ひらがな/カタカナ/Latin/数字混在、④旧字/異体字/外字、⑤住所の全半角・丁目/番/号・漢数字/算用数字・ハイフン揺れ、⑥同姓同名/読み揺れ/外国人名、⑦西暦/和暦/元年/境界日、⑧敬語・役職・社外/社内文書をfixture化する。評価指標はCER、field exact match、structure fidelity、address normalization exactness、name false-match/false-nonmatch、date conversion exactness、human 訂正 rate、critical-field errorを分離する。

セキュリティとプライバシー

Privacy: 氏名・住所・帳票はPIIを含み得るため、比較評価/評価にはsyntheticまたは適法に利用可能なfixtureを優先し、raw 成果物 保持期間・保持方針を制限。 監査: raw→OCR→normalization→reference lookup→human 訂正→finalの変換履歴とreference バージョンを保持。 コスト: 高価なVLMを全ページへ使う前にlayout/OCR/field 処理先の振り分けを行い、低確信度/critical fieldだけ上位モデルまたはhumanへ送る比較を行う。 Operability: 日本語特有失敗を「モデルが日本語対応か」の一列で管理せず、data type別SLOへ分解する。

要点と前提

---

現行性の確認範囲と限界

Japanese AI 裏付け is decomposed across authoritative address/postal/character/name/date/OCR/language controls; product/API/モデル details stay version-pinned/PRODUCT_VOLATILE.

確認できていること

  • JAPAN_LOCALIZATION_CONTRACTをCoreの候補とする。最低限必要なフィールドは、タスク、ドキュメント/データ型、スクリプト/レイアウト、正規化対象、正式な参照先、モデル/OCRバージョン、ロケール/カレンダー、入力の出典・来歴、生の出力、正規化された出力、検証結果、人による修正、最終的な成果物。

  • 日本語能力は少なくとも (A) generation/style、(B) OCR/layout、(C) character 相互運用性、(D) address normalization、(E) name matching、(F) date/calendar、(G) structured form extraction に分ける。

  • 住所・郵便番号・氏名等は、LLMがもっともらしい正規形を生成するだけでは確定しない。ABR、日本郵便、文字情報基盤等のauthoritative/reference 出典との照合結果と出典 バージョンを残す。

  • 日本語OCRは縦書き、複数段、漢字、混在script、手書き、処理結果の受領記録/table/layoutをfixture別に測る。単一CER/WERまたは英語中心比較評価から日本語帳票性能を推定しない。

  • 敬語はgrammar correctnessだけでなく、相手/役割/場面/組織規約に依存するpragmatic appropriatenessであり、自動評価だけで閉じず代表業務fixtureとhuman reviewを置く。

  • 和暦は表示形式と内部の正式な日付(正式な date)を分離する。生成テキストの「令和N年」を業務システムへ直接コミットせず、カレンダー変換と範囲検証を決定論的なレイヤーで行う。

よくある失敗・反証

  • 日本語で自然に会話できるモデルでも、縦書きOCR、外字、人名突合、住所正規化、和暦変換の正確性は別能力である。

  • authoritative dataにもcoverage/更新時点/粒度の限界がある。ABR町字正式版の存在は、全住居番号・地番が完全整備済みという意味ではない。

  • 郵便番号は住所主体の識別そのものではない。郵便番号から得られる町域情報を個別建物・人物住所の確定へ外挿しない。

  • 氏名突合サービスの公称精度はその初期評価fixtureに対する値であり、特定組織の利用環境の名簿、外国人名、旧字/異体字、OCR誤り混入条件へ一般化しない。

  • JaWildTextはresearch 比較評価であり、特定commercial モデル/serviceのSLAではない。

  • NDLOCR-Liteが日本語資料向け実装として存在することは、あらゆる現代帳票・手書き・写真に最適という保証ではない。

  • 敬語/文体の「正しさ」は一意でない。文化庁等の一般指針や検索対象の文書群頻度を、組織固有の文書規程・顧客関係へそのまま置換しない。

  • 上記の現在の改訂版を再度固定(pin)し、住所、氏名、和暦、帳票、OCR、敬語の修正機能を用いて、重要項目のエラー率と人による修正率を実測する。各一連の処理(処理の流れ)の許容しきい値を定義した時点で、更新の判断が可能となる。

実務での使い方

  • ABR: 公開データの整備粒度・更新日・対象地域/住所階層。 日本郵便API: 現在の API仕様・利用条件・rate/利用可能性・返却粒度。 氏名突合: 国内利用前提、一部機能の国外IP制限、現在の モデル/threshold。 OCR: OS/hardware、モデル/公開・提供、文書種、縦横/手書き、入力画質。 Language resources: 検索対象の文書群 license/access、genre/time coverage。

  • 住所、郵便、文字、人名、OCR、検索対象の文書群の各基盤は実在し、Japan-specific 評価/normalization layerを構成可能。統合条件・契約自体はPROPOSAL。生成LLM単独でなく 決まった規則に従う parser + authoritative lookup + OCR/VLM + rule 妥当性の検証 + human review のcomposite architectureを推奨候補とする。

  • 後続TEST_PROFILE: ①縦書き/横書き/二段組、②請求書・領収書・申請書、③漢字/ひらがな/カタカナ/Latin/数字混在、④旧字/異体字/外字、⑤住所の全半角・丁目/番/号・漢数字/算用数字・ハイフン揺れ、⑥同姓同名/読み揺れ/外国人名、⑦西暦/和暦/元年/境界日、⑧敬語・役職・社外/社内文書をfixture化する。評価指標はCER、field exact match、structure fidelity、address normalization exactness、name false-match/false-nonmatch、date conversion exactness、human 訂正 rate、critical-field errorを分離する。

  • Privacy: 氏名・住所・帳票はPIIを含み得るため、比較評価/評価にはsyntheticまたは適法に利用可能なfixtureを優先し、raw 成果物 保持期間・保持方針を制限。 監査: raw→OCR→normalization→reference lookup→human 訂正→finalの変換履歴とreference バージョンを保持。 コスト: 高価なVLMを全ページへ使う前にlayout/OCR/field 処理先の振り分けを行い、低確信度/critical fieldだけ上位モデルまたはhumanへ送る比較を行う。 Operability: 日本語特有失敗を「モデルが日本語対応か」の一列で管理せず、data type別SLOへ分解する。

  • 公開後の業務において、JAPAN_LOCALIZATION_CONTRACTをEA-004非LLM AI、EA-011 ベンチマーク、EA-016 評価、EA-099 アクセシビリティへ相互参照する。

  • ABRの町字以降(街区符号・住居番号・地番)の2026年以降整備状況を再pinする。

  • 日本郵便APIの現在の データ形式の定義/バージョン/rate/terms、氏名突合支援の現在の モデル/バージョン/利用可能性を再確認する。

  • NDLOCR-Lite repoのexact 公開・提供/tag/commitとlicense、NDLOCR系の現行比較評価/対応layoutを採集する。

  • JaWildTextの正式公開dataset/評価 code 改訂版をpinし、commercial/現在の modelsを同一fixtureで再測定する。

  • 和暦について、政府/標準の正式な conversion 出典と元号境界fixtureを追加する。

  • 敬語・社内外文体はNINJAL 検索対象の文書群だけで閉じず、文化庁等の一次指針と実組織style guideを分離してfixture化する。

  • Japanese AI 裏付け is decomposed across authoritative address/postal/character/name/date/OCR/language controls; product/API/モデル details stay version-pinned/PRODUCT_VOLATILE.

まだ確認できていないこと

  • EA-100-UNKNOWN-01

    / STOP_CONDITION

  • EA-100-UNKNOWN-02

    現在の ABRの番地以下coverage、郵便API 現在の 利用枠/terms、氏名突合現在の モデル 改訂版、NDLOCR-Lite exact tag/commit、commercial OCR/VLMの日本語帳票比較、和暦の採用正式な library/出典、敬語の業務別受け入れ確認 threshold。

  • EA-100-UNKNOWN-CURRENTNESS

    外部根拠の再確認日が正式な本文・公開管理情報で確定していないため、現行性は未確認のまま保持する。確認日を推測して補わない。

根拠資料

出典ID・検証情報・機械可読データ

根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。

記事ID
EA-100
最終確認日
—
提供元・モデル・プラン・利用環境
—
対象地域
—
元資料の全文と収録照合記録
WHY_THIS_MATTERS_TO_UPDATE

日本語を生成できることと、日本の業務データを安全に処理できることは同義ではない。住所には表記揺れと行政上の階層、人名には異体字・外字・読みの曖昧性、文書には縦書き・複数段・帳票レイアウト、日付には西暦/和暦、対人文書には敬語・役職・定型がある。汎用LLM/VLM/OCRの総合スコアだけでは、これらのfailure surfaceを十分に表現できないため、Japan-specific fixtureと正規化/検証層が必要である。

SCOPE_ROUTING

Enterprise AI Core: localization evaluation、structured extraction、normalization、provenance、human review。 Japan overlay: 住所/氏名/文字/和暦/敬語/帳票/縦書き。 Implementation/non-LLM component: OCR、address registry、postal data、name matching、Unicode/character mapping。 Benchmark: Japanese-specific OCR/VLM fixture。

CLAIM_OR_RESEARCH_QUESTION

Q1. 「日本語対応」を単一capabilityとして扱わず、language generation / typography-layout / OCR / entity normalization / calendar / business-registerの別能力として評価すべきか。 Q2. 住所・人名等は生成モデル単独で正規化せず、authoritative/reference dataと照合する設計が必要か。 Q3. 縦書き・混在文字種・漢字・帳票は一般multilingual benchmarkでは不足し得るか。

EVIDENCE TABLE
  • source class: official government base registry exact title: アドレス・ベース・レジストリ org: デジタル庁 canonical URL: https://www.digital.go.jp/policies/base_registry_address publication/update/access: updated 2026-03-30 / accessed 2026-09-16 version: 町字正式版は2025-06-01公開 supporting locator: 取組の概要、町字データ、整備状況 evidence label: VERIFIED_SPEC relation: support / context established: 住所・所在地を公的基礎情報データベースとして整備し、町字データを正式公開している。住所は単なる自由文字列ではなく参照可能な公的データとして扱える。
  • source class: official government explanatory publication exact title: 住所の「表記揺れ」解決で官民の負担削減、災害支援も アドレス・ベース・レジストリが目指す「データを自動的に使える未来」 org: デジタル庁 canonical URL: https://digital-agency-news.digital.go.jp/articles/2025-10-31-0 publication/access: 2025-10-31 / accessed 2026-09-16 supporting locator: 「東京都千代田区紀尾井町1-3」「1-3」「一の三」の例、ABRジオコーダー説明 evidence label: VERIFIED_SPEC + SOURCE_REPORT relation: support / failure-envelope established: 同一住所に複数表記が存在し、文字列一致では別データ化し得る。ABRジオコーダーは住所文字列をレジストリと照合し、正規化住所、町字ID、緯度経度等を出力する。
  • source class: official postal data/API exact title: 郵便番号データダウンロード / 郵便番号・デジタルアドレスAPI org: 日本郵便 canonical URL: https://www.post.japanpost.jp/service/search/zipcode/download/ ; https://lp-api.da.pf.japanpost.jp/ publication/update/access: current; postal change notice updated 2026-08-31 / accessed 2026-09-16 version: API current surface; Business Digital Address support added 2026-03-19, entrance lat/long update 2026-07-30 supporting locator: UTF-8 1-record-1-line data、漢字/カナ/ローマ字、公式API evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / availability-context established: 日本郵便は郵便番号住所データを複数形式で提供し、公式APIは最新郵便番号データと連携する。住所補完・検証は生成モデルの記憶だけに依存させる必要がない。
  • source class: official interoperability/character infrastructure exact title: 文字情報基盤 org: IPA / IMI canonical URL: https://imi.ipa.go.jp/mj/ publication/access: current page / accessed 2026-09-16 version: 約6万文字の行政人名漢字等を整備 supporting locator: 文字情報基盤の取組み evidence label: VERIFIED_SPEC relation: support / limit established: 行政で用いられる人名漢字等約6万文字を対象に標準化を進め、住基ネット統一文字、JIS、常用漢字に含まれない文字等の相互運用を扱う。人名処理を「一般的な常用漢字だけ」の問題へ縮小できない。
  • source class: official government service/evaluation exact title: 氏名突合支援サービス よくある質問 org: デジタル庁 canonical URL: https://developers.digital.go.jp/documents/name-matching-support/faq/ publication/update/access: initial model 2025-10; accessed 2026-09-16 version: FAQ current surface supporting locator: 精度、score threshold、文字範囲、日本国外利用 evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / limit established: 初期モデル評価は日本人名95%以上、外国人名80%以上とされるが、業務特性に応じthresholdを調整可能と明記され、常用/人名用漢字外の文字も返り得る。単一thresholdや「人名一致=確定」を全業務へ外挿しない。
  • source class: official library R&D / implementation exact title: NDLOCR-Liteの公開とその背景 org/author: 国立国会図書館 次世代システム開発研究室 / 青池亨 canonical URL: https://current.ndl.go.jp/e2891 publication/access: 2026-06-25 / accessed 2026-09-16 version: NDLOCR-Lite, released 2026-02-24 supporting locator: 2026年現在のNDLOCR/NDL古典籍OCR/Lite系統 evidence label: VERIFIED_SPEC + OSS_PRACTICE relation: support / implementation established: NDLは日本語資料のOCRを継続研究し、NDLOCR/古典籍OCRとLite版を公開。Liteは一般PCでGPU不要の実行を狙い、英文・手書きも実験的対応する。
  • source class: primary research benchmark exact title: JaWildText: A Benchmark for Vision-Language Models on Japanese Scene Text Understanding authors: Koki Maeda, Naoaki Okazaki canonical URL: https://arxiv.org/abs/2603.27942 publication/access: 2026-03-30 / accessed 2026-09-16 version: arXiv 2603.27942 supporting locator: abstract; dataset/task/error analysis evidence label: RESEARCH relation: support / counter / benchmark established: Japanese scene textにはmixed scripts、vertical writing、大きなcharacter inventoryがあり、一般multilingual benchmarkが十分に捉えない問題を指摘。3,241 instances、1.12M annotated characters、3,643 unique character types、STVQA/receipt KIE/handwriting OCRの3 taskで14 open-weight VLMを評価し、best average 0.64、特にkanji recognitionを主要bottleneckと報告。
  • source class: official language resources exact title: データベース・コーパス・資料 / BCCWJ2 org: 国立国語研究所 canonical URL: https://www.ninjal.ac.jp/resources/ ; https://clrd.ninjal.ac.jp/ publication/update/access: BCCWJ2 partial release 2026-03-24 / accessed 2026-09-16 version: BCCWJ2 staged release; completion planned through FY2028 supporting locator: 書籍・雑誌・新聞・白書・Web・法律等、BCCWJ2公開案内 evidence label: VERIFIED_SPEC + RESEARCH relation: support / evaluation-context established: 日本語の書き言葉・話し言葉を評価/研究するための専門コーパス群が存在する。敬語・文体・語彙の妥当性は、LLMの自己申告だけでなくcorpus/専門レビューへ接続可能。
FINDINGS
  • JAPAN_LOCALIZATION_CONTRACTをCore候補とする。最低フィールドは task、document/data type、script/layout、normalization target、authoritative reference、model/OCR version、locale/calendar、input provenance、raw output、normalized output、validation result、human correction、final artifact。
  • 日本語能力は少なくとも (A) generation/style、(B) OCR/layout、(C) character interoperability、(D) address normalization、(E) name matching、(F) date/calendar、(G) structured form extraction に分ける。
  • 住所・郵便番号・氏名等は、LLMがもっともらしい正規形を生成するだけでは確定しない。ABR、日本郵便、文字情報基盤等のauthoritative/reference sourceとの照合結果とsource versionを残す。
  • 日本語OCRは縦書き、複数段、漢字、混在script、手書き、receipt/table/layoutをfixture別に測る。単一CER/WERまたは英語中心benchmarkから日本語帳票性能を推定しない。
  • 敬語はgrammar correctnessだけでなく、相手/役割/場面/組織規約に依存するpragmatic appropriatenessであり、自動評価だけで閉じず代表業務fixtureとhuman reviewを置く。
  • 和暦は表示形式と内部canonical dateを分離する。生成テキストの「令和N年」を業務システムへ直接commitせず、calendar conversionとrange validationを deterministic layerで行う。
LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
  • 日本語で自然に会話できるmodelでも、縦書きOCR、外字、人名突合、住所正規化、和暦変換の正確性は別能力である。
  • authoritative dataにもcoverage/更新時点/粒度の限界がある。ABR町字正式版の存在は、全住居番号・地番が完全整備済みという意味ではない。
  • 郵便番号は住所identityそのものではない。郵便番号から得られる町域情報を個別建物・人物住所の確定へ外挿しない。
  • 氏名突合サービスの公称精度はその初期評価fixtureに対する値であり、特定tenantの名簿、外国人名、旧字/異体字、OCR誤り混入条件へ一般化しない。
  • JaWildTextはresearch benchmarkであり、特定commercial model/serviceのSLAではない。
  • NDLOCR-Liteが日本語資料向け実装として存在することは、あらゆる現代帳票・手書き・写真に最適という保証ではない。
  • 敬語/文体の「正しさ」は一意でない。文化庁等の一般指針やcorpus頻度を、組織固有の文書規程・顧客関係へそのまま置換しない。
AVAILABILITY_GATES

ABR: 公開データの整備粒度・更新日・対象地域/住所階層。 日本郵便API: current API仕様・利用条件・rate/availability・返却粒度。 氏名突合: 国内利用前提、一部機能の国外IP制限、current model/threshold。 OCR: OS/hardware、model/release、文書種、縦横/手書き、入力画質。 Language resources: corpus license/access、genre/time coverage。

IMPLEMENTATION_STATE

住所、郵便、文字、人名、OCR、corpusの各基盤は実在し、Japan-specific evaluation/normalization layerを構成可能。統合contract自体はPROPOSAL。生成LLM単独でなく deterministic parser + authoritative lookup + OCR/VLM + rule validation + human review のcomposite architectureを推奨候補とする。

BENCHMARK_OR_EVAL

後続TEST_PROFILE: ①縦書き/横書き/二段組、②請求書・領収書・申請書、③漢字/ひらがな/カタカナ/Latin/数字混在、④旧字/異体字/外字、⑤住所の全半角・丁目/番/号・漢数字/算用数字・ハイフン揺れ、⑥同姓同名/読み揺れ/外国人名、⑦西暦/和暦/元年/境界日、⑧敬語・役職・社外/社内文書をfixture化する。metricはCER、field exact match、structure fidelity、address normalization exactness、name false-match/false-nonmatch、date conversion exactness、human correction rate、critical-field errorを分離する。

SECURITY / PRIVACY / AUDIT / COST / OPERABILITY

Privacy: 氏名・住所・帳票はPIIを含み得るため、benchmark/evalにはsyntheticまたは適法に利用可能なfixtureを優先し、raw artifact retentionを制限。 Audit: raw→OCR→normalization→reference lookup→human correction→finalの変換履歴とreference versionを保持。 Cost: 高価なVLMを全ページへ使う前にlayout/OCR/field routingを行い、低confidence/critical fieldだけ上位modelまたはhumanへ送る比較を行う。 Operability: 日本語特有failureを「modelが日本語対応か」の一列で管理せず、data type別SLOへ分解する。

SAFE_WORDING_FOR_FUTURE_BOOK

「日本語を生成できることと、日本の業務データを正確に処理できることは別である。住所の表記揺れ、人名の異体字、縦書きや帳票レイアウト、和暦、敬語などは独立した失敗条件を持つ。重要項目は生成モデルのもっともらしさだけで確定せず、公的・業務上の参照データ、決定的な変換規則、文書種別ごとの評価、人による訂正を組み合わせる。」

UPDATE_WORK_HANDOFF
  • 公開後WorkではJAPAN_LOCALIZATION_CONTRACTをEA-004非LLM AI、EA-011 benchmark、EA-016 eval、EA-099 accessibilityへcross-referenceする。
  • ABRの町字以降(街区符号・住居番号・地番)の2026年以降整備状況を再pinする。
  • 日本郵便APIのcurrent schema/version/rate/terms、氏名突合支援のcurrent model/version/availabilityを再確認する。
  • NDLOCR-Lite repoのexact release/tag/commitとlicense、NDLOCR系の現行benchmark/対応layoutを採集する。
  • JaWildTextの正式公開dataset/eval code revisionをpinし、commercial/current modelsを同一fixtureで再測定する。
  • 和暦について、政府/標準のcanonical conversion sourceと元号境界fixtureを追加する。
  • 敬語・社内外文体はNINJAL corpusだけで閉じず、文化庁等の一次指針と実組織style guideを分離してfixture化する。
OPEN_UNKNOWN

/ STOP_CONDITION

OPEN_UNKNOWN

current ABRの番地以下coverage、郵便API current quota/terms、氏名突合current model revision、NDLOCR-Lite exact tag/commit、commercial OCR/VLMの日本語帳票比較、和暦の採用canonical library/source、敬語の業務別acceptance threshold。

STOP_CONDITION

上記のcurrent revisionを再pinし、住所/氏名/和暦/帳票/OCR/敬語fixtureでcritical-field errorとhuman correction率を実測し、各workflowの許容thresholdを定義した時点で更新判断可能。

要点と前提

---

AUDITED_CURRENTNESS_BOUNDARY

Japanese AI support is decomposed across authoritative address/postal/character/name/date/OCR/language controls; product/API/model details stay version-pinned/PRODUCT_VOLATILE.

  • EVD-EA-100-URL-DC2CE94810C9研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: デジタル庁

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-DC2CE94810C9
    検証箇所
    EVIDENCE TABLE · canonical URL: https://www.digital.go.jp/policies/base_registry_address
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-C9E708A9E709研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: デジタル庁

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-C9E708A9E709
    検証箇所
    EVIDENCE TABLE · canonical URL: https://digital-agency-news.digital.go.jp/articles/2025-10-31-0
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-BD9C6E420EC0研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: 日本郵便

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-BD9C6E420EC0
    検証箇所
    EVIDENCE TABLE · canonical URL: https://www.post.japanpost.jp/service/search/zipcode/download/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-C12DD53DE90E研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    canonical URL: https://www.post.japanpost.jp/service/search/zipcode/download/ ;

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-C12DD53DE90E
    検証箇所
    EVIDENCE TABLE · canonical URL: https://www.post.japanpost.jp/service/search/zipcode/download/ ; https://lp-api.da.pf.japanpost.jp/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-778F2C11A8F1研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: IPA / IMI

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-778F2C11A8F1
    検証箇所
    EVIDENCE TABLE · canonical URL: https://imi.ipa.go.jp/mj/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-AAE28AE8D329研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: デジタル庁

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-AAE28AE8D329
    検証箇所
    EVIDENCE TABLE · canonical URL: https://developers.digital.go.jp/documents/name-matching-support/faq/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-C060D8ED54C8研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org/author: 国立国会図書館 次世代システム開発研究室 / 青池亨

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-C060D8ED54C8
    検証箇所
    EVIDENCE TABLE · canonical URL: https://current.ndl.go.jp/e2891
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-1624DF90B395研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    authors: Koki Maeda, Naoaki Okazaki

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-1624DF90B395
    検証箇所
    EVIDENCE TABLE · canonical URL: https://arxiv.org/abs/2603.27942
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-915F1144A657研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    org: 国立国語研究所

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-915F1144A657
    検証箇所
    EVIDENCE TABLE · canonical URL: https://www.ninjal.ac.jp/resources/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EVD-EA-100-URL-2909338D516D研究資料研究資料根拠の出所: SOURCE_PACKET_REFERENCE

    canonical URL: https://www.ninjal.ac.jp/resources/ ;

    裏付ける内容
    —
    確認日
    —
    出典・実験ID
    SRC-EA-100-URL-2909338D516D
    検証箇所
    EVIDENCE TABLE · canonical URL: https://www.ninjal.ac.jp/resources/ ; https://clrd.ninjal.ac.jp/
    適用範囲
    EVIDENCE TABLE
    出典・来歴
    SOURCE_PACKET_REFERENCE_PROJECTED
    限界
    元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。
  • EA-100-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET

    EA-100 監査済みresearch / canonical revision binding

    裏付ける内容
    1. JAPAN_LOCALIZATION_CONTRACTをCore候補とする。最低フィールドは task、document/data type、script/layout、normalization target、authoritative reference、model/OCR version、locale/calendar、input provenance、raw output、normalized output、validation result、human correction、final artifact。 2. 日本語能力は少なくとも (A) generation/style、(B) OCR/layout、(C) character interoperability、(D) address normalization、(E) name matching、(F) date/calendar、(G) structured form extraction に分ける。 3. 住所・郵便番号・氏名等は、LLMがもっともらしい正規形を生成するだけでは確定しない。ABR、日本郵便、文字情報基盤等のauthoritative/reference sourceとの照合結果とsource versionを残す。 4. 日本語OCRは縦書き、複数段、漢字、混在script、手書き、receipt/table/layoutをfixture別に測る。単一CER/WERまたは英語中心benchmarkから日本語帳票性能を推定しない。 5. 敬語はgrammar correctnessだけでなく、相手/役割/場面/組織規約に依存するpragmatic appropriatenessであり、自動評価だけで閉じず代表業務fixtureとhuman reviewを置く。 6. 和暦は表示形式と内部canonical dateを分離する。生成テキストの「令和N年」を業務システムへ直接commitせず、calendar conversionとrange validationを deterministic layerで行う。
    確認日
    —
    出典・実験ID
    COMM-093-EA0100
    検証箇所
    COMM-093-EA0100 · EA-100-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-100.md
    適用範囲
    監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
    出典・来歴
    AUDIT_PASS_CANONICAL_BINDING
    限界
    canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
  • EA-100-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK

    EA-100 Web body identity / canonical readback

    裏付ける内容
    canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
    確認日
    —
    出典・実験ID
    WEBBODY-EA0100-R8-C731603F
    検証箇所
    WEBBODY-EA0100-R8-C731603F · content/staging/EA-100.md · EA-100-R5-LEGACY-MIGRATION-20261008-R1
    適用範囲
    R9/R10 canonical readback後のProduction生成時body identity。
    出典・来歴
    CANONICAL_READBACK_BODY_HASH_MATCH
    限界
    body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
出典ID
COMM-093-EA0100, SRC-EA-100-URL-DC2CE94810C9, SRC-EA-100-URL-C9E708A9E709, SRC-EA-100-URL-BD9C6E420EC0, SRC-EA-100-URL-C12DD53DE90E, SRC-EA-100-URL-778F2C11A8F1, SRC-EA-100-URL-AAE28AE8D329, SRC-EA-100-URL-C060D8ED54C8, SRC-EA-100-URL-1624DF90B395, SRC-EA-100-URL-915F1144A657, SRC-EA-100-URL-2909338D516D, WEBBODY-EA0100-R8-C731603F
追跡中のUNKNOWN ID
EA-100-UNKNOWN-01, EA-100-UNKNOWN-02, EA-100-UNKNOWN-CURRENTNESS
再確認のきっかけ
正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合

機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。

    同じ記事IDの機械可読データです。