AIで議事録からTODOを自動抽出・登録する方法｜担当者・期限の判定と誤登録を防ぐ実務設計

「田中さんが金曜までに修正する」「見積書は佐藤さんが送る」――会議中に決まったはずの仕事が、次の会議まで放置されていないでしょうか。

原因の一つは、議事録を作成しても、そこからTODOを拾い、担当者と期限を確認し、タスク管理ツールへ登録する工程が人手のままだからです。

この工程は、AIを使えば次のように自動化できます。

1. 議事録からTODO候補を抽出する
2. 担当者・期限・根拠発言を構造化する
3. 曖昧な候補を人間の確認キューへ分ける
4. 確定したTODOだけをGoogle SheetsやNotionへ登録する
5. 担当者への通知、期限監視、完了結果の記録までつなぐ

重要なのは、AIに「それらしいTODO」を書かせることではありません。誤抽出、二重登録、期限の誤変換、危険な自動実行を防ぐ仕組みまで含めて設計することです。

本記事では、初心者が1件の議事録から検証を始め、最終的に例外対応型の自動運用へ移行する手順を解説します。

Hiroの運用環境で確認した一次情報

本記事の公開前に、Hiroが運用する auto-ai-blog のローカル環境を2026年7月21日に確認しました。

実際の保存先である各サイトの sites/<site>/content/posts 直下について、Markdownファイルを集計した結果は次のとおりです。

これはファイル数の実測値です。840本すべてが公開済み、検索流入獲得済み、収益化済みという意味ではありません。

同日の機械ログ generator/.budget_ledger.json には、次の値が記録されていました。

{
  "today": "2026-07-21",
  "articles_today": 17,
  "images_today": 0,
  "articles_this_week": 17,
  "images_this_week": 0
}

さらに、AI生成記事の品質基準を検査する次のテストを実行しました。

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

結果は、対象となる3件のテストがすべて成功しました。

...                                                                      [100%]

この運用では、記事生成を文章作成だけで終わらせず、入力、生成、形式検査、保存、公開、ログ記録を一つのパイプラインとして扱っています。

議事録からのTODO抽出にも、同じ設計思想を転用できます。

ただし、この実行ログが証明しているのは、ブログ運用環境と品質検査が実在することです。TODO抽出の正解率や売上への効果を証明するものではありません。抽出精度は、自社の議事録を使って別途測定する必要があります。

AIで議事録からTODOを自動抽出する全体像

基本的な処理フローは次のとおりです。

録音・会議メモ
       ↓
文字起こし・議事録保存
       ↓
AIがTODO候補をJSONで抽出
       ↓
プログラムが形式・危険度・重複を検査
       ↓
安全なTODOをタスク管理ツールへ登録
       ↓
曖昧なTODOを人間の確認キューへ送る
       ↓
担当者への通知・期限監視
       ↓
完了状況と業務成果を記録

AIには読みやすい要約ではなく、後続処理で扱える構造化データを作らせます。

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

この形式なら、プログラムが担当者や期限を読み取り、Google Sheets、Notion、Slackなどへ渡せます。

ただし、JSONで出力されたことと、内容が正しいことは別問題です。形式検査と意味の確認を分けて考える必要があります。

導入前に決める3つのルール

TODOとして採用する条件

自動登録するTODOは、原則として次の条件をすべて満たすものに限定します。

• 実行する作業を動詞で表現できる
• 担当者が明示されている
• 期限を具体的な日付に変換できる
• 根拠となった発言を保存できる
• 外部への確定回答、送金、契約、削除を伴わない

「価格表も見直した方がよさそう」のような提案は、確定したTODOとは限りません。AIに無理に確定させず、確認対象として扱います。

人間の確認が必要な条件

次のいずれかに該当する場合は、needs_review: true にします。

• 担当者または期限が不明
• 発言者と担当者の関係が曖昧
• 複数の解釈ができる
• 金額、契約、発注、返金を含む
• 顧客への正式回答を伴う
• 個人情報や機密情報を含む
• 議事録内で後から撤回されている
• 他の決定事項と矛盾している

自動実行してよい処理

最初は、失敗しても取り消しやすい処理だけを対象にします。

ステップ1：対象にする会議を1種類に絞る

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

まずは1種類を選んでください。

• 編集会議から記事修正TODOを抽出する
• 商談議事録から見積・資料送付TODOを抽出する
• 商品改善会議から販売ページの修正TODOを抽出する
• 外注定例から納品確認TODOを抽出する
• 集客会議から広告・SEO施策のTODOを抽出する

初期検証には、週次で繰り返され、担当者と期限を比較的明確に決めている会議が向いています。

法務判断、採用決定、返金、契約承認など、誤登録の影響が大きい会議から始めるのは避けましょう。

ステップ2：議事録の入力形式を固定する

AIの抽出精度は、入力される議事録の品質に左右されます。

最低限、次の項目を固定してください。

# 会議名

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

## 決定事項

## 会話メモ

## 保留事項

## 撤回・変更事項

会議日とタイムゾーンが必要な理由

「金曜まで」「来週水曜」「月末」といった表現を日付へ変換するには、基準となる会議日が必要です。

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

「今週」「来週」などの解釈は組織や話者によって異なる場合があるため、一意に変換できなければ null として確認キューへ送ります。

会議IDが必要な理由

APIの再試行や手動での再実行が発生すると、同じTODOが二重登録される可能性があります。

会議ごとに一意なIDを付け、後述する task_hash と組み合わせて重複を防止します。

ステップ3：人間が正解TODOを作る

AIを使う前に、人間が同じ議事録を読んで正解TODOを作ります。

最低でも10件、できれば同じ種類の会議を20〜30件用意し、次の項目を記録してください。

この正解データがなければ、「AIがうまく抽出できた気がする」という主観評価しかできません。

議事録の一部をプロンプト調整用に使い、別の議事録を最終評価用に残してください。同じデータで調整と評価を行うと、特定の例だけに最適化され、実運用時の精度を過大評価するおそれがあります。

正解データを複数人で作る場合は、担当者や期限の判定が一致しなかった箇所も記録します。人間同士でも判断が分かれるTODOを、AIだけに確定させるべきではないからです。

ステップ4：AIへ渡すプロンプトを作る

次のテンプレートを、自社の会議形式に合わせて調整してください。

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

前提:
- 会議日時は {{meeting_datetime}} です
- タイムゾーンは {{timezone}} です
- 参加者は {{participants}} です
- 相対期限は会議日を基準にYYYY-MM-DDへ変換してください
- 期限を一意に変換できない場合はnullにしてください

抽出条件:
- 具体的な作業が発生する発言だけを対象にする
- 感想、雑談、未確定の提案は自動登録対象にしない
- 担当者や期限を推測で補わない
- 根拠となる原文をevidenceへ保存する
- 議事録の後半で撤回された決定は除外する
- 類似するTODOは1件に統合する
- 売上、集客、顧客対応、商品改善に直接関係する場合だけ
  revenue_relatedをtrueにする

確認条件:
- 担当者または期限が不明な場合
- 発言の解釈が複数ある場合
- 金額、契約、発注、返金、削除、対外回答を含む場合
上記ではneeds_reviewをtrueにし、理由をreview_reasonへ記録する

出力条件:
- JSON配列のみを出力する
- Markdownや説明文を付けない
- priorityはhigh、medium、lowのいずれか
- ownerは参加者名またはnull
- due_dateはYYYY-MM-DDまたはnull
- 根拠のない情報を追加しない

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

議事録:
{{meeting_minutes}}

例えば、会議日が2026年7月21日で、次の発言があったとします。

田中: 金曜までに商品ページのCTAを修正します。
佐藤: 価格表も見直した方がよさそうですね。

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

[
  {
    "task": "商品ページのCTAを修正する",
    "owner": "田中",
    "due_date": "2026-07-24",
    "priority": "high",
    "revenue_related": true,
    "evidence": "金曜までに商品ページのCTAを修正します",
    "needs_review": false,
    "review_reason": ""
  },
  {
    "task": "価格表の見直し要否を確認する",
    "owner": null,
    "due_date": null,
    "priority": "medium",
    "revenue_related": true,
    "evidence": "価格表も見直した方がよさそうですね",
    "needs_review": true,
    "review_reason": "実施の決定、担当者、期限が明示されていない"
  }
]

2件目は確定TODOではなく、確認候補です。自動登録用と確認用を同じ一覧に混在させず、登録前の処理で明確に分岐させます。

ステップ5：AIの出力をプログラムで検査する

AIの返答を、そのままタスク管理ツールへ登録してはいけません。

最低限、次の検査を入れます。

JSONとして解析できない        → 処理を停止して再試行キューへ送る
taskが空                      → 登録しない
evidenceが空                  → 確認キューへ送る
ownerが参加者一覧にない       → 確認キューへ送る
期限の形式がYYYY-MM-DDでない  → 確認キューへ送る
期限が会議日より前            → 確認キューへ送る
priorityが許可値以外          → 確認キューへ送る
危険操作を含む                → 自動実行を停止する
既存のtask_hashと一致         → 重複登録しない

priority を勝手に medium へ補正すると、元の異常を見逃す可能性があります。初期運用では、補正するより確認キューへ送る方が安全です。

重複防止用のtask_hash

例えば、次の文字列を正規化してハッシュ化します。

sales-20260721-01|商品ページのctaを修正する|田中

重複判定に使う項目は、次の3つが基本です。

• 会議ID
• 正規化した作業内容
• 担当者

正規化では、前後の空白、全角・半角、英字の大文字・小文字、連続する空白などを統一します。正規化ルールを後から変えるとハッシュ値も変わるため、ルールのバージョンも保存しておくと安全です。

ただし、表現が少し異なるだけで別ハッシュになるため、ハッシュだけで意味的な重複を完全には防げません。類似タスクの統合は、確認画面でも行えるようにしてください。

ステップ6：Google Sheetsへ登録する

初心者には、まずGoogle Sheetsへ登録する構成が扱いやすいでしょう。議事録の原文、AIの抽出結果、人間の修正内容を横並びで確認できるためです。

推奨列は次のとおりです。

登録時は、同じ task_hash が存在しないことを確認してから行を追加します。

複数の処理が同時に走る可能性がある場合は、「確認してから追加する」だけでは不十分です。確認と追加の間に別の処理が同じ行を登録する競合が起こり得るため、データベースの一意制約やロックなど、登録先に応じた排他制御を検討してください。

運用が安定したら、Notion、Trello、Backlog、Jiraなどへ移行できます。最初から複数ツールへ接続すると、抽出エラーと連携エラーを切り分けにくくなるため、一つずつ追加してください。

ステップ7：通知と期限監視をつなぐ

タスクを登録しても、担当者が気づかなければ実行されません。

最低限、次の通知を設けます。

• 登録時に担当者へ通知する
• 期限の1営業日前にリマインドする
• 期限超過時に担当者と管理者へ通知する
• 担当者不明のTODOを確認用チャンネルへ送る
• 登録失敗や通知失敗を運用担当者へ知らせる

通知には、作業名だけでなく次の情報を含めます。

タスク: 商品ページのCTAを修正する
担当者: 田中
期限: 2026-07-24
根拠: 「金曜までに商品ページのCTAを修正します」
議事録: https://example.com/minutes/...

完全無人化を目指す場合でも、エラーの監視先は必要です。目標は人間を完全に排除することではなく、正常処理には介入せず、異常時だけ確認する運用です。

ステップ8：安全な後続処理だけを自動化する

TODO登録が安定したら、その先の処理を段階的に接続します。

例えば「過去記事のCTAを修正する」というTODOなら、次の流れが考えられます。

1. 対象記事を識別する
2. 現在のCTAとリンク先を取得する
3. AIが修正案を作成する
4. 禁止語、リンク切れ、文字数を検査する
5. 変更前後の差分を保存する
6. 下書きとして保存する
7. テスト成功後に公開キューへ送る
8. 公開後のクリック率を記録する

送信、公開、削除のように外部へ影響する処理には、次の安全策を設けます。

• 初期段階では下書きまでに制限する
• 実行前に差分を表示する
• 承認者を記録する
• 実行結果とエラーを保存する
• 元の状態へ戻せる手順を用意する
• 同じ処理を安全に再実行できるようにする
• 一定件数の失敗が発生したら自動停止する

議事録TODO抽出の専門家チェックポイント

根拠発言と議事録へのリンクを保存する

AIが作ったTODOだけでは、誤抽出の原因を追跡できません。

evidence には必要最小限の原文を保存し、source_url から元の議事録を確認できるようにします。

文字起こしデータに時刻情報がある場合は、発言時刻や発言IDも保存すると、長い議事録から根拠箇所を探す時間を短縮できます。

担当者と期限を推測させない

「誰か確認してください」「なるべく早く」といった発言では、担当者や期限が確定していません。

AIが勝手に補完すると、一見正常に見える誤タスクが蓄積します。不明な項目は null として返し、人間に確認させてください。

抽出・検査・実行の権限を分ける

処理を次の3層に分離します。

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

抽出AIには、送金、契約、削除、外部送信の権限を与えません。モデルやプロンプトを変更しても、実行側の安全ルールが維持される構成にします。

プロンプトとモデルのバージョンを記録する

同じ議事録でも、プロンプトやモデルの変更により出力が変わる可能性があります。

各処理について、次の情報をログへ残します。

• 処理日時
• 会議ID
• 使用モデル
• プロンプトのバージョン
• 抽出結果
• 検査結果
• 人間による修正内容
• 登録先のID
• 実行結果

精度が低下したときに、どの変更が原因だったかを追えるようになります。

機密情報の扱いを先に決める

議事録には、顧客名、価格、契約条件、個人情報が含まれる場合があります。

利用するAIサービスについて、データ保持期間、学習利用の有無、保存地域、アクセス権限、削除方法、社内規程との適合を確認してください。必要に応じて、氏名や企業名を匿名化してから送信します。

匿名化する場合は、同じ人物を毎回同じ仮名へ変換できる仕組みも必要です。会議ごとに仮名が変わると、担当者の照合や履歴追跡が難しくなります。

画像で説明すべき箇所

実運用の記事に追加するなら、次の3画面を並べたスクリーンショットが有効です。

1. 議事録の原文
2. AIが返したJSON
3. Google SheetsやNotionへ登録されたTODO

赤枠で根拠発言、青枠で担当者、緑枠で期限を対応させると、文章がどのように構造化されたかを確認できます。

生成画像だけでなく、個人情報をマスキングした実画面、プロンプトのバージョン、実行日時、成功・失敗が分かるログを掲載すると、独自性と検証可能性が高まります。

よくある失敗と改善方法

失敗1：要約とTODO抽出を同時に頼む

読みやすい要約は出ても、登録可能なJSONにならないことがあります。

改善方法： 要約とTODO抽出を別処理にし、抽出処理にはJSON以外を返さないよう指定します。

失敗2：提案を確定TODOとして登録する

「検討したい」「見直した方がよい」が、大量の未完了タスクになります。

改善方法： 決定、担当者、期限、根拠という採用条件を設け、不足があれば確認キューへ送ります。

失敗3：後半で撤回された決定を抽出する

会議の前半だけを見るとTODOに見えても、後半で方針が変わっている場合があります。

改善方法： 議事録全体を対象にし、撤回・変更事項を確認するようプロンプトへ明記します。

失敗4：同じ議事録から二重登録する

APIの再試行や手動再実行で、同じTODOが増えることがあります。

改善方法： 会議IDと task_hash を保存し、登録前に照合します。同時実行がある場合は、一意制約やロックも使います。

失敗5：AIの抽出精度だけを追う

抽出が正しくても、登録、通知、実行のどこかで止まれば業務成果にはつながりません。

改善方法： 抽出精度に加え、登録成功率、通知成功率、期限内完了率を測定します。

失敗6：自動化と無審査を混同する

対外メール、契約、送金まで無条件で実行すると、誤作動時の影響が大きくなります。

改善方法： 取り消し可能な社内処理から自動化し、外部影響の大きい操作には承認を残します。

失敗7：エラー時に同じ処理を無制限に再試行する

登録先の障害や認証切れが原因の場合、再試行を続けると重複登録やAPI制限を招きます。

改善方法： 再試行回数に上限を設け、失敗理由、入力、会議IDを保存して異常通知を送ります。

失敗8：プロンプト変更後に過去データで再評価しない

文章上は小さな変更でも、担当者や期限の判定が変わる場合があります。

改善方法： プロンプトやモデルを変更するたびに、固定した評価用議事録で回帰テストを実施します。以前より悪化した場合は、本番へ反映しません。

成果を測るKPI

導入前後を比較する前に、まず正解データを使って抽出性能を測ります。

再現率と適合率は、一方だけを見てはいけません。すべてをTODOとして抽出すれば再現率は上がりますが、不要抽出も増えます。反対に、確実なものだけを抽出すれば適合率は上がりますが、抽出漏れが増える可能性があります。

初期導入の判定基準は、業務リスクに合わせて決めます。例として、次のようなゲートを設定できます。

TODO再現率が90%未満         → プロンプトまたは議事録形式を改善
TODO適合率が90%未満         → 採用条件を厳格化
期限正解率が95%未満         → 期限を自動確定しない
登録成功率が99%未満         → 自動実行範囲を拡大しない
危険操作の誤実行が1件以上   → 即時停止して原因調査

これらは万能な基準ではありません。契約や顧客対応では、さらに厳しい基準が必要です。また、評価件数が少なければ、数件の成否だけで割合が大きく変動します。率だけでなく、評価した会議数とTODO数も併記してください。

「AI導入後に売上が増えた」という相関だけで効果を判断してはいけません。

会議ID
  → 抽出されたTODO
  → 実施した変更
  → 公開・送信日時
  → クリックや問い合わせ
  → 購入・受注

この関係をログで追える状態にして、初めて業務成果を評価できます。

反論：人間が議事録を読んだ方が早いのではないか

会議が月に数件しかなく、担当者と期限も明確なら、人間が直接登録した方が早い場合があります。

自動化が効果を出しやすいのは、次の条件がある組織です。

• 同じ種類の会議が繰り返される
• 毎週多数のTODOが発生する
• 転記漏れや期限超過が起きている
• 複数のタスク管理先へ登録している
• 完了状況を継続的に集計したい

導入コストには、プロンプト作成だけでなく、正解データの作成、連携設定、監視、保守も含まれます。

削減できる転記時間より運用コストの方が大きいなら、議事録テンプレートを改善するだけで十分です。

導入判断では、次の式で月間効果を概算できます。

月間削減時間
= 1会議あたりの転記・確認削減時間
× 月間会議数

月間純効果
= 月間削減時間の金額換算
- AI利用料
- 連携ツール費
- 人間の確認コスト
- 保守コスト

この値が小さい段階では、大規模なシステムを作らず、Google Sheetsへの半自動登録にとどめる方が合理的です。

AIによるTODO抽出が向かないケースと限界

次の場面では、抽出精度が下がる可能性があります。

• 発言者が識別されていない
• 録音品質が悪く、文字起こしに誤りが多い
• 冗談、皮肉、遠回しな表現が多い
• 業界固有の略語が説明されていない
• 担当者や期限を会議中に決めない
• 複数案件が混在する長時間会議
• 決定と撤回が何度も繰り返される
• 契約や法務判断など文脈依存性が高い

AIは、会議で決まっていない担当者や期限を正しく復元できません。入力に存在しない情報を、抽出精度の改善だけで補うことはできないからです。

また、会議自体が不要なら、TODO抽出を自動化しても根本的な改善にはなりません。定例会議を減らし、非同期の報告やタスク起票へ移行する方が有効な場合もあります。

今日からできる30分の検証

直近の議事録を1件選び、次の順序で検証してください。

1. 人間が正解TODOを作る
2. 作業内容、担当者、期限、根拠発言を記録する
3. 本記事のプロンプトでAIに抽出させる
4. AIの出力を正解TODOと比較する
5. 誤りを次の4種類に分類する

抽出漏れ
不要抽出
担当者違い
期限違い

6. 曖昧なTODOを確認キューへ分ける
7. 自動登録してよい条件と禁止条件を文章化する
8. 検証結果を保存する

検証結果は、次のような表で残すと次回の改善に使えます。

最初の目標は完全自動化ではありません。「どのTODOなら自動登録でき、どのTODOには人間の確認が必要か」を、自社データで判断できる状態にすることです。

まとめ：議事録からTODOを抽出し、実行までつなげる

AIで議事録からTODOを自動抽出する手順は、次のとおりです。

1. 対象会議を1種類に絞る
2. 会議ID、開催日時、参加者を固定する
3. 人間が正解TODOを作る
4. AIにJSON形式でTODO候補を抽出させる
5. 形式、危険度、重複をプログラムで検査する
6. 安全なTODOだけをタスク管理ツールへ登録する
7. 曖昧なTODOを人間の確認キューへ送る
8. 通知、期限監視、実行ログを接続する
9. 正解率だけでなく、完了率や業務成果も測る
10. 安全な処理から段階的に自動実行へ移す

議事録を要約しただけでは、仕事は進みません。

担当者、期限、根拠を持つTODOへ変換し、登録、通知、実行、効果測定まで追跡できて初めて、会議の内容を再利用可能な運用資産へ変えられます。

本気で業務自動化の仕組みを構築したい方へ

毎回AIへ文章を貼り付ける運用から抜け出し、入力、判断、実行、監視までを一つの流れにしたい方へ、実践マニュアルを用意しています。

自動化は利益を保証するものではありません。一方で、手作業の転記や確認に依存していた処理を、記録と検証が可能な仕組みへ置き換えることはできます。

まずは議事録1件で精度を測り、安全に処理できる範囲を確認してください。その結果を基に、通知、登録、下書き作成など、取り消しやすい処理から自動化を広げるのが現実的です。

次に自動化する業務を、実装可能な設計図へ変えたい方はこちら。

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