AIで議事録からTODOを自動抽出｜担当者・期限・根拠まで登録する実務フロー

会議が終わるたびに議事録を読み返し、「誰が・何を・いつまでに進めるのか」を手作業で整理していませんか。

議事録は残っているのに、担当者が曖昧なまま放置される。次回の会議で同じ確認を繰り返す。売上に直結する見積提出や商品ページ修正が、ほかのメモに埋もれてしまう。この状態では、会議を開くほど管理作業が増えてしまいます。

そこで役立つのが、AIによる議事録からのTODO自動抽出です。

この記事では、議事録をAIへ渡し、作業内容・担当者・期限・根拠となった発言を抽出して、NotionやGoogle Sheetsへ登録する方法を解説します。通知、重複防止、定期実行、障害検知まで接続し、人間の確認を最小限に抑える手順も扱います。

狙うのは、単なる時短ではありません。商談後の見積作成、アフィリエイト記事の更新、商品ページ改善、ポイント案件の期限確認など、収益につながる行動を会議から確実に発生させる仕組みを作ることです。

ただし、AIを導入しただけで収益が生まれるわけではありません。収益額や削減時間は、会議数、業務内容、抽出精度、実行体制によって変わります。本記事は一般的な情報提供を目的としており、利益や成果を保証するものではありません。

検証環境で確認した一次情報

この記事を一般論だけで終わらせないため、Hiroが運用する auto-ai-blog のローカル環境を、2026年7月16日に確認しました。

確認時点のMarkdown投稿ファイル数は、次の通りです。

集計対象は、各サイトの sites/<site-name>/content/posts 直下にある .md ファイルです。下書きと公開済み記事を区別していないため、「公開記事が743本ある」という意味ではありません。

また、次のコマンドでAIスロップ防止関連テストを実行しました。

python -m pytest tests/test_slop_guard.py tests/test_validate_ai_slop.py -vv

実行環境はPython 3.11.9、pytest 8.4.2です。結果は3件すべて成功、実行時間0.14秒でした。

さらに、リポジトリ内の generator/ai_slop_guidelines.json には、2026年6月26日に取得されたNotion由来の品質基準が保存されています。最低スコアは8点で、固有データ、数字の根拠、視覚的証拠、限界の説明、読了後の行動など、10項目が定義されています。

ただし、これらは記事制作環境と品質テストの存在を示すものであり、後述するTODO抽出フローの精度や収益効果を証明するデータではありません。本フローの効果は、実際の議事録と人間が作成した正解TODOを比較して、別途測定する必要があります。

本記事では、この限界を明示したうえで、結果をログで検証できる運用として設計します。

AIによる議事録・TODO自動抽出の全体像

処理の流れは、次の7段階に分けられます。

会議の録音・メモ
      ↓
文字起こし・議事録の保存
      ↓
AIがTODO候補を抽出
      ↓
形式・必須項目を機械的に検査
      ↓
NotionやGoogle Sheetsへ登録
      ↓
担当者への通知・期限前リマインド
      ↓
完了状況と収益関連KPIを集計

AIには文章を要約させるのではなく、システムが読み取れる構造化データを作らせます。構造化データとは、項目名と値が決まっているデータです。例えば、次のようなJSONを指します。

{
  "task": "見積書を更新して顧客へ送付する",
  "owner": "田中",
  "due_date": "2026-07-22",
  "priority": "high",
  "source": "田中さんが来週水曜までに見積書を更新して送ります",
  "needs_review": false,
  "review_reason": ""
}

この形なら、別のプログラムが担当者や期限を読み取り、タスク管理ツールへ自動登録できます。

一般的なAI要約との違いは、入力・抽出・検査・登録・通知・KPI・収益行動を一つの流れとして設計する点です。

ステップ・バイ・ステップで作るTODO自動抽出フロー

1. 自動化する会議を一種類に絞る

最初からすべての会議を対象にしないでください。会議の種類によって、TODOの定義や誤作動したときの危険度が異なるためです。

開始しやすい例は、次の通りです。

• ブログ編集会議から記事更新TODOを作る
• 商談議事録から見積・資料送付TODOを作る
• 商品改善会議からCTAや価格表の修正TODOを作る
• 外注定例から納品確認TODOを作る
• ポイント案件の検討会から申込期限の確認TODOを作る

法務、採用、返金、契約承認など、判断責任が重い会議は初回の対象に向きません。

2. 議事録の形式を固定する

AIの精度は、モデルだけでなく入力品質にも左右されます。最低限、次の項目を議事録へ入れます。

# 会議名

開催日: 2026-07-16
会議ID: sales-20260716-01
参加者: 田中、佐藤、鈴木

## 決定事項

## TODO候補

## 保留事項

## 会話メモ

開催日が必要なのは、「来週水曜」「月末」「次回まで」といった相対期限を日付へ変換するためです。処理日を基準にすると、過去の議事録を再処理した際に期限が変わる恐れがあります。

会議IDは、再処理時の重複登録を防ぐために使用します。日時だけでは同時刻の会議を区別できないため、部署名や案件名も含めると安全です。

3. TODOとして採用する条件を決める

AIへ「TODOを抽出して」とだけ頼むと、感想や検討事項までタスク化されることがあります。採用条件を先に定義します。

自動登録候補

• 作業内容が具体的である
• 担当者が明示されている
• 期限を日付へ変換できる
• 社内作業であり、外部への確定回答ではない
• 元の発言を根拠として保存できる

人間の確認へ回す候補

• 担当者または期限が不明
• 金額、契約、発注、返金を含む
• 顧客への正式回答を伴う
• 個人情報や機密情報を含む
• 発言者の意図を複数の意味に解釈できる

確認が必要なTODOには、needs_review: true を付けます。AIに無理な推測をさせるより、「不明」と返させる方が安全です。

4. JSON出力用のプロンプトを作る

次のテンプレートをコピーし、直近の議事録で試してください。

あなたは会議後のタスク整理担当です。
以下の議事録から、実行可能なTODOを抽出してください。

前提:
- 会議日は {{meeting_date}} です
- 参加者は {{participants}} です
- 相対期限は会議日を基準に YYYY-MM-DD へ変換してください
- 変換できない期限は "未設定" にしてください

抽出条件:
- 具体的な作業が発生する発言だけを対象にする
- 感想、雑談、決定事項だけの文は除外する
- 担当者を推測で確定しない
- 根拠となった原文を source に保存する
- 同じ作業を言い換えただけの発言は一つにまとめる

出力条件:
- JSON配列のみを出力する
- 説明文やMarkdownを付けない
- 担当者不明なら owner を "要確認" にする
- owner、due_date、source のいずれかが不明なら
  needs_review を true にする
- priority は high、medium、low のいずれかにする
- review_reason は確認が必要な理由を短く記載する

出力項目:
task, owner, due_date, priority,
source, needs_review, review_reason

議事録:
{{meeting_minutes}}

例えば、議事録に次の発言があったとします。

田中: 見積書は私が来週水曜までに更新して送ります。
佐藤: 価格表も直した方がよさそうですね。

期待する出力は次の形です。

[
  {
    "task": "見積書を更新して顧客へ送付する",
    "owner": "田中",
    "due_date": "2026-07-22",
    "priority": "high",
    "source": "見積書は私が来週水曜までに更新して送ります",
    "needs_review": false,
    "review_reason": ""
  },
  {
    "task": "価格表を修正するか確認する",
    "owner": "要確認",
    "due_date": "未設定",
    "priority": "medium",
    "source": "価格表も直した方がよさそうですね",
    "needs_review": true,
    "review_reason": "担当者と期限が明示されていない"
  }
]

AIが返したJSONは、そのまま登録せず、プログラム側でも検査します。

検査例:
- taskが空なら登録しない
- sourceが空ならレビューへ送る
- due_dateが過去ならレビューへ送る
- ownerが参加者一覧にないならレビューへ送る
- priorityが許可値以外ならレビューへ送る
- 同じ会議IDとtask_hashが存在すれば重複登録しない

5. AIの出力をプログラムで検査する

プロンプトだけで出力品質を保証することはできません。最低限、JSONとして読めるか、必須項目があるか、担当者と期限が妥当かを機械的に確認します。

次は、Python標準ライブラリだけで行う最小例です。

import hashlib
import json
from datetime import date, datetime

ALLOWED_PRIORITIES = {"high", "medium", "low"}


def validate_task(item: dict, participants: set[str]) -> dict:
    required = {
        "task",
        "owner",
        "due_date",
        "priority",
        "source",
        "needs_review",
        "review_reason",
    }

    missing = required - item.keys()
    if missing:
        raise ValueError(f"必須項目がありません: {sorted(missing)}")

    review_reasons = []

    if not str(item["task"]).strip():
        raise ValueError("taskが空です")

    if not str(item["source"]).strip():
        review_reasons.append("根拠となる発言がありません")

    if item["owner"] not in participants:
        review_reasons.append("担当者を参加者一覧で確認できません")

    if item["priority"] not in ALLOWED_PRIORITIES:
        review_reasons.append("priorityが許可値ではありません")

    if item["due_date"] == "未設定":
        review_reasons.append("期限が未設定です")
    else:
        try:
            due_date = datetime.strptime(
                item["due_date"], "%Y-%m-%d"
            ).date()
            if due_date < date.today():
                review_reasons.append("期限が過去の日付です")
        except ValueError:
            review_reasons.append("期限の形式が不正です")

    if review_reasons:
        item["needs_review"] = True
        item["review_reason"] = "、".join(review_reasons)

    return item


def make_task_hash(meeting_id: str, item: dict) -> str:
    source = "|".join(
        [
            meeting_id,
            str(item["owner"]).strip(),
            str(item["task"]).strip(),
            str(item["due_date"]).strip(),
        ]
    )
    return hashlib.sha256(source.encode("utf-8")).hexdigest()


raw_response = """
[
  {
    "task": "見積書を更新して顧客へ送付する",
    "owner": "田中",
    "due_date": "2026-07-22",
    "priority": "high",
    "source": "見積書は私が来週水曜までに更新して送ります",
    "needs_review": false,
    "review_reason": ""
  }
]
"""

tasks = json.loads(raw_response)
participants = {"田中", "佐藤", "鈴木"}

for task in tasks:
    validated = validate_task(task, participants)
    validated["task_hash"] = make_task_hash(
        "sales-20260716-01",
        validated,
    )
    print(json.dumps(validated, ensure_ascii=False))

実運用では、処理日ではなく会議日と業務ルールを使って期限を検証してください。上のコードは構造を示す最小例であり、タイムゾーン、休日、担当者の表記揺れ、API再試行までは扱っていません。

6. 保存先を一つに決める

TODOの保存先が複数あると、どこを見れば最新状態が分かるのか曖昧になります。これはSSOT、つまり唯一の正しい管理元を決める問題です。

初心者が検証するならGoogle Sheets、議事録と一緒に管理するならNotion DB、開発案件ならGitHub Issuesが候補です。

最低限、次の項目を保存します。

task_hash は、会議ID、担当者、TODO本文、期限などから作る識別値です。同じ議事録を再処理しても、同一ハッシュがあれば新規登録を止められます。

ただし、TODO本文が一文字変わるだけで別のハッシュになる方式では、意味が同じタスクを重複登録する可能性があります。まずは完全一致で運用し、重複が多い場合にだけ、表記の正規化や類似度判定を追加してください。

7. 通知と再通知を自動化する

初回運用では、担当者へ直接通知せず、レビュー専用チャンネルへ送ります。誤抽出を把握する前に自動通知すると、不要なタスクが大量に届く可能性があるためです。

検証後は、次のように分岐できます。

needs_review = false
→ TODO DBへ登録
→ 担当者へ通知
→ 期限前日に再通知

needs_review = true
→ レビュー用チャンネルへ送信
→ 人間の承認後にTODO DBへ登録

完全無人に近づけるなら、担当者と期限が明確で、機密性や金銭リスクが低いTODOだけを自動登録します。高リスクな判断まで無人化すると、削減できた時間より事故対応の負担が大きくなる場合があります。

8. 定期実行と障害ログを設定する

Make、Zapier、GAS、Pythonなどを使い、新しい議事録が作成されたときに処理を開始します。

ログには次を残してください。

• 実行日時
• 対象となった議事録ID
• AIモデルまたは処理方式
• プロンプトのバージョン
• 入力文字数またはトークン数
• 抽出件数
• 自動登録件数
• 要確認件数
• 重複除外件数
• 登録・通知の成功件数
• API利用料
• 処理時間
• エラー内容

登録失敗を検知できない自動化は、気づかないうちにTODOを失います。エラー発生時は再試行し、一定回数失敗したら管理者へ通知する設計が必要です。

再試行では、同じTODOを二重登録しないようにしてください。API呼び出しがタイムアウトしても、登録先では処理が完了している場合があるためです。再送前に task_hash の存在を確認する設計が安全です。

専門家目線のチェックポイント

抽出率だけで精度を判断しない

確認する誤りは、少なくとも4種類あります。

大量に抽出できても、担当者と期限が間違っていれば運用価値は下がります。特に売上や顧客対応に近いTODOでは、誤抽出より抽出漏れの方が大きな損失につながるケースもあります。

検証用の正解表には、最低でも次の項目を用意します。

最初の10〜20件は、人間が全件確認してください。誤りの傾向が分かってから、自動登録の対象範囲を広げます。

AIの自己申告スコアを過信しない

AIに信頼度を数値で出させても、その数値が実測精度を直接示すとは限りません。次のような機械的ルールを併用します。

ownerが不明
期限が未設定
sourceが空
契約・請求・返金・発注を含む
外部送信を伴う
個人情報を含む

該当したTODOは、AIが高い信頼度を示していてもレビューへ回します。

プロンプトとモデルの変更履歴を残す

抽出結果が変化したとき、モデルの変更が原因なのか、プロンプトの修正が原因なのかを判別できなければ改善できません。

ログには、次のような識別情報を保存します。

{
  "model": "使用したモデル名",
  "prompt_version": "todo-extractor-v1.2",
  "schema_version": "task-schema-v1",
  "processed_at": "2026-07-16T10:30:00+09:00"
}

モデルやプロンプトを変更するときは、過去に人間が判定した同じ議事録で再テストします。テスト対象まで毎回変えると、改善したのか、会議内容が簡単だっただけなのか判断できません。

収益導線とTODOを接続する

「会議後の転記時間が減った」だけでは、自動化資産としての効果を評価しにくくなります。収益につながるTODOには、revenue_related: true のような分類を付ける方法があります。

対象例は、見積提出、販売ページ改善、広告停止、記事リライト、休眠顧客フォロー、ポイント申請期限の確認です。

ただし、分類されたTODOが完了しても、売上やポイント獲得が保証されるわけではありません。「収益関連TODOの完了」と「実際の売上発生」は分けて記録してください。

よくある失敗と対策

議事録の書式が毎回変わる

原因: 開催日、参加者、決定事項の位置が一定していない。

対策: 会議テンプレートを固定し、開催日と発言者名を必須にします。

AIが担当者を勝手に決める

原因: 「営業側で対応する」などの曖昧な表現を、AIが個人名へ置き換える。

対策: 参加者一覧にない担当者は自動登録せず、owner: "要確認" とします。

同じTODOが何度も登録される

原因: 議事録の更新や定期処理のたびに新規タスクを作る。

対策: 会議IDとTODOの内容からハッシュを作り、登録済みか確認します。

通知が増えて無視される

原因: 通常タスク、期限超過、要確認を同じ頻度で通知する。

対策: 高優先度は即時、通常TODOは日次、要確認はレビュー専用チャンネルへ分けます。

根拠となる発言を保存していない

原因: TODO本文だけをデータベースへ登録している。

対策: source、会議URL、発言者、タイムスタンプを保存します。誤抽出の修正や責任範囲の確認に利用できます。

AIの処理成功を登録成功とみなす

原因: JSONを生成できた時点で処理完了としている。

対策: AI抽出、JSON検査、データベース登録、通知を別々に記録します。各段階に成功・失敗・再試行回数を持たせてください。

成果を測るKPI

削減時間は、導入前後で同じ種類の会議を比較します。

例えば、「会議後の整理が1回15分、週4回、4週間」という仮定なら、導入前は月240分です。自動化後のレビューが1回3分なら月48分となり、差は月192分です。

時給換算額を3,000円と仮定すると、時間削減の評価額は次のようになります。

192分 ÷ 60分 × 3,000円 = 9,600円

月間のAI・連携ツール費と保守コストが合計4,000円なら、単純差額は5,600円です。ただし、これは条件を置いた試算であり、実績ではありません。APIエラー対応、初期構築、教育、誤登録の修正時間も含めて判断してください。

画像で説明すべき箇所

記事や社内マニュアルへ追加するなら、最も説得力があるのは、抽出前の議事録と抽出後のTODO一覧を横並びにした実画面のスクリーンショットです。

左側では根拠となる発言へ色を付け、右側では task、owner、due_date、source、needs_review を表示します。どの発言がどのTODOになったかを線で結ぶと、AIの判断を読者が追跡できます。

追加候補として、次の図も有効です。

• 議事録からAI、TODOデータベース、通知までのフロー図
• 誤抽出・抽出漏れ・期限ミスを表示するKPI画面
• JSON解析失敗や登録失敗が分かる実行ログ
• 要確認タスクだけを集めたレビュー画面
• プロンプト変更前後の精度比較表

生成画像は仕組みの説明には使えますが、運用実績の証拠にはなりません。公開可能な範囲で、実際のログや匿名化した管理画面を併用してください。

反論・限界・使えないケース

AIによるTODO自動抽出は、次のケースでは精度が安定しにくくなります。

• 発言者が記録されていない
• 冗談、皮肉、遠回しな依頼が多い
• 会議外で担当者や期限が変更される
• 議事録が短く、前後関係が分からない
• 法務、医療、金融、採用などの専門判断を含む
• 外部AIへ送信できない機密情報がある
• 責任者の決定に社内調整が必要である

機密情報を扱う場合は、利用するAIサービスのデータ保持条件、学習利用の有無、保存地域、アクセス権限、削除方法、社内規程を確認してください。必要に応じて、氏名や顧客情報の匿名化、送信項目の制限、ローカル環境で動くモデルを検討します。

録音や文字起こしを行う場合は、参加者への告知や同意、社内規程、適用される法令も確認が必要です。

また、「人間が一切関与しない完全自動化」は、低リスクで定型的な業務に限定する方が現実的です。例外処理や高額な取引まで無人化すると、誤作動時の損害が大きくなります。

導入前に使えるチェックリスト

次の項目を満たしてから、担当者への自動通知を有効にしてください。

• 対象とする会議を一種類に限定した
• 会議日、会議ID、参加者を記録している
• TODOの採用条件とレビュー条件を決めた
• AIが根拠となる原文を返す
• JSONをプログラム側で検査している
• 担当者を参加者一覧と照合している
• 相対期限を会議日基準で変換している
• task_hash で重複登録を防いでいる
• 登録失敗と通知失敗を別々に検知できる
• 機密情報の送信条件を確認した
• 人間が作った正解TODOと比較した
• 誤作動時に自動処理を停止できる

まとめ：今日やることを一つに絞る

AIで議事録からTODOを自動抽出する仕組みは、次の順番で作れます。

1. 直近の議事録を1本選ぶ
2. 人間が正解TODOを作る
3. JSONプロンプトでAIに抽出させる
4. 抽出漏れ、誤抽出、担当者ミス、期限ミスを数える
5. 根拠文と要確認フラグを付けて保存する
6. プログラム側で必須項目と重複を検査する
7. 精度を確認してから通知と定期実行をつなぐ
8. 収益関連TODOの完了数と人間の介在時間を記録する

読了後の最初のアクションは、直近の議事録を1本選び、記事内のプロンプトでJSONを出力することです。自動登録を始める前に、人間が作った正解表と比較してください。

議事録を「読み返す記録」から「次の行動を発生させる入力データ」へ変えると、会議後の作業を再利用可能な自動化資産にできます。収益に近い行動を分類し、通知、期限管理、KPIまで接続すれば、人間が毎回転記しなくても改善活動が進む状態へ近づけます。

本気で自動化・収益基盤を構築したい方向けの実践マニュアル

議事録からTODOを抽出できても、それだけでは収益を生む仕組みは完成しません。

次に必要なのは、どのTODOを売上・成約・ポイント獲得へつなげるかを決め、実行、通知、販売、効果測定まで一貫して回す設計図です。

毎日の転記や確認に時間を使い続けるのか。それとも、一度作った仕組みを改善しながら、自動化資産として育てるのか。その差は、導入したツールの数ではなく、入力から実行、検証、収益導線まで接続できるかで生まれます。

商品一覧では、AI、ブログ、SaaSアフィリエイト、VPS、決済、集客などを組み合わせ、継続的に動く仕組みを構築するための実践マニュアルを紹介しています。

手作業を減らし、継続的な収益につながる自動化資産を作りたい方は、次のページから目的に合う設計図を選んでください。

成果や収益は、実行量、市場環境、運用方法によって異なります。「不労所得」や利益を保証するものではありません。

本気で自動化・収益基盤を構築したい方向けの実践マニュアルを見る