楽天市場の商品検索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連発で困っている方の切り分けが、少しでも早く終われば幸いです。