商品コンテンツの品質チェック

生成前に品質契約を定義する

各フィールドの受け入れルールを書きます。識別情報とリビジョンフィールドはソースと一致するべきです。編集可能なテキストは指定ロケールを使い、必要な情報を含み、送信先形式を守るべきです。主張には裏付けとなる証拠が必要です。一つの合否ラベルだけでは、どの条件が商品を止めたか説明できません。

機械で確認できる欠陥と編集上の判断を分けます。テキスト欠落と識別子の変化は決定論的に特定できます。翻訳が利点を誇張しているかどうかには、コンテキストと適切なレビューが必要です。各問題を解決できる人またはシステムへ送り、結果を候補リビジョンに付けます。

組み立て後に保護値を比較する

許可されたテキストフィールドだけを生成し、ソースからコピーした保護値を使って候補レコードを組み立てます。その組み立てたレコードに対して2回目の比較を実行します。これにより、レビュー中の偶発的な編集だけでなく、マッパーのミスも検出できます。

以下のJavaScript例では、スキーマ検証済みオブジェクトとスカラーの保護値を想定しています。保護キーの欠落、余分、変更と、古いソースリビジョンを検出し、安定した問題コードを返します。このヘルパーの前にスキーマと値の検証を置き、その後で構造的に有効な候補を編集レビューへ送ります。

function checkProtected(source, candidate) {
  const issues = [];
  if (candidate.sourceRevision !== source.sourceRevision) {
    issues.push({ code: "STALE_SOURCE", field: "sourceRevision" });
  }
  const keys = new Set([
    ...Object.keys(source.protected),
    ...Object.keys(candidate.protected),
  ]);
  for (const field of keys) {
    const hasSource = Object.prototype.hasOwnProperty.call(source.protected, field);
    const hasCandidate = Object.prototype.hasOwnProperty.call(candidate.protected, field);
    if (!hasSource || !hasCandidate ||
        !Object.is(source.protected[field], candidate.protected[field])) {
      issues.push({ code: "PROTECTED_FIELD_CHANGED", field });
    }
  }
  return issues;
}

数値の表示と値を分ける

ローカライズされた数値は見た目が変わっても、同じ保存数量を表すことがあります。MDNではロケール対応の表示にIntl.NumberFormatが文書化されています。権威ある値を選択した後で表示形式を適用し、描画された通貨文字列から価格をモデルに再現させないでください。

数値とともに単位を定義し、各寸法にどの単位が属するかを含めます。変換が承認されているなら、決定論的な変換ルールを使い、元の表現を保持します。文中の数字だけを比較しないでください。単位の異なる同じ数字は、異なる商品を表すことがあります。単位が欠落している場合は、ソースが解決するまで承認を止めます。

プレースホルダーの個数とマークアップを検証する

アプリケーションのテンプレートパーサーで、ソースと候補からプレースホルダートークンを収集します。名前の集合だけでなく個数を比較します。重複したトークンは、元のトークンがすべて現れていても、文やアプリケーションを壊す可能性があります。形式固有のエスケープルールは送信先の境界で保ちます。

以下の小さなチェックは、すでに抽出されたトークンを受け取ります。普遍的なプレースホルダー正規表現を試みるものではありません。HTMLでは、文書フラグメントを解析し、許可された構造とリンクを別々に比較します。カスタム描画ではWordPressのエスケープガイダンスが関係しますが、エスケープだけではコンテンツが意図した意味を保ったことは証明できません。

function samePlaceholderCounts(sourceTokens, candidateTokens) {
  const counts = new Map();
  for (const token of sourceTokens) {
    counts.set(token, (counts.get(token) ?? 0) + 1);
  }
  for (const token of candidateTokens) {
    if (!counts.has(token)) return false;
    counts.set(token, counts.get(token) - 1);
  }
  return [...counts.values()].every((count) => count === 0);
}

ケース：フィールドは有効でも、表現には修正が必要

gpt-5.6-lunaとxhigh reasoningを明示的に設定した翻訳エージェントが、20個の合成商品から日本語20件とドイツ語20件のパッチを作りました。決定論的なスキーマ、識別情報、保護フィールドのチェックは、組み立てた40行すべてで通過しました。価格、通貨、素材、寸法はソースからコピーし、生成パッチが変更できるのは識別されたSKUとロケールのtitleとdescriptionだけでした。

未加工の日本語パッチも構造バリデーターを通過します。それでもAIレビューで以下の2件の表現上の問題が特定され、説明が修正されました。保護された素材フィールドを確認しても、文章が素材を正確に説明していることは確定できません。スキーマチェックがすべて通過した後も、影響の大きい各主張をソースと比較してください。

インポートだけでなくレビュー用エクスポートもテストする

OWASPはスプレッドシートの数式インジェクションを説明し、安全変換が利用者ごとに異なることを指摘しています。仕入先と生成されたセルを信頼できないものとして扱います。実際のスプレッドシートツールに向けたレビュー済みシリアライズポリシーを使い、メモリ上の表だけでなく保存された成果物を検査します。

機械インポートをレビュー用ファイルから分けます。人間向けに安全にするために追加した接頭辞が、インポート中に識別子や公開説明を黙って変えないようにします。パーサーでエンコーディング、引用符処理、想定行識別子を検証します。元のソースを未加工のまま保持し、スプレッドシートエディタが導入した変更を特定して修正できるようにします。

承認を正確な候補に結び付ける

事実の承認と言語の承認とともに、候補リビジョンまたはハッシュを保存します。後の編集があれば、レビューされるまで関係する承認を無効にします。商品仕様が変わった後は翻訳が同じでも古くなる可能性があるため、最終公開処理では現在のソースリビジョンも比較します。

ケース成果物では、修正済みの日本語パッチとドイツ語パッチがreview_status: unreviewedの行に組み立てられます。両方のレポートにはtranslation_semantic_review: pendingが残っています。AIによる修正はリビジョンの段階であり、ネイティブ話者やマーチャントの承認ではありません。未加工と修正版の候補を保持し、インポートパッケージに入る正確なテキストを適切なレビュアーに承認してもらいます。

チェックを再現し、範囲を明確に保つ

ローカルケースのテストは、ソースフィールドの保持、重複SKU、SKU欠落、禁止された価格上書きを実行します。保存された日本語とドイツ語パッチの読み取り専用再組み立てで、両方の検証済み出力を再現できます。より広いカタログでは、独自のプレースホルダー文法、マークアップ、リビジョンポリシーのチェックを追加します。上の例示ヘルパーは別の例であり、40行に使ったバリデーターそのものではありません。

これはLunaを設定したローカル翻訳ケースであり、Astraやゲートウェイの呼び出し、実際のストアインポートはありません。ツールからAPI使用量、リクエストID、課金は公開されず、両方の出力にはnullの使用量とコストが残っています。構造結果を意味レビューへ進めるために使い、その後に承認済みストアアダプターを別途テストしてください。

node --test examples/commerce-localization-case/case.test.mjs

よくある質問