長文や多言語一括翻訳も安定稼働（連載 5/5・最終回）分割翻訳パイプライン & タイムアウト調整

AITranslator v1.5.0 の連載第 5 回・最終回です。今回は目立たないものの運用上の効果が大きい 2 つの改善、分割翻訳パイプライン と LLM タイムアウトの環境変数化 について取り上げます。

v1.4 までの課題

v1.4 までは、翻訳の実行は 1 回の HTTP リクエストで完結する構造でした。

「翻訳を作成」ボタンを押す → サーバ側で全フィールドを順番に LLM で翻訳 → すべて完了したら翻訳先コンテンツを保存し、レスポンスを返す、という流れです。

シンプルで分かりやすい構造ですが、運用するうちにいくつかの課題が見えてきました。

• 長い記事でタイムアウトに引っかかる: 本文が長く LLM の応答に時間がかかると、Apache の ProxyTimeout や Nginx の proxy_read_timeout などのインフラ側タイムアウトに先に切られてしまうことがありました
• 多言語一括翻訳に時間がかかる: 「全ての言語に翻訳」で 4〜5 言語を一括処理すると、5 分以上かかることもあり、ブラウザ側でも完了を見通しにくい状態でした
• 進捗が見えない: 翻訳中は画面が静止しているように見え、処理状況が分かりませんでした

特にタイムアウトの問題は、翻訳設定によって発生する場合としない場合があり、再現性のある不具合として扱いづらいものでした。

分割翻訳パイプライン

v1.5.0 では、翻訳の実行を 3 段階に分割 しました。

1. prepare: 翻訳プランを作成し、翻訳先のドラフトを作成する
2. translate_field × N: フィールドを 1 つずつ翻訳し、ドラフトに書き込む
3. finalize: Placement や convert_breaks などの後処理を行い、ドラフトを確定する

ブラウザ側の JavaScript が、この 3 段階を順番に HTTP リクエストとして送ります。1 回のリクエストで処理されるのは「1 フィールド分の翻訳」だけになったため、リクエスト 1 つあたりの所要時間が大幅に短くなりました。

これにより、インフラ側のタイムアウトに引っかかりにくくなり、リクエストが小刻みになったことで進捗表示も自然に実現できるようになりました。

翻訳ウィジェットには「翻訳中 2/5: 本文」のようなフィールド単位の進捗が表示されます。「全ての言語に翻訳」モードでは「言語 1/4 (日本語→英語): 翻訳中 2/5: 本文」のように、外側の言語ループの進捗も表示されます。

進捗が見えると体感は大きく変わります。残りの処理量が分かれば待ちやすくなりますし、何の表示もないまま待たされる状態に比べて、安心して完了を待てます。

翻訳が途中で止まった場合

分割パイプラインは「1 リクエストでまとめて処理」する方式とは異なり、途中で止まる可能性があります。たとえば次のようなケースです。

• ブラウザを閉じた
• ネットワークが切れた
• 個別フィールドの翻訳が失敗した（LLM API の制限など）

途中で止まった場合、それまでに翻訳されたフィールドだけが入った「下書き状態」の翻訳先コンテンツが残ります。公開状態は常に「下書き」で作成されるため、翻訳が途中のコンテンツがサイト上に表示されることはありません。

再開したい場合は、同じ翻訳ボタンをもう一度押すだけです。AITranslator は既存の下書きを検出し、「上書きしますか？」のモーダルを表示します。OK を押せば、残りのフィールドも含めて再実行されます。

破棄したい場合は、翻訳先サイトのコンテンツ一覧から手動で削除してください。

全フィールド失敗時の自動破棄

「全フィールドの翻訳に失敗したものの、ドラフトだけは残る」という状態は、混乱を招きやすいものです。v1.5.0 では、全フィールドが失敗または skip された場合、AITranslator がフロントエンドから rollback リクエストを送り、新規作成された翻訳先ドラフトを自動的に破棄 します。

対象は新規作成のドラフトのみで、既存の翻訳先を上書きするモードでは rollback しません。上書きモードでは既存の値が変更されてしまうため、自動巻き戻しを安全に行えないためです。

LLM タイムアウトの環境変数化

もう 1 つの改善が、LLM への HTTP リクエストタイムアウトを柔軟に設定できるようになったことです。

これまではプロバイダ実装の中にハードコードされていたタイムアウト値を、v1.5.0 では次の優先順位で外部から指定できるようにしました。

範囲は 30〜1800 秒です。範囲外を指定した場合は、警告ログを残してデフォルトにフォールバックします。

適切な値の目安

デフォルトの 300 秒（5 分）は、通常の翻訳タスクであれば十分です。ただし、次のようなケースでは延長を検討してください。

• 数万字を超える長文記事の翻訳
• カスタムプロンプトで複雑な変換ルールを設定している
• LLM プロバイダ側のレスポンスがそもそも遅い

逆に、「タイムアウトに達する前にプロバイダ側のエラーレスポンスを早く受け取りたい」という場合は、60〜90 秒程度の短めの値も選択肢になります。

設定方法の使い分け

3 通りの設定方法は、次のように使い分けるとよいでしょう。

• 環境変数: テスト環境で一時的に変更したいとき。シェルから素早く設定できます
• mt-config.cgi: 本番運用の標準値として固定したいとき
• プラグインシステム設定: 非エンジニアの管理者にも調整できるようにしたいとき

3 つすべてを設定した場合は、優先順位の高い環境変数が適用されます。運用ルールを決めたうえでご利用ください。

全言語一括翻訳の挙動変更

「全ての言語に翻訳」チェックボックスの挙動も、あわせて整理しました。

v1.4 までは、同じターゲット言語の翻訳設定が複数ある場合、最初の 1 つだけが実行されていました（重複排除の意図によるものです）。

v1.5.0 では、すべての翻訳設定が順次実行される ようになっています。たとえば次のような構成です。

• 日本語→英語（同じサイト）
• 日本語→英語（別サイト A）
• 日本語→英語（別サイト B）

これら 3 つすべてが順番に翻訳されるため、「同じ言語だが翻訳先サイトが異なる」運用にも対応できるようになりました。

まとめ

v1.5.0 の分割翻訳パイプラインと LLM タイムアウト調整は、目立たないものの運用上の効果が大きい改善です。

1. 翻訳実行を 3 段階に分割し、インフラ側のタイムアウトに引っかかりにくく
2. フィールド単位の進捗表示で、待ち時間の見通しを改善
3. 失敗時は自動 rollback で、翻訳途中のドラフトを残さない
4. LLM タイムアウトを環境変数・mt-config・プラグイン設定の 3 通りで調整可能
5. 全言語一括翻訳で、すべての設定が順次実行されるように

連載を終えて

5 回にわたり、AITranslator v1.5.0 の機能をご紹介しました。

v1.5.0 は、v1.x のなかでも特に大きな変更を含むリリースになりました。サイト間翻訳・多言語サイト運用の実用度が大きく向上したと考えています。

実際にお試しいただき、「ここが分かりにくい」「こうした機能も欲しい」といったご意見がありましたら、ぜひフィードバックをお寄せください。

• 製品ページ: AITranslator
• リリースノート: AITranslator v1.5.0

ここまでお読みいただき、ありがとうございました。