問い合わせ内容からFAQの不足テーマを洗い出す

処理の起点を決める

毎月1日の時刻起動にします。

リアルタイム処理は不要です。ただし、新機能のリリース直後は週次で回すことを勧めます。 リリースによる問い合わせ急増を早く捉えるためです。

入力データを集める

リリース履歴を渡すことが効きます。 「新機能Xのリリース後、そのテーマの問い合わせが月0件から月60件に増えた」という因果が見えます。

データの取得方法を決める

問い合わせ本文： 問い合わせ管理システムのAPI、またはCSVエクスポートで取得します。月1回の処理なので、CSVの手動エクスポートでも運用に支障はありません。

既存FAQ： FAQ管理システム、または社内Wikiから取得します。

AIへ渡す前に整形する

1. 顧客情報のマスキング … 社名、氏名、メールアドレス、契約番号を伏せます。この分析に顧客の特定は不要です
2. 引用・署名の除去 … 過去のやり取りの引用を落とします
3. 対象の絞り込み … 営業問い合わせ、スパム、資料請求を除外します。FAQで解決すべき問い合わせだけを対象にします
4. 文字数の制限 … 本文が長い場合、先頭500字に切ります。顧客は冒頭で用件を書くことが多いためです

AIに処理させる

3段階に分けます。

第1段：各問い合わせから「知りたかったこと」を1文で抽出

4,400件それぞれに対して実行します。出力は1文（30字程度）なので、軽量なモデルで足ります。

クラスタリング：LLMではなく埋め込みベクトル

抽出した1文を埋め込みベクトルに変換し、類似度でまとめます。ここをLLMにやらせないでください。 4,400件の類似判定をLLMで行うのは費用と時間の無駄で、精度も安定しません。

クラスタ数は自動で決めるより、「件数が10件以上のクラスタ」という条件で切るほうが実用的です。 月10件未満のテーマは、FAQを作る優先度が低いためです。

第2段：各クラスタにテーマ名を付ける

クラスタに含まれる代表的な問い合わせを渡し、テーマ名を付けさせます。数十クラスタなので、処理は軽くなります。

第3段：既存FAQとの突合とカバー状況の判定

各テーマについて、埋め込み類似度で近いFAQを検索し、そのFAQが本当にそのテーマに答えているかを判定させます。

指示内容を固定する

第1段（各問い合わせの要約）：

以下の問い合わせについて、顧客が知りたかったことを1文（30字以内）で書いてください。

【厳守事項】
- 顧客の言葉ではなく、質問の内容を書いてください。
  （「困っています」ではなく「通知メールが届かない原因」）
- 問い合わせに書かれていない事柄を補わないでください。
- 用件が複数ある場合、主たる用件を1つだけ書いてください。
- 判別できない場合は「判別不能」と書いてください。

【問い合わせ】
{inquiry}

第3段（FAQとの突合）：

あなたはFAQの整備を検討する担当者です。
以下のテーマについて、既存FAQでカバーされているかを判定してください。

【厳守事項】
- 判定は次の4つから選んでください。
  covered: FAQに該当項目があり、内容も十分
  hard_to_find: FAQに該当項目があるが、タイトルや表現が
                問い合わせの言葉と異なり、検索で見つけにくい
  insufficient: FAQに該当項目があるが、内容が問い合わせに答えていない
  missing: FAQに該当項目がない
- hard_to_find と判定する場合、
  問い合わせで使われている言葉と、FAQのタイトルの違いを具体的に書いてください。
- insufficient と判定する場合、FAQに不足している内容を具体的に書いてください。
- FAQの内容を評価する際、そのFAQに書かれていることだけを見てください。
  一般的にどうあるべきかで判断しないでください。
- 新しいFAQの本文を書かないでください。判定と指摘までです。

【テーマ】{theme_name}（件数: {count}件）

【このテーマの代表的な問い合わせ（5件）】
{sample_inquiries}

【類似度の高い既存FAQ（上位3件）】
{candidate_faqs}

hard_to_find という判定を設けていることが、この構成の要点です。

FAQに書いてあるのに問い合わせが来る場合、原因は2つあります。内容が不十分か、見つけられないかです。この2つで打ち手がまったく違います。 前者はFAQの書き直し、後者はタイトルの変更や検索キーワードの追加です。

多くの企業が「FAQを増やす」ことで解決しようとしますが、実際には既存FAQが見つかっていないだけということがよくあります。

出力形式を固定する

{
  "period": "2026-08",
  "total_inquiries": 4400,
  "themes": [
    {
      "theme_name": "",
      "count": 0,
      "share": 0.0,
      "prev_month_count": 0,
      "change": 0,
      "coverage": "covered | hard_to_find | insufficient | missing",
      "related_faq_id": "",
      "gap_note": "",
      "sample_inquiries": [],
      "possible_cause": ""
    }
  ],
  "new_themes": [],
  "resolved_themes": [],
  "unclassified_count": 0
}

• new_themes … 前月になかったテーマ。リリース直後の問題を捉えるために重要です
• resolved_themes … 前月あって今月消えたテーマ。FAQ整備の効果測定に使います
• possible_cause … リリース履歴と照らして、原因が推定できる場合。推定であることを明示させます

システムへ連携する

月次レポートをスプレッドシートに出力します。列は「テーマ／件数／前月比／カバー状況／該当FAQ／不足内容／代表的な問い合わせ」とします。

FAQ管理システムへの自動登録はしません。 FAQの作成は人の作業です。この構成は、どのFAQを作るべきかの優先順位を示すまでです。

ただし、hard_to_find と判定されたFAQについては、改善の提案（タイトルの候補、追加すべき検索キーワード）を添えると、実行されやすくなります。

人が確認する

全件、人が確認します。 ただし、確認するのは「テーマの単位」であり、個々の問い合わせではありません。数十テーマなので、30分程度で確認できます。

確認の観点は3つです。

1. テーマのまとめ方が妥当か … 別のテーマが一緒にまとめられていないか、逆に同じテーマが分かれていないか
2. カバー状況の判定が正しいか … 特に covered と判定されたテーマに、本当にFAQが対応しているか
3. 優先順位の決定 … 件数だけでなく、FAQを作る手間と効果を踏まえて決めます

AIの出力をそのままFAQ整備計画にしないでください。 件数が多いテーマでも、FAQで解決できないもの（個別の設定に依存する質問など）があります。

例外に対処する

記録を残す

• 各月の分析結果（テーマと件数）
• 確定したテーマ名の辞書
• FAQ整備の実施記録（いつ、どのFAQを作ったか）
• 整備後のテーマ別件数の推移

最後が、この構成の成果指標です。 「通知メールが届かない」のFAQを作った翌月、そのテーマの問い合わせが182件から120件に減ったなら、月62件の削減です。減っていなければ、FAQの内容か置き場所に問題があります。