ClaudeでFAQを作る手順：問い合わせ履歴を根拠に整備する

結論

ClaudeでFAQを整備する近道は、想定で質問を考えさせるのではなく、実際に届いた問い合わせ履歴を丸ごと読ませて質問の塊に分けさせることです。履歴とマニュアルをプロジェクトに登録し、「マニュアルに書かれていることだけで答え、根拠の原文を引用する」と縛れば、件数の多い順に並んだ質問と、根拠つきの回答が同時に手に入ります。1年分の履歴から30問の初稿を承認に回す状態まで、目安として半日です。

---

想定で作ったFAQと、履歴から作ったFAQの違い

手元の資料だけでFAQを書くと、作った側が説明したいことが並びます。サービスの特長、機能の使い方、申し込みの流れといった項目です。一方、実際に届く問い合わせで多いのは、資料のどこにも書かれていない細かい場面です。設定を途中で中断したらどうなるか、担当者が異動したときに誰に連絡するか、契約の途中で台数を減らせるか。こうした質問は、作り手の頭からは出てきません。

問い合わせ履歴を読ませると、この差が数字で見えます。想定で作った20問のうち半分は年に数件しか聞かれておらず、実際に月10件届いている質問がFAQに1問もない、という状態はよくあります。

Claudeは長い文書を分割せずに読み込めるため、履歴を月ごとに切らずに渡せます。全体を通して読ませると、「4月に集中している質問」「1年を通じて一定数ある質問」といった時期の偏りも同時に拾えます。前者は新年度の手続きに関する質問で、時期を選んで案内を出すほうが効きます。後者がFAQに載せるべき質問です。

---

履歴を渡す前に、個人情報を落とす

問い合わせ管理システムから履歴を書き出すと、氏名、会社名、メールアドレス、電話番号、契約番号、製品のシリアル番号が列として付いてきます。質問を抽出する作業に、これらは一切使いません。書き出しの設定で本文の列だけを残すか、表計算ソフトで不要な列を削ってから渡します。

本文の中にも個人が特定できる記述が残ります。「○○支店の△△です」と名乗る書き出しや、担当者名を挙げたやりとりです。件数が多いと手で消しきれないため、出力側でも抑えます。指示に「抽出結果に、人名、会社名、支店名、電話番号、メールアドレスを含めないでください」と書き添え、出てきた一覧に固有名詞が残っていないかを人の目で確かめます。

顧客から預かった情報を外部サービスへ入力してよいかは、自社の生成AI利用ルールと、顧客との秘密保持の取り決めによります。判断がつかないときは、情報システム部門か法務の担当に先に確認してください。

---

プロジェクトに資料を置いて、根拠の範囲を固定する

Claudeのプロジェクトに、製品マニュアル、保守契約の約款、社内の対応手順書、現行のFAQを登録しておくと、そのプロジェクトの中で始めた会話はいつでも同じ資料を参照します。会話のたびに添付し直す手間がなくなるだけでなく、回答の根拠になる範囲が固定されるという効果があります。

範囲を固定する意味は、FAQでは大きくなります。担当者が個別に会話を始めると、Aさんは最新のマニュアルを添付し、Bさんは1つ前の版を添付する、ということが起きます。同じ質問に違う回答ができる原因の多くはここです。プロジェクトに置いた資料を差し替える手順を決めておけば、誰がFAQを作っても根拠がそろいます。

プロジェクトの指示欄には、文体と禁止事項を書いておきます。「回答は150字以内、です・ます体」「登録した資料に書かれていないことは答えない」「推測で補った場合はその旨を明記する」といった条件を毎回書かずに済みます。扱える資料の分量や数はプランや時期で変わるため、最新の仕様は公式情報で確認してください。

---

Claudeで問い合わせ履歴からFAQを作る手順

1. 個人情報を落とした履歴と、マニュアルをプロジェクトに登録する
2. 履歴を読ませ、質問の塊に分けて件数を出させる
3. 塊ごとに、マニュアルに答えがあるかを判定させる
4. 答えがある塊だけ、引用つきで回答を書かせる
5. 引用のない回答と、原文からずれた回答を潰す
6. サポートの責任者が承認し、公開する

履歴を質問の塊に分ける

最初の作業は要約ではなく分類です。1件ずつ要約させると、件数分の文章が出てきて読みきれません。同じことを聞いている問い合わせをまとめさせます。

プロジェクトに登録した問い合わせ履歴を、すべて読んでください。

同じことを聞いている問い合わせをひとつの塊にまとめ、質問の一覧を作ってください。

条件
- 言い回しや表現が違っても、聞いている内容が同じなら同じ塊にする
- 塊ごとに次を出す
  1. 顧客の言葉に近い質問文
  2. 件数
  3. 元の問い合わせでの言い回しを3つまで
  4. 問い合わせが集中している月があれば、その月
- 件数の多い順に並べる
- 人名、会社名、支店名、電話番号、メールアドレスを出力に含めない
- 回答はまだ書かないでください

元の言い回しを残させるのは、FAQの質問文を顧客の言葉で書くためです。社内で「保守区分の変更」と呼んでいる手続きを、顧客は「プランを下げたい」「台数を減らしたい」と言います。社内の呼び方で質問文を書くと、FAQページの検索で見つけてもらえません。

マニュアルに答えがあるかを判定させる

質問の一覧ができたら、回答を書かせる前に、答えられるかどうかを切り分けます。

先ほどの質問一覧の各行について、プロジェクトに登録したマニュアルと約款に
答えが書かれているかを判定してください。

判定は次の3つのいずれかで示してください。

A 資料に明確に書かれている。根拠の見出し名を添える
B 資料に関連する記述はあるが、この質問にそのまま答えられない。
  何が足りないかを1行で書く
C 資料にまったく書かれていない

表で出力し、件数の多い順に並べてください。回答は書かないでください。

Bが付いた質問は、資料の書き方に問題があります。マニュアルに機能の説明はあるが、顧客が知りたい可否の判断が書かれていない、という状態です。この一覧は、FAQを作る材料であると同時に、マニュアルを直す優先順位にもなります。

Cが付いた質問のうち件数が多いものは、サポートの担当者が口頭で答えてきた内容です。ここを文章にすることが、FAQ整備の本題になります。

---

具体例1：保守サービスの履歴1年分から、FAQを30問に組み直す

業務用プリンターの保守サービスで、1年分の問い合わせ約2,000件と、製品マニュアル、保守契約の約款をプロジェクトに登録した状態を想定します。判定でAが付いた質問について、回答を書かせます。

判定がAだった質問について、FAQの回答を作成してください。

【根拠の扱い】
- プロジェクトに登録したマニュアルと約款に書かれていることだけで回答する
- 他社の保守サービスの一般的な条件や、業界の慣行を持ち込まない
- 資料から答えが決まらないものは、回答欄を空にして「要確認」と記す

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

- 根拠の所在には、資料名と見出し名を書く
- 根拠の原文には、その箇所の文章を連続した1文または2文で、
  一字も変えずに写す。要約はしない
- 原文を写せない回答は、回答欄を空にして「要確認」とする

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

出てきた表は、回答の列ではなく原文の列から読みます。原文が空欄の行は、Claudeが資料の外から持ってきた内容です。保守サービスでは「出張は翌営業日までに伺います」「消耗品は保守の範囲に含まれません」といった、業界では一般的でも自社の約款には書かれていない条件が紛れます。

原文が入っている行にも、ずれが潜みます。約款に「年1回の定期点検を実施する」と書かれているところから、「点検は年1回無償で実施します」という回答が作られていることがあります。無償かどうかは原文に書かれていません。原文と回答を1行ずつ並べて見ると、この種の追加は短時間で見つかります。

---

具体例2：いまのFAQが、実際の問い合わせに答えられているかを採点させる

新しくFAQを作る前に、既存のFAQを履歴で採点すると、手を入れる箇所が絞れます。

プロジェクトに登録した現行のFAQ18問と、問い合わせ履歴の両方を参照してください。

現行FAQの各問について、次を判定してください。

1. その質問が、履歴の中で何件届いているか
2. 現行の回答で解決できたはずの問い合わせが何件か
3. 現行の回答があるにもかかわらず問い合わせが来ているものは、
   回答のどこが足りないと考えられるか

あわせて、履歴に件数の多い質問があるのに現行FAQに存在しないものを
一覧にしてください。

この判定で、FAQに載っているのに問い合わせが減っていない質問が浮かびます。多くは、回答に条件が書かれていないか、顧客が探している言葉と質問文が違うかのどちらかです。前者は回答を書き直し、後者は質問文を顧客の言い回しに寄せます。

判定の数字はClaudeの推定なので、そのまま報告資料に使わないでください。手を入れる順番を決める目安として扱い、根拠になった問い合わせを何件か開いて確かめます。

他のツールで同じ進め方をする場合の違いは、ChatGPTでFAQを作る手順とGeminiでFAQを作る手順にまとめています。部門としてFAQ整備を進める手順はカスタマーサポートのFAQをAIで作る方法で扱っています。

---

想像で書かれた回答を、人が読む前に絞る

点検もClaudeに頼めます。点検と修正を分けるのが要点です。

先ほど作成したFAQの表を点検してください。

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

1. 根拠の原文が空欄の行
2. 原文には書かれていない日数、金額、回数、時間が回答に登場している行
3. 原文の意味を回答が広げている行。
   原文が特定の条件下の記述なのに、回答が条件なしで書いている場合を含む
4. 無償、無料、保証、対応、といった負担や責任に関わる言葉が
   回答にあり、原文に対応する記述がない行
5. 資料に出てこない部署名、様式名、システム名が回答に出てくる行

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

4番目は、保守や修理の案内で特に効きます。費用が発生するかどうかは顧客の関心が最も高い部分で、ここを曖昧に書いた回答は、そのまま請求時のもめごとになります。

絞り込んだ後に人が読みます。全件を読むべきなのは、費用に触れた回答、期限や対応時間を述べた回答、契約の変更や解約に関わる回答です。それ以外の操作手順は、実際に製品を触って確かめられるものから順に見ていきます。

---

承認して公開するまで

Claudeの回答は、成果物を別画面に出す機能を使うと本文とは別の枠に表示され、その枠の中だけを直していけます。FAQの表のように何度も手を入れる成果物では、会話の履歴を遡らずに最新版を見られるため、修正のやりとりが追いやすくなります。

承認は、回答の内容ごとに担当を分けます。

回答の内容	承認する担当	見るところ
費用、請求、保守の範囲	契約または経理の担当	金額と、有償か無償かの区別
対応時間、訪問までの日数	サポートの責任者	現在の体制で守れる内容か
操作手順、画面や部品の名称	製品担当	現行の製品と一致しているか
契約の変更、解約	契約を管理する部門	約款の条文と合っているか

承認を依頼するときは、その担当が見る行と、根拠の原文の列を残した表を渡します。原文が並んでいれば、承認する側は資料を探さずに済みます。承認の結果は質問ごとに記録し、誰が、いつ、どの版の資料をもとに承認したかを残します。マニュアルの改訂や価格改定のたびに、影響する回答を特定できます。

公開後も、履歴からの採点を定期的に回します。四半期に一度、直近の履歴で同じ判定をかければ、新しく増えた質問と、回答を直しても減らない質問が分かります。

---

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

質問の塊が細かく分かれすぎる。 言い回しの違いを別の質問として扱うと起きます。「同じ回答文で答えられる問い合わせは同じ塊にしてください」と、まとめる基準を回答側から指定し直します。

出力が途中で切れる。 件数の多い履歴から一度に30問の表を出させると起きます。「件数の多い順に10問ずつ出力し、続きは私が指示してから出してください」と区切ります。

個人情報が出力に残る。 「○○支店の担当者から」のような記述は、指示しても残ることがあります。出てきた一覧を検索して部署名や地名を確認し、残っていれば「出力から支店名と地名をすべて削ってください」と直させます。

プロジェクトに入れた資料のうち、古い版を参照している。 同じ名前の資料が複数入っていると起きます。回答に添えられた資料名を確認し、旧版はプロジェクトから外します。

回答の文体が資料の言い回しに引きずられる。 マニュアルの文章をそのまま写すと、顧客には硬すぎます。「資料の言葉をそのまま使わず、製品に詳しくない顧客に説明する言い方へ書き直してください。ただし日数、金額、製品名は原文の表現を変えないでください」と、書き換えてよい範囲を分けます。文体をまとめて整える方法はClaudeで文章の書式を整える手順が参考になります。

---

まとめ

問い合わせ管理システムから直近1年の本文を書き出し、個人情報の列を外したファイルを1つ作るところから始めてください。マニュアルと一緒にプロジェクトへ登録し、質問の塊と件数を出させれば、いま何がいちばん聞かれているかがその日のうちに分かります。回答は根拠の原文つきの表で作らせ、原文が空欄の行を担当者に回します。分類と判定に使った指示文はプロジェクトの指示に残しておくと、次の四半期は履歴のファイルを入れ替えるだけで同じ点検ができます。