AIでFAQを作る方法｜問い合わせ履歴から整理する流れ

AIでFAQを作るなら、問い合わせ履歴から「よくある質問の候補」を集める工程と、承認済み情報から「回答を書く」工程を分けます。問い合わせ件数だけで優先順位を決めず、誤解の影響、料金・契約への影響、問い合わせ先で解決できなかった理由も見ます。入力前には個人情報や契約情報を除き、FAQの回答には根拠となる最新資料、責任者、見直し条件を付けます。

先にFAQの使い道と対象読者を決める

FAQは、社外のお客様向け、社内担当者向け、販売代理店向けなど、誰が読むかで質問と回答の粒度が変わります。対象者を決めずに問い合わせをまとめると、顧客向けに出せない社内手順や、特定契約だけに当てはまる回答が混ざることがあります。まずFAQの目的、公開範囲、利用場所、回答責任者を決めます。

次のような一覧が出発点になります。

• 対象者と利用場面。

• FAQへ含めてよい問い合わせの種類。

• 対象期間と対象チャネル。

• 公開できない顧客別・契約別の内容。

• 回答を承認する部署と、更新を受け取る窓口。

• FAQで回答しない場合の問い合わせ先。

問い合わせ履歴を別目的に使う場合は、利用目的と社内規程を確認します。個人情報保護委員会のFAQは、利用目的を本人が合理的に予測できる程度に具体化する考え方を示しています。履歴をFAQに加工するだけで適法性が自動的に決まるわけではありません。利用環境、委託先やAIサービスの契約、組織の規程を担当者が確認してください。

入力データを小さく、安全に整える

収集した問い合わせをそのままAIへ渡さず、FAQ化に必要な部分だけ残します。氏名、電話番号、メール、住所、会員番号、注文番号、個別の契約条件などが不要なら除去します。置換後も、地域・日付・状況の組合せから個人や案件が分かる場合があります。匿名化したつもりで済ませず、データ管理者がサンプルを確認します。

入力用のテーブルには、質問本文だけでなく、個人・案件識別子を除いた分類用の短い要約を作ります。分類用データと問い合わせ元の記録は分離し、アクセス権限を必要な担当者に限定します。元データの保存期間や削除は組織のルールに従い、AIへ送ったデータがサービス側にどう扱われるかも契約・設定から確認します。PPCは生成AI利用に際して、利用目的の達成に必要な範囲で個人情報を扱うよう注意を促しています。

元情報に誤記がある場合や、苦情・健康情報など通常のFAQへ出せない内容が含まれる場合は、自動分類の対象から外します。質問の表現が複数でも同じ意味か判断できないときは、「重複候補」にして人が確認します。AIへ意味の近さだけで統合させると、違う契約条件の質問が一つにまとまることがあります。

質問候補を「頻度」と「影響」で見る

問い合わせを分類した後、件数を数える前に分類の粒度をそろえます。「ログインできない」と「パスワードを忘れた」は関連していても、必要な回答が違うことがあります。カテゴリ名、まとめる条件、分ける条件を例付きで決め、AIのクラスタ結果を担当者が確認します。

優先順位は件数だけで付けません。たとえば、以下の二軸でレビューできます。

表は横にスクロールできます

質問候補	発生頻度	間違った回答の影響	扱い
操作方法	多い	小〜中	手順FAQ候補
請求・解約	中	大	最新規約・契約確認後に公開
安全上の問題	少ない	大	FAQだけで済ませず専用窓口へ
個別契約の例外	少ない	大	公開一般回答にせず担当へ転送

これは優先づけの例で、実際の影響区分は組織の業務に合わせて定めます。「質問数が少ないから不要」とは限りません。法的・金銭的影響や安全性が関わる質問は、公開前に責任部署が回答できるか確認します。

回答の根拠と適用条件を付ける

FAQの回答は、問い合わせ文だけから生成しません。公式ヘルプ、利用規約、契約条件、承認済みマニュアルなど、回答の正本となる資料を指定します。回答の各主張に、参照資料名、章・URL、確認日、適用するプラン・地域・対象者を付けます。資料間で内容が食い違う場合は、AIに多数決させず、どの資料を優先するか責任者へ確認します。

回答表は次の構造にできます。

• 質問：利用者が実際に使う自然な表現。

• 短い結論：最初の一、二文で回答する。

• 手順・条件：操作順、対象、必要な条件。

• 根拠：承認済み資料と該当箇所。

• 対象範囲：プラン、地域、契約、バージョン。

• 未確認点：担当者へ確認する内容。

• 返信先：FAQで解決しない場合の窓口。

• 更新担当・期限：次に内容を見直す条件。

根拠資料に答えがない場合は、AIに一般知識で埋めさせず「回答確認中」とします。料金や契約など、誤回答の影響が大きい項目は、FAQの公開承認者が原資料へ戻って確認します。

文章に整える前のプロンプト

あなたは問い合わせ履歴の分類とFAQ下書きを支援します。問い合わせ内の個人情報を再掲せず、入力された承認済み資料だけを回答根拠にしてください。

各質問を「候補質問」「想定対象」「根拠資料」「適用条件」「回答案」「未確認事項」に分けてください。

根拠が見つからない質問は回答を作らず「担当確認」としてください。異なる契約・商品・地域の条件をまとめないでください。

件数や優先順位を出す場合は、集計対象期間、対象チャネル、重複処理のルールを明記してください。

出力は公開版ではなく担当者レビュー用の下書きです。個別案件の回答が混じっていないかも示してください。

入力：［承認済みの分類データと回答ソース］

この指示でも、モデルが「根拠資料の文言」と「推測」を誤って混ぜることはあります。出力へ出典欄があるかだけで安心せず、実際に出典の該当箇所が回答を支えるかを人が確認します。

公開前QAと更新運用

公開前には代表的な質問を実際の利用者に見せ、質問文から必要なFAQを見つけられるか確認します。回答の結論が先にあるか、条件が抜けていないか、例外ケースを誤って一般化していないかも確認します。検索語が違う同一質問を複数登録して見つけやすくする場合は、主FAQと別表現を関連づけ、回答の重複管理を決めておきます。

• 回答中の価格・日付・機能が参照元と同じか。

• プランや契約条件が対象読者と合っているか。

• 問い合わせ固有の情報が混入していないか。

• 問い合わせ履歴からの件数が説明されているか。

• FAQで回答できないときの連絡先があるか。

• 更新責任者と見直し条件が設定されているか。

• 古い回答を差し替えたとき、利用中のヘルプ面にも反映されるか。

仕様変更、規約改定、障害、料金変更などを更新トリガーとして決めます。固定の更新周期だけでは、重大な変更後に古い答えが残ることがあります。変更担当がFAQ ownerへ知らせる経路を作り、公開日時、版、承認者を記録します。

うまくいかないときに戻す場所

似た質問が誤って一つに統合された場合、生成指示だけを強めるのではなく、カテゴリの分割条件や契約区分を確認します。FAQに存在しない回答が出た場合は、質問データではなく承認済みの回答ソースが不足している可能性があります。更新日が古い回答は、文章生成をやり直すより先に正本を特定します。問い合わせ件数が不自然なら、集計期間、二重投稿、チャネルの欠落、bot問い合わせを確認します。

公開後も、利用者が同じ質問を繰り返す、回答後に窓口へ再連絡する、古いページが検索で見つかるといった状況を記録します。これらはFAQの構造や回答内容を直す手掛かりですが、単純にFAQの数を増やす根拠ではありません。どの作業を減らしたいのか、利用者がどこで迷うのかを確認してから修正します。

問い合わせをFAQ項目へ変える例

たとえば、問い合わせ記録に「請求書をもう一度送ってほしい」「請求書の宛名が違う」「経理に出す書類が見つからない」という文面があったとします。これらは同じ「請求書」カテゴリでも、回答が一つとは限りません。再送方法、宛名変更の可否、書類の保存場所は別の作業です。AIにはまず意味が近い問い合わせをまとめさせ、次に「回答が同じ正本で説明できるか」を人が確認します。契約者ごとの情報や個別の請求内容はFAQへ移しません。

質問候補の優先順位は、件数と影響を別々に見ます。件数は対象期間・問い合わせ経路・重複処理の影響を受けるため、単純な順位が利用者の困り度とは限りません。料金・解約・安全に関わる項目、誤答すると損失が大きい項目、同じ説明を繰り返している項目を分けてレビューし、公開の順番を決めます。

表は横にスクロールできます

候補	先に確かめること	FAQ化の判断
同じ操作質問が複数ある	操作手順の正本と対象画面	手順が共通なら一問にまとめる
契約ごとに条件が違う	対象プラン・契約主体	共通部分だけ説明し、個別条件は窓口へ
例外処理が少数ある	例外を適用できる権限	例外を通常回答へ混ぜず専用案内にする
古い問い合わせが急に増えた	仕様変更・障害・告知不足	FAQ追加前に原因を担当部署へ確認

回答を作るための根拠台帳

質問と回答のペアには、回答を承認した部署、根拠資料の名前・版または更新日、適用範囲、次回確認条件を残します。AIが参照資料から回答を作った場合も、引用や参照箇所が元資料に実在するか確認します。資料がない問いに対して、自然な一般論を回答欄へ入れないでください。「公開回答を作らない」「担当部署へ確認」のどちらにするかを明示します。

最初の試行では、数十件を一度に処理するより、カテゴリを一つ選び、問い合わせ候補と回答根拠を人が照合できる範囲で始める方が修正点をつかみやすくなります。出力後は、似た質問を統合しすぎていないか、プランや地域の条件が消えていないか、回答がFAQの対象読者に合っているかを確認します。確認済み回答だけを公開用の原稿へ移し、未承認出力は作業メモと分けます。

FAQ公開後に見る指標と見直しの合図

問い合わせ件数の減少だけを成功条件にしません。FAQを見た後も窓口へ連絡する利用者がいるなら、ページが見つからない、質問の言葉が合っていない、回答の前提が見えない、実際の個別条件が違うなど複数の原因があり得ます。可能な範囲で、検索語、閲覧後の再問い合わせ、回答の修正履歴、未解決の理由を同じ期間で見ます。データを集める際も個人を識別する必要がなければ集計単位で扱います。

価格・契約・画面操作などの正本が更新されたら、影響するFAQを洗い出し、旧回答をいつ止めるか決めます。FAQの所有者が不在、根拠資料が失効、適用条件が特定できない場合は、AIに文章を整えさせて公開を続けるのではなく、該当回答を一時的に外す判断も必要です。

AIものさしの判断

AIでFAQを作るときは、問い合わせ履歴から「質問候補を抽出する工程」と、公式sourceから「回答を書く工程」を分けると安全です。

問い合わせ文をそのまま学習素材のように投入するのではなく、個人情報を除き、回答sourceを固定して使います。