この記事の結論：製造メーカーのアフターサービスで生成AIを使うなら、問い合わせ窓口だけをチャットボット化するのではなく、製品情報、取扱説明書、修理履歴、部品情報、過去の対応記録をつなぎます。AIは情報検索、確認質問、回答案、修理受付、報告書作成を支援し、安全判断、故障診断、保証判定、リコール対応、最終回答は担当者が確認します。
はじめに
製造メーカーでは、製品を販売した後にも多くの業務が続きます。
- 製品の使い方に関する問い合わせ
- エラーや故障の一次切り分け
- 修理受付
- 出張修理の日程調整
- 交換部品の確認
- 見積書の作成
- 取扱説明書やFAQの案内
- 修理後の報告
- 同じ不具合の集計
- 設計、品質保証、製造部門へのフィードバック
これらの業務は、電話、メール、Webフォーム、販売店、サービス拠点など複数の窓口に分かれています。さらに、取扱説明書、部品表、修理履歴、保証条件、製品ごとの注意事項が別々に管理されていると、担当者は回答する前に情報を探すだけで時間を使います。
生成AIは、この情報探索と引継ぎを効率化できます。ただし、AIに問い合わせ対応を丸ごと任せればよいわけではありません。
ポイントは、1件の問い合わせを、受付から修理完了、取扱説明書の改善、製品改善までつなぐことです。
アフターサービスで起きやすい問題
問い合わせ窓口と修理部門が分かれている
カスタマーサポートが聞いた内容を、修理担当者がもう一度確認する。修理担当者が作成した報告書を、品質保証部門が別の形式へ転記する。同じ情報を何度も入力すると、対応時間だけでなく、伝達漏れも増えます。
製品の特定に時間がかかる
同じ製品名でも、型式、製造番号、販売時期、仕向地、ソフトウェアのバージョンによって仕様が異なる場合があります。対象製品を確定しないまま回答すると、別の取扱説明書や部品を案内する可能性があります。
取扱説明書が見つからない、読まれない
取扱説明書がPDFで公開されていても、利用者が必要な箇所へたどり着けるとは限りません。エラーコード、症状、操作名など、利用者の言葉と説明書の見出しが一致しないこともあります。
ベテラン担当者へ確認が集中する
「この音ならこの部品を疑う」「この年代の機種は、先にこの箇所を見る」といった知識が、修理記録ではなく担当者の経験に残っていることがあります。問い合わせが増えるほど、詳しい人へ確認が集中します。
生成AIを使える8つの場面
1．問い合わせを分類する
電話の文字起こし、メール、Webフォームの内容から、製品名、型式、製造番号、発生日時、症状、エラーコード、使用環境、発生前に行った操作、安全に関する申告、保証・保守契約、写真・動画・ログの有無、緊急度、次に確認する質問を整理します。
情報が足りない場合は、回答を作る前に不足項目を出します。最初から原因を決めつけず、受付情報と原因仮説を分けることが重要です。
2．取扱説明書から該当箇所を探す
利用者の質問を、取扱説明書内の用語へ置き換えて検索します。
例えば「赤いランプが点滅する」という問い合わせに対し、対象機種の表示灯名称、点滅パターン、該当するエラーコード、取扱説明書の参照ページ、利用者が確認できる範囲、電源遮断や修理依頼が必要な条件を探します。
回答には、参照した説明書名、版、ページ、該当箇所を付けます。AIの要約だけを表示せず、利用者や担当者が原文を確認できるようにします。
3．確認質問を作る
故障相談では、最初の申告だけで原因を判断できないことがあります。AIは症状に応じて、発生時期、再現条件、異音・異臭・発熱・煙の有無、落下や水濡れ、部品交換や設定変更、エラーコードなどの確認質問を組み立てます。
ただし、危険が疑われる場合に再操作を促してはいけません。質問の前に、安全上の停止条件を確認します。
4．一次回答案を作る
対象製品、症状、取扱説明書、FAQ、過去の承認済み回答を基に、担当者向けの回答案を作ります。
回答案は、問い合わせ内容の要約、安全上の注意、利用者が確認できる項目、参照した取扱説明書、解決しない場合の連絡方法、修理受付に必要な情報の順にすると確認しやすくなります。
AIが作成した文章は、担当者が製品と状況に合っているか確認してから送信します。
5．修理受付と訪問準備を支援する
問い合わせ内容から、対象製品、設置場所、症状と再現条件、過去の修理履歴、想定する確認箇所、必要な測定器、持参候補の部品、作業前の安全確認、顧客へ準備を依頼する事項をまとめます。
持参部品は候補として提示し、正式な部品番号、互換性、在庫、出荷可否は部品管理システムと担当者が確認します。
6．修理報告書を作る
現場担当者のメモ、写真、交換部品、測定結果、作業時間から、申告された症状、現地確認結果、原因、実施した作業、交換部品、修理後の確認、顧客への説明、再発防止のための注意、次回確認事項、設計・品質部門へ共有する内容をまとめます。
音声入力から報告書を作れるようにすると、移動後の転記を減らせます。ただし、測定値、部品番号、作業結果は原記録と照合します。
7．FAQと取扱説明書の改善候補を出す
問い合わせが多い質問を集計し、検索されているが説明書にない言葉、同じ箇所で発生する操作ミス、問い合わせが多いエラーコード、写真や図が必要な手順、製品ページへ追加すべきFAQなどを整理します。
取扱説明書は、問い合わせ対応の資料であると同時に、製品安全にも関わる正本です。AIが直接書き換えるのではなく、改善候補と根拠となる問い合わせをまとめ、技術、品質、法務、サービス部門で確認します。
8．製品改善へフィードバックする
問い合わせ件数だけを見るのではなく、型式、製造時期、症状、使用環境、交換部品、再修理の有無を組み合わせます。
例えば、同じ部品交換が特定の製造ロットで増えている場合、単なるFAQではなく、品質確認や設計変更の候補になります。
AIは傾向の整理と報告書作成を支援できますが、製品不具合、重大事故、リコールの判断は行いません。正式な品質管理と製品安全の手順へ切り替えます。
1件の問い合わせを最後までつなぐ
アフターサービスを改善する場合、部門ごとに別のAIを導入するより、1件の対応に共通IDを付けて情報をつなぐ方が効果を確認しやすくなります。
- 顧客が問い合わせる
- AIが製品情報と症状を整理する
- 担当者が緊急度と安全性を確認する
- AIが取扱説明書とFAQから回答案を作る
- 解決しない場合は修理受付へ引き継ぐ
- AIが過去履歴と訪問準備情報をまとめる
- 修理担当者が診断、作業、動作確認を行う
- AIが修理報告書の下書きを作る
- 顧客へ担当者が結果を説明する
- 問い合わせと修理結果をFAQ、取扱説明書、品質改善へ戻す
この流れで重要なのは、AIがすべてを処理することではありません。同じ情報を何度も聞かないことと、次の担当者へ判断材料を残すことです。
AIへ渡す前に整える情報
| 情報 | 正本にする場所 | AIでの使い方 |
|---|---|---|
| 製品名、型式、製造番号 | 製品・顧客マスター | 対象製品の確定 |
| 取扱説明書、サービス資料 | 文書管理 | 該当箇所の検索と回答案 |
| 部品番号、代替品、在庫 | 部品・在庫管理 | 候補の抽出 |
| 問い合わせ履歴 | CRM・受付管理 | 経緯の要約と引継ぎ |
| 修理履歴、測定結果 | サービス管理 | 類似事例の検索 |
| 保証条件、保守契約 | 契約・保証管理 | 確認項目の提示 |
| リコール、重要注意事項 | 品質・製品安全管理 | 担当部門への即時引継ぎ |
最初からすべてのデータを統合する必要はありません。対象製品を1シリーズに絞り、承認済みの取扱説明書、FAQ、修理受付票、過去の対応記録から始めます。
また、説明書の版が複数ある場合は、最新版だけでなく適用対象を管理します。古い製品へ新しい説明書の手順を案内しないためです。
取扱説明書をAIに読ませるときのルール
取扱説明書を検索できるだけでは、業務で使える状態とは言えません。最低限、次のルールを決めます。
- 回答には資料名、版、ページを付ける
- 対象型式と製造番号を確認する
- 複数資料が矛盾した場合は回答を止める
- 警告、禁止、注意を要約で弱めない
- 画像、配線図、部品図は原本も表示する
- 廃止製品と現行製品を分ける
- 改訂後は検索結果を再確認する
- 回答できない場合の引継ぎ先を表示する
消費者庁のリコール情報サイトでは、是正措置として回収や交換だけでなく、点検、修理、補修部品の提供、説明書の差替え、注意喚起も扱っています。アフターサービスの回答は、単なる接客ではなく製品安全の情報伝達になる場合があります。
そのため、AIの「分かりやすい要約」より、正しい対象製品と正しい版の情報を示すことを優先します。
生成AIに任せない範囲
以下はAIだけで決定、実行しません。
- 発煙、発火、感電、けがなどが疑われる場合の安全判断
- 製品を継続使用してよいかの最終判断
- 故障原因の確定
- 分解、調整、通電確認などの作業指示
- 保証対象か、有償修理かの最終判定
- 部品の互換性と代替可否の確定
- 重大製品事故やリコールへの該当判断
- 法令、規格への適合判断
- 修理完了の判定
- 顧客への最終回答
- 顧客情報や修理履歴の無制限な外部AIへの入力
特に、問い合わせには氏名、住所、電話番号、購入履歴、設置場所、製品の利用状況などが含まれます。個人情報や顧客情報を扱う場合は、会社が承認したAI環境、入力できるデータ、保存期間、アクセス権限を決めます。
AI活用例：ChatGPTプロジェクトで「修理受付・一次回答」を作る
ここでは一事例だけ、対象製品Aシリーズの修理受付をChatGPTのプロジェクト機能で支援する例を考えます。プロジェクト機能の位置づけ、料金プラン、会社管理との境界は、先にChatGPTは「チャット」ではなく「プロジェクト」で使うと仕事になるで整理しています。
この例でChatGPTが担うのは、問い合わせ内容の整理、承認済み資料の検索、確認質問と一次回答案の作成です。故障原因、安全性、保証、部品適合の最終判断は担当者が行います。
1．対象業務と完了条件を決める
プロジェクト名は「Aシリーズ 修理受付・一次回答」とします。Aシリーズは説明用の架空製品です。
対象は、電話やWebフォームで受けた問い合わせを、担当者が確認できる受付票と一次回答案へ変換するところまでです。次の状態になれば1件の処理を完了とします。
- 製品を特定する情報と症状が受付票に整理されている
- 不足情報が質問として列挙されている
- 参照した資料名、版、ページが示されている
- 危険が疑われる場合は回答作成を止め、引継ぎ先が示されている
- 顧客へ送る文章は「回答案」と明記され、担当者の確認前には送信されない
2．プロジェクトへ入れる資料を限定する
プロジェクトには、Aシリーズに適用できる承認済み資料だけを登録します。
| 登録する資料 | 例 | 用途 |
|---|---|---|
| 取扱説明書 | Aシリーズ取扱説明書 第3版 | 操作方法、警告、エラー表示の確認 |
| エラーコード一覧 | Aシリーズ エラーコード表 2026-07 | コードの意味と利用者が確認できる範囲 |
| 承認済みFAQ | カスタマーサポートFAQ 2026-08 | 一次回答案の表現 |
| 修理受付票 | 修理受付テンプレート v2 | 出力項目の固定 |
| 重要注意事項 | 製品安全・重要連絡一覧 | 即時引継ぎ条件の確認 |
顧客名、住所、電話番号、製造番号を含む受付履歴を、資料としてプロジェクトへ蓄積し続ける構成にはしません。正本はCRMや修理管理システムに置き、ChatGPTへ入力する情報は社内ルールで許可された範囲に限定します。
取扱説明書を改訂した場合は、旧版を残したまま追加するのではなく、対象型式と適用期間を確認してプロジェクトの資料を更新します。
3．プロジェクト指示を設定する
プロジェクト指示には、役割、参照順序、停止条件、出力形式を書きます。例えば次のように設定します。
あなたはAシリーズの修理受付を支援します。
登録された資料だけを根拠にし、推測で故障原因を確定しないでください。
処理手順：
1. 型式、製造番号、症状、発生日時、使用環境、エラーコードを整理する
2. 不足項目を確認質問として出す
3. 対象型式に合う取扱説明書、エラーコード表、FAQを検索する
4. 資料名、版、ページを付けて一次回答案を作る
5. 修理が必要な場合は、受付票と担当者への引継ぎ事項を作る
停止条件：
- 発煙、異臭、異常発熱、感電、けがの申告がある
- 対象型式または適用する資料の版を確定できない
- 複数の登録資料が矛盾する
- リコールまたは重要注意事項に該当する可能性がある
停止条件に該当した場合は、再操作を促さず「回答停止」と表示し、
製品安全担当者またはサービス責任者への引継ぎ事項だけを出してください。
出力は「受付要約」「不足情報」「参照資料」「一次回答案」
「修理引継ぎ」「担当者確認事項」の順にしてください。この指示をプロジェクト共通にすると、担当者ごとに質問の仕方や出力形式が変わるのを抑えられます。一方、製品安全ルールを変更した場合は、個別チャットではなくプロジェクト指示を更新します。
4．問い合わせごとにチャットを分ける
1件の問い合わせにつき、1つのチャットを作ります。チャット名は個人名を使わず、「受付日・製品型式・受付番号」のようにします。
入力は、自由文だけでなく次の型にそろえます。
受付番号：SR-2026-0825-014
製品：Aシリーズ
型式：A-200
製造番号：入力可否を社内ルールで確認
症状：電源投入後にE17が表示され、再起動すると一時的に復旧する
発生日時：2026年8月25日 9時頃
使用環境：屋内、通常運転中
安全に関する申告：煙、異臭、発熱、けがはなし
顧客が試したこと：電源を1回だけ再投入
依頼：不足情報、参照資料、一次回答案、修理引継ぎを作成ChatGPTには、顧客へ直接返答させるのではなく、最初に不足情報を出させます。この例では、E17がどの操作後に出たか、表示が継続するか、周辺機器の状態、取扱説明書で許可された確認項目を追加質問として整理します。
5．AIの出力を担当者が確認する
期待する出力は次の形です。
| 出力 | この事例で確認する内容 |
|---|---|
| 受付要約 | A-200でE17が表示され、再起動後に一時復旧した |
| 不足情報 | 発生直前の操作、再現回数、周辺機器の状態など |
| 参照資料 | Aシリーズ取扱説明書 第3版の該当ページ、E17一覧 |
| 一次回答案 | 安全上の注意、利用者が確認できる項目、修理窓口 |
| 修理引継ぎ | エラー発生条件、取得すべきログ、訪問確認候補 |
| 担当者確認事項 | 型式、資料の適用範囲、回答文、保証・修理区分 |
担当者は、参照ページを原本で開き、対象型式、警告文、確認手順が一致しているかを確認します。E17の意味を資料から特定できない場合や、資料同士で記載が異なる場合は、AIの文章を整えて送るのではなく回答を止めます。
確認後、承認した回答だけをメールやCRMへ転記します。受付内容、担当者が修正した箇所、最終回答、修理結果は正本側へ保存します。ChatGPTのチャットだけを対応履歴の正本にはしません。
6．1か月だけ試して効果を測る
最初はAシリーズと一次回答業務に限定し、1か月間だけ試します。確認する指標は、受付票作成時間、一次回答までの時間、担当者による修正率、参照資料の誤り、再問い合わせ率です。
例えば受付票作成が1件10分から5分になっても、参照資料の誤りや再問い合わせが増えた場合は成功とは判断しません。どの指示や資料を直せば修正率が下がるかを確認し、問題がない場合にだけ別シリーズや修理報告書作成へ広げます。
この構成なら、ChatGPTプロジェクトを単なる資料置き場にせず、入力、参照、停止、確認、記録まで含む小さな業務単位として試せます。
小さく始める4段階
第1段階：取扱説明書検索
対象製品を1シリーズに絞り、承認済みの取扱説明書とFAQから回答候補を探せるようにします。最初に確認するのは、回答速度よりも参照箇所の正しさです。
第2段階：問い合わせ整理と回答案
メールやWebフォームから受付票を作り、不足情報と回答案を出します。送信は担当者が行います。問い合わせ分類、確認質問、回答案の修正内容を残します。
第3段階：修理受付と報告書
修理受付票、訪問準備票、修理報告書をつなぎます。現場担当者が同じ内容を再入力する回数を減らします。
第4段階：改善へのフィードバック
問い合わせと修理結果を集計し、FAQ、取扱説明書、部品在庫、設計、品質改善へ戻します。この段階で、AIが回答を作るだけの仕組みから、アフターサービス全体を改善する仕組みに変わります。
効果を測る指標
| 指標 | 確認すること | 注意点 |
|---|---|---|
| 初回回答までの時間 | 情報検索と受付が速くなったか | 速さだけで誤回答を増やさない |
| 一次解決率 | 問い合わせ窓口で解決した割合 | 危険な自己解決を促していないか確認 |
| 再問い合わせ率 | 同じ内容で再連絡があった割合 | 説明の分かりやすさも確認 |
| 修理リードタイム | 受付から完了までの時間 | 部品待ちと情報待ちを分ける |
| 再修理率 | 同じ症状が再発した割合 | 製品、作業、使用環境を分けて見る |
| 報告書作成時間 | 現場担当者の転記が減ったか | 原記録との一致を確認 |
| 説明書改善件数 | 問い合わせが文書改善につながったか | 件数だけでなく再問い合わせ減少を見る |
費用対効果を確認する場合は、削減時間だけでなく、誤案内、再訪問、部品の誤出荷、対応漏れを減らせたかも見ます。
AI部署として役割を分ける
アフターサービスへ継続的にAIを組み込む場合、役割を分けると管理しやすくなります。
- 問い合わせ整理AI：受付内容の分類、不足情報、緊急度候補を整理する
- 取扱説明書検索AI：対象機種の資料から参照箇所を探す
- 回答案作成AI：承認済み情報を基に担当者向けの回答案を作る
- 修理準備AI：過去履歴、確認箇所、持参候補をまとめる
- 修理報告AI：現場メモから報告書の下書きを作る
- 品質フィードバックAI：問い合わせと修理結果から改善候補を整理する
AIメンバーごとに、入力情報、参照先、出力、禁止事項、確認者を決めます。1つの万能AIへすべての権限を与えるより、問題が起きたときに原因を追いやすくなります。
まとめ
製造メーカーのアフターサービスで生成AIが力を発揮するのは、問い合わせへ文章で回答する場面だけではありません。
製品の特定、取扱説明書の検索、確認質問、修理受付、訪問準備、報告書、FAQ改訂、品質改善までつなぐことで、担当者の情報探索と転記を減らせます。
一方、安全判断、故障診断、保証判定、部品の適合、リコール対応、最終回答は人が確認します。
まずは対象製品を1シリーズに絞り、取扱説明書検索と問い合わせ整理から始めます。回答の正しさと担当者の修正内容を記録し、問題がない範囲から修理受付、報告書、改善フィードバックへ広げる方法が現実的です。
自社のアフターサービス業務を整理する
どの製品、どの問い合わせから生成AIを使うべきか分からない場合は、現在の受付、回答、修理、報告、改善の流れを1件分だけ書き出します。
Prompthingでは、既存の取扱説明書、FAQ、修理履歴、顧客管理を活かしながら、生成AIを継続運用する「AI部署」の設計を支援しています。