製品文書は仕組みを説明しますが、顧客は「出力できるか」「解約後はどうなるか」「誰が見られるか」と状況を尋ねます。AIは文書を読みやすいFAQの下書きにできます。ただし、条件を保ち、資料にない答えを作らないことが大切です。
Infobaseは繰り返し使う情報源、Skillは作業の指示を担当します。両者を分けると、資料の更新と文章作成のルールを別々に管理できます。
承認済み資料と質問テーマを集める
現在の製品ガイドと規程を使い、古い版を除きます。責任者や適用日が分かれば、曖昧な点を確認しやすくなります。問い合わせからテーマを集める際は、不要な個人情報をコピーしないでください。
単発なら直接添付で十分です。定期的に更新するFAQにはInfobaseガイドに沿った資料集を使えます。
回答の条件を伝える
選択した承認済み製品文書からFAQを作ってください。
読者：[対象]。質問テーマ：[一覧]。
各項目に質問、短い答え、可能なら文書名と箇所、重要条件を示してください。
資料で確かめられる内容だけを使い、規程、価格、上限、安全性の保証、日付を作らないでください。
未回答や矛盾する質問は確認一覧に分け、公開文と内部メモを分離してください。
繰り返すならSkillsガイドに従って保存できます。
少数の例で確認する
次は架空の編集例で、Studio Globalの規程や実測出力ではありません。
資料：プロジェクト所有者はタスク一覧をCSVで出力できます。アーカイブ済みタスクは含みません。
適切な答えは「所有者がCSVでタスク一覧を出力できます。ただしアーカイブ済みタスクは含まれません」です。
「全員がすべてのプロジェクトデータを好きな形式でダウンロードできます」では、権限、範囲、形式を増やし、例外を削除しています。自然な文章でも根拠と一致しません。復元可否など資料にない質問は、製品担当者へ確認します。
内部の根拠表を残す
| 項目 | 目的 |
|---|---|
| 顧客の質問 | 実際の必要に対応する |
| 承認済み回答 | 公開する表現を記録する |
| 根拠資料 | 確認者が照合できる |
| 条件と例外 | 誤解を招く簡略化を防ぐ |
| 確認者と日付 | 責任を記録する |
内部パスや機密メモは公開FAQに含めないでください。公開資料は必要に応じてリンクし、非公開の証拠は許可された確認手順内で扱います。
方針を変えずに読みやすくする
先に直接の答えを示し、用語を説明し、長文を短くします。短くするために必要条件を削ってはいけません。大きな修正にはDocumentsを使えます。Brand Voiceは文体を助けますが、事実の承認は資料と担当者に基づきます。
公開は自社サイトやヘルプセンターの通常の手順で行います。チャットでFAQを作っても、外部システムへ自動配信されるわけではありません。規程変更や繰り返す混乱があれば再確認してください。