AIで議事録からTODOを自動抽出・登録する方法｜誤登録を防ぎ、通知・実行までつなぐ8ステップ

「会議では決まったのに、誰も対応していない」「議事録からTODOを転記する作業に、毎週時間を取られている」と悩んでいないでしょうか。

議事録を保存しただけでは、仕事は動きません。作業内容、担当者、期限を抽出し、タスク管理ツールへ登録して、完了まで追跡して初めて実務につながります。

この間を人間が処理していると、転記漏れ、担当者の誤認、期限の見落としが発生します。

AIを使えば、次の流れを自動化できます。

1. 議事録からTODO候補を抽出する
2. 担当者・期限・根拠発言を整理する
3. 曖昧な内容や危険な処理を除外する
4. 確定したTODOをNotionなどへ登録する
5. 担当者へ通知し、期限を監視する
6. 許可された安全な業務だけを自動実行する
7. 完了結果とエラーを記録する
8. KPIを測定して抽出精度を改善する

この記事では、初心者が1件の議事録で試せる小規模な構成から、通常処理には人間が介在しない「例外対応型」の運用までを順番に解説します。

目指すのは、単なる議事録要約ツールではありません。会議で決まった集客施策、商品改善、記事制作、顧客フォローなどを確実に実行し、過去の会議を継続的に働く自動化資産へ変える仕組みです。

ただし、自動化が収益を直接保証するわけではありません。収益につながる施策の実行漏れを減らし、人間の作業時間を圧縮するための実務設計として読み進めてください。

実行環境で確認した一次情報

Hiroが運用するauto-ai-blogでは、トピック選択、AIによる記事生成、レビュー、最終検査、Markdown保存、Notion登録、Gitへの反映を一連の処理として扱っています。

2026年7月22日に、各サイトの投稿フォルダにあるMarkdownファイルをPowerShellで再集計しました。

$sites = 'ai-tech', 'business', 'real-estate'

foreach ($site in $sites) {
    $path = "sites/$site/content/posts"
    $count = (Get-ChildItem -LiteralPath $path -File -Filter '*.md').Count
    [PSCustomObject]@{
        Site  = $site
        Count = $count
    }
}

実測結果は次のとおりです。

この899本はローカルに保存されていたMarkdownファイルの数です。全記事が公開済み、検索流入獲得済み、または収益化済みという意味ではありません。

一方で、生成物を一定の形式にそろえ、検査して保存する工程を繰り返せることは確認できます。

同日、AIスロップ防止機能に関するテストも実行しました。

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

実行結果は、対象3件すべて成功でした。

...                                                                      [100%]

この結果が示すのは、指定された品質検査コードが現在の環境でテストを通過したことです。議事録からのTODO抽出精度や、売上への効果を証明する結果ではありません。

このブログ運用と同様に、議事録のTODO自動抽出でも、抽出・検査・登録・実行を別工程に分ける設計が重要です。

なお、記事内の2点の画像は仕組みを説明するための概念図であり、実際の管理画面を撮影したスクリーンショットではありません。一次情報として利用できるのは、上記のパス、再現コマンド、実測件数、テスト結果です。

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

処理の全体像は次のとおりです。

録音・会議メモ
      ↓
文字起こし・議事録
      ↓
AIがTODO候補を構造化
      ↓
形式・重複・危険度を検査
      ↓
安全なTODOを登録
      ↓
担当者への通知・期限監視
      ↓
許可された業務だけを自動実行
      ↓
成果物・エラー・KPIを記録

重要なのは、AIに読みやすい要約文を書かせるのではなく、後続のプログラムが処理できる構造化データを作らせることです。

例えば「田中さんが金曜までに販売ページを直す」という発言を、次のJSONへ変換します。

{
  "task": "販売ページのCTAを修正する",
  "owner": "田中",
  "due_date": "2026-07-24",
  "evidence": "田中さんが金曜までに販売ページを直す",
  "revenue_related": true,
  "risk_level": "low",
  "needs_review": false,
  "review_reason": null
}

各項目には次の役割があります。

JSONとして解析できることと、内容が正しいことは別問題です。形式検査と意味の検査を分けて設計します。

AIで議事録からTODOを自動抽出する8ステップ

1．対象にする会議を1種類に絞る

最初からすべての会議を対象にすると、用語、議事録の形式、TODOの判断基準がばらつきます。

まずは、担当者と期限を比較的明確に決める会議を一つ選びます。

• 編集会議から記事修正TODOを抽出する
• 商品会議から販売ページの改善TODOを抽出する
• 集客会議からSEO・広告施策を抽出する
• 外注定例から納品・確認作業を抽出する
• 営業会議から資料作成や連絡業務を抽出する

契約、採用、返金、送金、データ削除を扱う会議は、誤処理した場合の損失が大きいため、初期検証には向きません。

2．議事録の入力形式を固定する

文字起こしデータには、最低限のメタデータを付けます。

会議ID: marketing-20260722-01
開催日時: 2026-07-22 10:00
タイムゾーン: Asia/Tokyo
参加者: 田中、佐藤、鈴木

## 決定事項

## 会話記録

## 保留事項

## 撤回・変更事項

会議日時が必要なのは、「来週月曜」「今月末」といった相対期限を日付へ変換するためです。

処理日を基準にすると、過去の議事録を再実行した際に期限が変わってしまいます。必ず会議の開催日時を基準にします。

会議IDは重複登録の防止に使います。同じ議事録が再送されても、同一の会議IDとTODO識別子があれば登録を停止できます。

3．人間が正解データを作る

AIを評価するには、比較対象となる正解TODOが必要です。

最初は同じ種類の会議からサンプルを選び、人間が次の項目を記録します。

サンプル数に万能な正解はありません。例えば過去10会議を使う場合は、「同じ種類の会議10件を初期比較に使用した」という前提を評価ログへ残します。

少数のサンプルで高い精度が出ても、別の会議で同じ結果になるとは限りません。件数を根拠なく精度保証へ結び付けないようにしてください。

AIと人間の判定が食い違った箇所は削除せず、次のように分類します。

• TODOの抽出漏れ
• 雑談や提案の誤抽出
• 担当者の誤認
• 期限の誤変換
• 撤回済みTODOの抽出
• 複数タスクの誤結合
• 一つのタスクの過剰分割

この差分が、プロンプトと検査ルールを改善するための一次データになります。

4．抽出プロンプトを作る

次のテンプレートを、自社の議事録に合わせて調整します。

以下の議事録から、実行可能なTODO候補を抽出してください。

ルール:
- 感想、雑談、未確定の提案は確定TODOにしない
- 担当者や期限を推測で補わない
- 相対期限は会議日時を基準に日付へ変換する
- 一意に判断できない項目はnullにする
- 根拠発言をevidenceへ原文のまま保存する
- 後から撤回または変更された決定は除外する
- 契約、送金、削除、公開、対外送信を含む場合はneeds_reviewをtrueにする
- 議事録に存在しない事実を追加しない
- JSON配列のみを返す

出力項目:
task, owner, due_date, evidence, revenue_related,
risk_level, needs_review, review_reason

会議日時:
{{meeting_datetime}}

タイムゾーン:
{{timezone}}

参加者:
{{participants}}

議事録:
{{meeting_minutes}}

例えば「価格表も見直した方がよさそう」という発言は、確定したTODOとは限りません。

担当者や期限が決まっていない場合は推測で補わず、nullを入れて確認キューへ送ります。

{
  "task": "価格表の見直しを検討する",
  "owner": null,
  "due_date": null,
  "evidence": "価格表も見直した方がよさそう",
  "revenue_related": true,
  "risk_level": "medium",
  "needs_review": true,
  "review_reason": "担当者と期限が確定していない"
}

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

AIがJSONを返しても、そのまま登録してはいけません。

登録前に、少なくとも次の判定を行います。

最小限の判定は、次のようなコードで表現できます。

HIGH_RISK_WORDS = {
    "契約",
    "送金",
    "返金",
    "削除",
    "公開",
    "顧客へ送信",
}


def validate_task(task, participants, meeting_text):
    errors = []

    if not task.get("task"):
        errors.append("task_missing")

    evidence = task.get("evidence")
    if not evidence:
        errors.append("evidence_missing")
    elif evidence not in meeting_text:
        errors.append("evidence_not_found")

    owner = task.get("owner")
    if owner is None:
        errors.append("owner_missing")
    elif owner not in participants:
        errors.append("unknown_owner")

    if task.get("due_date") is None:
        errors.append("due_date_missing")

    if any(word in task.get("task", "") for word in HIGH_RISK_WORDS):
        errors.append("high_risk_action")

    return {
        "valid": len(errors) == 0,
        "needs_review": len(errors) > 0,
        "errors": errors,
    }

これは概念を示す最小例です。本番環境では、日付形式、タイムゾーン、文字コード、入力サイズ、API失敗、再試行回数も検査してください。

6．重複を防いでタスク管理ツールへ登録する

同じ議事録を再処理したときにTODOが増殖しないよう、タスクごとの識別子を作ります。

例えば、次の3項目を結合します。

marketing-20260722-01|販売ページのctaを修正する|田中

Pythonでは、次のようにハッシュ化できます。

import hashlib
import re
import unicodedata


def normalize_task_name(value):
    value = unicodedata.normalize("NFKC", value)
    value = value.lower().strip()
    return re.sub(r"\s+", "", value)


def create_task_hash(meeting_id, task_name, owner):
    source = "|".join(
        [
            meeting_id,
            normalize_task_name(task_name),
            owner or "",
        ]
    )
    return hashlib.sha256(source.encode("utf-8")).hexdigest()

データベース側でもtask_hashへ一意制約を付けます。アプリケーション側の確認だけでは、同時実行時に二重登録される可能性があるためです。

ただし、「LPのボタンを直す」と「販売ページのCTAを修正する」のような意味上の同一タスクは、文字列ハッシュだけでは検出できません。

そのため、次の2段階で重複を判定します。

1. 完全一致するハッシュは自動的に拒否する
2. 意味が似ている候補は確認キューへ送る

登録項目の例は次のとおりです。

• meeting_id
• source_url
• task
• owner
• due_date
• evidence
• status
• risk_level
• needs_review
• task_hash
• prompt_version
• created_at
• completed_at
• result_url
• error_code

保存先は、Notion、Google Sheets、Trello、Backlogなどから一つ選びます。

複数のツールを正本にすると、どこを確認すべきか分からなくなります。タスクの正本となる保存先を一つ決め、他のツールは通知先または閲覧用に限定する設計が現実的です。

7．通知と期限監視を接続する

登録後は、次のイベントを自動化します。

• 新規登録時に担当者へ通知する
• 期限前にリマインドする
• 期限超過時に再通知する
• 担当者不明のTODOを確認キューへ送る
• 登録失敗や連携失敗を管理者へ通知する
• 完了時に成果物URLを記録する

通知には、少なくとも次の情報を含めます。

作業: 販売ページのCTAを修正する
担当者: 田中
期限: 2026-07-24
根拠: 田中さんが金曜までに販売ページを直す
元議事録: https://example.com/meetings/marketing-20260722-01

根拠を確認できる状態なら、担当者がAIの誤解に気づきやすくなります。

通常処理を無人化しても、異常時の通知先は必要です。人間がすべてを事前確認する運用ではなく、失敗や曖昧さが発生した場合だけ介入する形へ移行します。

8．収益につながる後続業務を自動化する

TODO登録は入口です。収益に近く、かつ誤処理しても復旧できる業務へ接続すると、自動化資産としての価値が高まります。

例えば「既存記事のCTAを改善する」というTODOなら、次の流れを構築できます。

1. 対象記事を検索する
2. 現在のCTAとリンク先を取得する
3. AIが修正案を作成する
4. 禁止表現、リンク切れ、文字数を検査する
5. 変更前後の差分を保存する
6. テスト環境へ反映する
7. 品質ゲート通過後に公開する
8. クリック数や商品ページへの遷移数を記録する
9. 一定期間後に変更前後の数値を比較する

公開まで自動化する場合でも、次の条件を満たさない変更は停止させます。

• 対象記事を一意に特定できない
• 変更差分が設定した上限を超える
• リンク先が応答しない
• 法務・医療・金融など高リスクな表現を含む
• 検査コードが失敗する
• 公開後の確認処理を実行できない

収益額は、アクセス数、商品、価格、導線、成約率などに左右されます。「AIでTODOを抽出すれば利益が出る」とは断定できません。

測定すべきなのは自動化した件数ではなく、完了した施策が生んだ業務成果です。

本番運用前に決める承認境界

すべてのTODOを同じ権限で処理してはいけません。

権限も次の3層に分離します。

• 抽出AI：TODO候補を作る
• 検査プログラム：形式、根拠、重複、危険度を判定する
• 実行プログラム：許可された処理だけを実行する

TODO候補を作るAIへ、公開、送信、削除などの権限を直接渡さないでください。一度の誤解が、そのまま外部操作につながるためです。

実行ログに残す項目

障害の原因を追跡できるよう、処理単位のログを残します。

{
  "run_id": "run-20260722-001",
  "meeting_id": "marketing-20260722-01",
  "prompt_version": "todo-extractor-v3",
  "started_at": "2026-07-22T10:30:00+09:00",
  "candidate_count": 5,
  "accepted_count": 3,
  "review_count": 1,
  "rejected_count": 1,
  "duplicate_count": 0,
  "registered_count": 3,
  "status": "completed",
  "error_code": null
}

最低限、次の項目を同じrun_idへひも付けます。

• 入力した会議ID
• 使用したモデル
• プロンプトのバージョン
• 抽出件数
• 除外件数
• 確認キュー件数
• 重複件数
• 登録成功件数
• エラーコード
• 開始時刻と終了時刻

議事録原文に個人情報が含まれる場合は、ログへ全文を複製せず、アクセス制御された原本への参照を保存します。

よくある失敗と対策

要約文をそのままTODOとして登録する

原因： 読みやすい文章と、実行可能なタスクを区別していない。
対策： 作業、担当者、期限、根拠を固定項目で出力させます。

AIが担当者や期限を補完する

原因： 空欄を禁止したプロンプトになっている。
対策： 不明な場合はnullを許可し、確認キューへ分岐させます。

再実行でTODOが増殖する

原因： 会議ID、一意識別子、データベースの一意制約がない。
対策： task_hashを保存し、同じ入力を複数回処理しても結果が重複しない冪等性を持たせます。

表記が違う同一タスクを検出できない

原因： 完全一致する文字列だけで重複を判定している。
対策： 完全一致は自動拒否し、意味が似ている候補は確認キューへ送ります。

タスク管理ツールが複数になる

原因： 部門ごとにNotion、スプレッドシート、Google Tasksなどへ登録している。
対策： 正本を一つ決め、他のツールにはリンクまたは通知だけを送ります。

TODOは増えるが完了しない

原因： 抽出件数を成果として扱っている。
対策： 完了率、期限超過率、成果物URL、収益関連施策の実行結果まで追跡します。

API障害で同じ処理を何度も実行する

原因： 再試行回数と停止条件が決まっていない。
対策： 指数バックオフ、最大試行回数、冪等キー、失敗キューを設定します。

成果を測るKPI

初期運用では、根拠のない目標値を設定するより、同じ種類の会議を一定期間測定して基準値を作ります。

その後、プロンプトや入力形式を一つずつ変更し、変更前後の結果を同じ正解データで比較してください。モデル、プロンプト、入力形式を同時に変えると、何が改善に寄与したのか分からなくなります。

無人運用へ移行する判断基準

いきなり完全自動化へ進まず、次の段階を踏みます。

段階1：抽出だけを試す

AIの出力を保存しますが、タスク管理ツールには登録しません。人間の正解データと比較します。

段階2：下書き状態で登録する

登録は自動化しますが、担当者への通知や後続処理は実行しません。

段階3：低リスク処理だけを自動実行する

社内タスク登録、下書き作成、集計など、取り消し可能な処理へ限定します。

段階4：例外対応型へ移行する

通常処理は自動化し、次の条件に該当した場合だけ人間へ通知します。

• 担当者または期限が不明
• 根拠発言を確認できない
• 高リスク語を含む
• 登録件数が通常範囲を超える
• 外部APIが連続して失敗する
• 重複率や要確認率が急上昇する

本番移行の基準は、業務の損失許容度に合わせて決めます。単に「精度が高そう」という印象だけで移行してはいけません。

限界・使えないケース・注意点

次のような状況では、AIが正確にTODOを判断できない場合があります。

• 音声が不鮮明
• 話者を識別できない
• 皮肉や暗黙の了解が多い
• 複数人が同時に話している
• 会議中に決定が何度も変更される
• 会議後にチャットや口頭で方針が変わる
• 担当者や期限を明示しない組織文化になっている

また、議事録には顧客情報、人事情報、契約情報が含まれる可能性があります。

利用するAIサービスについて、次の項目を確認してください。

• 入力データの保持期間
• モデル学習への利用有無
• 保存地域
• 通信と保存時の暗号化
• 管理者権限
• アクセスログ
• データ削除方法
• 外部委託先への提供範囲

必要に応じて、個人名、メールアドレス、電話番号、契約金額などを匿名化します。

無人運用には停止条件も必要です。連続エラー、登録件数の急増、担当者不明率の上昇などを検知したら、自動処理を止めて管理者へ通知してください。

今日から始める具体的アクション

まずは直近の会議を一つ選び、次のチェックリストを実行してください。

• 会議ID、開催日時、タイムゾーン、参加者を議事録へ追加する
• 人間が正解TODOを作る
• AIにJSON形式でTODO候補を抽出させる
• 担当者、期限、根拠発言を照合する
• 曖昧な候補を自動登録から除外する
• task_hashを生成して重複を防ぐ
• 一つの保存先へ下書き状態で登録する
• 抽出結果と人間の修正内容をログへ残す
• 再度同じ議事録を処理し、重複登録されないことを確認する
• 問題がなければ担当者へのテスト通知を接続する

この1回分のログが、自動化を進めるための基準データになります。

精度が安定した通常処理から、登録、通知、下書き作成へ接続し、例外だけを人間へ戻してください。

会議で決まった施策が確実に実行され、記事、商品ページ、見込み客フォロー、運用データとして蓄積されれば、毎回ゼロから作業する時間を減らせます。

収益を保証する仕組みではありませんが、議事録を保存するだけの状態から、意思決定を継続的に実行する自動化資産へ変えることは可能です。

本気で業務と収益導線を自動化したい方へ

「AIでTODOを抽出できた」で止まると、便利な業務改善に終わります。

収益につながる自動化資産を作るには、集客、商品、決済、コンテンツ制作、品質検査、公開、効果測定までを一つの仕組みとして接続する設計図が必要です。

「どの作業から自動化すべきか分からない」「エラーで止まり続けない運用を作りたい」「自分が動いていない時間にも改善が積み上がる導線を持ちたい」という方は、実装手順を体系化した実践マニュアルを確認してください。

次の会議へ参加している間にも、前の会議で決まった施策が安全に進み続ける。その状態を作るための最初の一歩は、1件の議事録を構造化して測定することです。

本気で自動化・不労所得を構築したい方向けの実践マニュアルを見る