NotebookLMを社内ナレッジ検索として活用し、仕様問い合わせを半減した話

こんにちは。システム開発部のsonohaです。
ニフティ温泉のWEBサイトの開発全般を担当しています。

今回は、非エンジニアから寄せられるシステム仕様に関する問い合わせ対応を、NotebookLMを使って省力化してみた取り組みについて紹介します。

ニフティ温泉では、開発チームがフルサイクルで開発保守運用に携わっている関係上、
企画・営業・カスタマーサクセスなど、さまざまな職種のメンバーからシステム仕様に関する問い合わせを受けることがあります。

もちろん、サービスをよりよく運用していくために必要なコミュニケーションではあります。

一方で、集中して設計や実装をしている最中に問い合わせ対応が入ると、どうしても思考の切り替え（コンテキストスイッチ）が発生し、開発の生産性に影響が出てしまうという課題もありました。

そこで今回は、GitHub CopilotやNotebookLMを使いながら、仕様問い合わせ対応を少しでも効率化できないか試してみました。

目次

---

仕様問い合わせは、ソースコードの深い紐解きが必要なケースが多い

まず、どのような課題があったのかを整理します。

非エンジニアからの問い合わせは、単純な仕様確認だけではありません。

たとえば、

• この条件のとき、画面には何が表示されるのか
• この購入経路の場合、メール配信対象に含まれるのか
• 管理画面で更新した内容は、どのページに反映されるのか
• 特定のキャンペーン設定と既存機能が組み合わさったとき、どう動くのか

といった、実装やデータ構造を確認しないと正確に答えにくいものもあります。

もちろん、すべての仕様がきれいにドキュメント化されていれば理想的です。
しかし、長く運用されているサービスでは、すべての機能や例外、過去の経緯を常に最新状態で維持することは現実的に難しいです。

特に問い合わせとして上がってくるものは、よく使う主要機能というよりも、ニッチな機能やエッジケースであることが多くあります。

そのため、最終的にはソースコードを読みに行き、条件分岐やDBの値、外部連携の仕様を確認することが少なくありませんでした。

GitHub Copilotにソースコードを調査させてみる

弊社では、GitHub Copilotを使った開発業務を推進しています。

そこで最初に試したのは、GitHub Copilotを使ってソースコードを調査する方法です。

問い合わせ内容をもとに、関連しそうな処理をCopilotに探してもらい、該当するコードの要約や仕様の説明を出してもらいます。

これは一定の効果がありました。

これまでやっていたような「人間がgrepして、関連ファイルを開いて、処理を追っていく」という地道な作業よりも、最初の取っかかりを見つける速度はかなり上がります。

一方で、運用してみるといくつかの課題がありました。

複数リポジトリをまたぐ調査が少し面倒

システムによっては、フロントエンド、バックエンド、管理画面、バッチ、外部連携などが別リポジトリで管理されています。

ローカル環境でCopilotを使う場合、リポジトリをまたいだ仕様調査はどうしてもシームレスさに欠けます。

回答がエンジニア向けになりやすい

Copilotはソースコードをもとに説明してくれるため、クラス名、メソッド名、DBカラム名、フラグ値などが多く含まれた回答になりがちです。

エンジニアが調査するには便利ですが、そのまま企画・営業・カスタマーサクセスのメンバーに共有できる形にはなりません。

プロンプトの工夫である程度の整形はできますが、最終的には、私が非エンジニア向けに言い換える必要がありました。

つまり、GitHub Copilotは「エンジニアがソースコードを調査する時間」を短縮するには有効でしたが、「非エンジニアが自分で仕様を確認できる状態」を作るには、もう一工夫必要でした。

NotebookLMを仕様問い合わせの入口にしてみる

次に試したのが、NotebookLMです。

NotebookLMは、アップロードしたドキュメントやWebページなど、与えられたソースをもとに回答を生成してくれるAIツールです。

今回やりたかったことは、非エンジニアが直接ソースコードを読むことではありません。

問い合わせが発生したときに、まずAIに聞けばある程度の仕様がわかる状態を作ることです。

そこで、NotebookLMを「仕様問い合わせの一次回答者」のように使えないか試してみることにしました。

以下で、各要素の役割やポイントを説明していきます。

ソースコードをそのまま読ませるのではなく、仕様ドキュメントを作る

NotebookLMは、GitHub Copilotのようにリポジトリ内のソースコードを直接読みに行く用途には向いていません。

そのため、先にGitHub Copilotでソースコードから仕様を要約したドキュメントを作成し、それをNotebookLMのソースとして登録することにしました。

ドキュメントの内容としては、以下のような情報をGoogleドキュメントにまとめています。

• ユーザー体験（UX）視点の挙動定義
  • コード上の条件分岐を「画面上で何が起きるか」に翻訳した資料です。
  • エラーメッセージの表示タイミングや、ボタンの活性・非活性条件など、ユーザーの目に触れる挙動を網羅します。
• ビジネスロジックの判定基準
  • DBのステータス遷移やバリデーションロジックを「業務上のルール」として整理した資料です。
  • 例えば「キャンセル可能な条件」など、複雑な条件分岐をエンジニア以外も判断できるマトリクス形式などで言語化します。
• オペレーション・運用仕様
  • 管理画面での操作権限や、外部システムとの連動フローをまとめた資料です。
  • カスタマーサポートや営業担当が、トラブル時に「どの画面で何を確認・操作すべきか」を迷わないための手引となります。
• データ定義とビジネス指標
  • ログやDBに記録される値が、集計時にどのような意味を持つのかを定義した資料です。
  • 「売上として計上されるタイミング」や「KPIとしてのカウントルール」など、分析や経理処理に必要な情報の裏付けを明文化します。

作り方としては、次のようなプロンプトを使ってGitHub Copilotに依頼しました。

以下は、UX視点の挙動定義ドキュメントの例です。

@workspace
あなたはUI/UXに精通したフロントエンドエンジニア兼テクニカルライターです。
このリポジトリに含まれるXXXXのフロントエンド実装から、ユーザーの操作に対するシステム側の場合分けを抽出し、非エンジニア向けにMarkdownでまとめてください。

バックエンドの複雑な処理や技術的な用語は省略し、「画面上で何が起きるか」「ユーザーにどう見えるか」に焦点を当ててください。

以下の項目を必ず含めてください：

1. XXX画面におけるユーザーのアクションフロー（例：情報入力 → 確認画面 → 送信ボタン押下）
2. フロントエンドから外部サービスへ直接通信している処理
3. 画面上にエラーメッセージが表示される条件（入力エラー、処理失敗など、どのような場合にどんなメッセージを出すか）
4. ローディングや画面遷移のタイミング

以下の項目は含めないでください：

1. XXXに関する情報

これで生成されたドキュメントを叩き台として、業務判断に必要そうな情報に不足があれば、適宜追記を行います。

ここで重要なのは、ソースコードの内容をそのまま貼るのではなく、問い合わせ対応に使いやすい粒度で仕様に変換することです。

コードの構造をすべて説明する必要はありません。
むしろ、非エンジニアが知りたいのは「実装がどうなっているか」ではなく、「業務上どう判断すればよいか」です。

そのため、ドキュメントを書くときも、なるべく技術的な言い回しは排除し、業務上の言葉に寄せるようにしました。

Googleドキュメントにまとめて、チューニングしやすくする

仕様ドキュメントは、Googleドキュメントにまとめることにしました。

理由は、回答品質を見ながらソースをチューニングしやすくするためです。

NotebookLMに仕様を読み込ませてみると、最初から完璧な回答が出るわけではありません。

ソースコードを仕様ドキュメントに抽象化する過程で細部が削がれてしまい、特にエッジケースに関する質問に対しては、実際の仕様とは少しずれた回答になることがあります。
（たとえば、「通常はA」と書いていたものの、実際には「条件XのときだけB」という例外があり、その例外が問い合わせで重要になるようなケースです。）

その場合は、NotebookLMの回答を見ながら、元のGoogleドキュメントに例外条件や補足説明を追記します。
そのうえで再同期し、次回以降の回答品質を改善していきます。

つまり、NotebookLMを入れて終わりではなく、問い合わせが発生するたびにドキュメントを少しずつ育てていく運用です。

社内ドキュメントだけでなく、公開情報もソースに加える

NotebookLMのソースには、ソースコードを要約した作成した仕様ドキュメントだけでなく、Web上に公開されている情報も加えました。

たとえば、自サービスのヘルプページ（https://support.onsen.nifty.com/hc/ja）です。

ヘルプページには、ユーザー向けに整理された仕様や注意事項が掲載されていますし、社外向けドキュメントということもあり比較的に情報の鮮度が保たれています。

非エンジニアからの問い合わせも、最終的にはユーザー向けの説明に通ずることが多いため、ヘルプページを参照することには意味があります。

また、開発で利用している外部モジュールや外部サービスに関してWeb上に公開されている公式ドキュメントも、必要に応じてソースに加えています。

これにより、社内仕様だけでなく、外部仕様に依存する部分もあわせて確認できるようになります。

問い合わせ対応は体感で半分ほど減った

実際に運用してみると、システム仕様に関する問い合わせは体感で50%ほど減りました。

もちろん、すべての問い合わせが無くなったわけではありませんが、
これまでエンジニアに直接聞いていたような仕様確認のうち、一定数はNotebookLMで自己解決できるようになりました。

特に、問い合わせる側にとっても「まずここで確認できる」という入口ができたことは大きいと感じています。

非エンジニアのメンバーが、知りたいタイミングで即座に情報を引き出せるようになり、カスタマーサポートやカスタマーサクセスのスピード感の向上にもつながります。

また、エンジニア側としても、集中しているタイミングでの割り込みが減り、作業に戻るためのコンテキストスイッチも少なくなりました。

やってみて感じた注意点

今回の取り組みは、本格的なRAG基盤を構築したわけではありません。

初期の構築コストや開発スピードを考慮し、まずは既存ツールであるNotebookLMを活用して、最速でPoC（概念実証）を回す判断をしました。

今回のシンプルな仕組みを実際に動かしてみて、特に重要だと感じたのは次の4点です。

①AIに読ませる前提でドキュメントを書くこと

人間向けのメモとしては十分でも、AIが回答に使うには情報が曖昧すぎることがあります。
条件、例外、対象範囲、用語の定義などは、できるだけ明確に書いた方が回答品質は安定します。

また、できるだけ構造化した情報整理（テーブル形式やリスト形式など）を行うと、AIによる解釈のブレを防げそうです。

②AIの回答品質を見ながらソースを育てること

最初から完璧な仕様ドキュメントを作ろうとすると、作成コストが高くなります。

まずは問い合わせが多い領域から小さく始め、回答が弱かった部分を補足していく方法が現実的でした。

③AIの回答を過信しないこと

NotebookLMはソースに基づいて回答してくれますが、ソース自体が古かったり、必要な情報が不足していたりすれば、当然ながら回答も不十分になります。
そのため、重要な判断に使う場合は、最終的にエンジニアが確認する運用も必要です。

システムプロンプトとして、「憶測の絶対禁止」や「ドキュメントから読み取れない仕様は開発チームへエスカレーション」などを指示することで、ある程度はガードレールを敷くことができます。

④AIの口調もチューニングすること

ソースコードを元にした構造化されたドキュメントをソースとすると、回答の内容はどうしても情報量が多くなります。

人間同士のSlackや口頭での質問であればかいつまんで1行2行で回答できるものを、AIは懇切丁寧に15〜20行くらいかけて説明してくれます。
逆に情報量が多く要点が掴みづらくなるため、非エンジニアのメンバーにとって仕様を読み解くハードルが上がるという課題が生じました。

絵文字や感嘆符を織り交ぜながら柔らかく親しみやすい口調で回答してもらうようにプロンプトをチューニングできると、繰り返しこのAIを使ってみようという気持ちになります。

今後やりたいこと

現時点では、運用を始めてまだ1ヶ月ほどです。

短期的には問い合わせ対応の負荷が下がった実感がありますが、継続的に運用できるかどうかはこれから検証していく必要があります。

今後は、次のような点を改善していきたいと考えています。

• 問い合わせが多い機能から順に仕様ドキュメントを拡充する
• 回答品質が低かった質問を記録し、ソースの改善に活かす
• ドキュメント更新のフローを開発プロセスに組み込む
• 本格的なRAG基盤を構築する必要があるか検討する

RAGのような仕組みを作る場合でも、結局は参照する情報源の品質が重要になります。
その意味では、NotebookLMを使った今回の取り組みは、社内ナレッジ活用の小さな検証としても意味があったと感じています。

さいごに

今回は、NotebookLMを使ってシステム仕様に関する問い合わせ対応を省力化してみた取り組みを紹介しました。

本格的なRAG基盤を作ったわけではありませんが、既存ツールを使うだけでも、情報源の整え方と運用次第で一定の効果を出せることがわかりました。

AI活用というと大きな仕組みを作ることに目が向きがちですが、日々のちょっとした困りごとを減らすところから始めるのも、十分に価値があると感じています。

今後も、開発チームの生産性向上や、職種をまたいだ情報共有をしやすくするための取り組みを進めていきたいと思います。

ニフティライフスタイルでは、今回ご紹介したようなAI活用を、エンジニアだけでなく企画や営業、カスタマーサクセスなど、全職種で推進しています。

最新のテクノロジーを柔軟に取り入れ、プロダクトと組織の両方をアップデートし続けたいという方を、現在積極的に募集中です！
カジュアル面談も可能ですので、ぜひお気軽に採用ページよりご連絡ください！