今すぐ使える！無料の画面録画ツール活用

OBS StudioはGitHubで数万規模のスター、FFmpegも同様に厚い支持を得る成熟ソフト¹²であり、WindowsとmacOSには標準の画面録画機能が最初から搭載されている³⁴。つまり追加費用をかけずに、テキストより速く伝わる「動画の一次情報」を今日からチームの標準にできる。プロダクトの不具合再現、仕様の変更点、オンボーディングの小さなハードルは、短い画面録画一本で解消できる場面が多い。テキストの整形や図の作成にかけていた時間を、録画と共有の数分に置き換えるだけで、意思決定は前へ転がる。無料かつ即効性の高い選択肢を積み上げ、品質とガバナンスを両立させるのがCTOの現実解だ。

即効で回すなら「標準機能＋オープンソース」

OS標準は最短ルートだ。Windows 10以降はWin+GでGame Barを起動し、そのままウィンドウや全画面を録画できる³。macOS Mojave以降はShift+Command+5で録画UIが出現し、画面全体、領域、マイク音声の有無を選べる⁴。どちらもインストール不要で、端末セキュリティポリシーに乗りやすいのが強みだ。一方で、ビットレート（1秒あたりのデータ量）やコーデック（圧縮方式）、キーフレーム間隔（編集や検索の基準となるフレーム）などの細かな制御はできない。繰り返し使う操作手順を品質一定で残したい場合や、負荷を押さえながら長時間の収録をしたい場合は、OBS StudioまたはFFmpegが妥当になる。OBSはUIでのプリセット運用とライブ視認性が強み、FFmpegはスクリプト化と軽量動作が強みという役割分担で考えると設計が楽だ。迷ったら、解像度1080p・フレームレート30fps・ビットレート約6Mbps・CBR・キーフレーム2秒を起点に調整すれば、初心者にも扱いやすく実用画質になる。

ブラウザ単体でもChromeやEdgeはgetDisplayMediaを介してタブ録画が可能で、WebMでの保存なら追加ソフト不要だ⁵。デバッグ用にタブ限定の録画を手早く回すには十分な品質が得られる。例えば次のコードは、ブラウザ内でタブを録画してダウンロードさせる最小例になる。チームのヘルプページに貼っておけば、ユーザーからの再現動画を簡単に集められる。再生はChrome/Edgeがスムーズで、他ブラウザでは再生互換性を事前に確認しておくと安心だ。

<button id="rec">Start</button>
<script>
  const btn = document.getElementById('rec');
  btn.onclick = async () => {
    const stream = await navigator.mediaDevices.getDisplayMedia({video: true, audio: true});
    const chunks = [];
    const rec = new MediaRecorder(stream, { mimeType: 'video/webm;codecs=vp9' });
    rec.ondataavailable = e => chunks.push(e.data);
    rec.onstop = () => {
      const blob = new Blob(chunks, {type: 'video/webm'});
      const a = document.createElement('a');
      a.href = URL.createObjectURL(blob);
      a.download = `capture-${Date.now()}.webm`;
      a.click();
    };
    rec.start();
    setTimeout(() => rec.stop(), 10000); // 10秒だけ録画
  };
</script>

標準機能のハマりどころ

macOSでシステム音声を含めたい時は、BlackHoleやLoopbackのような仮想デバイス（音声の入出力を仮想的に橋渡しする仕組み）が必要になる⁶。WindowsのGame BarはUWP制約由来の相性問題が残るアプリもあり、録画対象の切り替えに弱い。品質の一貫性が要件に入るなら、早めにOBSへ寄せておくと火消しが減る。

品質とパフォーマンスを決めるOBS/FFmpeg設計

録画の品質は、解像度（画面の細かさ）、フレームレート（1秒あたりのコマ数）、ビットレート（動画の情報量）、キーフレーム間隔（編集のしやすさに関与）、エンコーダ（圧縮エンジン）の選択でほぼ決まる。UI運用ならOBSの出番だ。出力モードを詳細に切り替え、録画品質を高品質、エンコーダをx264またはハードウェア（NVENC/Quick Sync/VideoToolbox）に設定する。CPUを守りたいならNVENCやQuick Sync、Apple SiliconではVideoToolboxが第一候補になる⁷。キーフレーム間隔は2秒（配信互換）を基準に、ローカル用途なら長めでも構わない。可変ビットレートでも良いが、チームルールを明確にするならCBR指定が扱いやすい。最初の一歩としては、1080p/30fps/CBR 6Mbps/キーフレーム2秒でスタートし、用途に応じて微調整すればよい。

FFmpegは自動化の主役だ¹¹。以下はコピペで動く最小例で、Windowsでディスプレイ全体とマイクを録る。gdigrabは軽量で、ターゲット指定も柔軟だ⁸⁹。

# Windows: 画面 + マイク（既定デバイス）をH.264で録画
ffmpeg -f gdigrab -framerate 30 -i desktop \
  -f dshow -i audio="マイク (既定)" \
  -c:v h264_nvenc -preset p5 -b:v 6000k -maxrate 6000k -bufsize 12000k \
  -c:a aac -b:a 160k -movflags +faststart capture-win.mp4

macOSではavfoundationを使う。Apple SiliconならVideoToolboxでハードウェアエンコードが効果的だ¹⁰。デバイス番号はffmpeg -f avfoundation -list_devices true -i ""で確認できる。

# macOS: 画面 + マイクをH.264 (VideoToolbox) で録画
ffmpeg -f avfoundation -framerate 30 -i 1:0 \
  -pix_fmt yuv420p -c:v h264_videotoolbox -b:v 6000k \
  -c:a aac -b:a 160k -movflags +faststart capture-mac.mp4

LinuxはX11とPulseAudioの組み合わせが広く使われている⁸。Wayland環境ではツールチェーンに依存するため、XWaylandの併用やOBSを推奨する。

# Linux: X11 + PulseAudio をH.264で録画
ffmpeg -f x11grab -framerate 30 -i :0.0 \
  -f pulse -i default \
  -c:v libx264 -preset veryfast -b:v 5000k -c:a aac -b:a 128k capture-linux.mp4

長時間録画や編集耐性を上げるなら、コンテナにMKVを使ってからMP4へリマックスする手順が堅い。録画中の異常終了時にフッターが壊れても救える可能性が上がる。

# 安全第一: まずMKVで録画
ffmpeg -f gdigrab -i desktop -c:v h264_nvenc -c:a aac rec.mkv
# その後に無再圧縮でMP4へ変換（高速）
ffmpeg -i rec.mkv -c copy -movflags +faststart rec.mp4

品質に直結するのはエンコーダの選び方だ。ソフトウェアのx264は同じビットレートで画質が出しやすいがCPUを使う。ハードウェアのNVENC/Quick Sync/VideoToolboxはCPU負荷を抑えながら充分な画質を出せる⁷。開発機でビルドと同時に収録するならハードウェアエンコードが安全だ。次はGPUエンコードの最小例で、負荷を数％単位に抑えやすい。

# NVIDIA: NVENC を使った高効率録画
ffmpeg -f gdigrab -framerate 30 -i desktop \
  -c:v h264_nvenc -preset p4 -rc cbr -b:v 6000k -maxrate 6000k -bufsize 12000k \
  -c:a aac -b:a 160k capture-nvenc.mp4

共有とセキュリティ：SaaSに乗らずに流す

守秘が厳しい現場では、クラウドSaaSへの自動アップロードを避けたい場面がある。オンプレかVPC内のS3互換ストレージに保管し、署名付きURL（一定時間で無効化されるリンク）で有効期限付きの共有にすると監査しやすい¹²。AWS CLIなら数秒でリンクを切れる。CIからも叩けるので、E2Eテストの失敗時に動画を添付するのも容易だ。

# S3へアップロード
aws s3 cp rec.mp4 s3://your-bucket/path/rec.mp4 --sse AES256
# 1時間有効の署名付きURLを発行
aws s3 presign s3://your-bucket/path/rec.mp4 --expires-in 3600

秘匿情報が映り込む恐れがあるなら、FFmpegのフィルタでぼかしや塗りつぶしを事前に入れておくと運用が楽になる。UI固定座標なら自動化も容易だ。部分的なマスキングと透かしの重畳は次の通りだ。

# 画面右上200x100をぼかし、透かしロゴを右下に配置
ffmpeg -i rec.mp4 -i logo.png \
  -filter_complex "[0:v]boxblur=10:1,drawbox=x=W-220:y=20:w=200:h=100:color=black@0.6:t=max[v]; \
                   [v][1:v]overlay=W-w-20:H-h-20" \
  -c:a copy rec_safe.mp4

トリミングは再エンコードなしで行えば画質劣化もゼロで済む。レビュー用に短く切るだけなら、キーフレームに合わせた無劣化カットが高速だ。

# 無再圧縮でトリム（最寄りキーフレーム単位）
ffmpeg -ss 00:00:08 -to 00:00:24 -i rec.mp4 -c copy rec-cut.mp4

運用設計とROI：3日で習慣化する導入

ツール導入の鍵は、収録・命名・配置・共有の四つを決めて習慣化することだ。命名は日時とトピックを先頭に置くと検索性が上がる。例えば2025-08-30_bug-1234-repro.mp4のように揃えておけば、JiraやGitHubの番号と自然に紐づく。ファイル配置はプロジェクト単位の録画/日付/課題番号という三層に固定すると、属人性が減る。共有はSlackのスレッドに署名付きURLと30文字以内の概要、関連チケットのリンクを添えて完了させる。説明テキストを最短化し、動画に情報を寄せるのが短期で効くコツだ。

生産性の目安を数式化しておくと、導入の意義が説明しやすい。バグ再現の説明時間が1件あたり平均5分短縮され、月200件のトリアージがあるなら、削減時間は約1,000分、すなわち16.7時間になる。エンジニアの実効コストを1時間7,000円と仮置きすると、月あたり約11.7万円の説明コスト削減だ。動画収録と共有の追加コストが1件あたり2分だとしても、差し引きで十分にプラスが出る。オンボーディングや運用引き継ぎのレクチャーでも同種の効果が出やすい。静的ドキュメントの作成・更新に費やす時間が多いほど、録画の一次情報に置き換えるインパクトは大きくなる。

業務への影響を最小化するためのマイルストーンはシンプルで良い。初日は標準機能での録画と共有を全員が体験し、二日目にOBSのプロファイルを配布して品質を揃える。三日目にFFmpegのスクリプトを配布し、E2E失敗時の自動収録とアップロードをCIに組み込む。以降は「録画を貼る」文化が自然に根づいていくはずだ。

CI連携と自動化の最小構成

E2Eテストの失敗時に直近の操作を自動で録画し、成果物として保管できると、再現不能のやり取りが減る。PlaywrightやPuppeteerは内蔵のトレースや動画収録をサポートしているが、要件次第ではFFmpegで画面全体を並行録画するのが簡潔だ。GitHub Actions上でXvfbの仮想ディスプレイと併用する例を示す（|| trueは失敗しても後続を続行するためのガード）。

# GitHub Actions: FFmpegでE2Eの様子を並行録画
jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Xvfb
        run: |
          Xvfb :99 -screen 0 1920x1080x24 &
          export DISPLAY=:99
      - name: Start recording
        run: |
          ffmpeg -y -f x11grab -s 1920x1080 -i :99 \
            -c:v libx264 -preset veryfast -b:v 5000k e2e.mkv &
          echo $! > ffmpeg.pid
      - name: Run tests
        run: npm run test:e2e || true
      - name: Stop recording
        run: |
          kill $(cat ffmpeg.pid) || true
          ffmpeg -i e2e.mkv -c copy e2e.mp4
      - uses: actions/upload-artifact@v4
        with: { name: e2e-video, path: e2e.mp4 }

ローカルでも同じ思想で良い。ワンライナーをシェルに仕込み、録画開始・停止・アップロード・URL生成までを一気に流すと、チームの実効活用率が跳ね上がる。

# ローカル一発: 録画→停止→S3アップロード→URL出力
start(){ ffmpeg -y -f gdigrab -framerate 30 -i desktop -c:v h264_nvenc -b:v 6000k -c:a aac rec.mkv & echo $! > .pid; }
stop(){ kill $(cat .pid); ffmpeg -i rec.mkv -c copy rec.mp4; aws s3 cp rec.mp4 s3://bucket/path/; aws s3 presign s3://bucket/path/rec.mp4 --expires-in 3600; }

まとめ：動画を標準にする、今日から変わる

無料で即日導入できる選択肢だけで、画面録画の品質とガバナンスは十分に作れる。OS標準は最短、OBSは運用の均質化、FFmpegは自動化の土台と考え、チームの要件に応じて段階的に使い分ければ良い。説明を文字から動画へ移すだけで、認識合わせの往復は減り、意思決定は早くなる。あなたのチームにとって、最初の一本はどのシーンだろうか。バグ再現、仕様レビュー、オンボーディングのいずれでも構わない。今日このあと10分で一つ録画し、署名付きURLで共有してみてほしい。小さな実践が、明日のコミュニケーションを変える最短の一歩になるはずだ。