楽天のSKUプロジェクトによるAPIの仕様変更【場合別の対応手順】
楽天のSKUプロジェクトが進んでいる。これは楽天での商品管理をAmazonのようにすることを目指すものだ。
具体的には、ある商品のサイズ違い、色違いなどがある場合、今までの楽天の仕様だと異なる商品管理番号が割り振られていたが、SKU移行後は同じ商品管理番号の中にSKU管理番号が割り振られることになる。
楽天の言い分によると、SKUプロジェクトによって利用者は今までより買い物がしやすくなるし、店舗側は商品管理がしやすくなるらしい。
このSKUプロジェクトによって楽天APIの仕様が変わる。APIを利用したツールを使っている人は、SKU移行後に必ず影響を受ける。
- ネクストエンジンやクロスモールなどの市販ツールを使っている人
- APIソフト開発者
- スポットで他人・他社に作ってもらったEC運営ソフト利用者
ネクストエンジンやクロスモールなどの市販ツールを使っている人
これはサービス提供元がAPIの仕様変更に必要な対応してくれるので、特に気にする必要はないだろう。店舗側で必要な作業が発生する場合は、サービス提供元から通知があるはずだ。
APIソフト開発者
楽天のAPIソフト開発者も影響を受けるが、仕様変更を自分で把握して対応できるので問題ないだろう。SKU移行に伴うAPIで影響のある部分は以下の通り。
商品API
商品APIはSKU移行後に利用できなくなるので、商品API 2.0（ItemAPI 2.0）への移行が必須。
在庫API（InventoryAPI）
在庫API（InventoryAPI）はSKU移行後に利用できなくなるので、在庫API 2.0（InventoryAPI 2.0）への移行が必須。在庫周りはEC運営において致命的なので要注意。ただ、仕様変更といっても対応するのはそんなに大変ではない。詳しくは楽天のSKU移行に対応した在庫API 2.0（InventoryAPI 2.0）にPythonでアクセスするを参照。
ジャンル・タグ検索API（NavigationAPI）
SKU移行後に利用できなくなるのでジャンル・商品属性情報検索API（NavigationAPI 2.0） への移行が必須。
購入商品API（PurchaseItemAPI）
これはマイナーチェンジの範疇だろうが、場合によっては地味に面倒くさい修正が必要となるかもしれい。
スポットで他人・他社に作ってもらったEC運営ソフト利用者
一番影響を受けそうなのがこのパターンである。過去に自動化・効率化のツールを知人や他社、クラウドソーシングなどで一度きりの依頼で作ってもらい、その後も使い続けているというパターン。
このパターンに該当する人は、SKU移行後に突然ソフトが使えなくなるという悲惨な目に遭う。一般の市販ソフトへの乗り換えの検討や、使用中のソフトの修正などの対応が発生する。はやめに開発をしてもらった人に連絡しよう。
お困りの方はこちらよりご相談ください。なんらかの提案ができるかもしれないので。
