この記事はLITALICO Engineers Advent Calendar 2025 カレンダー1 の 8日目の記事です
はじめに
「問い合わせ対応を生成AIで効率化しました！」系の記事・事例はすでに多くネット上に転がってはいますが、事例が多いに越したことはないだろうと思い、本記事を執筆しました！
いまはNotebookLMやgemini(Gem)、chatGPTなどのツールを土台にこういったものをつくるのが簡単な方法であると思います。
今回は、NotebookLMとGemを実際に使ってツールをつくってみて、結論、NotebookLMが今回の要件だと微妙、Gemが好感触という差があったので、その差分・比較についても触れつつ、プロンプトやその工夫を紹介できればと思います！
1. 背景と課題
私たちのプロダクトの問い合わせ対応は、以下のようなフローで行われています。
- 一次対応（CSチーム）： ユーザーからの電話・メール対応。
- 二次対応（エンジニア）： CSで解決できない技術的な調査（エスカレーション）。
ここで課題となっていたのが、「ノウハウの共有不足」 です。
エンジニアが持っている調査ノウハウや仕様の知識がCS側に伝わりきっていなかったり、CS同士でもノウハウ共有がしきれていない現実がありました。結果的に、CSだけで完結できるはずの質問もエスカレーションされてしまうケースもありました。
しかし、「今からCSメンバーに追加で技術マニュアルをインプットしてもらう」 のは、コストやリソースの観点から現実的ではありませんでした。
そこで、「CSメンバーがなるべく学習コストを払わずに、エンジニアや他のCSのノウハウを活用できるAIアシスタント」 を作ることにしました。
2. 技術選定：なぜNotebookLMではダメだったのか
当初、ドキュメントを読み込ませるだけでRAGが実現できる NotebookLM を導入しようとしました。しかし、検証を進める中で課題に直面しました。
課題：出力情報の「粒度」と「形式」
NotebookLMはドキュメントの内容を要約・回答するのは得意ですが、「出力する情報の粒度」や「回答の形式」を細かく制御するインターフェース（システムプロンプト）が当時存在しませんでした※。
そのため以下のような問題が発生しました。
- エンジニア向けの難解なドキュメントを読ませると、回答も難解になりがち。(エンジニアのノウハウもCSの一次回答に反映したいので、エンジニア向けドキュメントも読ませたい)
- CS向けの回答形式を定めても、その形式を遵守してくれない。
※(記事執筆中に確認したところ、NotebookLMに10000文字までのプロンプトをかける項目が追加されていたので、NotebookLMでも以上問題が一定解消できます。ただ、改めてNotebookLMで完成形と同様のプロンプトで試したところ、特に回答形式ルールの遵守において、Gemの方が精度が高いと感じました。)
実際にCSの方からも、「回答に専門用語が多く、利用難易度が高い」とフィードバックがありました＞＜
そこで、システムプロンプトによって出力情報の粒度や役割（ペルソナ）を固定できる Gem への移行を決断しました。
3. 解決策：実際のGemプロンプト
概要
先述のNotebookLM版での課題を解消すべく、主に２つの軸でプロンプトを書いています。
- CSが入力した「対話ログ」に対し、「技術的な背景」 と 「CSが取るべきアクション」、**「開発にエスカレすべきか否か」**という回答形式をさだめ、CSの一次対応で必要な情報のみを簡潔に返すようにした。 (回答形式の遵守に関しては、プロンプトを書けるようになった今のNotebookLMと比較しても依然Gemのほうが精度が高いと感じています)
- 回答に専門的すぎてCSにそのまま返すには難解な回答になりがちな問い合わせカテゴリに関しては、ドキュメント側に
<task>タグを設定し、それをGemが読み取ることで補足情報を返すようにした。(ここは今のNotebookLMならできる。ただ、ドキュメント外の情報が必要な<task>を定義した場合はGemに軍配が上がる)。
2については、たとえば、「ブラウザのキャッシュクリアをユーザーに案内する」という情報をCSに返すときに、ドキュメント側に、以下のような記載をしたうえで、Gem側で<task>タグの補足をちゃんと考慮するようにプロンプトを書いています。
課題: ログインできない
対応: キャッシュクリアの案内
ブラウザに残っているcookieデータを削除。
<task start>
Google Chrome, Microsoft Edgeにおける、cookieデータ削除フローを箇条書きで丁寧に説明
e.g. まず右上の三点メニューを開きます。
<task end>
実際のプロンプト(一部省略)
# ペルソナ
あなたはLITALICO教育ソフトのプロフェッショナルシステムサポートです。
# タスク
- 対話ログを入力するので、CSの対応について教えてください。
- 対話ログの「事象」と「エラーコード」の項目に特に注意してください。
- ドキュメントに、「<task>」に囲まれたプロンプトがある場合は、その指示も加味してください
# 知識の重要度
- 問い合わせ対応マニュアルの「問い合わせ種別ごとの対応フロー」の内容を優先してください。
- 対話ログにエラーコードがある場合は、「エラーコード対応表」の内容も加味してください。ただ、あくまで、「問い合わせ種別ごとの対応フロー」の内容が最優先です。
# 対話ログの形式
(プロンプトの本筋と関係しないので省略)
# 出力形式
## 何が起きているか、技術的背景
- 事象を端的に説明し、技術的背景も説明する
## CSが対応すべきアクションは何か
## 開発にエスカレすべきか否か
# 出力に関しての注意
- 出力形式に定めた項目に特化してください。
- どのドキュメントのどの項目を参照した、などの余計な情報は含めないでください。
- 未知の事象については、未知であることを明確に伝えてください。そのうえでエンジニアへのエスカレーションを促してください。
# コンテキスト
- 質問者は、ユーザーからの問い合わせを受電にて一次対応をしています。
- LITALICO教育ソフトは、まなびプランDT版（デスクトップ）、まなびプランweb版、まなび教材、まなび動画 で構成されています。
4. プロンプト上の工夫詳細
以下書籍やネット上の情報をもとに、以下の工夫をしました。
LLMのプロンプトエンジニアリング
① Google公式プロンプト構成の流用
Googleが推奨するプロンプト構成（ペルソナ → タスク → コンテキスト → 制約事項）をベースに構築しました。構造化することでGemが指示を理解しやすくなり、回答の安定性が向上します。
https://support.google.com/gemini/answer/15235603?visit_id=639006755950266853-835219159&p=custom_gems&rd=1
ただ、今はGemの編集画面にプロンプトを調整するgeminiが組み込まれており、それを利用するだけで勝手にこの形式に近い形に整形してくれるので、あんまり人間が気にしなくてもいいかもしれません。
② 知識の優先順位付け（Priority）
複数のドキュメント情報が競合して、回答がカオスになることがありました。
ここでは 問い合わせ対応マニュアル > エラーコード表 という優先順位を明確に指示しました。これにより、エラーコード上は「要調査」となっていても、運用マニュアルに「再起動で直る」とあれば、そちらを優先して回答できるようになります。
③ <task>タグによるドキュメント側からの制御
システムプロンプトですべてを指示するのではなく、読み込ませるドキュメント（マニュアル等）の中に <task>ここに特記事項</task> というタグを埋め込みました。
そしてプロンプト側で「<task>タグがある場合はその指示も加味せよ」と指示することで、問い合わせカテゴリごとの個別事情をGemに柔軟に対応させています。
④ 入力情報の形式化とフォーカスするポイントの明示
「対話ログ」と呼ばれる、CSが一次応対する際のユーザーとのやりとりのログがあるのですが、それを貼り付けるだけで回答できるようにしたい要望がありました。
対話ログの形式をCSから共有いただき、そのなかでどこに注目させるか(今回は「事象」と「エラーコード」)を明示することで、入力された情報をAIがより洗練して使えるようにしています。
⑤ ロールプロンプティング
「プロフェッショナルシステムサポート」というペルソナを与えることで、回答の精度や責任感（のようなもの）が向上すると言われています。Role Promptingなどというようです。
⑥単体テスト
プロンプトを修正するたびに同じログを入力して出力の変化を見る「手動単体テスト」を繰り返し、ハルシネーション（知ったかぶり）や情報の粒度を調整しました。
2年半ほどエンジニアとして問い合わせ対応経験がある私自身が出力の精度をチェックし、ある程度形になったら、実際のCSの方に試用してもらってフィードバックをもらうという流れでプロンプトを調整しました。
5. 回答例
入力
- ソフトを開こうとしたらエラーが出た。何回かやり直したり、ユーザーを作り直したりした。エラーコード：13-002202
出力
ファーストアクションとして謝罪から入る、といったCS側のノウハウと、技術的な仕様などのエンジニア側のノウハウを上手に組み合わせて回答してくれています！
6. 最後に余談
CSチームに展開した時期が悪く、あまり問い合わせが来ない時期に展開したので、まだ多くのフィードバックをいただけてはないのですが、使っていただいた事例では良い反応がありました。
また、これを契機に、CSチーム内で別の観点でのGemを内製しようという動きになったようなので、そういう意味で一つの着火剤になれたのもよかった！
私自身完璧主義なところがあり、いろいろ試行錯誤している中で、CSのみなさんに展開するのが遅れてしまったのですが、同世代のPdMに相談したところ、「さっさと展開してフィードバックもらってから改善すべき」と尻を叩かれ、一旦リリースすることができました。
CSの方が電話しながら使うには、回答生成が少し遅い、など課題がまだあるツールなので、どんどん進化させられたらと思います！