公開日: 2026 年 11 月 10 日
Policybazaar は、9, 700 万人以上の登録顧客を抱えるインド有数の保険プラットフォームです。顧客の約 80% が毎月ウェブサイトにアクセスしています。親会社の PB Fintech は最近、エンドツーエンドの退職計画プラットフォームである Pensionbazaar を立ち上げました。これは、Paisabazaar Marketing & Consulting Private Limited のブランドです。
どちらのチームもすでにコーディング エージェントを使用しています。コーディング エージェントはコードを迅速に作成しますが、そのコードがブラウザで何を行うかを確認することはできません。エージェントは古いウェブパターンに手を伸ばすことが多く、画面が正しくレンダリングされたかどうかを確認する方法がなかったため、エンジニアは依然としてすべてを手動で検証する必要がありました。
この問題を解決するため、両社は 2 つのツールを Agentic Workflows に組み込みました。Modern Web Guidance でモデルに最新のウェブ標準を学習させ、エージェント向け Chrome DevTools でエージェントにライブのヘッドレス ブラウザを提供して、作業を検査、検証できるようにしました。
影響は次のとおりです。
92%
Policybazaar の約 30 のランディング ページで手動監査の労力を削減
>90%
Pensionbazaar の新しいページの開発とテストの所要時間を約 4 日から数時間に短縮
>90%
新しい Pensionbazaar 画面で報告される UI バグが減少
課題: コードは高速、検証は低速
Policybazaar と Pensionbazaar は、標準の AI コーディング ワークフローでは本番環境レベルで最適化できない 2 つの異なるボトルネックに直面しました。
Pensionbazaar: QA サイクルが長い新しい画面
Pensionbazaar は、マルチステップの Retirement Freedom Score 計算ツール、カスタマイズ可能な投資費用の予測、自動化された推奨レポートなど、数十の新しい複雑な画面を必要としていました。チームは、コーディング エージェントと Figma MCP サーバーを使用してこれらを構築しましたが、2 つの問題により QA サイクルが長くなっていました。
まず、エージェントは暗闇の中でコーディングしていました。ベースモデルはコードを生成できますが、レンダリングされたインターフェースの確認、計算されたスタイルと設計仕様の比較、レイアウト シフトの検出、ネットワーク ウォーターフォールの読み取りはできません。そのため、UI のクリッピングやレイアウト シフトなどの関連する問題が、手動 QA まで残ってしまいました。
2 つ目は、生成されたコードが過去のものであることです。最新のウェブ プラットフォームを認識していないエージェントは、古い回避策に頼り、組み込みの <dialog> 要素を使用する代わりに、重い JavaScript モーダルを記述し、不要なポリフィルを追加し、fetchpriority などのパフォーマンス ヒントを省略しました。
Policybazaar: 30 のランディング ページと手動監査
Policybazaar の生命保険チームは、さまざまな保険商品向けに約 30 のランディング ページを運営しており、各ページにはさまざまなマーケティング キャンペーンのバリエーションがあります。これらのサイトには 1 日に 20 万～ 30 万人の訪問者があり、すべてのページで毎月デザインとビジネス ロジックの更新が行われます。チームは、Core Web Vitals のスコアを高く維持し、すべてのバリアントがアクセス可能で、すべての画面サイズで正しくレンダリングされるようにする必要があります。
自動化する前は、エンジニアが各ページを手動で監査していました。
- PageSpeed Insights を実行して、実際のユーザーデータを収集します。
- Core Web Vitals のスコアと推奨事項を評価します。
- 開発ビルドまたはステージング ビルドを検査し、スコアの背後にある問題を診断して、アプリケーション コードの修正を適用します。
このプロセスは時間がかかり、繰り返し作業が多く、スケーラビリティがありませんでした。最適化の見落とし、監査範囲の不整合、パフォーマンス低下の未検出、リリースの遅延などの余地が残されていました。
ワークフローを変更する前に、チームは 3 つの目標を設定しました。1 つ目は、監査範囲を継続的にしながら、パフォーマンス監査に費やすデベロッパーの時間を 80% 以上削減すること、2 つ目は、検証済みのレポートを使用して QA の所要時間を短縮すること、3 つ目は、画面がワイヤーフレームと一致しないために発生する UI バグを減らすことです。
解決策: コードから検証へのループ
Pensionbazaar は、コードの記述とチェックの間のギャップを埋めました。エージェントはコードを記述し、クリーンなブラウザ インスタンスを起動して、視覚的な同等性、レイアウトの破損、コンソール エラー、パフォーマンスをプログラムで監査し、人間の介入を最小限に抑えながら、検出された問題を修正します。エージェントは Figma MCP からデザインを取得し、レンダリングされたページとデザイナーの意図を比較します。
次の動画は、このループの動作を示しています。エージェントは、新しい画面の Figma デザインを読み取り、実装します。その後、エージェント向け Chrome DevTools を使用して、レンダリングされたページを検査し、見つかった差異を修正します。
ステップ 1: 最新のウェブ標準でエージェントをグラウンディングする
Pensionbazaar チームは、生成されたコードが最新のウェブのベスト プラクティスに沿い、最新のプラットフォーム機能を使用し、古いブラウザでも動作することを望んでいました。手動で確認するのは面倒であり、エージェントが常にプラットフォームの最新の状態になっているとは限りません。Modern Web Guidanceは、この問題を解決します。これは、Chrome とウェブ コミュニティのウェブ エキスパートが作成、管理しているエージェント スキルで、200 を超えるユースケースに対応しています。これにより、エージェントは最新のウェブ プラットフォーム API と、Baseline ターゲットに適合するパフォーマンスとユーザー補助のベスト プラクティスに沿って作業を進めることができます。ターゲットを設定しない場合、デフォルトはBaseline Widely Availableになります。
エージェントは、Figma ファイルからコンテキストを pull した後、コードを記述する際に Modern Web Guidance を使用します。Pensionbazaar の場合、これによりコードが次の 3 つの方法で変更されました。
- ネイティブ要素が JavaScript の回避策に置き換えられました。エージェントは、プランの詳細モーダルに組み込みの
<dialog>要素と Popover API を使用し、財務サマリー カードに CSS Grid と Flexbox を使用しました。 - エージェントは、ベースモデルでは通常省略されるパフォーマンス ヒントを追加しました。これには、ヒーロー LCP 画像の
fetchpriority="high"、スクロールしなければ見えない位置にあるプランカードのloading="lazy"、Interaction to Next Paint（INP）を保護するためのscheduler.yield()を使用した時間ベースの実行バジェットが含まれます。 - 最新の機能が古いブラウザを壊すことはありませんでした。Pensionbazaar は、Browserslist で定義されている古いブラウザ バージョンをサポートしています。このエージェントは、ワンタイム パスワード（OTP）フィールドで
:user-invalidCSS 疑似クラスやautoComplete="one-time-code"などの機能を使用しました。古いブラウザでは無視され、コア機能は引き続き動作します。
ベースモデルはそれほどかけ離れていませんでした。パフォーマンスについては、チームはベスト プラクティスと約 70% 一致していることを確認しました。エージェント自身のレポートには、残りのギャップを埋める 12 個の Modern Web Guidance ルールが記載されていました。4 つの例:
| 地域 | ベースモデルのギャップ | Modern Web Guidance ルール |
|---|---|---|
| 画像の読み込み | fetchpriority="high" と loading="lazy" の組み合わせなど、矛盾する組み合わせをハルシネーションした。 |
それらを組み合わせることを明示的に禁止し、優先度の高い画像を 1 ページあたり 1 つまたは 2 つに制限します。 |
| レイアウトの安定性 | パフォーマンスを考慮して content-visibility: auto を提案しましたが、contain-intrinsic-size は省略しました。 |
コンテンツのレンダリング時にレイアウトが大きくずれるのを防ぐには、2 つのプロパティをペアにする必要があります。 |
| メインスレッドの譲り | 期限パターンなしで scheduler.yield() を一般的に使用しました。 |
Interaction to Next Paint（INP）を保護するために、厳格な時間ベースの期限（performance.now() + 50）を適用します。 |
| Service Worker のキャッシュ保存 | オフライン フォームの送信が考慮されていなかった。 | Service Worker は GET 以外のリクエストをネイティブにキャッシュできないことをエージェントに警告します。 |
Pensionbazaar にとって、後で技術的負債を抱えないように、初日から高品質のコードを構築することが優先事項でした。Modern Web Guidance は、特定のブラウザ互換性ターゲットを尊重しながら、最新のウェブ標準とパフォーマンスのベスト プラクティスを採用するようにコーディング エージェントを誘導しました。これにより、フロントエンドのコードレビューが大幅に容易かつ迅速になり、最終的に開発の所要時間が短縮されました。
Policybazaar、エンジニアリング マネージャー、Aman Soni 氏
ステップ 2: エージェントにブラウザを提供する
エージェント向け Chrome DevTools は、MCP サーバー、CLI、エージェント スキルなどのツールのセットです。コーディング エージェントは、コンソールログ、ネットワーク トラフィック、ユーザー補助ツリー、その他の DevTools 機能などのランタイム デバッグデータにリアルタイムでアクセスできます。
チームは、コーディング エージェントである Claude Code にプラグインとしてエージェント向け Chrome DevTools をインストールしました。
# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
チームは、インストール済みの Chrome 拡張機能が結果に影響を与えず、個人データや機密データが漏洩しないように、すべてのテストをクリーンなブラウザ インスタンスで実行したいと考えていました。これを行うには、MCP サーバー構成の args 配列に --isolated を追加します。
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
テストで既存のログイン済みブラウザ セッションが必要な場合は、代わりに --autoConnect を使用します。
ステップ 3: エージェントに自身の作業を確認して修正させる
エンジニアリング チームは、エージェントの指示にチェックをリストします。これは、プロンプトまたはエージェント スキルとしてリストされます。大まかに言うと、エージェントは次の処理を行います。
- DOM ツリーと計算された CSS を検査し、Figma のデザインと比較します。
- ページをモバイル ビューポートにサイズ変更して、レスポンシブ性をテストします。
- パフォーマンス トレースを記録して、スクリプト、レンダリングを妨げるリソース、その他のパフォーマンスの問題によって発生する長いアニメーション フレーム（LoAF）を特定します。
- エンジニアがレビューする前に、コードを書き換えて、設計の不一致、パフォーマンスの問題、コンソール例外を修正します。
次の表に、各チェックをサポートするエージェント向け Chrome DevTools ツールを示します。
| 小切手 | ツール |
|---|---|
| ビューポート全体でレスポンシブ性をテストする | resize_page は、ページのウィンドウを明示的なサイズに変更します。emulate は、特定のデバイス環境をエミュレートします。take_screenshot は結果をキャプチャします。 |
| DOM と計算された CSS を Figma のデザインと比較する | take_snapshot は、ユーザー補助ツリーに基づいてページのテキスト スナップショットを返します。get_css_styles は、適用された CSS ルールを読み取ります。evaluate_script は、ページ内で JavaScript 関数を実行します。 |
| LoAF、レンダリングを妨げるリソース、Core Web Vitals の問題を見つける | click と drag は、インタラクションをエミュレートします。performance_start_trace と performance_stop_trace は、パフォーマンス トレースを記録します。performance_analyze_insight は、トレース内の分析情報の詳細な診断を返します。list_network_requests と get_network_request はネットワーク アクティビティを示します。lighthouse_audit は、SEO やユーザー補助など、パフォーマンス以外の領域を監査します。 |
エージェントは、小さな画面でテキストが切れている、フレックス ラップが破損している、最適化されていない画像がレイアウト シフトを引き起こしているなどの問題を見つけると、短い修正ループを実行します。
- エージェント向け Chrome DevTools が正確なエラーをキャプチャします。
- エージェントはデータを分析し、問題のある CSS または JavaScript を書き換えます。
- エージェントはページを再読み込みして、修正を確認します。
1 つの画面で、エージェントはページをレンダリングし、ヘッダーのレイアウト、間隔、グラデーションがデザインと一致していないことを確認しました。関連する .scss ファイルを修正しました。また、アコーディオンを展開して、開いた状態がデザインと一致していることを確認するなど、ページを操作しました。
ステップ 4: 検証済みのレポートを QA に渡す
検証が完了すると、エージェントは本番環境対応のコードと QA チーム向けの監査レポートを提供します。このレポートに含まれるデータは次のとおりです。
- スクリーンショット、DOM スナップショット、計算されたスタイルから構築された、ピクセルの違いをハイライト表示する Figma デザインとの視覚的な比較。
- さまざまな画面サイズでレンダリングされたページのスクリーンショット。
performance_start_traceとperformance_analyze_insightの Core Web Vitals とパフォーマンス診断（Speed Index や Total Blocking Time（TBT）など）。lighthouse_auditの SEO、ベスト プラクティス、ユーザー補助の Lighthouse スコア。- 行の折りたたみや切り替えなどのインタラクション、コンソール エラー、行の編集、行の削除、空の状態などのアプリケーションの状態変化のチェックに合格または不合格。
30 のキャンペーン ページに同じアプローチを適用
Policybazaar は、メイン プラットフォームで、PageSpeed Insights の手動実行を、Kiro のエージェント向け Chrome DevTools を介して実行される監査に置き換えました。キャンペーン ページが公開される前に、エンジニアがモバイルとパソコンのステージング URL に対して監査をトリガーします。エージェントはパフォーマンスと Lighthouse の監査を実行し、エージェント向け Chrome DevTools はラボデータとともに実際の Chrome ユーザー エクスペリエンス レポート（CrUX）のフィールド データを自動的に取得します。これにより、PageSpeed Insights のステップが完全に置き換えられました。
その後、エージェントはパフォーマンス スコア、検出されたボトルネック、エンジニアが修正すべき改善点の優先順位付きリストを報告します。あるプレリリース監査では、ページの読み込み中に次々と実行され、重要なレンダリング作業と競合する、重要でない API 呼び出しがフラグ付けされました。チームはページが公開される前に問題を修正しました。
エージェントは、エンジニアが 1 回のパフォーマンス監査を完了する時間内に 12 回のパフォーマンス監査を完了できるようになりました。手作業が 92% 削減されたことになります。
ウェブ パフォーマンスは、優れたユーザー エクスペリエンスを維持するために重要ですが、数十のランディング ページにわたって手動で監査し、ウォーターフォールとトレースを評価することは面倒で、大きなボトルネックになっていました。エージェント向け Chrome DevTools はこのプロセスを変革し、エンジニアのパフォーマンス監査時間を 92% 削減しました。これにより、エンジニアはより複雑なタスクに集中できるようになりました。
Policybazaar、エンジニアリング マネージャー、Aman Soni 氏
影響
Modern Web Guidance とエージェント向け Chrome DevTools により、Policybazaar と Pensionbazaar のフロントエンド テストは、手動で事後対応的なプロセスから、自動化された事前対応的なプロセスに変わりました。次の表に、変更前と変更後のワークフローの比較を示します。
| 地域 | 以前: 手動レビューとベースモデル | 変更後: Modern Web Guidance とエージェント向け Chrome DevTools |
|---|---|---|
| パフォーマンス監査の取り組み（Policybazaar） | エンジニアが PageSpeed Insights を実行し、Core Web Vitals を確認して、約 30 ページのランディング ページそれぞれに手動で修正を適用しました。 | 手作業を 92% 削減。エージェントは、エンジニアが 1 回の監査に必要とした時間で 12 回の監査を完了します。 |
| 監査の対象範囲（Policybazaar） | キャンペーン バリエーション全体で監査の対象範囲が不一致。 | キャンペーン ページのパフォーマンス テストのカバレッジが 100% に。 |
| 新しい画面のターンアラウンド（Pensionbazaar） | コードの入力からオーナー確認済みの画面が表示されるまで数日かかります。 | 数時間。90% 以上高速化。 |
| デザインの不一致に関するバグ（Pensionbazaar） | UI のクリッピングとレイアウト シフトが手動 QA に到達しました。 | UI のバグが 90% 以上減少しました。 |
92% の削減は、チームの目標である 80% 以上を上回りました。ランディング ページの回帰は、ステージングや QA に到達する前に検出されます。Pensionbazaar では、コードはすでに監査済みで、複数のビューポートのスクリーンショットが添付されているため、設計、エンジニアリング、QA の間のやり取りが削減されます。
チームにとっての重要ポイント
- 信頼できるガイダンスに基づいてエージェントをグラウンディングする。Modern Web Guidance などの厳選されたガイダンスにより、エージェントは古いパターンから遠ざかり、コードをベースライン ターゲット内に維持できます。
- レンダリングされたページを確認するまで、エージェントがフロントエンド タスクを完了としてマークしないようにします。エージェント向け Chrome DevTools を使用すると、エージェントは実際のブラウザでレイアウト、ビューポート、パフォーマンス トレースを検査できます。
- ループに明確な終了条件を指定する。エージェントがループしてトークンを浪費しないように、ステップ制限と明示的な合格 / 不合格条件を設定します。
- 更新頻度が高く、テンプレートを使用しているページから始めます。クローズドループ ワークフローは、ターンアラウンド スピードが重要な場合に最も効果を発揮します。
- クリーンなブラウザで監査を実行する。拡張機能やキャッシュに保存されたデータが結果に影響したり、個人データが公開されたりしないように、
--isolatedを使用します。