YouTube・ケーススタディ

ケーススタディ：WeTVの性能デバッグ自動化

元の資料：Case Study: WeTV — How WeTV cut performance debugging time by 87% using Chrome DevTools for agents and Modern Web Guidance
2026年11月10日（Chrome for Developers ブログ）

このページには実際に動く作例があります。

Tencentの国際向け動画配信WeTVが、リリースの性能チェックの失敗を、CI/CDの中でエージェントに診断と修正まで任せた事例です。

現場

動画が中心のサイトでは、性能が視聴の継続、検索での表示、再生の滑らかさを左右します。WeTVのCI/CDはリリースごとに性能トレースを取り、CLS（レイアウトのずれの累積）を0.1以下に保つ決まりでした。ただ、チェックに落ちたあとの原因探しは手作業で、Chromeを開いてトレースを取り、動いた要素を特定し、エディタに戻って直し、再確認する、という一周に約4時間かかっていました。

やったこと

マージリクエストの流れの中にエージェントを置きました。Chrome DevTools for agentsが実際のChromeでページを見て「何が壊れたか」を伝え、Modern Web Guidanceが「どう直すのが今の標準か」を決めます。

運用の要点は、エージェントに即興させないことです。使われているプロンプトは、まず診断し、原因を確定してから直すこと、CLSの犯人の特定には専用の分析（CLSCulprits）を使って要素とタイミングとスコアを出すこと、並行する担当エージェントは触るファイルの範囲を分けること、直したら同じトレースで確かめてCLS 0.1未満を確認すること、までを手順として固定しています。

実例：再生ページのレイアウトのずれ

あるマージリクエストで、デスクトップの再生ページのCLSが0.39（上限0.1の約4倍）でした。原因は動画プレーヤーです。サーバ側で描画されるプレーヤーの入れ物に高さの予約がなく、クライアント側で組み立て直されたときに高さが広がり、周囲がずれました。

直し方は、サーバ側の描画の時点で場所を予約することでした。ガイドを引いてエージェントが書いたCSSがこれです。

.play__block--player .play__aside--left {
  inline-size: 100%;
  block-size: auto;
  aspect-ratio: 16/9;
}

作例：場所の予約の有無

直したあと、パイプラインが再ビルドし、同じトレースを取り直します。CLSが0.1を下回って初めて、人のレビューに進みます。

結果

他のチームへの教訓として挙げられていること

• エージェントは、失敗が起きる場所（マージリクエスト）で起動する。人が落ちたチェックに気づいて手で始める形にしない。
• 直す前に診断させる。トレースと犯人の名指しが先にあると、症状への当て推量の修正にならない。
• 実行時のデータを標準と組にする。トレースは「どの要素が動いたか」、ガイドは「どの直し方が今の作法か」を担う。
• 証拠を要求する。落ちたのと同じトレースの取り直しが、直ったことの証拠になる。
• 人は輪の中に残す。エージェントが調べ、チェックを通ったパッチをエンジニアがレビューする。

「速度と質の両方で、結果はとても効果的でした。複雑なレイアウトの問題を直すうえで、信頼できる参照になりました。修正のたびに厳密な確認を行っており、成功率と安定性のおかげで、リリースへの自信が大きく上がりました。」— Yangjie Zheng（Head of Engineering, WeTV）※発言の要旨