企業向けAI電話応答とリアルタイム配車の連携｜GoGoCha 技術事例

問題の背景

高齢者、旅行者、法人のお客様は、電話、サイト、LINEからタクシーを依頼します。窓口ごとに依頼を別管理すると、運営側は複数の画面で情報を照合する必要があります。本事例では各窓口を共通の配車バックエンドに接続し、ドライバー、乗客、運営側が同じ依頼の状態を確認できるようにし、情報不足時の有人対応も残しています。

実装方法

• —AI電話窓口は配車に必要な情報を収集し、共通バックエンドが依頼の保存と配車を担当します。会話と依頼の状態を分けることで、電話、サイト、LINEを同じ業務フローにつなぎます。
• —Express、PostgreSQL、Redis、BullMQ、および Socket.IO を使用して、即時配車バックエンドを構築する。
• —ウェブサイトでの料金シミュレーションでは、まず実際の料金 API を呼び出し、失敗した場合は、ローカルルールに基づいて明確な代替料金を表示する。
• —高齢者が利用しやすいように、大きな文字、音声優先、高コントラストなどの表示方法を採用する。

Falcon の実際の責任範囲

• ブランドウェブサイトと料金シミュレーションインターフェース
• AIによる電話対応の入力と、配車タスクのデータ構造
• SmartDispatcherV2：即時配車バックエンド
• LINE Bot、ドライバー/顧客向けアプリ、および運用管理システムとの統合

AI電話応答から配車までのデータフロー

1. 01顧客は電話、ウェブサイト、または LINE から配車を依頼する。
2. 02システムは、場所、連絡先、および配車タスクの情報を共通の配車フローに送信する。
3. 03バックエンドは PostgreSQL で状態を保存し、BullMQ でキューを処理し、Redis/Socket.IO を使用してリアルタイムで同期する。
4. 04ドライバー、顧客、および運用管理システムは、同じ配車タスクの状態を把握する。

制限、失敗、および代替手段

• —AIが場所、連絡先、依頼内容を確実に確認できない場合は、人が追加確認すべきです。モデルの推測を実行可能な配車データとして扱ってはいけません。本ページは、すべての着信を無人で処理できるとは主張していません。
• —サイトの運賃APIが失敗した場合はローカルルールによる代替見積もりを提示し、画面で算出根拠と制限を明示する必要があります。代替結果はリアルタイム運賃APIの成功、配車依頼の完了、正式見積もりの取得を意味しません。
• —キューとリアルタイム通信を分離することで、単一の接続の問題が配車タスクの消失につながるのを防ぐ。

証拠の検証方法

• ✓電話、ウェブサイト、LINE、および料金シミュレーションなどの入力は、公開ブランドウェブサイトから確認できる。
• ✓公開されているアプリ画面とウェブサイト画面は、異なる入力からの製品範囲を証明するために使用され、プライベートな顧客またはドライバーのデータは含まれない。
• ✓技術的な構造は、Falconが実際に担当する範囲に基づいています。具体的な利用量、接続率、作業時間の削減、または正式なSLAなど、公開されていない情報も含まれます。

公開可能な測定値と能力