チャットベースで宿探しをサポートするリリースしました

はじめに

一休.com は宿泊施設の予約サービスを展開しています。
この度、旅行における宿探しをサポートするチャットベースの「AIコンシェルジュ」を限定リリースしました。
この記事では裏側のシステムや現在の使用状況について紹介します。

AIコンシェルジュって？

主に二つの機能からなっています。

宿泊施設の検索・提案

現在約10%程のユーザーの画面上にAIの吹き出しアイコンを設置し、押したときにチャットのUIが開くようにしています。
開いたときの画面では、まっさらな画面で「質問する」テキストエリアだけがあるとハードルが高いので、入力例としてパーソナライズされた質問を提示し、それを押すことでもぴったりな宿が提案されるようになっています。
もちろん自由入力で宿を探すことも可能です。
待ち時間もある程度（10秒~15秒）あるので、旅のtipsを出すことで時間を感じさせない工夫もしています。

チャットアイコン	開いたときの画面

詳細情報の案内

実際に宿泊施設のページ行った際に、その施設についての質問も自由にできるようになっています。
施設についてユーザーが興味のありそうな質問がフッターに並べられており、それらをクリックすることでチャットのUIを開くことができます。
また、上にスワイプすることでも開くようになっています。

フッターの質問	開いたときの画面

汎用LLMとの関わり

ChatGPTを無料ユーザーとして使うなどでも、同じように宿を探すことは可能です。
それでもあえてチャットベースの機能を置いたのはそれ以上の価値をユーザーに提供できると考えたからです。
汎用LLMではリアルタイムな情報、たとえば宿泊料金や空室状況といった「鮮度の高い情報」は取得できませんが、従来の在庫取得APIとLLMを組み合わせることでそれを実現することができます。
また、一休がもつユーザの過去の予約情報を分析して、それに合わせた宿の提案や、興味のある文面を組み立てることも可能です。
例えば「蟹アレルギーがあるので食事内容を変えてほしい」と過去に伝えていたとすればそれを情報として組み込むことで、「ただし、このプランの夕食には蟹が含まれています」などの注意文言をだすなど、宿の紹介文にも反映されるはずです。（現状はできませんが、パーソナライズの強化という観点で今後やりたいと考えています。）

ただし、汎用LLMをユーザーの一休.com流入チャネルとしても活用しておくのは意味があると考えています。
2025年10月にOpenAIが発表した Apps in ChatGPT はこちらが実装したMCP+UIをChatGPT内で実現できるものとなっており、一休の価値を織り込んだ状態で宿をLLM上で探すという体験が現実味を帯びてきました。

サイト内に設置したAIコンシェルジュとの関係で二重投資に見えるかもしれませんが

• サイト内チャットは自社UIでの予約体験を最大化する
• Apps in ChatGPTはユーザーの生活導線の中に入り込む

ことを目的として両軸で進めていこうとしています。

開発の裏側

システム構成

AIコンシェルジュでは、LLMでのチャットによく使われる ReAct型 を採用しています。
LLM側が必要に応じてtool呼び出しを行い、その結果をもとにさらにtoolを呼び出すか、ユーザー向けの文章を生成するフローを推論をしながら行うフレームワークです。
チャットの構築には Langchain + Langgraph を使っており、Openai, Google, Claudeなど各種モデルを簡単に比較検討することができます。

llm = ChatOpenAI(
    model="gpt-5.1",
    temperature=0,
    model_kwargs={"response_format": {"type": "json_object"}},
    callbacks=None,
    reasoning = {
        "effort": "none"
    }
)

response = await llm.ainvoke(
    [SystemMessage(content=system_prompt)] + state.messages
)
result = json.loads(response.content[0]["text"])

特にLanggraphはチャットの構築に適しており、チャットを開始させるタイミングやtoolの呼び出し時など、好きなタイミングでデータを出し入れ可能なstateという概念があることで自由度が相当高まります。

ただ、実際は...

gpt-5.1の推論ありはかなり遅いです。あらゆるユーザーのクエリに対して一つのReActフレームワークで対応しようとすると、宿泊施設をリストアップするクエリ（例えば「来週金曜に名古屋で一人２万円以内のビジネスホテル探して」）などで60秒以上かかることもあり実用的ではないといったこともしばしば起きました。
ちなみに、60秒は最初に文字が出始めるまでの秒数であり、出終わるのを計測するとさらに+10秒かかります。
AIコンシェルジュは、非同期で探して情報をまとめるManusのような立ち位置というよりは、もう少しカジュアルな使われ方を想定しているため、最終的に文字が出始めるのを10秒程度に収めたいという話になりました。

OpenAIに限定していますが、実際はClaude Sonnetやgeminiも試しており、20個程度の想定した宿泊施設リストアップクエリに対して、以下のような計測をしています。（数字は平均秒数）

モデル	文章生成開始(秒)	文章生成完了(秒)
gpt-5	65	79
sonnet 4.5	32	59
gemini 2.5 pro	40	44

sonnet 4.5ですら遅いです。ボトルネックをつぶさに見ていくと、「tool呼び出すべきかの推論」とそもそも推論の出始めがかなり遅いことが分かりました。そこで、ユーザーのクエリをまずはタイプに分類する過程を入れ、それぞれ以下のようにモデル・ワークフローを変えることにしました。

• 宿の詳細を聞くクエリ: 従来のReAct型
• 宿のリストアップクエリ: 推論なしのウォーターフォール型ワークフロー

推論なしのウォーターフォール型ワークフロー

宿泊施設のリストアップは初めのリストアップさえできれば、後のステップはそこまで難しくありません。

1. ユーザーのクエリに適した宿泊施設名のリストアップ
2. 宿泊施設名からIDの抽出
3. IDから在庫、料金、売上情報の抽出
4. 前のステップを元に文章の生成

手順が割と定まっていますが、これをそれぞれtoolを与えることで実現しようとしていました。宿名が分かったら次はIDが必要なのは自明なのにわざわざLLMで推論していました。システムプロンプトに長々と説明を書いて、禁止事項を書いて……最終的に数千文字になっていました。

そこで、単純に「ユーザーのクエリに適した宿泊施設名のリストアップ」をシンプルにLLMに行わせ、その配列をパースしてIDの抽出を行うといったように思考の余地が介在しないワークフローに切り替えました。

その結果、最終的に以下のように現実的なラインまで速度を向上させることが出来ました。

モデル	文章生成開始(秒)	文章生成完了(秒)
gpt-5	14	29
sonnet 4.5	15	30

しかし、これはこれでデメリットもあります。細かい条件の精度が悪化してしまうのです。推論モデルだと、一度出たリストを自己検証してクエリに適合しないと除外する等改善していくのですが、そのステップが抜けているからです。とはいえ、そこまで大外しすることもあまりないので許容範囲かとは思っています。

ユーザー行動ログを分析しながら改善した点

実際に限定リリースした後の話です。
宿泊施設ページではあらかじめ質問をフッターに並べているのですが、一部のユーザーが同じ質問を何度も押していることが分かりました。実は並べている質問はすでに事前に回答を生成しており、それを表示するだけなのですが、チャットのUIにおいて、一瞬で文章が出てくるとそれが出てきたと認識できずに同じ質問を押してしまうことが分かりました。
あえて1秒ウェイトした後、順次文字を表示するようにすると、そのような現象は見られなくなりました。
ウェブアプリケーションにおいて速いに越したことはないと思っていたのですが、遅くする方がいいこともあるのは面白い気付きでした。

本当は調べてない

使用状況

実際にチャットがどのように使われたかを分析するにあたって、具体的な会話履歴は langsmith を使用し、各種ボタンのクリックについてはログをDBに格納することで計測しています。
また、ユーザー選定については、よく一休.comを訪問してくれている人を母集団として過去の予約金額ベースで３つのグループにわけ、それぞれ均等な人数になるようにしたうえでABテストを実施しました。

チャットを開く経路としては３通りあり、それぞれのユーザーの割合は以下のようになりました。（計測期間はリリース後１週間）

• 宿ページで上にスワイプする: 9.10%
• トップ、リストページでAIアイコンをタップする: 1.14%
• 宿ページのフッターに並んでいる質問をタップする: 3.47%

ただ、実際にテキストを入力して何か情報を得たユーザーの率は0.41%にとどまり、思ったよりかなり少ない水準でした。スワイプ後、特に何も入力せずに離脱したか、質問をタップ後出てきた内容で十分だった可能性があります。

宿泊施設を探すことを主軸に置いて開発しましたが、宿を探すためにテキストを入力することはあまりなく、実際はある程度施設を絞ったうえで気になる質問をクリックしているユーザーが多数を占めているということが分かりました。徐々に各指標を上げていければと思っています。

今後の展望

現在は限定リリースのため、直近の展望としては全ユーザーに公開することを目指しています。
また、機能としては

• 前述のとおりよりパーソナライズを強化することで「専属」コンシェルジュ感を高める
  • ユーザーの過去の詳細な予約行動も取得
  • あらかじめ用意した施設への質問のパーソナライズ
• 従来のリストページとのインタラクション
• 速度向上

など、より便利に使いやすくなるようにしていく予定です。

採用

上記のようにLLMをどんどん活用して深く携わりたいという方はこちらから応募お願いします、お話ししましょう！

エンジニア採用はこちら↓