過去の議事録をAIで探せるようにするには、会議ごとの要約だけでなく、同じ議題がどの会議で扱われ、何が決まり、後で何が変更されたかをたどる索引を作ります。「この案件の納期はいつ決まった？」に答えるためには、検索で見つかった一文を示すだけでは足りません。案件、会議日、議題、原文の位置、決定の状態を結び付けておきます。
ここでは、保存済みの議事録を対象に、AIで議題の候補を抽出し、人が照合して会議を横断する索引へ整理する手順を説明します。新たな録音や自動公開は行いません。Notionを整理先の例にしますが、列を持つ表でも同じ考え方を使えます。以下の記録・出力例は説明用の架空データで、製品上での動作やAIの検索精度を実測したものではありません。
目次
先に「何を探したいか」を三つに分ける
まず、実際に担当者が聞く質問を書き出します。すべてを「関連する議事録を探す」にすると、現在の結論と当時の経緯が混ざります。
表は横にスクロールできます
| 質問の種類 | 必要な答え | 原文で確かめること |
|---|---|---|
| 経緯を知りたい | 議論・決定・変更の順序 | どの会議で何を述べたか |
| 現在の決定を知りたい | 対象案件に適用する確認済みの決定 | 後続会議の変更・撤回・条件 |
| 過去の時点を知りたい | 指定日までの記録に基づく状態 | 指定日より後の情報を混ぜていないか |
「今はどうなっている？」には、索引の確認範囲も必要です。9月までの議事録しか入っていないなら、10月の現在の決定を保証できません。「確認した記録は9月30日分まで」と回答に残す設計にします。
原本を残し、会議と議題を別の単位にする
最初に、一つの案件・定例会議の数回分だけを選びます。利用が認められた記録か、整理先を誰が閲覧できるかを確認し、元議事録はそのまま保管します。AIへの入力や索引の共有で、元の閲覧範囲を広げないでください。
会議の一覧には、会議ID、案件ID、会議日、記録の版、原文リンク、確認範囲を置きます。議題の一覧には、議題ID、案件ID、議題名、別名候補を置きます。「見積」「費用」「予算」のような似た語は、同じ議題かを人が判定してからまとめます。別案件の「見積」は同じ議題にしません。
次に、会議と議題の間に「議題が扱われた記録」を作ります。一つの会議には複数の議題があり、一つの議題は複数の会議に登場するためです。
表は横にスクロールできます
| 記録に持たせる列 | 使い道 |
|---|---|
| 会議ID・案件ID・議題ID | 別の案件や会議との混同を防ぐ |
| 会議日・原文の版 | 内容が述べられた時点と参照版を残す |
| 発言の要旨・原文位置 | 要旨から該当段落や時刻へ戻る |
| 区分 | 提案、決定、条件付き決定、保留、変更、撤回を分ける |
| 前の記録ID | 何を変更・撤回したのかをたどる |
| 確認状態・確認者 | AIの抽出候補と人が確認した記録を区別する |
Notionのリレーションは、データベースの項目同士を関連付ける仕組みです。会議と議題、変更前と変更後の記録を結ぶ整理に利用できます。ただし、関連付けだけで「どちらが有効か」が自動的に決まるわけではありません。Notion公式：リレーションとロールアップ（新しいタブで開く）
AIには議題候補と原文位置を出させる
会議名だけから議題を決めず、本文の該当箇所も一緒に渡します。長い記録を分けて処理する場合は、各入力に会議IDと段落番号を付けます。途中が欠けている入力には、その範囲を明記します。
次の依頼文は、索引の候補を作るための例です。
入力した議事録だけから、議題別索引の候補を作ってください。
出力列：会議ID｜案件ID｜議題名候補｜要旨｜区分｜原文位置｜確認事項。
一つの行には一つの議題内の一つの主張を置いてください。
提案・決定・条件付き決定・保留・変更・撤回を区別してください。
明記されていない承認、適用日、担当者を補わないでください。
既存の議題一覧と対応する候補を示し、同名の別案件は結合しないでください。
変更や撤回の対象が特定できない場合は「対象確認待ち」としてください。
原文位置を確認できない行は、その理由を確認事項に残してください。
既存の議題一覧：［案件IDと議題ID、議題名、別名］
入力範囲：［会議ID・会議日・版・段落範囲と、利用可能な本文］
出力後は、議題名よりも案件IDと原文位置を先に確認します。「導入日」と「検証開始日」、「見積依頼」と「発注承認」は似た文章でも別の話です。名称が似ているという理由だけで、AIが同じ議題や同じ決定へまとめていないかを照合します。
決定の上書きではなく、変更のつながりを残す
次の表は、架空の案件Aに関する例です。記録日と内容の更新関係を示すためのもので、AIの実出力ではありません。
表は横にスクロールできます
| 記録ID | 会議日 | 原文にある内容 | 索引での扱い |
|---|---|---|---|
| A-01 | 9月2日 | 「納品日は9月30日とする」 | 決定の記録 |
| A-02 | 9月9日 | 「10月7日への延期を検討したい」 | 提案。A-01を失効させない |
| A-03 | 9月16日 | 「納品日は10月7日に変更することで合意」 | A-01を変更した記録として関連付ける |
この範囲を人が確認済みなら、「9月16日の会議で10月7日へ変更した」と説明できます。一方、9月9日までの状態を聞かれた場合に、9月16日の決定を混ぜてはいけません。
「条件が整えば延期する」としか書かれていない場合は、条件が成立した証拠まで必要です。新しい日付の記録というだけで採用しません。原文に変更対象が明記されていない、会議同士で食い違う、承認の有無が分からない場合は、両方を提示して「現行決定は確認待ち」とします。
古い記録を削除すると、なぜ方針が変わったのか調べられなくなります。履歴を残したまま、現在の状態を尋ねる検索と、経緯を尋ねる検索で参照する範囲を分けます。
検索できないときは、検索対象を切り分ける
Notionでは、データベース内検索はページ名やプロパティ値を対象とし、ページ本文は対象にしません。本文にしかない言葉を探す場合は、ワークスペース検索など別の経路を使います。議題IDや別名をプロパティへ持たせるのは、本文の内容をすべて自動検索できるからではなく、探すための手掛かりを明示するためです。Notion公式：検索（新しいタブで開く）
また、最終編集日は会議日と同じとは限りません。昔の議事録を昨日修正しただけで、その会議の決定が最新になったとは扱わないでください。会議日、適用日、編集日は別々に確認します。
Notion AIで利用可能な検索は、ワークスペースでの提供状況や接続された情報源に依存します。この手順は、索引を用意すれば任意のAIが全記録を自動取得するという保証ではありません。AIに参照させた会議の一覧と、参照できなかった範囲を答えに残します。原文を開けない利用者へ、要約だけを別の場所から渡してよいかも確認してください。Notion公式：共有と権限（新しいタブで開く）
少数の質問で、取り違えと見落としを確かめる
整理した記録から、人が正解と根拠を確認できる質問を用意します。最低限、同名の別案件、提案のままの変更、確定した変更、指定日以前の状態、記録に答えがない質問を含めます。
回答は「結論／対象案件／基準時点／参照した会議と原文位置／確認待ち」に分けて読みます。結論が合っていても、根拠が別案件なら失敗です。正しい会議が見つからない場合は、入力漏れ、議題の別名、検索範囲、閲覧権限を順に確認し、原文にない答えを生成させて埋めません。
新しい会議を追加したときは、新しい候補の作成だけでなく、同じ議題の過去の記録と関係するかも確認します。表記の修正は既存行の訂正、決定の変更は新しい履歴として扱うなど、更新の区別を決めておくと経緯が残ります。AIの回答精度や作業時間の削減率は、記録と質問を固定して測るまでは数値で断定しないでください。
一回の会議から担当と期限を拾う段階なら、議事録からタスクを抽出する方法が先です。会議記録以外の社内文書も含めて回答の根拠を設計する場合は、出典付きチャットボットのナレッジ設計も参照してください。
参考資料
仕様の確認日：2026年10月20日。操作画面、AI検索の利用条件、接続先の仕様は利用する環境の公式案内で確認してください。