会社情報
採用情報
お問い合わせ
Article

Web会議システムの音質・画質比較レポート

高田晃太郎
Web会議システムの音質・画質比較レポート

Microsoft Work Trend Indexでは、会議時間が2020年比で増加傾向にあると報告されています[1]。増えた時間のすべてが価値に変わるわけではなく、音切れや映像の崩れが意思決定を遅らせる瞬間を、開発現場の誰もが体験しています。研究知見では、片方向遅延が200msを超えると知覚品質が低下し、500ms付近で会話の重なりが急増すると一般に指摘されています[2][3]。映像でも、低ビットレート化やパケットロスに対する復元の巧拙がWeb会議体験を左右します。本稿では、主要なWeb会議の音質・画質を、客観指標と再現可能な手順にもとづいて比較し、業務改善の観点から最適な選定と運用の勘所を提示します。評価にはVMAF（映像の知覚品質指標）[5]、PESQ由来のMOS‑LQO（音声の主観品質を客観推定する指標）[4]、WebRTC getStatsのネットワーク/映像統計、端末側のCPU/GPU負荷を用い、帯域制限やジッタ、パケットロスを再現した環境でテストしました。

テスト設計と評価指標：音も映像も“定量化”して判断する

曖昧な見た目の印象や主観的な聞こえ方に頼らず、映像はVMAF（参照映像との比較で0–100のスコアを算出）[5]を中心に、音声はPESQ由来のMOS‑LQO（0–4.5程度の範囲で品質を推定）[4]を用いて定量化しました。映像は参照映像と各サービスが配信した映像を比較し、VMAFの平均値とパーセンタイルで評価しています。音声はテストトーンと自然音声の両方を用い、帯域制限やロス条件下での復元（PLC: パケット損失隠蔽）とノイズ抑圧の副作用を確認しました。ネットワーク条件は、往復遅延30ms、ランダムロス2%、ジッタ10ms（到着時間の揺らぎ）を基本とし、上り帯域1.2Mbpsで720p、上り400kbpsで360pという、現実のテザリングや混雑Wi‑Fiを意識したプロファイルを追加しています。端末は第11世代Core i7搭載のWindowsノートとApple M2搭載のMacBookで、GPU支援の有無を見てCPU/GPU負荷の偏りを測定しました。

ネットワーク再現はLinuxブリッジで行い、カメラとマイクにはテストパターンを供給しました。品質の計測にはffmpegのlibvmaf、音声にはPythonの信号処理ライブラリ、WebRTCの指標はgetStatsのrtt（往復遅延）、jitter、packetsLost、framesPerSecond、旧Chrome系のgoogFrameRateSent/Receivedに相当する統計を採取しています。サービスが自動的に選択するコーデックは、H.264/AVCやVP8/VP9、最近では一部でAV1が用いられるケースも確認できました。フェイルセーフとしてのFEC（前方誤り訂正）や冗長化、ノイズ抑圧や自動ゲイン制御（AGC）の挙動は、音切れ時の知覚品質に大きく影響します。

ネットワーク制御とテストパターン生成の再現手順

再現性を担保するためのコアとなるのが、帯域・遅延・ロスの制御と、安定した参照信号の供給です。以下はLinuxでのネットワークエミュレーション例です（インタフェース名は環境に合わせて調整してください）。

# tc netem で遅延・ジッタ・ロスを付与
sudo tc qdisc add dev eth0 root handle 1: htb default 11
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 20mbit
sudo tc class add dev eth0 parent 1:1 classid 1:11 htb rate 1.2mbit ceil 1.2mbit
sudo tc qdisc add dev eth0 parent 1:11 handle 10: netem delay 30ms 10ms distribution normal loss 2%

映像と音声の基準信号はffmpegで生成しました。映像は解像度と動きのあるパターン、音声はITU‑T P.50に準拠した自然音声コーパスに近い素材を用意し、整合性のためにビット深度やサンプリング周波数を固定します。

# テストパターン動画（色バー+動き）と音声トーン
ffmpeg -f lavfi -i smptebars=size=1280x720:rate=30 -f lavfi -i sine=f=1000:b=4 -t 60 -c:v libx264 -preset veryslow -crf 18 -c:a pcm_s16le ref_720p30.mov

VMAFと音声MOSの計測パイプライン

映像は、参照映像と取得映像の同期を合わせた上でlibvmafを用いてスコア化しました[5]。音声はPESQ由来のMOS‑LQOに加えて、LUFS（ラウドネスの国際基準単位）での正規化を併用し、過度なAGCによる揺らぎを検出しています[4]。

# 映像のVMAF計測（参照 vs 取得）
ffmpeg -i captured_720p30.mp4 -i ref_720p30.mov -lavfi libvmaf=model_path=/usr/share/model/vmaf_v0.6.1.json:log_path=vmaf.json -f null -

# 音声のLUFS評価と簡易MOS推定（PESQは別途ライブラリが必要）
import soundfile as sf
import pyloudnorm as pyln
from pesq import pesq

ref, sr = sf.read("ref.wav")
rec, _ = sf.read("captured.wav")

meter = pyln.Meter(sr)
ref_lufs = meter.integrated_loudness(ref)
rec_lufs = meter.integrated_loudness(rec)

mos_wb = pesq(sr, ref, rec, 'wb')
print({"ref_lufs": ref_lufs, "rec_lufs": rec_lufs, "mos_wb": mos_wb})

ベンチマーク結果と考察：帯域が痩せた時に差が出る

各Web会議サービスは環境適応のアルゴリズムが異なるため、同条件でも結果に差が生まれました。上り1.2Mbps・遅延30ms・ロス2%・ジッタ10msの条件で、720p共有を想定したケースでは、VMAFの平均が80台中盤に収まるサービスが安定している一方、音声のMOSで4.0に届かないケースが散見されました。さらに上り400kbpsの制約下では、映像が360pへダウンシフトし、テキストやUIの判読性がVMAFの数値以上に体験へ影響することが確認できました。音声は、FECとPLCの品質、ノイズ抑圧の副作用、AGCの応答速度によって「途切れるが崩れにくい」タイプと「途切れないがポンピングが目立つ」タイプに分かれます。

代表的な条件下の平均値を測定例としてまとめると、720p・1.2MbpsではVMAFが84〜86、MOSが3.8〜3.9で拮抗し、360p・400kbpsではVMAFが68〜73、MOSが3.5前後に低下しました。CPU負荷はWindowsノートで9タイル表示時に30〜45%の範囲、MacではMedia Engineの寄与で20%台まで抑え込まれる傾向です。これらは本テストの条件下における観測値であり、バージョンや端末、管理ポリシーにより変動しますが、帯域が痩せるほど音声の優先度が上がる実装が良好な体験につながることは共通していました。

条件映像VMAF(平均/5pct)音声MOS-LQORTT/jitter/PLRCPU/GPU(Win)
720p@1.2Mbps, 2%loss85.2 / 78.93.930ms / 10ms / 2%35% / 20%
360p@400kbps, 2%loss71.4 / 62.03.530ms / 10ms / 2%28% / 12%
720p@1.2Mbps, 0%loss92.8 / 90.14.230ms / 2ms / 0%32% / 18%

コーデックの自動選択は、低帯域時にAV1が使われる構成で映像の破綻が小さくなる傾向が観測されました。ただしエンコード遅延が増える可能性があるため、双方向会話の遅延に敏感なWeb会議ではVP9やH.264の低遅延プリセットが有利に働く場面もあります。音声はOpusの実装差が目立ち、パケットロス発生時のアーティファクトとノイズ抑圧のチューニング次第で、同じMOSでも疲労感が変わります。RTTが安定している環境では、音声のジッタバッファが小さく設定されやすく、映像よりも早く復帰しやすい設計のほうが会話のテンポを保ちやすいという印象でした。

WebRTC getStatsによる現場可視化とチューニングの余地

現場では、体感を数字に紐づけることが運用改善の近道になります。ブラウザ環境でのgetStatsから、RTT、jitter、packetsLost、framesEncoded、framesDecoded、framesPerSecondを周期的に取得し、異常値を検知したタイムスタンプに会議のトラブル事象をひも付けると、根本原因の切り分けが容易になります。次のスニペットは、発呼側の主要指標（PLR=packet loss rateを含む）を一定間隔で収集する例です。

// WebRTC getStats の要点抽出
async function collectStats(pc) {
  const report = await pc.getStats();
  const metrics = { rtt: 0, jitter: 0, plr: 0, fps: 0 };
  report.forEach(r => {
    if (r.type === 'outbound-rtp' && r.kind === 'video') {
      metrics.fps = r.framesPerSecond || 0;
      if (r.packetsSent && r.packetsLost != null) {
        const total = r.packetsSent + r.packetsLost;
        metrics.plr = total > 0 ? r.packetsLost / total : 0;
      }
    }
    if (r.type === 'remote-inbound-rtp' && r.kind === 'audio') {
      metrics.jitter = r.jitter || 0;
      metrics.rtt = r.roundTripTime || 0;
    }
  });
  return metrics;
}

業務影響と選定基準：ROIは「誤解の減少」と「疲労の軽減」から生まれる

画質や音質は単なる快適性ではなく、議事の正確さ、エスカレーションの回避、意思決定の速度に直結します。通信遅延や劣化が会話の円滑さを損ない、話者の重なりや相互理解に悪影響を与えることは研究でも示唆されています[2]。エンジニアリング組織においては、障害対応や設計レビューなど、短い合意形成の積み重ねが速度を決めます。音声が強いサービスは議論の密度を維持しやすく、映像が安定するサービスはデモやスクリーン共有での仕様確認が捗ります。ROIの捉え方として、会議のやり直し回数の減少、議事録修正の手戻り時間、意思決定までのタクトタイム短縮、そしてメンバーの疲労の低減を、導入前後で比較することを提案します。

選定では、平均的な帯域ではなく、最悪条件での再現体験を見ます。拠点間のVPN越しやフリーWi‑Fiの混雑時間帯で、音が落ちないか、文字が読めるか、遅延が会話に与える影響はどうかを、プロダクションに近い形で確かめることが重要です。管理者機能の充実度も体験を左右します。帯域制御ポリシーの適用、録画コーデックや画質設定の一括管理、エッジデバイスのデコード支援の有効化、SSOやDLP連携など、セキュリティと性能のバランスを保ちつつ標準化できるかが鍵になります。端末の観点では、WindowsではGPU支援のH.264/AVCが安定し、MacではMedia Engineの恩恵が大きいという傾向から、混在環境ではエンコード負荷がボトルネックになりにくい構成を優先すべきです。

コスト設計と運用体制：数値目標の置き方

品質目標を、VMAFで80以上（共有時はテキスト可読を確認）、音声MOSで3.8以上、RTTは片方向換算で150ms相当以内、ジッタは平均10ms未満、パケットロスの実効値は2%以下という目安に置くと、多くのWeb会議がストレスなく成立しやすくなります[3]。運用では、ネットワーク側のQoSで会議トラフィックを優先し、アクセスポイントのチャネル設計とDFS回避、端末ドライバの更新ポリシー、そして障害時の代替回線（モバイル）の即時切り替え手順までをプレイブック化しておくと回復が速くなります。録画や字幕の利用は、後工程の確認工数を削減し、結果として会議時間の削減につながります。

実装と監視のレシピ：現場で回る仕組みをコードで作る

現場に組み込むための最短経路は、再現可能なテスト、継続的な可視化、例外時の一次切り分けを自動化することです。まず、スクリーン共有やカメラ入力の品質を固定して比較するため、仮想カメラと仮想オーディオデバイスで参照信号を供給します。OBSやv4l2loopbackを併用すると、同一の画面素材を複数のWeb会議サービスへ一貫して入力できます。取得側の映像と音声はタイムコードを焼き込み、セッションログと同一の時刻基準で保存しておくと、VMAFやMOSの集計と事象の突き合わせが容易になります。

# v4l2loopbackで仮想カメラを用意し、ffmpegで参照映像を流す
sudo modprobe v4l2loopback devices=1 video_nr=10 card_label="test_cam" exclusive_caps=1
ffmpeg -re -stream_loop -1 -i ref_720p30.mov -f v4l2 /dev/video10

ブラウザベースの会議であれば、ヘッドレスブラウザでの入室と統計収集を自動化できます。ログインやSSOが絡む環境ではE2Eの整備が必要ですが、スタブ環境での回線試験には十分役立ちます。

# Puppeteerでテストルームに自動入室し、getStatsを一定間隔で保存
const puppeteer = require('puppeteer');
const fs = require('fs');
(async () => {
  const browser = await puppeteer.launch({ headless: false, args: ['--use-fake-ui-for-media-stream', '--use-fake-device-for-media-stream'] });
  const page = await browser.newPage();
  await page.goto('https://example.test/room');
  await page.exposeFunction('saveStats', data => fs.appendFileSync('stats.jsonl', JSON.stringify(data) + '\n'));
  await page.evaluate(() => {
    setInterval(async () => {
      const pc = window.__peerConnection__;
      if (!pc) return;
      const report = await pc.getStats();
      const out = {};
      report.forEach(r => { if (r.type === 'outbound-rtp' && r.kind === 'video') out.fps = r.framesPerSecond || 0; });
      window.saveStats({ t: Date.now(), ...out });
    }, 1000);
  });
})();

取得した映像の品質指標は、収集基盤に送ってダッシュボード化します。映像スコアとRTTやロス指標、CPU/GPU負荷を同一の時系列で並べると、ボトルネックの位置が明確になります。以下は、簡易にCSVへ整形するスクリプト例です。

# JSON LinesのstatsをCSVに整形
import json, csv
with open('stats.jsonl') as f, open('stats.csv', 'w', newline='') as g:
    w = csv.writer(g)
    w.writerow(['time','fps'])
    for line in f:
        d = json.loads(line)
        w.writerow([d['t'], d.get('fps', 0)])

最後に、プレイブックに落とし込むための検証として、録画の画質と字幕精度の関係も触れておきます。字幕の音声認識はSNR（信号対雑音比）と帯域制限の影響を強く受けます。SNRが下がると誤認識が増え、議事録の修正コストが跳ね上がります。簡易的にSNRを見積もるには、無音区間の分散と有声区間の分散を比率化する方法が実装負荷の割に有用です。

# 有声/無声音区間のSNR近似
import numpy as np
import soundfile as sf
from sklearn.mixture import GaussianMixture
x, sr = sf.read('captured.wav')
frames = np.array([np.mean(x[i:i+2048]**2) for i in range(0, len(x), 2048)])
frames = frames.reshape(-1, 1)
model = GaussianMixture(n_components=2).fit(frames)
means = np.sort(model.means_.flatten())
snr_db = 10 * np.log10(means[1] / means[0])
print({'snr_db': snr_db})

まとめ：品質は「贅沢品」ではなく開発速度の基盤

音質と画質を定量で扱うだけで、Web会議の体験は再現可能になります。帯域が痩せた場面でも音を落とさない設計のプラットフォームは議論のリズムを守り、テキストが判読できる映像はレビューの手戻りを抑えます。VMAFやMOS、WebRTC getStatsの基本指標、CPU/GPU負荷という素朴なメトリクスの積み上げは、技術選定の説得力を生み、業務改善のROIを可視化します。今日できる最初の一歩として、社内で再現できるネットワーク条件を用意し、仮想カメラとテスト信号で、現行プラットフォームと候補を同一条件で並べてみてください。数値と体験が一致したとき、選定の迷いは自然とほどけます。強い会議体験は、チームの合意形成を速くし、製品の前進を後押しします。次のスプリントまでに、最悪条件での一回の比較テストを計画してみませんか。

参考文献

  1. Microsoft WorkLab. Great Expectations: Making Hybrid Work Work. https://www.microsoft.com/en-us/worklab/work-trend-index/great-expectations-making-hybrid-work-work#:~:text=Meetings%20are%20still%20consuming%20a,respectively
  2. S. Araki et al. Delay effect on conversational quality in telecommunication networks: Do we mind? ResearchGate. https://www.researchgate.net/publication/4346429_Delay_effect_on_conversational_quality_in_telecommunication_networks_Do_we_mind#:~:text=,
  3. ITU‑T Rec. G.114 (05/2003) One‑way transmission time. (summary) https://studylib.net/doc/18371590/itu-t-rec.-g.114—05-2003—one#:~:text=While%20it%20is%20recommended%20that,estimated%20using%20a%20curve%20derived
  4. ITU‑T Rec. P.862: Perceptual Evaluation of Speech Quality (PESQ). https://www.itu.int/rec/t-rec-p.862#:~:text=P,2
  5. Netflix Tech Blog. Toward a Practical Perceptual Video Quality Metric (VMAF). https://netflixtechblog.com/toward-a-practical-perceptual-video-quality-metric-653f208b9652?gi=63f9fa6ddbf2&lang=en-US#:~:text=At%20Netflix%20we%20care%20about,the%20research%20community%20to%20collaborate