「さっきまで動いていたのに検索が止まる」「宿は出るのに経路が表示されない」——そんな“原因不明”を落ち着いて解決するためのトラブルガイドです。楽天トラベルと駅すぱあとの連携で起こりがちな不具合を、まず試す確認ポイント→原因の切り分け→復旧手順→再発防止のコツの順にやさしく解説。難しい用語はできるだけ避け、今すぐ試せるチェックリストと、問い合わせ時に役立つメモの取り方まで網羅しました。

そもそも「楽天トラベル」「Express」「駅すぱあと」のAPIって何？それぞれ何ができるの？

まず、「API」って何？

API（Application Programming Interface）は、サービス同士をつなぐ「共通の差し込み口」です。

人間がサイトやアプリの画面を操作する代わりに、プログラムが決められた形式で情報を取り出したり、条件を渡して検索したりできます。

旅行分野なら、宿の空室や料金、駅から駅までの経路と運賃など、必要な情報を自動で取得して自分のサイトやアプリに表示できるようになります。

この記事では、旅行計画で人気の「楽天トラベル」「Express」「駅すぱあと」の3つを取り上げ、各APIで何ができるのか、どう活用できるのかをやさしく整理します。

楽天トラベルAPIとは

楽天が提供する旅行予約サービス「楽天トラベル」のデータを外部から扱えるようにしたのが、楽天トラベルAPI（楽天ウェブサービスの一部）です。

宿泊施設の検索や、エリア・予算・設備などの条件での絞り込み、住所や緯度経度から近い宿の探索、宿の写真や設備・プラン情報の取得などに対応します。

提携プログラム（アフィリエイト）と連動させて、検索結果から楽天トラベルの予約ページへ誘導することも可能です。

できること（代表例）

• 宿検索：エリア、キーワード、駅・観光地の周辺、緯度経度などでホテル/旅館を一覧取得
• 条件絞り込み：価格帯、食事条件（朝食あり・2食付など）、部屋タイプ、禁煙/喫煙、設備（大浴場、温泉、駐車場、Wi‑Fi 等）
• 空室・料金の確認：日付・泊数・人数・部屋数を指定して概算料金を取得
• 施設情報：住所、アクセス、写真、評価指標、簡易レビュー要約などのメタ情報
• リンク生成：公式の予約導線（アフィリエイトID付きURL）を自動付与

活用アイデア

• 地域特集ページで「今週末に空きがある宿だけ」を自動掲載
• 観光記事の末尾に「この記事で紹介したスポット近くの宿」を地図とセットで表示
• 価格レンジや設備でパッケージしたテーマ特集（ソロ旅向け/子連れ歓迎/サウナ付き など）

使うときのポイント

• アクセスにはアプリケーションID（必要に応じてアフィリエイトID）を利用
• レスポンスはJSON/XMLが中心。必要な項目だけを抽出して自サイトのUIに整形
• レート制限やキャッシュの活用で過剰リクエストを回避（例：人気エリアの一覧は数時間キャッシュ）
• 表記やリンク位置など、利用規約・ガイドラインの遵守が必須

ExpressのAPIとは

ここでいう「Express」は、Node.js の定番Webアプリケーションフレームワーク「Express（エクスプレス）」を指し、外部サービスとつなぐための“自前API”を手早く作る道具です。

旅行系の外部API（楽天トラベルや駅すぱあと等）をそのままフロントから叩くのではなく、Expressで中継（バックエンド）を用意しておくと、鍵の秘匿、レスポンスの整形、キャッシュ、横断検索などを安全かつ柔軟に実装できます。

できること（代表例）

• ルーティング：/hotels、/routes のようなエンドポイントを定義し、複数APIをひとつの窓口に集約
• ミドルウェア：認証、レート制限、ログ、CORS、バリデーションなどを共通化
• レスポンス統合：異なるAPIの結果をひとつのフォーマットに整形（例：宿＋最寄駅＋運賃の合算）
• キャッシュ＆高速化：Redis等と連携し、一定時間の再検索を抑制
• 非同期処理：複数APIへの並列リクエストで体感速度を改善

旅行サービスでの役割

Expressは“ノリシロ（つなぎ目）”です。

例えば「到着駅から徒歩10分以内の宿だけ表示し、さらに今夜の空室と最終電車に間に合うプランだけを出す」といった横断的なロジックは、Expressに集約して実装します。

UIはシンプルな検索フォームでも、裏側では楽天トラベルAPIと駅すぱあとAPIを協調させ、ユーザーには“旅の意思決定に必要な答え”だけを返せます。

駅すぱあとAPIとは

「駅すぱあと」は、乗換案内でおなじみの経路探索エンジン。

駅すぱあとAPI（駅すぱあとWebサービス等）を使うと、鉄道・地下鉄・私鉄・一部のバスを含む経路検索、所要時間、運賃、乗換回数、IC/切符運賃の差、定期代、時刻表、運行情報の取得といった“移動”に関するデータを取り扱えます。

出発地/目的地は駅名や住所、緯度経度から指定でき、検索条件（早い・安い・乗換少ない、始発/終電 等）も細かく設定可能です。

できること（代表例）

• 経路検索：日時、経由、優先条件を指定して最適ルートを取得
• 費用の把握：運賃合計、IC/切符の差分、定期券の価格
• 時刻表・運行情報：列車の出発/到着時刻、遅延・運休情報（提供範囲は契約に依存）
• 周辺駅の特定：緯度経度から最寄り駅を検索し、徒歩やバスとの接続を補助

活用アイデア

• 「この宿に泊まるなら、空港/主要駅からこう行く」が自動で出る滞在ガイド
• 最安/最速/乗換少ないの3プラン比較を1画面で提示
• イベント終了時刻から逆算し、終電に確実に間に合う宿だけを抽出

使うときのポイント

• 商用利用は契約が前提。利用範囲やクレジット表記、キャッシュ可否など規約の確認が必須
• 駅名の表記ゆれや地名あいまい検索の扱いに注意（可能なら駅コードや座標で一意化）
• 運行情報は刻々と変わるため、キャッシュ時間は短めに設計

3つを組み合わせると何ができる？

宿と移動は、旅の両輪です。

楽天トラベルAPIで「泊まる」を、駅すぱあとAPIで「移動」を、Expressで両者の条件突き合わせと出力の最適化を担わせると、検索体験が一気に“意思決定のしやすい”形になります。

実現できる体験例

• 宿×経路の同時最適化：目的地までの所要時間と終電を加味して、今夜泊まれる宿をランキング
• “ドア to ドア”見積もり：自宅最寄駅→宿最寄駅の往復運賃＋宿泊費を合算表示
• 観光動線ナビ：1日のスポット巡り順を経路時間で自動調整し、最後にアクセス良好な宿を提案
• 雨天・遅延時のリルート：運行情報の変化に合わせて、宿のチェックイン時刻や移動手段を再提案

設計のコツ（データとパフォーマンス）

場所を一意化する

宿の住所、緯度経度、最寄駅を結びつける「場所辞書」を用意します。

楽天トラベルの施設座標と、駅すぱあとの駅座標/駅コードをExpress側でマッピングしておくと、徒歩圏や所要時間の計算が安定します。

キャッシュと整形

• 頻出の宿一覧やエリア人気は数時間キャッシュ
• 在庫（空室）や運行情報は短寿命（数分〜十数分）
• APIごとに異なる項目名を、共通スキーマ（例：price, time, distance, rating）に整形

レート制限とフォールバック

急なアクセス増には、Expressでレート制限とキュー制御を。

外部APIで失敗したら直前キャッシュを返す／検索範囲を広げるなどのフォールバック戦略を用意しておくと、体験の途切れを防げます。

セキュリティと法務の基本

• APIキーはサーバー側（Express）にのみ保持し、フロントに露出させない
• 通信はHTTPS、ログに個人情報や完全な検索クエリを残しすぎない
• 各APIの利用規約（表示義務、リンク条件、キャッシュポリシー、禁止事項）を順守
• サードパーティのコンテンツ（画像・地図）には権利表記を付す

はじめ方（スモールスタートの手順）

1. アカウント登録
   • 楽天ウェブサービスに登録し、アプリID（必要に応じてアフィリエイトID）を取得
   • 駅すぱあとAPIは用途に応じて申し込み。テスト/商用の条件を確認
2. Expressの雛形を作成
   • /hotels と /routes の2エンドポイントから開始
   • .envでAPIキーを管理、CORS/レート制限/ログのミドルウェアを追加
3. 最小の統合
   • /hotelsでエリア＋日付の宿一覧（楽天）を返す
   • /routesで出発駅→宿最寄駅の最短ルート（駅すぱあと）を返す
4. 横断レスポンスの設計
   • /plan で宿候補ごとに「価格・空室・最寄駅・所要時間・終電可否」を合算
   • 表示は「おすすめ」「最安」「乗換少ない」など3タブに分ける
5. キャッシュとUI磨き
   • Redis等でキャッシュ、フェイルセーフ実装
   • 地図や写真と併せて、初見で判断できるUIに整える

よくある疑問にサクッと回答

無料で使えるの？

楽天トラベルAPIは一定条件で無料で使えます（アフィリエイト連携などのガイドラインあり）。

駅すぱあとAPIは用途やトラフィックに応じた契約が基本。

料金や権利表記は最新の公式情報で確認してください。

個人でもできる？

プロトタイプは個人でも可能です。

ExpressでAPI中継を組み、少量トラフィックで検証してから拡張するのが安全です。

商用公開の前に、各APIの規約・表示義務を必ずクリアにしましょう。

地図はどうする？

地図タイルやジオコーディングは地図事業者のAPI（Google Maps、Mapbox、国土地理院など）と併用します。

宿の座標と駅座標を重ね、徒歩圏の可視化や混雑に応じた迂回提案も可能です。

まとめ：APIで「探す」を「決められる」に変える

楽天トラベルAPIは“泊まる情報”、駅すぱあとAPIは“移動情報”。

Expressは、その2つを安全・高速に束ねる“設計の土台”です。

これらを組み合わせるだけで、単なる検索結果の羅列ではなく、「今の自分に最適な旅の答え」を返す体験へと進化させられます。

空室・料金・所要時間・終電可否・合計コストを一望できれば、比較にかける時間がぐっと減り、旅はもっと身近になります。

小さく作って素早く検証し、キャッシュや整形、表記ルールを固めながら拡張する。

そんなアプローチで、あなたのメディアやサービスに“迷わない旅計画”を実装してみてください。

一般の旅行者にとって何が便利になるの？旅行計画はどこまで自動化できるの？

宿・経路・当日運用まで一気通貫 楽天トラベル×駅すぱあと×Express活用で「迷わない旅」を実現

「宿の空きはあるけど駅から遠い」「行きやすい時間帯だと宿が高い」「急な遅延で予定が崩れた」——旅のストレスは多くが情報の分断から生まれます。

楽天トラベルの宿情報と、駅すぱあとの経路検索がひとつにつながり、裏側をExpressが素早く橋渡ししてくれると、探す・決める・移動するが一本の体験になります。

ここでは、具体的に何が便利になるのか、旅計画はどこまで自動化できるのかを、実際の利用シーンに沿って解説します。

何が便利になる？ シーン別の体験変化

出発前：条件整理が一瞬で終わる

• 宿と移動の同時最適化：予算・部屋タイプ・露天風呂の有無など宿の条件と、最寄り駅からの徒歩分数・乗換回数・終電時刻といった移動条件をひとつの画面で調整できます。
• 価格×所要時間の両軸比較：少し出発を早めると宿が安い、1駅先の宿にすると乗換が1回減る、など「総合的に得な案」を自動で提示。
• 地図と経路の連動：楽天トラベルで見つけた宿を地図で開くと、駅すぱあとの最寄り駅・バス停が自動で紐づき、徒歩と公共交通を合わせたドア・トゥ・ドアの時間が即わかります。

比較・予約前：悩む要素を数値化してくれる

• 「総移動コスト」表示：運賃・所要時間・乗換ストレス（回数/階段の多さ）・徒歩距離をスコア化し、総合点の高い案から提示。
• 料金カレンダー×交通混雑の重ね合わせ：人気日程は宿の価格が上がり、列車も混みやすい。両方の混雑が低い「穴場日」を可視化します。
• キャンセルポリシーの横並び：同等条件ならキャンセルしやすい宿を上位に。急な予定変更に備えやすくなります。

出発直前〜移動中：遅延や混雑に強い

• 遅延・運休の自動検知：駅すぱあとが拾う系統情報に基づき、数分単位で乗換を再計算。予約済みの宿のチェックイン最終時刻から逆算して最適ルートを再提示します。
• 徒歩⇄バス/タクシーの代替提案：雨天や大荷物なら「徒歩15分→最寄りバス8分」「駅前タクシーでショートカット」など現実的な代替をワンタップ表示。
• プッシュ通知は必要な時だけ：ダイヤ乱れ・乗り過ごし検知・終電リスク接近など「今知らせる価値が高い」イベントだけを通知。

現地滞在：行きたい場所の順番が自動で美しく

• 滞在時間を確保したルート：開館時間・滞在目安・移動時間から、無理のない順番とペース配分を提案。
• ランチ混雑回避：人気店のピーク帯を外すため、午前/午後の観光順を自動で入れ替え。結果だけでなく「なぜそうしたか」も表示。
• 荷物動線も最適化：コインロッカーの空きやすい駅・ホテルの荷物預かり時間を踏まえて「預ける/持つ」を判断。

帰宅後：旅の記録が勝手にまとまる

• 移動ログと宿データの自動整理：何時にどこを出て、どんな手段で移動し、どの宿に泊まったかが時系列でまとまります。
• 次回のヒント：混雑回避が有効だった時間帯、歩きすぎた日の傾向などを学習。次の提案精度が上がります。

どこまで自動化できる？ 3段階でイメージ

レベル1：情報の自動整理

条件を入れると、宿・経路・料金・時間がひとつのビューに整列。

候補を横断比較でき、予約は自分で決める段階。

面倒なリサーチ時間が半減します。

レベル2：旅程の半自動生成

日数、到着/出発時刻、行きたいスポット、予算を入力すると、現実的な1日のタイムラインが自動生成。

気になる場所を入替えると経路と時間配分が即再計算され、細かな修正だけで済みます。

レベル3：条件付きの全自動予約

上限予算、ベッドタイプ、禁煙/喫煙、駅から徒歩◯分以内、キャンセルポリシーなど「越えてはならない基準」を事前に設定し、最良プランが見つかったら自動で確保。

完了通知と詳細が届き、ワンタップで確定/取り消しができます。

これにより、人気日程の取り逃しが大幅に減ります。

自動化しない/できない領域

• 食事の好みや特別な体験選びの「好み決定」
• 天気が悪くても強行するか中止するかの価値判断
• 現地の空気感・気分で「予定外に寄り道」する余白

自動化はあくまで「選択肢を整える」「面倒を減らす」ためのもの。

最後の一押しは人の判断が心地よさにつながります。

リアルな利用シナリオでわかる便利さ

週末、箱根で1泊2日の温泉旅

1. 条件入力：予算3万円/人、午前出発、露天風呂付き優先、乗換少なめ。
2. 提案：小田原経由が最短だが混雑。少し遅め出発＋登山鉄道の空いている時間帯案を提示し、宿は駅から徒歩7分の好評価旅館を上位表示。
3. 当日：登山鉄道の遅延を検知し、箱根湯本からバス代替＋徒歩短縮ルートを通知。チェックイン時刻に間に合う「静かな道」も案内。

札幌拠点で小樽も楽しむ2泊3日

1. 条件入力：雪道での徒歩を短縮、海鮮ランチのピーク回避。
2. 提案：小樽のピークに合わせず、午前は札幌市内観光→13時台に小樽着の列車を提案。駅からのバス時刻に合わせてスポット順序を自動調整。
3. 当日：積雪で徒歩が厳しいと判断され、タクシー併用案をプッシュ。合計費用と時間のバランスが一目でわかる。

金曜出張ついでに、現地で1泊延泊

1. 条件入力：会社規定の宿予算内、朝一で空港へ向かいやすい場所。
2. 提案：翌朝の空港アクセスが良い駅前ホテルをピックアップ。チェックアウトから空港までの経路と所要時間を確定表示。
3. 変更対応：最終ミーティングが延びたら、最終列車・バスの乗継を再計算し、間に合わない場合は別ルートと宿のレイトチェックイン手続きを併せて案内。

予算・時間・体力を同時に最適化する仕組み

評価軸の例

• 価格：宿料金＋運賃の合計。早割やクーポンも反映。
• 時間：ドア・トゥ・ドアの所要時間。待ち時間や徒歩も含む。
• 乗換負荷：回数、階段の多さ、ホーム間移動距離を加味。
• 徒歩距離：天候/荷物量の重みづけで許容範囲が可変。
• レビュー：立地・清潔感・朝食など項目別に重みづけ。

これらを総合スコアにして、あなたの重み（例：子連れだから乗換負荷重視、出張なら時間重視）を反映。

候補が数秒で並び替わります。

当日の変化に強い「再計算」の安心

遅延・運休

路線トラブルを検知したら、目的地到着時刻とチェックインリミットから逆算し、間に合う代替ルートを提示。

間に合わない場合は宿へ自動連絡の選択肢も表示します。

天候悪化

雨や雪で徒歩移動に無理が出る場合、屋内移動中心のルートに切り替え。

屋内通路・地下道情報を優先し、必要ならバスやタクシーを組み合わせます。

満席・混雑

人気列車やレストランが混む時間帯を避け、訪問順をその場で入れ替え。

待ち時間を「見る価値のある寄り道」に変換します。

安心して任せるための設定と配慮

• 権限は細かくオン/オフ：位置情報、カレンダー連携、決済は必要な範囲だけ。いつでも取り消し可能。
• 自動予約は上限とルールを明確に：1泊あたりの上限額、禁煙/喫煙、ツイン/ダブルなど必須条件を設定。
• 通知は「重要だけ」に最適化：終電・遅延・チェックイン締切など、価値の高いアラートに限定。
• キャンセル方針の見える化：無料期間・期限の明記、代替候補の同時提示で決断が早くなります。

上手に使いこなすコツ

好みの初期設定で精度アップ

• 乗換の許容回数、徒歩の許容距離、優先したい部屋タイプや朝食有無をプリセット。
• 「急ぎ」モードと「ゆったり」モードを切替。出張とレジャーで重みを変えましょう。

アラート閾値を自分仕様に

• 終電アラートは「30分前/15分前/10分前」の好みで。
• 遅延通知は「5分以上/10分以上」など感度調整。

オフライン時の安心

• 主要経路のオフライン保存、予約確認書の端末保存、QR/バーコードの事前ダウンロードで電波が弱くても安心です。

家族・友人と共有

• 旅程リンクを共有し、各自の現在地から合流地点までの最適ルートを自動案内。集合遅延のストレスが減ります。

よくある心配ごとへのヒント

手数料や価格面は損しない？

条件が同じなら、早割・クーポン・ポイント還元を含んだ実質価格で比較します。

見かけの料金差に惑わされないので、結果として損を避けやすくなります。

キャンセルが不安

無料キャンセル期限の前に自動リマインド。

必要なら代替案と一緒に提案されるため、落ち着いて判断できます。

交通系ポイントや定期券は反映できる？

通過区間が定期券エリアなら、実際の追加運賃のみで比較。

モバイルSuica/SAPICAなどの利用実態に寄せた経路評価が可能です。

近い未来に期待できること

• 混雑ヒートマップとの連携で「空いている楽しみ方」を提案
• 二酸化炭素排出量の見える化と「低排出」プランの優先
• 天候・季節・イベントに応じたダイナミックな滞在順最適化
• 音声で「明日、温泉。乗換少なめ、予算3万円」で完結する会話型予約

結論：手間は減り、余白は増える。迷わない旅へ

楽天トラベル×駅すぱあとの連携は、宿と移動という分断を埋め、「行けるプラン」を「行きたくなるプラン」に磨き上げます。

条件整理は自動、比較は一画面、当日の乱れにも強い。

自動化の役割は、あなたが本当に悩みたい「どんな体験をしたいか」という問いに集中させてくれることです。

最初はレベル1の自動整理から。

慣れたら半自動の旅程づくり、混雑シーズンは条件付き自動予約を活用。

旅はもっと自由に、もっと軽やかになります。

次の週末、まずは「好みの初期設定」を作ってみてください。

それだけで、旅計画は驚くほどスムーズに動き出します。

はじめるにはどうすればいいの？アカウント登録やAPIキー取得の手順は？

最初の一歩を最短で！楽天トラベル×Express×駅すぱあとAPI 登録とキー取得のはじめかた

宿の検索と鉄道経路の算出を同時にこなす旅アプリやブログ連動の旅プランナーを作るなら、楽天トラベルAPIと駅すぱあとAPIを軸に、自前のAPIレイヤー（Express）でつなぐのが王道です。

ここでは、はじめての方が迷わないように「アカウント登録」「APIキー（アプリID）の取得」「最初のリクエスト確認」までを、つまずきやすいポイントとあわせて丁寧に解説します。

全体像：登録から初回リクエストまでの5ステップ

1. 楽天トラベルAPI用に「楽天ウェブサービス（RWS）」のアプリIDを取得する
2. 駅すぱあとAPIのデベロッパー登録を行い、APIキーを受け取る
3. 開発環境（Node.js + Express）を用意し、環境変数でキーを管理する
4. Postmanやcurlで各APIを単体検証する
5. Expressで両APIを束ねるシンプルなエンドポイントを作り、動作確認する

実装は後からいくらでも拡張できます。

まずは「キーを取り、動かす」ことだけに集中すると、驚くほどスムーズに進みます。

楽天トラベルAPI：開発者登録とアプリID取得の手順

必要なもの

• 楽天会員ID（無料）
• 楽天ウェブサービス（RWS）での開発者登録（無料）

手順

1. 楽天会員にログインする
2. 楽天ウェブサービス（RWS）の開発者サイトにアクセスし、利用規約に同意する
3. 「アプリケーションID（Application ID）」を発行する
   • アプリ名（任意）と連絡先など基本情報を入力
   • 用途や利用予定APIの選択画面がある場合は「楽天トラベル」関連を選ぶ
4. 必要に応じて「アフィリエイトID」を準備
   • 楽天アフィリエイトに参加すると発行されるID。リンク経由の成果計測に使える
   • 必須ではないが収益化を見据えるなら取得しておくと便利
5. ダッシュボードで「Application ID」を確認・控える

最初のリクエスト例（ホテル検索）

APIのバージョンやパラメータは公式ドキュメントを必ず確認してください。

以下は代表的な呼び出しイメージです。

GET https://app.rakuten.co.jp/services/api/Travel/SimpleHotelSearch/20170426
  ?applicationId=YOUR_RAKUTEN_APP_ID
  &format=json
  &keyword=箱根温泉
  &hits=10

ブラウザで直接叩くと見やすいですが、レート制限やCORSの観点から、基本はサーバー側（Express）経由がおすすめです。

よくある注意点

• レート制限があるため、キャッシュや再試行の制御を設計に入れる
• 掲載ルール（表示義務・クレジット表記、リンク先の扱いなど）を確認
• 商用利用や収益化時は規約とガイドラインに沿った運用・表記を行う

駅すぱあとAPI：デベロッパー申込とキー発行の手順

必要なもの

• 駅すぱあとAPI（駅すぱあとWebサービス）用のアカウント
• 利用申込（評価・トライアルまたは商用プラン）

手順

1. 駅すぱあとの開発者サイトでアカウントを作成
2. 利用したいAPI（経路探索、駅情報、所要時間など）に応じて申請
   • プランや想定トラフィック、利用目的を入力
   • 開発・評価向けのキーが発行される場合あり（提供条件はサイト記載に準ずる）
3. ダッシュボードまたはメールでAPIキーを受領
4. 必要に応じてリファラ（ドメイン）やIPアドレス制限を設定

最初のリクエスト例（経路検索）

駅名や日時の形式はドキュメントに従いましょう。

駅名は正確な表記が必要です。

GET https://api.ekispert.jp/v1/json/search/course/extreme
  ?key=YOUR_EKISPERT_KEY
  &from=新宿
  &to=箱根湯本
  &date=20250120
  &time=090000

結果には複数の候補（ルート）が含まれ、所要時間・運賃・乗換回数などを比較できます。

よくある注意点

• 駅名は同名駅の曖昧性に注意（ID指定やジオサーチを併用すると安定）
• 表示・二次利用のポリシーに従う（クレジット表記やデータの再配布制限など）
• 高頻度アクセスは課金やレート制限に影響。サーバー側でのキャッシュ戦略を設計

Expressは「自分のAPI」を作るための土台：アカウント・キーは不要

ExpressはNode.jsのWebフレームワークで、外部サービスのようなアカウント登録やAPIキーは必要ありません。

目的は「楽天トラベル」と「駅すぱあと」のレスポンスを安全・高速に仲介し、アプリやブログで使いやすい形に整えることです。

準備するもの

• Node.js（LTS推奨）
• パッケージマネージャ（npm もしくは pnpm, yarn）

初期セットアップ

mkdir travel-starter && cd travel-starter
npm init -y
npm i express axios dotenv

ルートに.envファイルを作成し、APIキーを保存します（.gitignoreで除外）。

# .env
RAKUTEN_APP_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
EKISPERT_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PORT=3000

最小のプロキシ例

外部APIへ直接フロントからアクセスさせるとキー露出やCORSの問題が起きがち。

Expressで仲介しましょう。

// index.js
import 'dotenv/config'
import express from 'express'
import axios from 'axios'

const app = express()

app.get('/api/hotels', async (req, res) => {
  try {
    const { keyword = '箱根温泉', hits = 10 } = req.query
    const url = 'https://app.rakuten.co.jp/services/api/Travel/SimpleHotelSearch/20170426'
    const { data } = await axios.get(url, {
      params: {
        applicationId: process.env.RAKUTEN_APP_ID,
        format: 'json',
        keyword,
        hits
      },
      timeout: 8000
    })
    res.json(data)
  } catch (e) {
    res.status(502).json({ error: 'Rakuten API error', detail: e.message })
  }
})

app.get('/api/route', async (req, res) => {
  try {
    const { from = '新宿', to = '箱根湯本' } = req.query
    const url = 'https://api.ekispert.jp/v1/json/search/course/extreme'
    const { data } = await axios.get(url, {
      params: {
        key: process.env.EKISPERT_KEY,
        from, to
      },
      timeout: 8000
    })
    res.json(data)
  } catch (e) {
    res.status(502).json({ error: 'Ekispert API error', detail: e.message })
  }
})

app.listen(process.env.PORT || 3000, () => {
  console.log('Server running')
})

単体検証：まずは1件でも返せればOK

curlでサクッと確認

curl "http://localhost:3000/api/hotels?keyword=箱根温泉&hits=3"
curl "http://localhost:3000/api/route?from=新宿&to=箱根湯本"

200が返り、JSONが表示されれば成功です。

異常時はExpress側のログに詳細が出るよう、エラーハンドリングを充実させましょう。

Postman/Insomniaを活用

• 環境変数でBASE_URLやキーを切り替え、開発/本番の確認をスムーズに
• コレクションに「ホテル検索」「経路検索」「複合API」などを登録して再利用

複合活用の最初のゴール：宿とアクセスの“同時”表示

最初に目指すと扱いやすいのは「宿の候補」と「最短のアクセス」を並べて見せることです。

例えば、楽天トラベルAPIで得た宿の住所や最寄り駅を取り出し、駅すぱあとAPIで最寄り駅までのルートを同時に提示します。

最短パイプラインの例

1. 宿を検索（楽天トラベルAPI）
2. 宿データから最寄り駅または緯度経度を取得
3. 出発駅（ユーザー入力）→最寄り駅（プログラムで決定）を駅すぱあとAPIに投げる
4. 宿の基本情報＋所要時間/運賃/乗換回数を合体して返す

これだけでも「選ぶ理由」が明確になり、離脱率が下がります。

キー管理とセキュリティの基本

• APIキーは環境変数で保持し、リポジトリに含めない（.envと.gitignore）
• 本番はシークレットマネージャー（例：GCP Secret Manager、AWS Secrets Managerなど）を利用
• 駅すぱあとはリファラやIP制限の設定が可能なら有効化
• ログにキーを出力しない。エラーでもマスクする
• 必要に応じてキーの定期ローテーションを計画

規約・表示・課金でつまずかないために

• レート制限とキャッシュポリシー
  • 短時間に同じ条件の検索が続く場合はメモリ/外部キャッシュを活用
  • バックオフ（指数的再試行）とフォールバック（最低限の代替表示）を実装
• クレジット表記やリンク先ルール
  • 楽天トラベルや駅すぱあとの表記義務・利用ルールを遵守
  • アフィリエイトID利用時の表示方法を確認
• データ保持と二次利用
  • レスポンスの超過保存や再配布に制限がある場合が多い。ログやDB保管期間を明文化
• 商用プラン・従量課金
  • 想定トラフィックを見積もり、費用の上限管理（アラートやクォータ）を設定

開発を加速する小ワザ

• データ整形の型を先に決める
  • 宿カード用の統一スキーマ（名称・住所・価格帯・レビュー・最寄り駅・所要時間）を作る
• ステーションIDの正規化
  • 駅名のぶれを防ぐため、初回に駅IDへ解決して保持
• 地図連携を想定した座標の扱い
  • 緯度経度は必ずWGS84で統一。ズーム/ピン用途に小数点桁数をそろえる
• エラーUX
  • API停止時は「最新の時刻表が取得できません」などユーザーフレンドリーな文言に

ありがちなトラブルと対処法

CORSでブロックされる

フロントから外部APIを直叩きせず、必ずExpress経由に。

開発時はローカルのポート跨ぎに注意。

駅名が一致せずルートが返らない

駅すぱあとの駅検索APIで事前にID解決。

ユーザー入力に対してサジェスト（インクリメンタルサーチ）を実装すると改善します。

文字化けやエンコードエラー

UTF-8で統一し、URLパラメータはエンコードする。

日本語駅名・地名は特に注意。

レート制限に達する

キャッシュ（検索条件ハッシュ化）、バックオフ、特定条件のサンプリング（間引き）で対処。

バッチの時間帯は分散。

料金・所要時間が想定とずれる

検索条件（有料特急の可否、優先条件、日付と時刻）を明示的に設定。

デフォルト挙動の違いに注意。

最小実装のロードマップ（半日でここまで）

1. 楽天トラベルAPIで「キーワード検索→トップ3件」取得
2. 各宿の住所から最寄り駅を1つ決める（最初はハードコードでも可）
3. 駅すぱあとAPIで「出発駅→最寄り駅」の最短ルートを取得
4. 宿カードに「所要時間」「乗換回数」を添えてリスト表示
5. 「条件を変える」UI（出発駅、日時、予算）を追加

まずは「1ページ・1ルート・1泊」でOK。

体験価値が明確になり、次の改善点が見えてきます。

本番前チェックリスト

• APIキー保護（環境変数、アクセス制限、ローテーション）
• エラーハンドリング（タイムアウト、再試行、ユーザー向けメッセージ）
• キャッシュ戦略（条件ごとにTTLを設計。当日/休日は短め）
• 表記・リンクの規約順守（クレジット、アフィリエイト表記）
• 監視とアラート（5xx急増、外部API応答時間の劣化を検知）

次の一歩：精度と体験を磨くアイデア

• 地図ピンと経路オーバーレイの連携（ホテル選択で経路を再計算）
• 「歩く時間短め」「乗換少なめ」など好みの優先度を保存
• 遅延・運休情報の取り込みと再探索
• 価格アラート（宿の料金が閾値を下回ったら通知）
• パフォーマンスチューニング（SSR/キャッシュで初回表示を高速化）

まとめ：登録して、鍵をとって、まずは1件を返す

はじめるのに必要なのは、楽天ウェブサービスのアプリIDと、駅すぱあとのAPIキー、そしてExpressの薄いラッパーだけ。

最初の1件が返ってくれば、あとはUIや評価軸、再計算の賢さを足していくだけです。

登録→キー取得→単体検証→Expressで仲介、という最短ルートで、今日から「迷わない旅計画」の土台づくりを始めましょう。

料金はかかるの？無料枠・制限・コストの目安はどうなっているの？

料金はかかるの？

楽天トラベル×Express×駅すぱあとAPIの無料枠・制限・コスト感を一気に整理

旅サービスをAPIでつなぐと、ホテル検索から経路案内までがスマートに流れます。

とはいえ、最初に気になるのは「お金」。

ここでは、楽天トラベルAPI・Express（バックエンド）・駅すぱあとAPIを組み合わせるときの、無料枠や制限、そして現実的なコストの目安をまとめて解説します。

個々の価格表だけを眺めても全体像はつかみにくいもの。

開発〜運用のライフサイクル別に、どのタイミングで何にコストが発生するのかまで、設計のコツとともに具体的に掘り下げます。

楽天トラベルAPI：原則無料で使えるが、規約と制限の理解が肝心

料金と無料枠の考え方

楽天トラベル系のAPIは、楽天ウェブサービスの枠組みで提供され、基本的に利用料は「無料」です。

利用にはアプリID（またはAPIキー）の取得、利用規約とガイドラインの順守が前提となります。

商用サイトでの活用も可能ですが、掲載方法・リンク方法・帰属表記などのルールが細かく定められています。

収益は宿の予約成立時などに発生するアフィリエイトや送客で補うモデルが一般的です。

想定される制限

• リクエスト回数の上限（時間単位・日単位のレート制限）
• 結果データのキャッシュ・再配布に関する制約
• リンク先やクレジット表記の義務
• スクレイピングや過剰な並列アクセスの禁止

レートやキャッシュの条件は更新されることがあるため、実装前に最新のドキュメントで確認しましょう。

一般的には、個人・小規模の試作レベルで困るほど厳しいことは少ないものの、キャンペーン時などに瞬間的に負荷が上がる設計は避けるのが無難です。

コスト最小化の設計ポイント

• 結果のキャッシュ層を用意する（例：1〜6時間で更新）。在庫・料金は鮮度優先、施設情報は長めに。
• ユーザー入力が固まるまでリクエストを送らない（デバウンス/サジェストはローカル辞書で対応）。
• 一覧→詳細の順に段階的に取得。最初から全件の写真やレビューを引かない。
• 非同期キューでバックグラウンド更新。画面描画はキャッシュで即時、裏で差分更新。

Express（バックエンド）：ソフトは無料、費用は「動かす場所」で決まる

ライセンスと基本コスト

ExpressはNode.jsの代表的なWebフレームワークで、MITライセンス。

利用料はかかりません。

費用が発生するのは、APIキーを隠しつつ各APIを束ねる「バックエンド」をどこで動かすか、という運用部分です。

ホスティングの選択肢と費用感

• サーバーレス（FunctionsやCloud Run系）：低トラフィックに強く、無料枠が用意されることが多い。リクエスト数・GB秒・外向き転送料で課金。
• コンテナ/VM（常時稼働）：月額の固定費が発生。小規模なら月数百円〜数千円程度から始められるケースも。
• PaaS/ホスティングサービス：無料枠あり（スリープや帯域制限などの制約つき）。テスト〜β段階との相性が良い。

小規模運用のざっくり試算例

1日あたり1,000〜3,000PV、API呼び出しが1PVあたり2〜5回、レスポンス主体の軽量なJSONで、キャッシュを設けた場合、月間のホスティング費は数百円〜数千円に収まることが珍しくありません。

ピーク時の同時接続やログ保管（ストレージ）を厚くすると、もう少し増えます。

画像や大容量のバイナリ転送が多いと、下りではなく「外向きの転送料」がボトルネックになるので注意しましょう。

無料枠の落とし穴

• スリープ/コールドスタート：応答の初動が数秒遅くなり、検索体験を損なう。
• 同時実行の上限：昼休みや夜間などアクセスが集中するとスロットルされる。
• 地域リージョン：日本近傍に置かないとAPIチェーン全体でレイテンシが増える。

検索UIの満足度は「体感速度」によるところが大きく、無料枠を使う場合でも、キャッシュやプリフェッチで体感速度を補う工夫が効きます。

駅すぱあとAPI：商用は有料が基本。必要機能と想定PVで見積る

料金モデルの全体像

駅すぱあと（駅すぱあとWebサービス/Ekispert API）は、乗換検索や運賃・所要時間などの経路情報を提供する実績のある有料APIです。

商用利用は月額の契約が基本で、利用規模（PV・QPS）や使う機能モジュール（経路探索、定期券、運賃詳細、混雑など）によって料金が変わります。

開発者向けにテストやトライアルの手段が用意される場合がありますが、商用リリースでは有償契約が前提と考えておくのが安全です。

見積りに必要な情報

• 月間の想定PV（ユニーク/リピーターの比率もあると精度UP）
• 1PVあたりの経路API呼び出し回数（検索→再検索→詳細展開の流れ）
• ピーク時間帯のQPS（同時実行の見込み）
• 必要機能（経路、運賃、定期、最終列車、ダイヤ、混雑情報など）
• キャッシュ方針（短期キャッシュの可否と時間）
• 導線（Web/アプリ/バックエンドのみ）と表示方式（文言・クレジット）

このあたりを揃えて相談すると、スムーズにプラン提案や概算見積もりが進みます。

一般に、商用の最小プランは「数万円/月」規模から始まることが多く、PVや機能が増えるに従い段階的に上がるイメージです。

よくある制限と遵守点

• レート制限（QPS/日次）：短時間の集中リクエストを避ける設計が必要。
• キャッシュと二次利用：再配布やスクレイピングは禁止。キャッシュ可否と保持時間は契約・ガイドラインに従う。
• 表記と出典：所定のクレジットやリンク、表示条件を満たす。
• 運行実態との齟齬対策：ダイヤ改正時期の更新・検証フローを持つ。

コストを抑える実装テクニック

• 駅名はIDで正規化：ユーザーの曖昧入力はフロントで補完し、APIへは駅コードで問い合わせ。
• 段階検索：一覧候補→詳細の二段構え。候補一覧表示時に全件の詳細を引かない。
• 一時キャッシュ：同一条件の再検索はキャッシュヒットで返す。時間帯・優先条件ごとにキーを分ける。
• 再検索の抑制：並び替えはクライアント側で可能な範囲はローカルで対応。
• バッチ前計算：人気ルートや定番区間は定期的にプリフェッチしておく。

全体の費用感：段階別の現実的な見立て

検証（PoC）段階

目的：UI/UXの当たりをつける。

費用の内訳イメージ：

• 楽天トラベルAPI：無料で検証可能（規約順守）
• Express：無料枠や安価なホスティングで0〜数百円/月も現実的
• 駅すぱあとAPI：テスト手段が提供されれば0円〜、なければ見積りの事前相談から

合計：ほぼ無料〜ごく小額。

まずは動くものを作り、測定データを取る段階。

ベータ（限定公開）段階

目的：利用実績の収集と改善。

費用の内訳イメージ：

• 楽天トラベルAPI：無料（規約内の表示・リンク運用を厳密に）
• Express：月数百円〜数千円（ログ保管や監視を加味）
• 駅すぱあとAPI：商用契約の最小プランを検討（数万円/月規模からが一般的）

合計：数万円/月前後から。

規模・機能で変動。

本番（一般公開）段階

目的：安定運用と収益化。

費用の内訳イメージ：

• 楽天トラベルAPI：無料（アフィリエイト成果で収益化を補助）
• Express：トラフィックに応じて数千円〜数万円/月
• 駅すぱあとAPI：機能追加やPV増に伴い段階的に増額（数万円〜数十万円/月のレンジで設計）

合計：事業規模次第。

乗換機能の利用が多いほど駅すぱあとの比重が増えます。

「1PVあたり何回APIを叩くか」が最大のコストレバー

呼び出し回数の設計テンプレート

• ホテル一覧：1回（条件検索）
• ホテル詳細：1回（個別ページ遷移時）
• 料金・在庫更新：必要時のみ差分更新
• 経路候補：1回（出発地・到着地・時間が確定したら）
• 経路詳細：展開時に1回（乗り換え詳細や運賃内訳が必要なとき）

1PVあたりのAPI総数を「2〜3回」に抑え、再検索時はキャッシュで返せる比率を高めるのが理想です。

UXを損なわずに呼び出し回数を減らすと、レート制限の回避とコスト最適化の両方に効きます。

キャッシュ戦略の実務ポイント

• キー設計：検索条件を正規化（駅コード/緯度経度/日時の粒度）
• TTLの差別化：施設情報は長め、料金・在庫・運行は短め
• ユーザー別キャッシュ：直前の検索条件はセッションキャッシュで即時復元
• 整形後キャッシュ：API生データではなく、UIでそのまま使える形を保持

制限・規約に触れないための最低限チェック

レート・同時実行

バックオフ（指数的リトライ）とキューを用意し、瞬間風速での連打を避ける設計に。

クライアントからの連続入力はデバウンスで抑制します。

データの扱い

再配布やバルク保存は避け、表示目的での必要最小限に。

キャッシュ許容範囲と保持期間は各APIのガイドラインに合わせます。

表記・リンク

帰属表記、リンクの遷移先、ブランドロゴの扱いなど、UI要件をデザイン初期から組み込みましょう。

後追い修正は手戻りが大きくなります。

現場で効くコスト最適化レシピ

フロントで工夫してAPIを呼ばない

• 駅名・地名はローカルの候補辞書やオフラインインデックスでサジェスト
• スケルトンスクリーンで体感速度を上げ、API完了までの離脱を防ぐ
• ソート・フィルタは可能な限りクライアント側で実施

バックエンドは「集約」と「整形」に専念

• 楽天トラベルと駅すぱあとのレスポンスを共通スキーマにマッピング
• 必要なフィールドだけを返し、転送量を削減
• 繰り返し使う派生値（合計所要時間・徒歩含めた到着時刻等）はサーバー側で事前計算

運用で効率を高める

• ピーク時のキャッシュヒット率とレイテンシを可視化し、閾値を調整
• 想定外のリトライ増加を検知（ユーザー操作や外部障害の兆候）
• ダイヤ改正・大型連休・天候急変の前後でTTLを動的に短縮/延長

費用対効果の見方：収益と品質を両立させる

成果地点から逆算する

予約ボタンのクリック率や実予約率をKPIに据え、そこに効くAPI呼び出し以外は「体験の品質を落とさない範囲で」削るのが鉄則。

駅すぱあとの詳細呼び出しは、予約検討フェーズが深まったユーザーに絞るとムダが減ります。

SLAとコストのバランス

「いつでも即応」を目指すとホスティングコストは跳ね上がりがちです。

ピーク時だけ性能を底上げするオートスケールと、普段はキャッシュ中心で回す運用が現実的です。

最後に：無料で始め、有料は段階的に。ルールを味方に伸ばす

楽天トラベルAPIは原則無料、Expressは無料だが運用でコストが発生、駅すぱあとAPIは商用では有償が基本。

全体のカギは「1PVあたりの呼び出し回数設計」と「キャッシュ戦略」にあります。

まずは無料・小コストで検証し、手応えと数値を持って駅すぱあとAPIの商用契約へステップアップ。

レート制限や表記ルールを味方につけ、設計でムダを削り、体験は豊かに。

そんな堅実な進め方が、旅サービスを長く育てる最短ルートです。

宿探しと経路検索をどうつなぐの？3つのAPIを連携させる基本の流れは？

宿探し×経路検索を一本化する実装ガイド（楽天トラベル×Express×駅すぱあと）

「ホテルは良さそう。

でもアクセスが大変そう」「移動は便利だけど宿が高い」――この二律背反を同時に解くには、宿のデータと経路のデータを同じ土俵に載せて比べることが近道です。

楽天トラベルの宿データ、駅すぱあとの経路データを、Expressでつないでひとつの指標で判断できるように整える。

これが「迷わない旅計画」のコアとなる流れです。

全体アーキテクチャのイメージ

構成はシンプルです。

フロント（Web/アプリ）からExpress（自前の連携用API）に問い合わせ、Expressが背後で2つの外部APIを呼び出して結果を集約・整形します。

• フロントエンド：出発地、日時、人数、予算、優先条件（時間/料金/乗換）などの入力UI。結果表示は「宿カード」に移動指標を重ねて比較。
• Express（連携レイヤー）：入力を受けて、楽天トラベルと駅すぱあとを順序よく呼び出し、共通の指標にまとめる。キー管理、キャッシュ、レート制限の吸収役。
• 楽天トラベルAPI：宿の検索・詳細・位置情報を取得。
• 駅すぱあとAPI：駅名サジェスト/正規化、経路探索、所要時間・料金・乗換回数の取得。

ポイントは「連携の順序」と「場所の正規化」。

宿情報を先に取り、宿の“場所”を駅すぱあとで使える形に整えてから経路を引きます。

連携の基本ステップ（最短ルート）

1. 入力を受け取る：出発地（駅名/住所）、出発または到着希望時刻、人数、部屋タイプ、予算、優先条件（時間・料金・乗換・歩行）を受理。
2. 宿を候補抽出：楽天トラベルAPIでエリアやキーワード、日付、料金帯、空室条件を指定して候補を最大N件取得。
3. 宿の位置を確定：住所/緯度経度/アクセス文を解析。緯度経度がある場合はそれを優先。なければ住所から地理座標を補完。
4. 最寄り駅を特定：駅すぱあとの駅名サジェストや近傍駅検索を使い、宿の緯度経度から「到達可能な最寄り駅候補」を1〜3件抽出。駅名ゆらぎを排除して公式な駅IDを紐づけ。
5. 経路を引く：出発地→最寄り駅（→宿までの徒歩/バス）の経路を時刻指定で検索。所要時間、料金、乗換、到着時刻、終電/始発の可否などを取得。
6. 往復の実用性を評価：チェックアウト後の移動（例：宿→観光地/空港）も試算し、滞在全体の“移動負担”を数値化。
7. スコアリング：宿の価格や評価に、移動の時間・料金・乗換の重みを足し合わせ、比較しやすい総合スコアを算出。
8. 結果を提示：宿カードに「ドアtoドアの時間」「合計運賃」「乗換回数」「終電に間に合うか」「翌朝の始発時刻」などを並べ、予約リンク（楽天トラベル）へ誘導。

この流れを守ると、「宿の良し悪し」と「移動のしやすさ」を同時に見える化でき、意思決定が素早くなります。

データをつなぐ鍵は「場所の正規化」

宿と経路をうまく繋げるには、場所の表現を統一する必要があります。

住所表記や駅名のゆらぎを吸収し、API間で食い違わない“共通キー”を作ることが重要です。

3層の正規化戦略

1. 座標を優先：宿の緯度経度が取得できれば最強。駅すぱあとに渡す際も座標→近傍駅の順で正規化。
2. 公式駅IDに変換：駅名文字列は揺れやすいので、候補の駅を提示するエンドポイントで正式な駅ID/コードに置き換える。
3. フォールバックを用意：座標なし/曖昧住所のときは、アクセス文のキーワード（「○○駅徒歩5分」など）から駅を抽出し、候補として検証。

これにより「駅名が合わず経路が引けない」「地図上は近いのに徒歩時間が極端に長く出る」といった不整合を避けられます。

Expressで作る連携APIの設計

Expressは“橋渡し”に徹します。

外部APIの生データをそのまま返すのではなく、旅の意思決定に必要な形に集約して返すのがコツです。

ミニ設計（代表的なエンドポイント）

• 検索統合エンドポイント（例：/search-stay-route）
  • 入力例：出発地（駅名/座標）、チェックイン/アウト、人数、上限予算、優先条件、最大候補数。
  • 出力例：宿ID、名称、料金（総額/1人あたり）、緯度経度、最寄駅（ID/名称/距離）、到着所要時間、運賃、乗換回数、徒歩分数、終電・始発関連フラグ、総合スコア、予約URL。
• 補助エンドポイント
  • 駅サジェスト：文字列→候補駅（ID付）
  • 近傍駅検索：座標→駅候補（距離順）
  • 宿検索：楽天APIの薄いラッパ。キャッシュ前提。

キャッシュと同時実行の工夫

• 検索の段階キャッシュ：同じ条件の宿一覧は短時間（5〜15分）キャッシュ。
• 段階的探索：宿候補が多い場合、まず上位N件だけ経路を引き、スクロールや並べ替え時に追加ロード。
• 同時実行の上限：駅すぱあとの呼び出しは並列数を絞り、キューを挟んでレート制限を越えないように制御。

安全なキー管理とCORS回避

• 外部APIキーはサーバ側に保持。フロントからはExpressだけを叩く。
• ドメイン制限やIP制限が可能なら積極活用。ログで不正呼び出しを検知。

実用シナリオで流れを追う

例：紅葉シーズンの京都1泊2日

金曜の夜に東京駅を出発し、土曜に京都駅周辺で1泊、日曜は清水寺や嵐山を回って夕方に帰京するプランを想定します。

優先は「乗換少なめ」「到着時間厳守」。

1. 条件入力：出発地＝東京駅、金曜19:30頃出発、チェックイン21:30目標、2名1室、予算2万円/人、乗換優先度を低く設定。
2. 宿候補取得：楽天トラベルから京都駅〜四条周辺の空室を取得。料金とレビューで上位30件に絞る。
3. 位置と最寄駅：各宿の緯度経度→近傍駅候補（京都/烏丸/祇園四条など）を抽出。徒歩分数を見積もる。
4. 経路探索：東京駅→（新幹線）→京都駅→徒歩/地下鉄→宿、の時刻指定ルートを複数評価。終電可否もチェック。
5. スコアリング：到着時刻偏差（21:30±15分以内を高評価）、乗換回数、徒歩時間、宿料金・評価を統合しランキング。
6. 翌日の動線：宿→清水寺→嵐山→京都駅→東京駅の流れも試算。無理のない所要時間かを可視化。
7. 提示：上位5件のみ詳細経路を展開表示、残りは“タップで計算”にしてAPIコールを節約。即予約ボタンを用意。

この流れなら、「アクセスの不安」「翌日の動線の破綻」を事前に潰しつつ、宿と移動を一画面で比べられます。

エラーや穴を先回りして防ぐ

• 駅名の揺れ：同名駅（例：○○駅前/本町）や旧駅名に注意。必ず駅IDで管理。
• 徒歩と実距離の差：川や踏切で“直線距離は近いのに遠回り”が起きる。徒歩経路APIの距離/時間を使うか、安全側に補正。
• バス依存エリア：最寄り駅からのバス時刻で夜間到着が不可になることがある。最終バス時刻の警告を表示。
• 終電リスク：到着時刻が終電ギリギリなら代替案（1本前/タクシー目安）を併記。
• レート制限：大量の候補に一気に経路を引かない。段階的・遅延計算で回避。
• 住所の欠落：宿の住所品質が低い場合に備え、緯度経度やアクセス文を優先して推定。
• メンテ/障害：外部APIが落ちたら“移動情報なしで宿のみ表示”にフォールバック。後から再計算ボタンを用意。

賢く回すための最適化

呼び出し回数を削る工夫

• 上位N件のみ経路即時計算、他は「表示時にオンデマンド」。
• 同じ出発地・同時刻の経路は結果が近い。近傍駅グルーピングで計算を再利用。
• 宿一覧のキャッシュTTLは短め（イベント時はさらに短縮）。

比較しやすい指標設計

• ドアtoドア所要時間（分）
• 合計運賃（円）
• 乗換回数（回）
• 徒歩総時間（分）
• 終電セーフ/アウト、翌朝始発到達可否
• 宿の総額/1人あたり、レビュー平均

これらを重み付けで一つのスコアにまとめると、一覧で直感的に比較できます。

重みはプリセット（「とにかく早く」「安く」「疲れにくく」など）を用意し、切り替えで再計算できると便利です。

当日変動への耐性

• 遅延・運休情報が取れる場合は再計算をトリガー。
• 天候悪化時は徒歩重みを下げ、乗換少ないルートを優先。
• 満席ピークは1本前の便/別線を自動提案。

実装チェックリスト

• 出発地は駅名/住所/現在地の三択をサポートしているか。
• 宿の緯度経度が取れない場合のフォールバックがあるか。
• 駅名は必ず公式IDで保持・伝搬しているか。
• 上位候補のみ即時計算、残りはオンデマンドになっているか。
• 終電・始発の可否表示がわかりやすいか。
• 料金の内訳（宿代・運賃）が明確か。
• 外部APIエラー時のメッセージと再試行導線があるか。
• APIキーはフロントから見えないか（サーバ管理・環境変数）。
• ログとアラートで失敗パターンを検知できるか。
• アクセシビリティ（色覚・フォントサイズ）とモバイル最適化は十分か。

ケース別の小ワザ

• 観光密集地：徒歩を細かく評価。徒歩10分以内の宿にバッジ付与。
• 郊外・温泉地：バス/送迎の運行時間を注意喚起。送迎予約の要否も表示。
• 出張：朝の移動（宿→会場）を優先評価。到着したい時刻を固定して逆算。
• 家族旅行：乗換回数と徒歩時間に高いペナルティを設定してスコアリング。

データ品質を上げるメタ情報

• 駅から宿までの標高差や坂道情報を“疲れ指数”として加点/減点。
• 雨天時に屋根付き経路率を優先（地下通路/アーケード）。
• 週末・平日の混雑係数を所要時間に微加算。

導入のスモールスタート手順（要点）

1. Expressを立て、環境変数で外部APIキーを管理。
2. 宿検索の薄いラッパを作り、緯度経度と予約URLを必ず返すよう整形。
3. 駅サジェスト/近傍駅のラッパを作成。駅IDを中心に扱う。
4. 経路検索を時刻指定で呼ぶ関数を用意。所要時間・料金・乗換・徒歩を抽出。
5. 統合エンドポイントで「宿→最寄駅→経路」の順に結合し、スコアを計算。
6. UIで上位結果のみ即時計算、スクロールで追加計算。
7. キャッシュと同時実行数を調整し、レート制限を超えない運用にする。

よくある疑問のヒント（要約）

• 宿と経路のどちらを先に？

  → 宿の候補数が少ないなら先に宿。多いなら先にエリア×最寄駅を粗く当てる方法も有効。

• 地図は必要？

  → 比較には不要だが、最寄り駅〜宿の徒歩が複雑な地域では静的マップでも有用。

• スコアはどう決める？

  → デフォルト3種（早い/安い/楽）＋カスタム。重みはUIで可変に。

結び：宿と移動を「同じものさし」で比べれば、迷いは減る

楽天トラベルの豊富な宿データと、駅すぱあとの堅牢な経路データ。

Expressがその間を取り持ち、「場所の正規化」と「指標の統一」を行えば、候補比較にかかる時間は驚くほど短くなります。

移動時間・料金・乗換・徒歩・終電の可否までを1枚のカードに集約することで、「ここに泊まりたい」が「ここなら到着できる、翌朝も動きやすい」という確信に変わります。

計画の自由度を上げつつ、当日の不安を下げる。

このバランスが、3つのAPI連携で実現できる最大の価値です。

コードが書けなくても使えるの？スプレッドシートやノーコードでの活用法は？

コードが書けなくても大丈夫！楽天トラベル×駅すぱあと×Expressをスプレッドシート＆ノーコードで動かす完全ガイド

APIと聞くと「プログラミングが必要では？」と思いがちですが、いまはスプレッドシートやノーコードツールを使って、宿検索や経路検索、旅程の自動化まで十分に実現できます。

ここでは、楽天トラベルAPI・駅すぱあとAPI・そして中継役（本稿では“Express”と呼ぶHTTPゲートウェイやワークフローサービス）の3つを、コードなしで組み合わせて使う具体的な手順とコツを一気に解説します。

「コード不要」でAPIを扱う基本発想

ポイントは以下の3つです。

• スプレッドシートやExcelで「URLにパラメータを入れて取得」できる仕組みを使う
• Zapier/Make/n8n Cloudなどのノーコード自動化で「呼び出しと整形」を任せる
• Bubble/Glide/AppSheetなどに「表示と操作のUI」を担わせる

この役割分担を決めると、コードを書かずに、宿データと経路データをつなぎ、旅程を自動生成・共有するまでの流れが組めます。

スプレッドシートでREST APIを呼ぶ3つの王道

1) Googleスプレッドシート＋APIアドオン

アドオンを使うと、URLとパラメータを設定するだけでJSON/CSVを取り込めます。

代表例は「API Connector」「Apipheny」「Coupler.io」など。

どれもGUIで以下の操作が可能です。

• HTTPメソッド（GET/POSTなど）とURLを設定
• APIキーやヘッダーを入力（例：Authorization、app_id など）
• レスポンスのJSONを列に展開
• 定期自動更新（5分〜1日間隔など）

楽天トラベルAPIの例（ホテル検索）:

https://app.rakuten.co.jp/services/api/Travel/KeywordHotelSearch/20170426?applicationId=YOUR_APP_ID&keyword=箱根&datumType=1&format=json

駅すぱあとAPI（駅すぱあとWebサービス／Ekispert API）の例（シンプル経路）:

https://api.ekispert.jp/v1/json/search/course/light?key=YOUR_API_KEY&from=新宿&to=箱根湯本

上記URLをアドオンにセットすれば、レスポンスJSONがシートに並びます。

アドオンが難しければ、まずは無料トライアルで挙動を掴むのがおすすめです。

2) Excel（Power Query）でJSONを整形

Excelの「データ」→「データの取得」→「その他のソース」→「Web」からAPI URLを指定すると、Power QueryがJSONを階層表示。

クリックで展開し、必要な項目だけを列に変換できます。

定期更新も簡単で、社内PCにExcelしかない環境でも強い選択肢です。

3) Airtable/Notion＋外部連携

Airtableは「Data Fetcher」などの拡張や、Make/Zapierと組み合わせるとAPI取り込み基盤になります。

Notionは直接API取得は得意ではありませんが、Make経由でデータベースに自動追加すれば「旅のハブ」化が可能です。

宿データと経路データを一枚にまとめる設計図

APIを扱う上で重要なのは「キー設計」と「正規化」。

最低限、以下を押さえると管理が楽になります。

• 宿テーブル：宿ID、宿名、住所、緯度、経度、最寄り駅（候補）、料金、URL
• 駅テーブル：駅名、駅コード、緯度、経度、路線
• 経路テーブル：出発駅、到着駅、所要時間、乗換回数、料金、到着時刻、ルートURL

宿データに「緯度・経度」があると、駅との距離計算や地図表示に応用できます。

最寄り駅が取れない場合は、住所からジオコーディング（スプレッドシートのアドオンや地図サービス）で座標取得→駅リストとの距離最小で「最寄り駅推定」という手もあります。

Googleスプレッドシート実践：最短セットアップ

ステップ1：アドオンで楽天トラベルAPIを取り込む

1. アドオン（例：API Connector）をインストール
2. 新しいリクエストを作成し、URLにホテル検索エンドポイントを設定
3. クエリにパラメータ（applicationId、keyword、hits、format=json など）を入力
4. 実行して、宿名、宿ID、住所、緯度・経度、料金、プランURLなどを展開

シートA（Hotels）に宿一覧が並びます。

ステップ2：駅すぱあとAPIで所要時間・料金を取得

1. 駅すぱあとAPIのキーを取得（商用・公開利用の条件は要確認）
2. アドオンで新規リクエストを作成し、from（出発駅）とto（最寄り駅）を設定
3. レスポンスから最短ルートの所要時間、料金、乗換回数、到着時刻を抽出
4. シートB（Routes）として保存

出発駅はユーザー入力セル（例：B2）に固定し、toはHotelsシートの最寄り駅列を参照すると、宿ごとの移動コストが一括で揃います。

ステップ3：Express（中継）を使って安定化

ブラウザやノーコードUIから直接APIを叩くと、CORSやキー露出の課題が出ます。

そこで、MakeやZapierの「Webhook/HTTP」機能を使って中継（プロキシ）を作るのが安全・簡単です。

• Makeで「Webhook（Custom）」を作成 → 受け取ったパラメータを元にAPIを呼ぶ → 整形して返す
• スプレッドシートやBubble等は、このWebhook URLを呼ぶだけでOK
• APIキーはMakeのセキュアな環境変数/コネクタに保持し、フロントには出さない

これが“Express”的な中継の考え方。

コードを書かずに、鍵管理とCORS回避、整形を両立できます。

ステップ4：シート関数で「旅のスコア」を作る

宿の魅力は価格だけではありません。

たとえば以下のような総合スコアを作ると、比較が一気に楽に。

• 総合スコア＝宿料金×重みA＋所要時間×重みB＋乗換回数×重みC＋徒歩時間×重みD
• 重みは別シートに置いて簡単に調整できるようにする
• FILTER/SORT/QUERY関数で「条件に合う順」で並べ替え

当日の発着時刻に合わせて再計算すれば、「今から出ても余裕？」「最終便に間に合う？」も見える化できます。

ノーコード自動化（Make/Zapier/n8n Cloud）のワークフロー例

フロー例1：フォーム入力→最適な宿＋経路をSlackで通知

1. Googleフォームで「出発駅・予算・チェックイン日・人数」を受け付ける
2. Makeでトリガー（新規回答）→ 楽天トラベルAPIで候補を取得
3. 駅すぱあとAPIで各候補の所要時間・料金を算出
4. スコア順にトップ3を整形 → Slack/メールにカードで通知（宿名、料金、所要時間、予約URL）

フロー例2：日次更新の「おすすめ宿リスト」を自動生成

1. 毎朝6時にMakeが起動 → 楽天トラベルAPIで最新の空室・価格を取得
2. 駅すぱあとAPIで主要駅からのアクセス性をスコアリング
3. Googleスプレッドシートを更新 → Notion/サイトに自動公開

フロー例3：予約が成立したら旅程ページを自動発行

1. 予約完了メールをGmailで検知
2. 宿名・住所・日付を抽出 → 最寄り駅を推定
3. 駅すぱあとAPIで当日の最適ルートを算出
4. Notionに旅程ページを作成し、カレンダー・マップ・チェックリスト付きで共有

UIまでノーコード：見せ方を作る

AppSheet：スプレッドシートをそのままアプリ化

Google Sheetsのデータを読み込み、一覧・詳細・地図表示までノーコードで作成。

ルートURLや予約URLをボタン化して、当日の操作性を高められます。

権限設定も簡単で、家族やチーム共有に最適です。

Bubble：API Connectorで柔軟なUI

Bubbleの「API Connector」プラグインに楽天トラベルAPIや中継Webhookを登録。

繰り返し要素（Repeating Group）にバインドすれば、写真付きのホテルカード一覧が即完成。

お気に入り登録やタグ絞り込みなど、UIの自由度が高いのが強みです。

Glide/Adalo：モバイルに最適化

Glideはスプレッドシート直結でモバイルアプリをノーコード生成。

リスト＋地図、フィルタ、共有が早い。

旅行メンバー用の軽量アプリとして相性◎です。

実務で効く「運用のコツ」

呼び出し回数を最小化（コスト＆制限対策）

• キャッシュ：同じ条件の検索結果は一定時間（例：1〜6時間）再利用
• バッチ：ユーザー操作のたびにAPIを叩かず、バックグラウンドで一括更新
• 差分更新：全件ではなく、日付や価格が変わりそうな範囲だけ問い合わせ

CORSとキー管理は「中継」で解決

• Make/ZapierのWebhookを「安全なゲートウェイ」にする
• キーはフロントに埋め込まない（URLパラメータで露出させない）
• レート制限に備えてバックオフ（一定時間待って再試行）を設定

データ整形の型を作る

• JSONパスのマッピング表を1枚用意（宿→列A〜G、経路→列H〜N など）
• 駅名の揺れを辞書で吸収（例：「新宿」「新宿駅」「Shinjuku」）
• 日付・時刻はISO形式（YYYY-MM-DD、HH:MM）で統一

よくあるつまずきと即解決ヒント

JSONが深すぎて展開できない

アドオンの「フィールド選択」機能で必要な階層だけ抽出。

どうしても複雑なときは、Makeで一度整形してからシートに流すと安定します。

駅名が一致せず、経路が返らない

駅すぱあとの駅コード/候補APIで正規化するか、辞書を作成。

ユーザー入力はプルダウン式に限定し、入力揺れを防ぐのが確実です。

重複データが溜まる

宿ID＋日付でユニークキーを作り、追加時に重複チェック。

Makeなら「Search Rows → Create/Update」を使ってUPSERTにします。

速度が遅い

1回のリクエストで取りすぎない（ページング活用）。

表示用は軽量列だけの「ビュー」シートを作り、詳細は別シートに。

規約と出典表記、最低限の配慮

• 各APIの利用規約・商用可否・出典表記ルールを遵守
• 料金・所要時間は変動があるため「参考」である旨を明示
• 外部リンク（予約/経路）には遷移先が公式であることを明記

今日から試す「最小ステップ」

1. Googleスプレッドシートを開く（Hotels、Routesの2シートを用意）
2. API Connector（またはApipheny）を入れる
3. 楽天トラベルAPIのアプリIDを取得し、キーワード検索を1回実行
4. 駅すぱあとAPIのキーを取得し、出発駅→最寄り駅で所要時間を1件取得
5. 重みを決めた総合スコア列を作って並べ替え
6. MakeでWebhookを作り、同じ処理を自動化（朝6時に更新）
7. AppSheetでシートを読み込み、一覧と地図の簡易アプリを公開

ここまでなら、完全ノーコードで到達できます。

慣れたら、中継でデータ整形を高度化し、UIもBubble/Glideで磨き上げれば、旅の検索から意思決定までが一枚のシートと数本のシナリオで完結します。

結論：ノーコードでも「探す→決める→動く」まで行ける

スプレッドシートは「データのハブ」、Make/Zapierは「見えないエンジン」、AppSheetやBubbleは「見せる・触るUI」。

この三位一体で、楽天トラベル×駅すぱあと×Express（中継）をつなげば、コードを書かずに高品質な旅体験を自動で組み立てられます。

まずは小さく、1回の検索と1本のルートから。

手を動かせば、APIは思った以上に身近で、そして強力です。

規約や表記はどう守るの？著作権・データ利用・プライバシーの注意点は？

楽天トラベル×Express×駅すぱあとAPIを安心して使うための「規約・権利・プライバシー」実務ガイド

便利な旅アプリやウェブ特集をつくるうえで、APIの活用は不可欠です。

ただし、公開後に指摘を受けたり、アカウント停止や法的リスクにつながるのは避けたいところ。

ここでは、楽天トラベル・駅すぱあと各APIと、中継役として使うExpress（Node.js）を組み合わせる際の、表示ルール、著作権・データ利用、プライバシー対応の要点を、現場で役立つ実務目線でまとめます。

全体像：どのルールを同時に守るのか

APIを使うときは、複数のルールが同時に適用されます。

どれか1つを守ればよいのではなく、すべてを満たす必要があります。

• 提供元の規約・ガイドライン（例：楽天トラベルの開発者規約、駅すぱあとAPIの利用規約・表記ルール）
• 掲載データの権利（画像・レビュー・ルート情報などの著作権・データベース権・商標）
• 自社サービスの法令遵守（個人情報保護法、景表法、電子契約法、電気通信事業法等）
• 配信先のルール（アプリストア、広告プラットフォーム、アフィリエイトの表示基準）
• オープンソース利用のライセンス（ExpressはMITライセンス）

まずは「規約→権利→プライバシー→表示」の順で要件を洗い出し、設計に落とし込みましょう。

表示・クレジットの基本設計

楽天トラベルの表示で押さえるべきこと

• 出典の明示：宿情報・料金・在庫など、APIから得た内容には「情報提供：楽天トラベル（出典リンク）」の表記を付ける。
• ディープリンク：施設詳細や予約導線は、提供元が指定するリンク形式で遷移させる（トラッキングパラメータやアフィリエイトIDの付与ルールに従う）。
• 価格注記：「料金は変動します／最終的な料金・在庫はリンク先でご確認ください」といった最新性の注記を近接表示。
• ロゴ・ブランド：楽天のロゴや名称の使用はガイドラインに従う。無断改変・二次ロゴ化・視認性不足を避ける。
• 禁止事項：スクレイピング、価格や在庫の恒久保存・二次配布、ランキングの恣意的改ざんなどは行わない。

駅すぱあとの表示で押さえるべきこと

• クレジット：経路・運賃・時刻に「提供元の表示（例：駅すぱあと）」と著作権表記を付ける。
• 再利用制限：取得したデータの再配布や、原型を留めない形での大量利用（独自DB化など）は原則不可。
• 最新性の注記：ダイヤ改正・運休等により差異が生じうる旨を明記。誤差に備えるUI（再計算ボタンなど）を併設。
• 画面キャプチャの扱い：スクリーンショットの公開はガイドラインに基づく（許諾・透かし・サイズの要件など）。

Express（中継サーバー）のクレジット

• MITライセンス：再配布（バイナリ配布やSaaSのOSS通知ページ等）を伴う場合は著作権表示とライセンス文面を含める。
• 脆弱性対策：依存ライブラリのライセンスも確認し、セキュリティ更新を継続。

表示の最小サンプル（フッターやカード近接に配置）

例：

宿の情報：出典 楽天トラベル（最新の料金・在庫はリンク先でご確認ください）／
経路情報：出典 駅すぱあと（時刻・運賃は変更になる場合があります）

著作権・二次利用の境界線を理解する

APIレスポンスの権利帰属

APIで得られるデータの多くは、提供元や第三者に権利が帰属します。

表示は認められていても「保存・加工・再配布」には別の制限がかかることが一般的です。

特に、価格・在庫・時刻表など「時間依存の事実情報」は、長期保存して独自配布すると規約違反になりやすい領域。

必要な範囲に限って短期間キャッシュし、表示目的のみに使うのが基本姿勢です。

画像・レビュー・テキストの扱い

• 写真は著作権の対象。提供元が許諾した形式・サイズ・透かし・クレジットで掲載する。
• レビューや説明文は転載制限が厳しい。抜粋・要約可否、引用の要件（出典明示・改変禁止など）を必ず確認。
• サムネイル自動生成やトリミングにも注意。意匠・商標を損なう加工は避ける。

キャッシュとスクリーンショットの違い

• キャッシュ：APIの安定化・コスト最適化目的で短期保存するもの。許可された範囲・期間で、第三者提供はしない。
• スクショ：権利物の二次利用にあたる可能性が高い。提供元のポリシー（公開可否、透かし、画面要素の改変不可など）に従う。

スクレイピングとAPIの線引き

公式APIが用意されている場合、スクレイピングは多くのサイトで明確に禁止されています。

安定性・法的リスクの両面から、APIを利用し、足りない情報は許諾を得て補完するのが原則です。

データ保存・再配布の設計指針

保存期間のルールを決める

• 瞬間値（料金・在庫・時刻）：分〜数時間レベルの短期キャッシュ。表示・内部集計のみに限定。
• メタ情報（施設ID、緯度経度）：正規化して保持可能。ただし出典を追跡できるようにフラグを残す。
• ログ：個人情報を含まない形で要約し、目的と期限を定めて保管。

バックアップと監査ログ

復旧のためのバックアップは必要ですが、APIレスポンスの原文を長期保存・再配布しないこと。

データベースには「取得日時・出典・同意根拠（必要に応じて）」を記録し、監査に備えます。

二次配布とAPIキーの扱い

• APIから得たデータを第三者に再配布しない（静的JSONをCDNで配る等も要注意）。
• フロントエンドにAPIキーを埋め込まない。Express等のサーバーで秘匿し、レート制限・ドメイン制限を実装。

国外配信・越境移転

海外ユーザーに提供する場合や海外リージョンのサーバーを使う場合、データ移転の同意や契約条項が必要になることがあります。

個人データを含むなら特に注意してください。

個人情報・プライバシーの実務

収集するデータの棚卸し

• 必須か任意か：メール、電話、氏名、位置情報、旅程（予定・同行者）、IP・Cookie、デバイスIDなどを分類。
• 目的の特定：予約連絡、リマインド、混雑通知、レコメンド、カスタマーサポート等の目的と法的根拠を明記。

同意とクッキー管理

• 解析・広告・A/Bテスト用Cookieは、同意取得とオプトアウト手段を提供。
• 未同意時は計測タグを発火しない。ログは匿名化・仮名化を徹底。

権利行使への対応

• 開示・訂正・削除・利用停止の手続きを公開。問い合わせ先、確認手順、回答期限の目安を明記。
• バックアップ・ログに残るデータの消去方針（不可逆化・停止処理）もあらかじめ設計。

セキュリティ実装の最低ライン

• 通信の暗号化（HTTPS/TLS）、キー管理（環境変数・KMS）、権限分離（最小権限のAPIトークン）。
• 入力値検証、レート制限、CSRF・XSS対策、依存パッケージの更新。
• インシデント対応計画（検知→封じ込め→通知→再発防止）。

位置情報の配慮

位置情報はセンシティブです。

明確な同意と、常時取得のオン/オフ切り替え、精度の段階的制御（おおよそ位置のみ等）を用意しましょう。

広告・アフィリエイト運用の留意点

• 成果報酬の明示：アフィリエイトリンクであることを分かる形で表示。
• 比較の公平性：恣意的な並び替えや非対象の隠蔽を行わない。アルゴリズムの考え方を簡潔に説明。
• 誤認表示の回避：価格・在庫・所要時間は「目安」「最新情報は提供元で確認」注記を近接表示。

ブランド・商標の取り扱い

• 名称・ロゴはガイドラインに沿って使用。比率・余白・背景色のルールを守る。
• ニックネーム・省略形・装飾による改変を避ける。商標記号やクレジットが必要な場合は付与。
• 第三者の商標（鉄道会社名、路線名、施設名）にも配慮し、必要に応じて表記ルールに従う。

公開前のセルフチェックリスト

• 出典クレジットとディープリンクを全ページ・全カードに表示しているか。
• 価格・在庫・ダイヤの最新性注記が近接表示されているか。
• キャッシュの保持期間・用途・削除条件が決まっているか。
• APIキーがフロントに露出していないか（中継サーバー経由か）。
• プライバシーポリシー・利用規約・特商法/会社情報ページが整備されているか。
• Cookie同意とオプトアウトが機能しているか（タグの発火制御）。
• インシデント対応手順と連絡先が社内共有されているか。
• ロゴ・商標の使用がガイドライン準拠か（サイズ・余白・色）。
• 第三者提供・再配布にならないUI/設計になっているか。
• テストデータでの検証が完了しているか（本番キー流出防止）。

運用を安定させる実務フローの例

1. 規約確認と要件定義（表示・保存・リンク・禁止事項をドキュメント化）。
2. データ分類と保持方針（短期キャッシュ／長期保存不可／匿名化ログ）。
3. Expressでプロキシ実装（キー秘匿、レート制限、レスポンス整形、クレジット付与）。
4. UIへの注記・出典・再計算導線の組み込み。
5. 監査ログ・死活監視・レイテンシ監視の導入。
6. 四半期ごとの規約再確認と表示見直し（シーズン前に重点チェック）。

ありがちなNGとリスク

• フロントから直接APIを叩いてキーが流出する。
• 価格や時刻を無期限に保存し、静的JSONとして配布してしまう。
• 出典表記やディープリンクを省略する。
• ロゴの縦横比を崩したり、独自色で塗り替える。
• レビュー文を全文転載する（引用要件不備）。
• 未同意のCookieで広告タグを発火する。
• アクセスログに個人情報を平文で残す。
• スクレイピングで取得したデータを混在させる。
• 障害時の連絡先・対応手順が用意されていない。
• 海外CDN配信で越境移転の同意・契約を失念する。

文例テンプレート（編集してご利用ください）

出典・注記の例

宿泊情報は楽天トラベルの提供データに基づき表示しています。料金・在庫・キャンセル条件は
変動します。ご予約前にリンク先で最新情報をご確認ください。
経路・運賃情報は駅すぱあとの提供データに基づきます。ダイヤ改正や運行状況により
実際と異なる場合があります。

プライバシーポリシー抜粋の例

取得する情報と目的
当社は、予約連絡・旅程提案・障害対応のため、氏名、連絡先、検索条件、閲覧履歴、位置情報（同意時のみ）、
Cookie情報等を取得・利用します。
第三者提供
法令に基づく場合を除き、ご本人の同意なく第三者への提供は行いません。
Cookie等の利用
解析・広告のためCookie等を利用します。設定から同意の変更・撤回が可能です。
開示・削除の請求
保有個人データの開示・訂正・削除等の請求は、こちらの窓口までご連絡ください：xxxxx@example.com

利用規約の注記例

免責事項
当サイトに掲載される料金・所要時間・運賃・在庫等は目安であり、正確性・最新性を保証するものではありません。
最新の情報は各提供元のサイト・アプリにてご確認ください。
知的財産権
当サイトに表示されるコンテンツの権利は、当社または正当な権利者に帰属します。権利者の許諾なく複製、
転載、再配布することを禁じます。

開発の工夫で「規約を守りやすく」する

• 中継サーバーで必ず整形：出典・注記をレスポンス時に付与し、フロントでの抜け漏れを防ぐ。
• キャッシュのTTLをコード化：料金・ルート系は短命、メタ情報は長命といった区分を一元管理。
• フェイルセーフUI：不確実性の高いデータには「再計算」「最新情報へ」ボタンを近接配置。
• 権限で出力を変える：社内検証用は詳細ログ、本番は匿名化とマスキング。

最後に：長く使われるサービスは「マナー」が支える

API活用はスピード勝負ですが、規約・権利・プライバシーの配慮が甘いと、公開後に止まります。

最初から「出典の見える化」「最新性の注記」「短期キャッシュ」「キー秘匿」「同意管理」を設計に組み込めば、開発も運用もシンプルに。

信頼はUIの片隅にある一文や、小さなクレジットの積み重ねで生まれます。

安心して使ってもらえる旅体験づくりのために、今日からチェックリストをプロジェクトの標準にしていきましょう。

注：実際の表記要件・利用可否・リンク形式・ロゴ使用条件等は、各提供元の最新ガイドライン・規約で必ずご確認ください。

仕様やルールは予告なく更新されることがあります。

うまく動かないときどうする？よくあるつまずきとトラブル解決のコツは？

APIが動かない？

楽天トラベル×Express×駅すぱあと連携のつまずき解消ガイド

宿探し（楽天トラベルAPI）と移動計画（駅すぱあとAPI）を、Expressの中継でつないだ途端、「昨日まで動いてたのに…」「本番だけ失敗する…」という壁に当たることがあります。

ここでは、よくある症状を再現→原因切り分け→最短で復旧という順で解説し、同じトラブルを繰り返さない設計のコツまでまとめます。

最初に確認する5つの基本

• 環境差の把握：開発・ステージング・本番でホストやキーを固定値にしていないか。環境変数が未設定だと別のAPI先に飛ぶことがあります。
• 時刻のズレ：署名やタイムスタンプを使うAPIはサーバー時計のズレに弱いです。NTPで同期、タイムゾーンはAsia/Tokyoに。
• リクエストの完全記録：URL・クエリ・ヘッダ・本文・レスポンスコードを1セットで保存。成功例と失敗例をDiffできれば復旧が早まります。
• 最小再現：条件を削って成功する最小パターンを探す。「駅名だけ」「住所だけ」「半径1kmだけ」と足し算で原因を特定。
• 依存関係：CDN・WAF・VPN・社内プロキシが間に入っていないか。特に海外リージョン経由で速度やタイムアウトが悪化します。

楽天トラベルAPIで起きやすい症状と対処

宿が出ない・件数が極端に少ない

• 地点条件の矛盾：緯度経度＋キーワード＋エリアIDを重ねがけすると絞り込みすぎます。まずはどれか1軸に。
• 半径指定の誤差：距離の単位や小数点の丸めで0件になることがあります。半径を広げて成功するか確認し、段階的に縮めます。
• 日付のフォーマット：ゼロ埋め漏れ（例：2025-9-3 → 2025-09-03）に注意。ISO 8601で統一しましょう。
• 在庫更新のタイミング：深夜帯は在庫同期の都合で揺らぎます。キャッシュのTTLを日中と夜間で変えるのも有効です。

並び順が期待と違う

• ソートキーの明示：価格順・距離順などは明確に指定。距離順は「基準座標」が必須です。
• 価格の種類：1室あたり／1人あたり、素泊まり／朝食付きなどの違いをUIで切り替えられるように。

住所・緯度経度のズレで駅紐付けに失敗

• ジオコーディングの再確認：公式の緯度経度があるならそれを優先。なければ住所→座標の変換でNFKC正規化（全角/半角統一）を。
• 最寄駅の定義：直線距離で最も近い駅≠実利用の最短。徒歩の可否（川・坂・踏切）を考慮して2〜3駅候補を出し、駅すぱあとで到達時間が最短の駅を採用します。

駅すぱあとAPIでつまずくポイント

駅名ゆらぎで経路ヒット率が落ちる

• 表記差への対処：長音（ケ→ヶ）、全角/半角、英数字、旧字などをNFKCで正規化。余分なスペースはトリム。
• 駅コードの採用：テキスト検索よりも駅コードの利用が堅牢。住所→候補駅→駅コードの2段階に分けます。
• ランドマーク名を避ける：商業施設の名称検索は外す。必ず駅としての名称を入力します。

特急・新幹線・IC運賃の設定漏れ

• 乗車種別の明示：特急を避けたい、IC運賃を優先したいなどはフラグで指定。デフォルト値を鵜呑みにしないこと。
• 所要時間のズレ：通勤時間帯の混雑や乗換余裕を広めに。体力や荷物が多い場合は「乗換に+5分」を足して安全側に寄せます。

時刻指定の落とし穴

• 発時刻と着時刻：出発優先なのか到着優先なのかで結果が変わります。UIで切替を用意。
• 終電・始発の境界：日付またぎは特に失敗しやすい。日付と時間を別で保持し、日を跨いだかどうかを明示的に扱います。

Express（中継サーバー）まわりの落とし穴

ブラウザがリクエストを止めてしまうとき

CORSの事前検証（OPTIONS）が失敗すると通信できません。

サーバー側で以下を確認してください。

• 必要なオリジンのみ許可：Access-Control-Allow-Originは“*”ではなく自ドメインを指定。
• クレデンシャルが不要なら送らない：withCredentials=trueを無効に。
• プリフライト対応：OPTIONSに200を返し、必要なヘッダ（Authorization, Content-Typeなど）をAllow-Headersに含めます。

タイムアウトと同時処理の管理

• アップストリームに合わせる：API側のSLAより短いタイムアウトにし、ユーザー待ちを減らす。
• 同時実行の制限：駅すぱあとへの経路探索を一度に大量発行せず、キューで制御。バーストを抑えればレート制限回避にも有効。
• フォールバック：宿一覧は出す、経路は後から追記という漸進レンダリングで体感を改善。

観測性が弱くて原因が見えない

• 相関IDの付与：リクエストごとにIDを発行し、楽天・駅すぱあと・自サーバーのログを紐付け。
• サンプリング：全量保存が難しければエラー時は詳細ログ、成功時はサマリのみ。

連携時に起きる「境界」の問題

宿→駅のひも付けを堅牢に

1. 宿の座標を取得（公式値＞ジオコーディング）。
2. 半径1〜2kmで候補駅を複数取得（徒歩の障害物に注意）。
3. 駅すぱあとで出発地から各候補駅の所要時間を評価し、最短を採用。

この3ステップで「直線距離は近いのに行けない」を避けられます。

日本語テキストの正規化で検索精度を上げる

• NFKCで統一：全角英数・長音記号・結合文字を正規化。
• 記号の扱い：ハイフン（-、ー、―）、スラッシュ、中黒は削除して比較する補助キーを作る。
• 表記ゆれ辞書：よく使う地名（ヶ/ケ、崎/﨑など）は手元に変換表を持つと安定します。

日付・時刻の取り扱いを一本化

• 内部はUTC、外部表示はJSTに統一。
• ISO 8601（YYYY-MM-DDTHH:mm:ssZ）で保持し、APIが要求する形式に出力時だけ変換。
• 日跨ぎ判定を関数化して重複ロジックを排除。

呼び出し回数とコストを抑える実装

キャッシュの設計ポイント

• 地理キャッシュ：座標→最寄駅候補は日次で更新。地図の現地改札が変わらない限り高い再利用性があります。
• 人気エリアのプリフェッチ：週末の箱根・京都など需要が読める場所は先にトップNを更新。
• 鍵設計：リクエストを「検索条件の正規化文字列」でハッシュ化。パラメータ順序の違いによるキャッシュミスをなくします。

呼びすぎで門前払いにならないために

• 指数バックオフ＋ジッター：429や503は待ってから再試行。待ち時間にランダム性を加えバーストを回避。
• 段階的詳細化：一覧→詳細の順に、必要になった時だけ深い呼び出しを行う。
• 重複排除：同一セッション・同一条件の連打はフロントで抑制（連打ガード、デバウンス）。

バッチでの前取り更新

• 深夜の低負荷時間に人気条件を更新し、昼間はキャッシュを返す。
• キャッシュの鮮度はUIに表示し、必要なら「更新」ボタンで手動再取得。

ノーコードやスプレッドシートでのよくある詰まり

入れ子が深いレスポンスの扱い

• 「整形用シート」を作ってJSONを一度フラット化。配列はINDEXで1件ずつ展開。
• 列名は「親子_キー名」で統一するとVLOOKUP/RELATEが楽になります。

同じ宿・駅が何度も現れる

• 自然キーを決める：宿ID＋チェックイン日、駅コード＋時刻のように「組み合わせ」でユニーク化。
• 差分更新：全削除→全書き込みは避け、キー一致は上書き、新規だけ追加。

体感速度が出ない

• 先に候補だけ出す：宿名・サムネ・概算料金を先出し、経路は後追いで差し込む。
• 画像は遅延読み込み：Lazy-loadと適切なサイズのサムネイルを用意。

日本語が崩れる・記号が化けるときの対処

• レスポンスのContent-Typeとcharsetを確認。UTF-8前提で受け、フロントでもUTF-8に統一。
• URLエンコード：クエリに日本語を含めるなら、必ずエンコード。特に駅名検索で失敗要因になりがち。
• 改行・タブの除去：住所や施設名に混ざる制御文字は検索前に除去。

見積りと実際の移動コストがズレる理由と抑え方

• ICと切符の差：表示に「IC推定」などの注記を入れ、確定料金ではないことを明示。
• 座席指定・特急料：別途かかる項目はセクション分けして見せると誤解が減ります。
• リアルタイム変動：ダイヤ乱れ時は再計算を促すバナーを表示。古い結果の再利用を避けます。

復旧を早めるテクニック集

最短で原因に辿り着く手順

1. curlやAPIクライアントで「サーバー対サーバー」で成功するか確認。
2. Express経由に切り替えて確認。ここで失敗なら中継の問題。
3. 最後にブラウザから叩いて確認。ここで失敗ならCORSやフロントの問題。

ログに必ず残すべき情報

• 呼び出し先、HTTPメソッド、ステータスコード、レスポンス時間
• 主なクエリ条件（駅名、座標、半径、日付）
• 相関ID、ユーザーセッションID（個人特定情報は含めない）

ユーザー体験を守るフォールバック

• 経路が取れない時は「最寄駅の目安距離」だけ先に出す。
• 宿が0件の時は検索条件の緩和提案（半径拡大、日付変更、予算変更）。
• 失敗を隠さない：再試行ボタンと、次に何をすれば良いかの一言を添えます。

再発防止の設計チェックリスト

• キーと秘密情報はサーバー保管。フロントへは絶対に出さない。
• 検索条件の正規化（駅名・住所・日付）は関数化し、どこから呼んでも同じ振る舞いに。
• レート制限の上限手前でアラートを上げるモニタリング。
• キャッシュのTTLはデータ性質ごとに分ける（宿在庫短め、駅候補長め）。
• 例外パターンの自動テスト（終電直前、日跨ぎ、住所に記号、半径ゼロなど）。

まとめ：原因は「入力のゆらぎ」と「境界の設定」にある

楽天トラベルAPI・駅すぱあとAPI・Expressの3者連携で止まりがちなポイントは、ほとんどが「入力の揺れ（駅名・住所・日本語表記）」と「境界（CORS、レート、タイムアウト）」に集約されます。

正規化してから問い合わせる、呼び出しを絞ってキャッシュする、そして中継の設定を適切にする。

この3つを徹底すれば、再現性の高いシステムに育ち、旅の意思決定を邪魔しない軽快な体験が実現できます。

最後に

本記事は、旅行計画に役立つAPIをやさしく解説。
楽天トラベルAPIで宿の検索・空室・料金・写真などを取得し、記事や特集に自動掲載できる。
駅すぱあとAPIで経路・所要時間・運賃を取得して動線を提示。
さらにExpressで中継APIを作れば、鍵の秘匿やキャッシュ、複数APIの統合で安全かつ高速な表示が可能。
一般サイトでも地図連携やアフィリエイト導線を整え、使いやすい旅行ページを実装できる。