【Web制作業】保守問い合わせをAIで整理する方法｜症状と確認済み事項の分け方

保守問い合わせで症状と確認済み事項を分ける理由

Webサイトの保守問い合わせでは、顧客が困っている内容と、その原因を調べるために確認した内容を区別する必要があります。これらを一つの文章としてまとめると、実際には確認していない情報が確認済みとして引き継がれる場合があります。

顧客からの説明には事実と推測が混在しやすい

例えば、顧客からスマートフォンでお問い合わせフォームが送信できないという連絡が届いたとします。その際、昨日までは動いていた、サイトの更新が原因かもしれない、といった説明が一緒に含まれることがあります。

この場合、フォームが送信できないという申告は症状ですが、昨日まで正常だったという説明は顧客からの申告情報です。また、サイトの更新が原因という説明は、調査によって裏付けられていない限り原因の仮説にすぎません。

AIへ問い合わせ文をそのまま短く要約させるだけでは、この違いが分からなくなる場合があります。

症状と確認済み事項では役割が異なる

症状は、現在どのような問題が起きていると報告されているかを示す情報です。一方、確認済み事項は、担当者が実際に行った確認作業と、その結果を示す情報です。

確認済み事項には確認の根拠も残す

確認済み事項として記録する場合は、確認したという言葉だけで終わらせず、誰が、いつ、どの環境で、何を確認し、どのような結果だったかを残します。

例えば、PCでは正常に表示されたという記録だけでは、顧客が確認したのか、保守担当者が確認したのか分かりません。確認者や環境を明確にすることで、次の担当者が同じ確認を繰り返す必要があるか判断しやすくなります。

保守問い合わせを整理するためのテンプレート

保守問い合わせをAIで扱う場合は、最初に共通の整理項目を決めることが重要です。毎回異なる形式でまとめるのではなく、受付から引き継ぎまで使えるテンプレートを用意すると、担当者間で情報を共有しやすくなります。

基本となる受付・整理項目

モデルケース：フォームの不具合に関する問い合わせ

以下は説明のために仮定したモデルケースです。実際の顧客対応や導入実績を示すものではありません。

この文章には、現在の症状、以前の利用状況、別の環境に関する情報が含まれています。しかし、保守担当者が実際に確認した内容は記載されていません。

ここで重要なのは、PCでは送信できるという情報を、担当者が確認済みの事実として扱わないことです。顧客が聞いた情報であるため、確認者や確認条件を調べる必要があります。

また、AIがフォームのプラグインやサーバー設定を原因と推測しても、それだけで原因を確定してはいけません。

確認済み事項を更新する際の記録方法

担当者が実際に調査した後は、確認内容を追加します。作業記録は後から見返せる形式にしておくと便利です。

実施していない作業については、確認済みと記載せず、未実施または未確認として管理します。

問い合わせの分類と対応優先度の判断方法

AIによる整理では、問い合わせの内容を分類するだけでなく、対応の優先順位を検討するための情報を抽出できます。ただし、最終的な優先度は影響範囲、業務への影響、契約条件などを踏まえて人が判断する必要があります。

問い合わせの種類を分ける

Webサイト保守の問い合わせは、必ずしもすべてが障害ではありません。ページ更新の依頼と、サービスが利用できない障害では、必要な担当者や確認内容が異なります。

優先度は影響と緊急性を基準に判断する

文章に至急と書かれているかどうかだけで、対応優先度を確定することは適切ではありません。サイトの重要機能が停止しているか、利用者に影響しているか、セキュリティ上の問題が疑われるかなどを確認します。

これは分類を考えるためのモデル基準です。実際の連絡方法、対応期限、営業時間外の扱いなどは、自社の保守契約と運用ルールに合わせて設定してください。

保守問い合わせをAIで整理する6つの手順

保守問い合わせのAI活用は、最初から受付システム全体を自動化する必要はありません。まずは受信した問い合わせ文を一定の形式に整理し、担当者が確認するところから始める方法が現実的です。

ここでは、実際の保守業務へ組み込むための手順を紹介します。

1. 問い合わせの原文と関連情報を集める

   メール、チャット、問い合わせフォームなどから届いた内容を集めます。対象サイト、対象ページ、受付日時、過去の対応履歴なども、利用可能な範囲で確認します。AIへ渡す前に機密情報や個人情報の取り扱いを確認してください。

2. 緊急対応の対象でないか確認する

   サイト停止や情報漏えいの疑いなど、緊急連絡が必要な内容を先に確認します。緊急対応に該当する場合は、AIでの整理を待たず、社内のルールに沿って対応を開始します。

3. AIへ分類項目を指定して整理する

   症状、顧客申告、確認済み事項、未確認事項、原因仮説、次の対応案に分けるようAIへ指示します。入力にない情報を補完しないことや、確認していない内容を確認済みとしないことも明示します。

4. AIの整理結果を元資料と照合する

   元の問い合わせ文や実際の作業記録とAIの整理結果を比較します。症状の意味が変わっていないか、確認者が正しいか、未実施の作業が完了扱いになっていないかを確認します。

5. 担当者と次の確認事項を決める

   整理結果をもとに、顧客への追加質問、再現確認、設定調査などの対応を決めます。技術的な調査や契約範囲の判断が必要な場合は、それぞれの責任者へ確認します。

6. 対応履歴を更新して引き継ぐ

   受付IDに紐づけて、確認済み事項、未確認事項、担当者、次の対応を保存します。調査が進んだら記録を更新し、古い情報と新しい確認結果が混在しないようにします。

そのまま使えるAI整理用プロンプト

生成AIへ問い合わせ内容を整理させる際は、出力形式と禁止事項を具体的に指定します。次のプロンプトは、保守問い合わせの整理に使うためのひな形です。

AIに入力する情報を統一する

プロンプトだけを共通化しても、担当者が入力する情報が異なると、整理結果にも差が出ます。問い合わせ本文と確認作業を区別した入力形式を用意してください。

入力項目が不明な場合は空欄や未確認として扱います。例えば、問い合わせ文に発生時刻が書かれていない場合、受付時刻を障害の発生時刻として補完しないよう注意します。

引き継ぎ前の確認チェックリスト

整理した問い合わせを別の担当者へ引き継ぐ際は、次の項目を確認します。

AIを利用する際の情報管理と運用上の注意点

Webサイトの保守問い合わせには、顧客情報、管理画面の情報、アクセス記録などが含まれる場合があります。AIで整理できる業務でも、すべての情報をそのまま外部サービスへ入力してよいわけではありません。

利用するAIツールの契約条件、管理設定、自社の情報管理ルールを確認したうえで、入力範囲を決めてください。

個人情報や認証情報をそのまま入力しない

問い合わせメールには担当者名、メールアドレス、電話番号などが含まれることがあります。また、技術的な問い合わせには、管理画面の情報やアクセス記録が添付されることもあります。

AIで文章を分類するだけであれば、こうした情報をすべて入力する必要がない場合があります。入力前に不要な情報を除外することが重要です。

技術的な原因調査はAIの整理結果と分ける

AIは問い合わせ文から原因の候補を挙げることができますが、実際のサーバー設定やプログラムの状態を確認しているとは限りません。

例えば、フォームが動かないという問い合わせから、JavaScriptの問題、フォーム設定の問題、通信環境などを候補として提示することはできます。しかし、実際の調査なしに原因を断定することは適切ではありません。

原因の候補を一覧化する用途と、実際に原因を特定する調査作業は分けて考えてください。

保守契約の対象範囲を確認する

保守問い合わせの内容によっては、既存の保守契約に含まれる作業と、追加見積もりが必要な作業が混在することがあります。

AIが修正依頼を通常の保守作業として分類した場合でも、契約書や保守範囲を確認しないまま作業を確約することは避けます。

よくある失敗例と対策

AIを保守問い合わせの整理へ導入する際は、要約の読みやすさだけを評価しないことが重要です。実際の対応に必要な情報が欠けていないか、誤った確認結果が含まれていないかを確認する必要があります。

失敗1：問い合わせ文を短く要約するだけで終わる

問い合わせの概要が分かっても、症状、確認済み事項、未確認事項が分かれていなければ、担当者は再び原文を読み直す必要があります。

単なる要約ではなく、指定した管理項目ごとに整理するプロンプトを使用します。

失敗2：顧客が確認した内容を担当者の確認済み事項にする

顧客から他の端末では動いているという説明があった場合、AIが動作確認済みと短くまとめてしまう可能性があります。

確認者が誰なのかを明確にし、担当者が実際に確認していない場合は顧客申告として分類します。

失敗3：AIが挙げた原因を確定した原因として扱う

生成AIが技術的にもっともらしい原因を挙げた場合でも、その原因が実際に発生しているとは限りません。

原因仮説は別の項目で管理し、調査や検証によって裏付けられるまで確定事項として扱わないようにします。

失敗4：対応済みと確認済みを混同する

問題の存在を確認したことと、修正作業を完了したことは異なります。表示不具合を再現できた段階で対応済みとすると、必要な修正や検証が残っていても完了扱いになるおそれがあります。

調査中、対応中、顧客確認待ち、完了など、作業の状態を別項目で管理します。

失敗5：緊急性の高い問い合わせを通常のAI処理に回す

サイト停止や情報漏えいの疑いがある問い合わせを、通常の文章整理作業の完了まで待たせると、初動対応が遅れるおそれがあります。

緊急連絡の対象をあらかじめ決め、受付段階で担当者が判断できる運用を整えてください。

まとめ

Web制作の保守問い合わせをAIで整理する際は、文章を短くすることよりも、担当者が確認した事実と未確認の情報を区別できる状態をつくることが重要です。

問い合わせ内容の分類と記録形式を統一すると、次に確認することや、別の担当者へ引き継ぐ内容を整理しやすくなります。

最初からすべての問い合わせを自動化する必要はありません。まずは日常的に発生する保守問い合わせの整理から始め、担当者が確認しやすい形式をつくることが実務への導入の第一歩になります。