NotebookLMの使い方は社内ナレッジ設計から
目次
はじめに
NotebookLMを社内で試すと、最初の反応はだいたい前向きだ。
PDFを入れる。Googleドキュメントを入れる。質問すると、根拠つきで返ってくる。長い資料を読む時間が短くなるので、これは便利だと感じやすい。
ところが、業務に載せようとした瞬間に別の問題が出る。
どの資料を入れてよいのか。古い資料と新しい資料が混ざったら、どちらを信じるのか。人事規程、営業資料、議事録、FAQ、仕様書を同じノートブックに入れてよいのか。誰が更新するのか。
ここを曖昧にしたまま始めると、NotebookLMの使い方は「便利な個人ツール」で止まる。チームの業務基盤にはならない。
画面操作の手順だけを知りたいなら、公式ヘルプを見ながら触るほうが早い。ここで扱うのは、社内利用に入る前のソース設計だ。要件定義書、基本設計書、変更履歴、受け入れ条件、顧客別カスタマイズ仕様のような資料を、どう分けてAIに渡すかを考える。
NotebookLMの使い方で最初に決めること
NotebookLMは、ソースを入れて、そのソースに基づいて質問や要約を行うツールだ。Google Workspaceの公式ページでも、信頼できる情報を基盤にした調査と思考のパートナーとして紹介されている。音声解説、引用元の提示、Workspaceとの連携、オンボーディングや営業支援の例も示されている。
公式情報を見る限り、使い始めの操作は難しくない。資料を追加し、聞きたいことを入力し、返ってきた答えの根拠を見る。個人で調査するだけなら、それでかなり役に立つ。
業務利用で先に決めたいのは、操作手順ではない。ソースの設計だ。
たとえば、営業チームがNotebookLMに製品資料、商談メモ、競合比較表を入れるとする。質問は「この顧客に刺さりそうな提案軸は？」だ。便利そうに見える。だが、商談メモにまだ社外共有できない情報が混ざっていたらどうするか。競合比較表が半年前のままだったらどう扱うか。製品資料と個人メモのどちらを根拠にするか。
開発やSIerの現場なら、さらにややこしい。提案時の要件定義書、初期の基本設計書、顧客レビュー後の変更履歴、受け入れ条件、障害時の暫定メモが並ぶ。NotebookLMに渡す前に、正式な判断履歴と途中メモを分けないと、AIは「決まったこと」と「検討したこと」を同じ重さで扱ってしまう。
AIは、入れられた資料を前提に答える。だから、NotebookLMを業務で使う前には、AIに何を読ませるかを人間が決める必要がある。
社内ナレッジは「全部入れる」と壊れる
社内ナレッジ活用でありがちな失敗は、共有ドライブやWikiを丸ごと入れようとすることだ。
気持ちは分かる。探す手間を減らしたい。属人化をなくしたい。質問すれば社内の答えが返ってくる状態を作りたい。だが、社内文書は思っているほどきれいではない。
同じテーマの資料が複数ある。最新版と旧版が並ぶ。議事録には決定前の仮説が残る。営業資料には顧客別の前提が混ざる。FAQには古い運用が残っている。
この状態で「全部入れる」と、AIはもっともらしい答えを返す。ただし、それが最新なのか、正式なのか、誰が承認した情報なのかは分からない。
社内ナレッジをNotebookLMに入れるなら、まず棚を分けたい。
- 正式回答として使う資料
- 参考情報としてだけ使う資料
- 古いが履歴として残す資料
- 個人メモとして扱う資料
- 外部共有禁止の資料
この分類がないまま使うと、AIの回答精度ではなく、情報管理の粗さが表に出る。
ソースは業務単位で小さく切る
NotebookLMのノートブックは、巨大な社内検索窓として使うより、業務単位で切ったほうが扱いやすい。
たとえば「入社オンボーディング」「営業提案の準備」「FAQボットの検討」「プロダクト仕様の理解」「契約レビュー前の論点整理」のように、使う場面を絞る。
場面を絞ると、入れる資料も決めやすい。
オンボーディングなら、就業規則、社内ツールの使い方、申請フロー、よくある質問。営業提案準備なら、製品概要、価格表、導入事例、よくある反論、提案時の注意点。プロダクト仕様理解なら、仕様書、変更履歴、受け入れ条件、既知の制約。
ここで効くのは「何でも答えるAI」ではない。「この仕事については、この資料を根拠に答えるAI」だ。
NotebookLM Enterpriseの公式ドキュメントでも、PDF、Googleドキュメント、Googleスライド、ウェブサイトURLなどのデータソースを追加してノートブックを作り、AIがそれらのドキュメントに基づいて回答する構造が説明されている。つまり、回答品質はソース設計に強く依存する。
根拠つき回答は万能ではない
NotebookLMの魅力は、回答と一緒に根拠を見られることだ。これは業務利用ではかなり大きい。根拠がないチャット回答より、確認しやすい。
ただし、根拠が示されることと、業務判断として正しいことは別だ。
根拠資料が古ければ、古い根拠に基づいた回答になる。根拠資料が正式版でなければ、未承認の情報をそれらしく返す。複数資料の間に矛盾があれば、AIが選んだ引用だけでは判断しきれない。
だから、NotebookLMを使うときは、回答を読む人の役割も決めておく。
- 回答をそのまま使ってよい領域
- 人間が根拠を確認してから使う領域
- 専門部署の承認が必要な領域
- 外部送信前に必ずレビューする領域
社内FAQの一次回答なら、そのまま使える範囲が多いかもしれない。契約、採用、顧客提案、セキュリティに関わる回答は 、人間確認を前提にしたほうがよい。
Google Workspace Updatesでは、NotebookLMが組織内の提供データに基づいて知識共有を助けること、Workspace Business / Enterprise向けのcore serviceとして提供されること、データ保護や共有範囲の考え方が説明されている。だからこそ、社内運用では「使えるか」だけでなく「誰が何に使うか」を設計する必要がある。
NotebookLMを業務で使う前の5ステップ
実務で始めるなら、次の順番が扱いやすい。
- 対象業務を1つに絞る
- 正式なソースだけを選ぶ
- 古い資料と参考資料を分ける
- 回答を使ってよい範囲を決める
- 更新担当と更新タイミングを決める
最初の対象は、社内FAQやオンボーディングが向いている。理由は、質問パターンが読みやすく、根拠資料も比較的そろえやすいからだ。
逆に、最初から全社横断の「何でも聞けるAI」を作るのは重い。部署ごとの用語、権限、正式文書の所在、最新版の管理が絡む。便利なデモにはなるが、運用に乗せるほど確認項目が増える。
NotebookLMの使い方を学ぶだけなら、個人の調査資 料で十分だ。業務に入れるなら、最初に扱う仕事を小さくする。そのほうが、チーム内でレビューしやすく、改善もしやすい。
社内ナレッジ用のソース表を作る
NotebookLMに資料を入れる前に、簡単なソース表を作ると事故が減る。
| 項目 | 例 |
|---|---|
| 業務名 | 新入社員オンボーディング |
| 質問例 | 経費精算、勤怠、アカウント申請 |
| 正式ソース | 社内規程、申請マニュアル、FAQ |
| 参考ソース | 過去の質問、研修資料 |
| 使ってはいけない資料 | 個人メモ、未承認ドラフト、顧客別資料 |
| 更新担当 | コーポレート担当 |
| 更新頻度 | 月1回、規程変更時 |
| 回答の扱い | 社内確認用。外部送信不可 |
この表があると、NotebookLMを触る人が変わっても前提がぶれにくい。資料を追加するときも、「これは正式ソースか、参考ソースか」と判断できる。
AIに何を読ませるかは、プロンプトより前の設計だ。プロンプトで丁寧に「正確に答えて」と書いても、ソースが混ざっていれば限界がある。
RAGやFAQボットと何が違うのか
NotebookLMは、社内ナレッジを試す入口として使いやすい。一方で、RAGやFAQボットの代替としてそのまま置くには向き不向きがある。
NotebookLMは、資料を読み込み、根拠を見ながら調査する体験に強い。少人数のチームが資料を理解したり、オンボーディング資料を読んだり、提案準備の壁打ちをしたりする用途には合う。
FAQボットは、同じ質問に安定して答え、利用ログを見て改善し、必要ならSlackやTeamsに組み込む用途に向く。RAG 基盤は、権限管理、検索対象、評価データ、回答フォーマット、監査ログまで作り込むときに選びやすい。
つまり、NotebookLMは「業務に入れる前のナレッジ整理」にも使える。どの資料が正式か。どの質問が多いか。回答の根拠は足りているか。ここを確かめてからFAQボットやRAGへ進むと、構築後の手戻りが減る。
社内AIの運用設計については、AIエージェントの記憶設計やAIエージェントに文脈を渡す設計でも詳しく扱っている。NotebookLMで試した内容を、そのまま本番AIの設計材料にするイメージだ。
企業利用では権限と共有範囲を見る
企業でNotebookLMを使うときは、個人利用と同じ感覚で進めないほうがよい。
プランによって見える機能や管理の前提は変わる。Google Workspace Updatesでは、NotebookLM Plusの共有ノートブックや利用状況分析などが説明されている。Google Cloudの企業向けページでは、NotebookLM Enterpriseの文脈で、組織向けのガイドやヘルプセンター作成、VPC-SCやIAMなどの追加のプライバシー・セキュリティ機能が紹介されている。一般のWorkspace利用、NotebookLM Plus、NotebookLM Enterpriseを同じものとして 扱わないほうがよい。
チーム導入の前に見る観点は次の通りだ。
- 使えるライセンスとプラン
- 管理者が有効化しているサービス範囲
- Google Drive上のファイル権限
- ノートブック共有の範囲
- 社外秘や顧客情報の扱い
- 監査や利用状況確認の要否
特に、Driveで見える資料をそのままAIに読ませてよいとは限らない。閲覧権限があることと、AI回答の根拠にしてよいことは別の判断だ。
Atsumellならどう設計するか
Atsumellがこのテーマを見るとき、NotebookLMそのものの機能比較だけでは終わらせない。
見たいのは、業務フローとナレッジの境界だ。誰が何を知っているのか。どの資料が正式なのか。どの判断は人間が持つのか。外部送信前にどこで止めるのか。ここを整理しないと、AIは便利な下書き係で止まる。
Kakusillでは、要件定義や設計ドキュメントをAIが読める構造に寄せていく。NotebookLMで社内資料を読みやすくする発想とも近い。違いは、Kakusillが「開発や業務改善に使う仕様・判断履歴」を構造化する側に寄っていることだ。
社内ナレッジ活用の第一歩としてNotebookLMを試す。そこで見えた質問、根拠不足、資料の古さ、権限の曖昧さを、次のAIエージェン トやFAQボットの要件へ落とす。この順番なら、いきなり大きなRAG基盤を作るより失敗しにくい。
生成AI PoCの成功基準でも書いた通り、AI導入は「何ができるか」より「何を成功と呼ぶか」を先に決めるほうが進みやすい。NotebookLMの業務活用も同じだ。導入前の考え方は、AI社員とは何かの整理にも近い。
最初の30分でやること
今日から試すなら、次の30分だけでよい。
1つの業務を選ぶ。資料を5本以内に絞る。資料ごとに「正式」「参考」「古い」「外部共有不可」のラベルを付ける。よくある質問を10個書く。NotebookLMに聞いて、答えと根拠を確認する。
この時点で見るべきなのは、AIの賢さではない。
答えの根拠が見つかるか。古い資料に引っ張られないか。質問が曖昧でも意図を拾えるか。人間が確認すべき箇所が見えるか。
ここまで分かれば、NotebookLMをそのまま使うか、FAQボットに進むか、RAG基盤を作るか、Kakusillのように仕様や判断履歴から整えるかを判断しやすくなる。
NotebookLMの使い方は、画面操作よりも前にある。社内ナレッジをどう切り、どの根拠をAIに渡し、どこで人間が責任を持つか。そこを決めるほど、AIは業務の中で使いやすくなる。
