ブラウザ完結型OCRアプリNDLOCR-Lite Webの概要と開発経緯

ブラウザ完結型OCRアプリNDLOCR-Lite Webの概要と開発経緯

NDLOCR-Lite Webは、国立国会図書館（NDL）が開発・公開したOCRソフトウェア「NDLOCR-Lite」をWebブラウザ上で動作するよう移植・再実装したツールです。インストール不要でブラウザさえあれば誰でも利用でき、しかも画像やOCR結果が外部サーバーに送信されないという特徴を持ちます。2026年2月末の公開直後から研究者・業務担当者・デジタルアーカイブ関係者を中心に広く注目を集めました。

国立国会図書館NDLラボが開発したNDLOCRシリーズ3世代の変遷

国立国会図書館のNDLラボは、令和3年度（2021年度）からOCR関連の研究開発を本格的に推進してきました。第1世代にあたる「NDLOCR」は、大量の図書・雑誌デジタル化画像からテキストを生成することを目的として開発され、GPUを必須とする高精度な処理が特徴でした。令和4年度にはNDLOCR ver.2が公開され、認識精度の向上と多様な資料形式への対応が図られています。

「NDLOCR-Lite」は、2026年2月24日に公開されました。GPUを必要とせず、一般的なノートPCや家庭用コンピューターでも動作する軽量版として設計されており、Windows・Mac・Linuxの各OS環境に対応するデスクトップアプリケーションが提供されています。さらに、NDLOCRが苦手としていた英文や手書き文字への対応が実験的に追加されたことも大きな変化です。そして同年2月26日、有志開発者によってWebブラウザ版「NDLOCR-Lite Web」が公開されたことで、インストールという障壁まで取り除かれました。この短期間での展開は、CC BY 4.0というオープンなライセンス体制があってこそ実現したものです。

NDLOCR-Lite WebがNDLOCR-Liteのデスクトップ版と異なる3つの点

デスクトップ版NDLOCR-LiteとWebアプリ版NDLOCR-Lite Webは、同じOCRモデル（DEIMv2・PARSeq）を使用しているため認識精度は基本的に同等です。しかし利用体験の観点では、次の3点が明確に異なります。

• インストール不要：デスクトップ版はZIPファイルを展開して実行ファイルを起動する手順が必要ですが、Web版はブラウザでURLにアクセスするだけで利用を開始できます。
• OS依存なし：デスクトップ版はWindows・Mac・Linuxそれぞれ専用のバイナリが必要ですが、Web版はブラウザが動作する環境であれば原則として利用可能です。
• PDF直接入力に対応：デスクトップ版は画像ファイル（JPG・PNG等）を入力として想定しており、PDFを直接投入するにはページごとに画像変換する手間が発生します。Web版はPDFをそのままドラッグ＆ドロップして処理できます。

一方で、Web版はスマートフォンやタブレットへの最適化がまだ十分ではなく、デバイスによってはモデルのセットアップ段階で処理が停止するケースも報告されています。

2026年2月公開から1週間でWebアプリ移植が実現した背景

NDLOCRシリーズがCC BY 4.0ライセンスのもとでソースコードごと公開されていることが、短期間での移植を可能にした最大の要因です。開発者は国立国会図書館の公式GitHubリポジトリからモデルファイルを取得し、ONNX Web Runtimeを活用してブラウザ内推論に対応させました。

もう一つの背景として、NDLラボがこれまで「NDL古典籍OCR-Lite」などを通じてOCR技術の知見を公開し続けてきたことがあります。東京大学史料編纂所の中村覚氏によるMac向け解説記事の公開や、有志によるCUDA対応フォークの開発など、NDLのオープンな研究姿勢が外部コミュニティの積極的な参加を促しています。NDLOCR-Lite Webの公開も、こうした協力関係の延長線上にあるものです。国立国会図書館の公式Xアカウントによる告知は公開から数日で1.1Mビューを超え、研究者・図書館員・デジタルアーカイブ関係者だけでなく一般ユーザーにも広く届いていることが確認できます。

CC BY 4.0ライセンスで公開されることの利用者への実質的メリット

CC BY 4.0（クリエイティブ・コモンズ 表示 4.0 国際）とは、著作者のクレジットを表示する条件のもとで、商用・非商用を問わず自由に複製・改変・再配布できるライセンスです。NDLOCR-Lite WebがCC BY 4.0のもとで公開されていることは、利用者にとって次のような実質的メリットをもたらします。

第一に、業務利用や商用利用において追加の許諾申請が不要です。社内文書のデジタル化や、スキャン資料からの検索システム構築などに活用しても問題ありません。第二に、自社システムへの組み込みや機能追加を伴う改変が許可されています。PDFバッチ処理対応やCUDA高速化のフォークが短期間で登場しているのもこのためです。第三に、改変版を社内外に配布する際も、元の著作者（国立国会図書館）のクレジットを明示すれば制限はありません。ただし、本アプリケーションが利用するライブラリ等については、それぞれ個別のライセンスが適用されるため、商用展開の際はLICENCE_DEPENDENCIESファイルの確認が必要です。

DEIMv2とPARSeqという2種モデルを組み合わせた設計思想の意図

NDLOCR-Lite Webの内部処理は「レイアウト認識」「文字列認識」「読み順整序」の3モジュールで構成されています。レイアウト認識にはDEIMv2モデルを採用しており、1024×1024ピクセルの画像入力からテキスト行の矩形領域を自動検出します。この段階で各行の文字数カテゴリ（小・中・大）が予測されます。

文字列認識にはPARSeq（Permutation Autoregressive Sequence）モデルを使用しており、行の文字数カテゴリに応じてPARSeq-30・PARSeq-50・PARSeq-100の3種類を使い分けるカスケード方式を採用しています。これにより、短い行と長い行でそれぞれ最適化されたモデルを割り当て、全体的な認識精度を高めています。この設計は、NDL古典籍OCR-Liteの開発経験を踏まえてNDLラボ職員が内製で構築したものであり、GPU不要という制約のもとでCPUおよびブラウザ内推論に適したアーキテクチャとして選択されています。

GPU不要・インストール不要を両立したNDLOCR-Lite Webの技術仕様

NDLOCR-Lite Webの最大の特徴は、高性能なGPUもアプリのインストールも不要である点です。通常、日本語OCRの高精度処理はGPUを使った並列計算を前提とするケースが多く、導入ハードルが高くなりがちです。NDLOCR-Lite WebはONNX Web Runtimeを活用してこの課題を克服しており、一般的なブラウザ環境でも実用的な速度でOCR処理を実行できます。

ONNX Web Runtimeを採用してブラウザ内処理を実現した仕組み

ONNX Web Runtimeとは、ONNX（Open Neural Network Exchange）形式で保存されたAIモデルをWebブラウザ上で直接実行するためのJavaScriptライブラリです。通常、AIモデルの推論処理はサーバー側で行うのが一般的ですが、ONNX Web Runtimeを使うことでモデルをブラウザにダウンロードしてローカルで推論を完結させることができます。

NDLOCR-Lite WebではこのONNX Web Runtimeを利用し、DEIMv2とPARSeq-30/50/100の計4つのONNXモデルをブラウザ内で実行しています。処理はWeb Workerを使って非同期で行われるため、UIが固まることなく認識処理が進みます。また、WebAssemblyによるCPU実行パスに対応しているため、WebGPUが利用できない環境でも動作します。サーバーへの通信は一切発生せず、選択した画像やPDFのデータも外部に送信されないため、機密性の高い資料のOCR処理にも安心して使用できます。

初回起動時に約146MBのモデルをダウンロードする理由とキャッシュ動作

NDLOCR-Lite Webを初めて開いた際には、ブラウザ内での推論に必要なONNXモデルファイルが自動的にダウンロードされます。その合計サイズは約146MBです。これはDEIMv2の物体検出モデル1ファイルと、PARSeqの文字認識モデル3ファイル（PARSeq-30・50・100）の合計に相当します。外部サーバーで推論を行うクラウド型OCRとは異なり、モデルをブラウザ内に持ち込んでローカル処理を実現するためにこのダウンロードが必要になります。

ダウンロードしたモデルはIndexedDB（ブラウザ内の永続的なストレージ）にキャッシュされるため、2回目以降のアクセスではダウンロードなしで即座に利用を開始できます。ただし、ブラウザのキャッシュをクリアした場合や別のブラウザプロファイルで開いた場合は再ダウンロードが発生します。回線速度にもよりますが、初回のセットアップには数十秒から数分程度の待ち時間が必要です。Wi-Fi環境での利用を推奨し、モバイル回線での初回起動は通信量の観点から注意が必要です。初回さえ完了してしまえば、次回以降は快適に使用できます。

DEIMv2によるレイアウト認識が1024×1024px単位で行領域を検出する仕組み

DEIMv2はDINOv3を活用したDEIMフレームワークベースの物体検出モデルで、画像内のテキスト行の矩形領域（バウンディングボックス）を自動的に検出します。NDLOCR-Lite Webでは画像を1024×1024ピクセルの解像度でモデルに入力し、各テキスト行の位置・範囲・文字数カテゴリを出力します。この入力解像度は、処理速度とレイアウト検出精度のバランスを考慮して設定されたものです。

文字数カテゴリの予測は「1行あたりの文字数が少ない・中程度・多い」という3段階の分類で行われ、後続のPARSeqモデル選択に使用されます。縦書き・横書きを問わずレイアウトを認識できる点がNDLOCR-Lite系の強みであり、段組レイアウトや複数カラムの資料でも行単位で正確に領域を切り出すことができます。ただし、極端に解像度が低い画像や、写り込みや影が多い写真では検出精度が落ちることがあるため、入力画像の品質が最終的な認識精度を左右します。適切な解像度（300dpi以上）でスキャンした画像を使用することが、精度を確保するうえで最も重要なポイントです。

文字数カテゴリに応じてPARSeq-30・50・100を使い分けるカスケード処理

PARSeq（Permutation Autoregressive Sequence）は、文字列認識に特化したシーケンス認識モデルです。NDLOCR-Lite WebではDEIMv2が予測した文字数カテゴリに基づき、3種類のPARSeqモデルを自動的に使い分けるカスケード方式を採用しています。

具体的には、1行の文字数が少ないと判定された行にはPARSeq-30、中程度の行にはPARSeq-50、文字数が多い行にはPARSeq-100が割り当てられます。各モデルは認識可能な最大文字長に最適化されており、短い行に大きなモデルを使うと無駄な計算が発生し、逆に長い行に小さなモデルを使うと末尾の文字が欠落するリスクがあります。カスケード方式によって処理速度と精度を同時に最適化しているのが、この設計の核心です。NDLラボの古典籍OCR開発で蓄積されたノウハウが活かされた実装となっており、GPU不要でも実用的な認識品質を維持できる理由のひとつとなっています。

対応ファイル形式JPG・PNG・PDFと各形式で想定される処理精度の差

NDLOCR-Lite Webが対応している入力ファイル形式はJPEG・PNG・PDFの3種類です。それぞれの形式で想定される処理品質には一定の差があります。

一般的に、解像度が高く鮮明な画像ほど認識精度は向上します。PDFの場合はページ数が多いほど処理時間も増加するため、大量ページの資料を扱う際はデスクトップ版またはバッチ処理対応のフォーク版の利用も検討してください。また、TIFFについてはWebアプリ版での対応状況が限定的なため、あらかじめJPEGまたはPNGに変換してから投入することをお勧めします。入力ファイルの品質と形式を事前に整えることが、OCR精度を安定させるための基本的な準備となります。

ドラッグ＆ドロップからテキスト出力までNDLOCR-Lite Webの操作手順

NDLOCR-Lite Webは、技術的な知識がなくてもすぐに使い始められるシンプルな操作性を備えています。URLにアクセスしてモデルのセットアップが完了すれば、あとは対象ファイルを読み込んでOCR処理を実行するだけです。このセクションでは、初回利用から結果出力までの流れを具体的に解説します。

初回セットアップ完了までに要する時間と環境別の待ち時間の目安

NDLOCR-Lite Webに初めてアクセスすると、OCR処理に必要なONNXモデル（合計約146MB）の自動ダウンロードが始まります。セットアップが完了するまでの時間は、利用環境によって異なります。

• 高速Wi-Fi環境（100Mbps以上）：ダウンロードは1〜2分程度で完了します。IndexedDBへのキャッシュ書き込みを含めても3分以内に操作を開始できます。
• 一般的なブロードバンド環境（30〜50Mbps）：3〜5分程度かかる場合があります。画面に進捗表示が出ている間はそのままお待ちください。
• モバイル回線・低速回線：10分以上かかるケースもあります。初回はWi-Fi環境での利用を強くお勧めします。

2回目以降のアクセスではIndexedDBに保存されたモデルが読み込まれるため、数秒でOCR処理を開始できます。ただし、ブラウザのキャッシュを全削除した場合や、プライベートウィンドウを使用した場合は再ダウンロードが発生するため注意してください。

画像・PDFファイルを読み込む3通りの入力方法と向き不向き

NDLOCR-Lite Webへのファイル入力は3つの方法に対応しています。作業の状況や手元のデータに応じて使い分けることで、操作効率を上げられます。

1. ドラッグ＆ドロップ：エクスプローラーやFinderから対象ファイルをブラウザ画面上にドラッグするだけで読み込めます。複数ファイルの連続処理には最も直感的な方法です。
2. クリックしてファイル選択：入力エリアをクリックするとファイル選択ダイアログが開きます。ファイルの保存場所が深い階層にある場合に操作しやすい方法です。
3. クリップボードから貼り付け（Ctrl＋V）：スクリーンショットや他アプリからコピーした画像をそのまま貼り付けることができます。ウェブブラウザ上の画像をすぐにテキスト化したい場合に便利です。

PDFの場合はドラッグ＆ドロップが最も効率的です。複数ページを含むPDFでもそのまま投入でき、ページ画像への変換は自動的に行われます。ただしページ数が多いPDFは処理に時間がかかるため、長大な文書は区切って処理することを検討してください。

OCR実行後に右欄へ表示されるテキストの確認・コピー・ダウンロード手順

ファイルを読み込んでOCR処理が完了すると、画面右欄にテキスト認識結果が表示されます。表示されたテキストは視覚的に確認しながら即座に活用できます。

テキストの取り出し方法は2通りあります。「コピー」ボタンをクリックするとクリップボードに全文がコピーされ、WordやExcelなどのアプリケーションに直接貼り付けることができます。「ダウンロード」ボタンをクリックすると、認識結果がテキストファイル（.txt）として保存されます。どちらの方法も追加の操作なしで完結します。PDFの複数ページを処理した場合は、全ページのテキストがページ順にまとめて出力されるため、後から結合する手間がかかりません。処理結果に誤りが含まれている場合は、テキストエディタや文書ソフトで手動修正してから利用してください。認識精度を高めるためには、出力テキストを原本画像と対照しながら確認する習慣を身につけることが重要です。特に固有名詞・数字・日付は優先的に確認するとよいでしょう。

複数ページPDFを一括処理した場合の出力形式とページ順序の扱い

NDLOCR-Lite Webに複数ページのPDFを投入すると、各ページが順次画像として展開されてOCR処理が行われます。処理完了後は全ページのテキストが読み込んだ順（ページ番号順）に連結された状態で右欄に表示されます。

この仕組みにより、デスクトップ版NDLOCR-Liteで発生していた「ページごとに別ファイルとして出力されるため、後で結合作業が必要」という手間が解消されています。ただし、ページ数が多いほど処理時間は増加します。目安として、10ページ前後のPDFであれば一般的なPCの処理能力で現実的な時間内に完了しますが、50ページを超える場合は相応の待ち時間を見込んでください。また、PDFがスキャン画像で構成されているのか、テキストレイヤーを持つデジタルPDFであるかによって処理品質が変わることはなく、NDLOCR-Lite WebはあくまでPDFを画像として扱いOCRを適用します。

認識結果に誤りが多いと感じたときに試すべき前処理3パターン

NDLOCR-Lite Webはあくまで機械的な推論であるため、入力画像の状態によっては誤認識が生じます。精度が低いと感じた場合、まず入力データ側の改善を試みることが効果的です。

• 解像度の向上：低解像度のスキャン画像は認識精度が著しく低下します。可能であれば300dpi以上でスキャンし直し、再度投入してください。
• 傾き補正と余白の除去：画像が傾いている場合や不要な余白が大きい場合は、画像編集ソフトで補正してから入力すると行検出の精度が上がります。
• コントラストの調整：薄い印刷や紙の変色により文字が背景に埋もれている場合は、画像をグレースケール化してコントラストを高めると文字輪郭が明瞭になります。

これらの前処理を施してもなお精度が改善しない場合は、資料の性質（手書き・特殊フォント・縦横混在など）がNDLOCR-Lite Webの現行モデルの対応範囲外である可能性があります。その場合は別のOCRサービスとの併用を検討するか、手動での文字起こしと組み合わせる方法が現実的です。

デスクトップ版NDLOCR-Liteおよび商用OCRサービスとの機能比較

NDLOCR-Lite Webを実際の業務や研究に使うにあたり、デスクトップ版との違いや商用OCRサービスとの比較を整理しておくことは重要です。ツール選択を誤ると作業効率の低下やプライバシーリスクにつながるため、各ツールの特性を正確に把握しておきましょう。

NDLOCR-Lite WebとNDLOCR-Liteデスクトップ版の機能差分一覧

NDLOCR-Lite Webとデスクトップ版は同じOCRモデルを搭載していますが、機能面や操作性において複数の差異があります。利用目的に応じた使い分けが必要です。

大量のファイルを一括処理したい場合や、特定エリアだけをOCR処理したい場合はデスクトップ版が適しています。一方で、インストールが難しい環境や、すぐに試してみたい場合はWeb版が最適な選択肢となります。

Google Document AI・Adobe AcrobatのOCRと無料・精度・プライバシーの三軸比較

NDLOCR-Lite Webを商用OCRサービスと比較するうえで重要な軸は、コスト・精度・データプライバシーの3点です。

プライバシー面では、NDLOCR-Lite Webがすべてローカル処理で完結する点が大きな優位性を持ちます。業務上の機密文書や個人情報を含む資料のOCR処理においては、外部サーバーへの送信が発生しないことが重要な要件となります。一方で、大量文書の自動処理やAPI連携が必要な用途では、商用サービスの方が適しています。

GPUありNDLOCRと比較したときの処理速度差と用途別選択基準

GPU必須の旧来版「NDLOCR」と、GPU不要の「NDLOCR-Lite（Web版含む）」を比較した場合、最も顕著な差は処理速度です。GPUを使ったNDLOCRは大量の並列計算を高速化できるため、数十〜数百ページの資料を短時間で処理する用途に適しています。

一方、NDLOCR-LiteはCPUのみで動作するように最適化されており、ノートPCでも実用的な速度で処理が可能です。Web版はさらにブラウザ内のWebAssembly経由で実行されるため、ネイティブ実行のデスクトップ版と比べて若干の速度低下があります。用途別の選択基準としては、1〜20ページ程度の日常的な文書処理にはNDLOCR-Lite Web、数十ページのまとまった資料にはデスクトップ版、数百ページ以上の大規模処理やAPI連携にはGPUありのNDLOCRが適しています。処理規模と環境に応じた適切な選択が作業効率を左右します。

縦書き・手書き・英文混在の資料で精度が落ちやすい条件の比較検証

NDLOCR-Lite Webは日本語の縦書き資料を主要ターゲットとして設計されており、縦書きレイアウトの認識は比較的安定しています。ただし、縦書きと横書きが混在する資料（例：雑誌・広告・古い学術書）ではレイアウト認識が複雑になり、誤検出が発生することがあります。

手書き文字への対応は「実験的」と位置づけられており、印刷文字と比較して精度は低くなります。特に個人差の大きい崩し字や草書体、鉛筆書きの薄い文字は誤認識が多くなる傾向があります。英文については、NDLOCRが苦手としていた分野への試行的対応としてNDLOCR-Liteから追加されており、基本的な英字活字であれば十分な精度が得られます。ただし英数字と日本語が混在する列（コード・型番・数式など）では誤認識が増える場合があります。これらの特性を踏まえ、資料の種類に応じてOCR後の確認工数を見積もっておくことが、実務において品質を安定させる鍵となります。

業務利用で優先すべきオフライン処理能力に関する3サービスの実態

業務においてOCRを活用する際、データの外部送信を避けたいというニーズは医療・法務・金融・官公庁など多くの分野で存在します。オフライン（ローカル）処理の観点から3つのアプローチを整理します。

• NDLOCR-Lite Web：ブラウザさえあればすべての処理がローカルで完結します。インターネット接続は初回のモデルダウンロード時のみ必要で、2回目以降はオフライン環境でも利用可能です。
• NDLOCR-Liteデスクトップ版：ダウンロード・インストール完了後はインターネット接続なしで動作します。社内ネットワーク限定の環境やインターネット遮断環境にも対応できます。
• Google Document AI・Adobe Acrobat：いずれも処理はクラウドサーバーで実行されるため、オフライン環境での利用はできません。社内規定や情報セキュリティポリシーによってはクラウドOCRの利用が制限される場合があります。

機密性の高い資料を扱う業務では、NDLOCR-Lite系のローカル処理ツールが最も安全な選択肢となります。

歴史資料・業務文書・手書きメモへのNDLOCR-Lite Web実務活用例

NDLOCR-Lite Webは単なる技術的なツールではなく、研究・業務・アーカイブといった実際の現場での活用が期待されています。ここでは代表的なユースケースを取り上げ、具体的な活用方法と注意点を解説します。

国立国会図書館デジタルコレクション画像をテキスト化する研究活用例

NDLOCR-Lite Webの開発元である国立国会図書館は、日本最大のデジタルアーカイブである「国立国会図書館デジタルコレクション」を運営しています。同コレクションには明治・大正・昭和の図書・雑誌・古地図などが大量にデジタル化されており、そのページ画像からテキストを抽出する際にNDLOCR-Lite Webは最適なツールです。

研究活用の具体的なシナリオとしては、まずデジタルコレクションのページ画像をスクリーンショットまたはダウンロードして保存します。次にNDLOCR-Lite WebにそのJPEGまたはPNGをドラッグ＆ドロップし、OCR処理を実行します。出力されたテキストを研究ノートや文書管理ソフトに貼り付けることで、キーワード検索や引用が可能なデジタルテキストとして活用できます。デジタルコレクション上でPDFとして提供されているコンテンツはそのままPDFを投入することも可能です。

古い社内稟議書・紙台帳のデジタル化業務でNDLOCR-Lite Webを使う手順

企業や自治体には、紙のまま保管されている古い稟議書・台帳・議事録が大量に存在します。これらをデジタルテキストに変換する作業に、NDLOCR-Lite Webを組み合わせると効率化が図れます。

1. スキャナーで紙資料を読み取り、300dpi以上のJPEGまたはPDFとして保存します。
2. NDLOCR-Lite Webをブラウザで開き、モデルのセットアップが完了するまで待ちます。
3. 保存したファイルをドラッグ＆ドロップしてOCR処理を実行します。
4. 右欄に表示されたテキストをコピーまたはダウンロードし、文書管理システムや検索データベースに登録します。
5. 機械認識の誤りを手動で確認・修正します。特に数字・固有名詞・金額は重点的に確認してください。

データが外部に送信されないローカル処理の特性から、個人情報や営業秘密を含む社内資料の処理にも安心して使用できます。ただし、大量の文書を日常的に処理する場合はデスクトップ版のフォルダ一括処理機能の方が効率的です。

手書きメモや英文書類の実験的対応機能を業務で活かすための前提条件

NDLOCR-Lite Webは手書き文字と英文に対して「実験的対応」として処理を試みます。この機能を業務で活用するにあたり、現時点での前提条件を正確に理解しておくことが重要です。

手書き処理の精度は、書体の整い具合と使用した筆記具に大きく依存します。楷書に近い整った手書き、ボールペンによる比較的明瞭な記述であれば一定の精度が期待できますが、走り書きや草書体、鉛筆の薄い書き込みでは誤認識が増加します。業務利用においては「完全なテキスト化」を期待するのではなく「大まかな内容の把握支援」として位置づけるのが現実的です。英文については、EIN通知書などのフォーマットが整った英語書類ではほぼ正確なテキスト化が報告されています。英字活字が主体の資料であれば実用レベルの精度が得られるケースが多いですが、いずれのケースでも認識結果の確認作業は省略せず行うことが前提条件となります。手書きや英文を含む資料では、確認にかかる時間を多めに見積もり、作業計画を立てることをお勧めします。

スキャンPDFが大量にある場合のバッチ処理代替手段と自動化の考え方

NDLOCR-Lite Web版はWeb UIでの1ファイルずつの処理を前提としており、100件・1000件のスキャンPDFを一括処理するバッチ機能は持っていません。大量ファイルを効率的に処理したい場合は、代替手段の活用が必要です。

最も手軽な代替手段は、デスクトップ版NDLOCR-Liteの「フォルダ内の画像を処理する」機能を使う方法です。フォルダにまとめた画像ファイルを一括投入し、ページごとにテキストファイルを出力できます。さらに高度な自動化が必要な場合は、コマンドラインからPythonで操作できる実行例がGitHubリポジトリに公開されており、python3 ocr.py --sourcedir 9892834_0001 --output tmpdirのようなコマンドでバッチ処理を実装できます。CUDAを活用した高速バッチ処理フォーク版も有志により公開されており、GPUを持つ環境では処理速度を大幅に向上させることが可能です。

テキスト抽出後の校正・検索・データベース登録までのワークフロー設計

OCRで抽出したテキストは、そのままでは実用に耐えないケースがほとんどです。誤字・脱字・文字化けが含まれるため、後工程の設計が重要になります。

標準的なワークフローとしては、まずNDLOCR-Lite WebでOCR結果を取得してテキストファイルとしてダウンロードします。次に、テキストエディタやWordで原本画像と対照しながら誤認識箇所を修正します。固有名詞・数値・日付は特に注意が必要です。修正済みテキストをデータベースや文書管理システムに登録すれば、全文検索やタグ付け・分類作業が可能になります。資料の性質上、完全な自動化は難しい場合が多いため、OCRを「入力補助ツール」として位置づけ、人間による最終確認を前提にしたワークフロー設計が現実的です。研究用途では、出力テキストを自然言語処理パイプラインへ投入し、形態素解析・共起分析・頻度集計などに活用する事例も増えています。大量の資料を継続的に処理する場合は、チェック済みフラグや担当者記録を管理台帳に設けると、作業品質を維持しやすくなります。

NDLOCR-Lite Webの現時点の制約事項と精度向上に向けた注意点

NDLOCR-Lite Webは公開直後のツールであり、現時点では対応が不十分な環境や条件が存在します。これらの制約を把握したうえで利用することで、無駄なトラブルを避け、ツールを正しく活用できます。

スマートフォン・タブレットで動作が不安定になる原因と現状の回避策

NDLOCR-Lite Webはデスクトップブラウザを想定して設計されており、スマートフォンやタブレットでの動作は現時点で最適化されていません。不安定になる主な原因は2つあります。

第一に、モバイルデバイスのメモリ制約です。NDLOCR-Lite WebはONNXモデルをブラウザ内に読み込むため、一定量のRAMが必要です。スマートフォンではバックグラウンドアプリの影響でメモリが不足しやすく、モデルのセットアップ段階で処理が停止するケースが報告されています（iPhoneでの停止が確認されています）。第二に、COOP/COEPヘッダーの扱いがブラウザによって異なる点です。一部のモバイルブラウザではこのヘッダーへの対応が不完全であり、SharedArrayBufferが利用できずONNX Web Runtimeが正常に動作しない場合があります。現状の回避策としては、デスクトップPCまたはノートPCで使用することが最も確実です。Pixel 10 Foldなど一部のAndroid端末ではデスクトップ版Chromeに近い動作が確認されていますが、安定性は保証されていません。

連続する数字・記号・ルビ付き文字で誤認識が起きやすい条件の整理

NDLOCR-Lite Webは日本語テキストの認識に特化しているため、特定の文字種や表現形式では誤認識が生じやすい傾向があります。事前に把握しておくことで確認作業の優先順位を設定できます。

• 連続する数字（電話番号・番地・統計値）：「0」（ゼロ）と「O」（英字）の混同、または「1」と「l」（小文字エル）の混同が頻繁に発生します。
• 記号・特殊文字：括弧・ダッシュ・波線・中黒など、フォントやスキャン品質によって認識結果が不安定になることがあります。
• ルビ（振り仮名）付きテキスト：本文とルビが別の行として検出され、テキストが混在して出力される場合があります。古い印刷物に多いルビ付き文章では特に注意が必要です。
• 縦書き中の横組みテキスト（数字・英字）：縦書き主体の資料に数字や英字が横書きで挿入されているケースでは、回転方向の判断が誤ることがあります。

これらの誤認識が多い箇所は、OCR結果と原本画像を対照確認する際に重点的にチェックすることが推奨されます。

機械的判断であることを前提とした確認作業の最低限チェックポイント

NDLラボ公式サイトには「機械的な判断結果のため、誤りを含みます」と明記されています。この前提に基づいた確認作業を省略してしまうと、誤った情報がそのまま業務や研究に使われるリスクが生じます。

最低限確認すべきチェックポイントは次の通りです。まず、固有名詞（人名・地名・組織名）の正確性を原本と照合します。次に、数値・日付・金額などの定量情報を目視で確認します。これらは誤りが発生した場合の影響が大きい項目です。さらに、文末の句読点や段落の区切りが正しく認識されているかを確認します。OCRは改行位置や段落境界を誤認識しやすく、これが文意のずれにつながることがあります。研究用途では、一次資料として引用する前に必ず原本との照合を行ってください。業務用途では、確認済み資料にスタンプ・フラグを立てる運用ルールを設けると、未確認テキストが誤って流用されるリスクを下げられます。確認作業の工数をあらかじめ計画に組み込むことが、品質を担保するうえで不可欠です。

メモリ不足により処理が止まるケースとブラウザ設定での対処方法

NDLOCR-Lite WebはONNXモデルをブラウザメモリ（RAM）に展開するため、空きメモリが少ない環境では処理が途中で止まる、または起動そのものが失敗するケースがあります。デスクトップ版NDLOCR-Liteの公式ドキュメントでも「PCのメモリに1GB以上の空きが必要」と明記されています。

対処方法としては、まず不要なブラウザタブをすべて閉じてメモリを解放することが最も効果的です。次に、動画再生アプリ・スプレッドシート・ビデオ会議ツールなどメモリを多く消費するアプリケーションを終了させてから再度起動してみてください。それでも改善しない場合は、ブラウザを一度完全に終了してから再起動する方法も有効です。Chromeの場合は、アドレスバーにchrome://settings/performanceと入力してメモリセーバー機能の設定を確認することも推奨されます。根本的にPCの搭載RAMが少ない場合（8GB未満）は、デスクトップ版との使い分けを検討するか、ブラウザ以外のアプリをすべて終了した状態で処理を試みてください。

COOP/COEPヘッダーが必要な技術的制約とfile://起動では動作しない理由

NDLOCR-Lite WebはSharedArrayBufferというブラウザAPIを内部的に使用しています。このAPIは並列処理に不可欠な機能ですが、セキュリティ上の理由からCross-Origin Opener Policy（COOP）およびCross-Origin Embedder Policy（COEP）の両ヘッダーが正しく設定されたWebサーバー環境でのみ有効になります。

このため、ダウンロードしたHTMLファイルをダブルクリックしてfile://プロトコルで開いた場合は動作しません。ローカルで試す場合は必ず開発サーバーを経由する必要があります。公開されているNetlifyホスティング版（https://ndlocr-liteweb.netlify.app/）はサーバー側でCOOP/COEPヘッダーが設定されているため、そのままブラウザでアクセスして使えます。自前でローカルビルドして試す場合は、npm run devで起動する開発サーバー（localhost:5173）を使うことで同様の環境が整います。この制約は現行ブラウザのセキュリティ仕様に基づくものであり、NDLOCR-Lite Web固有の問題ではありません。

CC BY 4.0ライセンス下でのNDLOCR-Lite Webローカル構築手順

NDLOCR-Lite WebはCC BY 4.0ライセンスで公開されており、GitHubのソースコードを元に自前でローカル環境またはサーバー環境に展開することができます。社内ネットワーク限定での運用や、カスタマイズを加えた自社ツールへの組み込みを検討している方に向けて、構築手順を解説します。

ローカルビルドに必要なNode.js環境とnpmパッケージのバージョン要件

NDLOCR-Lite WebはViteをビルドツールとして採用したReactベースのWebアプリケーションです。ローカルでビルドするにはNode.js環境が必要です。

動作確認されている環境は、Node.js 18以上（LTS版を推奨）およびnpm 9以上です。古いバージョンでは依存関係の解決に失敗する場合があるため、まずNode.jsの公式サイトから最新のLTS版をインストールすることをお勧めします。インストール済みのバージョンはnode -vおよびnpm -vコマンドで確認できます。必要なnpmパッケージはリポジトリ直下のpackage.jsonに定義されており、npm installコマンドで一括インストールされます。ONNXモデルファイル自体はnpmパッケージには含まれておらず、別途デスクトップ版NDLOCR-Liteのリポジトリから取得する必要があります。WindowsではNode.jsインストーラー版を、MacではHomebrewを使ったインストールが一般的です。いずれの環境でも、LTS版を選択することで安定した動作が期待できます。

ndlocr-liteリポジトリからONNXモデル4ファイルを取得して配置する手順

NDLOCR-Lite WebはDEIMv2モデル1ファイルとPARSeqモデル3ファイルの合計4つのONNXファイルを使用します。これらのモデルは国立国会図書館の公式GitHubリポジトリから取得します。

1. 国立国会図書館のGitHubリポジトリ（https://github.com/ndl-lab/ndlocr-lite）をクローンするか、リリースページからモデルファイルを含むアーカイブをダウンロードします。
2. 取得したモデルファイルを以下のコマンドでndlocrlite-webリポジトリのpublic/models/ディレクトリに配置します。

cp /path/to/ndlocr-lite/src/model/deim-s-1024x1024.onnx public/models/

cp /path/to/ndlocr-lite/src/model/parseq-ndl-16x256-30-*.onnx public/models/parseq-ndl-30.onnx

cp /path/to/ndlocr-lite/src/model/parseq-ndl-16x384-50-*.onnx public/models/parseq-ndl-50.onnx

cp /path/to/ndlocr-lite/src/model/parseq-ndl-16x768-100-*.onnx public/models/parseq-ndl-100.onnx

ファイル名のワイルドカード（*）部分にはバージョン番号が入ります。最新のリリースを使用してください。モデルファイルの配置が完了すれば、開発サーバーの起動またはビルドに進む準備が整います。

開発サーバーをlocalhost:5173で起動してCOOP/COEPを有効化する設定

モデルファイルの配置が完了したら、開発サーバーを起動して動作確認を行います。前述のとおり、NDLOCR-Lite WebはCOOP/COEPヘッダーが必要なため、file://プロトコルでは動作しません。開発サーバー経由での確認が必須です。

リポジトリ直下でnpm run devを実行すると、ViteがCOOP/COEPヘッダーを自動的に付与した状態でローカルサーバーを起動します。ブラウザでhttp://localhost:5173にアクセスすると、Netlify公開版と同じ動作環境が再現されます。ここでOCR処理が正常に動作することを確認してください。開発サーバーはホットリロード対応のため、ソースコードを編集すると即座にブラウザへ反映されます。機能追加やUIカスタマイズを試みる際はこのモードで開発を進めるのが効率的です。なお、ポート番号はViteの設定ファイルで変更可能なため、5173番が使用中の場合は別のポートを指定してください。

npm run buildで静的ファイルを生成しNetlifyへデプロイする流れ

動作確認が完了したら、本番環境向けのビルドを行います。npm run buildを実行すると、Viteによって最適化された静的ファイル群がdist/ディレクトリに生成されます。

Netlifyへのデプロイは、NetlifyのWebサイトにdist/フォルダをドラッグ＆ドロップするだけで完了します。その際、COOP/COEPヘッダーをサーバー側で設定する必要があります。Netlifyではリポジトリ直下にnetlify.tomlファイルを作成し、ヘッダー設定を記述することで対応できます。また、Vercel・GitHub Pagesなど他のホスティングサービスを使う場合も、各サービスのヘッダー設定機能で同様のCOOP/COEPヘッダーを付与してください。社内サーバーへのデプロイでは、NginxやApacheの設定ファイルにヘッダーを追加する方法が一般的です。ビルド後に生成される静的ファイルはCDNとの相性も良く、アクセス集中時の負荷分散にも対応しやすい構成となっています。

CC BY 4.0条件を満たしたうえで社内展開・改変利用する際の注意点

NDLOCR-Lite WebをCC BY 4.0ライセンスのもとで社内展開・改変する際には、いくつかの条件を正確に理解したうえで運用してください。

CC BY 4.0の主な要件は「著作者のクレジット表示」です。具体的には、改変・配布する際に「原著作者：国立国会図書館（NDL）」および元リポジトリのURLを明示する必要があります。社内ツールとして展開する場合でも、管理者向けドキュメントや利用規約ページに出典を記載することが求められます。また、本アプリケーションが依存するONNXモデルや各種ライブラリにはそれぞれ個別のライセンスが設定されています。商用サービスとして外部展開する場合は、GitHubリポジトリのLICENCE_DEPENDENCEIES（依存ライブラリのライセンスファイル）を確認し、各ライブラリのライセンス条件と矛盾しないか事前に確認してください。不明な点は法務部門への相談を推奨します。なお、改変を加えた派生版を公開・配布する際も、元のCC BY 4.0ライセンスの条件を継承することで、オープンな開発コミュニティへの貢献につながります。