はじめに

多くの企業では、社内ポータルや社内 Wiki に大量のナレッジが蓄積されていると思います。

しかし、これらの情報は検索性が低く、職人技のような検索スキルが求められることが多いです。
アイレットのセキュリティチームでも、WafCharm や Sysdig、Trend Micro Cloud One - Workload Security など多くの製品を扱っており、属人化しないサポートが喫緊の課題でした。

この記事では、社内 Wiki に貯められた大量のナレッジを、Google NotebookLM (以下 NotebookLM) で活用した事例を紹介します。

NotebookLM vs Gemini Gem

NotebookLM と Gemini Gem は、いずれも、目的やデータに合わせてカスタマイズが可能な Google の AI サービスです。

今回のケースにおいて、どちらの手法も検討しましたが、NotebookLM を利用する方法が最善と判断しました。
選定理由を紹介します。

カスタマイズ方式の違い

NotebookLMは、Gemini 1.5 Proの広大なコンテキストウィンドウを活用した、高度な RAG（検索拡張生成：Retrieval-Augmented Generation）を基盤とするサービスです。

アップロードされた資料は事前に解析・インデックス化されます。
その挙動（事前計算や、検索精度、引用元の特定能力）から、内部的には資料のベクトル化（Embedding）と、それに基づいた RAG プロセスが動いていると考えられます。
ユーザーの問いに対して、AI は最適な情報を検索・抽出し、それを Gemini 1.5 Pro の広大なコンテキストに注入して推論を行います。

この推察に基づき、検索精度を制御するためのインデックス設計を試みたところ、顕著な改善が見られました。

それに対して、Gemini Gem は、主にコンテキスト拡張（Long-context Prompting）のアプローチを取ります。
AI が推論する文字列に対して、資料を注入し、推論させる方式を取ります。

これらは、検索精度に対して大きく影響を与えます。

NotebookLM は、巨大なデータであっても事前処理として RAG に変換しているため、処理の精度が高いです。
証拠に基づく推論が可能で、ハルシネーションの確率も大きく下がります。

Gemini Gem は、全てのコンテキストを理解しているので情報の取りこぼしがほぼ有りません。
しかし、コンテキストが長すぎると特定の記述を見落とし、ハルシネーションの確率が上がります。
これは、Lost in the Middle 現象といわれるものです。

実際に、Wiki 情報の全体を渡すと情報をうまく推論できず、チャット内にキーワードを追加することで推論精度が向上することが観測されました。

Gemini Gem は外部データ参照も自律的に行うため、一般情報の回答も目立ちました。

NotebookLM Gemini Gem
カスタマイズ方式 RAG コンテキスト拡張
情報源 内部情報のみ 自律的な検索
ハルシネーション確率 低い 高い
プロンプトカスタマイズ 可能 可能
問題の性質 検索性の向上 情報の埋没

どちらがナレッジの検索という目的に最適か最後まで検討しましたが、今回の利用方法に関しては NotebookLM のほうが良いという結論に達しました。

検索精度向上のための Tips

最初に検討したのは社内 Wiki の内容全文を、NotebookLM に投入することです。
しかし、これは予想以上に検索精度が出ませんでした。

RAG はその仕組みから、『検索クエリに対して、如何に適切な回答が返ってくるか』という技術的な問題が、推論を行うための課題となります。

Wiki 全文では、ユーザーの問い合わせなどに対して適切な検索ができない。
この問題に対して、効果の高い方法は以下の手法でした。

プロンプトの参考例は、本文末の参考をご確認ください。

1. 膨大な Question list による「逆引き index」の作成

最初に実施した方法は、AI を用いて大量の Question list を作成することです。
この情報を、NotebookLM 内に index として入れることで、検索性は大きく向上しました。

RAG の特性から、Database 内のデータと如何に連携するかが、検索のキモとなります。
ユーザーが利用するような一般的な言葉のキーワードを Wiki の各ページから大量に作成しました。

この際に検討した内容は以下のとおりです。

Answer を記述しない

index の目的は、検索文字列から記事を参照することです。
Answer を Question list に含めてしまうと、NotebookLM は AI の作成した仮の Answer を証拠として回答してしまいます。

たとえ高精度であっても、AI で作った FAQ を回答の根拠とするのは不適切です。
そのため、NotebookLM が RAG で検索する際に Question list だけでは回答することができないよう、技術的制約を与えました。

これにより、AI の作成した FAQ を根拠として提示する事故を防ぐことが可能となりました。

関係性を重視させる

AI に記事から大量の Question list を作成することを要求すると、無意味な質問や、一般的な質問を大量に作成します。

しかし、これでは当初の目的である検索性向上のためのインデックスデータとしては不適切です。

この問題に対しては、プロンプトチューニングを行い無関係な質問の作成を禁止しました。
あくまでも、本文で記述されている内容を基にして、それと関係のある質問に限定することで無意味な質問を大幅に抑止しました。

逆に、言い換え (サーバー / ワークロード) などは積極的に広げるプロンプトを記述しています。
これは、ユーザーがどのような言葉を使っても検索を可能とするためです。

文脈の追加

AI に Question list の作成を依頼すると、『見積もり方法は？』のような簡単な質問に終止します。
これは、RAG にとってはノイズでしかありません。

プロンプトによって、質問は具体的にして、背景情報も含めた質問にするように限定しました。
これにより、『大規模な通信発生する環境での WAF の見積もり方法は？』のような背景情報を含めたより具体的な質問を生成するようになりました。

これらの対策により、RAG が検索可能な大量の Question list を用意できました。

2. UUID v5 による ID 空間の拡張と衝突回避

Question List と、本文を関連付ける際に、 ID 情報は重要です。
社内 Wiki は、ID 情報が RAG との相性が非常に悪く、情報の取り違えが頻発しました。

そのため、データ変換で ID 情報を追加するという手段を取りました。

連番 ID の害

多くのシステムでは、ID として数値連番を利用しています。
12345678 や 12345679 などの視認性が低い ID では、AI は検索の際に取り違えます。

また、空間衝突も問題となります。
1010という ID が、金額の『1010 円』や日付の『20261010』と混同（衝突）し、AI が情報を誤認する原因になります。

そのため、これらのシステムで付与された連番とは別に、検索用のキーを付与しました。

UUID v5

UUID (汎用一意識別子: Universally Unique Identifier) は、世界で一意の ID を付与するための規格です。
583c9d26-b813-4714-9064-2f5e25664ac2 のような形式で、一意の ID を生成できます。

今回は、UUID v5 (Namespace / SHA-1) を用いて空間を拡張しました。
もとの Wiki ID から、常に同一の UUID を生成できるため、今回のような変換には最適のアルゴリズムです。

UUID v5 を採用した最大の理由は、元の Wiki ID から常に同一の UUID を生成できる『決定的』な特性にあります。これにより、Wiki 側で更新があった際も、インデックスの一貫性を保ったままデータの再投入や紐付けが可能になります。

UUID は、文字列として十分に長く、また世界中で一意であることが保証されています。

元の Wiki ID をベースに UUID v5 を生成することで、『世界で一意かつ、トークンとして他の単語と混同されにくい文字列』として Index と本文を強固に紐付けました。

3. カスタムプロンプトの強制

Gemini Gem で実施しているように、カスタムプロンプトはユーザーからの適切な応答のために必須です。

NotebookLM では、『チャットの設定』『カスタム』から、カスタムプロンプトを設定できます。
Gemini Gem と同様に、検索方針や回答方針などをカスタマイズしました。

これにより、誰が利用しても同じような回答を精度を得ることが可能となりました。

社内ナレッジの活用

社内 Wiki を情報源として、既存の資産を最大限活用しつつ、NotebookLM により誰でも情報に正しくアクセスできるという資産の活用を実現しました。

まずは、チーム内で検証を兼ねて活用している段階ですが、今後社内での活用に広げたいと考えています。

まとめ

社内ナレッジの活用として NotebookLM は注目を浴びています。
データを投入するだけで、自動的に Vector database に変換を実施して、RAG により証拠に基づく検索を実施してくれるためです。

しかし、実用を考えた場合には、Question List の作成や、適切な ID 管理、カスタムプロンプトの実装など、多くの課題に直面しました。

AI 活用では、機能として使うだけでなく、その価値を 120% 引き出すことが重要となります。

参考

インデックス用プロンプト

# インデックス生成プロンプト

## Role
あなたは、ナレッジベース（Wiki）の検索精度を最適化するインデックス・エンジニアです。
RAG（検索拡張生成）において、ユーザーの曖昧なクエリとWikiページを正しくマッチングさせるための「検索用メタデータ」を生成してください。

## Goal
- ユーザーの話し言葉や曖昧な表現を、ページの内容に結びつける「Question List」の作成。
- 検索エンジンが意味を捉えやすい「キーワード」と「文脈」の抽出。

## Rules
1. **回答の詳細は書かない**: インデックスは「標識」です。回答そのものはWiki本体に任せ、「何が解決できるか」の問いに徹してください。
2. **具体的な質問作成**: 「手順は？」ではなく、「〇〇が起きた時の対処法は？」や「△△を申請する際の条件は？」といった、具体的な状況をシミュレートしてください。
3. **前提条件と制約の義務化**: 質問には、具体的な前提条件（OS、製品バージョン、環境等）や、発生しうる制約を付加してください。
4. **語彙の多様性（シノニム）**: 専門用語だけでなく、初心者が使う一般的な言葉、略称、旧称、英語表記を「Keywords」に含めてください。
5. **独立性の確保**: 他のページを参照せず、この1ページのみで完結する情報を出力してください。
6. **回答・憶測の禁止**: ページ内に記載がない情報は、要約、質問どちらにも含めることは禁止します。

## Output Format
#### Metadata
- **Category**: [ページの分類]
- **Target**: [誰に向けた情報か]
- **Keywords**: [専門用語, 類義語, 略称, 英語名, 俗称]

#### Contextual Summary
[このページは「何について」「どんな目的で」書かれているか。]

#### Question List (Search Intent)
- Q: [ユーザーが遭遇する「具体的な問題状況」＋「解決したいこと」]
- Q: [「前提条件」や「作業前の確認事項」に関する質問]
- Q: [専門用語を日常語に噛み砕いた質問（例：ワークロード ＝ サーバー）]

NotebookLM プロンプト

#　役割と目標:

* あなたはセキュリティサービスの '運用アドバイザー' です。
* NotebookLM に蓄積された各サービスの仕様書、運用約款、FAQに基づき、社内担当者からの問い合わせに対して、エビデンスに基づいた正確な回答を生成します。

# 前提条件

回答には、必ず NotebookLM による RAG を活用してください。

# 振る舞いとルール:

1. 適切な検索:
    - `id` を用いて、Wiki から実際の情報を抽出し、推論を行ってください。
2. 回答の精度:
    - 曖昧な回答を避け、NotebookLM内のドキュメントから証拠を提示した上で、明示的な回答を行ってください。
    - 回答の根拠となる参照元のセクションやタイトルを可能な限り明示してください。
    - 情報が不足している場合は、推測で答えず、どの情報が不足しているかを具体的に伝えてください。
3. 専門性とトーン:
    - 専門的かつ丁寧なビジネス口調を使用してください。
    - 社内担当者に対して信頼感を与える、簡潔で分かりやすい説明を心がけてください。
    - エスカレーションは最小限にとどめ、知識ベースの回答を実施してください。
4. 知識の活用:
    - 常に NotebookLM 内のサービス定義と蓄積された知識を最優先して参照してください。
    - 独自の判断ではなく、提供された資料に基づいた事実のみを回答の基盤としてください。
    - Wiki の情報を提供する場合、URL を提示してください。 e.g. `[{name}]({url})`

# 禁止されている話題

1. 料金の計算
    - 料金は、前提条件などが複雑です。
    - 計算方法が記載されたページに誘導してください。具体的な金額を回答してはいけません。
2. 他社サービスとの比較
    - 他社サービスと比較したり、提供していないサービスを提案してはいけません。

# 全体的なトーン:
* 誠実でプロフェッショナルな対応。
* 明確かつ論理的な構成。
* ユーザーをサポートする協力的で親切な態度。
* 自律的な調査と、回答。