旅行業界のAIカスタマーサービス:自動化すべきこととそうでないこと
Alicia Kirana Utomo
Katelin Teen
最終更新 June 18, 2026

まとめ
私はeeselでAIエージェントを開発しており、実際のサポートキューに対してエージェントを動かす様子を観察することに多くの時間を費やしています(顧客に届く前の段階で)。旅行のキューには独自の特性があります。普段は静かで平穏ですが、嵐が数百便のフライトを欠航させると、1時間以内に同じ質問が400件届きます。目標は「すべてに回答する」ことではなく、その予測可能な急増を吸収しながら、その中に潜む重要度の高いケースを見落とさないことです。
実際に機能するのは、実際のチケット履歴とドキュメントから学習し、文書化された繰り返しのティア1問題(手荷物ルール、キャンセルポリシー、払い戻し状況、「予約確認の再送」)を解決し、深夜3時でも旅行者の言語で回答し、乗り継ぎ再予約や安全上の問題を推測せず人間に引き渡すエージェントです。価値を得るチームは信頼度ベースのルーティングを備えたツールを選び、まず古いチケットに対してテストを行います。eeselが顧客の初月にティア1リクエストの73%を解決するのを見てきましたし、過剰に積極的なボットが静かに払い戻しポリシーを作り出す場面も見てきました。だからこそ、リリース前のテストは必須なのです。

旅行サポートが他と異なる理由
どのサポートチームも自分たちのキューが特殊だと思っています。旅行チームにはその主張を裏付ける根拠があります。この仕事が安定したSaaSのインボックスや小売の返品デスクと異なる理由が3つあります。
まず、ボリュームが他に類を見ないほど急増します。ほとんどのキューは徐々に増加します。旅行のキューは天気が変わっただけで午後中に10倍になることがあります。吹雪、航空管制ストライキ、火山噴火、航空会社のITシステム障害が起きると、突然すべてのインボックスに同じ3つの質問が溢れます。「フライトはキャンセルになりましたか」「再予約できますか」「払い戻しはどこですか」。これは採用で解決できる人員問題ではありません。新入社員が訓練を終える頃には急増はもう終わっているからです。

第二に、旅行はデフォルトで多言語です。どこからでも旅行者があなたから購入できるため、インボックスには十数の言語が、あらゆる時間帯に、あらゆるタイムゾーンから届きます。小売ブランドは通常1〜2つの市場に絞れます。旅行ではそれができず、「英語対応のみ、営業時間内」というのは、顧客が別の国で旅の途中にいる瞬間にバックログが積み上がることを保証するようなものです。
第三に、重要度が二極化しています。旅行チケットの大きな部分は退屈なほど繰り返しで、完全に文書化されています(「手荷物の許容量は?」「チェックインはどうすれば?」「予約の名前変更はできますか?」)。残りは時間的に重要で、結果が重大です:深夜の乗り継ぎミス、海外での医療問題、5桁のグループ予約の払い戻し。前者を誤るのは迷惑です。後者を誤ると顧客を永久に失い、同日にTrustpilotに反映されます。これが旅行におけるAIカスタマーサービスが、単に速いだけでなく、どのチケットに触れるかについて正確でなければならない理由です。
「AIカスタマーサービス」が実際に意味すること
このフレーズは、定型返信マクロから完全自律エージェントまでをカバーしているため、旅行において重要な3つの役割について具体的に説明します。
- 対応と解決。 エージェントは確信を持っている質問について、エンドツーエンドで顧客に直接回答するため、チケットが人間に届くことはありません。これがチケット削減の数字の源であり、旅行においては急増の大部分を占める文書化されたポリシー質問がこれに当たります。
- コパイロット下書き。 それ以外のすべてについて、エージェントが提案する返信を下書きし、人間のエージェントがレビューして送信します。最も安全な出発点であり、私たちが協力する旅行チームのほとんどが最初のピークシーズンにここから始めます。
- トリアージとルーティング。 誰かがチケットに触れる前に、AIがタグ付け、優先度設定、ルーティングを行います。旅行においては、「3時間後に出発予定のフライトがキャンセルになりました」というチケットが、「シニア割引はありますか」というチケットより優先されます。サポートチケットのトリアージを見たことがなければ、最も取り組みやすいところから始めてみてください。
この3つを結びつけているのが知識ソースです。旅行エージェントは何から学んだかによって価値が決まり、優れたものはヘルプセンターの記事だけでなく、解決済みチケットから学ぶAIナレッジベースチャットボットとして機能します。この違いはどの機能チェックリストよりも重要です。ヘルプセンターはAIに書き留めたことを教える一方、過去のチケットはチームが金曜の夜に乗り継ぎミスを実際にどのように処理するかを教えるからです。
自動化すべきことと、そうでないこと
これが旅行における全てであるため、境界線がどこにあるかについて率直に述べる価値があります。旅行型のキューに対してエージェントを動かしてきた経験から、分け方は一貫しています。文書化されていて繰り返しのものを自動化し、時間的に重要で不可逆なものは人間が担当します。

左の列がAIが価値を生み出すところです。手荷物とチェックインのルール、キャンセル・変更ポリシー、払い戻し状況の照会、「予約確認の再送」、ロイヤルティポイントの質問、「必要な書類は何ですか」。これらの回答はすでにドキュメントまたは先週クローズしたチケットにあり、文脈によって変わらず、混乱時の急増の大部分を占めます。エージェントに任せましょう。
右の列は私が踏ん張るところです。乗り継ぎミスの再予約、海外での医療・安全上の問題、複数人の複雑なグループ変更、そして補償に関する紛争はすべて共通の特徴を持ちます:重大な結果をもたらし、しばしば不可逆で、完全には文書化されていないことが多い。AIが少し間違えた再予約を自信を持って「解決」すると、誰かが立ち往生します。それは対応効率化の成功ではなく、払い戻しが付いた解約イベントです。
ある交通予約会社のサポートリードが目標を完璧に表現していました。彼はAIにZendeskチケットの約60%をチームから引き受けてほしいが、それはいつ人間にエスカレートするかを確実に知っている場合のみだと言っていました。これが正しい直感です。目標は高い解決率ではなく、適切なチケットに対する高い解決率です。
エージェントが何に回答するかを決める方法
ここはマーケティングページが省略している部分であり、開発者として私が最も重視する部分です。
まともな旅行サポートエージェントは単にテキストを生成するだけではありません。ループを実行します:受信チケットを読み取り、知っていること(過去のチケット、ヘルプドキュメント、接続ツール、予約システム)をすべて検索し、確信度に基づいてルーティングの判断を下します。確信度が高く、トピックがスコープ内であれば回答します。確信度が低ければ引き下がり、人間向けの下書きを作成するか、きれいにエスカレートします。これが信頼度ベースのルーティングであり、私がなしでは出荷したくない唯一の機能です。

季節性ECブランドのCXリードが言ったことが頭から離れません。彼女はAIが100%の質問に回答することはないと言い、そうしてほしくもないと言っていました。彼女が必要としていたのは、確信を持っているチケットのみを処理し、残りはそのままにするエージェントでした。なぜなら、何千もの回答を遡って監査して悪いものを見つけることはできないからです。旅行ではこれが二重に当てはまります:AIが間違えるかもしれない5%は、不釣り合いに再予約と払い戻しが多く、最も失敗できないチケットです。
リリース前にリスクを軽減する方法はシミュレーションです:エージェントを過去数千件の実際のチケットに対して実行し、トピック別に何と言ったかを、顧客が見る前に読みます。ギャップを見つけ、補完し、再実行します。誤った返信が旅行者を立ち往生させる場合、「信頼してください、正確です」は受け入れられる回答ではないため、eeselにシミュレーションを組み込みました。シミュレーションが確実であることを示したカテゴリのみで本稼働し、それ以外はすべて自律性を獲得するまで人間レビュー待ちの下書きとして残します。
多言語と24時間対応、旅行が省けない部分
ほとんどの業界では多言語サポートはあれば良いものです。旅行においては本質的な要件です。顧客は定義上、故郷ではない場所にいて、あなたのタイムゾーンではなく、夜間シフトが話せない言語でタイプしていることが多いです。英語のみで営業時間内にしか機能しないエージェントは、本当の意味での旅行サポートエージェントとは言えません。

これはAIが最も得意とすることの一つであり、過小評価されています。eeselは標準で80以上の言語に対応しており、より重要なのは多言語チケット履歴から学習するため、すべてをぎこちない機械翻訳レイヤーに通すのではなく、各言語でチームが実際に回答する方法で回答します。ドイツのジュエリーECブランドとのあるトライアルでは、言語ごとに促すことなく、エージェントがドイツ語、英語、フランス語、オランダ語、スペイン語、ポーランド語、クロアチア語、トルコ語のチケットを処理しました。私たちの大規模な導入事例の一つであるsmavaは、月間10万件以上のドイツ語チケットを処理する完全自動化されたZendeskエージェントを稼働させています。重要なのは言語数ではなく、シフト中にその言語を話すエージェントがいない深夜3時の質問でも、正しい回答がすぐに得られるということです。
その24時間対応がもう一方の柱です。ゲートで立ち往生している旅行者は、サポートチームが午後6時にログオフしたことを気にしません。文書化された質問はいつの時間帯でも即座に回答され、本当に複雑なものはキューに入れられ、トリアージされ、最初にログインした人間のための下書きと一緒に待機します。
実際の成果(数字)
解決率の主張には注意が必要です。簡単に水増しできるからです。そのため、文脈が付いた実際の顧客からの数字を示します。
Gridwiseは、ZendeskでZendesk上で稼働しているギグエコノミーのドライバー分析アプリで、結果が速く出たため最もよく引用します:
「初月に、eeselはティア1リクエストの73%を解決しています...チームは7日間のトライアル期間中に実装して迅速に結果を出しました。返信の修正と調整が簡単です。」
Kim Simpson、Gridwise
他にも知っておく価値のある事例があります:Global Paymentsはドキュメント全体で回答を見つける際に最大80%の時間節約を報告し、InDebtedはeeselをJiraチケットの最初の対応者として運用しています。業界は異なれど、旅行チームが参考にすべき同じパターンがあります:文書化された大多数を自動化し、残りは人間が担当し、シミュレーションが安全であることを証明する速度でのみ初回解決率を上げていく。

単一顧客の逸話ではなく、より広範なベンチマーク計算が必要な場合は、AIが節約できる金額の分析でチケット当たりのコストモデルを詳しく説明しています。
購入前にチェックすべきこと
5つだけチェックするとしたら、これらをチェックしてください。実際の旅行ピークを乗り越えられるAIヘルプデスクと、3週目にスイッチを切られるものを区別するものです。
| チェック項目 | 旅行における重要性 | 危険信号 |
|---|---|---|
| 信頼度ベースのルーティング | 確信のない再予約や払い戻しは推測ではなくスキップしなければならない | 「すべてに回答します」 |
| 過去のチケットで学習 | ドキュメントだけでは混乱時のチームの対応方法を見落とす | ヘルプセンターのみの取り込み |
| 標準で多言語対応 | 旅行者はあらゆる時間帯にあらゆる言語で来る | 英語のみ、または後付け翻訳 |
| リリース前のシミュレーション | ピーク前に実際のチケットで何と言うか確認する | 「そのままオンにするだけ」 |
| 既存のヘルプデスクに適合 | ハイシーズン前にプラットフォームを移行するべきではない | プラットフォームの強制移行 |
最後の行は思われているより重要です。ヘルプデスクはチームがすでに使っているところですから、AIはそれを置き換えるのではなく、上に重なるように機能すべきです。eeselはZendesk、Freshdesk、Gorgias、HubSpot、Salesforce Service Cloudを含む100以上のインテグレーションに接続できるため、スタックをそのまま保ちながらエージェントを追加できます。(上記のヘルプデスクと統合しているため、私たちの意見はその点を踏まえて判断してください。また、試すだけであれば無料オプションから始めるのも良い方法です。)
セキュリティについて、旅行の購買担当者には通常、実際の調達ゲートがあります。GDPRとEUデータ居住要件は一般的であり、チケットに支払いデータが含まれる場合はPCIが重要になります。これはよくある後期段階での成約阻害要因となるため、早めに確認してください。
自社開発か購入か?
多くの旅行テックチームはLLM APIを自分で組み込む能力を持っており、議論は通常「自分たちで作れるんじゃないか」というSlackスレッドから始まります。作れます。問題は、それを永遠に維持したいかどうかです。
プロトタイプを作るのは週末の作業です。実際の旅行者に対して安全にするための部分、確信度ルーティング、ヘルプデスク同期、シミュレーション、多言語知識の取り込み、そして運賃規則やポリシーが変わるたびに維持することは、継続的なエンジニアリングのコミットメントです。300以上の記事からなる知識ベースを持つ暗号ハードウェア企業GENERAL BYTESの顧客が購入を選んだ理由をまとめています:
「独自のLLMアプリケーションを作ろうとすることはできますが、その時間を投資したくありませんでした。メンテナンスが不要なものが欲しかったのです。」
Karel、GENERAL BYTES
こう表現します:AIサポートがあなたの製品であれば自作してください。あなたの製品が人をAからBへ運ぶことであり、サポートがすべてのピークを通じてスリムに運営したいコストセンターであれば購入してください。ほとんどの旅行チームには後者が当てはまり、エンジニアの時間と終わりのないメンテナンスを価格に入れると自作vs購入のコストは購入に有利に働きます。
費用
料金は旅行チームが痛い目に遭うところです。課金単位が多くの静かな仕事をしているからです。座席単位の料金体系はハイシーズン前の人員増強でコストが膨らみます。解決件数単位の料金体系は、嵐でボリュームが3倍になる月に請求書が恐ろしいことになります。eeselはフラットな使用量ベースの料金体系で動いており、旅行のボリュームが実際にどのように振る舞うかに綺麗にマッピングされる傾向があります。
| プラン | 料金 | 内容 |
|---|---|---|
| 無料トライアル | $50分の無料利用、カード不要 | 実際のチケットでお試し |
| 使用量ベース(PAYG) | チケット/会話1件あたり$0.40〜 | 座席ごとの費用なし、プラットフォーム費用なし、最低利用額なし |
| 年間コミット | 25%オフ(年間$300/月以上のコミット) | 同じ機能、低い料金 |
| エンタープライズ | プラットフォーム費用$1,000/月+使用量 | SSO、HIPAA/BAA、より高いKBの上限、専任SE |
旅行向けに特に強調したい点:ダッシュボード参照などの「軽い」タスクは無料、通常のチケットまたはチャットは$0.40で、請求額はサポートの作業量に応じてスケールし、雇用した季節スタッフの数には依存しません。つまり、静かな月はコストが低く、嵐の月はコストが高くなり、ピーク時の人員を年間通じて支払い続けることはありません。完全な内訳は料金ページにあり、コスト削減ガイドには異なるボリュームでの計算例が載っています。
旅行サポートにeeselを試してみる
eeselはまさにこのようなキュー向けに構築されたAIヘルプデスクエージェントです:過去のチケットとドキュメントから学習し、24時間365日80以上の言語で回答し、本稼働前に実際の履歴に対してシミュレーションを実行し、信頼度ベースのルーティングを使用して確信を持っているものにのみ回答し、再予約や紛争は人間にきれいに引き渡します。すでに使っているヘルプデスクの上で動作し、座席単位ではなく使用量で課金されるため、ピークを通じた人員増強でコストが膨らみません。自分のチケットに対して何と回答するか見たい場合、7日間トライアルは実際の履歴に対して実行されます。

よくある質問
旅行業界のAIカスタマーサービスとは何ですか?
旅行業界のAIカスタマーサービスの費用はどのくらいですか?
AIは多言語の旅行サポートに対応できますか?
嵐でフライトが欠航になるような混乱時のスパイクにAIはどう対処しますか?
AIが旅行者に誤った回答をしないようにするにはどうすればよいですか?

Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.








