TranslateBooksWithLLMs レビュー: 書籍翻訳をLLMで回すデスクトップアプリの実力と境界

誰の何を解決するのか: 長編を分割して訳すという地味な難所

LLMに本を訳させようとすると、最初に必ず壁に当たる。コンテキスト長である。千ページの小説をそのままプロンプトに載せることはできないし、章ごとに切って別々に投げれば、前の章で決めた人名表記や語り口が次の章で崩れる。TranslateBooksWithLLMs（以下TBL）が狙っているのはこの部分だ。READMEは「No size limit」と書き、単一ページから千ページ級の小説まで扱えるとしている。対象はEPUB、SRT、DOCX、TXTの4形式で、字幕のタイムコードやEPUBのスタイルを保つことを売りにしている。想定読者は、翻訳を仕事にするプロというより、個人で読みたい本や自分が持っている字幕をまとめて訳したい人、あるいは小規模なローカライズ作業を回したい人だ。GUIアプリとして配布されており、コマンドラインからも同じ処理を呼べる。

チャンク分割とコンテキスト保持: READMEが説明する処理の流れ

READMEによれば、TBLは文書を「intelligent chunking system」で分割し、セグメント間のコンテキストを保持しながら処理する。ここが単純な分割スクリプトとの差になる。前のチャンクで使った用語や文体を次のチャンクに引き継がないと、長編では訳語が揺れる。TBLはこれに加えて、用語集（glossary）と文体プリセット（style preset）という2つの補助情報を翻訳そのものとは別に扱う。プリセットはサンプル書籍から抽出するか手書きでき、全チャンクに適用される。用語集やプリセットを用意していない場合は、ドロップダウンでAutoを選ぶと、翻訳開始前にLLM呼び出しを1回ずつ行って文書から自動生成する。READMEはこの生成結果を保存しないと明記している。ジョブごとに毎回作り直す設計だ。処理の中断に備えてチェックポイントを自動保存し、続きから再開できる点も、長時間ジョブを回す前提の作りと言える。

動かし方: 配布バイナリとソースからの2経路

最も短い経路はリリースのzipを展開して実行するものだ。Windowsは `TranslateBook.exe`、macOSは `./TranslateBook` を起動し、ブラウザで http://localhost:5000 を開く。初回起動で `TranslateBook_Data` フォルダが作られ、設定がそこに入る。macOSでは初回にシステム設定のプライバシーとセキュリティから「このまま開く」を選ぶ必要があるとREADMEが注記している。ソースから入れる場合はPython 3.8+、Ollama、Gitが必要で、`git clone` のあと `ollama pull qwen3:14b` でモデルを取得し、Windowsは `start.bat`、Mac/Linuxは `chmod +x start.sh && ./start.sh` を実行する。CLIは `python translate.py -i book.epub -sl English -tl Japanese` のように呼び、プロバイダを変えるときは `--provider openrouter --openrouter_api_key YOUR_KEY -m anthropic/claude-sonnet-4` のようにキーとモデルを渡す。プロバイダごとにキーの引数名が分かれており、`--openai_api_key`、`--gemini_api_key`、`--mistral_api_key`、`--deepseek_api_key`、`--poe_api_key`、`--nim_api_key` が用意されている。Ollamaが繋がらないときは `curl http://localhost:11434/api/tags` で確認し、モデルが見つからないときは `ollama list` の結果を見てから `ollama pull model-name` を実行する、という切り分けがREADMEのトラブルシューティング表に載っている。

プロバイダ選択という設計判断: 翻訳エンジンを外に持たない

TBLは自前の翻訳モデルを持たない。Ollama、OpenAI互換サーバ（llama.cpp、LM Studio、vLLM、LocalAIなど）、OpenAI、Gemini、Mistral、DeepSeek、Poe、OpenRouter、NVIDIA NIMをバックエンドとして選ぶ構成だ。この設計の利点は、モデルの世代交代に追従しやすいことと、機密文書をローカルで完結させられることにある。欠点は、品質が完全に選んだモデル次第になる点だ。ツール側ができるのはチャンク設計、用語集、文体プリセット、リトライまでで、訳文の良し悪しそのものはモデルが決める。READMEがwikiへのリンクを「Translation Quality Benchmarks」として冒頭近くに置いているのは、この責任分界を作者自身が認識している表れだろう。どのモデルを選ぶかは利用者の仕事であり、TBLはその選択肢を広く用意する側に徹している。

書式保持の約束と、その約束が効かない場面

READMEはEPUBの書式、スタイル、構造がそのまま出てくるとし、SRTのタイムコードも同期が保たれると書いている。タグ、タイムスタンプ、書式の細部が保たれるという主張だ。ただしこれはREADMEの記述であって、こちらの環境で検証した結果ではない。判断材料としては、自分の手元のファイルで試すのが確実になる。特に注意したいのは、EPUBやDOCXの中には翻訳対象の本文以外に脚注、図表キャプション、索引、奥付などが混在していることだ。チャンク分割がこれらをどう扱うかはREADMEからは読み取れない。またSRTの場合、字幕は1行あたりの文字数制約が厳しく、訳文が長くなると表示時間に収まらないことがある。タイムコードが保たれても、テキスト量が増えれば読めない字幕になる。TBLはタイミングの調整までは約束していない。字幕の実運用を考えるなら、出力後に表示時間と文字数の検査を別途入れる必要がある。

Auto用語集のコストと、向かないユースケース

Autoモードは便利に見えるが、翻訳開始前にLLM呼び出しが2回（用語集と文体プリセット）走る。長編を何度も訳し直す使い方では、この分は毎回上乗せになる。逆に、シリーズ物や同一著者の作品を続けて訳すなら、一度プリセットを抽出して保存し、以後はそれを指定するほうが安定するし呼び出しも減る。READMEはAutoの結果を保存しないと明記しているので、再利用したいなら手動でプリセットを作る側に寄せる判断になる。向かないケースもはっきりしている。第一に、訳文の一文一文を人間が確認しながら進める校正中心の業務。TBLはバッチ処理の道具であり、対話的に訳語を確定していくUIではない。第二に、APIキーを外部に出せない統制環境。クラウドプロバイダを使う限り、原文はその事業者に送られる。ローカルOllamaを選べばこの問題は消えるが、その場合は相応のGPUとモデル選定が前提になる。第三に、法的に厳格な翻訳が必要な契約書や公文書。チャンク単位の翻訳は文書全体の法的整合性を保証しない。

代替手段との違い: 汎用LLMチャットとCATツールの間

比較対象として分かりやすいのは、原文をそのままChatGPTやClaudeのチャットに貼り付けて訳す方法だ。この方法は短い文書なら速いし、訳語の指示も対話で直せる。だが長編ではコンテキスト上限に当たるか、貼り付け作業そのものが破綻する。章ごとに分ければ今度は訳語の一貫性が崩れ、中断したら最初からやり直しになる。TBLはこの2点、つまり分割の自動化とチェックポイントによる再開を仕組みとして持っている。もう一つの比較対象は、翻訳メモリを備えたCATツールだ。CATツールは用語ベースと訳文メモリを資産として蓄積し、人間の訳者が確定した訳語を以後の文書で再利用する。TBLの用語集はLLMに渡すプロンプト上の指示であって、人間が確定した訳を強制する仕組みではない。この違いは、同じ用語を必ず同じ訳語で出したい場合に効いてくる。TBLは自動化と規模を取り、CATツールは統制と再現性を取る。用途が違う。

ライセンスと保守: AGPL-3.0が意味する範囲

TBLはAGPL-3.0で公開されている。AGPLはGPLに、ネットワーク越しに利用させる場合のソース開示義務を加えたライセンスだ。TBLはローカルで動くデスクトップアプリで、Web UIは http://localhost:5000 で待ち受ける。この構成をそのまま個人が使う分には、通常のGPL系ソフトと変わらない。問題になるのは、TBLを改変して社内や顧客向けにネットワークサービスとして提供する場合だ。AGPLの条件が及ぶ可能性がある。ここは法的判断なので、実際にそういう使い方をするなら法務に確認すべきで、この記事は法的助言ではない。保守の面では、リポジトリはアーカイブされておらず、直近のリリースは v1.5.10（2026-09-06）、その前が v1.5.9 と v1.5.8（ともに2026-08-24）で、短い間隔で版が上がっている。活発に見えるが、これはリリース日時の事実であって品質の証明ではない。依存先はLLMプロバイダのAPI仕様であり、そちらの変更で壊れる可能性は常にある。プロバイダを切り替えられる設計は、この種のリスクに対する実質的な保険になっている。

編集部の結論

長編のEPUBやSRTを、書式を壊さず一括で訳したい個人や小規模チームには向く。逆に、訳文の品質を人手で細かく制御したい商用出版のワークフローや、APIキーを外部に置けない環境、AGPL-3.0の条件を自社ポリシーで飲めない組織には勧められない。導入前に確認すべきは、自分の目標言語とモデルの組み合わせがwikiの翻訳品質ベンチマークでどう評価されているか、そしてCLIで `python translate.py -i book.epub -sl English -tl Japanese` を短いファイルで一度通し、出力EPUBの章構造とタグが保たれているかを自分の目で見ることだ。

公式情報源

1. hydropix/TranslateBooksWithLLMs on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases