「AIで完結」ではなく「人との協働」にこだわる。JTBとカラクリが挑んだ、災害時カスタマーサポートの"最難関局面" 

台風や地震など、交通インフラが乱れる「異常時」。旅行業界のカスタマーサポート（CS）には、振替やキャンセルを求めるお客様からの問い合わせが集中します。増員だけでは追いつかず、回答を待つお客様がどんどん増えていく ——。この"最難関局面"に、株式会社JTBのデータインテリジェンスチームとカラクリ株式会社が共同で挑みました。

舞台となったのは、経済産業省・NEDOによる懸賞金型プログラム「GENIAC-PRIZE」。国産基盤モデルを活用した社会課題解決AIエージェントの開発を促すこの取り組みの「カスタマーサポートの生産性向上」テーマに、両社は「問合せ返信対応AIエージェント」のPoC（概念実証）に共同で取り組み、これを成功させました。

「AIですべてを完結させる」のではなく、「人が最後に確認する協働ワークフロー」をあえて設計の中心に据えたこのプロジェクト。その背景と舞台裏を、JTB データインテリジェンスチームのみなさまに伺いました。

「異常時でも、お客様を待たせない」——旅行業CSが抱える構造的な課題

旅行業界のカスタマーサポートが直面する難しさは、需要の「瞬間集中」と「早期対応の必要性」が同時に押し寄せる点にあります。

台風で列車が運休し、航空便が欠航する 。そのとき、お客様が知りたいのは「自分の予約はどうなるのか」「取消料はかかるのか」という、一刻も早い回答です。一方で現場の担当者は、刻々と変化する運休・欠航情報を確認し、複数の業務システムを横断しながら、取消料の免除対象かどうかを正確に判断しなければなりません。

問い合わせは急増するのに、増員はすぐには追いつかない。さまざまな情報を確認する分、お客様への回答も通常より時間がかかり、お客様をお待たせしてしまう——。JTBが「最難関局面」と位置づけるこの状況をどう乗り越えるか。求められていたのは、「異常時でも、正確で、かつ滞留を作らないCSの設計」でした。

きっかけは「課題ドリブン」だったこと

JTB データインテリジェンスチームは、グループ全体のDXを推進するために2023年に発足した組織です。それ以前はデータ基盤やアルゴリズム開発を外部に委託することが中心でしたが、近年は「中身を自分たちで作る」内製開発へと舵を切ってきました。今回のプロジェクトは、その完全内製化を本格的に進めるなかでの挑戦のひとつでもありました。

両社が出会ったのは、GENIAC-PRIZE関連のマッチングイベント。当初から「一緒に組むぞ」と決めていたわけではなかったといいます。

「色々な会社さんの話を聞いていて、最初から共同開発のために行ったわけではありませんでした。それでも、もともと我々の側に『なんとかしなければいけない』という業務課題があって、そこにカラクリさんの強みがぴったりはまった。やっぱりテーマが良かったんです」（大門氏）

ポイントは、このテーマが「シーズ（技術）ドリブン」ではなく「課題ドリブン」だったこと。現場が本当に困っている問題が起点にあったからこそ、話は具体化し、実現に向けて一気に動き出しました。コンタクトボードへの返信業務をめぐる課題は、もともと中島氏を中心に取り組まれていたテーマでもあり、その延長線上で「カラクリさんと一緒にできることはないか」という形でプロジェクトが立ち上がったのです。

設計思想は「適材適所」——AI × RPA × 業務ロジックAPI

開発したのは、Web予約者向けメッセージボックスの「返信対応AIエージェント」。その設計を貫くのは、「適材適所」かつ「学習不要で保守性の高い」という思想です。

「すべてをAIエージェントに任せて、もっとエージェンティックに動かす」という構想も当初はありました。しかし議論を重ねるうちに、両社は別の結論にたどり着きます。

「業務を分解していくと、自然と『ここはルールベースで書ける』『ここはAIに任せるべき』という線引きが見えてくるんです。ルールで確実に記述できることを、あえてAIでやる意味はあるのか——そう問い直していった結果、ここは無理にAIにする必要はない、という判断になりました」（合田氏）

GENIACの文脈だけを考えれば「エージェントを使いたい」という気持ちもあった、と合田氏は率直に振り返ります。それでも両社は、あくまで「JTBがやるべきことの正解を一緒に探す」というスタンスを崩しませんでした。最も成功率の高いやり方を二人三脚で模索した結果が、この「適材適所」の構成だったのです。

「最後は人が確認する」を、どこに置くか

このプロジェクトを象徴するのが、「AIで完結ではなく、人間が最終確認を行う協働ワークフロー」という設計です。

問い合わせ一覧の確認 → 返信対象の判定 → 予約情報の整理 → 取消料免除の判定 → 返信文案の生成 → 返信下書きと根拠情報の登録。ここまでをAIエージェントが担い、最後の「確認・送信」だけを人間が行う。

「AIエージェントが勝手に送信して終わり、という世界観はやはり受け入れにくい。最後は自分たちで品質を担保したい、という現場から自然に上がってきた要件でした」（中島氏）

注目すべきは、この「人の確認」をどこに置くかまで踏み込んで設計した点です。確認を業務フローの途中に挟むと、それが実行されない限り後続の作業が止まってしまう。だからこそ、効率化が働く位置——最後の送信前——に確認ポイントを置いた。「人間の関与を最初か最後に持ってくる」というエージェント活用の定石を、現場の実務感覚とすり合わせながら形にしていきました。

「払う側・もらう側」を一度、脇に置く

委託元と委託先。立場の異なる二社が一つの開発を進めるうえで、最初の壁は「役割分担」でした。JTB側にも開発チームがあるからこそ、「どこまでをどちらが担当するのか」が当初はお互いにつかみきれず、ふわふわした状態が続いたといいます。

転機は、週1回の密なコミュニケーションを始めたこと。そして、ある考え方の転換でした。

「お金を払っている側・もらっている側、という関係を一度脇に置いて、『このプロジェクトが最速で終わるには、どちらが担当するのが効率的か』だけで考えられるようになってから、一気に進むようになりました」（合田氏）

JTB側の業務に関わる部分はJTBが、AIエージェントの動作はカラクリが。境界が曖昧な領域も、立場ではなく「効率」で柔軟に分担する。この割り切りが、プロジェクトを加速させました。

開発を大きく前進させたもう一つの要因が、JTBが用意した基幹システムのダミーアプリです。顧客情報を扱う基幹システムに外部からアクセスすることは難しく、ここが開発上の最難関でした。JTBがダミー環境を構築して渡したことで、カラクリ側はエージェントの動作を作り込めるようになり、開発は一気に進みました。

「9月から11月にかけて、まずは仕様をきちんと言語化することに注力しました。そこが固まっていたので、ダミーアプリをいただいた11月以降、開発は短期間でガッと仕上がった」（カラクリ武藤）

仕様の言語化を先行させたこの進め方は、後半の開発を非常に安定したものにしました。担当者の関与が変わる局面があっても破綻せず走りきれたのは、土台となる仕様が明文化されていたからこそ、と振り返ります。

ハルシネーション「ゼロ」を支えたもの

LLMを業務に組み込むうえで避けて通れないのが、ハルシネーション（誤った情報の生成）への対策です。カラクリ側は、この課題にプロンプトの作り込みで向き合いました。

「ハルシネーション対策の核は、プロンプトを丁寧に書き込むこと。加えて、もともと業務がきちんと整理されていて、LLMに明確な指示が出せる状態が整っていたことが大前提でした」（カラクリ武藤）

さらに、 GENIAC-PRIZE 審査用のデモ動画にも細やかな配慮を施しています。ブラウザ操作は「どこをクリックしているか」が伝わりにくいため、ボタンを押した箇所に色を付けて発火させたり、画面の切り替わりをあえてゆっくりにしたり。AIの挙動を"見える化"する工夫を重ねました。

そして合田氏は、この成果の土台に「業務整理」があったと強調します。

「業務がしっかり整理されていたから、LLMに正しい指示を出せる状況が整っていた。これが大前提でした」（合田氏）

実際の検証でも、ハルシネーションは発生しませんでした。

実証：台風10号、2,648件のデータで検証

両社は、2024年8月29〜30日に発生した台風10号の問い合わせ2,648件を用いて、開発したエージェントの効果を検証しました（実オペレーションへの投入ではなく、データ上での机上検証）。結果は次のとおりです。

• 生産性：1人あたり 24件／日 → 101件／日（約4倍）

• 返信文の精度：適切な回答テンプレートの選定について 正解率 98.5%

• ハルシネーション：電話番号・URL・便名・列車名などの具体情報で評価し、1,946件中 0件（具体情報を含まない返信文は除外）

さらに、1日1,500件の問い合わせが来るピーク日を15人体制で想定したモデルケースでの試算では——

• 従来は従来は当日中に360件回答、残りは翌日以降に順次対応 → 提案手法では 当日中に全件回答

• 当日中に全件処理するコストは 76万円 → 6万円（約70万円の削減）

人手では難しい「24時間、休みなく動き続ける」ことができる点を、大門氏は効果として挙げます。

「圧倒的に、人がやるよりも速い。人なら8時間働いて休憩も必要ですが、エージェントは問答無用で24時間動かし続けられる。それに、人員を急に増やしたり減らしたりするのは難しいですが、エージェントなら機械的にスケールできる。これは実際のオペレーションを考えると、大きな意味を持つはずです」（大門氏）

「設計そのもの」を、次の課題へ

このプロジェクトで得たものは、「一つのユースケースにおけるPoCの成功」にとどまりません。合田氏が大きな価値を見いだしているのは、その設計思想の汎用性です。

「基幹システムを外から操作するエージェントと、業務ロジックを切り出したAPI。これらをうまくオーケストレーションすることで自動化が実現する——この設計の考え方自体は、かなり汎用的だと思っています。コールセンターに限らず、同じような業務は社内に色々ある。この『フレームワーク』を、今後さまざまな場面で使えたら」（合田氏）

JTBは、開発したAIエージェント 市場開拓に向けた展開も視野に入れています。まずはCS部門での導入整理（Phase 1）から始め、国内・海外事業部への社内横展開（Phase 2）、グループ各社への展開（Phase 3）、そして宿泊・旅行・他業界への外部展開（Phase 4）へ。社内で実績を固めながら、外へと広げていく構想です。

Phase 1に向けた目下の課題は、継続的な改善ループのビルドイン。オペレーターのフィードバックをFeedback APIで自動収集・分析し、プロンプトの改善や業務ロジックの更新につなげる。品質向上と業務変化に対応し続ける運用の仕組みを確立することが、実装に向けた次の一歩となります。

国産モデルだからこその「安心」

最後に、国産基盤モデルを選んだ理由について。決め手は、扱う情報の性質にありました。

「顧客情報を扱う以上、外部との連携エンドポイントは慎重にならざるを得ません。クローズドな領域で完結させる必要がある。その点で、ベースが国産であることは安心材料になりました」（大門氏）

旅行業のリーディングカンパニーとして、お客様に「安心と快適」を届け続けること。JTBデータインテリジェンスチームとカラクリの挑戦は、AIの力を"安心を届ける力"へと変えていく取り組みでもあります。