楽天の公式データを使い始めて、最初の入口でつまずいた話
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
楽天最安値検索ツールを作るとき、楽天ウェブサービスが公式に用意している「商品情報を取りに行く入口」を使いました。
最初は「楽天が用意しているなら、すぐ使えるんじゃないか」と思っていました。実際には、使い始めの一番最初のところで、いくつかのつまずきがあって、動くまでに予想以上の時間がかかりました。正直、仕組みは全部理解しているわけではありません。でも「最初にどこでつまずいたか」は記録に残しておけると思うので、書いておきます。
このツール自体がどういうものかは、別の記事に書きました（楽天最安値検索ツールを作った話）。ここではそのツールを作る前段、「公式の入口を使えるようにするまで」でハマったことに絞って書いていきます。
まず、「鍵」が2種類あって戸惑った
この入口を使うためには、最初にアプリを登録して、いくつかのIDやキーを確認する必要がありました。ここで一番混乱したのが、「鍵」のようなものが1種類ではなかったことです。
私が戸惑ったのは、アプリケーションIDと、アクセスキー（accessKey）と呼ばれる情報でした。どちらも外部のデータを呼び出すために必要な「合言葉」のようなものなのですが、役割が少し違うらしいのです。
私のなんとなくの理解では、アプリケーションIDは「登録したアプリを見分けるための番号」で、入口にリクエストを送るときの名札のようなもの。一方のアクセスキーは、いまの楽天ウェブサービスでAPIを呼び出すときに一緒に使う、もう一つの認証情報。そんなイメージでした。
ただ、最初は「合鍵が2つある」という時点で頭が止まりました。どっちをどこに入れればいいのか、片方だけでいいのか、両方いるのか。登録画面にいくつも英数字の文字列が並んでいて、「これとこれ、何が違うんだ……」と画面の前で固まりました。
Claude Code に「2種類あってどっちを使えばいいの？」と聞いて、ようやく使い分けを整理できました。整理してみると特別難しい話ではなかったのですが、知らないうちは、ただ似たような文字列が2つ並んでいるだけにしか見えず、最初の一歩からつまずいた感覚でした。専門用語はあとから少しずつ覚えました。
合鍵の管理という意味では、少なくともアクセスキーは人に見せない前提で扱う必要がある、というのも後から知りました。漏れると他人が私のアプリの情報を使ってしまうおそれがあるので、公開される画面には出さず、ツールの裏側で扱う形にしています。ここも「言われてみればそうだよな」と思いましたが、最初は何も分からず登録していました。
「許可された場所からの呼び出しではありません」というエラー
合鍵をなんとか手に入れて、いざ動かしてみたとき、今度は「許可された呼び出し元ではない」という意味のエラーが出ました。
文字だけ見ても、何が起きているのかさっぱり分かりませんでした。合鍵はちゃんと入れたはずなのに、なぜ「許可されていない」と言われるのか。Claude Code に聞いてみると、私のケースでは、楽天ウェブサービスのアプリ設定で登録した情報と、実際にAPIを呼び出している場所が食い違っていることが原因になっている可能性が高い、と分かりました。
どうやらこの入口は、アプリごとのアクセス制御があり、登録しておいた条件と違う場所からの呼び出しを弾くことがあるようです。公開サイトから呼ぶのか、裏側のサーバーから呼ぶのかによって、確認すべき設定も変わるのだと理解しました。
具体的に何が起きていたかというと、自分の手元のパソコンで動かしているときと、実際に公開したあととで、APIから見た呼び出し元が違っていました。手元で試したときの設定のままだと、公開した側から呼んだときに「登録された条件と違う」と弾かれる。そのズレがエラーの正体でした。
「こんな仕組みになっていたのか」と、後から整理したら理解できましたが、最初はエラーメッセージだけ見ても何も分かりませんでした。Claude Code に『こうしたい』と伝えたら形にしてくれる、という感覚で進んでいたぶん、自分では解読できないエラーが出ると、途端に手が止まります。このエラーは特にそういう瞬間でした。IDやキーさえあれば動く、という素朴な思い込みが、ここで一度崩れました。
アクセスの回数にもルールがあった（詳しくは別記事に）
入口が動くようになってからも、続けて何度もアクセスを送ると、一時的に応答しにくくなることがある、と分かりました。短い時間に同じURLへ何度もリクエストを送りすぎないように、という注意があるようです。開発中は「直した→試す→直した→試す」を繰り返すので、知らないうちに連続でアクセスしてしまい、最初はここでも少し戸惑いました。
ただ、この「アクセス回数の制限にどう対処するか」「取ってきたデータをどのくらいの期間まで手元に置いていいか」といった話は、つまずき体験というより、ツールの裏側をどう設計するかという別の話になってきます。書き始めると長くなってしまったので、レート制限への対処やデータの持ち方の設計については別の記事に分けて書きました。ここでは「最初は連続アクセスで弾かれて驚いた」という入口でのつまずきとして、軽く触れるだけにしておきます。
外部の情報を使うということ
この入口を使い始めてみて分かったのは、「外部のサービスのデータを使う」というのは、単にデータを取ってくるだけではない、ということです。
アプリを申請して、IDやキーを管理して、登録した条件と実際の呼び出し元を合わせて、ようやくスタートラインに立てる。その入口に立つまでの一歩一歩で、「分からないこと」が次々に出てきました。私のような非エンジニアにとっては、コードを書くこと以前の、この「最初のセットアップ」が思った以上の関門でした。
もう一つ知ったのは、取得したデータを何にでも自由に使えるわけではない、という点です。楽天の商品を紹介し、楽天市場の商品ページへつなぐ目的で使うものなので、取ってきた情報をどう表示するか、どのくらい保存してよいか、どんな形で使ってよいかは、利用規約や公式ヘルプを確認しながら慎重に扱う必要があります。このあたりのルールは、入口が動くようになってから少しずつ読んで知っていきました。
「このエラーメッセージは何を意味しているの？」「どうすれば解決できる？」という会話を Claude Code と繰り返しながら、少しずつ動く形にしていきました。正直、仕組みは全部理解しているわけではありません。でも「なぜこのエラーが出るのか」「どう対応すればいいか」という部分は、なんとか把握できるようになってきました。
楽天ウェブサービスのデータを使ってツールを作ること自体は、Claude Code に助けてもらえば何とか形にできました。ただ、実際にやってみると、動かす前の入口のところ──IDとアクセスキーの使い分け、登録した条件と実際の呼び出し元の合わせ込み──だけでも、つまずきポイントがいくつもありました。
詰まった瞬間は「もうやめようか」と思いますが、原因が分かると一気に進む──その繰り返しが、ツール開発の正直な実態だと思います。コードよりも、こういう「最初の作法」を覚えていくことが、非エンジニアが外部サービスと付き合うコツなのかもしれません。
なお、楽天ウェブサービスの仕様や利用ルールは変わる可能性があるので、実際に使うときは公式ヘルプを確認するようにしています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ