楽天市場の商品検索APIを使っていて、こんな状況に心当たりはないでしょうか。

昨日まで普通に動いていたアフィリエイトツール・価格比較ツールが、ある日突然エラーを返すようになった
app.rakuten.co.jp 系のエンドポイントを叩いているコードが、直しようのない失敗を繰り返している
新しい仕組みに乗り換えようとしたら、キーを正しく渡しているはずなのにリクエストが弾かれる

私も楽天商品検索APIを使う個人開発ツールでこれを踏みました。結論から言うと、旧 Rakuten Web Service API（app.rakuten.co.jp 系）は 2026年5月13日に廃止されており、新APIはエンドポイントも認証方式も別物になっています。しかも新認証には「Refererヘッダ必須」という、サーバーサイド開発者が高確率でハマるポイントがあります。

この記事で分かることは次の3つです。

旧APIの廃止と、新API（openapi.rakuten.co.jp の Ichiba MS 系）への移行で何が変わったか
新認証の3点セット（applicationId / accessKey / Referer）と、最大のハマりポイントの回避方法
移行時に確認すべきこと（未提供APIの存在・依存機能の棚卸し・検証の順番）

なお、本記事の内容は執筆時点（2026年）に筆者が移行検証した範囲の情報です。パラメータ名やパスなどの細部は今後変わる可能性があるため、実装時は必ず楽天の公式デベロッパードキュメントを確認してください。

何が起きたのか：旧APIは2026年5月13日に廃止された

旧来の Rakuten Web Service API（app.rakuten.co.jp 系のエンドポイント）は、2026-05-13 に廃止されました。

つまり、旧エンドポイントを叩き続けているコードは、コード側に一切バグがなくても動かなくなります。「自分のツールが壊れた」のではなく「叩いている先が消えた」わけです。

厄介なのは、この手の外部APIの廃止は自分のツールのエラーとして観測される点です。ログ上は突然の4xxエラーの急増として現れるので、まず自分のコードや認証設定を疑ってしまい、原因特定に時間を溶かしがちです（私もそうでした）。

新旧APIの比較

移行検証で確認できた範囲での新旧比較です。

項目	旧API	新API（執筆時点）
ホスト	`app.rakuten.co.jp` 系	`openapi.rakuten.co.jp`（Ichiba MS 系。例: `/ichibams/api` 配下）
状態	2026-05-13 廃止	稼働中（ただし一部APIは未提供、後述）
認証キー	旧形式のアプリID	applicationId（UUID形式）+ accessKey（`pk_` で始まるキー）の2つ
Refererヘッダ	（旧構成では意識せず動いていた）	送信必須。無いと弾かれる
キーの互換性	—	旧キーは流用不可。新方式のキーを取得し直す必要がある

ポイントは2つです。

認証方式が別物。旧APIで使っていたキーをそのまま新エンドポイントに投げても通りません。新方式の applicationId と accessKey を取得し直す必要があります。
Refererヘッダが必須。これが本記事最大のポイントなので、次のセクションで掘り下げます。

最大のハマりポイント：Refererヘッダ必須

新APIでは、applicationId と accessKey を正しく渡していても、Refererヘッダが無いとリクエストが弾かれます。

なぜこれがハマりポイントになるかというと、Refererはブラウザが自動で付けるヘッダだからです。ブラウザ上のJavaScriptから呼ぶ分には勝手に付きますが、以下のようなサーバーサイドからの呼び出しではデフォルトで付きません。

Node.js の fetch / axios
Python の requests
curl（オプション指定なしの場合）
GitHub Actions や Cron ジョブ内のスクリプト

アフィリエイトツールや価格比較ツールは、バッチ処理やAPIルートなどサーバーサイドから叩く構成が大半のはずです。つまりこの読者層のほぼ全員が該当します。「キーは合っているのに弾かれる」となったら、まずRefererを疑ってください。

まず最小構成で認証だけ通す（curl例）

移行検証の鉄則は、アプリケーションに組み込む前に、curl等の最小構成で「認証が通ること」だけを先に確認することです。認証とアプリのロジックを同時にデバッグすると、切り分けができなくなります。

# -H "Referer: ..." が肝。これを外すと弾かれる
curl -sS \
  -H "Referer: https://your-app.example.com/" \
  "https://openapi.rakuten.co.jp/ichibams/api/<商品検索系のパス>?applicationId=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&accessKey=pk_xxxxxxxxxxxxxxxx&keyword=%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC"

applicationId は UUID形式の値が入ります
accessKey は pk_ で始まるキーです（上記はダミー表記です。実際のキーは公開リポジトリやクライアントサイドに置かないでください）
具体的なパスやパラメータの渡し方は執筆時点の構成に基づく一例です。必ず公式ドキュメントで最新仕様を確認してください

これで正常なレスポンスが返ることを確認してから、初めてアプリケーションコードに手を入れます。

fetch でRefererを明示的に付ける（Node.js例）

サーバーサイドの fetch では、Refererを自分でヘッダに書く必要があります。

const params = new URLSearchParams({
  applicationId: process.env.RAKUTEN_APPLICATION_ID, // UUID形式
  accessKey: process.env.RAKUTEN_ACCESS_KEY,         // pk_ で始まるキー
  keyword: 'コーヒーメーカー',
});

const res = await fetch(
  `https://openapi.rakuten.co.jp/ichibams/api/<商品検索系のパス>?${params}`,
  {
    headers: {
      // サーバーサイドではRefererは自動で付かないため、明示的に指定する
      Referer: 'https://your-app.example.com/',
    },
  }
);

if (!res.ok) {
  // 認証エラーとその他のエラーを切り分けられるよう、ステータスは必ずログに残す
  throw new Error(`Rakuten API error: ${res.status}`);
}

const data = await res.json();

キーは環境変数から読み込み、コードやリポジトリに直書きしないようにしてください。

落とし穴：全APIが新環境に揃っているとは限らない

ここも移行前に知っておきたいポイントです。

筆者が移行検証した時点では、Ranking系・Genre系のAPIは404が返り、未提供の状態でした（商品検索の ItemSearch 系は動作していました）。

つまり「旧APIで使っていた機能を新APIにそのまま置き換えれば終わり」とは限りません。移行作業の前に、次の棚卸しをおすすめします。

自分のツールが旧APIのどのエンドポイントに依存しているかを洗い出す
それぞれについて、新環境に対応するAPIが実際に提供されているかを（ドキュメントだけでなく実際のリクエストで）確認する
未提供のものがあれば、その機能を一時停止するか、別の手段で代替するかを先に決める

ランキング表示やジャンル絞り込みを主機能にしているツールの場合、ここの確認を飛ばすと「移行したのに主機能が動かない」ということになりかねません。なお、これはあくまで執筆時点の検証結果です。その後提供が始まっている可能性もあるので、最新状況は公式ドキュメントと実リクエストで確認してください。

この件から得た教訓3つ

今回の移行で得た、他の外部APIにも通じる教訓をまとめます。

1. 「突然の4xx急増」を検知できるようにしておく

外部APIの廃止告知は見逃しやすいものです。運営側は告知していても、開発者側がメールやお知らせページを常に追えているとは限りません。最後の砦として、エラー監視で「突然の4xxエラー急増」を検知できる仕組みを入れておくと、少なくとも「壊れたことに気づかないまま放置」は防げます。

2. 認証方式の刷新 = キーの再発行が必要、と考える

新旧の認証方式は別物でした。「エンドポイントだけ差し替えれば動くだろう」は通用せず、新方式のキー（applicationId + accessKey）の取得が必要です。API刷新の際は「キーはそのまま使えるのか」を最初に確認項目へ入れるべきです。

3. 検証は最小構成で「認証だけ」先に通す

curl一発で認証が通ることを確認してから、アプリケーションコードに組み込む。この順番を守るだけで、「キーが悪いのか、Refererが無いのか、パラメータが悪いのか、自分のコードが悪いのか」の切り分けが圧倒的に楽になります。

まとめ

旧 Rakuten Web Service API（app.rakuten.co.jp 系）は 2026-05-13 に廃止。旧エンドポイントを叩くコードは動かない
新APIは openapi.rakuten.co.jp の Ichiba MS 系（例: /ichibams/api 配下）
新認証は applicationId（UUID形式）+ accessKey（pk_ で始まるキー） の2点。旧キーの流用は不可
Refererヘッダの送信が必須。サーバーサイドからの呼び出しではデフォルトで付かないため、自分でヘッダに書く。ここが最大のハマりポイント
執筆時点では Ranking系・Genre系は404で未提供だった（ItemSearch系は動作）。「全APIが揃っているとは限らない」前提で依存機能を棚卸しする
検証は curl 等の最小構成で認証だけ先に通す。監視は「突然の4xx急増」を拾えるようにしておく

繰り返しになりますが、本記事は執筆時点（2026年）の検証に基づくメモです。パラメータ名・パス・提供API等の細部は変わる可能性があるため、実装の際は必ず楽天の公式デベロッパードキュメントで最新仕様を確認してください。同じ404連発で困っている方の切り分けが、少しでも早く終われば幸いです。