tl;dvでZoom会議を記録するときは、カレンダーの予定を自動記録するか、必要な会議だけ手動で記録するかを選びます。botが来ない場合は、予定・自動記録条件・待機室・参加制限を順に確認します。botなし記録へ切り替えるなら、残せるのは音声だけという違いも確認してください。
この記事では、Zoomで記録を始め、録れていない原因を切り分け、会議後に必要な記録へ戻れる状態までを扱います。tl;dvやZoomの実操作、録音、設定変更は行っていません。後半の診断表は、公式条件を使った独自の架空例です。
目次
記録方法を、残したいものから選ぶ
表は横にスクロールできます
| 方法 | 向く場面 | 先に確認すること |
|---|---|---|
| カレンダーからbotを自動参加 | 対象条件を決めた定例会議 | 予定、対象条件、hostの入室対応 |
| botを手動招待 | 今回だけ記録したいZoom会議 | 正しい会議URL、botの入室 |
| desktop appのbotなし記録 | botを入れず、音声を残したい | 端末音声、権限、参加者への周知 |
botを使うかどうかと、自動か手動かは別の軸です。desktop appを開いたことだけで、botなし方式を選んだとは判断しません。記録開始前に、今回選んだ方式をアプリで確認します。
botなし方式は、マイクとPCから再生される音を取り込みます。動画・画面共有・チャットは記録しません。画面上の操作や資料の変化まで後で確認したい会議では、音声だけで目的を満たすかを先に判断します。tl;dv：Recording without a bot（新しいタブで開く）
Zoomの自動記録を設定する
連携したGoogleまたはOutlookカレンダーに、対象会議があることを確認します。次にPreferencesで、自動記録をすべての会議、社内、社外のどこへ適用するか選びます。公式の社内・社外の区別はメールドメインが基準で、会議名に「社内」と書いてあるかではありません。
公開メールドメインのアカウントでは、社内のみ・社外のみを選べないと説明されています。また「自分が参加した会議だけ」の設定はGoogle MeetとChrome拡張の条件で、Zoomへそのまま適用しません。自分がZoomへ入らなければbotも来ない、という前提で自動化を組まないでください。tl;dv：Preferences（新しいタブで開く）
初回は短い社内テストを用意し、予定が認識されること、対象条件に合うこと、hostがbotを確認できることを順に見ます。会議ごとに入室を拒否したり、参加後にbotを退出させたりできるという公式案内もあります。記録しない会議をどう扱うか、hostと事前に共有しておきます。tl;dv：Recording meetings with Zoom（新しいタブで開く）
必要な会議だけ手動で記録する
botを使う手動記録では、Zoom会議を開いてdesktop appから開始する方法と、tl;dvホームのRecord nowへ会議URLを入力する方法が案内されています。どちらも、botを送る操作とhostが入室を許可する操作を分けて確認します。URLを渡せたことを、記録開始の証拠にはしません。
同名の会議が複数あるなら、タイトルだけでなく日時とURLを照合します。別の予定からコピーしたURLや、変更前のリンクを使うと、対象会議と送信先がずれます。URLに含まれる参加情報を、不要な共有先へ貼らないようにしてください。
botが出てこないときは、予定から順に見る
以下は公式のbot参加トラブル案内に沿う確認順です。botなし録音へ、botの待機時間や参加制限を当てはめません。tl;dv：Didn’t join my meeting（新しいタブで開く）
- 自動か手動かを確認する。 自動記録がオフなら、自動参加を待つだけでは始まりません。必要な会議へ手動招待したかを確認します。
- 予定開始時刻と予定形式を見る。 早くZoomへ入った場合、予定時刻より前にbotがいないだけかもしれません。終日予定はbotが参加しない条件として説明されています。
- 待機室と参加者を見る。 hostが入室要求を確認したか、bot以外の参加者がいるかを見ます。公式は、待機室での待機と、入室後に他参加者を待つ場面をそれぞれ10分と説明しています。この二つを足して「必ず20分待つ」とは扱いません。
- 別のtl;dv botがいないかを見る。 公式案内では、同じ会議に参加するtl;dv botは一つです。他の参加者が記録しているなら、重ねて招待するより、その人へ必要な記録の共有を依頼します。
- Zoomの参加制限を確認する。 認証必須の参加条件が原因になる例が公式にあります。管理者へ、該当会議の設定と表示されたエラーを渡します。
認証必須設定を外す公式手順が載っていても、録音のために組織全体の参加制限を一律に緩める判断はしません。管理者が会議の条件を確認し、許可された方法を選びます。botなし方式も、会議の記録を認めるかという判断を置き換えるものではありません。
まずは使ってみる
記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。
tl;dv
架空の6例で、最初の確認先を決める
次の表は障害を再現した結果ではありません。観察できた情報から、次の一手を選ぶための手製例です。「次の確認先」であり、原因を確定した一覧ではありません。
表は横にスクロールできます
| 例 | 分かっていること | 最初の確認先 |
|---|---|---|
| A | 自動記録オフ、手動招待なし | 記録方法を決め、必要なら手動開始 |
| B | 14時開始の予定へ13時55分に入室、botなし | 予定時刻と正しい会議URL |
| C | botの入室要求が待機室にある | hostの入室確認 |
| D | 同僚のtl;dv botがすでに参加 | 同僚の記録と共有先 |
| E | Zoomが認証条件のエラーを返す | host・管理者へ該当設定を照会 |
| F | botなし方式で相手の音声が欠ける | system audioの取得と選択方式 |
Bで「障害だから設定を変更」、Dで「別のbotを追加」、Fで「待機室を探す」と進めると、分かっている状況と作業が対応しません。原因が複数ある可能性は残し、一項目ずつ確認して結果を記録します。
botなし方式を使うときの準備と停止
公式の対象はMacまたはWindowsのdesktop appです。Macではマイクとsystem audioの権限を確認します。拒否済みの場合は、アプリのEnable microphone／Enable system audioから設定を開き、必要な権限と再起動を案内どおりに確認します。OSによって設定の表記が違うため、画面名だけを頼りに別の権限を広く付けません。tl;dv：Desktop app（新しいタブで開く）
開始前に参加者へ記録を伝え、選んだ方式でStart Recordingを実行します。会議が終わったらStop Recordingを行い、ライブラリで対象の記録を確認します。botなし方式では他のアプリの音楽や通知音も入り得るので、会議に不要な音を止めてから短く試します。会議サービス側の録音通知が自動で出るとは限りません。
アプリから「会議を検出した」という通知が出ても、記録済みとは扱いません。またdesktop appを終了・削除しても、カレンダー自動記録が有効ならbotの参加試行は続くという案内があります。自動記録を止めたいときは、desktop appの有無とは別にPreferencesを確認します。
会議後は、保存・内容・共有を別に確認する
まずライブラリで会議名と日時を確認し、開始部分と終了部分を再生します。自分と相手の声が含まれるか、途中開始や停止がないかを見ます。botなし方式の記録に映像がないことを、そのまま映像の取得障害とは判断しません。
次にTranscriptの固有名詞・数字・期限を元音声と照合します。決定事項や担当者を要約だけで確定せず、聞き取れない部分は未確認として残します。会議後に要約が作られたことと、全発言を正しく記録できたことは別です。
最後に、通知メールの送信先と、記録を閲覧できる相手を確認します。公式は、メールを自分だけに送る設定が、招待者の録画アクセス権を変えるわけではないと説明しています。メールが届かなかった人は閲覧できない、と推測しないでください。具体的なリンクと共有範囲の選び方は会議要約を共有する手順で確認できます。
記録が見つからない場合、要約の再生成を先に試すより、記録方法、会議URL、開始時刻、botの入室状況、端末音声を確認します。問い合わせ時はアプリ版、OS、会議日時、選んだ方式、表示エラー、確認済み項目をまとめ、認証情報や不要な会議内容を含めません。
参考資料
- tl;dv：Recording meetings with Zoom（新しいタブで開く）
- tl;dv：Understanding and setting your preferences（新しいタブで開く）
- tl;dv：tl;dv didn’t join my meeting（新しいタブで開く）
- tl;dv：Desktop app（新しいタブで開く）
- tl;dv：Recording without a bot（新しいタブで開く）
公式資料の確認日：2026年10月21日。bot参加トラブル資料は2025年4月3日、Zoom記録資料は2025年11月24日、desktop appとbotなし記録資料は2026年7月9日の掲載表記です。古いbotの説明だけで現在の全方式を判断せず、各方式の資料を使い分けました。診断6例は架空例で、実会議、入室待機時間、音声取得、文字起こし精度、共有権限、料金は未検証です。