移動支援AI自動化の現在地——電話番号の前に、声で確かめる

出典: note.com / 2026-05-23

地域の移動支援では、予約の電話が静かに人を削る。利用者は「いつ、どこから、どこへ」を伝えるだけのつもりでも、受ける側は聞き直し、記録し、重複を避け、運転手の都合を見て、必要なら折り返す。小さな作業に見えて、失敗できない作業だ。

このプロジェクトでは、その受付をAIで自動化している。対象はN市のT自治協が運営する移動支援。これまでK氏が人力で担ってきた電話受付を、いきなり置き換えるのではなく、現行運用を残したまま、別系統で検証している。

今回の進捗は派手ではない。むしろ重要なのは、派手な近道を一つ捨てたことだ。電話番号の審査と接続を急がず、まずブラウザ越しの音声会話で、予約受付そのものが成立するかを確かめる方針に切り替えた。

旧系統を壊さないための二重化

現行の運用はそのまま残す。K氏が使っている入力経路、確認手順、運転手側の見え方には触らない。ここを壊すと、技術検証ではなく業務事故になる。

新しい系統は、AI音声エージェント、Webhook、予約解析、専用データベース、管理画面で閉じる構成にした。利用者の発話をAIが受け、会話の終了後に必要項目を抽出し、予約候補として保存する。管理画面では、確定、却下、要確認の状態を人間が見られる。

旧系統は日々の運用を守るための線。新系統は、自動化が本当に使えるかを測るための線。この二本を混ぜないことが、今回の設計で最も大事な判断だった。

当初は、電話番号を取得し、AI電話基盤に接続し、実際の着信で試す順番を想定していた。ところが国内番号の利用には本人確認と規制対応があり、書類提出、審査、番号への紐付けが必要になる。手続きそのものが重い。

重い手続きを先に進めても、肝心の会話品質が実用に届かなければ意味がない。予約日時を聞き落とす。出発地と目的地を取り違える。すでにある予約と重複する。そうした基本部分が崩れるなら、番号の苦労は全部前倒しの無駄になる。

そこで順番を入れ替えた。電話番号ではなく、Web音声で先に話す。ブラウザの通話ボタンからAIに接続し、人間が実際に予約の会話をする。その結果が専用テーブルに保存され、管理画面で確認できるかを見る。

新系統の土台はすでに動いている。予約取り込みAPIは、会話ログを受け取り、AI解析を通して、予約候補を保存する。30分以内の近い予約を重複候補として扱うルールも入っている。

管理画面では、保存された予約を一覧できる。状態変更もできる。統計とシステム状態も見られる。電話番号を使わないチャットテストもあり、AIの応答方針を確認できる。

音声側では、V社のWeb SDKを使い、ブラウザからAIアシスタントと会話する方針にした。ここで見るべきものは、単なる音声認識の精度ではない。利用者が自然に話したとき、必要な情報を聞き返せるか。曖昧な日時を確認できるか。予約として保存できる粒度まで会話を畳めるか。そこが本丸だ。

AIが流暢に話すだけなら、もう珍しくない。移動支援で必要なのは、会話が終わったあとに、人間が扱える予約データが残ることだ。

名前、連絡先、希望日時、出発地、目的地、利用目的、補足事項。これらが欠けると、結局K氏が聞き直すことになる。聞き直しが増えれば、自動化は現場の負担を減らすどころか、新しい確認作業を生む。

だからテストでは、AIの返答が気持ちよかったかではなく、保存された予約が実務に耐えるかを見る。間違いがあれば、プロンプト、解析ルール、確認質問の順番を直す。電話番号の接続は、その後でいい。

次の作業は明確だ。Web音声の簡易ページを作り、ボタン一つでAIアシスタントに接続する。そこで予約会話を行い、保存結果を管理画面で確認する。成立した予約、欠落した項目、聞き返しが必要だった箇所を見て、会話設計を直す。

この段階で旧系統には触らない。外部の表計算連携も、既存ダッシュボードも、現場の入力導線もそのままにする。新系統だけで検証し、使えると判断できた時点で、はじめて電話番号の審査と接続に戻る。

自動化で一番危ないのは、動いたように見えるものを現場に入れることだ。今回は逆に進める。現場を守る線を残し、AIの線を横に引き、声のテストで予約成立を確認してから、電話へ進む。

小さな方針転換だが、これは逃げではない。実用に近づくための順番の修正である。

この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/n2d509c79837a