はじめに
2026年1月、特定コンテンツへのアクセス集中により、レスポンス遅延が発生。再発防止のため、全コンテンツ実行画面のパフォーマンス調査が必要になりました。 しかし、手動でChrome DevToolsを開いて、遷移ごとにAPIを記録し、スプレッドシートにまとめる作業は膨大な時間がかかりますし、あまりやりたくない仕事です。
そこで、Claude Code と Playwright MCP を組み合わせ、AIに「画面を操作しながらの自動計測」を任せたところ、驚くほど詳細なレポートが爆速で仕上がりました。
活用したツールスタック
- Claude Code: ターミナルで動作するAIエージェント
- Playwright MCP: Claudeがブラウザを操作するための拡張機能
- VSCode: コード確認・プロンプト微調整用
AIへの「無茶振り」プロンプト
実際に投げたプロンプトの構成です。
プロンプト例:
特定の動的コンテンツのレスポンスが悪いため、画面遷移ごとのAPI処理時間を測定し、改善ポイントを洗い出してください。
Playwright MCPを使って実際にページを操作し、以下のURLから最後までフローを実行してください。
結果は、APIごとのレスポンス時間を含むMarkdown形式のレポートで出力してください。
対象URL: https://staging.example.com/interactive-content?id=12345
作業の目的、実際にやること、それに必要な情報を与えて実行します。
爆速で生成された調査レポート（サンプル）
AIが実際に画面を叩いて、ネットワーク通信を傍受して作成したレポートがこちらです。（※一部情報を伏せています）
1. 計測概要
- 計測対象: インタラクティブ・コンテンツのユーザーフロー
- 対象フェーズ: コンテンツTOP → コンテンツ実施 → 結果表示
- 環境: ステージング環境
- 計測手法: Playwright MCPによるブラウザ操作およびネットワークログ解析
2. フェーズ別レスポンス計測結果
AIが各画面遷移における「体感速度」と「裏側で走っているAPI数」を自動集計しました。
| フェーズ | ユーザー操作 | 遷移時間 | API数 | 主なボトルネック |
|---|---|---|---|---|
| Phase 1 | TOPページ表示 | 1,894ms | 5回 | 初期情報取得API (958ms) |
| Phase 2 | コンテンツ開始 | 2,433ms | 5回 | 設問データ取得 (1,358ms) |
| Phase 3 | 回答・結果表示 | 3,803ms | 8回 | 回答登録POST (1,130ms) |
3. API詳細分析（ワースト5）
全18回のAPIコールのうち、改善優先度が高いものをAIが自動抽出しました。
| APIエンドポイント（仮称） | 処理時間 | メソッド | 備考 |
|---|---|---|---|
| /api/v1/get-scenario | 1,358ms | GET | 全フロー中で最遅。データ量に起因か。 |
| /api/v1/submit-answer | 1,130ms | POST | DB書き込みを伴うため、負荷耐性の確認が必要。 |
| /api/v1/get-result | 1,169ms | GET | 結果計算ロジックの最適化余地あり。 |
| /api/v1/get-config | 119~462ms | GET | 1フロー中に9回呼び出しされており非効率。 |
| /api/v1/verify-license | 260~328ms | GET | セッション内で3回重複呼び出しを確認。 |
4. AIによる改善提案
計測結果に基づき、AIがエンジニア視点で以下の最適化案を提示しました。
1. 共通設定API（get-config）のキャッシュ化
現状、1フローで9回呼び出されています。クライアントサイドでのメモリキャッシュ、または1回のバッチ取得に統合することで、計1.5秒程度のオーバーヘッドを削減可能です。
2. 設問データのプリフェッチ（先読み）
TOPページ表示中（Phase 1）に、裏側でPhase 2の設問データを読み込んでおくことで、ユーザーの体感待ち時間をほぼゼロにできます。
3. リクエストの並列化
Phase 3において、「結果取得」と「解説取得」のAPIが直列で呼ばれています。これを並列実行（Promise.all等）に変更することで、画面表示を約0.8秒高速化できる可能性があります。
困ったこと
Playwright MCPが起動するブラウザは、プロキシ認証やBASIC認証など、一部手動での補助が必要な場面はあります。これを乗り越えることができれば、E2Eテストの自動化が進むのだが、解決策を見出せていない。
ケースによっては画面操作が複雑でPlaywright MCPでは処理できない場合がありました。その場合は、初めにレポジトリの該当ソースコード部分を参照させ、操作方法を理解させておくと、画面操作がスムーズに進む場合が多いです。
結論
Playwright MCPを使うメリット
- 複雑な操作が必要な画面でも、AIがソースコードを読んで勝手に操作を完了してくれます
- ログをコピペして整形する手間がゼロになります
- 単なる数値報告ではなく、改善の優先順位まで提案してくれるため、そのまま設計作業に進められています
Playwrightは単なるテスト自動化ツールだと思っていたのですが、このような測定情報を集計できると、開発ツールとして重宝します。
Chrome Devtools MCPも使える（機能が多い）と聞いているので、そちらと比較検証もしてみたいです。