「以前も同じ問い合わせがあったはずなのに、答えが見つからない」「詳しい担当者が不在だと、調査を最初からやり直している」。対応履歴が増えても、次の仕事で使えなければ、会社の知識としては活かし切れていません。
過去の問い合わせを役立てるには、履歴を保存するだけでなく、再利用できる内容を選び、適用条件と根拠を確認し、必要な場面で探せるようにすることが大切です。その土台があれば、AIによる要約や回答案の作成も検討しやすくなります。
この記事では、問い合わせの対応記録をFAQへ整理する手順、公開・更新の運用、AI回答支援の始め方を、図解・確認表・記入例で解説します。中小企業のサポート窓口や業務担当者が、少ない件数から取り組める方法をまとめました。
対応履歴があるのに、会社の知識として使えないのはなぜか
問い合わせの記録は、顧客とのやり取りを残すために書かれます。そのため、途中の仮説や、顧客固有の条件、解決前の案内なども含まれます。長い履歴をそのまま検索しても、何が有効な回答だったのかを読み直す必要があります。
「設定を変更して解決」とだけ書かれていると、どの設定を、どの条件で変更したのかが分かりません。反対に、メールをすべて残していても、結論と適用範囲が見つからなければ、別の担当者が使うには時間がかかります。
必要なのは、対応した事実を残すことと、次の担当者が再利用できる説明を作ることの両方です。日々の対応から有用な内容を選び、確認・更新する流れを設けましょう。
- 対応結果を残す症状・条件・実施したこと・確認できた結果を記録。
- 候補を選ぶ繰り返す質問や、調査に手間がかかった内容を選ぶ。
- FAQへ整理適用条件と根拠を確認し、利用する範囲を決める。
- 使って改善見つからない言葉や不足した条件を、内容へ戻す。
対応履歴・FAQ・回答テンプレートは、役割を分ける
すべての情報を同じ知識として扱うと、特定の顧客だけに有効だった案内が、一般的な回答として使われることがあります。まず、何のために残す情報かを区別します。
| 情報 | 主な目的 | 利用するときの確認 |
|---|---|---|
| 対応履歴・過去事例 | ある問い合わせで、何を確認し、どう対応したかを残す | 今回と条件が同じか。解決内容と推測、個別対応を区別する |
| FAQ・手順の知識 | 一定の条件で再利用できる質問・回答・手順を整理する | 対象、適用条件、確認日、現在利用できる版を確認する |
| 回答テンプレート | 受付連絡や追加確認など、文章の型を用意する | 宛先、状況、日付、約束した内容を今回の問い合わせに合わせる |
FAQは、必ずしも「よくある質問」だけに限りません。発生頻度は低くても、調べ方を残す価値が高い内容は、手順や判断の知識として整理できます。一方、文章が丁寧な回答テンプレートでも、技術的な根拠や現在の条件まで保証するものではありません。
例えば「調査中であることを伝える文面」はテンプレートに向きます。「ある環境でエラーが解消した経緯」は過去事例として残し、再利用できる条件を確認してからFAQへ整理します。
FAQにする問い合わせは、件数と再利用の価値から選ぶ
最初から過去の問い合わせを全部整理しようとすると、日常業務の負担が大きくなります。まずは一つの製品や業務領域に絞り、現在も役立つ候補を選びましょう。
- 同じ内容を複数の担当者が何度も回答している。
- 必要な確認項目が決まっており、調査の入口をそろえたい。
- ベテランに聞かないと分からず、調査のやり直しが多い。
- 対応の順番や適用条件を明確にすれば、別の担当者も使える。
- 誤った案内をしやすく、使ってよい条件と使わない条件を整理したい。
「完了した」だけで、正しい解決方法と判断しない
問い合わせが完了になった理由には、解決、取り下げ、重複、返答を得られず終了などがあります。FAQ候補を選ぶときは、実際に何が確認できたかを読み直します。
解決できた事例でも、対象の製品や版が古い、顧客だけの設定がある、複数の対処を行って有効な手順が分からない、といった場合があります。そのまま一般化せず、追加の確認が必要な候補として残しましょう。
同じ質問のFAQが複数ある場合は、新しい記事を増やす前に、既存のFAQを更新できないか確認します。条件が異なるなら、その違いを見出しや適用範囲へ明示します。似た質問をまとめすぎて、異なる条件の回答が混ざらないようにすることも大切です。
再利用できるFAQには、回答だけでなく適用条件と根拠を残す
別の担当者が使うためには、答えの文章に加え、「いつ使ってよいか」「何を確認すべきか」「何をもとに判断したか」が必要です。次の項目を参考に、自社で必要なものを選んでください。
| 項目 | 残す内容 | 目的 |
|---|---|---|
| 質問・見出し | 顧客が困る場面、症状、操作目的 | 担当者が自分の質問と対応付けやすくする |
| 対象・適用条件 | 製品、版、環境、権限、設定など必要な条件 | 別条件へ誤って当てはめないようにする |
| 確認すること | 回答前に必要な情報と、判断の分かれ目 | 情報不足のまま手順を案内しない |
| 回答・手順 | 結論、操作や確認の順番、注意点 | 今回の状況へ合わせて利用する |
| 結果と次の対応 | 期待する結果、うまくいかない場合の相談先 | 手順の後に何を確認するかを明確にする |
| 根拠 | 確認した資料、仕様、検証記録、元の問い合わせ | 説明の根拠をたどり、見直しに使う |
| 管理する情報 | 作成・確認担当、確認日、見直し条件、版、利用状態 | 古い情報と現在利用できる情報を区別する |
| 共有・利用範囲 | 社内、特定の担当者、特定顧客向け、一般公開など | どこまで案内・共有してよいかを判断する |
一つのFAQでは、できるだけ一つの質問や判断を扱います。複数の問題が入っている場合は、共通する入口と個別手順を分け、必要な記事へ案内する構成も考えられます。
また、「この操作で必ず直る」と断定するより、対象条件、確認結果、該当しない場合の次の確認を記録します。原因が確定していない事例では、仮説を確定した仕様として書き換えないようにしましょう。
下書き・内容確認・利用開始・更新を、仕事の中へ組み込む
対応担当者だけに完成したFAQの作成を求めると、日常業務の中では後回しになりがちです。対応中や完了時に候補を残し、詳しい人が内容を確認する、という分担を考えましょう。
下書きには未確認事項があって構いません。ただし、未確認のまま現在利用できるFAQと同じ場所へ出さないことが大切です。確認する人、必要な修正、利用開始を判断する人を決めます。
今、その内容を回答の根拠として使ってよいかを管理します。
誰が参照でき、どこまで顧客へ案内してよいかを管理します。
更新は、日付だけでなく変更のきっかけを決める
製品の更新、仕様変更、画面変更、手順が使えなかったとの報告などを、見直しのきっかけにします。確認日が新しいだけで有効と判断せず、対象となる版や条件まで確認しましょう。
古いFAQを利用停止にした場合は、代わりの記事や相談先へ案内できるようにします。検索用のデータやAIの参照用データを別に持つ構成では、元の記事を更新しただけで、検索結果にも反映されるかを確認します。更新・削除・利用停止が、参照先まで届く仕組みが必要です。
アイプランナーのFAQ・過去事例レコメンドの紹介では、解決済みの問い合わせからFAQの下書きを作り、内容を確認して利用する流れが説明されています。候補を作ることと、正式に使う知識として確認することを分けるのが、運用を考える際の要点です。
必要なFAQを探せるよう、顧客の言葉と対象条件を整える
内容が正しくても、検索する言葉と見出しが合わないと見つかりません。社内だけで使う機能名に加え、顧客が使う表現、よくある言い換え、エラーの表記、対象の製品や分類を整理します。
例えば、社内では「帳票」と呼んでいても、顧客は「見積書」「PDF」「印刷」と表現するかもしれません。検索される言葉を把握し、質問文や関連語へ反映します。ただし、検索に引っ掛けるためだけに無関係な言葉を増やす必要はありません。
関連度が高い候補と、正しい回答は同じではない
候補の順位やスコアは、確認する順番を考える材料です。正解である確率や、今回の顧客へ案内してよい保証とは区別します。見つかったFAQの対象条件、根拠、現在の利用状態を開いて確認できることが大切です。
検索では、確認済みFAQと過去の対応事例を区別して表示すると、候補の意味が分かりやすくなります。過去事例にしか情報がない場合は、今回へ適用できるかを確認し、必要なら専門担当へ相談します。
何も見つからなかった場合も、改善の材料になります。質問の表現、対象、検索した語、既存FAQに足りなかった条件を残すと、新規FAQを作るか、既存記事を直すかを判断できます。
AI活用は、検索した根拠から回答案を作るところから始める
FAQ整備とAI活用は、別々の取り組みとは限りません。担当者が使える知識を整理し、今回の問い合わせに関係する資料を参照させることで、回答案や確認事項の作成を支援する設計が考えられます。
参考となる仕組みに、検索拡張生成（RAG）があります。AWSの説明では、回答生成時に関連する知識を取得して使う方法が紹介されています。モデルそのものを再学習させることと、回答時に資料を参照させることは別です。本記事では概念として紹介しており、vtplusが特定の検索方式や基盤を使うと断定するものではありません。
- 質問を整理困っていることと、対象・条件・不足情報を確認。
- 根拠を選ぶ使ってよいFAQや事例を選び、適用条件を確認。
- 回答案を作る選んだ根拠から文章と追加確認事項を整理。
- 人が確認して利用根拠、約束、公開範囲、顧客の状況と照合する。
| 作業 | 支援を検討できる内容 | 担当者が確認すること |
|---|---|---|
| 候補を探す | 問い合わせに関連するFAQや事例を並べる | 今回の条件に合うか、利用できる知識か |
| 内容を整理する | 症状・確認事項・未確認の点を要約する | 事実が抜けたり、推測が事実に変わったりしていないか |
| 回答案を書く | 根拠をもとに、今回の顧客へ伝える文章を整える | 根拠にない操作・価格・納期・約束が加わっていないか |
| 知識を整える | 対応記録からFAQの下書きを作る | 適用条件、根拠、機密情報、確認担当と公開範囲 |
アイプランナーのAI回答支援の公開紹介では、担当者がFAQ・解決済み事例を選び、その根拠を使って回答案を作成し、確認・編集して利用する流れが説明されています。顧客へ自動送信する機能とは分けて紹介されています。
根拠が不足する場合は、確認すべきことを返す
AIへは、答えを必ず作ることより、根拠にあることと、分からないことを区別させる方針を置きます。資料に答えがない、版が違う、複数の資料が食い違う場合は、追加質問や専門担当への確認に進めます。
参照元が表示されていても、その資料が本当に回答を裏付けるかは確認が必要です。また、AIが作った文章を未確認のままFAQへ戻すと、誤りが次の回答の根拠になる場合があります。生成した下書きも、通常の内容確認を経てから利用する知識へ加えましょう。
参照できる情報と、AIへ送る情報、顧客へ見せる情報を分ける
社内で閲覧できる過去の問い合わせには、顧客固有の設定や契約条件、個人の連絡先、社内調査の内容が含まれることがあります。担当者が読めることと、その内容を別の顧客へ案内してよいことは同じではありません。
FAQへ整理する際は、一般化できる知識と、元の事例だけに残す情報を分けます。社名を消すだけで十分とは限らず、固有の構成、識別番号、添付画面、特別条件なども確認します。
- 検索・参照：利用者の権限に沿った対象だけを取り出せるか。
- AIへの送信：必要な質問と根拠を選び、不要な本文や添付まで送らないか。
- 回答の利用：社内向けの内容や、別顧客の情報が文章へ混ざらないか。
- 保存・更新：生成結果や参照履歴の扱い、利用停止した知識の反映を確認できるか。
外部AIサービスを利用する場合は、送信する情報、保存や利用の条件、接続設定、運用上の確認範囲を整理します。「検索するだけの処理」と「外部サービスで文章を生成する処理」で、情報の流れが同じとは限りません。
回答生成に使う問い合わせ本文や資料は、参照するデータとして扱います。文中の記述をきっかけに、承認手順や公開範囲を変えたり、関係のない情報を送ったりしない設計も確認します。vtplusでの具体的な機能・提供構成・AI連携の条件は、利用環境に合わせて相談してください。
少数のFAQと質問例で試し、見つかるか・正しく使えるかを確認する
最初は一つの製品や業務を対象にし、内容を確認できる件数から始めます。FAQの件数を増やすことより、実際の質問に対して必要な知識が見つかり、条件に合う案内へつながるかを確認しましょう。
- 対象を決める一つの業務と、確認できるFAQ候補を選ぶ。
- 知識を整える条件・根拠・確認日・利用範囲をそろえる。
- 質問例で確かめる言い換え、情報不足、古い資料、権限差も確認。
- 結果から直す検索語、FAQ本文、参照条件、確認手順を見直す。
| 質問・状況の例 | 確認すること | 期待する扱い |
|---|---|---|
| FAQと同じ内容 | 必要な記事が見つかり、根拠に沿って案内できるか | 条件を確認し、根拠にない情報を足さない |
| 顧客の言い換え | 社内用語と違っても、関連する候補へたどれるか | 検索語・質問文の不足を見つけて直す |
| 対象や情報が不足 | 製品・版・環境が不明でも、結論を断定しないか | 必要な追加質問を提示する |
| 根拠なし・資料の食い違い | 裏付けがない回答や、都合のよい資料選びをしないか | 不足や相違を示し、確認先へつなぐ |
| 古い記事・利用停止・権限外 | 参照対象と生成結果へ正しく制限が反映されるか | 利用できない知識を回答の根拠へ出さない |
速さだけでなく、修正と根拠の確認も評価する
検索にかかった時間、役立つ候補が見つかったか、回答案の修正が必要だった箇所、追加確認が適切に出たかを記録します。比較する質問の範囲と条件をそろえ、単に生成が速いことを回答品質の改善と同じには扱いません。
検索結果が出ない場合は、知識不足か、言葉や分類の問題かを分けます。回答案が不適切なら、選んだ根拠、適用条件、質問の不足、生成の指示を順に確認します。モデルの変更だけに頼らず、FAQと運用も一緒に見直しましょう。
FAQの記入例と、コピーして使えるテンプレート
以下は架空の問い合わせから知識を整理する例です。実際の製品仕様や、そのまま使える解決手順ではありません。顧客固有の事例から、再利用できる確認の入口を作る考え方としてご覧ください。
例：帳票出力時の問い合わせを、確認用FAQへ整理する
元の記録：A社専用の帳票で出力エラーが発生。個別設定を確認して対応したが、その設定は他社と同じとは限らない。
FAQの質問：帳票出力時にエラーが出たとき、最初に何を確認しますか。
適用範囲：窓口で状況を聞き取るための社内向け確認項目。特定の原因や解決操作を断定するものではない。
確認内容：対象帳票、製品と版、操作手順、発生時刻、表示された内容、影響する利用者を確認する。
次の対応：既知の事例と条件が一致するかを担当者が確認し、分からなければ専門担当へ依頼する。
根拠と管理：元の事例と確認資料へ関連付け、確認担当・日付・見直し条件を記録する。
コピーして使うFAQテンプレート
質問・見出し／顧客が使う関連語：
対象製品・版・環境／使ってよい条件：
使わない条件／回答前に確認すること：
結論／確認・操作の手順：
期待する結果／該当しない場合の次の対応：
根拠資料／元の事例／確認できた結果：
下書き・確認・利用の状態／共有・公開範囲：
作成担当／確認担当／確認日／版：
見直すきっかけ／更新・利用停止時の案内先：
AI回答支援へ渡す指示の例
今回の質問と、利用を許可した根拠資料を区別して読み、確認できた事実、追加で必要な情報、回答案、参照元を整理してください。
根拠にない原因・操作・価格・期限は補わず、不足する点や資料の食い違いを示してください。回答案と根拠の対応が分かるようにし、顧客へ出せない情報は回答文へ含めないでください。
※この指示だけで、情報の送信範囲やアクセス権限を制御できるわけではありません。参照対象の選択・権限・利用前の確認は、システムと運用で別に設けます。
よくある質問
FAQをすべて整えてからAIを導入すべきですか？
全部を完成させる必要はありません。一つの業務で確認できる知識を用意し、検索と回答案を試す方法があります。未確認の記事を正式な根拠と混ぜず、対象範囲を絞って進めましょう。
過去の問い合わせを、そのままAIへ渡せばよいですか？
個別条件や途中の仮説、不要な個人情報が含まれる場合があります。今回に必要な情報を選び、利用条件と送信範囲を確認します。完了した履歴でも、一般的な正解とは限りません。
FAQを参照させることは、AIを再学習させることですか？
回答時に資料を参照する仕組みと、モデル自体の再学習は別です。利用するサービスの処理方式と情報の扱いを確認してください。FAQを登録しただけで、AIが常に最新の内容を参照するとは限りません。
公開済みのFAQなら、誰にでも案内してよいですか？
内容の確認状態と公開範囲を分けて確認します。社内用や特定顧客向けの知識もあるため、利用中のFAQであっても、一般公開や別顧客への案内が可能とは限りません。
AIが作ったFAQを、そのまま公開できますか？
下書きとして扱い、対象条件、根拠、手順、個人情報、確認担当と公開範囲を確認します。文章が自然でも、事実や適用条件が正しいことの保証にはなりません。
vtplusを検討するなら、繰り返し調べている質問から整理する
過去の問い合わせを会社の知識に変えるには、対応結果から再利用する内容を選び、条件と根拠を確認し、必要な場面で見つけられるようにすることが大切です。利用後の不足や変更もFAQへ戻し、日常の対応と更新をつなぎましょう。
vtplusで検討する際は、よくある質問、現在のFAQや対応記録、検索で困る言葉、確認担当、共有・公開したい範囲を整理すると、相談が具体的になります。AIを使う場合も、どの知識を根拠にし、誰が確認して利用するかから考えていきましょう。
参考情報
- アイプランナー：FAQ・過去事例レコメンド（候補の参照とFAQ下書き）
- アイプランナー：AI回答支援（根拠を選び、回答案を確認して利用する流れ）
- AWS：RAG（検索拡張生成）とは（回答生成時に知識を参照する概念）