ウェビナーの録画から、参加者と欠席者に配るフォロー資料を作る

処理の起点を決める

開催の翌朝に、前日ぶんの録画を確認するスケジュール実行にします。

ウェビナー終了と同時に動かさないのは、録画と文字起こしの処理が終わるまで時間がかかるためです。終了直後に取りに行くとファイルがありません。翌朝に回せば確実です。

終了を起点に動かしたい場合は、Zoomのレコーディング関連のWebhookが使えるかを開発者ドキュメントで確認してください。使える場合も、ファイルが揃わなければ一定時間後に再試行する作りにしておきます。

入力データを集める

データの取得方法を決める

録画と文字起こし： Zoom の Get meeting recordings エンドポイント（GET /meetings/{meetingId}/recordings）を呼びます。レスポンスの recording_files には録画ファイルの種類ごとの情報が入り、file_type が TRANSCRIPT のものが VTT 形式の音声トランスクリプトです。ほかに MP4（映像）、M4A（音声）、CHAT（チャットのテキスト）、CC（字幕）、SUMMARY（JSON）が返ります。

ファイルは download_url から取得します。パスワードで保護された録画にアクセスするには、download_access_token または OAuth のアクセストークンを Authorization ヘッダの Bearer トークンとして使います。必要なスコープは recording:read、粒度の細かいスコープでは cloud_recording:read:list_recording_files などです。

前提として、Zoom側でクラウド録画と音声トランスクリプトの設定を有効にしておく必要があります。 設定が無効だと TRANSCRIPT のファイル自体が作られません。最初に1本だけテスト開催して、TRANSCRIPT が返ることを確かめてください。

登壇資料： スライドの画像を Claude API に渡して、話の流れと突き合わせることもできます。Claude は1リクエストに複数の画像を含められ、JPEG・PNG・GIF・WebP に対応します。画像はテキストより前に置くほうが結果がよくなります。 ただし、文字起こしだけで要点は作れるので、まずは資料なしで始めてかまいません。

AIへ渡す前に整形する

1. 文字起こしの整形 … VTTのタイムコードと話者を残したまま、あいづちや言い淀みを落とします。タイムコードは残してください。 「この話は開始32分から」と書けると、レポートの価値が上がります
2. 参加状況の区分け … 視聴時間から3つに分けます。最後まで視聴（8割以上）／途中離脱（2割以上8割未満）／申込のみ（参加なし）
3. 個人情報の切り離し … 氏名とメールアドレスは生成AIに渡しません。区分と人数だけを渡し、宛先の差し込みは配信ツール側で行います
4. チャットの選別 … 「ありがとうございました」のようなあいさつを落とします。質問と意見だけを残します

AIに処理させる

取得と生成で役割を分けます。

取得（ワークフロー）にさせること： ファイルの取得、参加者の集計、区分け。視聴時間の集計を生成AIにさせません。 数え違いが起きます。

生成AIにさせること：

指示内容を固定する

あなたはウェビナーの運営を支援する担当者です。
文字起こしと質疑のログから、フォロー用の資料を作ってください。

【厳守事項】
- 本編で話していないことを書かないでください。
  レポートの各項目に、文字起こしのタイムコードを付けてください。
- 未回答の質問に回答案を作るときは、本編で話した内容の範囲で作り、
  範囲を超える場合は「講師の確認が必要」としてください。
  製品の仕様、価格、納期について、渡された資料にない数字を書かないでください。
- 参加者の氏名を書かないでください。区分と人数だけを使ってください。
- フォローメールでは、参加していない人に「ご参加ありがとうございました」と
  書かないでください。区分ごとに書き出しを変えてください。
- 効果や実績を断定する表現（「必ず〜できます」「〇倍になります」）を
  使わないでください。

【文字起こし（タイムコードつき）】
{transcript}

【Q&Aログ】
{qa_log}

【チャットログ（質問・意見のみ）】
{chat_log}

【参加状況の区分と人数】
{attendance_summary}

【過去のフォローメールの構成】
{past_email_format}

「参加していない人にお礼を書かない」の1行が重要です。 生成AIに「フォローメールを書いて」と頼むと、どの区分にも同じお礼の文で書き出します。申し込んだだけの人に「ご参加ありがとうございました」と届くのは、いちばん避けたい失敗です。

出力形式を固定する

Claude API の structured outputs でJSONスキーマを指定します。

{
  "webinar_id": "",
  "title": "",
  "held_at": "",
  "report": {
    "sections": [
      { "heading": "", "points": [], "timecode": "" }
    ],
    "key_takeaways": []
  },
  "qa": {
    "answered": [
      { "question": "", "answer_summary": "", "timecode": "" }
    ],
    "unanswered": [
      { "question": "", "draft_answer": "", "needs_speaker_check": true }
    ]
  },
  "emails": [
    {
      "segment": "最後まで視聴 | 途中離脱 | 申込のみ",
      "subject": "",
      "body": ""
    }
  ],
  "high_interest_signals": [
    { "question": "", "reason": "" }
  ],
  "needs_review": []
}

high_interest_signals には質問の内容だけを入れ、誰が質問したかは入れません。 突き合わせは自社側で行います。

システムへ連携する

出力先は3通りあります。

自動送信はしません。 見込み客に届くメールなので、内容の誤りがそのまま会社の信用に関わります。下書きまでを自動化し、送信は人が承認する運用にしてください。

人が確認する

全件、人が確認してから送ります。

理由は3つあります。ひとつは、製品の仕様や価格について誤った記述が混ざる可能性があること。ひとつは、未回答の質問への回答案が、講師の見解と違うことがあること。もうひとつは、文字起こしの誤変換が要点に持ち込まれることです。

確認を速くするための設計が重要です。

• レポートの各項目にタイムコードを付け、録画の該当箇所にすぐ飛べるようにする
• needs_speaker_check: true の質問を先頭にまとめる
• 3つのメールを並べて表示し、書き出しの違いを見比べられるようにする
• 製品名・数値・日付を色付けする（ここが誤りやすい箇所です）

例外に対処する

記録を残す

• 文字起こしの原本とレポート
• 生成したメールの下書きと、人が直した後の本文
• 送信した区分と件数
• 未回答の質問と、講師の回答
• 質問した人と、その後の商談化の有無

「人が直した後の本文」を残してください。 どこを毎回直しているかが分かると、プロンプトを直すべき箇所が決まります。

参加者の氏名とメールアドレスは個人情報です。生成AIに渡さない設計にしたうえで、保管場所と保存期間を社内規程に合わせてください。