世界を動かす技術を、日本語で。

整備工場のためにAI受付を構築しました

2026年3月23日原文(itsthatlady.dev)

概要

  • 高級自動車整備工場の電話対応ロスによる損失解消を目的としたAI受付「Axle」の開発プロジェクト
  • Retrieval-Augmented Generation(RAG)を活用し、価格や方針の正確な回答を実現
  • VapiとFastAPIを組み合わせて実際の電話応対を自動化
  • 音声体験の最適化とエスカレーション(人間への引き継ぎ)フローの設計
  • 今後は予約機能やダッシュボードの実装、セキュリティ強化が課題

高級自動車整備工場向けAI受付「Axle」の開発背景

  • 兄弟が経営する高級自動車整備工場 で、電話対応できずに 月数千ドルの損失
  • 作業中に電話に出られず、顧客が他店に流れてしまう現状
  • AI受付「Axle」 の開発を決意
  • カスタム音声エージェント として、価格・営業時間・方針・コールバック収集に対応

ステップ1:RAGパイプラインによる「AIの頭脳」構築

  • Webサイトデータをスクレイピング し、サービス内容・価格・方針など21超のドキュメントを 知識ベース化
  • Voyage AI(voyage-3-large) で各ドキュメントを1024次元ベクトルに変換し、 MongoDB Atlas に格納
  • Atlas Vector Search で顧客の質問と知識ベースの意味的類似検索を実現
  • Anthropic Claude で回答生成し、「知識ベースからのみ回答・知らないことは明言しコールバック提案」という 厳格なプロンプト を設定
  • ターミナルで「オイル交換はいくら?」→「コンベンショナル45ドル、シンセティック75ドル。オイルフィルター・液補充・タイヤ空気圧チェック込み。所要約30分」と 正確な回答

ステップ2:実電話番号への接続

  • Vapi を音声プラットフォームに採用し、電話番号取得・音声認識(Deepgram)・音声合成(ElevenLabs)・リアルタイムAPI連携を実装
  • FastAPI でWebhookサーバを構築し、顧客の質問をRAGパイプラインにルーティング
  • Ngrok でローカル開発サーバを公開URL化し、VapiからWebhook連携
  • Vapiダッシュボード でアシスタント設定(挨拶・RAG回答・コールバック収集・Webhook連携)
  • 会話履歴の文脈保持 による複数質問への対応
  • MongoDBに全通話を記録 し、顧客の質問傾向やAI→人間エスカレーション率の可視化

ステップ3:音声体験の最適化

  • ElevenLabsのAI音声 から20種以上をテストし、 Christopher (落ち着き・自然・自動車知識感)の声を採用
  • 音声用プロンプト を再設計し、短文・自然な価格表現・2~4文以内・機械的表現排除
  • 知識ベース外の質問は推測せず、コールバック取得・MongoDB保存でリード喪失防止
  • エッジケースをカバーする統合テスト を作成(不正リクエスト・ベクトル検索失敗・コールバック未入力など)

技術スタック

  • Vapi (Deepgram, ElevenLabs統合):電話番号・音声認識・音声合成・API連携
  • Ngrok :ローカル開発用トンネリング
  • FastAPI + Uvicorn :Webhookサーバ
  • MongoDB Atlas :知識ベース・ベクトル検索・通話ログ・コールバック管理
  • Voyage AI :テキスト埋め込み
  • Anthropic Claude :知識ベースに基づく回答生成
  • Python (pymongo, voyageai, anthropic, fastapi)
  • Copilot CLI :開発補助

今後の展望

  • カレンダー連携による即時予約受付 の実装
  • 新規コールバックのSMS通知 追加
  • コールバック管理ダッシュボード の構築
  • 本番運用向けセキュリティ強化
  • Railwayへのデプロイ で常時稼働化
  • 実際の顧客対応運用 への移行

ビジネス特化型AI音声エージェント開発のポイント

  • 汎用LLMは危険、必ず 知識ベースに基づくRAG で回答を制限
  • エスカレーション(人間引き継ぎ) は例外でなく 必須フロー
  • 顧客体験に直結する音声トーン の最適化が成功の鍵
  • 本記事はAIによる支援で執筆

Hackerたちの意見

RAGってここで必要なの?価格リストや営業時間みたいな最小限の情報なら、どんなコンテキストウィンドウにも簡単に収まると思うんだけど。まるでサービスマニュアルを丸ごとベクターデータベースに放り込んでるわけじゃないし…。

完全に同意。全体がコンテキストに収まると思う。

うん、このアーキテクチャは完全に不要だね。

たぶんそうじゃないけど、このプロジェクトは他の目的よりも学習のためにやったみたいだね。だったら、「生産準備完了」や「スケーラブルな」ソリューションを目指せばいいのに。私も個人プロジェクトで同じことをすることがある。必要だからじゃなくて、新しいことを学びたいから、オーバーアーキテクチャにしちゃうんだよね。

そうだね、ウェブサイト全体と価格表をコンテキストウィンドウに詰め込んじゃえばいいんじゃない?

音声会話の場合、問題は文脈を埋めることよりも遅延の方が大きいかもしれない。サイトが分からないから何とも言えないけど、もし彼が複数ページ分のテキスト(車の種類、手順、感情的な話など)を持っていて、「遅い」モデルを使っているなら、RAGを使って素早く小さな部分を選び、LLMで回答を洗練させるのが良いかもしれない。

「彼は週に何百件も電話を逃しているせいで、毎月何千ドルも失っている。彼は一日中作業している。電話が鳴るけど、出られなくて、顧客は電話を切って他の誰かにかける。それが失われた仕事だ。時には450ドルのブレーキサービス、時には2000ドルのエンジン修理が、誰も出なかったせいで消えてしまう。」外注の受付を雇うのにどれくらいかかるんだろう?月500ドルでも、毎月何千ドルも失っているなら、ROIはやばいことになるよね。

外注の受付を使っている友達がいるんだけど、彼はフルタイムのスタッフを3人雇っていて、受付は月150ポンドで9時から5時まで電話を受けている。彼は夕方にスケジュールを組んでいる。OPの投稿をそのまま受け取ると、彼の兄はすでに100%のキャパシティにいるってことだよね。そうじゃなきゃ、こんなに電話を逃すことはないはず。

それに、もし彼が電話に出られないほど忙しいなら、失われた仕事を引き受ける余裕もないだろうね。

良い「サービスライター」(この仕事の呼び方ね)は安くないし、通常は外注しない。地元の競合も使ってるからね。それに、顧客は複数の店舗のサービスを書いている人を信頼しないから。とはいえ、良いサービスライターは金の価値があるよ。引退するときにその人にビジネスを売ることになることが多いし、ほとんどのメカニックはビジネス面が得意じゃないから、サービスライターがその役割を担うんだ。

外注の受付なんて気にしないで、そういう電話のいくつかはボイスメールで十分対応できるよね。もちろん、ボイスメールのメッセージが始まったら切る人もいるけど、AIチャットボットと話してるって気づいたら切る人もいるしね。

それは失われた仕事だね。時には450ドルのブレーキサービス、時には2,000ドルのエンジン修理。クリス、地元のティーンエイジャーでも雇えばいいのに。最低賃金で働く人たちもいるから。

Hacker Newsで議論の続きを見る