DocuTranslate レビュー: LLM で PDF・Office・字幕を横断翻訳する Python ツール

DocuTranslate が埋めるのは「形式ごとに翻訳ツールを探す」手間

翻訳したい対象はたいてい 1 つの形式に収まらない。論文は pdf、原稿は docx、用語集は xlsx、字幕は srt、設定ファイルは json という具合に散らばる。それぞれに別のツールを当てると、API キーの管理も用語の統一も別々になる。DocuTranslate はこの入口を 1 つにまとめる。README は対応形式として pdf、docx、xlsx、md、txt、json、epub、srt、ass を挙げ、翻訳エンジンは利用者が指定した AI プラットフォームの API キーで動く。つまり翻訳そのものを提供するのではなく、ファイル形式ごとの抽出と再構成を肩代わりし、翻訳の実処理は外部の LLM に投げる。利用者層は README の構成から見て、コマンドラインに抵抗がない個人や小規模チーム、そして MCP 経由でエージェントから呼び出したい開発者である。

PDF は Markdown に変換されてから翻訳される

このツールの処理経路で最も重要なのは PDF の扱いだ。README は「When translating pdf, it is first converted to markdown」と述べ、その結果について「This will lose the original layout」と明示している。つまり PDF はページ画像や座標を保ったまま翻訳されるのではなく、テキスト構造として抽出され、翻訳後に何らかの形で再構成される。レイアウトを厳密に維持したい利用者には向かない、と README 自身が注意を促している。

変換エンジンには mineru が使われる。README によれば mineru はオンラインでもローカルでもデプロイでき、論文によく現れる表、数式、コードの認識に対応する。エンジンの選択は DOCUTRANSLATE_CONVERT_ENGINE で指定し、オンラインの MinerU を使う場合は DOCUTRANSLATE_MINERU_TOKEN が必要になる。ここは処理の質を左右する設定であり、数式や表が多い文書を扱うなら mineru 前提で考えるべき箇所だ。

一方、docx と xlsx については README が「maintaining original formatting」と書いており、PDF とは扱いが異なる。同じツールでも形式によって保証されるものが違う。

用語集の自動生成と jsonpath-ng による JSON 翻訳

長い文書を翻訳すると、同じ専門用語が章ごとに別の訳語になる問題が起きる。DocuTranslate は用語集の自動生成に対応し、用語の揺れを抑える仕組みを備える。用語集を人手で先に作るのではなく、翻訳の過程で生成させる方向の機能だ。

JSON の扱いも特徴的で、jsonpath-ng の構文でパスを指定し、その値だけを翻訳対象にできる。UI の文言ファイルのように、キーはそのままにして値だけを差し替えたい場面では、ファイル全体を LLM に渡すより事故が少ない。

翻訳の並列度は DOCUTRANSLATE_CONCURRENT で制御し、既定値は 10 と README にある。API 側のレート制限に当たるなら、この数値を下げるのが最初に試す調整になる。

起動方法: pip、uv、docker、そして Web UI

導入経路は複数用意されている。pip なら pip install docutranslate、MCP 拡張も入れるなら pip install docutranslate[mcp] を実行し、その後 docutranslate -i で起動する。uv を使う場合は uv init の後に uv add docutranslate、実行は uv run --no-dev docutranslate -i となる。ソースからなら git clone して uv sync --no-dev を流す。docker は docker run -d -p 8010:8010 xunbu/docutranslate:latest の一発で、タグを指定すれば v1.5.4 のような固定もできる。

起動オプションは実務に直結するものが揃っている。docutranslate -i --host 0.0.0.0 で LAN 内の他端末からアクセスでき、-p 8081 でポートを変え、--cors で既定の CORS 設定を有効にする。Web UI は既定で http://127.0.0.1:8010、API ドキュメントは /docs にある。--with-mcp を付けると MCP の SSE エンドポイントが同一ポートで立ち上がる。

MCP サーバー単体で使うなら docutranslate --mcp（stdio）、--transport sse、--transport streamable-http を選ぶ。SSE の場合は --mcp-host と --mcp-port で待ち受けを指定する。

環境変数だけで動かす MCP 構成

エージェントから呼び出す場合、設定は環境変数に集約される。必須は DOCUTRANSLATE_API_KEY、DOCUTRANSLATE_BASE_URL、DOCUTRANSLATE_MODEL_ID の 3 つ。任意で DOCUTRANSLATE_TO_LANG（既定は中国語）、DOCUTRANSLATE_CONCURRENT（既定 10）、DOCUTRANSLATE_CONVERT_ENGINE、DOCUTRANSLATE_MINERU_TOKEN を指定する。

README の uvx 構成例では、インストールなしで uvx --from "docutranslate[mcp]" docutranslate --mcp を起動し、env ブロックに API キー、ベース URL、モデル ID、翻訳先言語、並列数、変換エンジン、MinerU トークンを並べている。BASE_URL を差し替えれば OpenAI 互換の任意のエンドポイントに向けられる構造だ。SSE モードでは先に docutranslate --mcp --transport sse --mcp-host 127.0.0.1 --mcp-port 8000 を起動し、クライアント側に http://127.0.0.1:8000/mcp/sse を登録する。

注意点として、翻訳品質はモデル ID とプロンプトに依存する。README はカスタムプロンプトに対応すると書くが、具体的なプロンプト例は提示された範囲では確認できない。

向かないケース: レイアウト厳守、doc・xls、オフライン運用

最も明確な限界は PDF のレイアウトだ。README は pdf が Markdown に変換されることを太字で示し、レイアウト要件が厳しい利用者への注意を書いている。請求書や契約書のように、罫線や配置そのものが意味を持つ PDF をこのツールに通すと、得られるのは内容であって版面ではない。この用途では PDF を直接扱う翻訳サービスや、版面解析に特化したツールの方が適する。

形式の穴も明示されている。docx と xlsx は対応するが、doc と xls は現時点で未対応と README が書いている。古い Office 形式が混在する環境では、事前に変換が必要になる。

もう一点、翻訳の実処理は外部の AI プラットフォームに送られる。機密文書を扱う場合、どのエンドポイントに何を送るかを DOCUTRANSLATE_BASE_URL と DOCUTRANSLATE_MODEL_ID で把握しておく必要がある。完全なオフライン翻訳を期待するなら、この設計は前提が違う。

比較対象としての Pandoc と LLM 翻訳の役割分担

近い目的を持つ道具に Pandoc がある。Pandoc は形式変換に特化し、pdf、docx、epub、md などの間で文書構造を写し替える。ただし翻訳そのものは行わない。DocuTranslate は変換と翻訳を 1 本の流れにまとめ、変換の途中で LLM にテキストを渡す。

この違いは障害時の切り分けに現れる。Pandoc なら変換だけを検証し、翻訳は別のスクリプトで確認できる。DocuTranslate では PDF の抽出品質と LLM の訳文品質が同じ結果に混ざるため、出力が崩れたときにどちらが原因かを切り分けにくい。数式や表の認識に mineru を使う構成は、この混ざりを減らすための工夫だと読める。

逆に、字幕の srt や ass、設定の json のように構造が単純な形式では、変換と翻訳を分ける利点は小さい。1 つのコマンドで済む方が運用は軽い。

ライセンスと更新の追い方

ライセンスは MPL-2.0。ファイル単位のコピーレフトで、改変したファイルのソースを公開する義務が及ぶ範囲が MPL の対象ファイルに限定される。MPL-2.0 の条文解釈は個別事情で変わるため、社内配布や再頒布を伴う場合は法務確認が要る。ここでは条文の内容そのものには踏み込まない。

更新は活発で、提示された範囲では v1.7.7 が 2026-06-25、v1.7.8 が 2026-07-10、v1.7.9 が 2026-09-04 と、およそ 1 か月から 2 か月の間隔でリリースされている。docker で固定するなら xunbu/docutranslate:v1.5.4 のようにタグを指定し、latest を追う運用とは分けた方がよい。Python は 3.11 以上が要件で、これは README のバッジに示されている。

保守コストの実体はコードではなく API 側にある。LLM のモデル名や料金、レート制限は外部要因で変わるため、DOCUTRANSLATE_MODEL_ID と DOCUTRANSLATE_CONCURRENT の見直しが定期的に発生する。ツール自体の更新頻度より、接続先の変化の方が運用に効いてくる。

編集部の結論

レイアウトより内容の取り出しを優先する読者、たとえば論文や小説、字幕の翻訳を自前の API キーで回したい個人や小規模チームに向く。逆に、組版を保ったままの PDF や、doc・xls 形式のファイルを扱いたい場合は対象外で、README も doc と xls は未対応と明記している。導入前に確認すべきは 3 点で、第一に対象ファイルが pdf かどうか（pdf は Markdown 変換を経るため表や数式以外のレイアウトは失われる）、第二に DOCUTRANSLATE_CONVERT_ENGINE を mineru にするなら DOCUTRANSLATE_MINERU_TOKEN を用意できるか、第三に MPL-2.0 の下で配布物をどう扱うかである。

公式情報源

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. xunbu/docutranslate on GitHub