楽天の在庫更新を自動化｜SKU移行後に選ぶ在庫API

SKU移行済みかどうかで、使う在庫APIが変わる

楽天市場では2023年4月からSKUプロジェクトが順次進んでおり、移行した店舗では従来の在庫APIが使えなくなります。

SKUとは、色やサイズなど在庫を数える最小の単位です。SKUプロジェクトは、商品の管理単位を商品ページごとからSKUごとへ変える入れ替えを指します。2023年4月から全店舗を対象に、順次移行が進められてきました。

これが在庫の自動更新に直結します。SKUへ移行した店舗では、従来の在庫API（InventoryAPI）が利用できなくなります。在庫API 2.0（InventoryAPI 2.0）への移行が必要です。商品API（ItemAPI）も同じで、商品API 2.0（ItemAPI 2.0）へ移ります。

そのため、連携を組む前に自店の移行状況を確かめます。移行済みの店舗が従来の在庫APIを指定すると、認証が通っても在庫連携そのものが動きません。移行の時期は店舗ごとに違うので、RMSの管理画面で自店の状態を確認してください。

自作と外部サービスでは、費用の決まり方が違う

何を比べる表か：在庫連携の2つの方法（自作／外部サービス）に、任意で足すAI活用を並べ、費用の決まり方と向いている店舗を比べます。

この表からわかるのは、「在庫の自動更新」と「商品情報の作成」が別の投資判断だということです。在庫連携は一度組めば運用の手間が小さくなりますが、初期の開発工数は要件で変わります。商品情報の作成のほうは、手元の商品データを流し込むところから始められます。

自作の見積もりが読めないときは、外部サービスの料金を物差しにすると判断しやすくなります。ネクストエンジンは楽天市場のRMSとAPI連携（無料）により、在庫を24時間365日自動連携する機能を提供しています。サービス自体の料金は初期費用0円・月3,000円（受注200件まで）です。そこから先は201〜400件が1件35円、1,001〜3,000件が1件25円と、受注件数が増えるほど単価が下がります。別に年間保守費用15,000円（税抜）がかかります。

自店の月間受注件数を当てはめれば、外部サービスを使ったときの月額が出ます。その金額と、自作にかかる開発費を何年で取り戻せるかを比べる。これが現実的な判断の順序です。

→ くわしくは「AI導入費用は月1万円から｜3タイプ別の内訳」で解説しています。

在庫API連携を組む5つのステップ

在庫連携そのものに必要なのは、ステップ1・2・3・5の4つです。ステップ4のAI活用は任意で、在庫の自動更新が動いてから足せます。

RMSのWEB APIサービスでアプリ登録する

楽天RMSの管理画面から、WEB APIサービスの利用申請をします。

このとき、使うAPIの利用設定にチェックを入れます。SKU移行済みなら在庫API 2.0（InventoryAPI 2.0）と商品API 2.0（ItemAPI 2.0）を選びます。未移行なら従来の在庫API（InventoryAPI）です。ここを取り違えると、認証が通っても在庫が更新されません。

認証情報を取得してESA認証を組む

アプリ登録が終わると、serviceSecretとlicenseKeyという2つの値が発行されます。

楽天RMS APIの認証方式はESA認証と呼ばれます。この2つの値をコロンでつなぎ、Base64という方式で変換した文字列を、リクエストの見出し部分（Authorizationヘッダー）に指定します。開発の担当者は、この認証情報を毎回のリクエストに付ける処理を組みます。

在庫APIで在庫数を取得・更新する

SKUに移行した店舗が使うのは在庫API 2.0（InventoryAPI 2.0）です。

在庫情報の取得と更新に対応しており、自社の在庫管理システムやECカートの在庫数とつなぐと、在庫情報をリアルタイムに近い形で更新できます。連携が動くには、licenseKeyの中で在庫API 2.0が「利用中」になっている必要があります。在庫切れや過剰在庫を防ぐ効果が期待されていますが、実際にどれだけ減るかは店舗の運用状況によって変わります。

ChatGPT APIで商品情報の作成を助ける

在庫の数字の更新とは別に、商品名や説明文の作成にChatGPT APIを使う方法があります。

商品名をSEOルールに沿って一括で見直す使い方があり、商品数が多い店舗ではCSVデータをまとめて処理する方法が効率的とされています。応用として、楽天RMS APIのMCPサーバー（AIの道具に外部のシステムをつなぐ窓口）を自作した事例も報告されています。Claude Codeから話し言葉で、商品名の変更や価格の変更、全商品のExcel出力を指示するという内容です。

これは在庫更新そのものではありませんが、在庫API連携と組み合わせると、商品管理全体の手作業を減らせる可能性があります。

licenseKeyの更新を仕組みにする

licenseKeyは一定期間ごとに更新処理が必要です。

更新しないとその時点で自動連携が止まります。更新の時期をカレンダーや監視の仕組みに登録しておかないと、止まったこと自体に気づけません。

SKUの移行状況と開発体制で、選ぶ道が分かれる

自店がSKUに移行済みかどうかと、社内に開発できる人がいるかどうかで、選ぶべき手段が変わります。

図：SKUの移行状況と開発体制から選ぶ判断フロー

この図は、SKUの移行状況を最初の分かれ目にしています。そこで使えるAPIが決まってしまうため、開発体制の話より先に確かめる必要があるからです。

次に見るのは、社内に実装できる人がいるかどうかです。いなければ外部サービスを使うか、初期構築だけを外注して日常運用は自社で回す道があります。どちらも難しければ、無理に自作せず外部サービスから試すのが安全な進め方です。

連携が止まる原因は、licenseKeyの期限切れ

licenseKeyの更新を忘れると自動連携が止まり、在庫の数字がずれたまま販売を続けてしまうリスクがあります。

楽天RMS APIの認証方式は、更新を前提とした仕組みになっています。またAPIの仕様は変わることがあり、SKUプロジェクトのように使うAPIそのものが入れ替わる場合もあります。定期的に公式情報を確認する運用が要ります。

対処は2つです。licenseKeyの更新期限を社内カレンダーに登録すること。そして、API連携が止まっていないかをログで定期的に確かめることです。担当者が一人しか把握していない状態を避けておけば、休職や異動があっても連携は止まりません。

初期構築と日常運用は、担当を分けて考える

API連携を組むには開発知識が必要ですが、運用が始まったあとの日常業務は開発知識がなくても回せます。

アプリ登録・認証設定・API呼び出しの実装は、社内エンジニアか外部の開発会社が担当するのが現実的です。一方、ChatGPT APIで商品名をまとめて見直すようなCSV処理は、手順にしてしまえばEC担当者が定期的に回せる作業になります。

体制を考えるときは「誰が作るか」と「誰が日々動かすか」を分けます。初期構築を外注した場合でも、licenseKeyの更新時期とAPIエラー時の連絡先を1つのマニュアルにまとめておいてください。そうすれば、担当者の異動や休職があっても運用を引き継げます。

手作業の更新とAPI連携は、何が変わるか

何を示す表か：在庫API連携によって、在庫更新の手作業がどう変わる傾向にあるかを整理します。

この比較からわかるのは、在庫更新の自動化が作業時間の削減だけでなく、在庫切れや過剰在庫という機会損失の防止にもつながる可能性があるという点です。手作業の更新では、担当者が忙しい日に反映が遅れ、売り越しや欠品が起きることがあります。

ただしこれは一般的な傾向で、削減される具体的な時間数を示す出典は確認できていません。自社での効果を見積もるなら、まず現状の在庫更新にかかっている時間を実際に計測してください。導入後も作業時間を記録し、自社のデータで確かめていく進め方が現実的です。

FAQ

自社の業務に合わせたAIツールの選定・導入は、ぜひ、ジッソウLABのゲンバAIへ無料でご相談ください。