AI論文翻訳の実態：本当に使えるツールの見極め方（2026年版）

By Linnk Research Team | June 2026 | 11 min read

この記事のポイント

学術論文は一般的な文書とは根本的に異なる。数式・番号付き引用・参考文献リスト・結果表・段組みレイアウト・図のキャプション・脚注・用語の一貫性——この8つが翻訳を通じて機能し続けなければならないが、ほとんどの翻訳ツールはそのどれにも対応して設計されていない。
汎用機械翻訳は本文を訳してそれ以外を壊す。レイアウト対応PDFツールは見た目の殻を保つが数式を崩し結果表を散文として扱う。論文対応AI翻訳は最新の層であり、引用グラフをネイティブに扱える唯一のアプローチだ。
どの翻訳ツールでも最初に確認すべき一点：引用グラフが生き残るか。番号付き引用は番号のまま残る必要がある。参考文献中の著者名は翻訳されてはいけない。第1節の定義と第14節での参照の対応関係が壊れてはいけない。
用途で使い分けること。個人での閲覧なら多少の欠落は許容できる。自分の論文で引用するなら参考文献の正確さが必須。機関保存用なら原文と照合できるレイアウト再現性が求められる。
文献調査エージェントが複数言語をまたいで論文を読む動きが始まっている。現時点では計算生物学やML研究など限られた領域のアーリーアダプターが中心だが、方向性は定まっている——次世代の研究ツールは、言語間の処理を呼び出せるAPIとして前提にしている。

論文は「文書」ではない

ほとんどの翻訳ツールは、社内メモのような文書——段落が並び、見出しがあり、ときどき表が入る——を想定して設計されている。そこに研究論文を投入すると、ツールは誠実に処理しようとするが、読み始めた途端に問題が見えてくる。数式が消えている。番号付き引用が参照を失っている。参考文献リストの著者名が半分翻訳されている。行7に「0.847 ± 0.012」と書かれていた結果表が、いつの間にか翻訳言語の散文になっている。

これは特定ツールのバグではない。論文をメモとして扱ったときの予測可能な失敗だ。論文は構造化された人工物である。引用グラフがあり、意味を担うレイアウトがあり、何が翻訳されるべきか（本文）と何が絶対に翻訳されてはならないか（ギリシャ文字、数式、数値結果、参考文献の著者名）について暗黙の規則がある。その違いを知らないツールは、論文の形をした「何か」を出力する——それはもう論文ではない。

この記事は実践者向けのフィールドガイドだ。翻訳を通じて機能し続けなければならない8つの要素、現在使われている3つのアプローチとそれぞれの限界、そして「今週金曜日までに終わらせなければならない文献調査」に使う前に翻訳ツールをどうテストするか——を整理する。

生き残らなければならない8つの要素

ツールを評価する前に、自分が何を守ろうとしているかを知る必要がある。翻訳が壊しうる、論文の構造上不可欠な8つの要素を以下に示す。

数式。 LaTeX、MathML、画像埋め込み——論文はこの3種類すべてを含む。「the model uses $\alpha\cdot\beta$ ...」を「モデルはアルファにベータを掛けたものを使う」と変換したとき、その数式は消滅した。数式はそのままの形で通過しなければならない。
番号付き引用。 「As shown in [12], ...」は「[12]」のまま残る必要がある。著者年式（「(Tanaka et al., 2024)」）は参照可能な形を保たなければならない。引用番号がずれると、読者は主張を参考文献に辿れなくなる。
参考文献リスト。 著者名は翻訳しない。雑誌名は翻訳しない。号数やページ番号は翻訳しない。翻訳してよいのは引用のタイトルフィールドだけだが——そこも多くの場合すべきではない。文献を探す人は原題が必要だからだ。
結果表。 数値、単位、記号、統計表記（平均 ± 標準偏差、p値、信頼区間）を散文として再解釈してはならない。列ヘッダーは翻訳してよい。数値データのセルは翻訳してはならない。
段組みレイアウト。 学術誌の多くは2段組で掲載される。段の順序を無視した翻訳は、本来2本の並行する流れだったものを1本の連続したブロックとして出力する。
図のキャプション。 キャプションにはギリシャ文字、単位、略語、パネル参照（「(A)」「(B)」）が含まれることが多い。キャプションの文章は翻訳する。中に含まれる参照は翻訳しない。
脚注。 脚注は本文中の特定の語に紐付いている。本文が伸び縮みする翻訳では、脚注がアンカーから切り離されて宙に浮く番号になることがある。
用語の一貫性。 40ページの論文には「モデル」という語が280回登場するかもしれない。セクションごとに別の訳語が当てられると、個々の文が正しくても論文全体が標的言語で支離滅裂になる。

汎用ツールで翻訳した場合、これらのうち少なくとも3つは機能しなくなる。問うべき問いは「翻訳は成功したか？」ではない——「8つのうちどれが保たれたか、それは自分の作業目的に足りるか？」だ。

現在使われている3つのアプローチ

汎用機械翻訳

最も多くの人が選ぶデフォルト。論文を翻訳ツールに貼り付けて、目的言語の本文を受け取る。Google翻訳、DeepL、ブラウザ内翻訳機能、PDFアップロード付きの汎用AIチャット。安く、速く、本文の品質は驚くほど良いことも多い。

保たれるもの： 本文。それだけ。

壊れるもの： 数式がテキストとしてトークン化されて部分的に翻訳される。引用が予測不能な形で崩れる。参考文献の著者名が翻訳されることがある。結果表が行ごとに段落として読まれる。段組み論文は段の順序を失う。脚注がアンカーから切れる。用語が数ページごとにずれる。

このツールが適切な場面： 素早い内容把握。外国語論文が精読する価値があるかを確認したい、引用する必要はない、翻訳を他者と共有しない——という場合。出力は自分の目だけのため。

フォーマット対応PDFトランスレーター

PDFを視覚的なレイアウトを保ちながら翻訳するために設計されたツール群。OCR（多くはビジョンAIベース）で論文を構造化文書として読み取り、テキスト領域を翻訳してレイアウトを再描画する。DocTranslatorや類似サービスがここに入る。

保たれるもの： レイアウトの殻——段組みはほぼ段組みのまま、表は見た目上表のまま、図キャプションは図に付随したまま。

壊れるもの： 数式は元の数式の画像として再現されることが多い（これは機能する）が、最悪の場合はOCRと翻訳が混在した半端な出力になる（これは機能しない）。参考文献の扱いはツールによってまちまち——著者名を翻訳しないことを知っているものも、そうでないものもある。番号付き引用は通常生き残る。セクション間の相互参照は、翻訳中に本文が言い換えられると参照アンカーが一致しなくなることが多い。

このツールが適切な場面： 元の言語を読めない人に渡せる文書が必要なとき——会議、社内レビュー、翻訳アーカイブ。「見た目は原本に近く、目的言語で読める」を優先し、多少の参照崩れは許容できる場合。

論文対応AI翻訳

最新の層。基盤モデル駆動のシステムが論文を構造化された人工物として読み取る——セクション、引用パターン、数式領域、表の構造を認識し、各領域に適した翻訳ポリシーを適用する。本文は翻訳する。数値結果は翻訳しない。引用番号は残す。参考文献の著者名は残す。用語は文書全体で固定される。

保たれるもの： 適切に実装されていれば8つの要素すべて。引用グラフが生き残る。相互参照が解決する。論文全体がコンテキストに入った状態で翻訳が行われるため、長い文書でも用語の一貫性が維持される。

壊れるもの： 速度。これらのツールは汎用MTよりもページあたりの処理が遅い。コストも高い。品質は実装依存——「AI対応」を名乗るすべての翻訳ツールが謳い通りの機能を持っているわけではない。

このツールが適切な場面： 引用、引用、共有を伴うすべての作業。文献レビュー。自分の論文での引用。機関記録へのアーカイブ。引用グラフの保持が重要なあらゆる作業。

決定的なテスト：引用グラフは生き残るか

論文翻訳ツールを評価するとき、最も予測力の高い単一のテストは引用グラフが生き残るかどうかだ。候補ツールでこれを試してほしい。

30以上の番号付き引用を持つ論文を翻訳する。 翻訳版において、本文中のすべての「[12]」または「(Tanaka et al., 2024)」が参考文献リストの対応エントリと一致しているか確認する。引用のずれは最もコストの高い失敗モードだ。
結果表を含む論文を翻訳する。 数値セルが散文として再解釈されていないか確認する。「0.847 ± 0.012」が「八十四点七...」になっていたら、そのツールは定量的な作業には使えない。
数式を含む論文を翻訳する。 数式がソースと視覚的に同一かどうか確認する。LaTeX式がOCRと翻訳の混在として出力されていたら、そのツールは論文のために設計されていない証拠だ。
30ページを超える論文を翻訳する。 同じ専門用語が第2節と第7節で同じように翻訳されているか確認する。用語のドリフトは長文読解を壊す失敗モードだ。

ほとんどのツールはこれらのうち少なくとも1つで失敗する。使う価値があるツールは1つも失敗しない。

閲読・引用・保存：用途は3種類

求める翻訳の種類は、それをどう使うかによって決まる。

自分で読む。 汎用MTで十分なことが多い。その論文が精読する価値があるかを確かめようとしている。出力が不完全でもコストは低い——重要なことは結局ソース言語で確認するから。速さを優先する。
自分の論文で引用する。 論文対応翻訳、またはソースを慎重に直接読む。「田中ら（2024）は〜を見出した」と書くなら、その主張は実際の論文から来なければならない——断定を和らげていたり専門用語を誤訳していたりするかもしれない翻訳からではなく。翻訳は読むための補助手段であり、引用はソースから行う。
機関・法的目的での保存。 レイアウトの再現性が重要。翻訳版を受け取る次の人が、翻訳と原本を並べて構造が一致することを確認できる必要がある。論文対応翻訳またはフォーマット対応PDF翻訳を使い、ソースとの並行レビューを行う。

多くのチームが用途に対して誤った層を選んでいる。引用グレードの作業に汎用MTを使うのが最も多い間違いだ。カジュアルな閲読にフォーマット対応PDF翻訳を使うのが2番目に多い（必要のないレベルの再現性にコストをかけている）。

現場で使われるツール

短く、正直なマップ。ツールの動向は速いが、カテゴリーは安定している。

ツール	アプローチ	最適な用途	限界
Google翻訳 / DeepL（本文貼り付け）	汎用MT	素早い内容把握；精読する価値があるかの確認	数式・表・引用がある論文；引用目的の使用
汎用ChatGPT / Claude / GeminiへのPDFアップロード	長文コンテキストチャットMT	外国語論文への質問応答	成果物としての全文翻訳；引用グラフの保持
DocTranslatorなどのPDF翻訳ツール	フォーマット対応PDF翻訳	原本に近いレイアウトの翻訳文書の作成；大量翻訳	引用グラフの正確性；数式の扱い；長文での用語一貫性
Linnk ドキュメント翻訳	レイアウト保持付き論文対応AI翻訳	上記8つの要素を保つ必要がある研究論文・学術文書；スキャンPDFおよびデジタルPDFの両方に対応	Q&Aチャット（それだけ必要な場合はプラットフォームのサマライザー側を使う）

独立系のレビューとして、Research.com が学術執筆ソフトウェアと翻訳ツールのトラッキングを公開しており、部門単位での導入を検討する際の参考になる。

実務上の注意：Linnkのドキュメント翻訳には、コミットする前に自分の論文でツールが機能するか確認するための、透かしなし3ページプレビューのダウンロード機能がある。Linnkサブスクリプションひとつで翻訳ツールとサマライザー、マインドマップ出力、Research Copilot Q&Aが使えるようになる（Q&AはサマライザーサイドにあるのでTranslatorサイドではない）。ファイルは48時間後に自動削除されるため、未公開論文やプレプリントの取り扱い時に重要な点だ。

読者がエージェントである場合

文献調査エージェントは、論文翻訳ツールの先行的なユーザーだ。パターンは見えている：文献コーパス（領域特化インデックス、機関図書館、arXivコーパスなど）にアクセスできるエージェントが複数言語をまたいで論文を読み、要約し、ギャップを特定して仮説や関連文献を提案する。

これらのエージェントが機能するには、翻訳ステップが明確なインターフェースを持つ必要がある。具体的には：

構造化された出力。 エージェントにはパース可能な形式での翻訳が必要——レンダリングされたPDFではなく。引用参照が機械可読なスパンとして保持されたMarkdownまたは構造化HTML（視覚的に整形された上付き文字ではなく）。
呼び出せるインターフェース。 WebのUIはエージェントには機能しない。論文を受け取って翻訳をプログラマティックに返すAPIまたはCLIが最低限の要件だ。
ソース根拠付き参照。 エージェントが後から翻訳された論文の主張を引用するとき、翻訳版ではなく元の言語の論文の元の箇所に遡れる必要がある。引用はソースに紐付けられる。
再帰的な処理が可能な成果物。 エージェントは「第4節だけ翻訳して」と再度尋ねられるべきだ。ファイル全体を再アップロードせずに。ほとんどのコンシューマー向け翻訳ツールはこれをサポートしていない。

正直な注意：2026年時点でこれはアーリーアダプターの領域だ。主流の文献調査作業はまだ人間主導だ。しかし確立しつつある規律もある——初期採用者の計算生物学ラボ、ML研究グループ、一部の金融調査デスクが今日すでにこのループを動かしている。次の2年間を生き残る翻訳ツールは、人間の読者にもエージェントにも明確に対応できるものだ。

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

論文翻訳が単独で存在することはほとんどない。

スキャン素材の前処理。 古い論文、アーカイブ誌、一部の専門出版物は画像PDFが主流だ。翻訳前にデジタル化する——scanned.toはモバイルスキャン先行での取り込みに対応；scanread.aiはサインアップ不要の素早いOCRに向いている。
長文要約との組み合わせ。 論文が翻訳された（または一度のパスで言語をまたいで要約された）後、次のステップは通常、アウトライン・マインドマップ・ソース根拠付き引用の段落要約といった構造化された形で読むことだ。
仮説生成へのさらなる展開。 翻訳論文が仮説形成ステップへの複数インプットの一つになる研究ワークフローでは、引用グラフの保持が重要になる——その仮説はやがて元の論文に引用されて戻ってくるからだ。

同じ旅の異なる段階だ。

よくある質問

研究論文にGoogle翻訳を使えないのはなぜですか？

カジュアルな閲読には使えます。汎用MTは本文を訳してそれ以外を壊します——数式、引用、参考文献、表、段組みレイアウト。論文を引用したり、引用したり、翻訳版を共有したりするなら、壊れた部分の修正に翻訳で節約した以上の時間がかかります。

「PDF翻訳ツール」と「論文翻訳ツール」の違いは何ですか？

PDF翻訳ツールは視覚的なレイアウトを保持します——段組みは段組みのまま、表は表のまま。論文対応翻訳ツールはさらに引用グラフを保持します。番号付き引用は番号のまま残り、参考文献の著者名は翻訳されず、セクション間の相互参照が生き残ります。ほとんどのPDF翻訳ツールは論文対応ではありません。一部の論文対応翻訳ツール（Linnkなど）はスキャンおよび画像PDFにも対応しています。

数式は翻訳を通じて生き残りますか？

数式のエンコード方法によります。デジタルPDF内のLaTeXレンダリング済み数式は、適切に設計された翻訳ツールによってそのまま通過させることができます。画像埋め込みの数式（スキャン論文や多くのジャーナル出力に多い）は、画像領域として認識されて翻訳されないようにする必要があります。OCRと翻訳が混在した出力が最も多い失敗モードです——論文のために設計されていないツールの証拠です。

翻訳ツールが引用グラフを保持しているかどうか確認するには？

30以上の番号付き引用を持つ論文を翻訳します。本文中のすべての「[12]」または「(著者, 年)」が翻訳版の参考文献と一致しているか確認します。また参考文献リスト自体が翻訳されていないか確認します（著者名・雑誌名・ページ番号はすべてそのまま残っていなければなりません）。両方をパスすれば、そのツールは引用グレードの作業に使える可能性が高いです。

論文を一つの言語に翻訳して、別の言語でフォローアップの質問ができますか？

はい、これが言語横断の要約ワークフローです。優れたツールは、ある言語の論文を受け取り、要約・アウトライン・マインドマップを別の言語で一度のパスで生成できます——翻訳を先に行う迂回は不要です。その要約の上でのQ&A（Research Copilotスタイル）により、読む言語でフォローアップの質問をしながら、検証のためにソースを元の言語のままにしておくことができます。

AIエージェントは文献調査ワークフローで論文翻訳ツールを使えますか？

現時点では主にアーリーアダプターです——計算生物学ラボ、ML研究グループ、エージェント型文献調査ループを運用する一部の金融調査デスク。このパターンには構造化された出力、呼び出せるAPIまたはCLI、ソース根拠付き参照、部分的な再翻訳を求める能力が必要です。主流への採用はもう1〜2年先です。方向性は定まっています——エージェントに対して自分を開かない研究ツールは、2027年末には時代遅れに見えるでしょう。

手書きメモや古いスキャン論文の翻訳はどうすればよいですか？

デジタル化から始めてください。scanned.toのようなスキャン専門ツールが、手書きや紙原稿を最初にきれいなデジタルテキストに変換します。クリーンな編集可能版ができたら、論文対応翻訳ツールで処理します。劣悪なスキャンから直接翻訳しようとすると、2つの失敗モード（OCRエラーと翻訳エラー）が積み重なり、予測不能な形で悪化します。

結論。 学術論文は構造化された人工物であり、一般的な文書ではない。翻訳を通じて生き残らなければならない8つの要素——数式、引用、参考文献、表、段組みレイアウト、図キャプション、脚注、用語の一貫性——は汎用MTでは保たれず、フォーマット対応PDFツールでも対応にばらつきがある。用途で層を選ぶこと。自分で読むだけなら多少の欠落は許容できる。引用や保存には、引用グラフを保持できる論文対応翻訳が必要だ。