膨大な社内ドキュメントから、自分の役割に必要な情報だけを抽出したい。
そんな課題を抱えている方は多いのではないでしょうか。
先日、海外のRedditコミュニティで興味深い議論を見つけました。
GoogleのAIツール群を駆使して、数万ページにおよぶ業務マニュアルから「カスタマーサクセスマネージャー（CSM）専用の知識システム」を構築しようという試みです。
本記事では、この議論から得られた知見を整理します。
そして、役割特化型ナレッジベース構築のアーキテクチャについて考察していきます。
解決したい課題の本質
投稿者が直面している状況は、多くの大企業で見られるものでしょう。
複雑なB2B製品を扱うCSMとして、多数の部門と連携する必要があります。
プロジェクト管理部門、エンジニアリング部門、契約部門、財務部門などです。
各部門には3,000〜4,000ページもの研修資料やSOPが存在します。
その中にCSMにとって重要な情報が「点在」しているのです。
たとえば次のような記述があります。
「ステージXでCSMを関与させること」「契約タイプZの場合、CSMはA/B/Cを確認すべき」といった内容です。
これらは各部門の視点では「補足事項」に過ぎません。
しかしCSMにとっては、まさにこれが業務の核心なのです。
さらに厄介なのが「用語の多義性」の問題です。
「ルーター」という単語を例に挙げてみましょう。
エンジニアリング部門の文書では、物理的な設置制約やトポロジーの観点から説明されています。
一方でCSMが気にするのは全く異なる観点です。
保証範囲への影響、SLA、交換プロセス、契約条件などが重要になります。
同じ単語でも、役割によって着目すべきポイントが変わるわけですね。
Google AIツールの特性と制約
投稿者はGoogleツールのみを使用するという制約のもとで検討を進めていました。
具体的には以下の組み合わせです。
- Gemini（カスタムGem、Deep Research、Deep Think）
- NotebookLM
- Google Drive
各ツールの特性を整理してみましょう。
カスタムGem
CSMの研修資料を読み込ませることで「CSMの思考回路」を持ったアシスタントとして機能します。
「このステージでの私たちの役割は？」「引き継ぎはどうあるべき？」といった質問には適切に回答してくれるでしょう。
ただし、コンテキストウィンドウの制約があります。
各部門の膨大なSOPまで同時に処理するのは現実的ではありません。
Deep Research
数千ページの文書群を横断的にスキャンできます。
そして情報を統合する能力を持っています。
しかし、CSMの研修資料を読み込ませていなければ「CSMが何を重視すべきか」を理解できません。
用語の多義性問題も解決できないでしょう。
NotebookLM
選択したソースをまとめて「ノートブック」として管理できます。
構造化されたノートやFAQの生成も可能です。
ただ、このツールをどの段階で、どのような目的で使うべきかは明確ではありませんでした。
Deep Think（Geminiの熟考モード）
複雑な推論を丁寧に行う際に威力を発揮します。
オントロジーの設計や、微妙なニュアンスを持つ用語の解釈には適しているでしょう。
とはいえ、数万ページの処理というスケールの問題は解決してくれません。
提案されたマルチツール・アーキテクチャ
投稿者が検討していたのは、4段階のパイプライン構成です。
第1段階：CSMの視点を定義する
Gemini（必要に応じてDeep Thinkを活用）とCSM研修資料を使います。
CSMがあらゆるプロセスで何を重視するのかを明文化するのです。
具体的には以下の項目を整理します。
タッチポイント、責任範囲、依存関係、リスク、必要なインプット・アウトプット、SLAへの影響、更新・保証への影響などです。
このとき、多義的な用語への対応が重要になります。
「ルーター」「サイト」「アセット」といった用語について、CSM視点での解釈を明示的に記述します。
これを「CSM評価基準」として安定したテンプレートに落とし込みます。
第2段階：各部門のSOP（標準作業手順書）を圧縮する
Deep Research（またはGemini API）を使って、各部門の膨大なSOPに評価基準を適用します。
3,000〜4,000ページの原本から、「部門X：CSMビュー」という大幅に圧縮された文書を生成するイメージです。
この圧縮文書には以下の内容を含めます。
- CSMに関連するライフサイクルステージ
- 必要なCSMアクション
- 部門間の依存関係
- 多義的用語の注釈（「このSOPで『ルーター』と言っている場合、CSMにとっての意味はこうだ」）
- 原本の該当セクションへのポインタ
第3段階：NotebookLMでキュレーションする
NotebookLMを「キュレーションと精製のレイヤー」として活用します。
CSM研修資料のコア部分と、第2段階で生成した各部門のCSMビュー文書をNotebookLMに投入するのです。
ここで行うのは以下の作業です。
部門横断での概念のリンク付け、ライフサイクルステージごとのプレイブック生成、部門間の矛盾や抜け漏れの発見などです。
NotebookLMは「第2の脳」として、CSMの知識体系を整理・洗練する場となります。
第4段階：カスタムGemに統合する
精製されたCSMレイヤーをカスタムGemに投入します。
これで、カスタムGemは大幅に圧縮された高品質なコーパスで動作するようになるでしょう。
CSMは次のような質問ができるようになります。
「プロジェクトタイプYのステージZで何をすべき？」「SOPでXルーター構成と書いてあるけど、保証や契約にどう影響する？」といった内容です。
原本の数万ページを直接参照する必要がなくなります。
議論から見える設計上の論点
この投稿で提起された問いは、同様の課題に取り組む人々にとって示唆に富んでいます。
まず、NotebookLMの位置づけをどうするかという問題があります。
CSMオントロジーやプレイブックを設計する「作業場」として使うのか。
それともCSMが日常的に問い合わせる「メインアシスタント」として使うのか。
あるいはカスタムGemにフィードするための「中間層」として使うのか。
この選択は、ワークフロー全体の設計に影響を与えます。
次に、多義的用語をスケーラブルに処理する方法です。
文脈を明確にする情報が、読んでいるSOP本体とは別の文書に存在する場合があります。
どう対処すべきでしょうか。
NotebookLMのクロスソース理解機能に頼るのか、プロンプトエンジニアリングで解決するのか、API呼び出しの設計で対応するのか。
検討が必要です。
知識の構造化方法も重要なテーマです。
部門別（「部門Xプレイブック」）で整理するか、ライフサイクルステージ別で複数部門を横断してまとめるか。
グラフ構造のようなハイブリッド形式を採用する選択肢もあります。
ハルシネーション対策も見逃せません。
「提供された文書に明確な記述がなければ、わからないと言ってください」といった厳格なプロンプトを設定する方法があります。
これがGeminiやNotebookLMで有効に機能するかどうかは、検証が必要でしょう。
現実的な実装への道筋
投稿者が最終的に求めていたのは、安易な答えではありませんでした。
「全部放り込んで良いプロンプトを書けば解決」というアプローチではないのです。
求められていたのは三層構造の実現です。
まず、役割特化の視点を構築する。
次に、巨大な知識ベースに対してその視点をスケーラブルに適用する。
そして、精製された知識を日常業務に使えるUIに統合する。この流れです。
Googleツールのみという制約下でも、Apps Scriptなどの軽量なスクリプトを組み合わせることで、パイプラインの自動化は視野に入ります。
Driveをスキャンし、チャンク＋ルブリックをGemini/Deep Researchに送ります。
「CSMビュー」文書を専用フォルダに書き出し、そのフォルダをNotebookLMやカスタムGemにフィードするという流れです。
まとめ
この議論が示しているのは、単なるRAG構築の技術論ではありません。
より本質的なアプローチの重要性です。
「特定の役割が持つべき視点」を明示的に定義する。
そして、その視点を通じて膨大な組織知識をフィルタリングする。
この発想が鍵となります。
LLMは文書を「読む」ことはできます。
しかし「どの情報がこの役割にとって重要か」を判断する基準は、外部から与える必要があります。
その基準（ルブリック）の設計こそが、役割特化型ナレッジベース構築の核心なのでしょう。
GoogleのAIツール群は、それぞれ異なる強みを持っています。
これらを適切に組み合わせるアーキテクチャ設計が、実用的なシステム構築の鍵を握っているのです。
