AI による Drupal ページの自動翻訳

多言語のバックログには独特の匂いがあります。月曜に英語で公開し、ドイツ語は「今週中」と約束し、金曜には更新された47ページを前にして、「で… 本当のステータスはどうなっているんだ?」ときれいに答える方法がない、という状況です。

私は、チームがこれをより多くのプロセスを投入して解決しようとするのを見てきました。スプレッドシート、翻訳チケット、週次の同期ミーティング。誰かが200ページのヒーロー段落を編集するまではうまくいきます。そのあとは、また推測に逆戻りです。

私たちにとって最終的にうまくいったのは、翻訳を本番システムのように扱うことでした。追跡と統制のための TMGMT、cron 経由で自動的にジョブをトリガーする小さなカスタムモジュール、そしてバックグラウンドで動作し、チャンク分割によって大きなフィールドを扱える AI 翻訳ツールです。

この記事はマネージャーの視点です。成果、リスク、そして静かな混乱に陥らないためにチームに何を尋ねるべきか、です。

まず、「自動翻訳」が本当に意味すること(Drupal の観点で)

サイト全体を瞬時に5言語に変換する魔法のボタンを思い描いているなら、忘れてください。信頼できる版は、もっと遅く、もっと退屈です。

• 新規または更新されたコンテンツが検出される。
• 翻訳ジョブが作成され、追跡される。
• 作業がスケジュールに従ってバックグラウンドで実行される。
• 結果がレビュー工程に入る(そのリスクを選ぶなら自動承認)。
• 翻訳されたコンテンツが、あなたのルールを満たしたときに公開される。

この「ジョブ」という概念こそ、TMGMT が良い背骨である理由です。状態、追跡、ソース、翻訳プラグインを備えた「作業」として翻訳を管理するために作られています。

ですから、あなたが買うのは「AI 翻訳」ではありません。測定できるワークフローを買うのです。

cron とキューが実装の細部ではない理由

マネージャーはたいてい「cron」と聞くと「スケジュールされたタスク、結構」と考えます。しかし Drupal の自動 cron は、低トラフィックの状況ではずれ得るスケジュールで動作し、デフォルト設定ではユーザーリクエストに負荷を加えることがあります。

翻訳ジョブは重いものです。外部 API 呼び出し、リトライ、そして時には長いテキストを伴います。ですから信頼できるパターンはこうです。作業をキューに入れ、それから cron に制御された小分けで処理させる。

これをマネジメント用に訳すとこうなります。

• 編集者が翻訳を待たなくて済む。
• 誰かが長いページを公開したせいでサイトのレイテンシが急上昇しない。
• バックグラウンド時間を多く・少なく割り当てることで、スループットを調整できる。
• 障害が、実行全体を止めるのではなく、小さな作業単位に隔離される。

チームがこれを計画していなければ、あなたが手にするのは自動化ではありません。新しい障害モードです。

AI の部分:得られるもの、得られないもの

AI 翻訳ツールには、翻訳が使い捨てのスクリプトではなくジョブとワークフローを通じて管理され続けるよう、TMGMT 互換のアプローチを使います。

プロジェクトの観点では、プロバイダーの選択は人々が思う以上に重要です。それは後々の選択肢を与えてくれます。

• コストが変わったときにモデルを切り替えられる。
• ポリシーが求めるなら、機密コンテンツを別経路でルーティングできる。
• トーンのぶれを減らすために、言語ごとにプロンプトのスタイルを調整できる。
• 翻訳設定を、ハードコードされたロジックではなく設定として扱える。

しかし社内で過度に売り込まないでください。AI 翻訳は速く、驚くほど良いこともありますが、それでもガバナンスが必要です。レビューのワークフローには理由があって存在します。

大きな運用リスク:長い Body フィールド

これは、PM がたいてい最初のインシデントのあとにようやく知る部分です。

大きな Body フィールド(ドキュメント、ポリシーページ、埋め込みマークアップの多いページ)こそ、素朴な AI 翻訳が壊れる場所です。派手に失敗することもあります。より多いのは、静かに失敗することです。部分的な出力、一貫しない書式、あるいは、誰かが本番サイトで気づくまで通り抜けてしまう壊れた HTML です。

私たちの対処法は「より良いプロンプト」ではありません。エンジニアリングです。

• ユーザーリクエストの経路ではなく、バックグラウンドで翻訳する。
• 大きな Body の値を、実用的な範囲に収まるチャンクに分割する。
• 元の順序で再結合する。
• 1つの失敗がページ全体をブロックしないよう、チャンク単位でリトライする。

チャンク分割にはトレードオフがあります。チャンクをまたいで用語がぶれ得るのです。それは、言語ごとの軽い用語集やスタイルルールで緩和します。

カスタムモジュールの役割(そして、なぜそれが必要か)

TMGMT はワークフローエンジンですが、翻訳ジョブがいつ作成されるかを、なお何かが決めなければなりません。それがカスタムモジュールの役割です。

• コンテンツの変更を検出する。
• そのコンテンツタイプにどの言語が必要かを判断する。
• 翻訳ジョブを自動的に作成または更新する。
• cron が後で処理できるよう、作業をキューに投入する。

これにより、予測可能な運用リズムが得られます。また、翻訳を別個のプロジェクトの流れではなく、公開の衛生管理の一部にします。

より大規模なプログラムでは、明示的なルールが必要になります。どのコンテンツタイプが自動翻訳されるのか、どれがレビューを要するのか、そして軽微な編集と大幅な書き直しで何が起こるのか。ルールがなければ、自動化は「予期せぬ挙動」に変わります。

何を測るか(それが機能しているか分かるように)

成功を定義しなければ、チームがあなたの代わりに定義します。そしてその定義があなたの気に入らないかもしれません。実際に成果に対応する指標はこちらです。

• 翻訳レイテンシ: コンテンツの公開/更新から、翻訳がレビュー可能になるまでの中央値。
• バックログのサイズ: 「要翻訳」または「要レビュー」にある項目の数。
• 手直し率: AI の出力のあと、人間が翻訳を編集する頻度。
• 失敗率: 介入を要するリトライ、詰まったジョブ、書式の問題。

並行したダッシュボードを発明するのではなく、ジョブ追跡をレポーティングの面として使ってください。

ガバナンス:プロジェクトが成功するか、静かにあなたを恥じ入らせるか

自動翻訳への信頼を失う最速の方法は、法的にリスクのあるもの、あるいはブランドを傷つけるものを公開することです。自動化は被害範囲を広げます。

モジュールだけでなく、ポリシー上の決定が必要になります。

• どのコンテンツタイプが AI 翻訳を自動公開できるか?
• どれが必ずレビューを通らなければならないか?
• 製品名、法的な文言、規制対象の言語について、用語集の用語を誰が所有するか?
• モデルの更新がトーンを変えた場合の、ロールバック計画は何か?

ハイブリッドモデルが、しばしば健全な妥協点です。AI が量を担い、人間がリスクを担います。

編集チームを吹き飛ばさない展開計画

これを一度に全部やると、編集者は地面が動いたように感じます。より良い道があります。

構造が明確で、リスクの低い1つのコンテンツタイプから始めてください。ニュース記事、イベントページ、FAQ です。パイプラインを安定させます。それから、厄介なもの、つまり長文ページ、ドキュメント、書式の重いマーケティングページへと広げます。

また、cron をどう実行するかを早めに決めてください。信頼性とスループットは、チームが過小評価する形で納期に影響します。これは技術的な脚注ではありません。

これにゴーサインを出す前に、私が尋ねる問い

システムが機能しているとき、翻訳はバックグラウンドの雑音になります。それが目標です。

しかし、ここに居心地の悪い問いがあります。あなたはスピードを最適化しているのか、それとも確信を最適化しているのか? というのも、その答えが、自動公開するかどうか、レビューをどれだけ厳格にするか、どの言語から展開するか、そして用語管理にどれだけ投資するかを決めるからです。

どんな種類のサイトを運営しているのか(マーケティング中心、ドキュメント中心、あるいは混在)、そしてスコープに何言語あるのかを教えていただければ、1つのワークフローが誰にでも合うふりをするのではなく、リスクプロファイルに合った展開アプローチを提案できます。

市場で最高の Drupal 開発会社をお探しですか? たった今、見つかりました。

私たちは、妥協なく、速く、安全で、スケーラブルなプラットフォームを提供するために作られた、第1位の Drupal 特化型デジタルエージェンシーです。新規構築やリデザインから、移行や長期サポートまで、私たちの Drupal エキスパートが、ブティック水準のきめ細やかさでエンタープライズ級の成果を届けます。

今日、ぜひご相談ください。あなたの Drupal ロードマップを、高いパフォーマンスの現実に変えましょう。