AI 議事録からアクション抽出ワークフロー
要約
会議録音から自動でアクションアイテムを抽出し、タスク管理システムに同期するワークフロー。/recap で議事録をパース、/sync で Notion/Linear へ登録、/notify で所有者に通知。この3コマンドチェーンで、週あたり約2時間の手作業を削減できます。実装には20～30分の初期設定が必要ですが、その後は完全自動。
AI 議事録からアクションアイテム抽出：会議のあと3つのコマンドで実行するワークフロー
会議が終わってから10分以内に、割り当てられたアクションアイテムの大半が消え去る。誰も意図的に忘れているわけではない。録音記録は完璧でも、「その後、誰がいつまでにやるのか」という部分が曖昧なまま残るのだ。このガイドでは、生の議事録をタスク管理システム（Notion または Linear）に自動で送り込むコマンドチェーン ― 3つのスラッシュコマンドと1つのAI ノートテイク ツール ― を使った実装手順をお見せする。
なぜアクションアイテムは会議終了後に消えるのか
「誰かが何かを言った」から「誰かがそれを所有している」の間のギャップで、アクションアイテムは死ぬ。議事録は会議内の全ての「～すべき」と「できますか」を記録するが、議事録はタスクリストではない。4000語の対話の中に、本当のコミットメントが3つ埋もれているのだ。
解決策は、より良いノートテイカーではない。それは、opリーダーが議事録を読む方法で反応するコマンド：動詞を探し、所有者を探し、期限を探し、3つのうち1つでも欠けていたら「不明」とフラグを立てることだ。推測しない。Fellow の解説では、ベンダー側からも同じ見方が示されている ― 勝つツールは最もクリーンな議事録を持つものではなく、あなたが再構築する代わりに承認できるタスクリストを渡すものだ。
ほとんどのチームは既にノートテイカーを持っている。欠けているのは中間層だ：「要約を得た」から「実際に使っているシステムのタスクになった」までの段階。その中間層はスラッシュコマンドで、別の SaaS 契約ではない。そしてそれが、このガイドで実装する部分だ。
ステップ1：所有者と期限を抽出する、ノートテイカーを選ぶ
スラッシュコマンドが何かに触れる前に、構造化された議事録が必要だ。全てのノートテイカーが同じ方法でアクションアイテムを抽出するわけではなく、その差は転写精度スコアのランディングページより重要だ。
30秒のブリーフィング：ボットが会議に参加することで、ディール審査会で何かを言う人の意思が変わるなら、ボットレスツールを選べ。さもなくば、決定とアクションアイテムをどれだけ綺麗に分離するかで最適化する。
Fathom の要約構造はそのまま使える形に近い。決定、アクションアイテム、未解決の質問を1つのテキストの壁ではなく、別々のブロックに分離する。これがステップ2で /recap コマンドがパースする形式だ。
Fireflies は営業オペレーション向け。アクションアイテムを直接 HubSpot や Salesforce フィールドに送り込む。これは「このディールの次のステップ」が本来のアクションアイテムなら便利だが、内部チームタスクなら異なる。
Granola はボットを会議に送り込まない。ローカルで転写し、自分がタイプした注釈を転写に重ね、抽出したアクションアイテムは AI が「重要だと思った」ものではなく、あなたが「重要とマークした」ものに紐づく。
1つを選べ。精度を交差確認したいからと同じ会議に2つのノートテイカーを走らせるな。掃除の作業が倍になり、後述の /recap コマンドは1つの規範的な議事録を期待する。
ステップ2：議事録をタスクリストに変える /recap コマンドを作る
CommanderGPT で Workflow Builder を開き、/recap という新しいコマンドを作成する。プロンプトは3段階で動く：
議事録を引き込む（ペーストするか、プランが API エクスポートに対応していれば、ノートテイカーのエクスポートリンクを指す）
コミットメントパターンに合致する全ての文を抽出する："I'll", "we should", "can you", "let's"
各マッチに対して3つのフィールドを出力：タスク、所有者、期限。所有者または期限が欠けたら、推測する代わりに "unclear" を出力する
その3番目のルールがチームが飛ばすものであり、重要なのだ。所有者を推測する AI は、曖昧さを単に下流へ移動させるだけだ。3日後、「チーム」が実行しなかったことが判明する。チームの誰もそれが自分のものだと思わなかったからだ。
/recap [議事録をペースト]
→ アクションアイテムを次の形式で抽出：- [ ] タスク | 所有者 | 期限
→ 所有者または期限が欠けたら "unclear" とマーク、推測しない
→ 決定と FYI は無視、実行可能なコミットメントだけを出力本当の議事録で一度実行してから信頼する。6人のスピーカーがいる45分間の会議では、最初のパスは通常1回の手修正が必要だ：誰かが「価格を調べてくれない」と言ったが、"you" を名付けなかった。コマンドはそれをフラグすべきだが、黙って最後のスピーカーに割り当てることはない。
ステップ3：コピー・ペーストなしで Notion または Linear にアクションアイテムをルーティング
/recap がクリーンなリストを出力したら、チェーンの2番目のコマンド /sync が、そのリストを実際のタスクに変える。これがほとんどのチームが手動でやるステップであり、最も時間がかかるステップだ：要約メールから6行を6つの別々の Notion 行にコピーする。
チームが既に Notion に住んでいるなら、/sync は各抽出行をデータベースエントリにマップする。タスク名、所有者（チームメンバーリストに対して一致）、期限、そして会議録音へのリンク。エンジニアリング関連のオペレーション部門が Linear を走らせていれば、同じコマンドは issue を作成する。データベース行ではなく issue だ。会議日でタグ付けされているので、後から追跡可能だ。
マッピングは最初のランでは自動ではない。/sync は Notion プロパティのどれが所有者名を持ち、どれが期限を持つかを知る必要がある。Linear は、コマンドから新しい issue を受け入れる前に、デフォルトのチームと issue テンプレートが必要だ。人間が「New Issue」をクリックするのではなく、コマンドからだ。このセットアップをスキップすると、コマンドは無音で失敗するか、さらに悪いことに issue を間違ったチームのバックログに作成する。
セットアップコストは本物だ。Notion データベースフィールドをマップするか、Linear issue テンプレートを最初にセットアップするのに20～30分を期待する。その後、会議ごとにゼロの手入力だ。ある CS オペレーション チームが週次 QBR 準備コールでこれを走らせたのを見たことがある。25分のポスト会議クリーンアップを90秒のレビューと承認ステップに削減した。それは万能な数字ではない。独自のクリーンアップ時間は、通常の会議がどれだけのアクションアイテムを生成するかに依存する。しかし、それは勝ちの形だ。タイピング置換のレビュー分。
/recap → /sync → /notify チェーン：自分で走るワークフロー
フルチェーンは3コマンド、2つではない。3番目の /notify は、/sync が Notion または Linear への書き込みを完了した直後に、各所有者に Slack ダイレクトメッセージを送信する。その所有者固有のアクションアイテムと期限で。
Workflow Builder でチェーンした場合、シーケンスは次のようになる。議事録が入り、/recap が抽出し、/sync がタスクを作成し、/notify が所有者をピングする。ダッシュボードをチェックする必要なし。ダイジェストメールをスキム必要なし。タスク所有者は会議終了から1分以内に、コンテキストがまだ新鮮なうちに、全議事録を再読する必要がないほど新鮮なうちに、所有者であることを知る。
これが「3つのコマンド、1つのワークフロー、0の摩擦」というアイデアが稼ぐところだ。各コマンドは1つのジョブをこなし、1つを（異なるノートテイカー、異なる宛先、異なる通知チャネル）スワップでき、チェーンをリビルドすることなく。
ここで壊れるもの：定期会議、静かな話者、曖昧な動詞
このワークフローをチーム全体に展開する前に知っておく価値のある3つの失敗モード。その後ではなく。
定期会議は、/sync が新しいものを作成する前に同じタスク名で既存のオープンアイテムをチェックしない場合、タスクを複製する。過去14日間のオープンタスクに対して重複排除チェックを追加する。さもなくば、6つの異なる週から「法務に確認」行で満たされた Notion データベースが得られる。
静かな話者はスキップされる。誰かが呼び出し中の側の注釈やチャットメッセージでコミットした場合、議事録はそれを見ず、/recap も見ない。それは実際のギャップだ。チューニング問題ではない。コマンドは言われたことを抽出する。意図されたことではなく。
曖昧な動詞は曖昧なタスクを生成する。「価格について考えましょう」はアクションアイテムではなく、ディスカッション トピックだ。よくチューニングされた /recap はそれを不明としてフラグすべきだが、それのための偽の所有者と期限を製造してはいけない。コマンドが曖昧な会議から疑わしく完全なタスクリストを生成している場合、それは推測中だ。それは監査する価値がある。
30日後に測定する内容
ワークフローの言葉を信じるな。展開後30日間は2つの数値を追跡する：完了率（/recap が抽出したアクションアイテムのうち、期限までに実際に完了したのはいくつか）と手動修正率（コマンドが所有者または期限を間違ったのは、どのくらい頻繁に修正が必要だったか）。
ベースラインに対して完了率がフラットなままの場合、ボトルネックは抽出ではなく、フォローアップだ。スラッシュコマンドチェーンは責任問題を修正しない。手動修正率が最初の2週間の後に5つに1つ以上の抽出アイテムの場合、ノートテイカーをスワップしないでください。/recap プロンプトはタイトにする必要がある。Fellow の完了率追跡ガイドは、完了率側のための体系的なフレームワークがある。
持つフレームワークがなければ。ネットワーク全体のベンチマークはない。1週目のベースラインを測定し、比較する。
次のセットアップコマンド
/recap だけで開始する。次のディール審査または QBR 準備コールでそれを実行し、手動で Notion にそれを1回コピーし、修正が必要なだけ見る。3つのコマンド全てを1日目に一度にチェーンしてから、抽出を信頼する。あなたはただワゴン全体のタスクリストを自動化する方法を見つけてからだ。
/recap が3つの連続するコールで20%未満の修正で所有者と日付のペアをクリーンに生成したら、/sync を追加する。目的地が正しい後に /notify を追加する。チェーン全体を10人のチームに送信する前に偵察完了。