スキャン文書の翻訳 2026年版：OCRパイプラインからレイアウト対応AIまで

By Linnk Research Team | June 2026 | 13 min read

要点まとめ

スキャン文書の翻訳は、「ページを読み取る」と「翻訳結果を元のレイアウトに戻す」という二つの難題を組み合わせた作業だ。多くのツールはどちらか一方は得意でも、もう一方が弱い。
2026年時点で主流のアプローチは三つ——従来型のOCR→機械翻訳パイプライン、OCR+AIのハイブリッドスタック、そしてページを「テキストの羅列」ではなく「画像」として捉えるレイアウト対応ビジョンAI。
本質的な問題はエンジンの選択ではなく、失敗パターンにある。傾き補正、段組みレイアウト、混在文字、表、脚注、印鑑、手書きメモ——こうした箇所でパイプラインは静かに破綻する。
「とにかく文章が読めればいい」と「元の体裁を保ったまま返してほしい」は別の要件だ。目的に合った手段を選べばよく、一段落の抜粋にレイアウト再現の対価を払う必要はない。
翻訳されたスキャンの最終的な利用者が人間ではなくAIエージェントになるケースが増えつつある——契約書バンドルを精査する法務レビューワークフロー、海外の論文を読む調査エージェントなど。先行採用者たちがその基準を作っている。

スキャン翻訳がなぜ「二つの難題」なのか

スキャンしたPDFを開いてみよう——1987年の契約書、図書館のスキャナーで撮影された日本語の論文、誰かが二度ファックスしたスペイン語の行政書類。人間の目にはページが正常に見える。しかし翻訳ツールにとって、それは画像だ。テキストはその下に存在しない。人間が文字として読む形に配置されたピクセルがあるだけだ。翻訳を行う前に、何かがその文字を抽出しなければならない。そして別の工程として、翻訳された文字を元の外観を保ちながらページに戻す必要がある。

これが罠だ。生まれながらにデジタルなPDFの翻訳は本質的に一つの問題だ——文字列を翻訳済み文字列に置き換え、穏やかに再フローする。スキャンPDFの翻訳は二つの問題であり、二番目の問題——元に戻す——でほとんどのツールは静かにあきらめる。段組みが潰れ、表が段落に変わり、脚注が本文に溶け込んだWordドキュメントのテキストの壁が返ってくる。翻訳は読める。しかし誰かに渡せるものではない。

実際の現場で使われている文書でスキャン文書翻訳ツールを検証してきた一年間——印鑑と手書き署名のある二ヶ国語契約書、三ページ先の図を参照する脚注付きの段組み論文、チェックボックスと網掛けフィールドのある行政書類、傾きや裏移りのある資料。これは、現場で何が起きているか、各アプローチがどこで壊れるか、そして手元にある文書に合ったツールをどう選ぶかを記録したフィールドレポートだ。

背景：OCRと翻訳がなぜ別々に発展してきたのか

OCR——光学的文字認識——は1970年代から存在する。紙をデジタル化するために作られたのであって、翻訳するために作られたわけではない。出力は検索インデックスや文書管理システム、スクリーンリーダーに送ることを想定していた。段組みが正しく再現されるかどうかは別のツールの仕事であり、脚注が正しい本文段落に紐付いているかはレイアウトの問題だった。

機械翻訳も同じように、その壁の反対側で育った。翻訳エンジンは原文の文字列を受け取り、訳文の文字列を返すために作られた。原文をエンジンに渡す処理は別のラッパーが担い、翻訳された文字列を元の場所に戻す処理もまた別のラッパーが担っていた。

つまり、知らないうちに使ってきたこの10年のスタンダードなパイプラインは、OCR→翻訳→レイアウト復元という三段階だった。それぞれが独立した失敗パターンを持ち、互いを認識しない。失敗は累積した。OCRが一つの段落として誤読した段組みは、文脈を失った翻訳になった。OCRが行として線形化した表は、翻訳エンジンによって散文に変えられた。OCRが文字化けとして読んだ印鑑は、翻訳エンジンによって忠実にナンセンスに変換された。

新しいアプローチは、段階を統合することでこれを解決しようとしている——二段階を統合するもの、三段階すべてを統合するもの、OCRそのものを別の認識手法に置き換えるものがある。次の三つのセクションがその話だ。

パート1：従来型OCR→機械翻訳パイプライン

従来型スタックは2026年においても最も一般的だ——とりわけ企業の文書ワークフローでは。三つの独立した工程で動く。まずOCRエンジン——Tesseract、ABBYY、Google Document AI、AWS Textract——がスキャン画像を読み取り、テキスト表現を出力する（バウンディングボックス付きのこともあれば、大まかな読み取り順序の情報が付くこともある）。次に翻訳エンジン（Google翻訳、DeepL、Microsoft Translator）がそのテキストを受け取り、翻訳版を出力する。三番目に、レイアウトエンジンが元のページをモデルとして翻訳テキストをページに配置しようとする。

得意なのは、大量処理が必要な整形済みの一段組み文書だ。既知のテンプレートの請求書、標準的な書式の契約書、OCRエンジンが学習したような文書。スループットは優秀で、コストも予測しやすい。エンジンは成熟している。

苦手なのは、それ以外のほぼすべてだ。締め切りを過ぎてから気づくことが多い三つの静かな失敗パターン：

段組みレイアウトの読み取り順序。 脚注付きの二段組みジャーナルページは、使用するOCRエンジンによって四通りの順序で読まれうる。翻訳エンジンは、失われた構造に意味が依存していた文の混乱を受け取り、自信を持って訳文の混乱を作り出す。
表が散文になる。 OCRが表の構造を明示的に保持しない限り、翻訳エンジンには行が文として見える。「Q1 Q2 Q3 Q4」は四つの列ヘッダーではなく、翻訳される一つのフレーズになる。翻訳後のレイアウトには、表があった場所に段落が残る。
混在文字の衝突。 英語の技術用語がインラインに入った日本語論文、ラテン文字の名前が混じる中国語契約書、欧文数字が埋め込まれたアラビア語文書。OCRはそれぞれのスクリプトを個別には正しく認識しても、スクリプト間の境界判定を間違えることが多い。そのため単語がテキストフィードの中でつながり、翻訳エンジンはすべての遷移箇所で文字化けした出力を生成する。

従来型パイプラインがほぼ確実にうまくいかないもの：傾いたスキャン、低解像度の写真、印鑑、手書き注記、署名、印刷テキスト以外のものすべて。クリーンなオフィススキャンのために作られており、それに応じた挙動をする。

パート2：ハイブリッドOCR+AIスタック

次世代はパイプラインの形を維持しながら、コンポーネントをAIネイティブなものに置き換えた。OCR段階は従来型エンジンのままかもしれないが、その出力は大規模言語モデルに渡され、読み取り順序を整理し、曖昧さを解消し、混在文字を処理してから翻訳する——多くの場合、二段階を別々に実行するのではなく一回のAI呼び出しで行う。レイアウト再構築のステップもAIが支援することがあり、元のレイアウトを近似しながら翻訳テキストをどう流し込むかをモデルが判断する。

大きな改善点：エラーが累積しにくい。OCRが単語を誤読しても、前後の文脈と合わない誤読はAIステップでしばしば修正される。OCRが表を線形化しても、AIステップは位置情報のヒントから表を再構築することが多い。読み取り順序が曖昧な場合も、AIステップが文脈として一貫するテキストになる順序を選ぶ。魔法ではない——AIは文書の見た目に関する統計的な事前知識を使っており、本当に珍しい文書ではその知識が通じない——しかし現実のスキャンの大半においては、意味のある改善だ。

ハイブリッドスタックは2026年において「モダンな」文書翻訳サービスの多くが内部で動かしているものだ——マーケティングコピーにそう書かれていなくても。ユーザー体験は「スキャンをアップロードして、元のレイアウトで翻訳を受け取る」だ。レイアウトが崩れないかどうかは、レイアウト再構築ステップがどれほど積極的か——そしてAIが翻訳を収めるために元の構造からどれだけの逸脱を許されているか——による。

二つの失敗モードは残っている：

テキスト伸縮によるレイアウトの乱れ。 翻訳テキストが原文の文字数と一致することはほぼない。ドイツ語は英語より30%長くなり、中国語は40%短くなる。ハイブリッドスタックは翻訳テキストを元のバウンディングボックスに流し込む——つまりドイツ語ではボックスが溢れ（オーバーフロー、不自然な改行、コンテンツの欠落）、中国語ではスカスカに見える。優れたスタックはレイアウトを再調整する。劣ったものは問題が存在しないように振る舞う。
脚注、印鑑、欄外注記。 ハイブリッドスタックは依然として、主要な読み取り流れに属さないコンテンツに苦労する。ページ6の脚注がページ9の図を参照していても、浮いた文として届くことが多い。印鑑（「承認済」）は環境ノイズとして届く。手書きのイニシャルはたいてい何も届かない。

パート3：レイアウト対応ビジョンAI

最新のアプローチは、「OCRを独立した段階として行う」というアイデア自体をスキップする。マルチモーダルビジョンAIはスキャンされたページを画像として見て、領域を識別し（本文、見出し、表、段、図、脚注、印鑑、手書き）、それらの関係を理解し、元のレイアウトを尊重した翻訳版を生成する——すべて一度のパスで、同じモデルが構造と意味を同時に考慮する。

これが2026年における「レイアウト対応」という言葉の実際の意味だ。レイアウト保持機能を後付けしたOCRではなく、ページの二次元的な構造を意味の一部として扱うビジョンモデル。数年前に画像キャプションで起きたシフトと同じ——テキストストリームを処理するのではなく、ページを見るモデル。

得意なこと：乱雑なスキャン。混在文字。表として見える表。読み取り順序が曖昧になりうる段組みレイアウト。読者には構造的に明らかでも段階ごとのパイプラインには見えない、本文段落への脚注の紐付け。テキストとして書き起こされるのではなく、印鑑として認識される印鑑。手書きの欄外注記でさえ——ただし手書き認識はどのアプローチでも最も弱いリンクだ。

まだ苦手なこと：コスト（ビジョンモデルはページあたりの料金が高い）、速度（長い文書ではOCR→翻訳より遅い）、そしてハイブリッドスタックと同じテキスト伸縮のレイアウト問題。ビジョンモデルが原文より40%長い翻訳フランス語を生成したとしても、誰かがレイアウトを決めなければならない——再調整、再フロー、文字縮小、またはオーバーフロー許容。ツールによって選択は異なり、どれも完全に透明ではない。

正直な評価：レイアウト対応ビジョンAIは難しい文書において三方式の中で最も強力であり、簡単な文書においては最もコスト効率が悪い。クリーンなオフィススキャンのフォルダーには過剰だ。手書きのイニシャル、印鑑、混在文字、重要な脚注が含まれる契約書バンドルには、途中で何かを失わない唯一のアプローチだ。

三つのアプローチの比較

アプローチ	最適な用途	静かに失敗する場面	レイアウト忠実度	ページあたりコスト
従来型OCR→機械翻訳	大量処理、一段組み、クリーンなオフィススキャン	段組みレイアウト、表、印鑑、混在文字、手書き	低——通常テキスト文書に平坦化	最低
ハイブリッドOCR+AI	現実的な中品質スキャン、品質混在のバンドル	テキスト伸縮によるオーバーフロー、脚注、欄外注記	中——妥当なレイアウト、若干の乱れあり	中
レイアウト対応ビジョンAI	乱雑、混在文字、構造が複雑な文書	長文書のコストと速度、手書き認識はまだ不完全	高——言語間の制約の範囲で	最高

表は単純化している。実際のプロダクションツールはたいていアプローチを組み合わせている——クリーンなページには高速OCR、難しいページにはビジョンAI、ユーザーが実際に求める出力形式に合わせてレイアウト再構築を調整する。「どのアプローチが最善か」ではなく「手元の文書と出力の用途に合った組み合わせはどれか」が正しい問いだ。

現場を定義する失敗パターン

この記事から一つだけ覚えておくとすれば、失敗パターンを覚えてほしい。ツール選びの本当のインターフェースはそこにある。

傾き。 少し角度のついたページ。OCRの信頼度が下がり、読み取り順序が乱れ、段組みが互いに滲む。従来型パイプラインはしばしばナンセンスを出力し、ハイブリッドスタックは通常回復し、ビジョンAIは傾きにほぼ無関心だ——ページを画像として読んでいるため、回転はわずかな調整に過ぎない。

段組みレイアウト。 学術論文、新聞、雑誌、行政書類。OCRがどの段を先に読むかが問題だ。従来型パイプラインはしばしば段を混在させ、まるで混乱した対話のように読めるテキストを生成する。ハイブリッドスタックは通常正しく処理する。ビジョンAIはほぼ常に正しく処理する——段の識別はまさにその得意分野だからだ。

表。最も多く問い合わせがあるシナリオ。従来型パイプラインは表を行→散文に潰す。ハイブリッドスタックは認識できれば表を再構築する。ビジョンAIは表をネイティブに処理する——グリッドが見えているからだ。翻訳後も表はグリッド構造を保っていなければ誰にとっても役に立たない——出力が編集可能な表なのか、表の画像としてレンダリングされているのかに注目してほしい。

脚注と参照。 誰もマーケティングしない難問だ。「表3を参照」と書かれたページ4の脚注は、表3に紐付いていなければならない——少なくとも修飾している本文の文に紐付いていなければならない。従来型パイプラインは脚注を本文テキストに混入させる。ハイブリッドスタックは大きくばらつく。ビジョンAIは構造的な関係を目に見える形で保つ唯一のファミリーだ——ただしページをまたいだ参照は依然としてほぼ手作業での修正が必要だ。

混在文字。 英語の技術用語が入った日本語論文。フランス語の地名が入った日本語契約書。欧文数字が混じるアラビア語文書。スクリプト間の境界は、パイプラインが最も頻繁に失敗する場所だ。ビジョンAIは境界を最もうまく処理する——視覚的なセグメンテーションを理解しているからだ。従来型パイプラインはスクリプトを文字化けしたテキストに混合させることが多い。

手書き注記。 どこでも最も弱いリンク。レイアウト対応ビジョンAIでさえ、手書き——特に草書や速書き——は正解と不正解が同程度だ。重要な文書では、手書き注記には必ず人間によるレビューが必要だと考えてほしい。兄弟ツールのscanned.toは手書きOCRに特化したチューニングが施されている——欄外注記が重要で下流で翻訳する予定なら、まずそこでデジタル化するのが合理的だ。

印鑑・捺印。 ビジョンAIはほぼ印鑑として認識し、従来型OCRはほぼ文字化けテキストとして誤書き起こしし、ハイブリッドスタックは印鑑認識のために明示的に訓練されていない限りほぼスキップする。契約書バンドルに翻訳後の出力で保持が必要な印鑑がある場合は、ツールが印鑑を画像としてレンダリングするのかテキストとして書き起こすのかを事前に確認してほしい。

低解像度写真。 薄暗い場所でスマートフォンで撮影した契約書の写真はスキャンではなく、スキャン向けに作られたパイプラインのほとんどはうまく処理できない。ビジョンAIは最も寛容だ——ノイズのある画像で訓練されている——しかし前処理（傾き補正、コントラスト調整、シャープニング）はどのアプローチにも効果がある。

読者がエージェントになるとき

この記事のほとんどは、翻訳されたスキャンを人間が読む想定だ。2026年においてそれはまだ一般的なケースだ。しかし先行採用のケース——そしてツールが向かう方向を形作っているケース——は、翻訳文書の消費者がAIエージェントである場合だ。

M&Aデューデリジェンスでスキャンされた契約書バンドルを精査する法務レビューエージェントを想像してほしい。何百もの英語・日本語・中国語の契約書を翻訳し、重要条項を抽出し、異常な規定をフラグし、サマリーメモを作成しなければならない。そのエージェントはあなたのように百件のスキャンを読むことはできない。翻訳ツールをサブステップとして呼び出し、翻訳されたテキストを下流の要約または抽出ステップに渡す。翻訳が段組みを潰した散文の壁であれば、下流の抽出ステップはすべてを誤読する——条項の順序が入れ替わり、見出しが本文に混入し、表のセルが文章として繋がる。エージェントの確信度は高く、精度は崩壊している。

海外の論文を読む調査エージェントも同じだ——中国語、日本語、英語の論文を横断して文献調査を行うManusスタイルの自律オペレーター、英語以外のAPIドキュメントを翻訳してコードベースに統合するClaude CodeやCursorのエージェントモード。ますます、エージェントが読者となり、人間がレビュアーとなっている。エージェントには文章だけでなく、構造を保った翻訳出力が必要だ。

ツール選択への示唆。エージェントフレンドリーな翻訳は、人間フレンドリーな翻訳とは機能の優先順位が異なる。構造化出力——表は依然として表タグ付き、見出しは依然として見出しタグ付き、脚注は依然として脚注タグ付きの翻訳テキスト——は、下流ステップが機能するために必要なものだ。原文へのページレベルの参照——「この段落はページ7に、この印鑑はページ12の右下に」——はエージェントが何かがおかしいと思ったときに確認またはエスカレーションできるようにする。呼び出し可能なインターフェース（CLIまたはAPI）は、ウェブUIをスクレイプすることなく、エージェントが翻訳を呼び出す方法だ。

コーディングエージェントがここに最初に到達した。いつもそうであるように。翻訳された技術ドキュメントと外国語のコードコメントをワークフローに取り込むことを一年前から行い、アジェンティックな知識労働に広まりつつあるパターンに落ち着いた——構造化出力、原文参照、呼び出し可能なインターフェース、予測可能なスキーマ。これらの機能を提供するツールが、アジェンティックな知識労働がイノベーター領域から拡大するにつれて選ばれるツールになるだろう。

正直な注記：エージェント経由のスキャン文書翻訳はまだ初期段階だ。2026年における法務レビューや調査エージェントのワークフローのほとんどはパイロットであり、本番運用ではない。知識労働者の多くはまだスキャンをエージェントに通していない。しかし方向性は定まっている。今後十二ヶ月で、コンプライアンス、デューデリジェンス、学術調査においてエージェント経由の文書ワークフローの実際の本番利用が見られるようになり、それを支えるツール機能（構造化出力、呼び出し可能なインターフェース、原文に基づく参照）は差別化要因となるだろう。

人間ユーザーにとっての朗報：翻訳ツールをエージェントフレンドリーにする機能——構造化出力、レイアウト忠実度、原文に基づく参照——は、人間にとっても真剣なツールにする機能と同じだ。今日の自分のために良い選択をすれば、将来の自分とそのエージェントのためにも良い選択をしたことになる。

選び方：チェックリスト

簡単な自己診断。目の前の作業に当てはまる項目にチェックを入れてほしい。

原文は一段組みのクリーンなオフィススキャンか？はいなら、従来型パイプラインで十分で、より安価だ。
文書に段組みレイアウト、脚注、または損なわれてはならない表があるか？はいなら、ハイブリッドスタックまたはレイアウト対応ビジョンAIが必要だ。
文書は複数のスクリプトを混在させているか（CJK＋ラテン、アラビア語＋数字）？はいなら、レイアウト対応ビジョンAIを優先する——スクリプト境界はパイプラインが最も大きく失敗する場所だ。
文書に保持が必要な印鑑、捺印、手書き注記があるか？はいなら、レイアウト対応ビジョンAI。手書きはいかなる場合も人間によるレビューが必要だと考えること。
翻訳文書は共有、署名、または提出されるか——単に読まれるだけでなく？はいなら、レイアウト忠実度は妥協できない。フラットなテキストダンプは使い物にならない。
原文が別の言語で、かつ単にレンダリングするだけでなく内容を理解したいか？はいなら、翻訳と要約を別々にエクスポートで組み合わせるのではなく、両方を一度に処理するスタックが望ましい。
AIエージェントが翻訳出力をより大きなワークフローの一部として消費することがあるか？はいなら——投機的にでも——構造化出力、ページレベル参照、呼び出し可能なインターフェースを持つツールを優先する。
原文はスキャンではなく写真か？はいなら、傾きとコントラストを前処理し、ビジョンAIのノイズ耐性を活用する。
品質の混在した文書の束があるか？はいなら、自動ルーティング（簡単なページには安価なパイプライン、難しいページにはビジョンAI）のツールがコストと時間の両方を節約する。
レイアウトに関係なく別の言語でテキストが読めれば十分か？はいなら、シンプルな従来型パイプラインが最も安価な答えだ。

構造に関する項目（段組み、表、混在文字、印鑑、エージェント利用）を三つ以上チェックしたなら、従来型パイプライン層は卒業している。

現場のツール

ランク付けではなく——この分野は動きが速すぎる——何を見るべきかを整理し、各特性を強調するツールについて簡単な注記を加える。Linnk Translatorもその一つだ。機能が本当に合致する場所で言及し、そうでない場所では言及しない。

大量のファイル形式変換。 「とにかくこのファイルを別の言語でレンダリングしたい」という作業を多くの形式で行う場合——DOCX、PPTX、XLSX、PDF、EPUB、SRT、VTT——doctranslator.netは、予測可能なページあたりの料金と幅広い形式サポートを持つ強力な例だ。事実として：スキャンPDFは彼らのモデルでは生まれながらのデジタルファイルの5倍のクレジットを消費する。これはスキャン翻訳が実際により多くの計算コストを必要とするという正直な価格設定だ。スキャン固有のレイアウト忠実度よりも形式カバレッジが重要な場合に使おう。

モバイルファーストのスキャン・デジタル化。 作業がデジタル化から始まる場合——他のことが起きる前に紙を使えるデジタル形式にすること——scanned.toは当グループの兄弟ツールで、モバイルファーストで強力な手書きOCRを持ち、従量課金モデル（クレジットは有効期限なし）だ。同じ旅の異なる段階。作業がデジタル化の場合はそこから始め、読む・翻訳する・推論するための下流に結果を持ち込む。

クイックテキスト抽出のためのサインアップ不要OCR。 スキャンからクリーンなテキストだけが必要で他は何もいらない場合、scanread.ai——これも兄弟ツール——は無料の毎日の利用枠でOCRを実行し、サインアップ不要で、強力なCJKサポートを持つ。テキスト抽出への最速の経路。テキストを理解や翻訳にする必要があれば、下流ツールが引き継ぐ。

スキャン対応のレイアウト保持文書翻訳。 文書がスキャンで、かつ元の外観のまま出力する必要があり、かつ翻訳が防御できるものでなければならない場合——長い契約書、資料の調査資料、行政書類——Linnk Translatorはこの層のツールの一つだ。スキャンPDFのレイアウト対応処理、原文の忠実なデジタル化、翻訳前のAI文書事前検査、オプションの翻訳前指示（トーン、用語集、文の長さの設定）、翻訳後の段落レベルの改善、150以上の言語対応、アップロードされたファイルの48時間自動削除を備える。ウォーターマークなしのダウンロード可能な3ページプレビューは、コミットする前にLinnkが特定の文書を適切に処理することを確認する方法だ。この層には他のツールも存在する。ブランドではなく機能の適合度で選ぼう。

エンタープライズOCR＋ワークフロー統合。 ABBYY FineReader、Google Document AI、AWS Textract、Microsoftの文書インテリジェンススタックは、独自の翻訳レイヤーを下流に持つ企業向けの重量級オプションとして残っている。ボリュームと既存のエンタープライズパイプラインとの統合には強い。すぐに使えるレイアウト忠実性を持つ翻訳には弱い——翻訳は彼らのモデルでは下流の関心事だからだ。

どのツールもあらゆる軸で勝つことはない。手元の文書に対して、正直な選択は優先事項がボリュームなのか、忠実度なのか、エージェント対応なのか、コストなのか——そしてスキャンがワークフローの開始点なのか中間点なのかによる。

隣接ワークフローとの組み合わせ

翻訳はほとんどの場合、単独では存在しない。最も一般的な組み合わせ：

まずデジタル化、次に翻訳。 原文が紙や手書きが多い場合は、クリーンアップされた文書をレイアウト対応翻訳ツールに持ち込む前に、デジタル化ツール（モバイルファーストの紙にはscanned.to、クイックテキスト抽出にはscanread.ai）を通す。
翻訳して要約。 目標が外国語文書を理解することで、単にレンダリングすることではない場合は、翻訳を一回のパスで多言語入力を扱う長文書要約ツールと組み合わせる。一ステップのアプローチは、翻訳→要約の二ホップよりも情報の損失が少ない。
翻訳して抽出。 契約書バンドルやフォームの場合は、翻訳を構造化抽出ステップと組み合わせる——条項抽出、フォームからのキー・バリュー抽出、表抽出。ここにエージェントワークフローが生きる。

いずれの場合も、同じ旅の異なる段階だ。各段階でのクリーンな引き継ぎが最終的な出力を使えるものにする。

よくある質問

スキャンしたPDFを翻訳して、同じレイアウトのPDFを受け取れますか？

はい、2026年においてこれはレイアウト対応ツールに期待できる出力です——翻訳テキストだけのWordドキュメントではなく。忠実度はアプローチによって異なります。従来型OCR→機械翻訳パイプラインは通常フラットなテキストを返します。ハイブリッドOCR+AIスタックは若干のずれはあるものの妥当な近似を返します。レイアウト対応ビジョンAIは、翻訳テキストが原文の文字数と一致することがほぼないという制約の範囲で、最も高い忠実度の再構築を返します。

翻訳テキストが元のレイアウトを崩すのはなぜですか？

言語によって文字密度が異なります。ドイツ語は英語より長くなり、中国語は短くなり、アラビア語は右から左に書きます。翻訳テキストを元のレイアウトのバウンディングボックスに流し込むと、溢れたり、不自然な空白ができたり、行の折り返しが崩れたりします。優れたツールはレイアウトを再調整してこの差を吸収します。劣ったツールは元のボックスをそのままにして、テキストが溢れるか伸びるかに任せます。

AIはスキャン文書の手書きメモを翻訳できますか？

場合によります。手書きOCRはあらゆるアプローチで最も弱いリンクであり、最も強いビジョンAIでさえ草書や速書きについては正解と不正解が同程度です。重要な文書では、手書き注記には人間によるレビューが必要だと考えてください。兄弟ツールのscanned.toは手書きOCRに特化したチューニングが施されており、翻訳の前のデジタル化ステップとして合理的な選択肢です。

スキャン文書の表は翻訳後も表のままですか？

ツールによります。従来型パイプラインは表を散文に平坦化します。ハイブリッドスタックは構造を認識できれば表を再構築します。レイアウト対応ビジョンAIは表をネイティブに処理します。表の保持が重要な場合は、出力が編集可能な表なのか表の画像としてレンダリングされているのかを確認してください——どちらも一般的であり、必要なものは次のステップが読むことなのか編集することなのかによります。

スキャン文書の翻訳で混在文字（英語の専門用語が入った日本語など）はどう処理されますか？

これは従来型パイプラインにとって難しいケースの一つで、しばしばスクリプト境界でテキストを文字化けしたものに混合させます。ハイブリッドスタックはより良い結果を出します。レイアウト対応ビジョンAIは混在文字を最もうまく処理します——フラットなテキストストリームからではなく、スクリプト間の視覚的なセグメンテーションを理解しているからです。混在文字の文書では、エンジンの選択が大きく影響します。

AIエージェントはスキャン文書翻訳ツールを自動ワークフローの一部として呼び出せますか？

一部のツールは今日そのように使われ始めています——主に法務レビューのパイロットや調査エージェントのワークフローで。ボトルネックはインターフェースです。ウェブUIのみを提供するツールはエージェントからクリーンに呼び出せません。エージェントが選ぶツールはCLIまたはAPIを公開し、構造化出力（構造が保持されたテキスト、フラットテキストではない）を返し、原文参照を含みます。採用はまだイノベーター・アーリーアダプター層にあります。今後十二ヶ月でより標準的になるでしょう。

元の文書の印鑑、署名、捺印はどうなりますか？

印鑑と捺印はレイアウト対応ビジョンAIによって通常印鑑として認識され、テキストとして書き起こされるのではなく画像として出力にレンダリングされます。従来型パイプラインは文字化けした文字として誤書き起こしし、翻訳エンジンが忠実にナンセンスに変換します。法的または記録目的で印鑑を翻訳文書に保持する必要がある場合は、コミットする前にツールがどう処理するかを確認してください。

生まれながらにデジタルなPDFの翻訳とスキャンPDFの翻訳の違いは何ですか？

生まれながらにデジタルなPDFにはテキストレイヤーがあります——翻訳ツールは文字を直接読めます。スキャンPDFは画像です。文字を最初に抽出しなければなりません。この記事の失敗パターンのほとんどはその抽出ステップに起因します。翻訳エンジン自体はどちらにも同程度のパフォーマンスを発揮します。上流の抽出こそがスキャンPDFがより多くの計算コストを必要とし、より時間がかかり、より高度なレイアウト処理が必要な部分です。

結論。 スキャン文書の翻訳は二つの難題だ——ページを読み取り、元に戻す——2026年の三つのアプローチは異なるトレードオフでこれを解決する。クリーンなオフィススキャンには、従来型パイプラインで十分で安価だ。段組みレイアウト、表、混在文字、印鑑を持つ実際のスキャンには、レイアウト対応ビジョンAIが途中で何かを失わない唯一のアプローチだ。大きな声のマーケティングではなく、手元の文書に合った層を選ぼう。