ツアーガイド業界は、AIでもっと進化できる。現場から生まれたTourWeb

01 / THE PROBLEM

予約が入るたびに、
私たちは同じ情報をもう一度入力していた。

TourWebを作る前、GetYourGuideやViatorなどのOTAから予約が入ると、運営担当者が予約メールを開き、ツアー名、催行日、開始時間、参加人数、ゲスト名などを、ツアーメンバーで共有する別の管理アプリへ手入力していました。

新規予約だけではありません。時間変更、人数変更、キャンセルなどが届くたびに、元の予約を探して更新する必要があります。予約が増えるほど入力作業に時間がかかり、確認漏れや更新漏れも起こりやすくなります。実際に弊社でも行き違いが発生し、お客様にご迷惑をおかけしたことがありました。

予約を一元管理できる既存サービスもあります。ただ、弊社が本当に困っていたのは、予約一覧を作ることだけではありませんでした。その情報を、当日ツアーを担当するガイドの行動まで落とし込めないことが問題だったのです。

そして当日、ゲストが来ないと、また情報探しが始まる。

誰が来たのか。誰がまだ来ていないのか。未到着のゲストはどの予約なのか。電話番号はどこに書かれているのか。ガイドはまず運営へ連絡し、担当者がOTAや予約メールから該当するゲストを探すまで待つ。返信で電話番号を受け取り、その番号をWhatsAppへ手入力して、ようやくゲストへ連絡する。集合時間が過ぎている中で、このやり取りを毎回行う必要がありました。予約を「管理」できても、現場の対応は別作業のままだったのです。

予約を一覧にするだけでは、現場は変わらない。
予約情報が、ガイドの次の行動につながって初めてDXになる。

02 / WHY WE BUILT IT

欲しい仕組みがないなら、現場にいる自分たちで作る。

TourWebの始まりは、壮大な事業計画ではありません。「予約が入るたびに同じ内容を転記するのはおかしい」「変更やキャンセルも自動で追えるべきだ」「ガイドが自分で参加者と連絡先を確認できた方が速い」という、ごく現場的な違和感でした。

そこで弊社は、予約を受ける側とソフトウェアを作る側を分けるのをやめました。自社で使う。問題を見つける。その日のうちに直す。次のツアーで試す。このサイクルを繰り返しています。

03 / THE PRODUCT

予約管理ではない。
当日のツアーを動かすための画面です。

TourWebでは、複数の販売経路から届く予約メールを取り込み、ツアー名、日時、人数、ゲスト、予約元などを、現場が使える「運行情報」へ整理します。管理者のためだけの一覧表ではなく、ガイドがスマートフォンで見て、その場で判断できることを優先しています。

今日、誰が、どのツアーを、何人案内するのか。

午前・午後・夜の運行、担当ガイド、参加人数、ゲスト名、予約元、来場状況、連絡導線を一つの流れで確認できます。

• 月間カレンダーと日別運行ボード
• ガイド別の担当ツアー画面
• 予約元・ゲスト名・人数・集合場所の集約
• 新規・変更・キャンセルの予約メール取込
• 同一催行を一つのツアーとしてグループ表示
• WhatsAppへのワンタップ連絡
• ゲストごとの来場・未到着状況の確認
• 重複防止・処理履歴・権限管理

04 / WHAT CHANGED

情報共有を増やしたのではない。
確認しなくていい状態を増やした。

TourWeb導入後、OTA予約を共有アプリへ一件ずつ手入力する作業を減らし、新規予約、変更、キャンセルを一つの流れで扱えるようになりました。ガイドは運営担当者へ聞く前に、自分の画面で担当ツアー、参加者、来場状況を確認できます。ゲストが集合場所に来ない場合も、そのゲストの情報からWhatsApp連絡まで進めます。

ガイドが自分で担当ツアーとゲスト情報を確認できる。運営は同じ質問へ繰り返し回答する必要がない。予約の変更も一つの画面で追える。こうした変化によって、チームは情報探しではなく、例外への対応やゲストへの案内に集中できるようになりました。

05 / AI × DX

AIを使うだけでは、観光の現場は変わらない。

弊社は、ツアー中の多言語コミュニケーションにLLMを活用し、AI同時通訳ガイドの運用にも挑戦しています。しかし、ゲストに見える部分だけをAI化しても、予約・担当・連絡・変更が分断されたままなら、会社全体の速度は上がりません。

06 / WHY US

私たちの強みは、観光を知っていることでも、コードを書けることでもない。

現場から課題を見つけ、企画し、開発し、運用し、もう一度現場で確かめる。そのサイクルを自社で回し続けられることです。

弊社では、ガイドや運営が感じた違和感を、その場限りの不満で終わらせません。何が本当の原因なのかを整理し、解くべき課題を決め、機能として企画する。自分たちで開発し、実際のツアーで使い、問題があれば改善し、また次の運行で確かめます。

長いツアー名がスマートフォンで切れる。参加者名が開くまで見えない。変更前の時刻と現在の時刻を間違えやすい。小さく見える摩擦でも、毎日繰り返せば大きな負担になります。だから弊社は、誰かの大規模な開発計画を待たず、現場を止めずに改善を積み重ねます。

TourWebは、完成して終わる製品ではない。
現場と一緒に、毎日アップデートされる運営基盤です。

07 / NEXT

次は、他社の現場で通用するかを試したい。

TourWebは現在、Amazing Tour Japanの実際の運営を支える社内プロダクトです。次に目指すのは、自社だけに最適化された便利ツールではなく、地域やツアー商品が違っても使えるサービスへ育てることです。

いきなり完成品として広く販売するのではなく、同じ課題を抱える事業者と話し、実際の運用を見せてもらい、必要な機能と導入方法を一緒に検証したいと考えています。