学習の目標
- マニュアル・規程・仕様から自己解決型FAQの初稿をカテゴリ付きで得られる。
- 「想定読者」「避けるべき断定」「例外ケース」をプロンプトに埋め込み、抜けを減らせる。
- 公開前のサンプリング検証と版管理の型を回せる。
前提条件
- 一次ソースがPDFまたはテキストで揃い、旧版と混ざらない。
- 対象読者のリテラシー（社内向け／顧客向け）が決まっている。
- レビューを依頼できる担当（プロダクト・法務・サポート等）が机上にいる。
キーコンセプト
- 読者レイヤー: 専門語には必ず「一言＋例」をセット。略語の初出ルールをAIにも明示。
- 優先度＞網羅: 全問平等に丁寧にしない。問い合せログがあれば頻度順を先に取る。
- 例外の型: 「If 条件 → Then 手順 → Else 窓口」の三段をテンプレ化。
- 出典の見える化: 回答末尾に「根拠段落の要約＋参照」が無いFAQは外部公開しない。
手順（実践ステップ）
- 冒頭ブロック: 読者1行・禁止表現・トーン（です／ます等）を毎回貼る。
- ソース絞り込み: ノートブックに迷子資料を入れない。FAQ専用に分ける。
- 骨格: カテゴリ案 → 各カテゴリ上位10問 → 例外ブロックの順で生成。
- 整形指示: 「各Aに出典引用」「不明時は○○窓口へ」と必ず付ける。
- リスクフラグ: 返金・契約・医療・法解釈などは別表で人手高優先。
- サンプリング検証: 設問15なら最低5問を原文照合。ランダム抽出推奨。
- 公開フロー: Confluenceやヘルプセンターへ載せる場合、改訂日と責任者をヘッダに。
演習課題
- 15問ドラフトから5問を無作為抽出し原文照合。1問でも齟齬があればプロンプトのどこを直すかメモせよ。
- 「誤解されやすい用語」を3つ選び、公式定義との差分を自分の言葉で1行ずつ修正せよ。
自己チェックリスト
- [ ] 各回答にソース根拠がある
- [ ] 不明点の逃げ道が書かれた
- [ ] 高リスク項目が別表化された
- [ ] 公開先と権限が決まった
- [ ] 旧版FAQとの差分が分かる
- [ ] 画像・スクリーンショット要否が決まった
- [ ] SLA（回答レビュー日数）が設定された
つまずきポイント（避けたい落とし穴）
- 資料不足で捏造: 足りないならFAQではなく「仕様追記タスク」。
- 混ぜ物一次情報: ブログと公式版が混在するとユーザーが犠牲。
- ゼロレビュー公開: クレームの元。
まとめ
FAQは文章生成より問いの設計と根拠の見せ方が価値の核です。NotebookLMは初稿を短時間で出し、人は優先度・リスク・文体を仕上げます。
振り返りの問い（任意）
- 今回のFAQで、実際の問い合わせログとズレている問いはなかったか。
- 「不明」と書くべきところを無理に埋めていないか。
- 次の版で必ず追記したいソースは何か。
ミニレクチャー（20分）
サポート向けFAQを想定する。最初に「読者スキル」「禁止断定」「誤答時のエスカレーション先」を3行で貼る。資料はマニュアル本体とリリースノートだけに絞り、ブログは捨てる。生成後、ランダム5問についてリンク付きで公式段落を開き、回答の動詞が強すぎないかをチェック。「〜できません」など否定形は法務と相談。公開前にステージング環境へ貼り、検索クエリでヒットするかだけテストする。最後に改訂履歴テーブルへ日付と担当を1行追加する。FAQは生き物なので、NotebookLMノートブック自体にも source_version メモを残し、次回差分が追えるようにする。
公開チャネルが複数（ヘルプセンター・アプリ内・営業資料）にある場合、同一回答の重複管理表を別スプレッドシートに置き、NotebookLMにはその表をソースとして追加する方法もある。ユーザーからのスクショ付き問い合わせをFAQ化するときは個人情報をマスキングした別ファイルだけ投入し、原本は保持しない。大型アップデート前後は、旧FAQノートブックを読み取り専用アーカイブに切り離し、新マニュアルだけの清浄ノートを作ると取り違えが減る。
ツール・参考リンク
権利表記
NotebookLMは各社の商標または登録商標です。本記事は公式提供ではなく、一般的な情報提供を目的としています。
画像クレジット
サムネイル画像はUnsplashのライセンスに基づき使用しています。
お問い合わせ
AIツールの導入・活用支援のご相談はお気軽にどうぞ
📞 090-6262-3842