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