本件のお客様は、訪日外国人観光客向けのサービスを企画された事業者様です。
本案件では、旅行者がいくつかの質問に答えるだけで、生成AIが一人ひとりに合わせた旅程表を自動で作成するサービスを新規開発しました。「何日目にどこを訪れ、何時に移動し、どこで食事をするか」までを日別の時間割として組み立て、そのまま旅行に持っていける形で出力します。あわせて、宿泊施設やレストランの予約代行を依頼できる相談・決済の仕組みも実装しています。
本記事では、開発前の課題、提案したアプローチ、実装した主な機能、そして開発で苦労した点を整理してご紹介します。
今回のポイントは、生成AIが作った”それらしい旅程”を鵜呑みにせず、実在する施設か・実際に移動できる時間かを地図サービスで裏取りし、本当に回れる旅程に仕上げたことです。
開発前の課題
訪日旅行の計画づくりは、想像以上に大変な作業です。地名を見ても位置関係がわからず、都市間の移動にどれくらいかかるのかも見当がつかない。言語の壁もあり、現地の情報にはたどり着きにくい。結果として、ブログや口コミサイトを何十件も見比べた末に、誰もが知っている有名観光地だけを並べた計画になってしまう——これが旅行者側の実情でした。
一方、旅行会社にオーダーメイドで依頼すれば解決しますが、担当者が一件ずつヒアリングして旅程を組む以上、費用は高くなります。一人ひとりに合わせた旅程を、人手をかけずに作れないかというのが、事業側の出発点でした。
ここで「生成AIに聞けば済むのでは」という発想が出てきますが、実際に試すとそう単純ではありません。もっともらしい旅程は返ってくるものの、実在しない店の名前が混ざっていたり、電車で片道3時間かかる2都市を同じ日に詰め込んでいたりします。旅程表に必要なのは”それらしさ”ではなく、実際にその通りに動けることです。ここをどう埋めるかが最大の論点でした。
さらに事業としては、有名観光地だけを紹介するサービスにはしたくない、という要望もありました。地域の魅力的なお店や体験は、そもそも検索で見つけてもらえないという課題があるためです。
ご提案・開発アプローチ
まず、旅行者へのヒアリングを段階的な質問形式にしました。訪問したい都市と滞在日数、同行者、興味のあるジャンル、食事の好みなどを、一問ずつ答えてもらいます。会員登録をしなくても計画を始められるようにし、入口のハードルを下げつつ、途中で離脱しても続きから再開できる形にしています。
そのうえで、生成AIには「旅程の骨組みを考える」役割だけを担わせるという役割分担にしました。提案された施設が実在するか、どこにあるか、といった事実確認は地図サービスのAPI側で行います。AIの得意な部分と、機械的に確かめるべき部分を切り分ける、という考え方です。
移動時間も、AIの推測ではなく地図サービスで実際に算出しました。あわせて、施設の種類ごとの標準的な滞在時間と、距離に応じた移動手段の自動判定（近ければ徒歩、遠ければ電車や飛行機）を組み合わせ、1日の時間割として無理のない形に組み直す処理を独自に実装しています。
さらに、運営側が登録した地域のスポット情報を、旅程上の場所の近くから距離順に拾って提案する仕組みを用意しました。有名観光地を軸にしながら、その近くにある地域のお店へ自然に送客できる形です。完成した旅程はPDFとして持ち歩けるようにし、実際の予約はチャットで相談したうえで代行を依頼できるようにしました。
実装した主な機能
- 段階的なヒアリング（訪問都市・滞在日数・往復便情報・同行者・興味ジャンル・食事の好み・宿泊の希望）
- ヒアリング結果をもとにした、宿泊施設・レストラン・観光スポットの提案と選択
- 日別の旅程表の自動生成（訪問時刻・滞在時間・移動手段・移動時間つき）
- 生成中の待機画面と、内容が気に入らない場合の旅程の作り直し
- 地図サービス連携による施設情報の取得、ルート・移動時間の算出
- 旅程上の場所の周辺にある、地域のスポット・お店の提案
- 旅程表のPDF出力と、過去に作成した旅程の履歴管理
- 会員登録・メール認証と、未登録のままでも計画を進められる仕組み
- 宿泊・レストランの予約代行リクエストと、運営者とのチャット相談
- 予約代行手数料のオンライン決済（複数の決済手段に対応）と決済履歴の管理
- 運営者向けの宿泊施設・レストラン・観光地・イベント・掲載画像の管理
- 運営者向けのユーザー管理・問い合わせ対応・予約代行の進捗管理
- 訪日観光客向けの英語表示対応
開発で苦労した点
AIの答えを、そのまま信じない仕組みをつくる
本案件の核心は、ここに尽きます。生成AIは非常に自然な旅程を返してきますが、その中身が事実かどうかは保証されません。実在しない店名が混ざることもあれば、すでに閉店している施設が出てくることもあります。旅行者は現地でその通りに動くわけですから、これは致命的です。
そこで、AIが挙げた施設は必ず地図サービス側で検索し、実在が確認できたものだけを旅程に採用する流れにしました。時間の面でも同様で、AIが書いた「所要30分」をそのまま使うのではなく、実際の2地点間のルートから移動時間を算出し、そこに施設ごとの滞在時間を積み上げて時刻を計算し直すようにしています。徒歩で行ける距離なのか、電車が必要なのか、そもそも飛行機の距離なのかも、実距離から自動で判定します。
AIには発想を任せ、事実と計算は別の仕組みで裏取りする。この役割分担が、実用に耐える旅程表と、単なる”それっぽい文章”との分かれ目でした。
AIの回答が「途中で切れる」ことへの対処
これは実際に作ってみて直面した、生成AI連携ならではの問題です。旅程表は、日数が増えるほど出力データが長くなります。ところがAIには一度に返せる分量の上限があるため、長い旅程になると回答が文の途中でぶつ切りになることがあります。データとして中途半端な状態で返ってくるため、そのままでは画面に表示できません。
対策として、途中で切れたことを検知したらそこまでの内容をAIに渡して続きだけを生成させ、後から結合する仕組みを実装しました。さらに、それでも整合しない場合に備え、最後まで完全な形になっている部分までデータを巻き戻して復元する処理も用意しています。AI連携は「うまくいかない場合が普通にある」という前提で組む——これは今回とりわけ強く実感した部分です。
また、旅程の生成には相応の時間がかかります。無言で待たせると離脱につながるため、生成中は進捗のわかる待機画面を挟み、結果に納得できなければ作り直せる導線も用意しました。
有名観光地だけで終わらせない
AIも地図サービスも、放っておくと知名度の高い場所ばかりを提案します。これでは「どこかで見た旅程」にしかならず、地域のお店に人を送るという事業の狙いからも外れてしまいます。
そこで、運営側が登録した地域のスポット情報を、旅程上の各地点の位置から距離を計算して紐づける仕組みを作りました。同じ都道府県内のものを優先し、件数が足りなければ近隣の県から補う。都道府県の広さによって探す範囲を変える、といった調整も加えています。「有名観光地の近くにある、知られていない場所」を旅程の流れの中で自然に提示できるようにしたことで、旅行者の体験としても、地域への送客という意味でも価値のある形になりました。
まとめ
訪日観光客向けAI旅程作成サービスの開発事例では、生成AIの提案を地図サービスで裏取りし、実在する場所と現実的な移動時間に基づいた「実際に回れる旅程」に仕上げたことがポイントです。
生成AIを組み込んだ開発では、AIに任せる範囲と、任せてはいけない範囲を見極めることが成否を分けます。発想やまとめ方はAIが得意でも、事実の確認や数値の計算は別の仕組みで担保する必要がある。加えて、回答が途中で切れる、期待した形式で返ってこないといった事態は日常的に起こるため、そこまで含めて設計することを重視しました。
同様に、生成AIを活用したサービスや、外部APIと連携するWebサービスの開発をご検討の際は、お気軽にご相談ください。
