はじめに
こちらは エーピーコミュニケーションズ Advent Calendar 2025 13日目の記事です！
前編の構想編では、NotebookLMを活用したナレッジ共有の構想を示しました。
今回の実践編では、実際に構築した内容と、使って分かった利点・課題をまとめます。
実装の概要
前編で示した構想を、実際にNotebookLMで実装しました。想定通りに動作するところまでは確認ができています。
対象データ：
- 社外向けの公開技術記事（約2000件）
- 既存ナレッジツールのスプレッドシート（約50件）
- Slackチャネルのやり取り
データ収集と投入の実装
公開用の技術ブログと以前開発したナレッジ共有ツールのスプレッドシートをソースとしているため、直近でNotebookLMがスプレッドシートに対応したことが幸いし、こちらはスプレッドシートを分解する手間もありませんでした。
ブログ記事はMarkdownのテキストのみを投入し、画像は特に取り込んでいない状況。はてなブログがmarkdownのままダウンロードできるのでこちらも非常に手間がかからなかったです。
データ収集フロー
はてなブログからの記事取得
社外向けの公開技術記事ははてなブログで公開されており、はてなブログではAPIを使って記事ごとに1つのMarkdownファイルとしてダウンロードすることができました。非常に使い勝手が良いです。
NotebookLMのデータソース上限を考慮して、100件ごとに結合したMarkdownファイルにまとめることにしました。
初回全件取得タスク（GAS）
- 記事をAPIで総取り → Markdown形式でダウンロード → 日付順にソート → 100件ごとに結合してGoogle Driveに保管
定期更新タスク（GAS）
- 差分だけ取得 → Markdownファイルをダウンロード → 既存のファイルとマージし、内容を更新して再保存
ナレッジ共有ツールとSlackからのデータ収集
以前開発したナレッジ共有ツールとSlack Botから、同一のスプレッドシートにデータを蓄積しています。
ナレッジ共有ツール
- フロントエンドのフォーマットに沿って入力すると、内容をスプレッドシートに自動登録
- メモなどをタグ情報で構造化して蓄積
Slack Bot
- 特定のチャネルのやり取りを自動収集
- Slack APIでメッセージを取得し、必要な情報（投稿者、内容、タイムスタンプ等）をスプレッドシートに書き込み
スプレッドシートのNotebookLM投入
NotebookLMのアップデートでスプレッドシートの直接読み込みが可能になり、変換の手間を省略することができたため、ファイルそのままを投入してNotebookLM側で利用することが可能です。
データサイズとバッチ管理
現状は、社外向けの公開技術記事をほぼ全部NotebookLMに流し込んだ状態になっており、ファイル数上限を考慮して100記事を1ファイルとまとめている状態となっています。
想定通りにデータ収集と投入は完了し、まずは動作確認ができている状態。
※確認時点のドキュメントでは50(無償？)となっているが実際は300(有償？)、1記事5,000文字程度と概算した上で100記事を1ファイルにまとめることとしました。
1 つのソースには最大 500,000 語を含めることができます。アップロードできるファイルのサイズは 200 MB までです。最大 50 個のソースを含めることができます。
ノートブックの新しいソースを追加または検索する
実際の利用と検証結果
実際に日常的な質問をいくつか投げてみましたが、ひとまず何かしらの回答を得ることができることを確認できています。
確認できたこと
- ブログとスプレッドシートの両方から情報を引用して回答が得られる
- 質問の意図を理解し、関連する複数の情報源を統合して答えてくれる
- 回答の内容は自然で、質問意図に沿っている
使って分かった利点と課題感
良かった点
- 自然言語で検索できる：タイトルやタグを覚えていなくても質問できる
- 異なる形式を統合：ブログ（markdown）とシート（構造化情報）の両方を扱える
- 会話的な探索：前の質問を踏まえて、さらに掘り下げた回答が得られる
特に、ブログとスプレッドシートの情報を横断的に統合して返せるので、既存のナレッジツールを拡張するような形で利用価値を上げられたかなと思っています。
NotebookLMは触った感じだと万能に使える話ではないですが、散在している情報を活用するための手段としては有効であることが分かりました。
今後の課題と展望
課題と展望
現場本格運用を考えると手動作業も残ってしまっているため、あまり理想的な状態ではありませんが、ざっくり以下が課題として残っています。
- 自動更新がされない：新しい記事が増えた際にデータソースが更新されると、NotebookLMは自動で再取り込みをしないため、手動で再同期をする必要がある。データ自体はGASで定期取得はしているが、NotebookLMへの取り込みが手動となり手間がかかる状況
- 特定分野への偏り：情報量か、そもそも整理をしていないからか、デフォルト表示される概要表示や選択項目のマインドマップや音声解説・動画解説等で特定のカテゴリに偏った情報が表示される傾向がある。質問による検索では適切に調べてくれていそうだが、自動生成されるコンテンツには偏りが見られる
- データソースがテキスト化されているため、正しくリンク先へアクセスができない部分がある
データソースをGoogleドライブにしている場合、更新ボタンで更新できるような旨の記述を見つけたのだが、取り込み方の問題なのかそちらが表示されずにファイルの取り込み直しが必要になってしまっている。
NotebookLMにこだわっているわけではないので、他の手段も検討しつつバランスの良い方式を検討していきたい。
一旦はNotebookLM側が自動更新に対応してくれれば最低限のラインはクリアかなといった印象です。あとは整理の仕方が問題になるのかといった感触。
NotebookLM以外での選択肢
今回の検証を終えた後、Gemini APIにFile Search Toolという新機能が公開されたようです。
こちらもより便利にRAGを構築する仕組みのようです。
まだ触れていないがNotebookLMとは異なりGemini APIを直接活用する形になるため、より柔軟なカスタマイズが可能になる様子。
料金体系も明確なようなので、小規模な環境構築からテストからテストは始めやすそうです。
また、AWSのS3 VectorsもGAされたようで、こちらもコストパフォーマンスの高いRAGが構築できるようで気になっています。
今回のNotebookLMでの検証で見えてきた課題を踏まえて、次のステップは少額で試せるところから試してみたいと考えています。
まとめ
NotebookLMを活用して、散在する社内ナレッジを横断的に検索できる仕組みを試し、約2000件の技術記事とスプレッドシートの情報を統合し、自然言語での質問に対して複数の情報源から回答を得られることを確認できました。
一方で、自動更新の手動運用や特定分野への偏りやリンク参照の課題など、実運用に向けた改善点も多くあるように感じています。今後は別軸でのサービス利用の検討とともに、データの整理と構造化、自動化フローの検討などをしながら、いろいろ試して行けたら良いかなと感じています。
理想的にはNotebookLMにこだわらず、人の手間が増えない形で情報を統合した管理ができるればと考えているため、色々と試しながら便利なものを作れたらと考えています。