最終更新日: 2026年8月20日
歴史的および手書き文書のためのOCRファイル形式 デジタル化による文化遺産の保存はルネサンスに突入しています。初期の光学文字認識（OCR）システムは、清潔で機械印刷された20世紀の書類を解析するよう設計されていましたが、現代の文化遺産機関ははるかに混沌として豊かな課題に直面しています：中世の写本、19世紀の筆記体の書簡、脆い装飾写本、そして何世紀も前のレジストリです。
歴史的文書の転写は、もはや単にプレーンな ASCII テキストを抽出するだけではありません。コンテキスト—ページの物理的ジオメトリ、ベースライン曲線、裏写り補正、余白注、略語、そして古文字学的な不確実性—を捉える必要があります。この専門分野は、しばしば手書き文字認識（HTR）に分類され、画像座標とテキスト層の両方を保存・交換するために使用されるファイル形式に大きく依存しています。
誤ったスキーマを選択すると、重要なベースラインデータが失われ、IIIF（International Image Interoperability Framework）マニフェストとの整合性が崩れ、長期的なデジタル保存が妨げられる可能性があります。ここでは、歴史的文書向けの主要な OCR および HTR ファイル形式、その構造的な強み、そしてアーカイブパイプラインに最適な選択を判断する方法についての決定的なガイドを紹介します。
歴史的ジレンマ：なぜプレーンテキストと標準的なPDFが失敗するのか 機械印刷された OCR は、シンプルな .txt ファイルやスキャンの下に隠しテキスト層を持つ “sandwich” PDF を出力することが多いです。歴史的写本や筆記体の手書きに対しては、これらの出力は次の 3 つの根本的な理由で失敗します：
非線形テキストと複雑なレイアウト: 歴史的な写本家は整然とした長方形のグリッドに従わなかった。テキストは余白に流れ込み、装飾されたイニシャルの周りを回り、挿入された行間訂正の間を織り交ぜ、または背表紙に沿って垂直に走る。 曲線的かつ斜めのベースライン: 手書き文字は硬直した水平軸に従うことはほとんどない。Transkribus、Kraken、eScriptorium などの HTR エンジンは、リガチャが多いスクリプトを解釈するために、バウンディングボックスではなくポリラインベースラインに依存している。 古文字学的複雑性とメタデータ: アーカイブ研究では、略語、歴史的な綴りの変化、損傷した読取、行レベルの信頼度スコアを追跡する必要がある。標準的な文書フォーマットはこの粒度を破棄してしまう。 元の遺物への忠実性を保つために、アーカイブコミュニティは転写テキストと共にレイアウトトポロジーを保存するよう設計された構造化 XML スキーマに依存している。
1. PAGE XML: 手書き文字認識（HTR）のゴールドスタンダード PRImA（パターン認識＆画像解析）研究所が開発した PAGE XML（Page Analysis and Groundtruth Elements）は、手書き文字認識と高度なレイアウト分析のための最先端フォーマットとして広く認識されている。
コアアーキテクチャ PAGE XML は物理文書を階層構造として扱う：
PcGts（ルート） Page (画像の寸法と全体の読順) TextRegion (段落、見出し、余白注、キャッチワード) TextLine Coords (ライン周囲のポリゴン座標) Baseline (文字の実際のベースラインに沿った点の列) TextEquiv (認識されたテキスト、オプションで信頼度メトリクス付き) 歴史的写本において優れている理由 ポリゴンとポリラインの精度: 文字を矩形のバウンディングボックスに強制的に入れる代わりに、PAGE XML は複数点のポリゴン境界と連続したベースラインを使用します。これにより、重なり合う筆記体の上昇部や下降部がセグメンテーションの妨げになるのを防ぎます。 細分化された構造タイプ: 領域は正確に分類できます（例：marginalia、drop-capital、signature-mark、header、editorial-note）。 広範なソフトウェアエコシステム: これは、Transkribus、eScriptorium、Kraken のような主要な HTR プラットフォーム向けの、内部およびエクスポート用の主要スキーマとして機能します。 2.最終更新日: 2026年1月12日
光学文字認識（OCR）は、もはやスキャンしたページを読み取り可能なテキストに変換するだけではありません。データ主導の現代において、選択するOCR出力形式は、検索性、コンプライアンス、長期保存、オートメーション、そして最新アプリケーションとの統合に直接影響します。シンプルなテキスト抽出から構造化された機械可読データまで、各形式はそれぞれ異なる目的を果たします。
本詳細ガイドでは、最も一般的に使用されるOCR出力形式（TXT、PDF、PDF/A、XML、JSON）を比較し、オープンソースのOCRパイプライン、エンタープライズ文書システム、AI搭載の分析プラットフォームなど、あらゆるワークフローに最適な形式を選ぶ手助けをします。
OCRとは何か、そして出力形式が重要な理由 OCRはテキストの画像（スキャンした文書、写真、PDF）を機械が扱えるテキストに変換します。このプロセスにより、従来は静的だったコンテンツを検索、編集、分析できるようになります。ただし、取得した生テキストは構造化され、利用可能な形式にパッケージ化する必要があります。
出力形式が決定する項目:
アクセシビリティ: コンテンツをどれだけ簡単に読み取り・検索できるか。 保存性: 元のレイアウトや視覚的完全性を維持できるか。 相互運用性: 他のソフトウェアやシステムがデータを容易に利用できるか。 編集性: 抽出されたテキストをどれだけ簡単に修正できるか。 メタデータと構造: フォントや位置、論理的階層（見出し、段落）などの情報を保持しているか。 誤った形式を選ぶと、書式の喪失、統合の困難、または法的保存に適さない文書になる可能性があります。
OCR出力形式の詳細比較 1. TXT（プレーンテキスト） 最もシンプルで汎用的な形式です。TXTファイルは抽出された文字列のみを含み、スタイル、画像、レイアウト情報は含まれません。
取得内容: 生テキスト。改行やスペースはOCRエンジンの推測に基づくことが多いです。 長所:
非常に軽量: ファイルサイズが極小。 どこでも互換性あり: 任意のテキストエディタで開けます。 テキスト分析に最適: データマイニング、自然言語処理（NLP）、キーワードインデックスに適しています。 完全に編集可能: コピー、貼り付け、修正が容易です。 短所:
すべての書式が失われる: フォント、太字、列、ページ構造が失われます。 画像なし: 埋め込み画像や写真は除去されます。 視覚的再現性が低い: 元文書とほとんど見た目が似ていません。 ベストユース: 分析用の純粋なテキスト抽出、シンプルな検索インデックス作成、またはストレージ容量が重要な場合に最適です。文書の保存や書式付きレポートには不向きです。
SEOノート: スキャン文書からクローラブルなテキストコンテンツを作成しウェブに公開するのに最適です。検索エンジンはプレーンテキストを容易に解析できます。
2. PDF（ポータブルドキュメントフォーマット - 標準） OCRで作成されたPDF（一般に「検索可能PDF」または「テキストレイヤー付きPDF」と呼ばれる）は、認識されたテキストを元のスキャン画像の背後に不可視で埋め込みます。
• 取得内容: 元のスキャンと見た目が全く同じですが、テキストの選択、検索、コピーが可能な文書です。
長所:
元のレイアウトと外観を保持: フォント、列、画像、グラフィックを維持。 検索可能かつ選択可能: 視覚的忠実性とテキスト機能を兼ね備えます。 広く受容: 文書共有のグローバル標準です。 短所:
ファイルサイズが大きい: 画像とテキストレイヤーの両方を含む。 構造データが限定的: 検索は可能ですが、タイトルと段落を自動的に認識しません。 専用ツールが必要な編集: 高度なテキストレイヤー編集にはAdobe Acrobat等の特定ツールが必要です。 ベストユース: 元と同一の外観を保ちつつテキスト検索を可能にする文書の共有に最適です。法務、学術、ビジネス文書で一般的です。
SEOノート: 検索エンジンは検索可能PDFのテキストレイヤーをクロールでき、関連クエリでの文書の見つかりやすさが向上します。最終更新: 05 Jan, 2026
もし文書をスキャンして、コンピュータが画像からテキストを検索可能・編集可能なコンテンツに変換する仕組みを不思議に思ったことがあるなら、**光学文字認識（OCR）**の世界に触れたことがあります。しかし、単に画像からテキストを抽出するだけで話は終わりません。本当の魔法は、その情報がどのように保存・構造化されるかにあります。
歴史的アーカイブをデジタル化したり、ビジネスの請求書を処理したり、印刷された本をデジタルライブラリへ変換したりする際、適切なOCR 出力フォーマットを選ぶことが重要になります。この領域を支配するフォーマットは HOCR、ALTO、PDF/A の3つです。各フォーマットは異なる目的に特化しており、その違いを理解すれば、後々のフラストレーションを何時間も削減できます。
ここでは、これらのフォーマットについて技術的基礎から実用的な活用例まで、知っておくべきすべてを解説します。
OCR ファイルフォーマットとは？ 特定のフォーマットに入る前に、OCR ファイルフォーマットが実際に何をするのかを確認しましょう。OCR ソフトウェアが文書を処理するとき、単なるプレーンテキストだけでなく、貴重な構造情報や位置情報も取得します。具体的には以下の要素が含まれます。
テキストコンテンツ: 実際の単語や文字 レイアウト情報: ページ上のテキストの位置（段落、列、ヘッダーなど） 書式データ: フォントのスタイル、サイズ、色 信頼度スコア: 各文字に対する OCR エンジンの確信度 構造階層: 章、節、見出し、脚注 OCR ファイルフォーマットは、抽出されたテキストとともにこの豊富なメタデータをパッケージ化し、元の文書の視覚的・構造的完全性を保ったデジタルツインを作り出します。
HOCR：HTML ベースの挑戦者 HOCR とは？ HOCR（HTML OCR の略）は、OCR 結果を HTML ファイルに埋め込むオープンスタンダードです。Tesseract OCR エンジンのエコシステムの一部として開発され、標準的な HTML マークアップにカスタムクラスや属性を追加して OCR データを表現します。
技術構造 典型的な HOCR ファイルは、以下のように見慣れた HTML ですが、専用要素が組み込まれています。title 属性にはバウンディングボックス座標（bbox）が含まれ、ページ上の各テキスト要素の正確な位置を示します。最終更新日: 29 Dec, 2025
文書のデジタル化の世界では、OCR（光学文字認識） はしばしば最終工程と見なされます――スキャン、文字認識、アーカイブ、完了。しかし、現代のコンプライアンス、オートメーション、データ駆動型ワークフローは、単なる 検索可能 PDF 以上を求めます。トレーサビリティ、機械可読構造、そして長期保存の保証が必要です。
ここで PDF/A-3 が登場します――誤解されがちで、時に議論の的となりますが、間違いなく強力です。多くの開発者は、以前の PDF/A 標準が厳格に禁止していた「元のソースファイルをアーカイブ PDF に直接埋め込む」ことができるため、これを「ハイブリッドモンスター」と呼んでいます。
PDF/A-3 が実際に何であるか、OCR ワークフローにとってなぜ重要か、そして オリジナルデータの埋め込み が現代の文書処理をどのように変えるかを探ります。
PDF/A-3 とは正確には何ですか？ PDF/A-3 は、電子文書の長期保存のための ISO 標準（ISO 19005-3）の第3部です。PDF/A-1 や PDF/A-2 が主に「視覚的再現性」に焦点を当てていたのに対し、PDF/A-3 は画期的な機能を導入します―― 埋め込みファイル添付 です。
デジタルコンテナとして、次のようなものを格納できます。
スキャン文書の視覚的表現（通常は PDF） 元のソースファイル（Word 文書、Excel スプレッドシート、CAD 図面） OCR テキスト出力 メタデータや補足情報 データベースエクスポートや XML ファイル すべてが単一の標準化されたパッケージにまとめられ、何十年先でもアクセス可能であることを目指しています。
OCR の問題点：見た目は綺麗でもデータとしては使いにくい 典型的な OCR ワークフローを見てみましょう。
100 枚の請求書をスキャンします。OCR ソフトはそれらを処理し、テキストを認識して「検索可能 PDF」を作成します。画像の上に見えないテキスト層が重ねられます。
問題点は？ そのテキスト層は構造化されていません。PDF から表をコピーして Excel に貼り付けようとすると、ほとんどの場合フォーマットが崩れます。PDF は文字は認識していますが、「この数値は総税額で、こちらは請求日だ」という意味は理解していません。
ここで PDF/A-3 ハイブリッドワークフロー がゲームチェンジします。
「ハイブリッド」ソリューション 単に検索可能テキスト層を作るだけでなく、最新の OCR エンジンは次のことが可能です。