ChatGPTで社内FAQを作る時、最初に回答文を求めると、元資料の空白まで文章で埋まりやすくなります。先に抜き出すのは、質問候補と根拠です。回答済み、資料不足、担当者確認へ分け、確認済みの内容だけをFAQへ移します。
ここでは、架空の案内資料を使い、FAQのたたき台を作る順番を整理します。
この記事でわかること
- FAQを作る前にそろえる元資料
- 質問候補と根拠を抜き出す指示
- 回答を3つの状態へ分ける方法
- 元資料が古かった時に直す順番
- 公開・共有前に人が確認する範囲
FAQの正解を元資料へ置く
FAQの回答は、ChatGPTの知識ではなく、自社で確認した資料が基準です。料金、対応範囲、申込条件が書かれた資料を先に決めます。
元資料の候補は次のとおりです。
- 公開中のサービス案内
- 現在使っている社内手順
- 担当者が確認した回答集
- 利用規約や契約条件
古い資料と新しい資料が混ざる場合は、どちらが現行かを人が決めます。ChatGPTへ判定を任せると、文章の書きぶりが新しいだけの資料を、内容まで新しいものとして扱ってしまうことがあります。
資料に書かれていないことは未回答なので、空欄を失敗と考えず、確認が必要な場所として残します。
資料同士で内容が違う場合も、AIに多数決をさせません。料金は料金表、対応範囲はサービス案内というように、項目ごとに正しい情報源を人が決めます。
どの資料を基準にするか決まっていないFAQは、文章を増やすほど食い違いが増えます。先に作るべきなのは回答集ではなく、情報源の対応表です。
実資料を入れる前に入力範囲を決める
社内FAQの元資料には、顧客情報や社内だけの条件が含まれることがあります。入力の可否が決まっていない場合は、公開情報かダミー資料で試します。
次の情報は、必要がなければ外す候補です。
- 顧客名、担当者名、連絡先
- 個別契約の金額や条件
- 管理画面のURLと認証情報
- 未公開の商品や予定
- 社内だけで使う識別番号
利用するサービスのデータ取扱いと、社内ルールを先に確かめます。ChatGPTで情報を整理する前のデータ管理も、入力範囲を決める時の参考になります。
質問候補・根拠・不足を先に抜き出す
最初の出力はFAQ本文ではなく、質問候補、根拠箇所、不足情報を並べた確認表です。
次の元資料から、社内FAQの候補を表にしてください。
列:
質問候補 / 回答案 / 根拠箇所 / 状態 / 確認先
ルール:
- 回答は元資料に書かれた内容だけで作る
- 根拠となる文を短く示す
- 資料に回答がなければ作らない
- 状態は「回答済み」「資料不足」「担当者確認」のいずれか
- 判断できない確認先は空欄にする根拠箇所はページ名や見出し名まで残しておくと、元資料の内容が変わった時に、どのFAQを見直せばよいかをそこからたどれます。
質問の表現は、実際に届いている問い合わせの言い方へ合わせて人が整えます。架空の質問件数や問い合わせ傾向を、AIに作らせることはしません。
回答を3つの状態へ分ける
出力された回答は、回答済み、資料不足、担当者確認へ分けます。文章として自然かどうかより、どの記述を根拠にしているかと、どの状態に当たるかを先に見ます。
回答済み
元資料に質問への答えがあり、どの記述が根拠かまで示せる状態です。FAQへ移す候補になります。
数字、日付、対象範囲は原文と照合し、言い換えで条件が広がっていないかも見ます。
資料不足
元資料に答えがなく、回答を作れない状態です。ChatGPTが補った文章は採用しません。
資料不足が何度も出る質問は、元資料側の更新候補です。マニュアルの更新漏れをAIで探す方法へつなぐと、FAQ以外の資料も同じ基準で見直せます。
担当者確認
資料に似た説明はあるものの、条件が合うか判断できない状態です。料金や契約条件など、決定権を持つ人へ確認します。
確認後は回答だけでなく根拠資料も直し、次回に同じ食い違いを残さないようにします。
元資料そのものが古い場合は、FAQより先に直す
3つの状態に当てはまらないものが一つあります。資料に答えは書かれているのに、その内容が現在と違う場合です。
これを「回答済み」に入れると、間違った回答が根拠つきでFAQへ入ります。担当者へ確認したうえで、まず元資料を直します。FAQへ移すのは、そのあとです。
確認表では、状態を「担当者確認」にしたうえで、確認事項へ「元資料の更新が必要」と書き添えます。回答を直す作業と、資料を直す作業を、別々に残せます。
料金改定や対応範囲の変更があった時期は、この食い違いが一度に出ます。FAQの作成をいったん止めて、どの資料が現行かを決め直すほうが早く終わります。
確認できた回答だけをFAQへ移す
FAQ本文へ移すのは、回答済みになった項目だけです。資料不足と担当者確認の行は、状態が変わるまで公開や社内共有の対象から外しておきます。
移す時は、次の項目をセットで残します。
- 質問
- 確認済みの回答
- 根拠資料
- 確認した担当者
- 見直す条件
見直す条件は「料金表を変えた時」「申込方法を変えた時」のような変更点です。日付だけの定期確認より、変更のきっかけと結びつけるほうが実務で追いやすくなります。
FAQの管理表は、次の形にすると追跡できます。
| 質問 | 根拠資料 | 確認者 | 見直す条件 |
|---|---|---|---|
| 受付後はどの手順で進むか | 申込案内 | 受付担当 | 申込手順を変えた時 |
| 対応範囲はどこまでか | サービス案内 | サービス担当 | 対応内容を変えた時 |
回答文だけを保存すると、根拠が変わっても気づけません。FAQを更新する単位は文章ではなく、質問、根拠、確認者、変更条件をひとまとめにした4点だと考えておくほうが、あとの見直しが楽になります。
問い合わせ返信で同じ回答を使うなら、AIで返信文を作る手順へもつなげられます。材料にはFAQの確認済み情報だけを使います。
FAQを増やす前に運用担当を決める
FAQは作成時より、内容が変わった時の更新で止まりやすい資料です。誰が質問を追加し、誰が回答を確定するかを決めます。
最低限、次の役割が必要です。
- 質問候補を集める人
- 根拠資料を更新する人
- 回答を確定する人
- FAQへ反映する人
一人が何役かを兼ねても構いませんが、役割の欄が空いたままなら、FAQを増やす前に元資料の整理から始めるほうが先です。
質問数を増やすこと自体は成果ではありません。答えられない質問が見つかり、元資料の不足を直せたなら、それもFAQ作成の成果です。
おわりに
ChatGPTで社内FAQを作る時は、質問候補、根拠、未回答を先に表へします。回答済み、資料不足、担当者確認へ分け、確認できた回答だけをFAQへ移す。この順番なら、元資料にない案内を増やさずに済みます。
公開情報やダミー資料で確認表を試すところまでは、自社でも進められます。情報源が散らばり、項目ごとの基準や確認者を決められない。そんな場合は、実資料を入力する前にお力になれるかもしれませんので、お気軽にご相談ください。
