このプレイブックの目的

多言語コンテンツサイトは、単なる翻訳の問題ではありません。運用の問題です。ひとつの編集原本、翻訳レイヤー、レビュー工程、公開フローが噛み合ってはじめて、ひとりでも維持できます。

目指すべきは完全一致ではなく、世界に届けながら運用負荷を増やさない一つの仕組みです。

Quick take

基本形はこうです。原文となる主言語を1つ決める。各デスクを構造化 DB で管理する。AI で一次翻訳する。重要ページだけ人が軽くレビューする。これで十分に強い運用になります。

役割推奨ツール
原本編集意図と構造を保つNotion, 執筆フロー
翻訳一次訳を速く作るGPT / Claude 翻訳ワークフロー
レビュータイトルやニュアンスを守る重要ページのみ人の確認
公開URL、言語切替、CMS を揃えるAstro, i18n routes, Vercel

スタック

まず主言語を決めます。各ページに slug、summary、outcome、audience、status を持たせると、後段の翻訳が安定します。

すべてのページを同じ精度で扱わないことが重要です。Daily Brief は速く、レビューや主力 playbook は軽くでも人が見る。まず構造と意図を移し、そのあとで語感を整えます。

多言語サイトが高コストになるのは、内容がずれていくからです。routing、CMS、翻訳ステータス管理を一本化すると、追加ページよりも運用の安定が得られます。

週次の進め方

  1. 原文ページを更新または公開する。
  2. 他2言語へ一次翻訳を流す。
  3. ホームページやコンバージョンに効くページだけレビューする。
  4. まとめて再デプロイし、版ズレを防ぐ。
  5. 古くなった言語版やズレたページを確認する。

人が最初に見るべきもの

優先ページ種別理由
1ヒーローコピーやトップページトーンの違和感が目立つ
2主力レビューや主力 playbook信頼感に直結する
3数字や主張がある case study正確さが重要
4Daily Brief主導面でなければ軽めでよい

チェックリスト

  • 原本となる言語を1つ決める。
  • 各言語を構造化 DB で持つ。
  • タイトル、ヒーロー、編集判断は手で確認する。
  • slug と routing を予測可能に保つ。
  • 言語版をまとめて再デプロイする。

このプレイブックが必要なサイン

  • 読者がすでに複数地域に分かれている。
  • 手作業翻訳が公開速度を落としている。
  • evergreen なページが増え、一貫性が重要になってきた。
  • 編集チームを増やさずに到達範囲を広げたい。

旧サイトと現プロジェクトからの素材

Operator note

多言語サイトの強さは、翻訳を頑張ることではなく、翻訳を運用レイヤーとして扱えることです。