NotebookLMで社内規定を検索｜問い合わせ対応時間を7〜8割減らした使い方

2026年4月10日2026年8月12日

社内規定のAI化で問い合わせ対応をゼロにするNotebookLM構築ガイドの表紙スライド

SkillStack Lab（スキスタ）運営者のスタックです。

「出張の宿泊費はいくらまで？」「有給は何日繰り越せる？」「この経費は誰の承認が必要？」

管理部門で仕事をしていると、社内規定を見れば答えが書いてある質問でも、社員から何度も問い合わせが来ませんか。

私の職場でも、こうした規程・マニュアルに関する類似質問が月20〜30件ほどありました。

以前はファイルサーバーからPDFを探し、該当条文を確認して回答するまで1件5〜10分ほどかかっていましたが、Gemini Notebook（旧NotebookLM）を使うようになってからは、該当条文と引用元を確認するところまで1〜2分程度になっています。

私の運用では、社内規定に関する問い合わせ対応時間を体感で7〜8割ほど減らせました。

ただし、実際に使って分かったのは、「社内規定を全部NotebookLMへ入れれば問い合わせ対応を自動化できる」というほど単純ではないことです。

本則と別表を取り違えたり、新旧の規程が混ざって古い金額を回答したり、規程に書かれていないことを一般論で補完したりするケースもありました。

スタック

社内規定で使うなら、AIに「判断」を任せるのではなく、「正しい条文を早く探す」ために使う。この線引きが一番重要だと感じています。

この記事では、元情シス・現役管理部門長の私が実際に運用している、社内規定をGemini Notebookで検索する方法、Notebookの分け方、質問例、失敗事例、Viewerでの共有、規程改定時の更新ルールまで解説します。

なお、NotebookLMは現在「Gemini Notebook」という名称になっています。本記事では検索で現在も広く使われているNotebookLMという旧名称も併記します。

この記事で分かること

社内規定をNotebookLMで検索する具体的な作り方
1Notebookを5〜10ファイルに絞っている理由
就業規則・旅費規程・経費規程で実際に使った質問例
本則・別表・旧規程をAIが取り違えた失敗例
ViewerとEditorを使い分ける社員向け共有方法
AIで自己解決させてよい質問・人へ回すべき質問の境界
NotebookLMからDify×SharePointへ移行する判断基準

NotebookLMは社内規定の「検索時間」を減らすのに向いている

最初に、私がGemini Notebookを社内規定で使う目的を明確にしておきます。

目的は、管理部門の判断そのものをAIへ任せることではありません。

「どの規程の何条に書いてあるか」を探す時間を短くすることです。

Gemini Notebookは、Notebookへ追加したソースを参照して回答し、回答中の引用から根拠となる箇所を確認できます。

そのため、例えば社員から、

出張時の宿泊費上限
経費精算の申請期限
慶弔休暇の日数
有給休暇の繰越日数

といった質問を受けたとき、何十ページものPDFを最初から探す必要がなくなります。

AIの回答をそのまま社員へ返すのではなく、引用元の条文を開き、人間が確認してから回答するのが私の基本運用です。

実際にNotebookLMへ入れている社内規定

私は現在、会社の規程・マニュアルを実際にGemini Notebookへ入れて運用しています。

主に使っているのは次の資料です。

分野	実際に入れている資料
人事・労務	就業規則、36協定、特別休暇規程など
経理	旅費交通費規程、経費精算ルール、小口現金運用マニュアル
総務	慶弔見舞金規程
情シス	情報セキュリティガイドライン、社内システム利用マニュアル
契約	契約書チェックリスト、標準契約書ひな形

ただし、これらをすべて1つのNotebookへ入れているわけではありません。

全社規定を1冊にせず部署・ドメインごとに分ける

私が運用しているNotebookは、大きく、

人事・労務
経理・会計
総務・情シス

など、担当領域ごとに分割しています。

1つのNotebookへ入れるファイル数は、基本的に5〜10ファイル程度です。

Gemini Notebook自体はもっと多くのソースを扱えますが、入れられる数と、入れた方がよい数は別だと考えています。

実際に20〜30ファイル以上をまとめたとき、「経費」という同じ単語が旅費規程、慶弔規程、IT関連規程など複数の資料へ登場し、質問と関係の薄い文脈を拾うことが増えました。

人事なら人事、経理なら経理とNotebookを分けた方が、引用元の確認も管理もしやすくなりました。

スタック

ソース上限まで詰め込む必要はありません。社内規定では「少数精鋭で、どの資料を根拠に答えたか追えること」の方が重要です。

NotebookLMで実際に精度確認した社内規定の質問例

単純に「この規程を要約して」と聞くだけでは、社内問い合わせ対応の検証にはなりません。

私は実際の問い合わせに近い質問を投げ、複数条文や別表まで正しく参照できるか確認しています。

旅費規程

出張時に前泊が認められる条件と、宿泊費の上限額を教えてください。

本則だけでなく、金額が記載された別表まで確認できるかを見る質問です。

慶弔規程

配偶者が結婚した場合の慶弔休暇の日数と、慶弔見舞金の申請期限はいつまでですか？

休暇日数と申請手続きという、離れた条文から条件をまとめられるか確認します。

経費精算

個人で書籍やセミナー受講費を立替購入する場合、誰の事前承認が必要で、上限いくらまで落とせますか？

決裁権限と経費精算ルールをまたいで確認する質問です。

有給休暇

入社2年目の社員が有給休暇を繰り越せる最大日数と、失効するタイミングはいつですか？

こうした具体的な質問で検証すると、「検索できる」だけでなく、複数条件を正しく組み合わせられるかまで確認できます。

実際に起きたNotebookLMの3つの誤回答

社内規定用途では、うまくいった例より失敗例の方が重要です。

私の環境でも、AIの回答をそのまま社員へ返していたら危なかったケースがありました。

1．本則だけ読み、別表の例外を落とした

出張手当について質問した際、本則に記載された原則の日額手当は回答したものの、別表にある役職別上限や海外出張時の特例を反映しなかったことがあります。

AIがまったく関係のない回答をしたわけではありません。

しかし、実務では例外条件が抜けただけでも誤案内になります。

2．規程にない手続きを一般論で補完した

慶弔見舞金の振込口座について質問した際、規程には記載されていないにもかかわらず、「給与口座へ振り込まれる」といった一般的な手続きを回答したケースもありました。

実際には専用申請書へ指定口座を記載する運用だったため、回答は誤りです。

社内規程検索では、「ソースに書いていないことは、分からないと回答させる」ことが重要です。

3．新旧規程が混在して手当額を取り違えた

最も危険だったのが、新旧2つの規程を同じNotebookへ入れていたときです。

旧規程と新規程で金額が変わっていたにもかかわらず、回答時に両方の記述が混ざりました。

AIが古い規程を正しく読んで答えた場合、それはAIのハルシネーションというより「古いデータを残した人間側の運用ミス」です。社内RAGではモデル性能以上に情報の鮮度管理が重要です。

規程改定時は古いソースを残さない

新旧規程の混在事故を経験してから、更新ルールを明確にしています。

旧PDF・旧DocをNotebookから削除する
最新改定版へ差し替える
ファイル名・ヘッダーに改定日を明記する
代表質問を再実行して回答を確認する

ファイル名は、例えば、

【最新_20260401改定】就業規則.pdf

のようにしています。

大きな法改正や組織改編に伴う全面改定では、継ぎ足し更新をせず、新年度用Notebookを新しく作り、旧Notebookを運用対象から外します。

Google Driveから追加した対応ソースを使っている場合も、必要に応じてソースの同期状態を確認してから社員へ案内します。

社員にはViewer権限で共有している

社内規定を共有する場合、誰でもソースを編集できる状態にはしていません。

私の運用では、

利用者	権限	役割
管理部門	Editor	規程の追加・更新・管理
一般社員	Viewer	規程を参照してチャットで質問

と分けています。

これにより、社員が誤って規程ソースを削除したり、個人的なメモを追加して回答の前提を変えたりする事故を防げました。

管理部門だけが「正しいソース」を管理し、一般社員はその資料へ質問する。

社内規程では、この役割分担が分かりやすいと感じています。

Viewerだから機密資料を自由に共有してよいわけではありません。閲覧させてよい社員だけへ共有し、Notebookに入れる資料自体も適切に分離してください。

「AIで答えてよい質問」と「人へ回す質問」を分ける

社員へGemini Notebookを公開するなら、最も重要なのがAIへ任せる範囲の明文化です。

私の会社では、大きく次のように分けています。

AIで自己解決してよいのは「規程に答えがある事実検索」

申請期限は何日以内か
提出フォーマットはどこにあるか
出張の日額上限はいくらか
経費精算の締日はいつか

こうした質問は、規程に明記された事実を探す作業なのでAIと相性があります。

個別判断が必要なら担当部署へ回す

長期休職や手当の個別試算
育児短時間勤務などの例外適用判断
懲戒・不利益変更
ハラスメント相談
規程上限を超える例外承認
法律解釈を伴う判断

この範囲ではAI回答を根拠に社員が自己判断せず、人事・経理・総務などの担当部署へ相談するルールにしています。

スタック

「検索」はAIへ任せても、「判断」と「承認」までは渡さない。管理部門で運用するなら、この境界を社員にも先に伝えておくことをおすすめします。

実際に問い合わせ対応は5〜10分から1〜2分になった

私の管理部門では、規程や手続きに関する類似質問が月20〜30件ほどあります。

項目	導入前	導入後
1件あたり	約5〜10分	約1〜2分
主な作業	PDFを探す→該当条文を検索→回答作成	質問→引用箇所を確認→回答
体感	文書探しによる作業中断が多い	必要な条文へ短時間で到達できる

単純計算だけを目的にした厳密な効果測定ではありませんが、実務感覚では問い合わせ対応時間を7〜8割程度削減できています。

特に大きいのは、数分の削減そのものより、別の仕事をしている途中でファイルサーバーを掘り始める回数が減ったことです。

よくある質問については、AIが示した根拠を人間が確認したうえで内容を整理し、FAQとして社内Wikiへ反映することもあります。

これにより、同じ問い合わせを繰り返し回答するのではなく、問い合わせそのものを次のナレッジ改善へつなげられるようになりました。

NotebookLMのセキュリティを「絶対安全」とは考えない

旧記事では「NotebookLMなら機密情報でも安全」「アップロードしたデータは絶対に学習されない」とかなり強く書いていました。

現在、この表現は使いません。

Googleは個人利用について、フィードバックを提供しない限りGemini Notebookの学習にデータを使用しないと案内しています。

また、対象となるGoogle WorkspaceやWorkspace for Educationの利用では、アップロード・質問・モデルの回答を人間によるレビューやAIモデル学習に使用しないと説明しています。

ただし、これは会社のあらゆる機密情報を無条件でアップロードしてよいという意味ではありません。

私は会社データについて、個人用Googleアカウントへ持ち込まず、会社が管理・許可している環境を利用します。

また、給与・評価・個人情報・認証情報・他社とのNDA対象資料など、そもそもAIへ渡す必要がないデータはNotebookへ入れません。

Gemini Notebookのデータ学習やWorkspaceとの違いについては、NotebookLMのオプトアウトとAI学習の記事で詳しく整理しています。

最初は5〜10ファイルの小規模検証で十分

社内AIというと、最初から全社の文書をつなぎ、自動更新・チャットBot・権限管理まで作り込みたくなるかもしれません。

私はおすすめしません。

最初に用意するなら、例えば経理部門で、

旅費規程
経費精算ルール
決裁権限表
小口現金マニュアル

など、5〜10ファイル程度で十分です。

そして、過去に実際に来た問い合わせを10〜20問ほど投げ、

正しい規程を参照するか
別表・例外まで拾うか
書いていないことを補完しないか
引用箇所から人間が確認できるか

を検証します。

ここで使えると判断してからViewerで対象社員へ広げる方が、安全で運用負荷も小さくできます。

NotebookLMでは足りなくなる3つのタイミング

Gemini Notebookは、小さく始める社内規程検索には便利ですが、どこまでも規模を広げられる業務基盤とは考えていません。

私なら、次のどれかが発生した段階でDify×SharePointなどの本格RAGを検討します。

1．社員がTeamsやSlackから出たがらない

Gemini Notebookを使うには、基本的にNotebookを開いて質問する必要があります。

利用者が増えると、

「Teamsで@総務Botと聞けば、その場で答えてほしい」

という要望が出てきます。

既存チャットの中で完結させたい要求が強くなったら、本格RAGへ進む一つのサインです。

2．1つの検索窓で細かな閲覧制御が必要になる

一般社員向け規程、管理職限定資料、人事限定資料などを細かく分けながら、一つの検索窓から利用させたい場合もNotebookの分割運用だけでは管理が複雑になります。

部署・役職・ユーザーによって検索対象を動的に変える必要が出た段階で、より詳細な権限設計が必要です。

3．文書が100ファイルを超え、自動同期が必要になる

私が最も現実的な境界だと考えているのが、文書数と更新作業です。

5〜10ファイルなら人間が更新できます。

しかし規程・マニュアルが数十〜100ファイルを超え、毎月のように改定されるようになると、

旧版を消し忘れる
更新対象を間違える
Notebookごとの同期状態を確認し忘れる
担当者に更新作業が属人化する

といった運用リスクが大きくなります。

この段階ではSharePointなどの正式な文書保管場所をマスターにし、更新をRAG側へ連携する仕組みを検討した方がよいでしょう。

DifyとSharePointを連携して自動更新・権限・運用保守まで設計する方法は、Dify×SharePoint連携ガイドで詳しく解説しています。

NotebookLMとDify×SharePointの使い分け

比較項目	Gemini Notebook	Dify×SharePoint
導入目的	小さく試す・規程検索	本格的な社内RAG
文書数の目安	私は5〜10ファイル程度で運用	数十〜数百文書にも対応する設計を検討
更新	人間が管理しやすい規模向き	自動同期を設計しやすい
利用画面	Gemini Notebook	Teams・Webチャット等へ連携可能
アクセス制御	Notebookを分けた運用がシンプル	要件に合わせた詳細設計が可能
構築難易度	低い	認証・権限・運用設計が必要