ランディングページを構造化フィールドとしてモデル化する

同じランディングページをベトナム、フィリピン、インドネシアの3市場で展開すると、最初は同じだったはずのページが少しずつ別物になっていきます。ある市場ではCTAが2つに増え、別の市場では見出しの下に説明文が1段落追加され、翻訳担当者はどこが最新の原稿なのか分からなくなります。この記事では、ページを自由形式のドキュメントではなく「型付きフィールドの集合」としてモデル化する考え方と、その具体的な進め方を、コンテンツ担当者と開発者の両方の視点から解説します。

自由形式のドキュメントがずれていく理由

リッチテキストエディタで1ページを丸ごと書く方式は、単一市場・単一言語のうちは手軽です。しかし市場とロケールが増えると、ページの「形」そのものがロケールごとに変わる余地が生まれます。形が揃っていないと、翻訳の差分確認、レビュー、フロントエンドでの描画のすべてが属人的な作業になります。

• 翻訳: 原文のどの段落がどの訳文に対応するのかを毎回目で突き合わせる必要があります。
• レビュー: 変更点が本文全体に埋もれるため、何が変わったのかを正確に把握しにくくなります。
• 描画: デザインが想定していない要素（余分な見出しや画像）が混入し、レイアウトが崩れます。
• 再利用: 同じ文言をアプリやメールで使いたくても、HTMLの塊から取り出す手間が発生します。

ページではなくセクションから始める

モデル化の出発点は、ページ全体ではなくセクションです。トップページであれば「Hero」「Why（選ばれる理由）」のように、デザイン上のまとまりごとに分け、それぞれに少数の型付きフィールドを持たせます。キーは home.hero.headline のように「ページ.セクション.フィールド」の順でドット区切りにすると、編集者にも開発者にも、その値がどこに表示されるのかが一目で伝わります。

{
  "home.hero.eyebrow": "International shipping",
  "home.hero.headline": "Ship to 20+ countries with ease",
  "home.hero.subcopy": "Track every order in real time, with clear pricing.",
  "home.hero.ctaLabel": "Get a quote",
  "home.hero.ctaHref": "/contact",
  "home.hero.imageAlt": "Staff packing a parcel",
  "home.whyIntro.title": "Why teams choose us",
  "home.whyIntro.description": "A regional warehouse network and support that answers."
}

ポイントは、キーが「意味」を表し、値が「文言」を表すという分担です。デザインを変更しても home.hero.headline が「Heroの主見出し」であることは変わりません。逆に、同じキーを別の意味で使い回すと、翻訳もレビューも混乱するため避けてください。

フィールドの型と入力ガイドを決める

各フィールドには型を与えます。型によって入力UIと検証内容が決まるため、誤った値が公開される前に気付けます。tixigen では、主に次の4つの型を使い分けます。

• テキスト: 見出しやボタンラベルなど、1行で完結する短い文言。
• 長文テキスト: 見出し下の説明文など、1〜2文程度の文章。
• URL: CTAのリンク先など。サイト内パスと完全なURLのどちらも扱えます。
• メディア: Hero画像など。代替テキストは別のテキストフィールドとして持たせます。

型に加えて、編集者向けのガイドも用意すると運用が安定します。たとえば「表示場所」「このフィールドの役割」「記入例」「文字数の目安」「トーン」です。見出しは60文字、CTAラベルは24文字、説明文は160文字といった目安があるだけで、各市場の担当者がデザインに収まる原稿を書きやすくなります。これらは編集画面でのみ使う情報で、公開APIのレスポンスには含まれません。

市場とロケールで同じ構造を共有する

フィールドのキーはすべての市場で共通で、市場とロケールの組み合わせごとに値だけを差し替えます。現在の市場とロケールは、ベトナム（vi・en）、フィリピン（fil・en）、インドネシア（id・en）です。構造が共通なので、フロントエンドは市場を意識せず同じコンポーネントで描画でき、編集者も「どのフィールドがまだ翻訳されていないか」を把握しやすくなります。

// GET /api/v1/public/pages/ph/home?locale=fil
{
  "fields": {
    "home.hero.headline": "Padaliang mundo, isang tap lang",
    "home.hero.ctaLabel": "Mag-quote"
  }
}

既存ページを移行する手順

すでに公開中のページをフィールドに置き換える場合は、一度に全ページを移行するのではなく、影響の大きいトップページから始めるのが現実的です。次の順番で進めると、デザインとコンテンツの認識のずれを早い段階でつぶせます。

1. 1現行ページをスクリーンショットで棚卸しし、セクションの境界に線を引きます。
2. 2各セクションで実際に変わりうる文言と画像だけを洗い出し、キーと型を決めます。
3. 3フィールドごとに表示場所、記入例、文字数の目安を書き添えます。
4. 4市場の既定ロケールで原稿を入力し、続けて en などの翻訳を入力します。
5. 5署名付きプレビューで表示を確認し、レビューで承認を得てから公開します。
6. 6フロントエンドを公開APIに接続し、ハードコードされた文言を順に置き換えます。

よくある落とし穴

• 細かく分けすぎる: 1文を3つのフィールドに分割すると、語順の異なる言語で自然な訳が書けなくなります。文は文のまま1フィールドに収めます。
• レイアウトを値に入れる: 改行位置や色の指定を文言に埋め込むと、市場ごとに見た目が変わります。見た目はコンポーネント側で決めます。
• キーを気軽に変更する: キー名はフロントエンドとの契約です。変更する場合は新旧を並行して持たせ、描画側の切り替え後に古いキーを削除します。
• 任意フィールドだらけにする: 公開に欠かせない見出しなどは必須として扱い、空のまま公開されないようにします。

型付きフィールドは、最初の設計に少し時間がかかる代わりに、市場やロケールが増えるほど効果が大きくなります。まずはトップページのHeroセクションだけでも、フィールドとして切り出すところから始めてみてください。