ChatGPTでFAQを作る手順：資料の根拠つきで顧客向けに公開

結論

ChatGPTでFAQを作る作業の中心は、質問を考えさせることではなく、回答の根拠を手元の資料に縛ることです。サービス資料や規約を添付し、「添付資料に書かれていないことは答えない。答えられない質問は未回答のまま残す」と条件を置き、回答ごとに根拠になった資料名と原文の引用を書かせます。この形にすると、誤案内になりかねない回答が最初から目印つきで出てくるため、担当者の確認は資料の該当箇所を開くだけで済みます。20問の初稿を承認に回せる状態にするまで、目安として1時間ほどです。

---

FAQの誤りは、記事の誤字とは性質が違います

FAQに書かれた一文は、読んだ顧客の行動をそのまま決めます。解約の期限を1日間違えれば、その日付を信じた顧客が請求を受けます。公開したFAQは会社の回答として扱われるため、後から「AIが書いた内容でした」という説明は通りません。

ChatGPTがFAQづくりでつまずくのは、質問の作成ではなく回答の作成です。質問は資料の内容から素直に導けますが、回答には資料に書かれていない部分が必ず出てきます。そこでChatGPTは、世の中の似たサービスでよくある条件を当てはめて、もっともらしい文章を作ります。「解約は30日前までにお申し出ください」「サポートは平日9時から18時まで対応しております」といった、業界の標準的な条件がそれらしく紛れ込むのはこのためです。

この種の回答は、日本語として自然で、書式も他の回答とそろっています。読んだだけでは見分けがつきません。人が文章を読む前に、ChatGPT自身に根拠を示させる必要があります。

---

ChatGPTにFAQを作らせる前に、資料の渡し方を決める

ChatGPTには手元のファイルを添付して読ませられます。サービス説明資料、規約、料金表、社内の対応マニュアル、既存のFAQページを書き出したものが素材になります。長い資料でも、画面に貼り付けるより添付するほうが、途中が欠ける心配が減ります。プランや時期によって使える機能が異なるため、扱えるファイルの種類や数は最新の公式情報で確認してください。

同じ商品やサービスのFAQを何度も作り直すなら、プロジェクトの機能で資料をまとめて置く方法が向いています。プロジェクトに資料を入れてその中で会話を始めると、毎回ファイルを添付し直す手間がなくなります。文体の決まりや禁止事項も、プロジェクトの指示やカスタム指示に書いておけば会話ごとに書かずに済みます。

見落とされやすいのが、公開してよい情報とそうでない情報の切り分けです。社内の対応マニュアルには、値引きの判断基準や例外対応の裁量など、顧客に見せない記述が混ざっています。丸ごと添付すると、その内容が回答に反映されます。添付する前に、顧客向けに出してよい範囲を担当者が決め、社外秘の段落を削った版を用意してください。機密情報や個人情報を外部サービスへ入力してよいかは、自社の生成AI利用ルールに従います。

---

ChatGPTでFAQを作る手順

1. 顧客向けに出してよい資料だけを選び、添付する
2. 資料から何が読み取れたかを先に答えさせる
3. 回答を書かせず、質問だけを洗い出させる
4. 質問を人が絞り込み、回答を根拠つきで書かせる
5. 根拠のない回答と、資料と食い違う回答を潰す
6. 担当者が承認し、公開する

回答づくりを4番目まで遅らせるのが肝です。質問と回答を一度に作らせると、100問近い文章がまとめて出てきて、どこに想像が混ざっているかを追えなくなります。

資料から読み取れた範囲を先に答えさせる

添付したつもりのファイルが読めていない、古い版の料金表を添付していた、という取り違えは、後から気づくと作業がすべて無駄になります。FAQを書かせる前に何が読めたかを確認します。

添付した資料を読んでください。まだFAQは作らないでください。

確認できたら、次の3点を教えてください。

1. 読み込んだファイル名と、それぞれに書かれている内容の見出し一覧
2. 資料の中に書かれている、数字を含む条件の一覧
   料金、日数、期限、対応時間、上限、回数など。
   それぞれ、どのファイルのどの見出しに書かれていたかを添えてください。
3. 資料どうしで食い違っている記述があれば、その箇所

2番目の指示が、この後の作業を楽にします。FAQで誤りが起きるのは、ほぼ数字を含む条件の部分です。資料にある数字を先に一覧にしておけば、後から出てくる回答の数字が一覧にないとき、すぐに疑えます。

回答を書かせず、質問だけを洗い出させる

読めた範囲を確かめたら、質問だけを作らせます。回答が並んでいないほうが、質問の抜けや重複を人の目で判断しやすくなります。

添付資料をもとに、このサービスの顧客が問い合わせてきそうな質問を洗い出してください。
回答はまだ書かないでください。質問だけを出してください。

条件
- 顧客が実際に使う言葉で書く。社内用語やサービス独自の機能名を質問文に使わない
- 申し込み、初期設定、日々の使い方、料金と請求、解約と返金、
  困ったときの連絡先の6つに分け、それぞれ5問以上
- 各質問に、添付資料の中に答えが書かれているかどうかを
  「資料にあり」「資料になし」で示す
- 「資料にあり」の場合は、どのファイルのどの見出しかを添える

出てきた一覧のうち「資料になし」が付いた質問が、これから社内で答えを決める項目です。ここで初めてFAQづくりの本当の作業量が見えます。顧客がよく聞くのに社内で答えが定まっていない質問は、たいてい10問以上あります。

---

具体例1：名刺管理サービスの顧客向けFAQに、根拠を付けて回答を書かせる

営業部門向けの名刺管理サービスを提供していて、サービス紹介資料、利用規約、料金表、既存FAQの12問を添付した状態だとします。質問の一覧を絞り込み、回答を書かせる段階のプロンプトです。

先ほど絞り込んだ25問について、回答を作成してください。

【根拠の扱い】
- 添付資料に書かれていることだけで回答してください
- 一般的な業界の慣行や、他社サービスの条件を持ち込まないでください
- 資料から答えが決まらない質問は、回答を書かずに「要確認」と記し、
  何が分かれば回答できるのかを1行で書いてください

【出力の形】
表で出力してください。列は次の4つです。
| 質問 | 回答 | 根拠の所在 | 根拠の原文 |

- 根拠の所在には、ファイル名と見出しを書く
- 根拠の原文には、その箇所の文章を一字も変えずに引用する
- 引用できる原文がない回答は、回答欄を空にして「要確認」とする

【回答の書き方】
- 120字以内。です・ます体
- 顧客が次に取る行動が分かるように、操作の場所や連絡先を含める
- 「基本的に」「原則として」のような、例外の余地を残す言い方は使わない

根拠の原文を引用させる列が、この表の要です。回答だけを読むと25問すべてがそれらしく見えますが、引用の列を見ると、原文が入っている行と、空欄か曖昧な要約しかない行にはっきり分かれます。空欄の行は、ChatGPTが資料の外から持ってきた内容です。

引用が入っている行も、そのまま信じられるわけではありません。「解約の申し出は当月中」と書かれた原文から「解約は月末までにお手続きください」という回答が作られている、といったずれが見つかります。申し出と手続きは別の行為です。原文が並んでいなければ気づけません。

---

具体例2：問い合わせ履歴から、実際に聞かれている質問を抜き出す

資料から作った質問は、書き手が「聞かれそうだ」と思ったものにすぎません。実際の問い合わせ履歴を読ませると、想定になかった質問が出てきます。

履歴を渡す前に個人情報を削ります。氏名、会社名、メールアドレス、電話番号、契約番号、住所は、質問の抽出に不要です。問い合わせ管理の画面から書き出したデータなら、これらの列を消して本文だけを残します。手で消すのが現実的でない件数なら、情報システム部門に書き出し方を変えてもらうほうが早く済みます。

添付したファイルは、直近6か月の問い合わせ本文を1行1件で並べたものです。
個人情報は削除済みです。

このデータから、FAQに載せるべき質問を抽出してください。

条件
- 言い回しが違っても同じことを聞いている問い合わせは、1つの質問にまとめる
- まとめた質問ごとに、件数と、元の問い合わせの言い回しを3つまで挙げる
- 件数の多い順に並べる
- 顧客がつまずいている場面が読み取れる場合は、
  「どの操作の途中で詰まっているか」を1行で添える
- 回答は書かないでください

元の言い回しを挙げさせる指示は、質問文を書くときに効きます。社内で「初期同期」と呼ぶ処理を、顧客は「最初の取り込み」「一括登録」と呼びます。顧客の言葉で書かないと、サイト内の検索で見つけてもらえません。

抽出した質問と、資料から作った質問を突き合わせます。両方にあるものは優先して整備します。履歴にしかないものは、資料に書かれていない運用上の質問です。資料にしかないものは実際には誰も聞いていない可能性があるため、後回しにします。

---

想像で補われた回答を、見つける

根拠つきで作らせても、確認をChatGPT任せにはできません。人が見る前に、機械的に絞り込める分だけ絞っておきます。

先ほど作成したFAQの表を、あなた自身で点検してください。

次の4つに当てはまる行を、理由つきで挙げてください。

1. 根拠の原文が引用されていない行
2. 根拠の原文には書かれていない数字、日数、金額、時間が
   回答に登場している行
3. 根拠の原文の意味を、回答が広げている行
   例えば原文が特定の条件下の話なのに、回答が条件なしで書いている場合
4. 資料のどこにも書かれていない固有名詞、画面名、ボタン名が
   回答に出てくる行

該当する行の番号と、どこが問題かだけを挙げてください。
修正はしないでください。

修正させないのは、点検と修正を同時にやらせると問題のあった箇所が書き換わり、何が問題だったのか分からなくなるためです。

この点検を通った後に、人が確認します。人が見るべきは、数字を含む回答と、顧客が損をしうる回答です。料金、期限、日数、対応時間は全件、資料の原本を開いて突き合わせます。解約、返金、補償、個人情報の扱いに関する回答も全件を読みます。それ以外の操作手順は、実際に画面を触って確かめられるものから順に見ていけば足ります。

他のツールで同じ作業をする場合の違いは、GeminiでFAQを作る手順とClaudeでFAQを作る手順にまとめています。社内の文書がMicrosoftの製品に寄っているならCopilotでFAQを作る手順が近道です。

---

公開前に担当者が承認する進め方

FAQの承認で起きがちなのは、25問の表を関係部署へ一斉に送って、誰からも返事が来ないまま止まることです。全員に全問を見せると、自分の担当範囲が分からず誰も手を付けません。回答の内容ごとに、承認する担当を分けます。

回答の内容	承認する担当	見るところ
料金、請求、支払い方法	経理または料金の管理担当	金額、税の表記、請求のタイミング
解約、返金、契約期間	契約を管理する部門	規約の条文と一字一句合っているか
操作手順、画面の名称	製品またはサポートの担当	現在の画面と手順が一致しているか
対応時間、連絡先	サポートの責任者	実際の体制で守れる内容か
個人情報、セキュリティ	情報システムまたは法務	公表してよい範囲か

承認を依頼するときは、その担当が見る行だけを抜き出した表を送ります。根拠の原文の列を残しておくと、承認する側は資料を探さずに済みます。

承認の記録は、質問ごとに「誰が、いつ、どの版を承認したか」を残します。料金改定や機能変更のたびに見直しが必要になるため、誰が承認したかが残っていれば、変更時に確認先をすぐ特定できます。更新を続ける体制の作り方はFAQをAIで整備する方法で扱っています。

---

自社サイトに載せるときの構造化データ

FAQを自社サイトに掲載するとき、質問と回答を検索エンジンや生成AIが読み取りやすい形で埋め込んでおくと、検索結果や回答での扱われ方が変わります。FAQPageという形式の構造化データがその役割を果たし、承認済みの表があればChatGPTに書かせられます。

承認済みの次のFAQを、FAQPage形式の構造化データに変換してください。

条件
- JSON-LD形式で出力する
- 質問文と回答文は、渡した内容から一字も変えない
- 回答にHTMLのタグを含めない。改行は文章の区切りにしない
- 「要確認」の行は含めない
- 出力はコードブロックひとつにまとめる

---
（承認済みのFAQの表を貼り付ける）

回答文を変えさせない指示が欠かせません。指示しないと、構造化データに入れるときに回答を短く整えてしまい、ページに表示されている文章と埋め込まれた文章が食い違います。表示と構造化データの内容が違うのは、検索エンジンの案内でも避けるよう書かれている扱いです。

出力をそのまま本番のページへ貼るのは避けてください。文字の書き方の誤りで読み取れなくなることがあるため、検索エンジンが提供している検証ツールにかけて確かめます。公開後に回答を直したときは、構造化データ側も同じ内容に直します。表示だけ直して放置すると、古い回答が引用され続けます。

---

うまくいかないときの対処

回答が長くなり、読む気が失せる。 字数の指定がないと、ChatGPTは丁寧に説明しようとします。「120字以内」のように上限を先に決めます。すでに長い回答ができている場合は、「回答が120字を超えている行だけ、意味を変えずに120字以内へ縮めてください。数字と固有名詞は削らないでください」と、対象を限定して縮めさせます。

似た質問ばかりが並ぶ。 資料の見出しを機械的になぞると起きます。「同じ答えになる質問を統合し、答えが異なる質問だけを残してください」と整理させます。

根拠の原文を引用させても、引用が要約になっている。 「一字も変えずに」と書いても、長い段落を渡すと要約されることがあります。「引用は原文から連続した1文を、句読点も含めてそのまま写してください。1文で足りなければ2文まで」と、引用の単位を指定します。

会話が長くなると、最初に出した条件が守られなくなる。 20問を超えるあたりから、字数の上限や禁止事項が崩れます。5問ずつに区切って作らせ、区切りごとに条件を短く書き添えます。プロジェクトやカスタム指示に条件を書いておくと、会話が変わっても条件が残ります。

添付した資料を読んでいないような回答が返る。 ファイルの形式によっては中身が読み取れていないことがあります。読み取れた見出しの一覧を出させて確かめ、読めていなければその資料だけテキストとして貼り付け直します。料金表のように表が多い資料は読み間違いが起きやすいため、条件を文章にした版を用意すると精度が上がります。

回答の文体がばらつく。 既存FAQが手元にあるなら、「添付した既存FAQ12問と同じ文体、同じ語尾、同じ敬称の使い方でそろえてください」と見本を指定します。

---

まとめ

手元にあるサービス資料のうち、顧客に見せてよいものを1つ選び、添付して読み取れた見出しと数字の一覧を出させるところから始めてください。質問だけを先に洗い出し、資料に答えがない質問に印を付けると、社内で決めなければならないことが先に分かります。回答は根拠の原文つきの表で出させ、引用が空欄の行から確認します。一度うまくいった根拠の指示文と点検の指示文は、プロジェクトの指示に保存しておくと、次の商品のFAQでは資料を差し替えるだけで同じ精度が出ます。