生成AIの活用ノウハウや、 注目の技術に関する記事を掲載
公開
更新

NotebookLMで議事録活用【検索編】

はじめに

議事録は「残す」こと自体はできても、あとから活用するところで詰まりがちです。たとえば、

  • 「あの決定はいつ・誰が・どの文脈で決めた?」を探せない
  • 文字起こしはあるのに、議事録の体裁に整えるのが面倒
  • 議事録は増えるのに、ネクストアクションが散らばって消える

といった問題です。
本記事では、NotebookLMを使って、議事録を「検索する」「作る」「次の行動に繋げる」3つの活用例を連載形式で紹介します。

NotebookLMを議事録に使う前提

NotebookLMは、一般的なチャットAIと比べて「ソース(根拠)前提」で使えるのがポイントです。

  • アップロードした議事録(ソース)に基づいて、要点抽出・横断整理・QAができる
  • 回答に引用(どのソースのどこを根拠にしたか)が付くため、レビューしやすい
  • ソースに基づいて、新たなレポートやスライドを生成できる

結論として、NotebookLMは「議事録の保管庫」ではなく、議事録を使い倒すための検索・編集・要約レイヤーとして設計すると、期待値が揃いやすいです。

ノートブック設計

3つの例に入る前に、最小限の設計だけ決めておくと失敗しにくくなります。

  • ノートブックの単位:プロジェクト単位 / チーム単位 / 顧客単位
  • 議事録ファイル名:YYYY-MM-DD_会議名_テーマ.md
  • 議事録の最小構造:会議情報(日時/参加者/目的)+決定事項+ToDo

この「最小構造」が揃っていると、①検索・②生成・③可視化の精度が一気に上がります。

過去議事録を「検索できる」ようにする

前編では、過去議事録を検索できる状態にするコツについて、ご紹介します。

ねらい

キーワード検索では拾えない「言い換え」や「文脈」を含めて、議事録から答えを引ける状態を作ります。

手順

  1. NotebookLMでノートブックを作る(例:PJ-A 議事録)
  2. 過去の議事録をソースとして追加する

– ソースを追加から、ファイル(Markdown/PDF/テキスト)をアップロード
– Google Drive上のGoogle Docs/Sheets/Slidesでの連携も可能

  1. 中央のチャット欄で質問する

NotebookLMにソースを追加

質問プロンプト例

user.md

1. 最新の決定事項は何ですか?いつ決まりましたか?
2. 未解決の論点を列挙してください。
3. 直近のToDoを担当者・期限つきで一覧にしてください。
assistant.md

### 1. 最新の決定事項と決定日

最新の決定事項は、**2026年1月6日**に開催された「技術ブログ定例(生成AI)議事録:LLM運用」にて合意された内容です。

主な決定事項は以下の通りです:

*   **次週公開の記事テーマ**:
    *   記事A:「LLM運用の基本:SLO・ログ・評価をつなぐ実務テンプレ」
    *   記事B:「LLMコスト最適化:品質を落とさず削るための実装パターン」
*   **記事の方針**:運用の話は抽象的になりがちなため、監視指標やアラート例を具体化し、「やることリスト」や「判断基準」を中心に構成する。
*   **最低限の監視項目**:レイテンシ、エラー率、トークン消費、拒否率、引用率(RAG時)、ユーザー再試行率を採用する。

### 2. 未解決の論点

直近の会議資料において、明確に「保留」または「次回以降の検討課題」とされた論点は以下の通りです:

*   **ガバナンス(権限・監査・PII)の詳細計画**:
    今回はLLM運用の「監視・コスト・品質」に焦点を当てたため、ガバナンス関連の記事化は**次々週以降**に計画することとし、今回は用語定義の追記に留めるとしています。
*   **「チェックリスト」の実装可否**:
    各記事に「コピペ可能なチェックリスト」を付けることが提案されていますが、「可能であれば」という条件付きであり、具体的な実装内容や必須化については制作過程での調整余地が残されています。

### 3. 直近のToDo(担当者・期限)

最新の議事録(2026-01-06)に基づくアクションアイテム一覧です。期限は文脈上、次回の定例または記事作成期限(次週公開に向けた準備完了)となります。

| 担当者                     | 期限(想定)    | タスク内容                                                                                                          |
| :------------------------- | :-------------- | :------------------------------------------------------------------------------------------------------------------ |
| **担当者(あなた)**       | 次回定例/執筆時 | **記事A(運用)**:監視・ログ・評価・リリースの運用テンプレを箇条書き作成し、各項目に「最低限の実装例」を付与する。 |
| **担当者(あなた)**       | 次回定例/執筆時 | **記事B(コスト)**:コスト削減策を5つ列挙し、それぞれの効果・副作用・適用条件を1行ずつ整理する。                   |
| **編集担当**               | 次回定例/執筆時 | **図表作成**:運用フロー(入力→推論→評価→改善)を1枚にまとめた図の案を作成する。                                    |
| **レビュー担当(SRE/ML)** | 次回定例/執筆時 | **指標・用語確認**:監視指標の妥当性チェック、および運用用語(SLO/SLA、アラート閾値表現など)の定義確認を行う。     |

***

**理解を深めるためのアナロジー:**

今回の一連の動きを「レストラン経営」に例えると分かりやすいかもしれません。

*   **12/23のプロンプト設計**は、美味しい料理を作るための**「レシピ開発」**でした。
*   **12/30のRAG評価**は、料理の味や提供品質をチェックする**「試食会と採点基準作り」**でした。
*   そして**1/6のLLM運用(今回)**は、お店を安定して回すための**「厨房のオペレーション(在庫管理・提供スピード・原価計算)」**を決める段階に入ったと言えます。

まずは良いモノを作り(プロンプト)、品質を保証し(評価)、最後にそれを継続的かつ効率的に提供する仕組み(運用)を整える、という順序でブログ記事の構成が進んでいます。

チャットの結果

NotebookLMは生成時にソースを引用するため、何を根拠にしたのかを簡単に辿ることができるのが特徴です。

参照したソース

検索しやすいソースの整え方

NotebookLMはソースの書き方に引っ張られます。最小限でも次を揃えると、「聞けば出てくる」状態になりやすいです。

  • 1会議1ファイル(後から時系列で追いやすい)
  • 冒頭に会議情報(日時/参加者/目的)を固定で置く
  • 議題ごとに見出しを切る(例:## 議題:モバイル対応)
  • ## 決定事項 / ## 未決・検討中 / ## ToDo の見出しを固定で入れる
  • ToDoには可能な限り「担当」「期限」を書く(検索で「誰の宿題か」が取れる)
  • 関連資料(チケットURL/仕様書/スライド等)も一緒にソース化する(背景の検索に効く)

精度を上げるコツ

  • 用語の揺れが多いプロジェクトは、「用語集/略語集」を1枚作ってソースに追加する
  • 議事録が長い場合は、月ごと/四半期ごとにノートブックを分ける
  • 「決定事項」「ToDo」を見出しで分けておく
  • 「このテーマの会議はどれ?」が頻出なら、会議の一覧(会議日/会議名/主要トピック)を1枚作ってソースに追加する
  • 議事録だけでなく、前提となる仕様書・チケット・要件メモも同じノートブックに入れる

また、チャットの設定で生成AIに知識を渡しておくこともポイントです。
たとえば、このノートブックで管理している議事録の目的などを渡しておくと、より良い回答を期待することができます。

チャットの設定

推測を禁止するようなシステムプロンプトを渡してみます。

system.md

## 2) 情報源の優先順位(最重要)

* 回答の根拠は、必ず「提供された議事録(Markdown)」のみとする。
* 議事録に書かれていない事実・数値・決定事項を推測で補完しない(推測は禁止)。
* 一般論の補足が必要な場合でも、議事録と矛盾しない範囲で「一般的には〜」と明示し、議事録由来ではないことを区別する。

ここで、先ほどの議事録では3. 直近のToDo(担当者・期限)において、期限(想定)という形で勝手に埋め合わせがされていましたが、このシステムプロンプトを入れてから同様のチャットを行うと、違う結果が得られることが分かります。

チャットの設定後のチャット結果

期限が勝手に推測で埋められていないことが分かります。

回答を検証する

NotebookLMの強みは「引用」ですが、重要な決定ほど「引用 → 原文」の順で確認する運用が安全です。

  • 引用が薄い/付かない場合は「引用必須」で再質問する
  • 決定事項は「根拠の抜粋」を取ってから判断する
  • 議論の経緯は「関連する会議の列挙 → 会議ごとの要点」の順に聞くと追いやすい

注意点

  • 引用が付かない/薄い回答は信用しない
  • 同名ファイルが多いと混乱するので、ファイル名に日付を入れる
  • 同じ会議の改訂版が混ざると答えがブレるため、古い版は削除する
  • 機密情報を扱う場合、フィードバックを送信しないこと

NotebookLMは入力されたデータを学習しないことを明記しています。ただし、フィードバックを送信するなどすることで閲覧される可能性があります。極めて重要な機密情報については入力を控える方がよいでしょう。
NotebookLM ヘルプ > NotebookLM の詳細 > NotebookLM でデータを保護する仕組み

まとめ

NotebookLMを使うことで、議事録をアップロードするだけで、チャット形式で聞くことができるようになります。
中編では、文字起こしデータから議事録をNotebookLMで「生成」するコツについてご紹介いたします。

中編はこちら

生成AI関連
NotebookLMで議事録活用【生成編】

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。

  1. 無料診断パック:業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
  2. 検証(PoC)パック:診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
  3. コンサルティングサービス:生成AI導入戦略の策定から運用体制構築までを包括的に支援します。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム
Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。

ARTICLE
生成AI関連記事一覧

生成AI関連

Amazon Bedrock Managed Knowled…

生成AI関連

Google Sheets canvasはどこまで業務アプリ…

生成AI関連

Amazon BedrockのRerank APIで検索順位…

生成AI関連

OpenAI Agents APIとは?本番運用に必要な5つ…

生成AI関連

Codex App Serverとは?Pythonでの使い方…

生成AI関連

Amazon Bedrockの基盤モデルパーサーを実測する―…

生成AI関連

ChatGPT WorkのScheduled TasksをW…

生成AI関連

Amazon Bedrock Knowledge Bases…

生成AI関連

ChatGPTのChat・Work・Codexの違い|5時間…

記事一覧を見る