フラットファイルの自動化：複数のAmazonマーケットプレイスで商品掲載情報を管理する

Amazonのフラットファイルは、大規模なカタログの商品掲載情報を一括管理するための最も網羅的なインターフェースです。一方、複数マーケットプレイスでの運用については、文書が特に不足しています。同じカテゴリーの同じ商品でも、マーケットプレイスごとにテンプレートのバージョン、必須項目、検証ルールが異なります。一つの商品データを基に10のマーケットプレイスで商品掲載情報を管理するには、テンプレートの違い、属性の翻訳、アップロード・検証・修正のサイクルに体系的に対応する必要があります。

本記事では、当社が複数マーケットプレイスのカタログ管理に使っているフラットファイルのワークフローを紹介します。テンプレートの違い、自動化の効果が最も大きい部分、手作業が避けられない部分を説明します。

フラットファイルとは

フラットファイルは、Amazonが商品掲載情報の一括作成・更新を処理するために使う、タブ区切りのスプレッドシートです。各行が商品、各列が属性を表します。Seller Centralの「カタログ > アップロードによる商品一括登録」からダウンロードするテンプレートで、必須列、任意列、各フィールドで使用できる値が定義されています。

フラットファイルはSP-APIのListings Items APIより前から存在し、現在もSeller Central内での一括編集の主要なインターフェースです。API側では、Amazonは2024年3月にフラットファイル形式とXML形式の商品掲載情報フィードを非推奨とし、2025年6月30日に廃止する予定で、JSONベースのListings Items APIとJSON_LISTINGS_FEEDへの移行を案内しました。Seller Centralからのフラットファイルのアップロードは影響を受けませんでした。複数マーケットプレイスで数十を超えるSKUを扱う出品者には、一括処理のワークフローが事実上必要であり、当社の構成ではフラットファイルがカタログ管理の主要なインターフェースです。

しかし、Amazonのフラットファイルに関する文書は分散しており、古くなっていることも少なくありません。最も新しい仕様は、管理対象のマーケットプレイスとカテゴリーについて、その都度ダウンロードするテンプレート自体です。保存済みのテンプレートや6か月前の文書に頼ると、アップロードエラーが起きやすくなります。

マーケットプレイス間のテンプレートの違い

初めて複数マーケットプレイスで運用する出品者の多くが想定する以上に、テンプレートの構造は異なります。同じフィールドを翻訳しただけではありません。

あるカテゴリーの米国向け衣料品テンプレートには、50の属性列があるかもしれません。対応するドイツ向けテンプレートには60列あり、EU規制で求められる特定の化学物質に関する適合宣言や、特定の商品種類に適用されるエネルギーラベル要件など、米国にはない項目が含まれる場合があります。日本向けテンプレートでは、サイズと色のバリエーションの構造が異なり、米国版では認識されないバリエーションテーマ名を使うこともあります。

フィールド名が同じでも、使用できる値はマーケットプレイスによって異なることがあります。item_type_keywordに指定できる文字列は、.comと.co.ukで違います。color_nameはマーケットプレイス固有の一覧に照らして検証されます。米国で検証を通る色名でも、ドイツや日本では承認済みの値に一致せず拒否されることがあります。エラーレポートも必ずしも明確ではありません。承認済みの一覧にないという説明ではなく、汎用的な属性エラーが返ってきます。

テンプレートのバージョンは予告なく更新されます。Amazonはカテゴリーの新しいテンプレートを定期的に公開し、必須項目を追加したり、古い項目を廃止したりします。古いバージョンでアップロードすると、処理自体は成功しても商品掲載情報が正しくインデックスされなかったり、特定の属性が通知なく無視されたりすることがあります。当社は重要なカタログ更新を始める際、保存済みのテンプレートを再利用せず、新しいものをダウンロードします。

サイズ体系の変換

衣料品と靴では、サイズ体系の変換が、複数マーケットプレイスのカタログ管理で最も手間のかかる作業の一つです。米国、EU、英国、日本のサイズ体系は直接対応せず、換算表も商品種類によって異なります。

米国サイズ8の女性用の靴は一般的な換算表では通常、英国サイズ6、EUサイズ39に相当します（ブランドの換算表によっては0.5サイズ異なる場合があります）が、米国のMサイズの女性用シャツは、ブランドのサイズ基準によってEUの38または40になることがあります。共通の換算表はありません。適切な方法は、メーカー固有のサイズガイドで検証した対応表を、商品種類とブランドごとにマスターとして管理することです。

マーケットプレイス固有の絞り込み条件で商品を正しく表示するには、Amazonのsize_nameとsize_systemを正しく組み合わせて入力する必要があります。size_nameに米国サイズを入れてもsize_systemを指定しないと、形式のない文字列として扱われる場合があり、当社の経験では、サイズで絞り込んだ検索結果に表示されないことがあります。アップロードの完了通知からは分からないこともあります。商品掲載情報は正常に作成されても、サイズでの絞り込みが機能しないのです。

特に日本では、多くの商品カテゴリーのサイズ体系が欧州とも米国とも異なります。衣料品には独自の数字の体系があり、靴にはセンチメートルを基準とした体系があります。当社が使用した日本向けテンプレートではsize_map_unit_of_measureが必須でしたが、米国やEUの対応テンプレートにはありませんでした。市場をまたいでテンプレートを再利用した際、この項目の欠落によって、通知のない処理失敗が起きました。項目名は商品タイプやテンプレートのバージョンによって異なるため、実際にダウンロードしたテンプレートの列見出しと有効な値を確認してください。

バックエンドキーワードの制限

バックエンドキーワード、つまりgeneric_keywordに送信する検索語は、マーケットプレイスごとに文字数の上限が異なり、制限の数え方も違います。

Amazon.comでは、generic_keyword全体に249バイトの上限があります。Amazon.deもバイト数で制限しますが、ドイツ語は英語よりマルチバイト文字が多いため、英語では米国のバイト数制限内に収まるキーワードでも、翻訳後はドイツのバイト数上限を超える場合があります。Amazon.co.jpの制限は日本語の文字エンコーディングと関係します。漢字1文字はUTF-8で3バイトを使うため、日本語で実際に入力できるキーワード量は、ラテン文字で数えた場合にバイト上限から想像する量より大幅に少なくなります。

ただし、キーワードの上限は、複数マーケットプレイスでの商品掲載情報の成果に影響する要因の中では比較的小さなものです。当社の観察では、バックエンドキーワードをバイト上限いっぱいまで詰め込む過剰な最適化は、自然な言葉での検索に合わせて表示される商品名、箇条書き、説明文を最適化することに比べ、追加の効果が小さくなります。バイト上限は守るべき制約であって、使い切れば成果が上がる指標ではありません。

実務では、商品ごとにマーケットプレイス固有のキーワード群を管理し、その市場の上限内に収め、見た目ではなくプログラムでバイト数を検証します。キーワード文字列をエンコードし、そのバイト長をマーケットプレイスの上限と比較する簡単なPython関数で、アップロード前に切り詰めの問題を検出できます。

自動化ワークフロー

フラットファイル自動化の基本となる考え方は、マーケットプレイス間の違いの大半が、意味ではなく構造にあるということです。商品自体は同じで、寸法、素材、用途、主な特徴は変わりません。変わるのは、その情報を各マーケットプレイスのテンプレート形式でどう表すかです。

当社は、すべての属性を特定のマーケットプレイスに依存しない形式で保存した商品データのマスターシートを管理しています。寸法はメートル法、サイズはメーカー本来の体系、キーワードは原語で保持し、カテゴリーは社内の共通分類に対応付けます。このマスターに、各対象市場の構造の違いを処理する変換層を適用して、マーケットプレイス別のフラットファイルを生成します。

変換層はスクリプトで、当社ではPythonで実装しています。マスターの各属性を各市場のフラットファイルの列に対応付け、サイズを換算し、カテゴリー分類をマーケットプレイスのブラウズノード構造へ変換し、出力前にフィールドごとの検証を行います。翻訳した商品説明、市場固有の適合宣言、国固有の規制属性など、手動確認が必要な項目は自動入力せず、出力で確認対象として示します。

ダウンロード・編集・アップロードのサイクル自体は半自動です。ダウンロードには、GET_FLAT_FILE_OPEN_LISTINGS_DATAなどのレポート種別を提供するSP-APIのReports APIを使います。ダウンロードしたデータの処理、マスターとの比較、アップロードファイルの生成は自動化しています。一方、アップロード自体と処理レポートの確認は手動です。自動化できないからではなく、大規模なアップロードで誤りが生じた場合の影響が大きく、Amazonへ送信する前に人が確認すべきだからです。

よくある失敗の種類

アップロードエラーには、検証の失敗、処理の失敗、通知のない失敗の三つがあります。

検証の失敗は最も分かりやすく、アップロードレポートに問題の行とフィールドを特定する明示的なエラーメッセージが返されます。主な原因は、指定された語彙を使う項目（size_name、color_name、item_type_keyword）の不正な値、特定のテンプレートバージョンの必須項目の欠落、キーワードや説明文のバイト数上限超過です。

処理の失敗は、検証には通っても商品掲載情報が期待どおりに更新されない場合に起きます。よくある原因はバリエーション関係の誤りです。対応する親のない子ASINや、子の属性に合わないバリエーションテーマを指定した親を送信するケースが該当します。また、既存ASINの分類と送信したブラウズノードが一致しない競合もあります。

通知のない失敗は最も検出が難しいものです。アップロードは成功し、処理レポートにもエラーはないのに、商品掲載情報が正しく機能しません。サイズが絞り込み条件に出ない、検索語がインデックスされない、管理画面ではバリエーション関係があるのに販売画面で正しく表示されない、といった問題です。検出には、販売画面を目視するのではなく、Catalog Items APIで公開中の商品属性と送信値を比較する必要があります。

実務上の対策は、アップロード後の検証工程です。アップロードから24時間以内に、対象となる各ASINの公開中の商品掲載データをAPIで取得し、送信値と比較して相違を検出します。複雑な作業ではありませんが、信頼できるカタログ管理と、エラーレポートに現れない不可解な変更を見つけるために常時手動監査が必要な管理とを分ける工程です。

Amazon FBAの新市場展開：データに基づく評価の枠組み — 商品掲載情報の管理方針を決める前に使う、市場選定の枠組み
FastAPIとTimescaleDBでAmazonデータウェアハウスを構築する — 更新方針の判断に使うカタログデータと商品掲載情報の実績データの保存・検索方法