本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

酉蓮社（旧増上寺報恩蔵）所蔵の嘉興版大蔵経に含まれる『大般若波羅蜜多經』巻571〜575（酉蓮社（旧増上寺報恩蔵）蔵嘉興版大蔵経目録データベースから、東洋文庫の研究プロジェクト基盤のIIIFサーバー経由で105画像として配信されている資料群）に対して、2つのOCRエンジン

を並べて適用し、出力テキストに現れた誤りの傾向を観測しました。

本記事の比較は、Cloud Vision APIがNDL古典籍OCRに対して優位に働く場面があるとご教示いただいたことを契機に着手しました。本資料についても同じ傾向が手元で確認できるかを確かめるべく105画像分の出力を並べて集計してみたところ、指標によってはVisionの方が参照テキストに近い結果が得られた一方で、別の観点ではNDLが優位な箇所もあり、両者には性質の異なる得手・不得手があることが見えてきました。

TL;DR

  • 本資料では、両OCRに同程度の本文が抽出された（NDL 39,768文字、Vision 38,740文字 / ノイズ除去後）。
  • NDL古典籍OCR-Lite は、画像にない文字列を生成する誤りを105画像中12画像で検出した。代表的なのは「いの」「あま」「一月にて琉球人の神香物語り…」のような、漢文版本に出現するはずのない仮名混じり行。
  • Cloud Vision API は、IIIF配信画像に同梱されたカラースケール／センチメートル定規／所蔵ラベル／朱印などを本文と同列に拾い、105画像全てでこの種のノイズが混入した。
  • 字形については、本記事で利用したNDL側XMLは校正用の字形置換リストが適用済みのデータで、康熙字典体（爲・曰・淸 等）に統一されている。Vision出力は新字体・中文簡化字寄り（為・日・清 等）に倒れる傾向だが、両者の差はNDL OCR素の挙動の比較ではなく後処理を含めた状態の比較になっている（観測3に注記）。
  • 巻末の音釋（音義注、難字に小字双行で音と意味を併記する漢籍の慣習）など複雑な多段組レイアウトの抽出量は、NDLが優位（同一画像でNDL 102行、Vision 49行）。
  • 参照テキストとの文字集合一致度（Jaccard）は、ノイズ除去後でVisionがやや高い（0.704 対 0.674）。

対象資料

酉蓮社（旧増上寺報恩蔵）所蔵の嘉興版大蔵経のうち『大般若波羅蜜多經』巻571〜575を対象としました。詳しい書誌は酉蓮社（旧増上寺報恩蔵）蔵嘉興版大蔵経目録データベースを参照してください。同データベースおよび本記事で利用したIIIF配信は、JSPS科研費 18K00073／21H04345／25H00464 による研究成果として公開されているものです。

  • IIIFマニフェスト: https://u-renja.toyobunko-lab.jp/api/iiif/2/015-03/manifest
  • canvas（画像）数: 105
  • 各canvas画像サイズ: 10328×7760 px（オリジナル）
  • 内容: 楷書整版による刊本。表紙、外題、各巻の経題・本文、巻末の音釋（音義注）、刊記・蔵書印などを含む。

各画像はIIIF Image API level 2準拠で、/full/{w},/0/default.jpg のサイズ指定で任意幅のJPEGを取得できます。

表紙画像（canvas 1）— 帙の外題と書き入れ「十五函之三」

表紙には、書き入れの墨書「十五函之三」と、書名・巻範囲を記した題簽（紙片）が見えます。

巻頭画像（canvas 2）— 経題・訳者・品題・朱印「增上寺報恩藏」と所蔵ラベル「酉蓮社所蔵」

巻頭ページには、経題・訳者表記・品題のほか、朱印「增上寺報恩藏」（旧蔵を示す印）、画像下部の所蔵ラベル「酉蓮社所蔵」、画像右上の色票・センチメートル定規などが一緒に写り込んでいます。

検証手順

NDL側の結果は既存の TEI/XML（015-03.xml）として渡されていたものを使用しました。このXMLは、NDL古典籍OCR-Lite（非ラテン文字主体の古典籍向けに学習されたモデル）が出力した行検出（<lb> 要素と <facsimile> 内の <zone> 座標）に対し、データ提供元の側で校正作業の中で人手で構造情報や字形補正を加えたものです。<lb> に付いている type="cover"（書き入れ）/"line"/"fascicle"/"chapter" といった属性、および前述の康熙字典体への字形統一は、いずれも校正者が割り振った／適用したもので、NDL古典籍OCR-Liteが自動付与しているものではない点にご注意ください。

Vision API側は、IIIFから取得した画像を DOCUMENT_TEXT_DETECTION に投げて fullTextAnnotation.text を取得しました。105画像であれば月1,000ユニットの無料枠内に収まります。

呼び出しの最小例（Pythonの urllib だけで完結する形）：

import base64, json, subprocess, urllib.request

token = subprocess.check_output(["gcloud", "auth", "print-access-token"], text=True).strip()
img_b64 = base64.b64encode(open("canvas_002.jpg", "rb").read()).decode()
body = {
    "requests": [{
        "image": {"content": img_b64},
        "features": [{"type": "DOCUMENT_TEXT_DETECTION"}],
        "imageContext": {"languageHints": ["ja", "zh"]},
    }]
}
req = urllib.request.Request(
    "https://vision.googleapis.com/v1/images:annotate",
    data=json.dumps(body).encode(),
    headers={
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json; charset=utf-8",
        "x-goog-user-project": "your-project-id",
    },
)
with urllib.request.urlopen(req, timeout=120) as r:
    result = json.loads(r.read())
print(result["responses"][0]["fullTextAnnotation"]["text"])

languageHints に ja と zh を両方与えています。漢文版本では中文寄りのコンテキストも有効です。

画像は /full/2048,/0/default.jpg で取得し、JPEGの圧縮込みで概ね2〜3MB／枚に収まりました（Vision APIは1リクエスト20MBが上限）。

観測1: NDLの仮名混入

NDLが出力した本文には、漢文版本のページに本来出現するはずのない平仮名・片仮名混じりの行が散見されました。105画像中12画像（11.4%）で発生しています。

代表的な例：

canvas 2  : 一月にて琉球人の神香物語り十一日本宅の宅の國の國の國の
canvas 2  : 七月廿一日の大地震動するにてもありて伊外にて
canvas 2  : 「アウスル」「アースルヤード」「ペロー
canvas 7  : い………………………………一切のふいのマのの
canvas 10 : いの
canvas 13 : めの…一心のやいのマのめ三ッ心のあいのマロの
canvas 30 : 一日にてそのありて其國
canvas 43 : あま
canvas 43 : 犂やし
canvas 64 : 身に
canvas 85 : あま

実際の画像（canvas 2）には、こうした仮名混じりの文字列はどこにも書かれていません。経題と本文、所蔵印、所蔵ラベルがあるだけです。

NDL古典籍OCR-LiteのTEI XMLには <facsimile> セクションに各行の認識領域（zone）の座標が含まれているので、それを画像に重ねてみると、何が起きているのかが直接見えます：

canvas 2にNDLの認識zone矩形を重ねた図。本来文字のない左頁の白紙領域にも縦長の矩形が9本検出されており、これらが先述の仮名混じり「行」の出所

右頁の本文・経題には妥当な矩形が引かれていますが、画像左頁の白紙領域（実際には印刷の罫線らしき淡い縦線が透けて見える程度）にも、本文の行と同じスタイルで縦長の矩形が9本引かれています。NDL側はこれらの矩形に対して文字認識を試み、結果として「一月にて琉球人の神香物語り…」のような仮名混じりの文字列を生成しているようです。XML上は校正者の手で <lb type="line"> の構造ラベルが割り振られており、本文行との区別はつかない状態になっています（前述の通り、type="line" 等のラベル自体はNDL OCRではなく人手で付与されたものです）。

一方、同じ画像をVision APIに通した場合、これらの仮名混じり「行」は一切出力されませんでした。

観測2: Visionのスケール／所蔵ラベル混入

逆に、Vision APIが拾ってNDLが拾わなかったものとして、IIIFの撮影画像に映り込んでいるカラースケール／センチメートル定規／所蔵ラベル／朱印があります。これは105画像全てで発生しています。

canvas 2 のVision出力（fullTextAnnotation.text 抜粋）：

5 6 7 8 9 170 1 2 3 4 5 6 7 8 9 180 1 2 3 4 5 6 7 8 9 190 1 2 3 4 5
大般若波羅蜜多經卷第五百七十一
唐三藏法師玄奘奉詔譯
第六分無所得品第九
爾時會中有菩薩摩訶薩名為善思問最勝日佛授
天王菩提記耶最勝答日我雖受記而猶鼻等爾時
...
西蓮社所蔵

冒頭の 5 6 7 8 9 170 1 2 3 4 5... は、画像右側に写り込んでいるセンチメートル定規の数字です。末尾の 西蓮社所蔵 は画像左下のラベル文字列です。Vision APIはこれらを本文行と区別せず、同じ text フィールドに連結して返します。

なお、ラベルの正しい読みは 「酉蓮社所蔵」（酉、ゆう）で、Vision APIは1文字目を 西 と誤認しています。酉 と 西 は字形が極めて近く（中央の縦画と横画の有無の差しかない）、汎用OCRでは混同されがちな組み合わせです。NDL古典籍OCR-Liteは今回の検証では所蔵ラベル領域そのものを抽出対象としなかったため、この字種誤読は発生していません。

矩形を描き出すと、これらが本文と同じ単語レベル矩形として検出されていることが直接確認できます：

canvas 2：Vision API の word 単位矩形。経本文の各漢字に加え、画像右の定規目盛り（数字列）、画像左下のラベル「酉蓮社所蔵」、中央の朱印「增上寺報恩藏」が同等の矩形として検出されている

集計：

  • ノイズに分類された総文字数: 約7,560文字
  • ノイズ混入頁数: 105 / 105

下流処理側で、行の位置（boundingPoly）や数字割合などを使ったポストフィルタが必要です。本記事の集計でもJaccard算出時には簡易な正規表現でノイズ除去を行っています。

観測3: 字形の保存

注記: 本記事で利用したNDL側のXMLは、データ提供元から校正作業のために字形の正規化（置換リスト）が一括適用された後の状態でいただいたものです。したがって本節で見ている「NDLが康熙字典体を保ち、Visionが新字体に倒れる」という差異は、NDL古典籍OCR-Liteの素の出力挙動の比較ではなく、後処理込みの最終データの状態と Vision API 出力の比較になっています。NDL OCR そのものの字形挙動を評価するには、置換適用前のRAW出力との照合が必要です（その素の挙動の評価は本記事の射程外です）。

本資料は康熙字典体に近い字形で組まれています。同一文字列がどう転記されているかを比較すると、両者に次のような状態の差が見られます。

漢字（経文）NDL XML（置換適用後）Cloud Vision API
爲 / 為爲（康熙）為（新字体）
曰 / 日曰日
淸 / 清淸（旧字体）清（新字体）
黑 / 黒黑黒

例えばcanvas 2の本文冒頭：

NDL    : 爾時會中有菩薩摩訶薩名爲善思問最勝曰佛授
Vision : 爾時會中有菩薩摩訶薩名為善思問最勝日佛授

Vision APIには中文簡化字データの強い影響もあるようで、日 への置換は文脈上明らかに 曰 であるべき場面でも一貫して発生していました。

漢籍の翻刻を扱う場面では、字形そのものが資料情報の一部です。新字体に倒れた出力をそのままTEIや翻刻データに入れるには、後段で字形変換テーブル（為→爲 等）の適用が必要になります。本記事のNDL側XMLが既に置換済みなのは、まさにこの種の後処理を済ませた状態のものです（NDL OCR素の出力をそのまま使えば、爲 を 為 と認識する／しないは別の評価対象になります）。

逆に、本文を「現代日本語の通読」用に渡す場面では、新字体のVision出力の方が読みやすいとも言えます。用途次第です。

観測4: 複雑なレイアウト（音釋・割書）の扱い

各巻末には音釋（音義注）があり、難字を1字大きく掲げ、その下に音と意味を**双行小字（割書）**で併記する漢籍の慣習的構造を取ります。多段の不規則グリッドに小字が配置される、OCR的に最も難しいレイアウトの一つです。

canvas 64：左頁が音釋、右頁が経題・本文。左頁の細密な多段組と、その左端の刊記縦書き列が同時に存在

このcanvas 64に対する出力行数：

  • NDL: 102行
  • Vision: 49行

NDLの認識矩形

NDL古典籍OCR-LiteのTEI XMLには <facsimile> セクションに各行の認識zone（ulx,uly,lrx,lry）が含まれます。canvas 64に重ねると：

canvas 64にNDLの認識zone矩形を重ねた図。右頁の本文は縦書きの列単位で矩形化され、左頁の音釋は大字の見出しとその下の小字双行（割書）の塊単位で矩形化されている

NDLは本文行は縦の列単位、音釋部分は大字見出し＋小字双行注の単位で矩形を引いています。割書をひと纏まりとして扱っている点がVision（後述）と対照的です。

Vision APIの認識矩形

Vision API の fullTextAnnotation は、ページ → ブロック → 段落 → 単語 → 記号 の階層構造を持ち、各レベルに boundingBox.vertices が付きます。これを画像に重ね描きすると、Vision がページをどのように区切っているかが目で見えるかたちで確認できます。

ブロック（赤）と段落（橙）の単位での切り出し：

canvas 64：Vision API のblock（赤）／paragraph（橙）矩形。右頁の本文は1〜2ブロックに、左頁の音釋は多数の小ブロックに分かれている

右頁の経本文は綺麗に大きな1ブロックとして取れているのに対し、左頁の音釋は小字の多段配置のため、Vision側はブロックを細かく分け、左端の縦書き刊記もそれ自体を1ブロックとして検出しています。

単語単位の矩形（青）まで描くと、割書の小字一つ一つが拾われていることが分かります：

canvas 64：Vision API の word 単位矩形。各漢字が個別に検出されているのが見える

割書部分の拡大：

canvas 64の音釋部分拡大。大字の見出し漢字（點・眼・緻・烏・婉・凹 等）と、その下に並ぶ双行小字（割書）が、Vision側で別々の word 矩形として検出されている

矩形そのものは妥当に置かれていますが、それを fullTextAnnotation.text に展開する際の読み順で問題が出ます。Vision は割書の小字を「大字の見出しと水平に並ぶ別の文字列」とみなして横方向に連結することがあり、出力テキストが見出し字／割書／別行を行きつ戻りつする形になります。

NDL（音釋部分の冒頭、抜粋）:
  音釋
  檢底
  轎音福
  醫倫
  四十
  車車
  佛足下如檢底之平也卑踐也
  輪輪輪
  輪中木之直
  轎音岡車鯛也穀
  ...

Vision（同じ部分、抜粋）:
  音大莫
  若义
  健
  羅人
  蜜 非
  多 人
  經等
  ...

矩形の検出は良くても、その後の「行の組み立て」が割書のような縦書き多段組では崩れる、というのが今回の観測です。NDL側も漢字認識自体に誤読はあるものの、レイアウトは保てているため、人手校正の出発点としては作業しやすい形になっています。Vision側は音釋ページでは矩形情報を直接使い、自前で割書の読み順を組み直す処理を入れる方が現実的そうです。

観測5: 仮名以外の本文誤り

NDLの仮名幻覚を除いた経文部分でも、両OCRには誤りがあります。同じ canvas 2 の本文行：

出力
参照（漢文として正しい字形）爾時會中有菩薩摩訶薩名爲善思問最勝曰佛授
NDL爾時會中有菩薩摩訶薩名爲善思問最勝曰佛授
Vision爾時會中有菩薩摩訶薩名為善思問最勝日佛授
出力
参照天王菩提記耶最勝答曰我雖受記而猶夢等爾時
NDL天王菩提記耶最勝答曰我雖受記而猶夢等爾時
Vision天王菩提記耶最勝答日我雖受記而猶鼻等爾時

夢 → 鼻 のような形態的に近い文字の誤読は、両OCRに共通して見られますが、Vision側にやや多い印象でした。

ただし経題そのもの（タイトル行）の取りこぼしは逆方向で、

NDL    : 大般若波羅蜜多經卷第五百七十   ← 末尾の「一」を欠落
Vision : 大般若波羅蜜多經卷第五百七十一 ← 完全に取得

のように、Visionの方が長い1行として完整に抽出するケースもありました。レイアウト解析と文字認識の優劣は、画像位置・行配置の影響を強く受けます。

集計

105画像分を通したざっくりした集計結果です。

指標NDL古典籍OCR-LiteCloud Vision API
抽出総文字数39,76838,740（ノイズ除去後）
仮名・片仮名混入頁数（漢文版本に対する誤検出）12 / 105（11.4%）0 / 105
計測スケール／所蔵ラベル混入頁数0 / 105105 / 105
ノイズ文字総数—約 7,560
参照テキストに対する文字集合一致率（Jaccard、ノイズ除去後）0.6740.704

「参照テキスト」には SAT 大正新脩大藏經テキストデータベース（本文部分のみ）を別途用意していただいたものを利用しました。SATの本文には音釋・刊記・蔵書ラベル等が含まれないため、これらを含むNDL／Visionの出力との比較は本文部分に限定された対称になっていません（NDL／Vision側の方が「広い」入力範囲を見ている）。Jaccardは文字集合の一致率という粗い指標であることもあり、本表の数値は厳密な精度比較というより両OCRの傾向を相対的に並べる目安として読んでください。

留保

  • 今回の対象は刊本であり、写本・崩し字・くずし字・変体仮名を主対象にした場合の傾向はおそらく異なります。NDL古典籍OCR-Liteはそれらを含む古典籍を主眼に学習されているため、写本素材ではより優位になる可能性が高いです。
  • Vision API の DOCUMENT_TEXT_DETECTION は汎用OCRであり、languageHints の与え方やバージョン更新で挙動が変わります。本記事の数字は2026年4月時点での1サンプルです。
  • ノイズ除去の正規表現は、本記事内の集計用に最低限のものを当てたに過ぎません。実運用ではVision APIの返す boundingPoly を使った位置ベースのフィルタの方が頑健です。
  • 参照テキスト（SAT本文）には音釋・刊記・蔵書ラベル等が含まれていないため、Jaccardの絶対値は対称比較の数字ではありません。NDLとVisionの相対比較として読んでください。
  • 「NDLの幻覚」と書いた行は、本記事では「漢文版本ページに仮名混じり行が出ているもの」を機械的にカウントしました。NDL古典籍OCR-Liteは書き入れや変体仮名を意図的に拾う設計なので、書き入れが実在する別資料では同じ判定が誤検知になります。
  • 観測3に注記した通り、本記事のNDL側データは校正用の字形置換が適用済みのものです。字形保存に関する観察はNDL古典籍OCR-Lite素の挙動の比較ではなく、後処理込みの最終データとVision API出力の比較になっています。同様の理由で、後述の「実務上の所感」に並べた使い分け案のうち「字形を保ちたい場合はNDL」とある部分も、置換リスト等の後処理運用が前提です。

実務上の所感

105画像という小さな規模の観測ですが、本資料に対しては次のように使い分けるのが現実的だと感じました。

  • 音釋など複雑な多段組を拾いたい・本文の漢字字形を保ちたい（後者は後処理前提） → NDL古典籍OCR-Lite。ただし下流で「漢文版本に仮名が混ざる行」を弾くフィルタが必要で、字形保存については別途、置換リストや既知の校正辞書を当てる運用が前提となります。
  • 本文を新字体寄りに通読したい・誤りを後段でLLM等に補正させたい → Cloud Vision API。ただしカラースケール／所蔵ラベル等のノイズ除去が必要。
  • 両方使えるなら、両方の出力を行単位でアラインして突合する のが、片方の弱点を相互に補える経済的な構成。Vision APIには無料枠（DOCUMENT_TEXT_DETECTION で月1,000ユニット）があるので、「NDL本命＋Vision補助」のような構成は導入のハードルが低いです。

冒頭でご教示いただいた「Visionが優位に働く場面がある」というご指摘については、本資料でも全体の文字一致率（ノイズ除去後）でVisionの方が参照に僅差で近かったという形で確認できました。一方で、複雑レイアウト処理・ノイズ非混入といった観点ではNDL側が優位で、最終的には用途と素材で選ぶ／併用する、というのが今回の観測から言えるところです（字形保存についての見え方は、上述の通り後処理込みのデータ状態に依存しており、NDL OCR素の挙動の評価ではない点にご注意ください）。

ソース

資料側：

OCR・関連ツール：