高級自動車整備工場向けAIレセプショニストの構築記 - Part 1

 (itsthatlady.dev)
1 ポイント 投稿者 GN⁺ 2026-03-25 | 1件のコメント | WhatsAppで共有
  • 高級整備工場の電話に出られないことによる売上損失を解決するため、実際に電話応対を行う**AIレセプショニスト「Axle」**を開発
  • AIは**Retrieval-Augmented Generation(RAG)**ベースで構築され、Webサイトから収集した実際のサービス・価格情報を根拠に正確な回答を提供
  • Vapi、Deepgram、ElevenLabs、FastAPI、MongoDB Atlasなどを連携し、電話接続、音声認識・合成、会話記録保存機能を実装
  • 音声品質は自然なトーンと短い文の構成に調整され、顧客に親しみやすく、それでいてプロフェッショナルな応答を提供
  • 今後は予約システム・SMS通知・コールバックダッシュボードへ拡張予定で、業務特化型の音声エージェントでは知識ベースとエスカレーション設計が重要

AIレセプショニスト構築プロセス

  • 高級自動車整備工場を運営する兄が電話に出られないことで毎月数千ドルの損失を被っていた問題を解決するため、カスタム**AIレセプショニスト「Axle」**を構築
  • 単なるチャットボットではなく、実際に電話を受けられる音声ベースのエージェントとして設計され、価格・営業時間・ポリシーなど実情報に基づいて顧客問い合わせに対応
  • プロジェクトは3段階で構成：知識ベース構築(RAGパイプライン) → 電話接続とサーバー連携 → 音声品質と会話トーンの調整

Step 1: 頭脳の構築（RAGパイプライン）

  • **Retrieval-Augmented Generation (RAG)**方式を使い、AIが実データに基づいて応答するよう設計
    • 単純にLLMを使うと誤った価格提示などの**幻覚(hallucination)**リスクがあるため、実際の情報だけを根拠に回答するよう制限
  • Webサイトデータのスクレイピングによって21件以上の文書を収集し、サービスの種類・価格・所要時間・営業時間・支払い方法・保証・代車ポリシーなどを含めた
  • MongoDB Atlasに知識ベースを保存し、**Voyage AI (voyage-3-large)**モデルで1024次元のベクトル埋め込みを生成
    • Atlas Vector Searchインデックスを通じて意味ベースの検索を実行
  • 顧客の質問が入ると同じ埋め込みモデルでクエリを変換し、意味的に類似した上位3件の文書を検索
  • **Anthropic Claude (claude-sonnet-4-6)**モデルを使い、検索された文書を文脈として応答を生成
    • システムプロンプトには「知識ベース外の情報は禁止、簡潔で会話調を維持、不明な場合はコールバックを提案」というルールを含めた
  • 結果として、ターミナルで「オイル交換の費用は？」のような質問に対して、実際の価格とサービス内容を正確に回答できるようになった

Step 2: 実際の電話番号への接続

  • AIの頭脳を実際の電話システムに接続するため、Vapiプラットフォームを使用
    • 電話番号の購入、Deepgramベースの音声認識、ElevenLabsベースの音声合成、リアルタイムの関数呼び出し機能を提供
  • FastAPI Webhookサーバーを構築
    • Vapiが顧客の質問をtool-callsリクエストとして/webhookエンドポイントに送信
    • サーバーはこれをRAGパイプラインに渡してClaudeの応答を受け取り、再びVapiへ送信
    • 自然な会話スピードを保つために遅延の最小化が必要
  • Ngrokを使ってローカルサーバーを外部HTTPS URLとして公開し、開発中でもリアルタイムでテスト可能

  • Vapiアシスタント設定

    • あいさつ文と2つのツール(answerQuestion, saveCallback)をWebhookに接続
    • 質問に答えるか、分からない場合は名前と電話番号を受け取ってコールバックを保存
    • 会話メモリ機能により以前の会話の文脈を維持
    • 「営業時間はどうなっていますか？」→「ではタイヤ交換はいくらですか？」のような連続質問にも対応可能

  • MongoDBへの通話ログ保存

    • 発信番号、質問、応答、人間の担当者への切り替え有無、タイムスタンプを記録
    • コールバック要求は別のcallbacksコレクションに保存して後続連絡を可能にした
    • これにより顧客問い合わせパターンとコール量の分析が可能

Step 3: 音声品質の調整

  • テキスト応答と音声応答の違いを踏まえ、音声伝達の最適化が必要
    • 文章としては自然でも、音声で聞くと不自然に感じられることがある

  • ElevenLabsの音声選定

    • 約20種類の音声を試した結果、**「Christopher」**の音声が最も自然で整備工場の雰囲気に適していた
    • あまりにロボットっぽい声や、過度に明るい声は不適切

  • システムプロンプトの修正

    • 短い文、Markdownの除去、「いい質問ですね！」のような不要な文句の削除
    • 価格は自然言語で発音（“forty-five dollars”）
    • 応答は2〜4文以内に制限
    • 目標は親しみやすくプロフェッショナルな人間らしい音声の実現

  • エスカレーション（コールバック）フローのテスト

    • 知識ベースにない質問が来た場合、AIは分からないと伝え、名前・番号を聞いてMongoDBに保存
    • 整備工場のオーナーが直接フォローアップできる

  • 統合テストの作成

    • RAGパイプライン、Webhook処理、全体フローを検証
    • 不正なリクエスト、検索結果なし、コールバック番号の欠落などのエッジケース処理も含めた

技術スタック構成

  • Vapi (Deepgram & ElevenLabs統合) — 電話番号、音声認識、音声合成、関数呼び出し
  • Ngrok — ローカル開発用HTTPSトンネル
  • FastAPI + Uvicorn — Webhookサーバー
  • MongoDB Atlas — 知識ベース、ベクトル検索、通話ログ、コールバックキュー
  • Voyage AI (voyage-3-large) — 意味ベースのテキスト埋め込み
  • Anthropic Claude (claude-sonnet-4-6) — 知識ベースに基づく応答生成
  • Python — pymongo, voyageai, anthropic, fastapiで構成
  • Copilot CLI — ビルド自動化ツール

次のステップ

  • 現在のAIは質問応答とコールバック収集機能まで完成
  • 次の目標はカレンダー連携によるリアルタイム予約、SMS通知、コールバック管理ダッシュボード、セキュリティ強化、Railwayデプロイ
  • 完成すれば24時間運用が可能になり、電話応答の取りこぼしによる売上損失を防止
  • 最も難しかった部分はコードではなく、整備工場に合う音声トーンの実現
  • 核心となる教訓：業務特化型の音声エージェントに生のLLMをそのまま使わないこと
    • 実際の知識ベースに基づかせ、**分からないときの対応フロー（エスカレーション）**を必ず設計する必要がある
    • これは例外対応ではなく中核機能である

関連記事

1件のコメント

 
GN⁺ 2026-03-25
Hacker Newsのコメント

  • 以前、サービスアドバイザー（受付担当） として働いていた。記事で述べられているシステムは、現実的には機能しないと思う

    1. 同じ修理履歴がなければ、見積もりを外す可能性が高い。一部の州では、誤った見積もりが法的問題になることもある
    2. 部品在庫と価格は刻々と変わる。システムがそれを反映できなければ、混乱を招くだけだ
    3. 新しい作業は、部品選定の段階から複雑だ。高級車であるほどさらに厄介になる
    4. 役に立つ部分は、せいぜい車両の 引き取り通知 くらいだろう。完了時点や進捗状況を自動で知らせる用途だ
      こういう開発は単なる 傲慢 を超えて危険だ。検証もなく仮定だけで作れば、他人の生計を危うくする
    • 私も専門家ではないが、こうした 見栄張り には共感する。受付が必要なら人を雇うのが自然だ。検証されていないAIソリューションに事業を任せるのは理解しがたい。単に管理したくないのか、流行を追っているのかは分からない
    • 実はもっと簡単な解決策がある。車の下で作業している人が ハンズフリーのスピーカーフォン で電話を受けられるようにすればいい。ローカル音声認識モデルを使えばニューラルネット技術にも言及できるし、費用もマイク込みで200〜300ドルあれば十分だ
    • ただ、元記事を見ると、この整備工場はすでに 固定されたサービスと価格表 を持っている。だから個別見積もりが必要な場合でなければ、上の問題は当てはまらない
    • 「危険だ」という評価は大げさに思える。開発者は兄の事業を手伝っているのであって、完璧でなくても顧客転換率が10%上がるだけで十分に価値がある
    • 車両完了通知や進捗アップデートは、すでに TTSシステム で何年も前から可能だった。わざわざLLMは必要ない

  • うちの地域の Subaruディーラー では、電話予約時にAIアシスタントを選べる。使ってみると、人間より正確で速かった。Taco Bell のAI注文も同様に素晴らしかった。こういうケースでは人と話さなくても不利益はなく、必要ならいつでも人につないでもらえる

  • こういうブログ記事は半分の話にすぎない。実際に 売上が増えたのか、顧客がボットであることを気にしたのか、失敗事例があったのか が気になる

    • 実際のところ、こうした問題はAI以前から バーチャルアシスタントサービス で解決できた。月200〜1000ドルで十分で、すでに失っていた売上を取り戻すだけの話だ。AIはただのもっと複雑なネズミ捕りでしかなく、高級サービス なら人間の対応のほうがはるかに信頼感がある
    • おそらくまだ 実運用テスト が十分に行われていないのだと思う。メールアドレスのようなものはLLMが正確に聞き取って書き取るのが難しい。リアルタイム音声応答では Anthropic は遅く、Groq は200ms未満で非常に速い
    • 以前、急いで 自動車ガラス交換 をしなければならなかったのだが、自動音声システムが不要な情報ばかり求めてきたので切った。単純な予約なら問題ないだろうが、特殊な状況では結局人と話す必要がある
    • こうした試みは合理的だ。ただし実際の性能はまだ未知数だ。AI楽観論者と悲観論者 を分けるリトマス試験紙のようなものだ

  • 私は最近、LLMベースの電話アシスタント をかなり好意的に見ている。Mint Mobileのカスタマーサポートに電話したとき、LLMが自然に理解して1分で問題を解決してくれた。以前なら20分以上待っていたような案件だ

    • LLMは発音が明瞭で、ヘッドセットのノイズもなく、理解しやすい。もちろんeBayのLLMチャットボットのようにひどい場合もあるが、うまく実装されたシステム は見事に機能する
    • Amazon のチャットサポートも似ている。LLMが注文情報を事前に整理し、人間は最後の承認だけを行う。効率的だ
    • ただ、なぜアプリで解決できず LLMを使う必要があるのか には疑問がある。結局のところ、開発プロセスの失敗に見える
    • 私にも似た経験がある。技術的な質問をしたらLLMが正確に答え、その後人間の担当者に引き継がれたが、むしろその人のほうが専門性に欠けていた。それでも時間は節約できた
    • 昔のロボットよりはるかにましで、RAGベースのチャットボット はドキュメント検索を置き換えるほど有用だ。たとえばmanager.ioのチャットボットは、ドキュメントを見る代わりにすぐ答えを返してくれて便利だった

  • 記事によれば、その整備工場は電話に出られず 毎月数千ドルの損失 を出しているという。だとすれば、月500ドル程度の 外注受付担当 を置くほうが、はるかにROIが高い

    • 実際、留守番電話 だけでも一部の問題は解決できる。AIでも留守番電話でも、どうせ一部の顧客は切るだろう
    • しかも、すでに忙しすぎて電話に出られないのなら、新規顧客を増やしても処理する余力がない可能性が高い
    • 私の友人は 外部受付サービス を使っていて、月150ポンドで9時〜5時までカバーしている。本人は夕方に予定を調整するだけだ。もし記事の内容が本当なら、その整備工場はすでに 100%の稼働率 で動いているはずだ
    • 優れた サービスライター は高いが、それだけの価値がある。顧客の信頼も高く、将来的には事業を引き継ぐ可能性もある
    • 結局のところ、そのROIはブログが宣伝したい AI教育コース の広告効果にすぎない

  • 最近はロボット対応だと感じたらすぐ切るようにしている。でも、そのうち AI音声 が人間と区別できないレベルになる気がする。そのときには電話に対する 信頼 が崩れるかもしれない。すでにメールやLinkedInはAIスパムであふれていて、だから電話に移ったのに、それもすぐ失われそうだ

    • それでも留守番電話に回されても同じように切るのだから、損はない
    • AIが私の話を誤解して結局人間につながれると、同じ話を二度しなければならず疲れる
    • 最近車を探していて複数のディーラーと連絡を取ったのだが、後になって全員 LLMベースの偽名担当者 だったと気づいた。応答速度が速すぎて不自然だった

  • 「これは汎用チャットボットではない」と言っていたが、実質的には 2026年型の汎用チャットボット にすぎない

  • ブログの「About」ページを見ると、筆者は コーディングを学んで金持ちになった というインフルエンサーに影響を受けたらしい。だが、そうした姿勢は私が望む エンジニアリング文化の方向性 とはかけ離れている

  • 人々が AIで個人ブログを書くこと に少し憂鬱さを感じる

    • それでも、正直に明かしている点は評価したい。大半の人は文章を書く経験が乏しく、LLMを通じて「うまく書かれた文章」を得られると思っている。彼らにとっては、AIが書いた文章が悪いものだとは感じられないのかもしれない

  • ここで RAG は本当に必要だろうか。単なる価格表と営業時間程度なら、コンテキストウィンドウ に全部入る

    • おそらく学習目的のプロジェクトだったのだろう。私も個人プロジェクトで 過剰なアーキテクチャ を試しながら学ぶことがある
    • 音声対話では レイテンシー（latency） のほうが大きな問題だ。サイトに複数ページあるなら、RAGで必要な一部だけを素早く読み込み、LLMが詳細な回答を作るほうが効率的かもしれない
    • 単にウェブサイトと価格表全体をコンテキストに入れるほうが簡単だ
    • 私も同意する。この程度の情報なら一度に十分処理できる
    • 全体として、この アーキテクチャは過剰 だ