公開日: 2026 年 11 月 10 日
WeTV は、Tencent の国際的な動画ストリーミング プラットフォームです。東南アジアをはじめとする世界中の視聴者に、ドラマシリーズ、アニメ、バラエティ番組を配信しています。動画を中心に構築されたサイトでは、パフォーマンスによって、視聴者がサイトに留まるかどうか、検索エンジンがコンテンツを表示するかどうか、再生がスムーズに感じられるかどうかが決まります。
WeTV のウェブ エンジニアリング チームは、パフォーマンス目標を達成できないコードをリリースしません。長い間、この基準を維持するには、デベロッパーはビルドがチェックに失敗するたびに、作業を中断して Chrome を開き、ページを手動でプロファイリングする必要がありました。1 つの回帰を追跡して修正するのに約 4 時間かかりました。
現在では、AI コーディング エージェントが CI / CD パイプラインの一部としてその作業を行っています。エージェント向け Chrome DevTools を使用して、エージェントはライブ ブラウザでページを検査します。Modern Web Guidance を使用すると、現在のウェブ プラットフォーム標準に沿った修正が作成されます。現在、このワークフローは、失敗したパフォーマンス テストの 90% を自動的に診断して解決します。チェックの失敗から修正の検証までの時間は、完全なビルドと手動評価を含めて、4 時間から 30 分に短縮されました。
課題: エディタとブラウザの間で立ち往生するデベロッパー
WeTV のエンジニアは、すでに IDE で AI コーディング ツールを使用していました。これらのツールはコードを記述することはできましたが、ブラウザで実行されたコードの動作を確認することはできませんでした。そのため、作業は 2 つに分割されました。エンジニアはエディタでコードを記述し、Chrome に切り替えてデプロイ、検査、検証を行います。修正するたびに、そのループを手動で繰り返す必要がありました。
この分割は、リリースゲートで最も大きな影響を及ぼしました。WeTV の CI / CD パイプラインは、リリースごとにパフォーマンス トレースを実行し、Cumulative Layout Shift（CLS）を 0.1 以下に抑えています。ビルドがそのラインを超えると、パイプラインはフラグを立てましたが、原因の特定は手動で行う必要がありました。エンジニアは、Chrome DevTools を開き、トレースを記録し、移動した要素を見つけて、その結果をエディタに戻し、修正を記述して、再度チェックを実行する必要がありました。1 つの CLS 回帰に約 4 時間のエンジニアリング時間がかかりました。
チームは、実行中のページを確認し、既知の標準に合わせてコードを修正するという、両方の作業を処理できるエージェントを必要としていました。
解決策: エージェントをブラウザとウェブ標準に接続する
WeTV は、パフォーマンス検証をマージ リクエスト（MR）フローに移行しました。開発者が MR を開くと、CI / CD パイプラインが環境を起動し、AI コーディング エージェントがローカルで実行されます。このエージェントには、チームの IDE ツールに欠けていた 2 つの機能があります。
- エージェント向け Chrome DevTools: Model Context Protocol（MCP）サーバーを実行し、エージェントをライブ Chrome インスタンスに接続します。エージェントは、パフォーマンス トレースを記録し（他の Chrome DevTools 機能も使用可能）、デベロッパーが DevTools で行うのと同じように、フロントエンド コードが実際にどのようにレンダリングされるかを確認できます。
- Modern Web Guidance: ウェブ プラットフォームのベスト プラクティスとブラウザの互換性データを含むエージェント スキル。これにより、エージェントは以前のパターンから離れ、最新のウェブ プラットフォーム機能に基づいて構築された修正に移行します。
エージェント向け DevTools は、何が壊れたかをエージェントに伝えます。Modern Web Guidance は、その修正方法を形作ります。
実際の例: エピソード再生ページでのレイアウト シフト
あるマージ リクエスト中に、エージェントはデスクトップ エピソード再生ページで performance_start_trace ツールを実行しました。トレースでは、CLS が 0.39 と記録されました。これは、上限の 0.1 のほぼ 4 倍です。
編集する前に診断するようにエージェントに指示する
WeTV では、エージェントが即興で対応することはできません。ワークフローを駆動するプロンプトは、コードに触れる前に問題を診断し、モデルがデフォルトで生成する内容に依存するのではなく、Modern Web Guidance と照合して調査結果を確認するように指示します。
WeTV チームが使用したプロンプトの例を次に示します。
Context:
"The CLS (Cumulative Layout Shift) of this page needs inspection. Diagnose
first, then modify the code, do not guess."
Mandatory Execution Steps:
1. Performance Trace: Use Chrome DevTools for agents to run performance traces
on both Desktop and Mobile views.
2. Identify Culprits: Use CLSCulprits insight to pinpoint the exact DOM elements
causing shifts (capture class/id, timing, and score).
3. Use web best practices for performance and CSS to optimize CLS.
4. Multi-Agent Parallelism: Enable parallel agents for efficiency:
- Agent A: Investigate Player/Main Layout SSR placeholders.
- Agent B: Investigate Sidebar Ads, VIP buttons, Tabs, and late-injected
lists.
- Agent C: Investigate Fonts and other minor factors.
Constraint: Each agent modifies only files within its scope to prevent
conflicts.
5. Root Cause Confirmation: Confirm the root cause before applying fixes.
Prioritize reserving space over changing interaction semantics just to fix
CLS.
6. Verification: After modification, re-test CLS via equivalent CSS injection
or local build. Target: CLS < 0.1.
このプロンプトの 2 つの部分が、ほとんどの重みを担っています。「まず診断してからコードを修正する」ことで、エージェントが症状にパッチを適用するのを防ぎます。ステップ 2 では、エージェントが insightName: 'CLSCulprits' で performance_analyze_insight を使用するように指示します。これにより、一般的な疑いではなく、正確な要素、タイミング、スコアが報告されます。
次の動画では、プロンプトが実行されると、エージェントは Modern Web Guidance で関連するガイドを検索し、CLS に関連する最新のウェブ機能を使用して修正を実装します。また、エージェント向け Chrome DevTools を使用して Chrome ブラウザ インスタンスを開き、パフォーマンス トレースを記録します。
このランタイム診断と構造化されたガイダンスの組み合わせにより、複雑なレイアウト シフトの自動修正が可能になります。自動ワークフローによって修正された問題の例を次に示します。
根本原因を特定する
トレースは動画プレーヤーを指していました。WeTV はサーバー上でプレーヤーをレンダリングしますが、プレーヤーのコンテナはプレーヤーの高さを予約していませんでした。クライアントがページをハイドレートすると、コンテナの高さが拡大し、周囲のコンテンツが移動しました。
標準ベースの修正を適用する
この問題を解決するには、サーバーサイド レンダリング中にスペースを予約して、ハイドレーションの前にコンテナが適切な高さになるようにします。以下は、エージェントが Modern Web Guidance の css-layout ガイドを参照して作成した修正の例です。
.play__block--player .play__aside--left {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16/9;
}
エージェントが CSS を適用した後、パイプラインがページを再ビルドし、エージェントが同じトレースを再度実行しました。CLS が 0.1 未満になった場合にのみ、パッチは人間によるレビューに進みました。
影響: リリースの迅速化とレイアウトの安定化
WeTV は、エージェント向け Chrome DevTools と Modern Web Guidance を CI / CD ワークフローに追加したことで、エンジニアリング効率とレイアウトの安定性を大幅に向上させました。
- エンドツーエンドのデバッグと解決にかかる時間を 87% 短縮（4 時間から 30 分に短縮）。
- 繰り返されるパフォーマンスの低下の 90% が自動的に診断され、解決されます。
エンジニアがプロファイリングに半日を費やすことはなくなりました。ビルドがしきい値を超えると、エージェントはトレースを読み取り、修正を書き込み、テストして、検証済みのパッチを人間のレビュアーに渡します。最終的な判断は人間が行いますが、失敗したチェックにすでに合格している修正から開始します。
CLS の回帰はマージ リクエスト内で修正されるため、本番環境に到達することはありません。これにより、ページは 0.1 の目標値を下回り、WeTV の検索での視認性が保護され、サイクルの後半でリリースをブロックする一般的な理由が排除されます。
チーム向けのレッスン
WeTV の設定はスタックに固有のものですが、その背後にあるパターンは、パフォーマンスに基づいてリリースを制限するほとんどのチームに引き継がれます。
- 障害が発生した場所でエージェントを実行します。WeTV はマージ リクエストからエージェントをトリガーするため、チェックの失敗に気づいて手動でセッションを開始する必要はありません。
- エージェントに編集前に診断させる。最初にトレースと原因の特定を求めることで、推測ではなく、実際の要素を対象とした修正を生成できます。
- ランタイム データを標準と組み合わせる。トレースは、移動した要素をエージェントに伝えます。Modern Web Guidance は、現在のプラットフォームの慣行に沿った修正方法を伝えます。
- 証明を要求する。失敗したトレースを再実行すると、修正が機能していることを示すエージェントの証拠になります。P2ER は、必須の経験的検証ルールでも同じ原則に従っています。
- 人間参加型にします。エージェントが調査を行い、エンジニアはチェックに合格したパッチを確認します。
フィードバックと今後の計画
WeTV は、エージェント向け Chrome DevTools のライブ ランタイム テレメトリと、Modern Web Guidance の標準化されたルールを組み合わせることで、手動のパフォーマンス分析をリリース プロセスから排除し、エージェントのコード変更を現在のウェブ プラットフォーム標準に準拠させることができました。
「スピードと品質の両面で、非常に効果的な結果が得られています。エージェント向け Chrome DevTools と Modern Web Guidance が提供する診断的インサイトは、複雑なレイアウトの問題を修正するための信頼できるリファレンスとなりました。修正のたびに厳格な検証を行っており、現在の成功率と安定性により、リリースの信頼性が大幅に向上しています。」
—Yangjie Zheng 氏、WeTV（Tencent）エンジニアリング責任者
次に、WeTV のエンジニアリング チームは、今後のコードリリースで、エージェント向け Chrome DevTools とモダンウェブ ガイダンスをエンドツーエンドのテストに導入する予定です。
リソース
同様のワークフローを設定するには、次のリソースをご覧ください。