多言語公式サイトで最もよく見られるトラブルは、訳し訳しの腔調ではなく、原文がすでに変更されているのに、翻訳サイトには古い原稿がそのまま掲載されていることだ。中国語のキャンペーンページが公開されたのに、英語の価格表はまだ前四半期のままだったり、日本語の法的通知に一つだけ修正漏れがあって、海外からのクレームが直接届いてしまうといったケースも少なくない。根本的な原因は、通常、各言語ごとに独立してリリースを行っており、「同一コンテンツパッケージ」の公開に対する統一したアクセス制御がないためである。
問題を分解すると、コンテンツパッケージ、言語状態、公開窓口の三つに分かれる
一度の改訂を「いくつかのページを修正する」という視点ではなく、コンテンツパッケージとして捉えるべきだ：
- 原文項目：タイトル、本文、CTA、構造化フィールド（価格、仕様、コンプライアンス声明）
- 言語別コピー：各言語ごとに一つのレコードを用意し、翻訳ステータスを付ける：未翻訳／翻訳中／審査待ち／準備完了
- 公開窓口：公開が許可される言語の集合と統一された有効開始時刻；準備完了していない言語がある場合は、パッケージ全体をブロックするか、ポリシーに基づいて段階的に降格させる
- ロールバックポイント：単一言語ファイルのみをロールバックするのではなく、コンテンツパッケージのバージョンごとにロールバックする
Word文書をネットワークドライブにアップロードしてから手作業で貼り付けると、フィールドやリンクが紛失しやすくなる。CMSが「特定言語のみ個別に公開できる」機能を許すと、新旧混在の国際サイトが生まれてしまう。
どのように設計すべきか
役割：コンテンツ責任者（原文）、翻訳者／エージェント、法務審査（特定の欄）、公開マネージャー。原文が確定していない限り、翻訳者は着手できない；法務欄が審査されていない場合、その言語は準備完了状態に進めない。フロントエンドのキャッシュはコンテンツパッケージのバージョン番号で無効化し、CDNに古いページが残らないようにする。
- コンテンツパッケージ：ビジネスキー、対象言語リスト、公開予定日時
- 項目：フィールドレベルの差分、スクリーンショット比較、用語集参照
- アクセス制御ルール：必須対応言語、延期可能な言語、ブロック条件
- 公開記録：操作者、バージョン、各言語のハッシュ値
SEO注意：hreflangとcanonicalはバージョンとともに変更すること；非公開言語のページは正しいステータスコードを返し、ソフト404にしてはいけない。キャンペーンページの臨時言語については「原文＋英語のみ」の戦略を取るが、これはアクセス制御内で明示的に設定し、口頭では行わない。
開発と検収
翻訳は機械翻訳による初稿を受け入れてもよいが、準備完了は必ず人手による確認が必要である。構造化フィールド（価格、日付）は自由なテキストへの入力を禁止し、個別に翻訳することで誤りを減らす。プレリリース環境では言語ごとのパスで検収を行う：原文で価格が変更された後、準備完了していない言語は外部から新しい価格に解析されないようにする。
検収シーン：
- 原文で価格が変更され、英語が準備完了していない場合、生産現場では旧価格を表示するのか、それともページ全体をメンテナンス中とするのか（ポリシーに従う）
- 強制公開の回避について、監査記録の有無と二人での確認義務
- ロールバック後のhreflangの整合性
- ある言語が長期的に遅れている場合、ボード上の赤信号が点灯するかどうか
- 用語集の変更が関連項目を一斉に汚染するかどうか
多言語サイトの規律は：まず全言語が揃ってから公開すること。遅れることは許容されるが、新旧混在は許されない。
失敗パターン
マーケティングはまず中国語から始める：キャンペーンは既に展開されているのに、翻訳サイトが動いておらず、海外からアクセスしても体験が途切れてしまう。アクセス制御ではデフォルトで「全言語が揃っている」ことを前提とし、緊急の例外は承認を得て期限付きで補完する。機械翻訳の直送：法律や価格ページは禁止；製品説明は機械翻訳＋抜き打ち審査可能。各言語の子サイトは技術スタックが分裂している：アクセス制御とバージョン番号が統一できず、まずは同一コンテンツサービスへ収束させることが優先される。
公開後に何を見ればいいのか
公開後4週間は注視する：言語間のコンテンツ遅延時間、アクセス制御の回避回数、古い翻訳による顧客クレーム、ロールバック回数。遅延と回避が減少すれば、次は自動翻訳による全サイトの実現を検討する。
翻訳ワークフローをどうアクセス制御に組み込むか
原文の確定が翻訳タスクのトリガーとなる：機械翻訳による初稿は選択可能だが、人手による審査は必ず通過させること。審査担当者は欄ごとに配置され、製品ページと採用ページでは異なる人が担当できる。審査で却下される場合は、具体的なフィールドを指摘しなければならず、「もう少し直してください」というだけでは不十分である。準備完了後は、コンテンツパッケージ全体の揃い具合を計算に入れる。
外部委託翻訳者は制限付きアカウントを使用し、割り当てられた項目しか見ることができず、直接公開することはできない。二言語並べての文書照合により、段落の漏れを低減する。リンクや画像のalt属性は個別にチェックリストを作成し、多くの「古い原稿事故」は実は古いリンクによるものである。
コンプライアンスが厳しいページ（プライバシーポリシー、契約条項）については、公開前に法務担当者の強制投入を義務付ける；期限切れの再審査カレンダーは言語ごとにタスクを生成し、英語で変更したのに中国語を忘れてしまう事態を防ぐ。
技術実装の要点
コンテンツサービスはフィールドレベルのバージョンを保存する；静的サイト生成時にはバージョンリストファイルを書き込み、運用側はCDNオブジェクトが一致しているかを確認できる。プレリリースドメインは言語ごとに完全にレンダリングし、クローラースクリプトで重要URLの価格と日付フィールドを抜き打ちチェックする。
翻訳メモリを使用する場合、原文を変更する際にはメモリ内の項目を汚染してマークし、古い訳文が新しい文脈で再利用されるのを防ぐ。用語集で矛盾が生じた場合は、業務オーナーの判断を優先し、変更理由を記載する。
公開窓口は業務ピークを避けることを推奨する；失敗時はプレリリース段階で自動停止し、半分だけ公開して生産に進むことはしない。コンテンツチームのKPIとして「言語の準備遅延」を監視するのは、「何ページ公開したか」よりも有意義である。
事故の振り返りテンプレート
典型的な事故の一例：中国語で価格が変更され公開されたのに、英語では依然として旧価格が表示され、カスタマーサポートは英語の見積もりに基づいて注文をロックしてしまう。振り返りでは、どのアクセス制御の穴があったのか、誰が権限を越えて跳び越えたのか、ロールバックに要した時間、顧客への影響範囲を明確に記述する必要がある。「アクセス制御の跳躍」は二人による確認が必要な例外ルートとして制度化し、監査記録にも残す。
ロールバック演習は四半期ごとに実施する：意図的に次要言語を汚染し、完全なロールバックと通知プロセスを経験する。演習中にCDNキャッシュのTTLが長すぎる場合、事前にポリシーを調整し、実際に事故が起きるまで待たずに改善する。
営業とカスタマーサポート向けに「言語の整合性照会」を開放する：製品SKUを入力すると、各言語の現在の価格と有効開始時期が分かる。問題を早期に察知し、ユーザーのスクリーンショットに頼る必要を減らす。
マーケティング配信との連携
配信素材引用のランディングページURLは必ずコンテンツパッケージのバージョンに紐づけなければならない。準備完了していない言語の広告グループは自動的に一時停止するか、メンテナンスページに切り替えられ、古い価格で広告費を無駄にするのを防ぐ。配信担当者は「言語が投下可能かどうか」のステータスだけを見て、CMSを自分で推測しない。
キャンペーン終了後の公開解除時、各言語は同時に無効化される；残留外リンクは301リダイレクトで総覧ページへ転送し、バージョンのスナップショットを保管して備考とする。
子会社がそれぞれ独立したCMSを使用している場合、少なくとも「コンテンツパッケージ状態API」を統一する：本社のマーケティングセンターが各拠点の準備状態を確認してから配信を指示する。状態APIがなければ、アクセス制御は口頭での同期に留まり、事故率は下がらない。
コンテンツパッケージ番号をカスタマーサポートの工事票フィールドに記載し、古い翻訳による苦情がどのリリース版に由来するかを容易に特定できるようにする。