【想定事例_詳細版】設備メンテナンス会社の問い合わせ対応を業務整理から改善

AIを業務に活用したいと考えていても、「どの業務に使えばよいのか分からない」「ツールを導入しても現場で使われない」「なんか思っていたのと違う」といった問題が起こることがあります。

その原因の一つは、現在の業務や問題を十分に整理しないまま、AIツールの導入から検討を始めてしまうことです。

AIは、既存業務に追加すれば必ず効果が出るものではありません。不要な作業や曖昧なルール、属人化した判断が残った状態でAIを組み込むと、かえって業務が複雑になることが多々あります。

本記事では、Google Workspaceを利用している設備メンテナンス会社を想定し、業務全体の確認から改善対象の選定、問い合わせ対応の業務整理、AI・自動化の設計、PoC、本導入までの流れを紹介します。

想定企業と相談の背景

今回想定するのは、法人、工場、店舗、事務所などを対象に、設備の修理・点検を行っている会社です。

項目	想定内容
業種	設備メンテナンス業
従業員数	約25名
主な顧客	法人、工場、店舗、事務所
主な業務	修理、点検、見積、納期確認、資料送付
利用ツール	Gmail、Google Drive、Excel、電話
相談内容	事務業務の負担と属人化を整理したい
AI活用状況	一部の担当者が試しているが、業務には未定着

この会社では、Google Workspaceを導入しているものの、業務全体で十分に活用できていません。

メールはGmail、資料はGoogle Drive、顧客情報や案件情報はExcelなど、情報が複数の場所に分散しています。

経営者や担当者からは、次のような悩みが挙がっていると想定します。

• 事務担当者の業務量が増えている
• メールや電話への対応に追われている
• 特定の担当者が不在になると処理が遅れる
• 問い合わせ内容や対応履歴が複数の場所に分散している
• Google Workspaceを十分に活用できていない
• AIを使いたいが、どの業務に使えばよいか分からない
• 大規模なシステム導入は避けたい
• 現場の負担を増やさず、小さな範囲から改善したい

この段階では、まだ「問い合わせ対応を改善する」と決めてません。

最初の目的は、AIツールを選ぶことではなく、どの業務に問題があり、どの業務から改善すべきかを整理することです。

最初に業務全体を棚卸しする

メール対応の負担が大きく見えていても、すぐに問い合わせ対応を改善対象として決めるわけではありません。

まず、受付・営業事務担当者が行っている主要業務を簡易的に洗い出します。

業務	主な作業
問い合わせ対応	メール・電話確認、分類、担当者共有、返信
見積作成補助	必要情報の収集、書類作成
日程調整	顧客、営業、現場担当者との調整
資料送付	カタログ、仕様書、見積書の送付
顧客情報管理	Excelやメール上の情報更新
請求関連補助	請求情報の確認と経理への共有
社内連絡	営業・現場・管理者への情報共有

それぞれの業務について、次の項目を確認します。

• 件数と発生頻度
• おおよその所要時間
• 主な担当者
• 使用しているツール
• 判断が必要な場面
• 特定担当者への依存
• ミスや手戻り
• 処理が遅れた場合の顧客への影響

この段階では、すべての業務を詳細に分析する必要はありません。

まずは業務全体を広く確認し、どの業務を優先して詳しく見るべきかを判断します。

改善対象業務の優先順位を決める

改善対象は、単純に作業時間が長い業務だけで決めるものではありません。

例えば、資料送付に一定の時間がかかっていても、顧客への影響が小さく、誰でも対応できるのであれば、最優先で改善する必要はないかもしれません。

一方、作業時間そのものは極端に長くなくても、対応漏れや担当者不在による遅延が顧客との関係に影響する業務は、優先度が高くなります。

今回のモデルケースでは、次の観点で各業務を比較します。

• 業務量
• 所要時間
• 属人化
• ミスや手戻り
• 顧客への影響
• 対応遅れのリスク
• 標準化のしやすさ
• 改善できる余地
• 通常の自動化との相性
• AIとの相性

簡易評価の結果は、次のようになったと想定します。

業務	負担	属人化	顧客影響	改善可能性	優先度
問い合わせ対応	高	高	高	高	高
見積作成補助	中	中	高	中	中
日程調整	中	中	高	中	中
資料送付	中	低	低	高	低
顧客情報更新	中	低	中	中	低

問い合わせ対応は件数が多く、新規メールが埋もれてしまって初動が遅れ、機会損失を招いている可能性もあります。

また、問い合わせ内容を読んで担当者を判断する業務が特定の事務担当者に依存しているため、担当者が不在になると処理が遅れる状態でした。

以上から、最初の改善対象として「メールで受け付ける問い合わせ対応」を選定します。

今回改善する問い合わせ対応の範囲

「問い合わせ対応」といっても、その範囲は広く、すべてを一度に改善しようとすると検討が複雑になります。

そこで、今回の対象範囲を明確にします。

対象とする問い合わせ

Gmailまたは問い合わせフォームから届く新規問い合わせの内

• 見積依頼
• 修理依頼
• 納期確認
• 資料請求
• 通常の施工後確認

今回は対象外とする業務

• 電話だけで完結する依頼
• クレーム対応
• 契約に関する判断
• 金額の確定
• 納期の確約
• 夜間・休日の緊急対応
• 法的判断や経営判断を伴う案件

今回の中心は、新規問い合わせの受付、分類、担当者への割り当てです。

ただし、担当者へ通知した時点で終わりにするのではなく、その後についても最低限、次の状態を追跡します。

• 誰が担当しているか
• 顧客から返信が来たか
• 技術確認が必要か
• 現在どの段階にあるか
• 対応が完了したか
• 完了後に何を保存するか

見積作成、訪問、修理作業など、案件そのものを最後まで完全自動化する想定ではありません。

現在の問い合わせ対応と課題

現在の問い合わせ対応は、次のような流れになっていると想定します。

1. 顧客からメールが届く
2. 事務担当者が受信箱を目視で確認する
3. 本文と添付資料を読む
4. 問い合わせ内容を分類する
5. 顧客情報や過去案件を確認する
6. 担当部署・担当者を判断する
7. 担当者へメールを転送する
8. 担当者が転送メールを再度確認する
9. 過去メールやGoogle Driveの資料を探す
10. 返信文を作成する
11. 必要に応じて現場担当者や上長へ確認する
12. 顧客へ返信する
13. 各担当者が資料や履歴を保存する

ここでは、事務担当者と案件担当者が同じメールや添付資料をそれぞれ確認しています。

また、担当者を判断する基準が明確でなく、事務担当者の経験や記憶に依存している状態です。

主な現状課題

• 通常メールに問い合わせが埋もれやすい
• 問い合わせの分類基準が統一されていない
• 担当者の判断が属人化している
• 過去メールや資料が複数の場所に分散している
• 対応状況を一覧で確認できない
• 完了条件が明確でない
• 担当者不在時の代替ルールがない
• 顧客とのやり取りが個人のメールや記憶に残りやすい

問題の原因を整理し、業務自体を見直す

業務改善では、問題と原因を分けて考える必要があります。

例えば、「担当者への通知に時間がかかる」という問題があったとします。

直接的な原因は、事務担当者が一件ずつメールを読み、経験をもとに担当者を判断していることです。

しかし、さらに背景を確認すると、次のような原因が考えられます。

• 問い合わせの分類基準がない
• 顧客と担当者の対応表が整備されていない
• 緊急度の判定基準がない
• 問い合わせを一覧管理する方法がない
• 担当者不在時の代替ルールがない
• 特定担当者の経験や記憶に依存している

この状態でAIに担当者を判定させても、基準となる情報やルールが整理されていないため、安定した結果を出すことは難しくなります。

そこで、AIを導入する前に、ECRSの考え方を使って現在の業務を見直します。

Eliminate｜なくせないか

• 事務担当者と案件担当者による同じ内容の二重確認
• 不要なメール転送
• 個人PCへの重複保存
• 同じ情報の複数台帳への入力

Combine｜まとめられないか

• 問い合わせ受付と管理表への登録
• FAQと返信テンプレート
• 顧客情報と担当者情報
• 案件情報と対応履歴
• 通知と必要資料へのリンク共有

Rearrange｜順番を変えられないか

• 最初に緊急度を確認する
• 担当者へ渡す前に必要な情報をまとめる
• 上長確認が必要な条件を早い段階で判断する
• 不足情報を確認してから担当者へ共有する

Simplify｜簡単にできないか

• 問い合わせ分類を選択式にする
• 担当者振り分け表を作成する
• 返信テンプレートを標準化する
• ステータスを統一する
• 保存場所とファイル名の付け方を統一する

AIを使わなくても改善できる部分を先に整理することが重要です。

改善後の業務方針とTo-Be業務

原因分析と業務の見直しを踏まえ、次の改善方針を設定します。

• 問い合わせを一覧で管理する
• 問い合わせ分類のルールを標準化する
• 担当者の振り分けルールを作成する
• 緊急案件・重要案件の判定基準を作成する
• 返信テンプレートとFAQを整備する
• 対応ステータスと完了条件を決める
• Gmailを正式なメール履歴として残す
• 問い合わせ管理表を進捗管理の起点にする
• AIは要約・分類候補・返信下書きに限定する
• 最終判断、顧客への送信、完了判定は人が行う

改善後の主な流れは次のとおりです。

1. 顧客から新規問い合わせを受信する
2. GASが未登録のメールスレッドを検出する
3. AIが内容を要約し、分類・緊急度の候補を作成する
4. 問い合わせ管理表へ登録する
5. 事務担当者へ新着通知を送る
6. 事務担当者が管理表を確認する
7. 事務担当者が案件担当者を選択する
8. GASが案件担当者へ通知する
9. AIが返信下書きを作成する
10. 案件担当者が内容を確認する
11. 必要な場合は技術担当者へ確認を依頼する
12. 案件担当者が顧客へ返信する
13. GASがメールスレッドの更新を管理表へ反映する
14. 案件担当者が完了を判断する
15. 必要な案件だけ、完了時にAIで要約して保存する

問い合わせ管理表を中心にした運用

改善後は、事務担当者がGmailの受信箱を一件ずつ巡回する働き方から、問い合わせ管理表を起点に処理する働き方へ変更します。

ただし、Gmailを一切見なくなるわけではありません。

管理表の役割

• 問い合わせを一覧で確認する
• 誰が担当しているかを確認する
• 現在のステータスを確認する
• 顧客から返信が来たかを確認する
• 技術確認の有無を確認する
• 完了した案件を確認する

Gmailの役割

• 顧客との正式なメール履歴
• 元の問い合わせ本文
• 添付ファイル
• 障害時にも残る原本情報

つまり、Gmailは正式な原本、問い合わせ管理表は業務の進捗管理という役割分担です。

問い合わせ管理表には、次のような項目を用意します。

項目	内容
受付番号	INQ-2026-0001など
受信日時	問い合わせを受信した日時
顧客名	顧客名・会社名
Gmailリンク	元メールスレッドへのリンク
AI要約	問い合わせ内容の要点
問い合わせ分類	見積、修理、納期、資料請求など
緊急度	高・中・低
不足情報	型番、設置場所、希望日など
案件担当者	顧客対応を進める担当者
技術担当者	技術確認を行う担当者
ステータス	新規受付、対応中、技術確認待ちなど
最終更新日時	Gmailまたは管理表の最終更新
Driveリンク	保存対象案件のフォルダ
完了時保存	保存不要、要約保存など

新しい問い合わせが登録されたら、GASが事務担当者へ通知します。

そのため、事務担当者がスプレッドシートを常に目視で監視し続ける必要はありません。

担当者通知と技術確認の流れ

事務担当者が管理表上で担当者を選び、ステータスを変更すると、GASが案件担当者へ社内通知メールを送ります。

事務担当者が改めて転送メールを作るのではありません。

案件担当者への通知内容

• 受付番号
• 顧客名
• 問い合わせ分類
• 緊急度
• AIによる問い合わせ要約
• 不足している情報
• 元Gmailへのリンク
• 問い合わせ管理表へのリンク
• 必要に応じてDriveへのリンク
• 顧客向け返信下書きの有無

案件担当者が内容を確認し、技術的な判断が必要だと考えた場合は、管理表で技術担当者を選択し、ステータスを「技術確認待ち」に変更します。

その変更をGASが検知し、技術担当者へ確認依頼を送ります。

技術担当者への通知内容

• 案件番号
• 顧客名
• 対象設備
• 現在分かっている症状
• 顧客からの希望
• 確認してほしい事項
• 元メールや添付写真へのリンク
• 回答希望日

すべての判断や会話を自動化するのではなく、通知と情報共有を自動化し、最終的な技術判断は人が行います。

最終的な判断結果は、管理表の技術確認欄へ記録します。

GAS・AI・ステータスの設計

今回の仕組みでは、GASの処理を大きく3つに分けます。

新規問い合わせ受付

GASが定期的に問い合わせ専用Gmailを確認します。基本案としては、5分ごとの確認を想定しています。新規受付処理では、次を行います。

• 未登録のメールスレッドを検出する
• 明らかな自動通知や対象外メールを除く
• 要確認条件に該当するメールへフラグを付ける
• メール本文や添付情報を取得する
• AIが要約・分類候補・緊急度候補を生成する
• 問い合わせ管理表へ登録する
• 「登録済」ラベルを付ける
• 事務担当者へ通知する

対応中案件の同期

登録済みのスレッドは、新規受付処理からは除外します。

ただし、顧客とのやり取りを把握する必要があるため、対応中案件の同期処理では引き続き確認します。

• 管理表から未完了案件を取得する
• 各案件のGmailスレッドIDを確認する
• メッセージ数や最終更新日時の変化を確認する
• 顧客からの返信があれば管理表を更新する
• 案件担当者へ通知する

完了時の保存処理

案件担当者が「完了処理待ち」に変更した案件を取得し、選択された保存方法に応じて処理します。

• 保存不要
• 要約のみ保存
• 要約＋添付ファイル保存

保存対象の場合は、関連メールスレッドを取得し、AIが案件全体を要約します。その後、Google Driveへ保存し、管理表にリンクを記録しステータスを「完了」にします。

ステータス管理

問い合わせ管理表では、主に次のステータスを使用します。

• 新規受付
• 要確認
• 担当者確認待ち
• 対応中
• 技術確認待ち
• 顧客返信待ち
• 顧客返信あり
• 訪問・見積調整中
• 完了処理待ち
• 完了
• 却下・対象外
• エラー

同じスレッドで返信された場合

GmailスレッドIDが同じであれば、既存案件への返信として扱います。

新しい案件を作成せず、既存の管理表を更新します。

新しいスレッドで送られた場合

顧客や担当者が新しいスレッドを作ると、GmailスレッドIDが変わり、管理表で追跡できなくなってしまいます。

その対策として、顧客向けメールの件名に案件番号を入れる運用にします。

例：「【INQ-2026-0001】空調設備の点検について」

案件番号と顧客メールアドレスが一致した場合は、既存案件への関連スレッド候補として扱えます。

一方、案件番号がない場合や顧客情報が一致しない場合は、自動で結合せず、事務担当者へ「既存案件の可能性あり」と通知し、人が確認します。

別の設備や別店舗の問い合わせを誤って同じ案件に結合しないためです。

完了時の記録とGoogle Driveへの保存

顧客と案件担当者が5往復、10往復とメールをやり取りした場合、すべてのメール本文を問い合わせ管理表へコピーする必要はありません。

役割を次のように分けます。

Gmail

顧客との正式なやり取りをすべて残します。

問い合わせ管理表

現在の状態と要点を残します。

• 最新ステータス
• 最終受信日時
• 最終送信者
• メッセージ数
• 最新の要点
• 次に必要な対応
• 担当者

Google Drive

必要な案件について、完了後の整理された記録を残します。

完了時には、案件担当者が保存方法を選択します。

• 保存不要
• 要約のみ保存
• 要約＋添付ファイル保存
• 要約＋関連資料保存

例えば、資料請求や営業時間の確認だけで終わった簡単な問い合わせは、Driveへの保存が不要な場合があります。

一方、修理、技術確認、見積、訪問対応など、今後の参考になる案件は保存対象とします。

AIによる完了時要約には、次の内容を含めます。

• 問い合わせ内容
• 顧客から得た情報
• 対応経緯
• 技術確認結果
• 最終的な対応内容
• 未解決事項
• 今後の参考情報

これをGoogleドキュメントなどに整理し、必要な添付資料とともにGoogle Driveへ保存します。

Google Workspaceの活用方法

改善後の業務フローを決めたうえで、Google Workspaceの各ツールを配置します。

ツール	活用内容
Gmail	問い合わせ受信、顧客対応、正式なメール履歴
Googleスプレッドシート	問い合わせ一覧、担当者、ステータス、KPI
Google Drive	必要な案件資料、完了時要約の保存
Googleドキュメント	FAQ、返信テンプレート、運用ルール
Google Apps Script	新着検知、管理表登録、通知、ラベル、進捗同期
GeminiなどのAI	要約、分類候補、緊急度候補、返信下書き、完了時要約

重要なのは、Google WorkspaceやAIの機能から業務を考えるのではなく、改善後の業務を実現するために必要なツールを配置するという順番です。

企業がMicrosoft 365、CRM、チケット管理システムなどを既に利用している場合は、それらを前提として設計します。

新しいツールを増やすことよりも、現在の環境を活かしながら、現場が継続して使える仕組みにすることを重視します。

PoCの設計と評価

PoCでは、問い合わせ対応全体を一度に自動化しません。今回のモデルケースでは、次の仮説を検証します。

AIによる要約・分類候補・返信下書きによって、問い合わせ対応の確認時間を削減しながら、一定の品質を維持できるかを見ます。

初期PoCの範囲

項目	想定内容
期間	4週間
対象	見積依頼、修理依頼、納期確認、資料請求
対象者	事務担当者と一部の案件担当者
AIの役割	要約、分類候補、返信下書き
人の役割	最終分類、担当判断、修正、送信
対象外	クレーム、契約、金額確定、納期確約
自動化範囲	管理表登録、担当者通知、下書き作成
中止条件	重大な誤分類、情報管理上の問題

PoCで確認するKPI

• 確認・分類時間
• 担当者通知時間
• AI分類候補と人の判断の一致率
• AI要約の修正率
• 返信下書きの利用率
• 返信文の修正時間
• 対応履歴記録率
• 重要案件の見落とし
• 担当者の使いやすさ

本記事は想定事例であるため、「分類時間を3分削減した」「一致率が84％だった」といった実績表現は使用しません。

実際には、「分類時間を短縮できるか」「分類一致率80％以上を目標例として検証する」といった形で、PoC前に評価条件を設定します。

PoC後は、必ず本導入するわけではありません。

検証結果によっては、次の判断も考えられます。

• 本導入へ進む
• 対象業務を限定して導入する
• 分類ルールを見直して再検証する
• AIは要約だけに限定する
• GASによる通常自動化だけ導入する
• AI導入を見送る

PoCは、導入を正当化するためではなく、導入可否を判断するために行います。

本導入・定着支援とまとめ

PoCで有効性が確認できた場合は、本番運用に向けた整備を行います。

本導入で行うこと

• 本番環境への実装
• 業務フローの確定
• ステータスと完了条件の確定
• 分類ルールの更新
• 担当者振り分け表の整備
• 返信テンプレートとFAQの改善
• 権限とアクセス設定
• エラー時の代替運用
• マニュアル作成
• 担当者への説明・教育

導入後の定着支援

• KPIの継続確認
• 利用状況の確認
• 誤分類や例外案件の確認
• 担当者からの意見収集
• ルールやテンプレートの更新
• 不要な入力や操作の削減
• 旧運用への逆戻り防止

新しい仕組みを作っても、現場が利用しなければ業務は改善しません。

導入後に「入力が面倒」「確認場所が増えた」「以前の方法の方が早い」と感じられると、担当者は元の運用へ戻ってしまいます。

そのため、実装だけでなく、実際の運用、教育、定着、継続的な改善まで設計する必要があります。

想定される効果

定量的な効果

• メール確認・分類時間の削減
• 担当者への通知時間の短縮
• 過去情報の検索時間の削減
• 返信下書き作成時間の削減
• 対応履歴記録率の向上
• 対応漏れや誤転送の削減
• 初回返信時間の短縮

定性的な効果

• 担当者不在時でも業務を回しやすくなる
• 新人や経験の浅い担当者でも対応しやすくなる
• 問い合わせ対応の判断基準がそろう
• 対応漏れを減らしやすくなる
• 返信品質を安定させやすくなる
• 管理者が案件の状況を確認しやすくなる
• 対応履歴やノウハウを社内に残しやすくなる

今回の事例で重要なのは、AIを使ったこと自体ではありません。

どの業務に問題があり、何が原因で、なぜその改善策を選んだのかを整理した点にあります。

AI導入の前には、業務全体を確認し、改善対象を選ぶ必要があります。

業務整理をせずに、AIを導入してしまうと「無駄な処理を”より早く、より複雑”に行うフロー」が出来上がってしまいます。

また、本来の業務の問題とは関係のないAI導入となってしまい、結局は使われなくなるということが多々起こります。

AIは、業務を整理する代わりになるものではありません。

業務を整理したうえで適切な範囲に使うことで、要約、分類候補、返信下書きなどのAIの強みを活かしやすくなります。