BuyCard.vipがHippoAPIで11言語のストアを構築した方法

お持ち帰りする

• 翻訳済みコンテンツはBuyCard側に保存され、購入者がページを開くたびにAIの応答を待つ必要はありません。
• 各言語に安定したURL、インデックス可能な本文、個別のSEOメタデータがあります。
• HippoAPIは作業用の下書きを作り、検証と人による確認は公開手順に残します。
• 同じモデル接続を翻訳、商品文、SEO確認、編集下書きに利用できます。

出発点は、現場の具体的な困りごとでした

BuyCard.vipは、英語だけで検索や購入をしない顧客にもギフトカードなどのデジタル商品を販売しています。商品ページには名前だけでなく、短い説明、購入時の注意、利用手順、条件、カテゴリ文、SEOタイトル、メタディスクリプションがあります。商品が入れ替わり、言語が増えると、翻訳は公開時だけの作業ではなく日常の店舗運営になります。

ブラウザの翻訳ボタンでは解決できません。表示はその訪問者だけの一時的なもので、用語を統一しにくく、検索エンジン向けの安定した現地語ページも作れません。BuyCardに必要だったのは、保存し、確認し、直し、繰り返し配信できる翻訳でした。

ここでいう「本物のサイト翻訳」とは

BuyCardは英語を原文とし、承認した訳文を対応するコンテンツと一緒に保存します。UIラベルはバージョン管理された言語辞書に置き、商品、固定ページ、記事、カテゴリ、SEO項目の訳文は専用のローカルテーブルに保存します。訪問者が言語別URLを開くと、WordPressが保存済みの文字を読み、HTMLに出力します。

大事なのは、訪問者が来る前に翻訳ページが存在していることです。キャッシュでき、編集者が直接修正でき、Sitemapに載せられ、ブラウザの翻訳ウィジェットを動かさなくても読めます。

11言語を、1つの運用手順で扱う

現在のストアは英語、簡体字中国語、スペイン語、ロシア語、ブラジルポルトガル語、アラビア語、フランス語、日本語、韓国語、ドイツ語、トルコ語に対応しています。アラビア語には右から左のレイアウトが必要です。日本語の商品表現や空白の使い方も、ドイツ語やポルトガル語とは違います。すべてを1つの「外国語」欄に入れれば、すぐ管理できなくなります。

チームは翻訳キューを確認し、欠けている項目を埋め、英語原文が変わった後に訳文を見直せます。原文の指紋を保存することで、古くなった可能性のある翻訳も見つけられます。問題が起きたとき、どのレコードのどの項目を直すかが明確です。

• ブランド名、額面、商品コードは変更しない。
• 顧客向けの説明は自然な現地語で書く。
• ストアが必要とする変数とマークアップを保持する。
• 原文変更後は訳文を見直し、古い内容を放置しない。

HippoAPIが担う部分

HippoAPIはコンテンツ制作の流れに入り、各購入者の前には入りません。BuyCardは定義した翻訳・執筆タスクを送り、構造化された下書きを受け取り、必須項目と形式を確認してから、自社システムに保存します。公開ページはローカルデータを読むため、ページ表示のたびに新しいモデル応答へ依存しません。

モデルへの入口を1つにすると、ストア連携を作り直さずに仕事ごとのモデルを選べます。大量翻訳、短いSEO説明、長い記事で同じモデルを使う必要はありません。接続方法は保ったまま、モデル選択を別に評価できることが実務上の利点です。

多言語SEOに役立つ理由

BuyCardでは各言語が独自URLを持ちます。生成HTMLは言語を示し、現地語のタイトル、説明、Canonical、代替言語リンクを持てます。多言語Sitemapも生成します。これらの情報により、検索エンジンは正しいページを見つけ、各言語版の関係を理解しやすくなります。

ただし、翻訳だけで順位が保証されるわけではありません。商品の提供状況、役立つ文章、内部リンク、速度、検索意図も必要です。この仕組みが取り除くのは基本的な技術障害です。現地語の内容がブラウザ内の一時的な翻訳に閉じ込められず、長く管理できる独立ページになります。

同じ接続を日々の運用にも使う

翻訳が最も分かりやすい用途ですが、デジタルストアにはほかにも反復する文章作業があります。BuyCardは商品説明、利用案内、SEO提案にも同じモデル接続を使います。SEOの状態画面で不足・弱い項目を探し、現在の文章と提案を並べ、担当者が適用する内容を決められます。

編集作業も同様です。検索データや実際の顧客質問からテーマを考え、長い記事は確認用の下書きとして保存します。価値があるのは「AI」ボタンではなく、提案が既存の仕事の中に入り、公開前に商品事実と照合できることです。

• 商品、ページ、記事、カテゴリの不足翻訳を補う。
• 商品説明、利用手順、短い購入案内を準備する。
• SEOタイトルと説明を適用前に確認する。
• 承認したテーマから編集下書きを作り、未確認の文章を直接公開しない。

人が必ず確認すること

ギフトカードには、文章の上手さでは直せない事実があります。利用可能国、通貨、額面、配送方法、利用手順、有効期限、ブランド条件です。商品データか承認済みの情報源から取得しなければなりません。翻訳処理はそれらを保持しますが、誤りが購入失敗につながる場合、最後の確認は人が担当します。

表現と用語も編集者が管理します。不自然な一文は保存済み訳文を一度直せば済みます。返金、在庫、配送に関する法的・サービス上の約束を、ページを魅力的に見せるためにモデルが作ってはいけません。

この方法を再利用できるチーム

同じ構造化コンテンツを複数市場で正確に保つ必要があるなら、この方法はECカタログ、SaaSヘルプ、旅行情報、アプリ一覧、マーケットプレイスなどで使えます。原文の担当者、訳文の明確な保存場所、安定した現地語URLがあると効果的です。

最初は小さく始めます。1種類のコンテンツと2言語を選び、モデルが下書きできる項目、絶対に変えてはいけない事実、確認場所、原文変更時の通知方法を決めます。この循環が安定すれば、言語追加はサイト再設計ではなく運用の仕事になります。

• ページ表示のたびに生成せず、訳文を保存する。
• 各言語に安定してクロール可能なURLを用意する。
• 事実項目と自由文を分ける。
• 再生成より確認と修正を簡単にする。