はじめに

Amazonの受注を、受注管理ツールや自作のスクリプト、Makeのような自動化サービスで取り込んでいる事業者は多いと思います。普段は動いていて当たり前なので、中身がどのAPI（システム同士をつなぐ窓口）を使っているかを把握している担当者は、意外と少ないものです。

Amazonの開発者向けドキュメントには、注文情報を取得するOrders APIの旧版（v0）が非推奨（deprecated）になり、新版（v2026-01-01）へ移行するよう求める告知が出ています。主要な取得オペレーションの移行期限は2027年3月27日と書かれています（出典: Amazon SP-API 変更履歴）。2026年10月時点で、期限まで約5か月です。

先に断っておくと、これは「予告」であり、止まると決まったわけではありません。ベンダーが対応を済ませていれば、何も起きない可能性は十分にあります。ただ、止まったときの影響は大きく、確認自体は聞くだけで済みます。この記事では、経営者や事業責任者が担当者やベンダーに投げるべき3つの問いと、確認しなくてよい場合を整理します。なお、この記事は公式ドキュメントの記述を読んで整理したもので、個々のツールや自社環境での動作は確認していません。

何が予告されているのか

公式の告知で読み取れる範囲は次のとおりです。Orders API v0が非推奨であること。getOrders、getOrder、getOrderBuyerInfo、getOrderAddress、getOrderItems、getOrderItemsBuyerInfoといった主要オペレーションについて、v2026-01-01への移行期限が2027年3月27日であること。現行の仕様はOrders APIのドキュメントにまとまっています。

ここで注意したいのは、移行期限と、個々のオペレーションの廃止日は別の話かもしれない点です。廃止日は別の廃止スケジュール（deprecation schedule）に載っているようですが、自分はそちらを確認できていません。「3月27日に必ず止まる」とは書かず、「その日を目安に移行が求められている」と受け止めるのが正確です。

また、Makeのヘルプ（Amazon Seller Central Ordersモジュールの更新）でも、v0ベースの旧モジュールを2027年3月27日に廃止すると案内されています。旧モジュールは新規シナリオでは作れず、既存のシナリオは期限まで動く、という内容です。Makeで組んでいる場合は、置き換え先のモジュールへの切り替えが必要になります。

新版では、1回のリクエストで注文情報をまとめて取得でき、必要な項目をincludedDataで選べる、個人情報の取得に別のトークン用APIが要らなくなる、といった変更が示されています。つまり、単に宛先が変わるだけではなく、データの取り方と形も変わります。

確認する3つのこと

1. いま使っている連携は、旧版（v0）を使っているか

最初の問いはこれです。受注管理ツールを使っているなら、ベンダーのサポートに「Amazon連携はOrders APIのv0を使っていますか。2027年3月27日の移行期限は把握していますか」と聞いてください。自作スクリプトなら、作った人か保守している人に同じことを聞きます。Makeなら、使っているモジュールの種類を確認します。

ここで「分からない」という答えが返ってくることがあります。その場合は、誰も把握していない連携が動いている状態です。担当者が退職していたり、外注先が当時のままだったりすると、期限までに誰が直すのかが決まっていません。この段階で見つかるのは、むしろ良いことです。

2. ベンダーの対応予定と時期はいつか

v0を使っていると分かった場合の次の問いは、「いつまでに、誰が、新版へ移すのか」です。回答は口頭ではなく、メールや告知ページなど文書で残る形でもらうのが安全です。

見るべき点は2つあります。1つは、対応時期が期限より十分前か。期限間際の対応だと、不具合が出ても直す時間がありません。もう1つは、対応が追加費用になるのか、既存の契約の範囲なのかです。ここは契約ごとに違うので、金額を一般論では言えません。自社の契約書か、ベンダーの料金ページで確認してください。自作スクリプトの場合は、直す人の工数がそのまま費用になります。

3. 移行後に表記が変わる項目を使った集計がないか

見落としやすいのは、この3つ目です。移行ガイドには、項目名や値の表記が変わる例が出ています。たとえば注文IDの項目名がAmazonOrderIdからOrder.orderIdに変わること。出荷区分（FulfillmentChannel）の値がMFNからMERCHANT、AFNからAMAZONに変わること。注文ステータスの値の表記が変わり、たとえばCanceledがCANCELLED（Lが2つ）になること。価格がproceeds.breakdownsという入れ子の構造で返ること。NumberOfItemsShippedなど、新版で対応していない項目があること、です。

連携ツールが吸収して従来どおりの形で渡してくれるなら問題ありません。ただ、ツールが値の対応を直さないまま新版に切り替わると、「自社出荷（MFN）の売上だけ集計する」といった条件に一致する行が突然ゼロになる、といったずれが起きる可能性があります。エラーは出ず、数字だけが静かにずれます。

確認の方法は単純です。社内のスプレッドシートや集計表で、出荷区分やステータスの値を条件にしているものがないかを担当者に聞いてください。あれば、移行後の値で動くかをベンダーに確認します。受注と売上の数字がもともと合いにくい構造については、楽天とAmazonで売上の数字が合わないのは、集計ミスではないかもしれないでも触れています。楽天・Amazon・自社ECの売上を1か所に集める全体像は、楽天・Amazon・自社ECの売上データを一元管理する方法で整理しています。

確認にかかる費用と時間

1つ目と2つ目の確認は、ベンダーや担当者に問い合わせを1通送るだけです。費用はほぼかからず、返事を待つ時間が主です。3つ目も、集計表の中身を担当者に見てもらう作業が中心で、大きな費用にはなりません。費用が発生しうるのは、確認の結果「移行が必要」と分かったあとです。その額は、契約形態や連携の作りで変わるため、ここでは書けません。

逆に、確認を後回しにして期限が近づくと、ベンダーの対応が混み合う、テストの時間が取れない、といった問題が起きやすくなります。数字が静かにずれる場合は、気づくまでの期間の売上データがやり直しになるおそれもあります。早く聞くほど選択肢が残ります。

確認しなくてよい場合

次のような場合は、この件に時間を使う必要はありません。

  • Amazonの受注を自動で取り込んでいない。Seller Centralからレポートを手でダウンロードして使っているだけなら、このAPIの移行は直接関係しません。
  • 使っているツールのベンダーが、v2026-01-01への対応済みであることを文書で示している。問い合わせ回答やリリースノートなど、後から確認できる形であれば、重ねて調べる必要は薄いです。
  • 取り込んだデータを、出荷区分やステータスの値で集計していない。受注件数を数えるだけなら、表記の変更の影響は小さい可能性があります。

反対に、一つでも「分からない」が出る場合は、聞いてみる価値があります。聞いて対応済みと分かれば、それで終わりです。

まとめ

Amazonの受注取り込みで使われるOrders APIの旧版は、2027年3月27日を期限に新版への移行が告知されています。ただし、これは予告であり、個々の廃止日は別のスケジュールにあるため、止まる日が確定しているわけではありません。

確認するのは3点です。連携が旧版を使っているか。ベンダーはいつ対応するか。出荷区分やステータスの表記変更で、集計やスプレッドシートがずれないか。確認自体は問い合わせを送るだけで済みます。分からない連携があること自体が、先に見つけておくべきリスクです。

自社の連携がどれに当たるのか分からない、ベンダーの回答をどう読めばよいか迷う、移行後の集計のずれを事前に確かめたい、といったときは、単発で相談を受ける形もあります。スポット相談で状況を整理するか、お問い合わせから現在の連携の構成を教えてください。