--- title: "SP-APIフィードAPI（Feeds API）の使い方｜JSON_LISTINGS_FEEDの送信手順とPython実装" url: "https://www.issoh.co.jp/tech/details/3717/" published: 2024-10-02 updated: 2026-11-02 categories: ["REST API"] publisher: "株式会社一創" --- # SP-APIフィードAPI（Feeds API）の使い方｜JSON\_LISTINGS\_FEEDの送信手順とPython実装 Amazon SP-APIのフィードAPI（Feeds API）は、商品情報・価格・在庫をまとめてAmazonへ送るためのAPIです。2025年7月31日に旧来のXML・フラットファイル系の出品フィードが廃止されたため、いま実装するならJSON\_LISTINGS\_FEEDで送る形が前提になります。この記事では現行のv2021-06-30について、6つのオペレーションのレート制限、Pythonでの送信から処理レポート取得までの実装、ペイロードとレポートの構造、キューの詰まりを避ける運用設計を、公式のAPIモデルとスキーマに沿って説明します。 ## まとめ - 現行版はFeeds API v2021-06-30。旧v2020-09-04で必須だったフィードドキュメントのAES暗号化・復号は不要です。 - 出品系のXML・フラットファイルフィード（POST\_PRODUCT\_DATAなど）は2025年7月31日に廃止済み。移行先はJSON\_LISTINGS\_FEEDかListings Items APIです。 - 送信はcreateFeedDocument→署名付きURLへPUT→createFeed→getFeed→getFeedDocumentの5段階。署名付きURLは5分で失効します。 - 1フィードのメッセージ上限は25,000件。数件を即時に直すならListings Items API、大量の一括更新ならJSON\_LISTINGS\_FEEDを選びます。 - フィードは先入れ先出しのキューで順に処理されるため、本数を増やしても1本ごとの処理は速くなりません。急ぎの更新は別のフィードに切り出し、同じ内容の再送は止めます。 ## Feeds API v2021-06-30の6オペレーションとレート制限 Feeds APIは6つのオペレーションで構成されます。[公式APIモデル（feeds\_2021-06-30.json）](https://github.com/amzn/selling-partner-api-models/blob/main/models/feeds-api-model/feeds%5F2021-06-30.json)の既定値では、最も速いgetFeed・cancelFeed（毎秒2）と最も遅いcreateFeed（毎秒0.0083）の間に約240倍の開きがあります。 | オペレーション | メソッド | パス | レート（req/秒） | バースト | | ------------------ | ------ | -------------------------------------------- | ---------- | ---- | | createFeedDocument | POST | /feeds/2021-06-30/documents | 0.5 | 15 | | createFeed | POST | /feeds/2021-06-30/feeds | 0.0083 | 15 | | getFeed | GET | /feeds/2021-06-30/feeds/{feedId} | 2 | 15 | | getFeeds | GET | /feeds/2021-06-30/feeds | 0.0222 | 10 | | cancelFeed | DELETE | /feeds/2021-06-30/feeds/{feedId} | 2 | 15 | | getFeedDocument | GET | /feeds/2021-06-30/documents/{feedDocumentId} | 0.0222 | 10 | 表の値は既定値です。実際に適用されたレートはレスポンスヘッダのx-amzn-RateLimit-Limitで返り、取引量の多い出品者にはより高い値が割り当てられる場合があると公式モデルに書かれています。待ち時間は固定値で決めず、このヘッダから計算してください。 表に出ない制約もあります。cancelFeedで取り消せるのはprocessingStatusがIN\_QUEUEのフィードだけで、処理が始まったら止められません。getFeedsで遡れるのは作成から90日までで、モデルには「フィードの保持期間は最大90日」とあります。pageSizeの上限は100件、feedTypesで指定できるのは10種までです。90日より前の送信履歴を監査に使うなら、feedIdと処理レポートを自社側に保存しておく必要があります。 ## XML・フラットファイル系フィードの廃止とJSON形式への移行 ### 廃止されたフィードタイプと期日の経緯 Amazonは2024年3月18日、Feeds APIでXMLとフラットファイル形式の出品データを送る方式の廃止を[公式リポジトリのDiscussion #3815](https://github.com/amzn/selling-partner-api-models/discussions/3815)で告知しました。対象はPOST\_PRODUCT\_DATA、POST\_INVENTORY\_AVAILABILITY\_DATA、POST\_PRODUCT\_PRICING\_DATA、POST\_PRODUCT\_IMAGE\_DATA、POST\_PRODUCT\_RELATIONSHIP\_DATA、POST\_FLAT\_FILE\_LISTINGS\_DATA、POST\_FLAT\_FILE\_PRICEANDQUANTITYONLY\_UPDATE\_DATAなどで、価格・在庫・親子関係・画像を含みます。告知の箇条書きは13項目ですが、POST\_FLAT\_FILE\_LISTINGS\_DATAが2回載っているので実質12種です。 告知時点の期限は2025年3月31日で、その後延長されて2025年7月31日に廃止されました。2024年以前の実装記事やサンプルコードはPOST\_PRODUCT\_DATAを前提にしたものが多く、そのまま動かしても通りません。なお告知には「セラーセントラルから出品者が直接送るフィードには影響しない」とあり、対象はFeeds API経由の送信だけです。また廃止されたのは出品データのフィードで、FBAの返送・廃棄依頼のような非出品系のフィードは残っています。2026年9月の公式モデル更新でも、POST\_FLAT\_FILE\_FBA\_CREATE\_REMOVALのサンドボックス応答が追加されました。 ### Listings Items APIとJSON\_LISTINGS\_FEEDの選び方 移行先は2つあり、「1回に何件触るか」と「結果をその場で受け取る必要があるか」でほぼ決まります。 | 観点 | Listings Items API v2021-08-01 | JSON\_LISTINGS\_FEED | | ------- | ------------------------------ | -------------------- | | 更新単位 | SKU 1件 | 1フィード最大25,000件 | | 既定レート | PUT・PATCHとも毎秒5 | createFeedとは別の枠 | | 結果の受け取り | 同期レスポンス | 処理レポート（非同期） | | 送信前の検証 | mode=VALIDATION\_PREVIEW | なし | | 処理の順番 | 優先レーン | 先入れ先出しのキュー | 数件から数十件のSKUをすぐ反映したいのにFeeds APIを選ぶのは設計ミスです。createFeedはオペレーション単位で毎秒0.0083リクエストしか通らず、結果は処理レポートを取るまで分かりません。[Listings Items APIのモデル](https://github.com/amzn/selling-partner-api-models/blob/main/models/listings-items-api-model/listingsItems%5F2021-08-01.json)ではpatchListingsItemが毎秒5リクエスト・バースト5、putListingsItemが毎秒5・バースト10で、エラーはレスポンスでその場で返ります。modeにVALIDATION\_PREVIEWを付ければカタログへ反映せずに検証だけ走らせられるので、投入前に必須属性の不足を潰せます。 大量更新ではフィードが有利です。1フィードのメッセージ上限は、[JSON\_LISTINGS\_FEEDの公式スキーマ](https://github.com/amzn/selling-partner-api-models/blob/main/schemas/feeds/listings-feed-schema-v2.json)でmaxItems 25,000件と定義されています。AmazonのSolutions Architectが書いた[公式サンプルリポジトリの解説](https://github.com/amzn/selling-partner-api-samples/discussions/109)も、少量でリアルタイム性が要る価格・在庫の更新はListings Items API、急がない大量更新はJSON\_LISTINGS\_FEEDと分けています。同じ解説によれば、Listings Items APIはフィードのキューを通らない優先レーンで処理されます。判断軸が呼び出し回数と応答の粒度になる点は、[REST APIとGraphQLの違い｜利点・欠点と選び方、キャッシュ・エラー・負荷を実測で比較](/tech/details/3591/)で扱ったAPI選定と同じです。 ## フィード送信をPythonで実装する手順 公式のユースケースガイドは手順を細かく分けていますが、API呼び出しの単位でまとめると5段階です。日本のマーケットプレイスを扱う場合、エンドポイントは極東リージョンのsellingpartnerapi-fe.amazon.comになります。 ### フィードドキュメントの作成と署名付きURLへのアップロード 最初にcreateFeedDocumentを呼び、送るファイルの置き場所を確保します。リクエストに渡すのはcontentTypeだけです。 ``` POST https://sellingpartnerapi-fe.amazon.com/feeds/2021-06-30/documents x-amz-access-token: Content-Type: application/json { "contentType": "application/json; charset=UTF-8" } ``` レスポンスでfeedDocumentIdと署名付きURLが返ります。**このURLは5分で失効します。**トークンの取得やファイルの組み立てを後回しにすると、アップロードする頃には切れています。送るファイルを先に作ってからcreateFeedDocumentを呼ぶ順番にしてください。 次に、受け取ったURLへファイルの中身をPUTします。ここでのContent-Typeは、createFeedDocumentで申告した値と完全に一致させます。 ### createFeedによるフィードの登録 アップロードが終わってからcreateFeedを呼びます。モデルのinputFeedDocumentIdの説明にも「createFeedを呼ぶ前にフィードドキュメントの内容をアップロードすること」とあります。 ``` POST https://sellingpartnerapi-fe.amazon.com/feeds/2021-06-30/feeds { "feedType": "JSON_LISTINGS_FEED", "marketplaceIds": ["A1VC38T7YXB528"], "inputFeedDocumentId": "" } ``` A1VC38T7YXB528はAmazon.co.jpのマーケットプレイスIDで、[Orders API（v2026-01-01）の公式モデル](https://github.com/amzn/selling-partner-api-models/blob/main/models/orders-api-model/orders%5F2026-01-01.json)の応答例にもmarketplaceName「Amazon.co.jp」と対で載っています。成功するとfeedIdが返ります。 ### 処理レポートの取得とGZIPの展開 状態はgetFeedで確認します。processingStatusはIN\_QUEUE、IN\_PROGRESS、DONE、CANCELLED、FATALの5値で、DONE・CANCELLED・FATALのいずれかになれば終了です。終了するとresultFeedDocumentIdが付くので、getFeedDocumentに渡してレポートのダウンロードURLを取ります。応答にcompressionAlgorithm: GZIPが含まれる場合は、ダウンロードした中身を展開してから読みます。 ここに2026年4月の変更があります。getFeedDocumentにenableContentEncodingUrlHeaderというクエリパラメータが公式モデルへ追加され、compressionAlgorithmがGZIPのドキュメントでtrueにすると、返るURLのContent-Encodingヘッダが既定のidentityではなくgzipになります。HTTPクライアントが自動で展開できるようにするための指定です。PythonのrequestsはContent-Encoding: gzipを見て自動展開するので、この指定をしたうえで従来どおりgzip.decompressを呼ぶと二重展開になります。ローカルのモックサーバーで確かめたところ、自動展開後のバイト列にgzip.decompressを当てるとBadGzipFileで落ちました。下の実装は先頭2バイト（0x1f 0x8b）を見てから展開するので、どちらの指定でも動きます。 ### Pythonでの実装例（送信からレポート取得まで） 5段階を通した最小の実装です。LWAアクセストークンの取得とレート超過時の再試行は省いています。モックサーバーに対して、アップロード前にcreateFeedを呼ばないこと、Content-Typeの一致、GZIPレポートの読み込み（Content-Encodingの有無の両方）を確認しました。 ``` import gzip import json import time import requests BASE = "https://sellingpartnerapi-fe.amazon.com" TERMINAL = ("DONE", "CANCELLED", "FATAL") def submit_listings_feed(token, seller_id, messages, marketplace_id="A1VC38T7YXB528"): headers = {"x-amz-access-token": token} content_type = "application/json; charset=UTF-8" body = json.dumps({ "header": { "sellerId": seller_id, "version": "2.0", "report": {"includedData": ["issues"], "apiVersion": "2021-08-01"}, }, "messages": messages, }, ensure_ascii=False).encode("utf-8") # 1. 本文を作ってからドキュメントを作成する（返るURLは5分で失効） r = requests.post(f"{BASE}/feeds/2021-06-30/documents", headers=headers, json={"contentType": content_type}, timeout=30) r.raise_for_status() doc = r.json() # 2. 署名付きURLへPUT。Content-Typeは申告値と同じにする requests.put(doc["url"], data=body, headers={"Content-Type": content_type}, timeout=60).raise_for_status() # 3. アップロード後にフィードを登録する r = requests.post(f"{BASE}/feeds/2021-06-30/feeds", headers=headers, json={ "feedType": "JSON_LISTINGS_FEED", "marketplaceIds": [marketplace_id], "inputFeedDocumentId": doc["feedDocumentId"], }, timeout=30) r.raise_for_status() return r.json()["feedId"] def fetch_processing_report(token, feed_id, interval=60): headers = {"x-amz-access-token": token} # 4. 終了状態になるまで待つ（本番は FEED_PROCESSING_FINISHED 通知で置き換える） while True: r = requests.get(f"{BASE}/feeds/2021-06-30/feeds/{feed_id}", headers=headers, timeout=30) r.raise_for_status() feed = r.json() if feed["processingStatus"] in TERMINAL: break time.sleep(interval) doc_id = feed.get("resultFeedDocumentId") if doc_id is None: return feed["processingStatus"], None # 5. レポートのURLを取り、GZIPなら展開して読む r = requests.get(f"{BASE}/feeds/2021-06-30/documents/{doc_id}", headers=headers, timeout=30) r.raise_for_status() doc = r.json() raw = requests.get(doc["url"], timeout=60).content if doc.get("compressionAlgorithm") == "GZIP" and raw[:2] == b"\x1f\x8b": raw = gzip.decompress(raw) return feed["processingStatus"], json.loads(raw) ``` 本番でgetFeedのポーリングを回すと、毎秒2リクエストの枠には収まっても空振りの呼び出しが増えます。完了の待ち受けは後述のFEED\_PROCESSING\_FINISHED通知に置き換えてください。 ## JSON\_LISTINGS\_FEEDのペイロード構造 ### headerとreport.includedDataの指定 JSON\_LISTINGS\_FEEDの中身はheaderとmessagesの2部構成です。headerの必須項目はsellerIdとversionで、versionは文字列「2.0」の固定値です。issueLocaleを省くと、先頭マーケットプレイスの既定言語でエラーメッセージが返ります。 headerにreportを付けると、処理レポートにListings Items APIの出力を同梱できます。includedDataに指定できるのはsummaries、attributes、issues、offers、fulfillmentAvailability、procurement、relationships、productTypesの8種で、apiVersionは2021-08-01だけです。反映後の状態を確かめるためにgetListingsItemをSKUごとに呼び直す必要がなくなるので、25,000件規模のフィードではリクエスト数の節約が大きくなります。 ``` { "header": { "sellerId": "<出品者ID>", "version": "2.0", "report": { "includedData": ["issues"], "apiVersion": "2021-08-01" } }, "messages": [ { "messageId": 1, "sku": "MY-SKU-001", "operationType": "PATCH", "productType": "LUGGAGE", "patches": [ { "op": "replace", "path": "/attributes/fulfillment_availability", "value": [ { "fulfillment_channel_code": "DEFAULT", "quantity": 10 } ] } ] } ] } ``` ### operationTypeとrequirementsの選択 messagesの各要素ではmessageId、sku、operationTypeの3つが必須で、DELETEで出品を取り下げる場合も省けません。UPDATE・PARTIAL\_UPDATE・PATCHではさらにproductTypeが必須で、UPDATEとPARTIAL\_UPDATEはattributes、PATCHはpatchesも要ります。operationTypeを誤ると属性が消えます。UPDATEは属性一式を送る全置換で、送らなかった既存の属性は置き換えで失われます。在庫数だけを直したいときにUPDATEを選ぶと、他の属性まで巻き添えになります。 部分更新にはPARTIAL\_UPDATEかPATCHを使います。スキーマの説明文には、PARTIAL\_UPDATEはPATCHでopにreplaceを指定した場合と等価だと書かれています。PATCHのopはadd、replace、merge、deleteの4種で、pathで対象属性を指定します。在庫や価格のような単一属性の定期更新なら、影響範囲が最も狭いのはPATCHのreplaceです。送る前にペイロードを商品タイプ定義APIのJSON Schemaで検証しておくと、レポートで弾かれる件数を減らせます。検証ライブラリの選び方は[JSON Schemaとは？JSONの構造を検証する書き方とDraft 2020-12の実装を実装者目線で解説【2026年版】](/tech/details/16289/)にまとめています。 requirementsはLISTING、LISTING\_PRODUCT\_ONLY、LISTING\_OFFER\_ONLYから選び、既定値はLISTING（商品情報と販売条件の両方）です。指定できるのはoperationTypeがUPDATEのメッセージだけで、PATCH・PARTIAL\_UPDATE・DELETEに付けるとスキーマ違反になります。既存ASINへの相乗り出品で商品情報に触れたくないなら、LISTING\_OFFER\_ONLYで販売条件だけに絞ります。 ## 処理レポートの読み方とエラー対応 ### summaryと2層のissuesの構造 [処理レポートのスキーマ](https://github.com/amzn/selling-partner-api-models/blob/main/schemas/feeds/listings-feed-processing-report-schema-v2.json)では、トップレベルはheader、issues、summary、itemsの4部です。まずsummaryを見ます。errors、warnings、messagesProcessed、messagesAccepted、messagesInvalidのカウンタに加え、includedDataを指定したときはitemSummary（items・errors・warnings）が入ります。公式の例は4件処理して受理2件・不正2件、errorsは3件です。1メッセージに複数のエラーが付くので、エラー件数と失敗したSKUの数は一致しません。 **issuesは2層に分かれています。**トップレベルのissuesはメッセージの受理を妨げた問題で、messageId、sku、code、severity、message、attributeNameの組で返ります。一方、includedDataを指定したときだけ現れるitems配列の下にもitems\[\].issuesがあり、こちらはListings Items API側の出力です。フィールド名がattributeNames（複数形）になり、categoriesやenforcementsが付きます。トップレベルだけを走査する実装では、受理後に出た問題を丸ごと取り逃します。 severityはERROR、WARNING、INFOの3種です。issuesで必須なのはseverityとmessageだけで、messageIdは「メッセージに起因しないエラー（フィード書式の不正など）では返らない」とスキーマに書かれています。再送対象をmessageIdで絞る実装には、messageIdが無いときにskuで突き合わせる処理を用意してください。 ### 代表的なエラーコードと切り分け スキーマの例に載っているコードは、実装初期によく当たるものです。2層のどちらに出たかで対応の急ぎ具合が変わります。 | コード | severity | 出現箇所 | 内容 | 対処 | | ----- | -------- | ------- | ------------- | -------------- | | 90220 | ERROR | トップレベル | 必須属性の欠落 | 商品タイプ定義で要件を再取得 | | 99022 | ERROR | トップレベル | 値の個数が最低数に届かない | 最低個数を満たす値を設定 | | 18448 | WARNING | items配下 | 関連属性が未入力 | 不足属性を補完 | | 18027 | WARNING | items配下 | メイン画像に文字やロゴ | 規約に沿う画像へ差し替え | WARNINGを「受理されたから後回し」と読むのは危険です。公式の例では18027にenforcementsが付き、actionsにSEARCH\_SUPPRESSED、つまり検索結果からの非表示が記録されています。ただしこの例のexemption.statusはEXEMPT\_UNTIL\_EXPIRY\_DATEで、expiryDateまでは措置が猶予されており、summariesのstatusにもDISCOVERABLEが残っています。Listings Items APIのモデルには、期限を過ぎるとAmazonが記載の措置を実施すると書かれています。フィードが成功していても期限後は検索結果から外れるので、WARNINGでもenforcementsとexemptionの期限を必ず確認してください。 90220と99022は属性要件の不一致です。Discussion #3815でAmazonは、商品タイプ定義APIのJSON Schemaでは必須属性がカテゴリXSDより増えて見える場合があり、それは条件付きの必須まで正確に表すようになった結果だと説明しています。属性セットを決め打ちで使い回さないでください。 ## フィード運用の設計：キュー・レート制限・監視 ### 4階層のレート制限と実効スループット createFeedの毎秒0.0083リクエストは逆数で約120秒なので、「フィードは2分に1本しか送れない」と読みたくなります。ところがSP-APIのレート制限は、アプリケーション単位・出品者単位・オペレーション単位・データタイプ単位の4階層で、0.0083はオペレーション単位の既定値にすぎません。 JSON\_LISTINGS\_FEEDにはデータタイプ単位の別枠があり、Discussion #109の表では出品者単位の処理能力を1日3,600万件としています。1フィード25,000件で割ると、計算上は1日1,440本（およそ1分に1本）に相当します。ただしこれは件数の処理能力から逆算した値で、フィード本数の上限として公表されたものではありません。公式モデルのcreateFeedの説明にも「JSON\_LISTINGS\_FEEDのレート制限はcreateFeedオペレーションのレート制限とは異なる」とあるだけで、本数の具体値は示されていません。割り当ては出品者やアプリケーションごとにも変わるので、実装ではx-amzn-RateLimit-Limitの値で待ち時間を決めてください。 ### FIFOキューを前提にした優先度の分離と重複排除 運用で詰まる原因の多くはレート制限ではなく処理待ちです。Discussion #109は、送信の枠が大きいことは処理が速いことを意味しないと強調しています。送ったフィードはキューに積まれ、先入れ先出しで順に処理されるため、本数を増やしても個々のフィードの完了は早まりません。混雑時にはフィードにかなりの待ちが出るとも書かれています。 そこで次の3点を設計に組み込みます。 - **急ぎの更新を別フィードに分ける**：在庫切れの反映のような急ぎの更新が大量にあるときは、商品データの修正など急がない変更をいったん止め、在庫・価格だけのフィードを送ります。件数が少なければListings Items APIの優先レーンに回します。 - **同じ内容を送らない**：前回と同じ値の再送はキューを膨らませ、他の更新を遅らせます。Discussion #109には、カタログの書き込みにSKU単位の更新レート制限があり、同じSKUへ大量の更新を送ると処理が遅れるとも書かれています。SKUごとに最後に送った値のハッシュを持ち、差分だけを送る仕組みにします。 - **急がない更新は1日に分散する**：変更が起きるたびに送るのではなく、一定件数か一定時間でまとめ、ピークを避けて送ります。 SKU単位でフィードを作る実装は、どの階層で見ても成り立ちません。更新対象をいったんキューに溜めて1ファイルにまとめる構成は、[Amazon SQSとは？FIFOキューと標準キューの違い・重複排除・可視性タイムアウトとDLQの設計【2026年10月】](/tech/details/17241/)で扱った重複排除の考え方がそのまま使えます。 ### 完了通知と出品状態の監視 完了の待ち受けはNotifications APIのFEED\_PROCESSING\_FINISHEDで行います。[通知のスキーマ](https://github.com/amzn/selling-partner-api-models/blob/main/schemas/notifications/FeedProcessingFinishedNotification.json)では、ペイロードにfeedId、feedType、processingStatus（DONE・CANCELLED・FATALのいずれか）、resultFeedDocumentIdが入ります。通知を受けたらresultFeedDocumentIdでgetFeedDocumentを呼べばよく、getFeedのポーリングが要らなくなります。[Notifications APIのモデル](https://github.com/amzn/selling-partner-api-models/blob/main/models/notifications-api-model/notifications.json)で定義されている配信先はAmazon SQSとAmazon EventBridgeの2種で、任意のHTTPエンドポイントには送れません。FEED\_PROCESSING\_FINISHEDはSQSキューで受けます。[公式サンプルの通知種別定義](https://github.com/amzn/selling-partner-api-samples/blob/main/use-cases/notifications/app/config/notification-type-definition.json)でもSQS側にだけ分類されており、EventBridge側に並ぶのはLISTINGS\_ITEM\_STATUS\_CHANGEやLISTINGS\_ITEM\_ISSUES\_CHANGEなどです。 フィードの完了は出品の健全性を保証しません。受理されたあとで画像の問題による検索非表示が付くこともあるので、出品側の通知も購読し、フィードの完了後に起きた出品の変化まで追えるようにします。[LISTINGS\_ITEM\_ISSUES\_CHANGE](https://github.com/amzn/selling-partner-api-models/blob/main/schemas/notifications/ListingsItemIssuesChangeNotification%5F2023-12-13.json)は出品の問題が作成・変更・解消されたときに届き、SKU、重大度（ERROR・WARNING・NONE）、Amazonが取った措置（EnforcementActions）を含みます。[LISTINGS\_ITEM\_STATUS\_CHANGE](https://github.com/amzn/selling-partner-api-models/blob/main/schemas/notifications/ListingsItemStatusChangeNotification.json)は、購入可能（BUYABLE）・検索可能（DISCOVERABLE）・削除（DELETED）の状態が変わったときに届きます。 ### 再送信の範囲とサンドボックスの限界 再送はエラーになったメッセージだけを抜き出して行い、ファイル全体を投げ直さないでください。全件の再送は投入枠を消費し、受理済みのSKUに不要な更新を走らせ、キューを詰まらせます。issuesのskuとmessageIdから再送ファイルを組み立て、処理できなかった更新は[デッドレターキュー（DLQ）とは：退避条件・再処理・監視の設計とSQS・Pub/Sub・Service Busの設定例](/tech/details/19037/)のように別の置き場へ退避して、原因を直してから戻します。バーストの15回分は平常時に使い切らず、障害時の再送用に残しておくと、復旧直後に429で待たされにくくなります。 Feeds APIの公式モデルには全6オペレーション分のサンドボックス応答（x-amzn-api-sandbox）が定義されています。ただし返るのは固定の応答で、実データの処理結果は再現されません。属性要件やエラーコードの確認は、少量のテスト用SKUを本番に送って行う計画にしてください。モール連携の仕組み全体を外部に任せる場合は、[API開発・システム連携](/service/system/api/)の支援内容も比較材料になります。 ## よくある質問 ### フィードAPIとレポートAPI、Data Kiosk APIの違いは何ですか？ データの向きと取り方が違います。Feeds APIは出品者からAmazonへデータを送るAPIで、公式モデルも「出品パートナーに代わってAmazonへデータをアップロードする」と説明しています。売上や在庫の実績をAmazonから取り出すのはReports API、GraphQLのクエリで分析用データを問い合わせるのがData Kiosk APIです。送るならFeeds、定型の帳票ならReports、集計を柔軟に問い合わせるならData Kioskと分けると迷いません。 ### 1回のフィードで複数のマーケットプレイスへ送れますか？ 同じリージョン内なら送れます。createFeedのmarketplaceIdsは配列で、モデルの定義は最小1件・最大25件です。日本・オーストラリア・シンガポールのように極東リージョンに揃い、かつheaderのsellerIdの出品者アカウントが出品しているマーケットプレイスの範囲なら、同じフィードドキュメントをまとめて適用できます。米国は北米リージョンでエンドポイントが別なので、日本と米国を1回のフィードにまとめることはできません。属性要件はマーケットプレイスごとに違う場合があるため、まとめる前に商品タイプ定義APIで要件を突き合わせてください。 ### processingStatusがDONEなら全件成功したと考えてよいですか？ いいえ。DONEはフィード全体の処理が終わったことを示すだけです。公式スキーマの例でも、4件処理して受理は2件という結果でフィードはDONEになっています。処理レポートのmessagesAcceptedとmessagesInvalid、itemSummaryのwarningsまで確認してください。 ### v2021-06-30なら暗号化の実装はもう不要ですか？ API仕様として課されていた暗号化・復号は不要になりました。旧v2020-09-04のモデル（現在は公式リポジトリから削除済み）にはFeedDocumentEncryptionDetailsがあり、standardにAES、initializationVectorにCBC用のベクトルを指定してドキュメントをクライアント側で暗号化・復号する必要がありましたが、現行モデルにこれらの項目はありません。一方で公式の[ドキュメント用ヘルパーのREADME](https://github.com/amzn/selling-partner-api-models/blob/main/clients/sellingpartner-api-documents-helper-java/README.md)は、保存時の暗号化を開発者の責任とし、暗号化していないドキュメントの中身は一時的であってもディスクに保存しないよう求めています。なくなったのは自前のAES処理であって、データ保護の義務ではありません。 ### 広告で使う「データフィード」とは別のものですか？ 別物です。この記事のフィードAPIはAmazon SP-APIの機能で、Amazonへ商品情報を送るためのものです。ショッピング広告などで使う「データフィード」は、各広告媒体の仕様に合わせて商品データを整形・最適化する運用の話で、対象も目的も違います。こちらは[DFO（データフィード最適化）とは？ツール料金比較と媒体別フィード仕様の実務](/column/details/7977/)で扱っています。 ## 関連記事 - [Amazon SQSとは？FIFOキューと標準キューの違い・重複排除・可視性タイムアウトとDLQの設計【2026年10月】](/tech/details/17241/) - [JSON Schemaとは？JSONの構造を検証する書き方とDraft 2020-12の実装を実装者目線で解説【2026年版】](/tech/details/16289/) - [Shopify APIとは：Admin・Storefront・Webhookの使い分けとレート制限をコードで解説](/tech/details/18947/) - [REST APIとGraphQLの違い｜利点・欠点と選び方、キャッシュ・エラー・負荷を実測で比較](/tech/details/3591/) - [DFO（データフィード最適化）とは？ツール料金比較と媒体別フィード仕様の実務](/column/details/7977/) --- 出典: [SP-APIフィードAPI（Feeds API）の使い方｜JSON\_LISTINGS\_FEEDの送信手順とPython実装]()（株式会社一創）