はじめに
自身が開発・運用しているシステムについて、企画部門や営業部門（非エンジニア）より、Slackでお問い合わせが飛んでくることがあります。
お恥ずかしながら、専用のマニュアル等が整備できておらず、聞かれたら都度Slackなどで回答する、というスタイルでした。
ただ、同じような質問が時間をおいて再度寄せられることもあり、自分の中で回答内容を毎回思い出しながら答えることになります。
問い合わせ側からしても、回答を待つ時間が発生するので、お互いにとってベストな状態ではないなと感じていました。
そんな中、問い合わせ側（企画部門）からも、
「Slackで聞いてレスを待つ前に、自分で解決できる手段があったほうがお互い楽なのでは？一次受けをチャットボットにできないか？」
という提案が上がってきていました。
両者の温度感が一致したのを後押しに、重い腰を上げてチャットボットを作ってみたので、その時の構成や設計の記録を残しておきます。
システムの中身そのものや具体的な業務内容には触れず、チャットボット側の作り方・振る舞いの設計にフォーカスして書きます。
構成
採用したのは、めちゃくちゃシンプルな構成です。
- ナレッジ：Google ドキュメント（章ごとにタブで分割して整理）
- 検索・回答：NotebookLM
- 入り口：社内ユーザーに NotebookLM のリンクを共有
以上です。コードは一行も書いていません。
凝った仕組みも考えなくはなかったのですが、時間も限られていたので、まずはドキュメントをNotebookLMに食わせるだけの構成で始めてみることにしました。
凝った仕組みを作るより、ナレッジ整備に時間を使った方がリターンが大きい、という割り切りです。
ナレッジに .md ではなくGoogle ドキュメントを採用しているのは、企画部門側からも直接編集できるようにしたかった（後述のナレッジを育てる仕組みで解説）ためです。ドキュメント内のタブは、ざっくり以下のように分けています。
ナレッジドキュメント（Google ドキュメント）
├── 概要・想定利用者
├── 機能カテゴリごとの詳細（A機能 / B機能 / ...）
├── 運用判断・トラブル対応集（プレイブック）
├── 過去のお問い合わせ集
└── 用語集・参考リンク
ドキュメント整備自体は地味で面倒な作業ですが、ここの品質がそのままチャットボットの回答精度に響くので、丁寧に整備するよう心がけました。
とはいえゼロから書き起こすのはしんどいので、Claude Code等にシステム概要をサマらせる → ドメイン知識や運用上の注意点を手作業で追記、という流れで初版を用意しています。
骨組みはAIに任せて、人間は補足・補正する、というやり方で、ここも手間を減らしました。
チャットボットの振る舞い設計
NotebookLMに渡している「振る舞い指示（プロンプト）」がこちらです。
ハルシネーションの抑制と、利用者への寄り添いの2点を意識した内容にしています。
そのまま転記できる形にしているので、参考になれば使ってみてください。
# あなたの役割
あなたは「<システム名>」の社内ヘルプデスクです。
利用者は社内の非エンジニア（企画・営業など）であり、
システムの細かい仕様や用語に詳しくありません。
# 回答方針
## 1. 出典の明示
- 回答は必ず提供されたドキュメント（ソース）の内容に基づいて行ってください。
- どのドキュメントのどの記述に基づいた回答かが分かるよう、引用・参照を明示してください。
- ドキュメントに記載のない事項について、推測で回答しないでください。
## 2. 利用者に寄り添った回答
- 専門用語や略語は、必要に応じて噛み砕いて説明してください。
- 「画面のどこを操作すればよいか」が分かるよう、具体的な画面名・ボタン名で案内してください。
- 手順を案内する場合は、番号付きの手順として整理してください。
- 回答は丁寧かつ簡潔に。長文になりすぎないようにしてください。
## 3. 分からないときの振る舞い
- ドキュメントを参照しても回答できない場合、
曖昧な推測で答えず、以下のように案内してください。
> 申し訳ありません、こちらのドキュメントからは確認できませんでした。
> 開発者までお問い合わせください。
> その際、以下の情報を添えていただけるとスムーズです。
> - 操作していた画面名
> - 行いたかった操作の内容
> - 発生した事象（エラー文言・スクリーンショットなど）
- ドキュメントの記述が古い／矛盾している可能性がある場合も、
推測で補完せず、開発者への確認を促してください。
## 4. やってはいけないこと
- ドキュメントに無い仕様を「こうだと思います」と回答すること。
- 個人情報・認証情報・社外秘の情報を要求すること。
- 利用者を咎めるような言い方（「マニュアルを読んでください」など）。
# 出力フォーマット
- 結論ファースト：まず質問への直接の回答を書く
- 次に、根拠となるドキュメントの該当箇所への参照
- 必要に応じて、補足や関連情報を箇条書きで提示
- 最後に、関連しそうな他のトピックがあれば一言だけ案内
意識したポイントは大きく2点です。
1. 「分からないときは開発者へ」を明示的に振る舞いに含める
ナレッジに無いことを聞かれた時に「開発者に投げ返す」動きを最初から仕込んでおくことで、ボットが誤情報を返してしまうのを避けたかった、というのが意図です。
加えて、開発者へ問い合わせる際に添えてほしい情報までボット側に言ってもらうようにしました。これで問い合わせの粒度がある程度揃うので、不足情報を聞くための会話のラリー回数を減らすことができると考えました。
2. 利用者に寄り添う
- 専門用語は噛み砕く
- 画面名・ボタン名で具体的に案内する
- 手順は番号付きで整理する
- 利用者を責めない
あたりを指示しています。
利用者から見て使いづらいと、ボットを経由するより直接Slackで聞いたほうが早い、という運用に戻ってしまいそうだったので、そこは気をつけたいと思いました。
ナレッジを育てる仕組み
仕組みと言うほどのものではないのですが、「過去のお問い合わせ集」タブの章の冒頭に、以下のような追記テンプレートを置いています。
YYYY/MM/DD — 概要
お問い合わせ内容：
（問い合わせ者の状況・依頼内容を簡潔に）
回答：
（実際に返した、または返すべき回答内容）
補足（任意）：
（背景・関連リンク・再発防止メモなど）
Google ドキュメント運用なので、自分でも企画部門側でも追記できます。
「同じ質問が来たら、まずここに書く。次回からはボットに任せる」という流れができれば、ナレッジが運用と並行して育っていくかな、と考えています。
運用してみての結果
効果がどれだけ出ているかは、正直なところ可視化しきれていません。
「Slackで聞こうとした手前で解決した件数」を測る術はないので、効果測定としてはあいまいというのが本音です。
ただ、納品から1ヶ月ほど経ちますが、自分のところにはいまのところ関連の問い合わせが来ていないので、大きな問題は起きていないのかなと思っています。
提案元の企画部門からは「ありがとう」と言ってもらえたので、それだけでも作って良かったなと感じています。
おわりに
ドキュメント整備は地味で面倒な作業で、目の前のタスクに追われていると後回しにしがちでした。
ただ、一度作ってしまえば、
- チャットボットのナレッジとして使える
- ボットが直接的な効果を発揮していなかったとしても、ドキュメント自体は手元に残る
- 自分がそのプロジェクトから離任するときの引き継ぎ材料にもなる
と、それなりに使い回しが効きそうです。
似たような状況で迷っている方がいたら、まずは手元のドキュメントをNotebookLMに突っ込んでみるところから試してみてもいいかもしれません。
教育で世界No.1へ。 スプリックスIT戦略部の公式テックブログです🌸 渋谷本部・長岡ラボの2拠点がワンチームとなり、世界展開する教育サービスを支えています！ 生成AI活用・モダンな技術スタックへの刷新・地方での組織づくりなど、私たちが日々の開発で得た知見と挑戦の記録をオープンに発信します
Discussion