多言語サイトは初回公開より、その後の料金・商品・営業時間・記事更新で差が出ます。自動化という言葉だけで契約せず、何を検知し、いつ翻訳し、誰が承認し、失敗時にどう戻すかを工程ごとに確認します。
更新の入口を一つにする
元CMS、商品管理、PDF、画像、外部予約など、変更が生まれる場所を一覧にします。担当者が翻訳チームへメールする方式だけに頼ると、細かな修正が抜けます。CMS公開、チケット、定期クロールのどれを正式な入口にするか決めます。
緊急情報は通常記事と同じ経路にしない方が安全です。営業時間や安全案内には優先ラベルを付け、翻訳版の一時非公開や共通告知へ切り替える手順を用意します。
自動検知・定期更新・完全同期を区別する
自動検知は変更を見つけること、定期更新は決めた間隔で反映すること、完全同期は原文と翻訳版を常時同じ状態へ保つことです。検知できても翻訳と承認を実行しなければ公開は変わりません。
契約時は、検知対象、実行頻度、新規文章の扱い、削除、失敗通知、手動再実行を確認します。『自動更新』の一語で工程を省略しないことが重要です。
差分にリスクを付けてレビュー経路を分ける
変更されたセグメントだけを抽出し、用語集・翻訳メモリ・AI翻訳へ渡します。価格、規約、安全、主要CTAは人の承認へ、低リスクな説明文は自動QAとサンプル確認へ分けます。
プレビューでは訳文だけでなくレイアウト、リンク、構造化データ、フォームを確認します。原文の削除が翻訳版でも消えるか、古いURLのリダイレクトも確認対象です。
- 差分の検知日時と原文版を残す
- リスク別に承認者と公開条件を変える
- 失敗時は前の正常版へ戻せるようにする
- 公開後にHTTP・表示・検索設定を監視する
更新時間と古い情報の滞留をKPIにする
公開本数だけでなく、原文変更から翻訳公開までの時間、期限を超えた未翻訳件数、差し戻し率、重大な更新漏れを測ります。これにより自動化が実際に運用を速めたか判断できます。
月次でボトルネックを一つ改善します。用語承認が遅いなら責任者を固定し、表示QAが遅いなら代表画面幅を自動テストへ移す、といった具体策へつなげます。
実行前に押さえる要点
- 元CMS・PDF・画像・外部機能を含む更新入口を一覧化し、正式な通知経路を決める。
- 検知、翻訳、承認、公開を分け、自動更新の実際の範囲を契約前に確認する。
- 変更から公開までの時間と古い情報の滞留を測り、毎月一つボトルネックを直す。