ClaudeでFAQを作成 — 問い合わせ履歴から候補を抜き、ヘルプ記事の古さを点検する

問い合わせ履歴からFAQを起こす作業は、「よく来る質問を数える」「その質問に答える記事があるか探す」「あっても内容が古くないか読む」の3段に分かれます。Claudeに任せやすいのは、この3段を同じ資料の上で続けて回せる点です。問い合わせのCSVと既存のヘルプ記事を1つのProjectに置けば、頻出質問のうち記事が無いものと、記事と食い違う回答が出ているものを同じ会話で抜けます。

ただし、Claudeが出す候補は下書きです。件数の数え違い、記事の読み違い、公開してはいけない社内事情の混入は、人が確かめる前提で組み立てます。この記事では、資料の置き方、指示の書き方、候補の検算、公開前に人が見る項目の順に進めます。

問い合わせの週次集計だけなら問い合わせCSVから週次レポートを作る手順が近い内容です。ここでは集計の先、つまり「記事を書く・直す」判断までを扱います。

Projectsに何を置くと点検が回るか

置くものは2種類です。直近の問い合わせCSVと、現行のヘルプ記事です。どちらも1つのProjectの知識(Project knowledge)に入れ、点検の観点は指示(Project instructions)に書きます。

Projectは、チャット履歴と知識ベースを持つ自己完結した作業場です。Projectsは無料アカウントを含む全ユーザーが使えます。無料アカウントで作れるProjectは最大5つです。

置き場として決めておくことは次の4点です。

有料プラン(Pro、Max、Team、Enterprise)では、知識がコンテキストの上限に近づくとRAG(検索拡張生成)に自動で切り替わり、容量が最大10倍に広がります。資料が増えるほど、この切り替えが起きる場面は増えます。仕組みの詳細はClaude ProjectsのRAG検索の仕組みにあります。

この切り替えは、記事の点検のやり方に影響します。RAGが働くと、Claudeは知識全体を毎回読むのではなく、質問に関連する部分を検索して取り出します。そのため「全記事を通読して矛盾を探して」という頼み方は、取り出された部分だけを根拠にした答えになる場合があります。後述のとおり、点検は記事単位に分けて頼みます。

なお、Projectの中で別のチャットを開いても、会話の中身は引き継がれません。点検の結果を次のチャットで使いたいときは、結果をファイルにしてProjectの知識へ追加します。

指示欄に書く点検の規約

Projectの指示は、そのProjectのすべてのチャットに効きます。点検の観点を毎回プロンプトに書くと、日によってぶれます。次のような規約を指示欄に置いておくと、誰が頼んでも同じ観点で動きます。公式の例を踏まえた書き方の一例です。

あなたはヘルプセンターの編集補助です。
 
【資料】
- tickets_*.csv: 問い合わせ履歴(列: ticket_id, created_at, subject, body, answer)
- help_*.html: 公開中のヘルプ記事(ファイル名の先頭に記事IDを付けている)
 
【守ること】
- 件数や傾向を述べるときは、必ず根拠のticket_idをセミコロン区切りで添える
- 記事の内容に触れるときは、記事IDと該当箇所の原文を引用する
- 資料に書かれていないことは補わない。分からないときは「資料に無い」と書く
- 返金の可否や契約解釈など会社の判断が要る回答は、候補に「要判断」と付ける
- 氏名・メールアドレス・電話番号が資料に残っていたら、候補に転記せず指摘する

ポイントは、根拠のIDを必ず付けさせることです。後で機械的に検算できるのは、この約束があるからです。「ファイル名の先頭に記事IDを付ける」のは、RAGが検索する際にも手がかりになります。公式のRAG解説も、分かりやすいファイル名と、質問の中で資料名を指定することを勧めています。

手順1: 問い合わせCSVを絞って個人情報を落とす

CSVには、集計に要る列だけを残します。点検に使うのは、問い合わせ日、件名、本文、実際に返した回答、チケットIDくらいです。氏名やメールアドレスの列は落とします。

本文の中に連絡先が書かれている場合は、列を消しても残ります。列の削除と本文の置換を手元でまとめて行う方法は、VOC分析の記事にスクリプトがあるので、アップロード前に通してください。

期間は、記事を直した後の問い合わせが混ざらないように切ります。たとえば前回の記事改訂日以降の分だけを渡すと、「もう直した問題」を候補に拾うのを避けられます。

手順2: 記事が無い質問を抜く

最初の依頼は、頻出質問を並べ、既存記事に答えがあるかを判定させることです。判定は3つに限定します。

プロンプトの一例です。

tickets_202609.csv の問い合わせを、同じ疑問ごとに束ねてください。
束ねた質問ごとに、help_*.html の中に答えが載っている記事があるかを判定し、
次の形式のCSVで出してください。
 
topic,ticket_ids,count,article_id,verdict
(verdict は「記事あり」「記事なし」「一部のみ」のどれか。
 article_id は記事あり・一部のみのとき必須で、該当箇所を1文引用する)
 
判断に迷うものは「一部のみ」にして、理由を1行で添えてください。

「一部のみ」を設けるのが肝です。2択にすると、記事に関連語が出てくるだけで「記事あり」と判定されやすくなります。たとえば「請求書の宛名変更」の質問に対し、請求書の発行手順だけが載った記事を「答えあり」と見なす、といったずれです。

例えば次のような形の出力になります(形式を示す例で、実際の出力ではありません)。

手順3: 記事と食い違う回答を抜く

2つ目の依頼は、記事と実際の回答のずれを探すことです。サポート担当が個別に返した回答が、公開中の記事と食い違っているなら、どちらかが古い可能性があります。

この点検は、記事を1本ずつ指定して頼みます。RAGが働いている場合に、取り出された部分だけで判定が終わるのを避けるためです。

記事単位の依頼文は、次のように書きます。

help_0042(請求書の発行と宛名)を点検してください。
 
1. tickets_202609.csv から、この記事の話題に関する問い合わせを探し、ticket_id を挙げる
2. それらの answer 列の回答と、記事の記述が食い違う箇所を、記事の原文と回答の原文を並べて示す
3. 食い違いの種類を「記事が古い」「回答が誤り」「どちらとも言えない」から選ぶ
4. 食い違いが無ければ「食い違いなし」と書く(無理に探さない)

4番の「無理に探さない」は意外と効きます。食い違いを探せと頼まれると、表現の差を食い違いとして挙げがちだからです。

「記事が古い」と「回答が誤り」の区別は、Claudeには付けられません。記事と回答のどちらが現行の運用に合っているかは、資料に書かれていないためです。分類は目安として受け取り、確定は担当者が行います。

手順4: 候補の根拠IDを機械で検算する

Claudeが出した候補は、そのまま信じず検算します。確かめやすいのは、挙げられた根拠のticket_idが実在するか、申告された件数と挙げたIDの数が合うかです。

次のスクリプトは、元のCSVと候補のCSVを突き合わせます。標準ライブラリだけで動きます。

import csv, sys
tickets = {r["ticket_id"] for r in csv.DictReader(open(sys.argv[1], encoding="utf-8-sig"))}
bad = 0
for r in csv.DictReader(open(sys.argv[2], encoding="utf-8-sig")):
    ids = r["ticket_ids"].split(";")
    missing = [i for i in ids if i not in tickets]
    ok = not missing and len(ids) == int(r["count"])
    bad += not ok
    print(f'{"OK " if ok else "NG "}{r["topic"]}: 引用{len(ids)}件 / 申告{r["count"]}件'
          + (f' / 存在しないID {",".join(missing)}' if missing else ""))
sys.exit(1 if bad else 0)

4行のサンプルCSVと、候補CSVの2行(うち1行に実在しないID 2009を混ぜたもの)でPython 3.12.2に対して実行した出力です。

python3 check_candidates.py tickets.csv candidates.csv
echo "exit=$?"

OK 請求書の宛名変更: 引用3件 / 申告3件
NG パスワード再設定: 引用2件 / 申告2件 / 存在しないID 2009
exit=1

NGの行は、件数の数え違いか、IDの書き間違いか、存在しない問い合わせを作った可能性があります。どれであっても、その候補は根拠が崩れているので、Claudeに「この行のIDを実在するものだけで引き直して」と返します。終了コードが1なので、定例の作業に組み込んで見落としを防げます。

検算でできるのは、IDの実在と件数の整合までです。「そのIDの問い合わせが本当に同じ疑問か」は、IDの先を人が数件読んで確かめます。全件を読む必要はなく、候補ごとに2〜3件を抜き読みすれば、束ね方のずれは多くの場合見つかります。

公開前に人が確認する項目

候補ができても、記事として公開する前に人が見る項目があります。Claudeが苦手なのではなく、資料の中に答えが無い項目です。

最後の画面名は見落とされがちです。Projectのファイルはテキスト抽出のみなので、画面キャプチャを貼った記事の更新は、Claudeには検出できません。画面の変更を伴う更新は、担当者が実際の画面を開いて確かめます。

つまずきやすい点

もう一つは、チャットをまたいだ引き継ぎです。点検した記事の一覧を別のチャットで使うには、一覧をファイルにしてProjectに追加します。公式に、Project内でも別のチャット間で文脈は共有されないと書かれています。

チームで確認するときの共有

TeamとEnterpriseのプランでは、Projectを組織のメンバーと共有できます。権限は2つです。

• 閲覧のみ(Can view): 内容・知識・指示を見て、Project内でチャットできる。編集はできない
• 編集可(Can edit): 指示と知識を変更し、メンバーの設定を更新できる

候補の確認役には閲覧のみを、資料の差し替えを担う人には編集可を渡す、という分け方ができます。共有はOwnerが組織全体でオフにでき、Enterpriseでは役割ごとの設定もあります。共有がオフの間は、既存の共有は残りますが、新しい相手には共有できません。共有できないときの扱いは、管理者に確認してください。

個人プランでは共有の機能が使えません。確認役に見せたいときは、候補のCSVを書き出して渡します。

よくある質問

新しい版のProjectsでも同じ手順で使えますか

Claude Codeから順次提供されているProjectsの新しい版は、チャットやCowork向けの既存のProjectとは別の仕組みで、提供はベータの段階です。既存のProjectは、これまでどおり使い続けられます。この記事の手順は、チャットのProjectの知識と指示を使う前提です。

問い合わせの接続は不要ですか

この手順はCSVを書き出して渡す経路です。ヘルプデスクに直接つなぐ構成はZendeskチケット分析にあります。サポート返信の下書きの作り方はClaudeで問い合わせ返信を作るが扱っています。返金の判断ぶれを点検する方法は返品・返金の規程と対応事例の突き合わせにあります。

まとめ

問い合わせ履歴からFAQを起こす作業は、頻出質問の抽出、記事の有無の判定、記事と回答の食い違いの点検の3段で、すべて同じProjectの中で回せます。出た候補は、根拠IDの実在と件数を機械で検算し、その先の判断を人が行います。公開してよいかを決めるのは、現行の仕様と会社の判断が分かる担当者です。