スタッフ向けの説明動画は撮ったまま渡さない｜無音と言い直しを自動で削る手順と、要点PDFを添える理由
スタッフ向けの説明動画は撮ったまま渡さない｜無音と言い直しを自動で削る手順と、要点PDFを添える理由
新しい業務システムや管理画面の使い方を、画面を録画しながら口頭で説明する。手軽で情報量も多いのですが、撮ったままのファイルをそのままスタッフに渡すと、まず最後まで見てもらえません。理由は内容の難しさではなく、操作待ちや言葉に詰まった時間が積み上がって尺が伸びていることにあります。
先に結論を書きます。
画面収録した説明動画は、①無音区間を自動で検出して一定の長さに詰める、②言い直し・迷いだけを文字起こしから探して手で削る、③動画を最後まで見ない人向けに要点をまとめたPDFを添える——この3点をセットにして渡します。 無音の圧縮は機械にやらせれば数分で終わり、内容の判断が必要な部分だけ人が見る、という分け方が最も手戻りが少なくなります。
この記事では、名古屋のWEB制作会社graciautoが、EC事業者向けに構築した受注管理システムの操作説明動画（25分36秒の画面収録）を編集して渡したときの実測値をもとに、閾値の決め方から削ってよい箇所の判断基準、要点PDFの作り方までをまとめます。動画編集の専門ソフトは使わず、無料のコマンドラインツールだけで完結する構成です。
結論：削るのは「無音」と「言い直し」だけ。内容は削らない
編集の目的を「短くすること」に置くと、判断を誤ります。目的は同じ内容を、聞き手が集中を切らさずに最後まで見られる状態にすることです。そのため削る対象は「無音」と「言い直し」の2種類に限定し、内容そのものには触りません。3つを並べると次のようになります。
| 種類 | 中身 | 削り方 | 判断者 |
|---|---|---|---|
| 無音 | 操作待ち・考えている間・マウスを動かしている時間 | 自動検出して一定の長さに詰める | 機械 |
| 言い直し | 「あ、これかな」「先にこっちですかね」などの迷い、同じ説明の重複 | 文字起こしから場所を特定して手で削る | 人 |
| 内容 | 説明そのもの、旧やり方との対比、注意点 | 削らない | — |
実例では、25分36秒の収録を22分14秒にしています。削れたのは3分22秒で、その内訳は無音の圧縮が約2分30秒、言い直しの削除が約40秒でした。削減分の8割近くが機械で自動処理できる無音です。ここを手作業でやろうとするから編集が終わらなくなります。
手順1：無音を自動で検出して詰める
無音の検出は、動画変換ツールのffmpegに標準で入っている silencedetect というフィルタで行います。設定するのは2つの数字だけです。
- 音量の閾値：どのくらい静かなら「無音」とみなすか。実例では
-35dBを使いました - 最短の長さ：何秒以上続いたら詰める対象にするか。実例では
0.8秒としました
ffmpeg -i 収録ファイル.mov -af silencedetect=noise=-35dB:d=0.8 -f null -これを流すと、無音区間の開始・終了時刻の一覧が出力されます。実例の25分36秒の収録では188箇所が検出されました。1分あたり7箇所以上、操作待ちや考える間が入っていた計算になります。
詰めるのは「ゼロ」ではなく「0.6秒」
ここが結果を分ける箇所です。検出した無音を丸ごと削除するのではなく、一律0.6秒の間に置き換えます。
無音をゼロにすると、説明の文と文が隙間なくつながって早口の棒読みのように聞こえ、聞き手が内容を処理する時間がなくなります。逆に元の長さのままだと、操作待ちで集中が切れます。実務で見られる状態にするには、「間はあるが、待たされてはいない」長さに統一するのが正解です。0.6秒は、区切りとして認識できて、かつ間延びしない実用的な値でした。
閾値の -35dB も、静かすぎる環境で録っていれば -40dB、エアコンや外音が入っているなら -30dB 前後に寄せて調整します。まず一度検出だけ流して、出てきた件数が体感と合っているかを見るのが確実です。0.8秒という長さも、会話のリズムより短くすると必要な息継ぎまで対象に入ってしまいます。
手順2：言い直しは文字起こしから探す
無音を詰めても、「あ、これかな」「先にこっちですかね」といった迷いの発話は音が出ているので自動では消えません。かといって、25分の動画を頭から見返して探すのは編集で最も時間を使う作業です。
ここは全文の文字起こしを先に作り、テキストで探すのが正解です。音声認識のfaster-whisperを使えば、画面収録のファイルを直接読ませて、時刻付きのテキストが得られます。あとは目で流し読みして、削る箇所の時刻をメモするだけです。25分の動画でも、テキストなら数分で通読できます。
実例で削った3箇所は次のとおりでした。合計で約40秒です。
- 「全体を把握してないんですが」という趣旨の前置きが重複していた箇所
- 目的のファイルを探して「これかな、先にこっちですかね」と迷っている箇所
- 長い操作待ちのあとに「で、それが、」と言い直している箇所
削る／残すの判断基準
迷ったときは、次の基準で切り分けます。
| 発話 | 判断 |
|---|---|
| 内容に関係のない前置き・ヘッジ（自信のなさの表明） | 削る |
| 操作の迷い、ファイルを探している時間 | 削る |
| 同じ説明の言い直し（2回目が正しい） | 1回目を削る |
| 「ここは注意してください」などの補足 | 残す |
| 旧やり方と新やり方の対比 | 残す |
尺を最短にすることを目的にしないでください。 実例では、旧フローの説明に約7分を使っていましたが、これは意図的に残しています。丸ごと落とせば15分台まで縮みますが、スタッフにとっては「今までこうしていた作業が、これからこう変わる」という対比こそが理解の土台になります。7分を削って理解が浅くなるなら、22分のまま渡したほうが結果は良くなります。
手順3：書き出しは残す区間を指定して一発で行う
削る箇所が決まったら、残す区間（keep区間）を並べて1回で書き出します。区間ごとに切り出して後で結合する方式は、つなぎ目で音ズレが起きやすく、やり直しのたびに全工程を踏み直すことになります。ffmpegの select / aselect フィルタに残す区間の条件をまとめて渡し、1回のコマンドで完成品を出す形にします。
画面収録では、先頭にフレームレートの指定を必ず入れる
ここは事前に押さえておくべき箇所です。画面収録のファイルは、画面が動いていない間はフレームを記録しない可変フレームレート（VFR）で保存されていることがほとんどです。この状態のまま区間の切り出しを行うと、映像のタイムスタンプの計算が狂い、音声だけ先に進んで映像が合わない状態になります。
対処は簡単で、フィルタの先頭に fps=30 を入れて固定フレームレート化してから区間指定を行うことです。この1行があるかないかで結果が変わるため、画面収録を素材にするときは最初から入れておきます。
実例の書き出し条件と結果は次のとおりです。
| 項目 | 元ファイル | 完成品 |
|---|---|---|
| 尺 | 25分36秒 | 22分14秒 |
| 解像度 | 4K（4096×2304） | 1080p |
| ファイルサイズ | 1.6GB | 976MB |
| 書き出し時間 | — | 約15分 |
4Kのまま配ると再生側の負荷もファイルサイズも無駄に大きくなるので、書き出し時に1080pへ落とします。Macであればハードウェアエンコード（h264_videotoolbox）を指定すると、25分の素材でも15分程度で書き出せます。ビットレートは画面収録なら6Mbps前後で、文字がにじまない品質になります。
元の収録ファイルは必ず原本のまま残しておきます。 修正依頼が来たときに作り直せる素材はこれだけです。
環境づくりの注意点（Intel Macの場合）
ffmpegはHomebrewで入れるのが定番でしたが、Homebrewは2026年9月からIntel版Macのサポートを終了しており、brew install ffmpeg が通らない環境があります。この場合はPython経由で静的ビルドを入れるのが確実です。
pip3 install imageio-ffmpegこれでハードウェアエンコードも含めて使えるバイナリが入ります。手順書がbrew前提で書かれていると環境ごと詰まるので、動画処理を始める前にどちらの経路で入れるかを決めておきます。
修正依頼は「編集版のタイムスタンプ」で受け取る
編集して渡すと、「11分45秒あたりを削ってほしい」といった修正依頼が返ってきます。このとき、依頼者が見ているのは編集版なので、時刻は編集版基準です。元の収録ファイルでは同じ時刻に別の内容が入っています。
対処は、書き出しに使ったkeep区間の一覧を捨てずに残しておくことです。残した区間の長さを順に足していけば、編集版の時刻から元ファイルの時刻を逆算できます。実例では編集版11分45秒〜11分57秒の依頼を、元ファイルの774.4〜785.9秒と特定して削除し、つなぎ目の前後を再度文字起こしして会話が自然につながることを確認してから差し替えました。
修正のたびに毎回この照合をやることになるので、カット計画のファイルは動画と同じ場所に保存しておくのが実務的です。
動画には要点PDFを添える
ここまでやっても、22分の動画を最後まで見る人と見ない人に分かれます。むしろ、日々の業務の合間に見る現場のスタッフほど、必要になったその場で答えを探したいので、動画は開かれません。
そのため、動画とセットでA4数ページの要点資料を渡します。実例ではA4×3ページのPDFを作り、次の構成にしました。
- これは何か（何が自動化されて、何が手作業として残るか）
- データの置き場所と構成の一覧表
- 毎日やる3ステップ（画面のスクリーンショット付き）
- 例外が出たときの流れ
- 帳票を出す操作
- 今の時点で未完成な箇所
- 詳しく知りたいときは動画のどこを見るか
この「動画＋要点資料」の考え方は、システムに限らずホームページを納品するときも同じです。管理画面の触ってよい範囲と受け渡す資料の中身はホームページ納品後に自分でどこまで更新できるかにまとめています。本稿はその資料を、動画を素材にして作る場合の手順です。
「未完成な箇所」を書くことが効く
6番目を省かないでください。導入直後のシステムには、必ず精度が出ていない項目があります。実例では「特定の販売経路では購入者名が空欄になる」「一部の品番が変換できていない」「参考値として表示している在庫は正確な数字ではない」といった点をPDFに明記しました。
これを書かずに渡すと、現場が最初に気づいた不整合を「壊れている」と受け取り、システム全体への不信につながります。先に書いてあれば、同じ現象は「想定内の未対応項目」として扱われます。 資料の信頼性はここで決まります。
資料に使う画像は、動画の元ファイルから抜く
スクリーンショットを撮り直す必要はありません。説明動画の元収録は解像度が高いので、そこから該当の場面のフレームを静止画として抜き出し、必要な部分だけ切り抜けば十分な画質になります。動画と資料で同じ画面を見せられるので、対応関係もわかりやすくなります。
なお、こうした資料は実データが映った画面を含みます。取引先名や購入者名が入るため、社外に出す資料とは明確に分けて管理します。
PDFを作るときの実務メモ
資料はHTMLで作り、ブラウザの印刷機能でPDFに変換するのが最も手が早い方法です。デザインの調整がCSSでできて、修正も再変換するだけで済みます。
このとき押さえておくべき点が2つあります。
1ページの高さを固定する。 内容を自然に流し込む作り方だと、数ミリの溢れで意図しない空白ページが挟まります。A4なら1ページの高さを268mm程度に固定し、ページ番号などのフッターは絶対配置にして、ページ数を確実に制御します。
変換後のPDFは画像化して目視で確認する。 ブラウザの表示で問題なくても、PDFにしたときに文字が切れたり画像がずれたりすることがあります。PythonのPyMuPDFを使えばPDFの各ページを画像として書き出せるので、それを並べて確認します。Intel Macでは定番のpopplerが入らない環境があるため、PyMuPDFを標準の確認手段にしておくと環境に左右されません。
まとめ：渡す前のチェックリスト
業務の説明動画を渡す前に、次を確認します。
- 無音を自動検出して、一定の長さ（0.6秒程度）に詰めたか
- 言い直し・迷いを文字起こしから探して削ったか
- 説明の内容そのものは削っていないか（旧やり方との対比は残す）
- 画面収録を素材にする場合、フレームレートを固定してから書き出したか
- 1080p程度に落として、配りやすいサイズになっているか
- 元の収録ファイルを原本のまま残したか
- カット計画を保存し、修正依頼の時刻を逆算できる状態にしたか
- 動画を見ない人向けの要点資料を添えたか
- 資料に「今は未完成な箇所」を書いたか
動画編集というと専門ソフトと長い作業時間を思い浮かべますが、業務説明の動画で本当に必要なのは演出ではなく、待ち時間を削って、要点に別の入口を用意することです。実例では25分の収録を22分に整え、A4×3ページの資料を添えるまでを、無料のツールだけで完結させています。
graciautoでは、業務システムの構築とあわせて、現場に定着させるための説明資料の設計まで対応しています。作った仕組みが使われずに止まってしまう原因の多くは、仕組みそのものではなく渡し方にあります。