要点
- AIは故障原因を確定するのではなく、症状・未確認事項・安全上の注意・修理先への引継ぎ情報を整理します。
- 異臭、煙、火花、燃料漏れ、高温などの申告では、遠隔操作より安全確保と専門窓口への連絡を優先します。
- 対応地域や加盟事業者、修理時間、売上効果は確認済みの事実と将来構想を分けて表示します。
キャンピングカーの修理相談では、症状の聞き取り、原因候補の整理、対応できる工場探しまで多くの情報が必要です。
そこで、修理の知識とWebシステムを組み合わせ、相談から案件管理、修理事業者への送客までを支援するAI・DX基盤を開発しています。
背景：専門知識が分散しやすい
キャンピングカーは、車両本体だけでなく、FFヒーター、サブバッテリー、電装、給排水など設備が多く、相談内容も複雑です。
担当者の経験だけに依存すると、情報共有や引き継ぎが難しくなります。
実際に作っている仕組み
- キャンピングカー修理AI相談
- FFヒーター診断支援AI
- サブバッテリー診断支援AI
- 修理RAGデータベース
- 修理案件管理システム
- 整備情報管理
- 修理受付AI
- 全国修理事業者マッチング・送客プラットフォーム
具体的な流れ
- 利用者が症状を入力
- AIが必要な確認事項を整理
- 登録された修理情報・ナレッジを検索
- 原因候補や確認順序を提示
- 人が内容を確認
- 修理が必要な場合は対応可能な事業者へ案件をつなぐ
- 受付後の案件状況を管理
AIが修理を断定するのではなく、相談の整理と次の行動を支援する位置づけです。
使用している技術
- OpenAI API
- RAG / ベクトル検索
- Notion連携
- Python / FastAPI
- Next.js
- データベースによる案件管理
- Webフォーム・管理画面
- 修理事業者マッチング設計
具体例1：サブバッテリーの相談を、安全確認から工場案内へつなぐ
架空の利用者から「車中泊の朝にサブバッテリーの電圧表示が下がっていた」と相談が届いた想定です。受付AIは、車両の年式・車種、バッテリーの種類、表示された値と確認時刻、直前に使っていた電装品、警告表示、発熱・焦げ臭さの有無を、必要な範囲だけ質問します。電圧値や写真だけから故障原因や走行可否を断定せず、熱・煙・異臭、配線の損傷など危険を感じる情報があれば、通電や分解を勧めず、利用者へ安全確保と専門業者・緊急窓口への相談を案内します。
RAGは、登録された車種別資料、過去の修理知識、メーカー文書から関連候補を検索し、資料名と版を添えて担当技術者へ渡します。担当者は車両情報と原資料を照合し、遠隔では判断できない部分を明確にしたうえで、対応可能な工場へ相談を引き継ぎます。
具体例2：FFヒーターの停止相談を、無理な再起動より情報整理に使う
別の架空の相談では、利用者が「FFヒーターが途中で止まり、表示にエラーが出る」と連絡したとします。AIは機器のメーカー・型式、エラー表示の正確な文字、停止までの時間、燃料や電源の状況、最近の修理履歴を確認候補として並べます。表示コードが確認できない場合は推測せず、画面写真や取扱説明書の該当箇所を安全な方法で確認してもらいます。
修理工場は、資料に沿って初期確認の範囲を決め、分解・燃料系統・電装系統など専門作業は有資格・対応可能な技術者が行います。AIが「この部品を交換すれば直る」と約束したり、利用者に危険な点検作業を案内したりしません。受付画面には、聞き取った事実、まだ未確認の項目、担当者、次の連絡予定を分けて残します。
根拠資料と人の判断を切り分ける
車載式故障診断装置（OBD）で取得する情報は、車両の電子制御に関する点検・検査の一部であり、キャンピングカーの居住設備すべてを診断するものではありません。国土交通省のOBD検査案内でも、対象車両・制度・関係者の範囲が定められています。故障コードが読めたことだけをもって原因や修理方法を確定せず、車両側と後付け設備の両方を専門家が確認します。国土交通省「OBD検査を実施するにあたって」
ナレッジには、文書名、対象機種、作成・更新日、出典、適用上の注意を持たせ、古い説明や別機種の情報を混ぜないようにします。利用者の車台番号、住所、連絡先、旅行予定などは、修理相談の目的に必要な範囲で扱い、不要なAI入力や広い社内共有を避けます。
案件を適切な修理事業者へ渡す運用
相談の整理後に工場を案内する場合、所在地だけで候補を選ばず、対応可能な設備・機種、現在の受入状況、訪問か持ち込みか、相談者が希望する時期を人が確認します。事業者へ渡す情報は、本人の同意を得た上で、診断に必要な症状と連絡方法に絞ります。問い合わせを送った日時、受領確認、折り返し予定、未接続時の再連絡担当を記録し、送客した後も利用者が宙に浮かないようにします。全国ネットワークを構築中の場合は、参加事業者や対応エリアを確認済みの事実と、将来構想として明確に分けて表示します。
相談を受けてから完了までの案件記録
受付IDごとに、症状の申告、確認済みの情報、未確認、緊急性の確認担当、紹介候補、本人への説明、修理工場の受領状況、次の連絡予定を分けて残します。AIが作った要約は「下書き」と表示し、担当者が原文や添付写真と照合してから案件記録へ反映します。修理事業者が受け入れできない場合は、理由と次の選択肢を担当者が更新し、利用者に進捗を伝えます。案件を複数の工場へ同時送信する場合も、共有する情報と本人同意の範囲を確認してから行います。
遠隔案内で越えない境界を先に決める
利用者が「今すぐ走行してよいか」「電源を入れ直せば直るか」と尋ねても、車両の状態を実見していないAIが安全を保証する回答はしません。異臭、煙、火花、燃料漏れ、高温などの申告は、一般的な故障候補の説明より安全確保と専門窓口への連絡を優先します。ナレッジベースには、禁止する遠隔作業、相談先、緊急時の案内を分かりやすく登録し、回答テストにも安全に関わる質問を含めます。
事業モデルまで含めて設計
この領域では、単なるチャットボットだけでなく、問い合わせを全国の修理会社へつなぐ送客モデルも設計しています。
つまり、「AIを作る」だけでなく、「問い合わせが発生してから仕事として成立するまで」を一つの仕組みとして考えています。
何が楽になるのか
相談時の聞き漏れを減らし、確認すべき項目を揃えやすくなります。
また、修理情報や過去の知識をRAGで参照できるようにすることで、担当者が毎回一から資料を探す負担を減らせます。
現時点で修理時間短縮率や売上増加率などの数値は公表していません。
よくある質問
Q. AIだけで故障原因を確定できますか？
できません。安全に関わるため、AIは原因候補や確認事項の整理を行い、最終的な診断や修理判断は専門家が行います。
Q. 修理情報はどこから参照しますか？
登録したナレッジや整備情報をRAGで検索する構成です。公開情報と内部情報の扱いは分けて設計します。
Q. 全国の修理会社と自動でつながりますか？
送客プラットフォームとしての仕組みを設計・開発していますが、実際の加盟状況や対応地域は運用段階で確認が必要です。
Q. 一般の自動車修理にも応用できますか？
案件管理や受付、ナレッジ検索の考え方は応用可能です。車種・業務ごとに必要情報を設計し直します。
まとめ
この事例では、専門知識をAIに載せるだけでなく、相談、案件管理、送客まで一体で設計しています。
現場経験と事業モデルを理解したうえで、AI・Webシステムへ落とし込むことが特徴です。