楽天市場 API は、楽天市場の商品データ・ランキング・ジャンル情報をプログラムから取得するための API だ。価格比較サイトや商品紹介ツールを作るとき、楽天の巨大な商品カタログを情報源として使える。

何ができるか

商品のキーワード検索とジャンル検索、ジャンル別ランキング、価格・レビュー・在庫を含む商品詳細の取得が基本機能だ。ジャンル一覧をツリー構造で取得できるため、カテゴリ別の比較ページを機械的に組み立てられる。楽天ブックスや楽天トラベルといった他サービスも横断的に検索できる点は、ECに閉じない情報サイトを作るときに効いてくる。

収益化との接続

楽天ウェブサービスへの登録で無料利用でき、楽天アフィリエイトと連携すれば商品紹介がそのまま収益につながる。個人開発者が「商品検索アプリ+アフィリエイト」という形でマネタイズしやすい設計になっているのは、この API の現実的な魅力だ。

設計上の制約を見落とさない

無料で使える代わりに、API には呼び出し回数の上限がある。商品データを大量に取得してまるごと自前 DB に複製するような使い方は制限に当たりやすく、利用規約上もデータの保存範囲には条件がある。検索結果はその場で表示に使い、必要なら短時間のキャッシュにとどめる設計が無難だ。返ってくる価格や在庫はあくまで取得時点のスナップショットで、リアルタイムの正確さは保証されない点も、価格比較を謳う以上は表示上の注意書きで補っておきたい。

用途の取り違えに注意

ここで誤解しやすいのが、楽天市場 API は「買い手側」の API だという点だ。商品を探す・紹介する用途のためのもので、楽天市場への出品や受注管理といった「売り手側」の操作はできない。店舗運営の自動化をしたいなら RMS API という別の仕組みを見る必要がある。価格比較やアフィリエイトという用途に絞れば、データ量と無料という条件はかなり強い。Amazon のアフィリエイト API と並べて使い、両モールの価格を横断比較するページを作ると情報サイトとしての厚みが増すが、その場合は各 API の規約や利用条件をそれぞれ満たす必要がある点は押さえておきたい。

🟡
アプリ ID とアフィリエイト ID は別物です。付け忘れると 1 円も入りません

API を呼ぶための識別子と、成果を紐づけるための識別子は別のパラメータです。アフィリエイト用の ID を渡さなくてもリクエストは正常に成功し、商品データも普通に返ってきます。エラーにならないため気づきにくく、「動いているのに成果が計上されない」という形で数週間後に発覚します。実装したら、返ってきた商品リンクがアフィリエイト用の URL になっているかを目で確認してください。

表示に条件が付く

楽天ウェブサービスのデータを使うページには、楽天のサービスを利用している旨の表示が 求められる。個人開発の小さなツールでも例外ではなく、規約上の条件として扱われる。 デザインを詰める前に、フッターなどに置く場所を決めておくと後戻りが減る。

「全件取得」はできない前提で設計する

検索 API は 1 回のリクエストで返る件数と、ページ送りできる深さの両方に上限がある。 掛け合わせた総数を超えた先の商品には、同じ検索条件では到達できない。ジャンルや 価格帯で条件を細かく割って、それぞれの範囲を取りに行くのが定石になる。

これは前述のキャッシュ制約とも噛み合う。カタログ全体を自前に持つ設計はそもそも 成立しないので、ユーザーの検索条件をそのまま API の条件に落とす素直な作りにした方が、 規約にも仕様にも沿う。並び順も API 側の指定に従うことになるため、取得後に独自の ランキングロジックで並べ替えたいなら、その分だけ多めに取ってから加工する必要がある。

ランキングは商品検索 API では取れない

つまずきの多くはここに集約される。楽天ウェブサービスは用途ごとに別々の APIとして 公開されており、キーワードやジャンルで商品を探す商品検索 API と、 売れ筋を返すランキング API は別のエンドポイントになっている。

商品検索 API にも並び替えの指定はあるが、それは検索結果内の並べ替えであって 「楽天市場で売れている順」ではない。商品検索 API をどう工夫してもランキングは 再現できないので、ランキングが欲しいならランキング API を呼ぶ。 ジャンル・性別・年代といった切り口で絞り込める。

🟡
ランキングは「いま」の順位で、過去に遡れません

返ってくるのは取得時点のランキングです。年次・月次の推移を後から取りにいく仕組みはないため、履歴が欲しければ自分で定期取得して蓄積するしかありません。「去年のランキングを分析したい」という用途は、今日から貯め始めない限り成立しません。分析を目的に使うなら、設計の最初に保存を組み込んでください。

ジャンル指定は ID で行う

カテゴリで絞り込むとき、渡すのは名前ではなくジャンル ID になる。ジャンルは 木構造になっていて、ジャンル情報を返す API で親子をたどって目的の ID を得る、 という手順を踏む。「家電」のような文字列を投げても絞り込めないので、 最初にジャンルの階層を一度取得して手元に持っておくと開発が進む。

キーワードとジャンルは併用できる。範囲を絞ってから検索する形にすると、 後述の取得件数の上限にも当たりにくくなる。

価格比較を作るときに実際に効く制約

価格比較の表を組みたい、という用途は多い。ただし返ってくる価格は取得時点の値で、 在庫や送料込みの実売価格を保証するものではない。表示するなら取得時刻を添えて、 最終的な価格は各ショップのページで確認してもらう導線にしておくのが安全だ。

同じ商品が複数のショップから出品されるため、何をもって「同一商品」とみなすかは 自分で決める必要がある。JAN コードが取れる商品なら束ねやすいが、 取れないものも多い。商品名の文字列一致に頼ると、容量違い・色違いが 同一視されて表が壊れる。比較軸を先に決めてから実装したい。

料金は「無料、ただし条件付き」

楽天ウェブサービスに登録すれば無料で使える。月額も従量課金も発生しない。 その代わりに、呼び出し回数の上限、データの保存範囲、表示に関する条件が 規約側で定められている。費用ではなく規約が制約になるタイプの API だと 捉えておくと、設計の判断を誤らない。