前編(検索編)では、過去議事録を「聞けば出てくる」状態にするための、ノートブック設計と検索のコツをご紹介しました。
ただ、現場で一番つらいのは「そもそも議事録を整える作業」ですよね。
中編では、NotebookLMを使って、文字起こしやメモ書きから「整った議事録」を生成するためのコツをまとめます。
議事録を生成する「速さ」だけでなく、次の2点を満たすことをゴールにします。
議事録を生成するだけであれば、ZoomやGoogle Meetの文字起こしで十分ですが、ワンステップ挟むことで、より高品質な議事録を作成することができます。
AI議事録については、下記のブログも是非ご覧ください。
NotebookLMはソースに強く引っ張られます。生成の精度は、投入する文字起こし・メモの整え方で決まります。
次のような情報を用意しておくことで、効率的に議事録を生成することができます。
議事録フォーマットとして、たとえば次のようなものを用意しておくといいでしょう。
# 議事録:{会議名}
## 会議情報
- 日時:
- 参加者:
- 目的:
- アジェンダ:
## サマリ(3行)
## 決定事項
- (決定事項)/根拠:
## 議論メモ(論点ごと)
### 論点:
- 要点
- 保留/未決
## ToDo(担当・期限)
- 担当:/内容:/期限:/根拠:
## 未決・次回確認
- 内容/確認先
たとえばGoogle Meetであれば、文字起こしデータに話者情報が入っています。
次のように、話者が入っているとより精度よく議事録生成することができます。



生成は「一発で完成」を狙うより、型 → 下書き → レビュー → 差分修正で回す方が安定します。
前編(検索編)でも触れた通り、議事録で困るのは「それっぽい補完」です。
推測を禁止し、書けないものは「不明」と明記させます。
## ルール
* 回答の根拠は、必ず「提供されたソース」のみとする。
* ソースに書かれていない事実・数値・決定事項を推測で補完しない。
* 情報が不足している場合は「不明」と書き、必要な確認質問を列挙する。
* 決定事項・ToDo・重要な数値には、根拠となる引用を必ず付ける。
添付ソース(文字起こし+メモ+アジェンダ)から、議事録を作成してください。
追加で確認すべき質問があれば、最大5つまで最後に記載してください。
## ルール
* 出力は添付ソース(議事録フォーマット)に厳密に合わせる。
* 回答の根拠は、必ず「提供されたソース」のみとする。
* ソースに書かれていない事実・数値・決定事項を推測で補完しない。
* 情報が不足している場合は「不明」と書き、必要な確認質問を列挙する。
* 決定事項・ToDo・重要な数値には、根拠となる引用を必ず付ける。
この型で出すと「議事録としての見た目」が揃い、後から検索・横断がしやすくなります。
ここでは、短い文字起こしを例にします。
実務では、文字起こし・メモ・アジェンダなどを取りあえず全部入れて試してみると良いでしょう。
PM: 今日の目的は、来週リリースの範囲を確定することです。
Dev: i18nは日本語・英語の2言語までなら間に合います。追加言語は次スプリントが良いです。
PM: では今回のリリースは2言語で確定。追加言語は検討事項にしましょう。
QA: モバイルの表示崩れが一部あります。確認に2日ほしいです。
PM: QAの確認を優先。リリース判定は金曜にしましょう。
このソースを入れたうえで、先ほどのテンプレで依頼すると、次のような形にまとまります。
議事録:{会議名}
1. 会議情報
* 日時: 不明
* 参加者: 不明(役割としてPM, Dev, QAの参加が確認されている)
* 目的: 来週リリースの範囲を確定すること
* アジェンダ: 不明
2. サマリ(3行)
* 来週リリースの国際化(i18n)対応は、日本語・英語の2言語に決定した。
* QAチームより報告のあったモバイル表示崩れの確認作業を最優先で実施する。
* 上記の確認結果を踏まえ、リリース判定は金曜日に実施することになった。
3. 決定事項
* 来週のリリースにおける国際化(i18n)対応は日本語・英語の2言語とする / 根拠:「PM: では今回のリリースは2言語で確定。」
* リリース判定は金曜日に実施する / 根拠:「PM: リリース判定は金曜にしましょう。」
4. 議論メモ(論点ごと)
4.1. 論点:次期リリースのi18n対応範囲
* 要点:
* 開発担当より、日本語・英語の2言語対応は今回のリリース範囲内で可能である旨の報告があった。
* 保留/未決:
* 日本語・英語以外の追加言語対応は次スプリント以降の検討事項とする。
4.2. 論点:モバイルでの表示崩れとリリース判定
* 要点:
* QA担当より、一部のモバイル端末で表示崩れが発生しており、確認に2日間を要するとの報告があった。
* PMはQAによる表示崩れの確認作業を優先し、その結果をもって金曜日にリリース判定を行うことを決定した。
5. ToDo(担当・期限)
* 担当: QAチーム / 内容: モバイルにおける表示崩れの確認と報告 / 期限: 金曜日まで / 根拠: 「QA: モバイルの表示崩れが一部あります。確認に2日ほしいです。」、「PM: QAの確認を優先。リリース判定は金曜にしましょう。」
6. 未決・次回確認
* 内容: i18n対応における追加言語(日本語・英語以外)の要否と実装時期 / 確認先: 不明
7. 確認事項
1. この会議の正式名称、開催日時、および全参加者の氏名と役職を教えてください。
2. QA担当が報告した「モバイルの表示崩れ」の具体的な事象(対象OS、ブラウザ、画面など)を教えてください。
3. モバイル表示崩れの確認タスクの主担当者はどなたになりますか?
4. 今後、i18nの追加言語対応を検討する際の意思決定者(確認先)はどなたになりますか?
5. ソースには記載がありませんでしたが、この会議で用いられた正式なアジェンダがあればご教示ください。
ポイントは、「不明」をそのまま残し、確認質問を出させることです。
ここで推測させてしまうと、後で必ず混乱します。
NotebookLMは「議事録の初稿」を高速に作れますが、他のAI議事録ツールや生成AIチャットツールと同様に、最終責任は人間側に残ります。
レビュー工程を前提に設計した方が、結果的に速く、高品質な議事録を作成できると考えられます。
NotebookLMは入力されたデータを学習しないことを明記しています。ただし、フィードバックを送信するなどすることで閲覧される可能性があります。極めて重要な機密情報については入力を控える方がよいでしょう。
NotebookLM ヘルプ > NotebookLM の詳細 > NotebookLM でデータを保護する仕組み
NotebookLMを使うと、文字起こしやメモから、一定の型を満たした議事録を速く作れるようになります。
中編のポイントは、生成AIに「うまく書かせる」ことよりも、推測を禁止し、レビューしやすい形に寄せることです。
後編(活用編)では、複数の議事録をまとめて「特定の人のネクストアクションを整理する」「課題を深掘りする」「要点を可視化する」といった、議事録の使い倒し方をご紹介します。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。