1. リリースしてから始まるCSチームのデスマーチ

新機能のリリース日。
開発チームが祝杯をあげている裏で、CSチームのSlackが悲鳴を上げている光景を何度見てきたことか…

「マニュアルに書いてあるのに！」
「画面を見ればわかるだろう！」

叫んでも、問い合わせの波は止まりません。
CSは常に「後手に回る」宿命にあるのでしょうか？
いえ、攻めのCSは、問い合わせが来る前にその芽を摘みます。

今回は、NotebookLMを単なる「要約係」ではなく、ユーザーのつまずきをシミュレーションする「予知マシン」として使う方法を解説します。

チャットボット導入のような大掛かりな開発は不要です。
必要なのは、既にある「仕様書」と、Geminiが生み出す「性格の悪い仮想ユーザー」だけです。

2. なぜ、マニュアルは読まれないのか

リリース直後にサポートセンターがパンクする原因の8割は、「マニュアルの3行目に書いてあること」です。

現場は「なんで読んでくれないんだ」と嘆きます…
しかし、これはユーザーの怠慢ではありません。
わたしたちの敗北です。

仕様を熟知したわたしたちは「知識の呪縛（Curse of Knowledge）」にかかっており、「ここを押せばこうなる」が当たり前すぎて、初めて触る人間がどこでフリーズするか想像できなくなっているのです。

結果、問い合わせが来てからFAQを追加する「モグラ叩き」が始まります。
この悪循環を断ち切るには、リリース前に「ド素人の目」で製品を監査する必要があります。

3. 「データがない」を言い訳にしなくても大丈夫

「うちは中小だから、立派なペルソナ定義なんてないよ」
そう思ったあなたこそ、この手法の対象です。

NotebookLMに「仕様書（正解データ）」と「ペルソナ（視点データ）」の2つを食わせて化学反応を起こすのが基本戦略ですが、この「ペルソナ」データがないなら、AIに作らせればいいのです。

従来のペルソナは、履歴書・職務経歴書のようなきれいなフォーマットにダミーの顔写真が貼られ、様々な仮の個人情報が記載されているものでしたが、AIが半自動的にペルソナ生成するこの手法は、「シンセティック・ペルソナ（合成顧客）戦略」と呼ばれています。

1. Gemini（チャット）：想像力を活かし、実在しそうな「厄介なユーザー」を創造する。
2. NotebookLM（ノートブック）：そのユーザーになりきって、仕様書の不備を指摘させる。

ここではAIの役割分担が非常に重要です。
Gemini単体でレビューさせると、仕様にない機能を勝手に妄想して批判し始める（ハルシネーション）リスクがあります。
一方で事実に忠実であろうとするNotebookLMは、ゼロイチからペルソナを作るような創造は苦手です。
Geminiにペルソナを作らせ、NotebookLMに検証させる。
この連携が鍵となります。

4. 実践プロンプト

では、具体的な3ステップです。
今日からWeb担当者に渡せるレベルに落とし込みました。

ステップ 0：仮想の敵「佐藤さん」を召喚する（at Gemini）

まずはGemini（ChatGPTでもClaudeでもお好みのLLMで大丈夫です）を開き、以下のプロンプトで「視点データ」を作成します。

📌 プロンプト例

あなたは、ある中堅企業の営業部で20年働いている50代のベテラン社員「佐藤」になりきってください。
佐藤はITツールが苦手で、新しいシステム導入に対して極めて懐疑的です。
「Excelと電話で十分だ」「これ以上仕事を増やすな」と考えています。


今度導入される「新しい営業管理ツール」に対して、佐藤が抱いている不安、不満、そして「こういう操作は絶対にできない（やりたくない）」という愚痴を、**佐藤の一人称で、感情を込めて2000文字程度の文章（独白）**にしてください。

なかなかこれまで書いたことのないようなプロンプト例ですが、想像の斜め上をいくレベルで、ベテラン佐藤さんの愚痴の塊が生成されますので、お試しあれ。

CSの方が卒倒しないように、事例の添付は一部のみで…（編集部は今回Claude先生にお願いしてみました）

ステップ 1：躓きポイントの抽出（at NotebookLM）

ここからが本番です。
NotebookLMを開き、「ソースA：機能仕様書」と、先ほど作った「ソースB：佐藤氏」の両方をアップロードしてください。

ご覧ください…
アップしただけで、この顔文字😩が自動生成されています…

では気を取り直して、こう問いかけましょう。

📌 プロンプト例

ソースBペルソナの「佐藤氏」が、ソースAの基本設計書仕様にある機能を利用しようとした際、用語の意味がわからず操作に迷うポイント、または誤操作しそうな箇所を5つ挙げてください。

AIはこう答えるはずです。
「佐藤氏は『二段階認証』という言葉だけで拒否反応を示し、アプリのインストール手順で確実に脱落します」。
これが、開発者視点では見えなかった（見たくなかった）「真実」です。

ステップ 2：翻訳されたFAQの作成（at NotebookLM）

ちゃぶ台をひっくり返したい気持ちをぐっと堪え、あぶり出した摩擦ポイントを、即座にコンテンツ化しましょう。

📌 プロンプト例

挙げられた5つのポイントについて、Webサイトの「よくある質問」に掲載するためのQ&A原稿を作成してください。
回答はソースAの仕様に基づいて正確に記述しつつ、専門用語を使わない平易な言葉（佐藤氏でも理解できる表現）に書き換えてください。

これで、「認証アプリ」という言葉を使わず、「スマホに届く6桁の数字」という言葉を使った、現場の手触り感のあるFAQが完成します。

5. 現場運用のためのTIPS：ノートブックの「分割統治」

実際に運用を始めると、数百ページに及ぶ仕様書をすべて1つのノートブックに放り込みたくなるかもしれませんが、それは言うまでもなく悪手です。

NotebookLMは大量の情報を処理できますが、情報量が多すぎると「ログインの話」をしているのに「決済の仕様」を参照してしまうなど、検索精度（Focus）がブレる可能性があります。
CSの現場運用としては、以下のようにノートを分割することを推奨します。

• ノートA：アカウント・ログイン周り（全ユーザー対象）
• ノートB：管理画面・設定周り（管理者対象）
• ノートC：決済・契約周り（経理担当対象）

機能やUI、あるいはディレクトリ単位でノートを分け、それぞれに適した「ペルソナ（佐藤さん、経理の田中さん等）」をぶつけることで、より精度の高い予知が可能になります。

6. この施策の「出口」戦略

この手法で作ったテキストデータは、単なる「よくある質問ページ」で終わりません。
ここには明確な進化のロードマップがあります。

Level 1：静的FAQの実装

まずはWebサイトや管理画面に、今回作ったQ&Aをシンプルなテキストやモーダルウィンドウで実装します。
「ゼロ次解決率」を上げ、CSの電話を鳴らさないことが第一歩です。

Level 2：データのブラッシュアップ

実際にクリックされた数や、それでも来てしまった問い合わせを分析し、NotebookLM内の「ソースB（ペルソナ）」や「FAQリスト」を更新します。

Level 3：AIチャットボットへの進化

磨き上げられたFAQデータがあれば、それをRAG（検索拡張生成）のソースとして読み込ませるだけで、高精度な社内用/顧客用チャットボットが完成します。

いきなりAIチャットボットを作ろうとするから失敗するのです。
まずはテキストデータという「資産」を作る。
そうすれば、時代（DX）のほうが勝手に追いついてきます。

リリース日の夕方、CSチームが涼しい顔で定時退社するために。
まずはGeminiで「御社のラスボス」を生成するところから始めてみてください。

7. NotebookLM利用時の留意点

1. 環境: NotebookLMおよびGeminiは、Google Workspace（有料版）環境下で利用し、データがAIの学習に利用されない設定を確認してください。
2. 加工: 仕様書に含まれる機密情報（APIキー、顧客名等）は、アップロード前に必ずマスキング処理を行ってください。
3. 検証: 生成されたFAQは、必ず技術担当者が事実確認を行ってください。「わかりやすさ」と「正確さ」のトレードオフが発生していないかチェックが必要です。