議事録は「残す」こと自体はできても、あとから活用するところで詰まりがちです。たとえば、
といった問題です。
本記事では、NotebookLMを使って、議事録を「検索する」「作る」「次の行動に繋げる」3つの活用例を連載形式で紹介します。
NotebookLMは、一般的なチャットAIと比べて「ソース（根拠）前提」で使えるのがポイントです。
結論として、NotebookLMは「議事録の保管庫」ではなく、議事録を使い倒すための検索・編集・要約レイヤーとして設計すると、期待値が揃いやすいです。
3つの例に入る前に、最小限の設計だけ決めておくと失敗しにくくなります。
この「最小構造」が揃っていると、①検索・②生成・③可視化の精度が一気に上がります。
前編では、過去議事録を検索できる状態にするコツについて、ご紹介します。
キーワード検索では拾えない「言い換え」や「文脈」を含めて、議事録から答えを引ける状態を作ります。
– ソースを追加から、ファイル（Markdown/PDF/テキスト）をアップロード
– Google Drive上のGoogle Docs/Sheets/Slidesでの連携も可能
1. 最新の決定事項は何ですか？いつ決まりましたか？
2. 未解決の論点を列挙してください。
3. 直近のToDoを担当者・期限つきで一覧にしてください。
### 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はソースの書き方に引っ張られます。最小限でも次を揃えると、「聞けば出てくる」状態になりやすいです。
また、チャットの設定で生成AIに知識を渡しておくこともポイントです。
たとえば、このノートブックで管理している議事録の目的などを渡しておくと、より良い回答を期待することができます。
推測を禁止するようなシステムプロンプトを渡してみます。
## 2) 情報源の優先順位（最重要）
* 回答の根拠は、必ず「提供された議事録（Markdown）」のみとする。
* 議事録に書かれていない事実・数値・決定事項を推測で補完しない（推測は禁止）。
* 一般論の補足が必要な場合でも、議事録と矛盾しない範囲で「一般的には〜」と明示し、議事録由来ではないことを区別する。
ここで、先ほどの議事録では3. 直近のToDo（担当者・期限）において、期限（想定）という形で勝手に埋め合わせがされていましたが、このシステムプロンプトを入れてから同様のチャットを行うと、違う結果が得られることが分かります。
期限が勝手に推測で埋められていないことが分かります。
NotebookLMの強みは「引用」ですが、重要な決定ほど「引用 → 原文」の順で確認する運用が安全です。
NotebookLMは入力されたデータを学習しないことを明記しています。ただし、フィードバックを送信するなどすることで閲覧される可能性があります。極めて重要な機密情報については入力を控える方がよいでしょう。
NotebookLM ヘルプ > NotebookLM の詳細 > NotebookLM でデータを保護する仕組み
NotebookLMを使うことで、議事録をアップロードするだけで、チャット形式で聞くことができるようになります。
中編では、文字起こしデータから議事録をNotebookLMで「生成」するコツについてご紹介いたします。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
