ホテルの座標が「秒」だった話（楽天トラベルAPIの落とし穴）
ホテル検索ツールを作り始めたとき、全国のホテルを地図に載せることを想定していました。楽天トラベルAPIから、ホテルごとの「場所を示す数字」も一緒に取れます。それを使えば、地図上にホテルの位置をぽんと打てる──そのつもりでした。
でも実際に試してみると、ホテルが日本海のど真ん中に表示されたり、どう考えてもおかしな場所に打たれてしまったりする。「バグかな」と思いながら、Claude Code に「地図がおかしい」と相談したのが、この問題との出会いでした。
「地図上の数字」にも単位がある
地図上の場所を示す数字には「度（ど）」という単位があります。たとえば東京なら、緯度が「35.6」くらいの数字です。この形式さえ守られていれば、地図に渡すとホテルの位置が正しく表示される、はずでした。
ところが Claude Code から「その数字、もしかして秒の単位で入っていませんか？」という返答が来ました。
角度の世界にも「度・分・秒」という区切り方があって、時計の「時・分・秒」と同じ発想です。1度は60分、1分は60秒なので、1度は3600秒にあたります。
楽天のデータから来た座標が「秒」の形式で入っていた場合、そのまま「度」として地図に渡すと、本来の3600倍の距離に相当する位置に飛んでしまいます。東京のホテルが、どこか遠い海の上に表示されたりするわけです。
試しに、数字を3600で割って地図に渡してみました。すると、ホテルが正しい位置に表示されるようになりました。理屈の全部を理解できたわけではありませんが、「割れば正しい位置に出る」という事実だけは、はっきり確認できました。
3600で割っても、まだ少しずれるケースがあった
大半のホテルは自然な場所に表示されるようになりました。ただ、それでも「位置が少しずれている気がする」ホテルが残っていました。
こういうケースには別の原因がありました。そもそもデータに入っている座標の値自体が、実際のホテルの場所と一致していないケースです。公式のAPIから取れる情報でも、登録されている住所と座標が食い違っていることがある──というのは、このときに初めて知りました。
日本の地図を管理している公的な機関のウェブサービスや、Googleの地図に住所を入れて位置を確認し、おかしそうなデータを一件ずつ確かめていきました。
私自身はコードを直接いじったわけではなく、「このホテル、住所と地図の表示がずれている気がする」と Claude Code に投げては、調べ方や確認の手順を一緒にたどっていく、という進め方でした。
「公式APIのデータでも確認が必要」という学び
この経験で気づいたことがあります。公式APIから取ってきたデータでも、「自分のツールで使える状態になっているか」は自分で確かめないといけない、ということです。
「公式APIから取ったんだから、そのまま使えば大丈夫」という思い込みが、一番の落とし穴でした。
単位が違うだけで、同じ数字がまったく別の意味になる。「数字が入っている」ことと「地図でそのまま使える値が入っている」ことは、別の話です。データを受け取ったあとに「ちゃんと地図に載っているか」を目で見て確認するひと手間が、意外と大事でした。
意外だったのは、こういう地味な確認作業ほど、ツール全体の精度にじわじわ効いてくる、ということでした。派手な機能を足すより、「変な値が入り込んでいないか」をこまめに確かめるほうが、使い勝手への影響は大きいかもしれない、と感じています。
「なんか変」を放っておかない
地図を最初に表示したとき、「あれ、ホテルの位置が変だな」という違和感はありました。「バグかな、後で直そう」と後回しにしていたら、そのままの状態でリリースしていたかもしれません。
でも「おかしいな」を放置せずに掘り下げてみると、そこに明確な原因が隠れていた。ツールを作っていると、こういう「なんか変な動作」に出くわすことが何度もあります。用語の意味は後からゆっくり覚えていけばよくて、「なんか変」という感覚のほうは最初から持てます。そこを入り口にすれば、エンジニアでなくても不具合の糸口くらいには立てるんだな、と思いました。
「数字が取れた」ことと「地図で使える数字が取れた」ことは、全然違う話でした。私がやったのは地図の表示を目で見て「おかしい」と言い続けることだけで、その先はほぼ Claude Code に助けてもらった形です──ホテル検索ツールを作る中で、いちばん実感として残っている場面のひとつです。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ