← All Research

日本語文書翻訳 2026年版：現場で実際に壊れるポイント

By Linnk Research Team | August 2026 | 11 min read

世に出回っている文書翻訳ツールの大半は、英語を軸に設計され、後から他言語に対応させたものだ。単語の間にスペースがあり、左から右へ読む表音文字同士の言語ペアであれば、その設計思想でも大きな支障は出ない。しかし日本語が翻訳パイプラインに入った途端、この前提はあちこちで崩れる。

本稿は、実際の業務で日本語文書を翻訳する過程において何が壊れるのか、そして何を確認すべきかを整理したフィールドレポートだ。

「膨張」ではなく「収縮」が起きる

ローカライズの世界でよく言われる注意点は文字数の「膨張」だ——ドイツ語は英語より3割ほど長くなるので余白を見ておけ、という話である。日本語は逆だ。英語から日本語に訳すと、多くの場合むしろ縮む。ときにはかなり縮む。英語で12語ある箇条書きが、日本語では短いひとことに収まってしまうことも珍しくない。

これは一見、無害な話に思える。だが実際はそうではない——レイアウトはそれ自体が視覚的な説得力を持つからだ。三つの箇条書きでバランスよく組まれていたスライドは、余白の中に浮かぶ三つの短い断片になる。英語の列見出しに合わせて幅を取った表は、日本語の見出しがその3分の1のスペースで済んでしまい、セルの中でスカスカに泳ぐ。文書として「正しい」のに「未完成」に見える。ビジネスの場では、それ自体が一つの欠陥になる。

逆方向、つまり日本語から英語に訳す場合には、鏡写しの問題が起きる。日本語から英語は膨張し、しかもその伸び方は不均一だ。コンパクトな日本語の名詞句一つで済んでいた表現が、英語では6語のフレーズになり、元のセルに収まらなくなる。

欧州言語同士のペアだけでテストしているツールは、このどちらの失敗にも出会わない。欧州言語間の膨張・収縮は穏やかで、しかも対称的だからだ。

日本語に特有の、三つのOCR失敗パターン

縦書き。 小説、法律文書、多くの行政書類、そしてほとんどの新聞は、上から下へ、右から左へ組まれている。横書きを前提にしたOCRエンジンは、ここで「多少ずれた」程度の結果を返すわけではない——列を縦に追う代わりに横断して読んでしまうため、堂々と、しかし完全に破綻した出力を返す。さらに厄介なことに、一つのページの中で縦書きと横書きが混在する日本語文書は珍しくない。縦書きの本文に、横書きの見出し・表・図版キャプションが組み合わさっている、というように。

ふりがな。 漢字の読み方を示すために、その上や脇に小さく添えられる表音文字だ。OCRはこれを本文に取り込んで文字化けの原因にするか、完全に読み飛ばすかのどちらかになりやすい。教育教材、法律文書、児童書などでは、ふりがなを落とすことは、その文書が伝えようとしている情報そのものを削り取ることに等しい。

半角と全角の混在。 日本語には数字・ラテン文字・カタカナのそれぞれに半角と全角という二つの表記がある。2026と２０２６は、意味は同じでも文字コードとしては別物だ。正規化を行わないパイプラインは、日付・型番・価格の表記が文書内でバラバラになる出力を生み、検索や後工程でのバリデーションが黙って一致しなくなる。

これに加えて、日本語という言語そのものの難しさもある。単語と単語の間にスペースがないため、区切り方を一つ間違えるだけで、そのまま誤訳につながる。しかも見た目には何もおかしく見えない。

敬語は、正確性の問題である

日本語は、文法そのものに人間関係を書き込む言語だ。敬語——尊敬語・謙譲語・丁寧語——は、中立な文に後から付け足す飾りではない。文をどう組み立てるか、その都度迫られる選択であり、そこを誤ると文書の性質そのものが変わってしまう。

本来です・ます体で書くべき契約書が、だ・である体、あるいはそれ以上にくだけた文体で訳されてしまうと、日本のビジネスパーソンにとっては、友人とのLINEのような文体で書かれた契約書を読まされているのに近い。内容自体は正しいかもしれないが、その文書は使いものにならない。

この点で機械翻訳は大きく進歩した。それでも、肝心の情報——誰が誰に対して、どのような関係性のもとで書いているのか——にはまだアクセスできていない。使っているツールに敬語のレベルを指定するオプションがあるなら、必ず設定しておくこと。ない場合は、残りのページを信用する前に、まず冒頭の1ページをネイティブのレビュアーに確認してもらう必要がある。

もう一つ、隣接する落とし穴が会社名・個人名の扱いだ。日本のビジネス文書では、様・御中・部長といった敬称や役職が名前の一部として機能している。これを削ってしまったり誤訳したりすることは、まさにそれが重要な意味を持つはずの文書において、目に見える形の失礼になる。

重要なのはパワーポイントだ

実務上、日本語の文書翻訳で最も需要が大きいファイル形式はプレゼンテーション資料——いわゆる「パワポ」だ。そして皮肉なことに、ほとんどの翻訳ツールが最も苦手とするのもこの形式である。

理由は構造的なものだ。テキストは段落のように流れ込むのではなく、サイズの決まったボックスの中に固定されている。スピーカーノートは別のテキストレイヤーとして扱われ、しばしば黙って抜け落ちる。図解は個々のテキストフレームの集合体であり、その読み順は文章のような一直線ではなく空間的な配置に依存する。グラフは埋め込みオブジェクトの中にテキストを抱えている。そして日本語への翻訳で文字数が縮むと、ボックスの中身が目に見えてスカスカになる——段落の中でなら気づかれない余白も、スライドの上では会議室にいる全員に一目でわかってしまう。

エクセルにも並行する問題がある。文字列を参照する数式、文字数に上限のあるシート名、そして翻訳後の文字列がVLOOKUPなどの検索を黙って壊してしまうセル——といった具合だ。

PDFの翻訳品質が高いからといって、パワポの扱いが同じレベルだとは限らない。実際に自分が送るファイル形式でテストすること。

使える成果物にたどり着くには

テキストレイヤーをすでに持つデジタルなソースファイル——PDF、DOCX、XLSX、PPTXなど——を扱う場合は、テキストだけを抜き出して別々に訳すのではなく、フォーマットを保ったまま翻訳できるツールを使うべきだ。ドキュ翻訳は、日本語を数ある対象言語の一つとして扱うのではなく、これらのフォーマットと日本語出力そのものを軸に設計されたプロダクトだ。

スキャンや写真が原本の場合は、その前段にOCRの工程が入る。縦書きやふりがなの問題が発生するのは、まさにこの段階だ。Scanned.toはレイアウトを保ったままスキャン文書を翻訳するために作られており、文字だけを取り出してその先は自分で処理したいという場合は、より軽量なScanRead.aiが向いている。

どちらのルートを選ぶにせよ、確認しておくべきチェックリストは短く、それだけの価値がある。

• 翻訳後のスライドや文書を実寸で開く。スカスカに見えたり、詰まりすぎていたり、見切れている箇所はないか。
• 1ページ目で敬語のレベルを確認する。文書の目的と一致しているか。
• 数字・日付・識別番号を確認する。半角と全角の不一致は、まずここに現れる。
• スピーカーノート・脚注・図版キャプションが訳文に残っているか確認する。
• 縦書きの原本であれば、2段落ほど実際に読んで順序が正しいか確認する。列の順番が入れ替わっていても文章としては滑らかに読めてしまう——それでいて、中身は完全に間違っている。

<!-- linnk:faq -->

よくある質問

翻訳した日本語のパワポが、なぜスカスカに見えるのか？

日本語は英語に対して縮む傾向があり、その差はしばしば大きくなります。英語の分量に合わせて作られたテキストボックスは、翻訳後に中身が足りない状態になります。これは翻訳の問題というよりレイアウトの問題であり、通常は翻訳後にボックスのサイズやバランスを調整する工程が必要になります。

OCRは縦書きの日本語を正しく読み取れますか？

対応できるエンジンもあれば、対応できないエンジンも多くあります。そして、そのどちらなのかを事前に教えてくれるツールはほとんどありません。横書きを前提にしたエンジンは縦書き文書の列を横断して読んでしまい、一見自然だが実際には完全に破綻した出力を返します。大量のバッチ処理をパイプラインに任せる前に、縦書きだと分かっているページで一度テストしておくべきです。

敬語とは何で、なぜ翻訳品質に影響するのですか？

敬語は、書き手と読み手の関係性を文法そのものに組み込む、日本語の敬称レベルの体系です。これは任意で選べる丁寧さではありません。誤ったレベルの敬語を選ぶと、一文一文は正確であっても、ビジネス文書や法律文書として使いものにならなくなります。

日本語への翻訳は、汎用ツールと日本語特化ツールのどちらを使うべきですか？

書式が重要でない一回限りの文書であれば、汎用ツールで十分です。レイアウト・敬語・フォーマットの再現性が重要になるビジネス文書——プレゼン資料、契約書、表計算ファイルなど——では、日本語向けに作られたプロダクトのほうが、ここまで挙げてきた失敗パターンを例外処理ではなく前提として扱っています。

<!-- /linnk:faq -->