「エクスポートしたファイルはどこですか」。サポートがまた答える。説明記事はあるのに、題名が「データ保管」なので見つからない。別の手順書には旧画面のメニュー名が残っている。
繰り返し質問をすべて新FAQにすれば、答えが競合する。AIによるサポートナレッジ更新では、見つけにくい、手順が古い、記事がない、方針が未決という違いを先に整理する。 Agentは改訂候補を準備し、何を公開できるかは知識責任者が決める。
Budaのサポート業務は検索、返信案、ヘルプセンター整備を含む。許可された問い合わせを具体的な更新作業に変えるところから始めたい。
六件を三つの問いへ戻す
以下は架空の教材で、実顧客、実施済み実験、実際の製品方針ではない。対象は一つのエクスポート窓口、10月12〜18日。同じチケット内の再質問は件数を増やさない。
| ID | 顧客の言葉 | 状態と確認済み根拠 | 問い |
|---|---|---|---|
| T01 | 「保存先はどこ？」 | 解決。承認済みH01 v3、第2段落 | 保存先 |
| T02 | 「ダウンロードが見つからない」 | 解決。同じH01 v3 | 保存先 |
| T03 | 「右上にボタンがない」 | 解決。承認済みP02 v4 | 操作手順 |
| T04 | 「新画面の入口は？」 | 解決。同じP02 v4 | 操作手順 |
| T05 | 「待機中に取消できる？」 | 未解決。承認済み規則なし | 取消 |
| T06 | 「キューから取り下げたい」 | 未解決。製品責任者の判断待ち | 取消 |
各群二件という数字は入力標本の数であり、顧客全体の割合や週次需要ではない。T02で三度やり取りしても一件。同じ事象が別チャネルで二件になったら関連を保存し、重複排除方法を書く。
言葉が似ていても同じ問題とは限らない。「ファイルがない」が保存場所なのか、生成失敗なのかを、操作段階、版、解決根拠で照合する。足りなければ分類保留にする。
三群あっても、新FAQが三本必要とは限らない
現在の記事と承認済み知識を照合し、四つに分ける。
- 既存だが見つからない： H01 v3は存在する。顧客の検索語を題名や関連リンクへ加え、同じ答えを複製しない。
- 手順が古い： H02の入口説明をP02 v4と比べ、該当段落と置換案、関連リンクを提出する。
- 本当に記事がない： 承認済みの解決方法があり、適切な記事がない場合だけ新規候補にする。この標本には該当例がなく、数合わせは不要。
- 方針が未決： T05とT06は問いの証拠で、取消可能という答えの証拠ではない。責任者の判断待ちに置く。
解決済みでも、一度限りの例外や個別対応は一般化できない。適用範囲と承認状態を見てから顧客向け文章へ移す。
一つの改訂から出典まで戻れるようにする
候補にはID、群、元の言葉と位置、旧記事URLまたは欠落、旧段落、承認版、製品範囲、理由、提案文、未決事項、確認役割が必要だ。
U02：T03第4段落・T04第2段落
旧文：H02第3手順、右上の入口という記述
根拠：承認済みP02 v4、第2節、新画面向け
提案：入口手順だけ置換。他の確認済み内容は維持
影響：H01からの参照、研修資料の旧説明を再確認
未決：旧画面利用者向けの手順を残すか
確認：知識責任者が適用を確認、編集者が読みやすさを確認
状態：改訂候補、未公開
H01/H02/P02は教材の識別子で実URLではない。実務では正確な許可済みURL、パス、版を使う。旧記事が見つからなければそう書き、URLを作らない。
主記事を直しても、定型文や研修稿へ自動反映されるとは限らない。古い説明の影響先を列挙する。
四つのファイルで判断を分担する
question-clusters.csvには所属ID、原句、重複除外後の件数、分類理由。update-queue.mdには動作、影響、根拠の充足、役割と未決事項。faq-drafts.mdには承認済み根拠を持つ新規・置換文だけを草稿として置く。sources.csvには工単、記事、方針版、該当位置、読取状態を残す。
優先度は顧客影響と着手可能な根拠から決め、件数は補助にする。頻出の未決方針は判断を急ぐ理由になるが、断定文を急いで作る理由ではない。
知識責任者が事実と適用、編集者が表現と操作可能性を確認する。その後も公開権限と実行は別に必要。「承認済み」というファイル名だけでは確認記録にならない。
専用Sessionで許可済みコピーだけを読む
匿名化したチケット、現行文書、承認済み一覧をBuda Driveへ置き、パス、窓口、期間を指定する。Agent DriveとSpace Driveは共有範囲が違う。Sessionを分けてもファイル権限は分かれない。
指定した匿名化資料だけを読み、繰返しメッセージを別件に数えず分類する。既存文と照合し四種類の候補と根拠、不足を四ファイルへ保存する。顧客返信、チケット変更、公開、正式文書の上書きはしない。
アップロード順で優先方針を決めない。採用する承認版を指定し、引用段落を開いて確かめる。
件数を増やす前に三つの誤りを探す
異なる操作段階が同群になっていないか。未解決票が確定方針に変わっていないか。既存記事の発見性改善で済むのに競合する答えを増やしていないか。まずこの三点を修正する。
方針競合の処理は適用判断、技術引継ぎは調査の証拠整理である。知識維持の反復方法は、後から検証可能なSkillにできる。
未解決票も更新材料になる？
問いと影響の材料にはなるが、答えにはしない。不足する規則と決める役割を残し、根拠が承認されてから草稿を作る。
同じような文ならまとめてよい？
目的、段階、版、解決根拠が一致するか確認する。情報不足は保留、別の操作なら分ける。
旧文を直すか新規にするか？
同じ意図の記事があれば入口や該当段落を直す。独立した問いで適切な記事がなく、承認済み答えがある場合に新規候補とする。
Buda AIのMarketplaceで適切なSkillを検索してインストールし、出典と未定方針の扱いを確認する。小さな匿名化標本から始め、責任者の確認後に公開を手配する。減らしたいのは表の行ではなく、次の顧客が答えを見つけられない原因だ。