商品カタログローカライズワークフロー

翻訳前にソースを固定する

カタログをエクスポートし、不変のソーススナップショットを保持します。出所、エクスポート時刻、リビジョンまたはファイルハッシュを記録します。すべてのバリエーションに安定した識別情報を割り当て、言語ジョブを作る前に欠落または重複した識別子を確認します。処理する商品とロケールの組み合わせをマニフェストに保持します。

ソース準備と翻訳を分けます。矛盾する測定値、欠落した単位、根拠のない主張は、まず商品所有者と解決します。仕入先のエクスポートの正規化が必要なら、その修正をソース変更として記録し、言語作業を始める前に所有者に結果のベースラインを承認してもらいます。

保護された事実と編集可能なテキストを分ける

SKU、価格、通貨、単位、バリエーション関係、その他の運用値の保護レコードを作ります。生成するのはテキストパッチだけにします。組み立て時には、保護値をソースから直接コピーし、モデルがコンテキストとして見ただけのフィールドの権威にならないよう、もう一度比較します。

主張も追跡可能にします。承認済みの主張を証拠に結び付け、根拠のないものはフラグを立てるようドラフト段階に伝えます。以下の設定は例示的なパイプラインポリシーであり、ShopifyやWooCommerceが受け付けるファイルではありません。アダプターは実際の送信先契約へマッピングする必要があります。

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

用語集とロケールブリーフを添付する

ロケールブリーフには、読者、トーン、承認済み用語、表示ルールを記載します。商品概念と推奨表記を分けて管理します。W3C ITSは用語と翻訳メタデータを定義しており、より豊かなローカライズシステムの参考になります。このワークフローでは、より簡単なバージョン管理された編集記録を使います。

実際のカテゴリーの例で曖昧な用語を解決します。用語集の項目が変わったら、影響を受ける候補を特定し、再生成か対象を絞った編集かを決めます。各ロケールを同じ承認済みソースに結び付けます。一つの翻訳版をレビューなしの中間ソースにして、残りへ使わせないでください。

ローカルケース：20商品、40言語パッチ

20個の合成商品からなる固定カタログを、翻訳エージェントがgpt-5.6-lunaとxhigh reasoningを明示的に設定した状態で、日本語20件とドイツ語20件のパッチへ翻訳しました。各パッチにはsku、locale、title、descriptionだけが含まれます。アセンブラーはprice、currency、material、dimensionsをsource.jsonからコピーするため、事実の保持はモデルに委任されたコピー作業ではなく、パイプラインの特性です。

保存されたvalidated-ja.jsonとvalidated-de.jsonには、それぞれ20行と空のfailuresリストが含まれています。読み取り専用の再組み立ては両方の保存済み出力と一致します。自分のバッチでもこの形式を使い、ソースリビジョンを保持し、言語パッチを分けて保存し、レビュー用パッケージを組み立てる前にカバレッジと許可フィールドを検証してください。

編集レビュー前に決定論的チェックを実行する

出力スキーマ、許可フィールド、識別子マッピング、ソースリビジョン、必須テキスト、保護値を検証します。アプリケーションの実際のテンプレート文法でプレースホルダー数を比較します。HTMLに一般的なテキスト置換を行わず、マークアップを解析します。形式不正のレコードは、インポーターに修復させず保留します。

スプレッドシートのレビュー用ファイルについては、OWASPが数式インジェクションのリスクと、普遍的に安全なCSV変換が存在しないことを文書化しています。選択したスプレッドシートツール向けにレビュー済みのエクスポートポリシーを使い、その成果物を機械インポートから分けます。人間向け表示のためにエスケープ接頭辞を追加しても、ストアペイロードのSKUを誤って変更しないようにします。

レビュー判断をコンテンツリビジョンに結び付ける

レビュアーにソースの事実、用語集のコンテキスト、候補、構造化された問題を渡します。事実に関する判断と言語に関する判断を分けて求めます。誰が承認し、どのリビジョンを見たかを記録します。レビュアーがローカライズされた表現を受け入れながら、証拠が必要な主張は保留することもできます。その区別を記録で表現してください。

ローカルケースでは、AIレビューが日本語DEMO-003を、段ボール紙を意味する表現から、ソースの厚紙台紙に一致する表現へ修正しました。またDEMO-010を合計2本の取っ手という意味に明確化しました。元の出力はraw-ja.jsonに残っています。組み立てられた両言語にはなおreview_status: unreviewedとtranslation_semantic_review: pendingが付いています。これらの修正はネイティブ話者やマーチャントによる承認ではありません。

送信先パッケージを組み立てて検証する

承認済みでソースが最新の候補を選び、許可されたフィールドだけを変換します。Shopifyの翻訳APIはリソースとダイジェストの契約を使います。WooCommerceの展開には、商品マッピングと、複数言語の場合は検証済みのローカライズ層が必要です。一般的なレビューパッケージ自体は、万能なストアインポートではありません。

ステージングで小さな承認済みインポートをテストします。インポーターの結果を保存し、対象フィールドを読み戻し、商品とロケールの動作を検査します。計画した商品集合と保存結果を照合します。失敗した行を分けて保持し、必要なら慎重に範囲を限定した取り消しに備えて以前の値を保存します。

結果とその限界を記録する

完成したマニフェストは、ソース、用語集、プロンプト、候補、チェック、承認、送信先の結果をリンクするべきです。証拠があるすべての試行について、リトライを含めて実際の使用量を記録します。使用量やレビュー結果がない場合は、明示的に不明のままにします。解析できるファイルであることは、ショップが受け入れた証拠ではありません。

範囲を限定したローカルケースでは、選択したモデルはLunaでありAstraではなく、ゲートウェイ呼び出しも実際のストアインポートもありません。API使用量、リクエストID、課金は公開されず、model_api_usageとmodel_api_costはゼロではなくnullのままです。次のステップは意味の承認であり、その後に別途承認された送信先テストを行います。

よくある質問