公開日: 2026 年 6 月 22 日
デジタル ソリューション エージェンシーの P2ER は、Chrome DevTools for agents を使用して、検証済みの動作するソフトウェアのみが最終レビューのために人に渡されるようにしています。ワークフローをエージェント インフラストラクチャに変換することで、AI エージェントが経験的な UI 検証を実行できるようになり、デプロイ頻度が週 1 回から 1 日に複数回に増加しました。
課題: 既存のアプリケーションで品質をスケーリングする
P2ER は、自動車メーカー、時計ブランド、ホスピタリティ企業など、グローバル ブランド向けにハイエンドのデジタル エクスペリエンスを提供しています。多くの企業と同様に、複雑な既存のアプリケーション内で作業することが主な課題でした。エージェント コーディングを採用するチームは、次の 3 つの大きなハードルに直面しました。
- 脆弱な UI テスト。標準のテストスイートでは、P2ER の一部のプロジェクトで変動するホテルの価格や季節限定のサービスなどの動的データに対応できませんでした。モックデータは、人間のテスターがすぐに発見する統合の欠陥を隠蔽することがよくありました。
- エージェントの信頼性に関する問題。明示的な指示がない場合、AI エージェントはタスクが完了したと主張することがありましたが、実際には検証していませんでした。
- コンテキストの喪失。タスクが広範囲でモデルのタイムアウトが発生すると、エージェントがセッションの目標を追跡できなくなりました。これにより、デベロッパーがエージェントが開始した作業を追跡して続行することが困難になりました。
解決策: クラフトマンシップのためのインフラストラクチャを構築する
P2ER は、AI を「スパーリング パートナー」として扱い、開発の反復的な側面も処理できるインフラストラクチャを構築しました。このアプローチにより、アーキテクチャと創造的な問題解決に焦点を当てることで、チームはクラフトマンシップを拡大できます。
エージェントの MCP サーバーに DevTools を使用して実証的検証を適用する
信頼性を確保するため、P2ER は必須の経験的検証ルールを確立しました。このエンジニアリング マンダートは、プロジェクトの AGENTS.md ファイルに明記されており、次のように規定されています。
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
チームは、エージェントの言葉を鵜呑みにするのではなく、エージェントがアプリケーションを視覚的かつインタラクティブに操作できる安全な環境を提供するために、エージェント向けの Chrome DevTools を使用しています。
これらの「テスト エージェント」は、標準の静的テストでは見逃されるいくつかの重要なタスクを実行します。
- 動的データ テスト: ステージング環境でも、エージェントは実際の変動データ（季節によって変化するホテルの料金など）に対してテストを行い、ユーザーがアプリケーションを体験するのとまったく同じように体験します。これは、エージェントの
github-issue-testスキルで呼び出されるnew_page、navigate_page、fill、click、hoverなどのエージェントの操作ツール用の DevTools によって有効になります。これにより、エージェントは動的に認証し、現実的なユーザーのクリックパスをシミュレートできます。 - ビジュアル監査: エージェントは、Figma レイアウトと実際の実装との間のビジュアルの不一致を特定します。エージェント向けの DevTools の
take_screenshotツールを使用すると、figma-validateスキルで Storybook のライブ レンダリングの高解像度スクリーンショットをキャプチャし、Figma のエクスポートと並べて比較できます。 - ユーザビリティ チェック: エージェントは、自動スクリプトでは見落としがちな翻訳の欠落やユーザビリティ エラーを検出します。エージェントは、
take_snapshotとtake_screenshotを介して取得したアクセシビリティ ツリーとビジュアル スナップショットを直接操作し、自動検証ワークフローで明示的に指示されたとおりに、MISSING_MESSAGE 文字列などの UI の異常を積極的にスキャンします。
サブタスクを分解して永続化する
セッション タイムアウトとコンテキストの損失に対処するため、P2ER はサブエージェントを通じて作業を厳密に区分化します。次に、エージェントにオーケストレーターとして動作するように指示します。
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
このプロセスで人間のプロダクト オーナーに最新情報を伝えるため、チームはエージェントが GitHub の問題で作業を追跡するためのカスタム スキルを統合しました。これにより、すべてのサブエージェント タスクとその結果が GitHub API を使用してサブ問題として保持され、文書化されます。これにより、他のデベロッパーが取得できる明確な監査証跡と永続的なコンテキストが作成されます。
並列実行のために環境を分離する
複数のエージェントがコードを並行して実行できるように開発プロセスをスケーリングするため、P2ER はエージェントのタスクごとに分離された環境を義務付けています。これにより、UI 検証中の状態の競合やネットワークの問題を防ぐことができます。
この分離の技術的な設定は次のとおりです。
- 分離された Git ワークツリー: 複数のエージェントが並行して動作する場合のファイル競合とワークスペースの汚染を防ぐため、タスクは分離された Git ワークツリー内で実行されます。各エージェントには、環境変数がコピーされ、依存関係がシンボリック リンクされる専用のファイル システム領域が割り当てられます。これにより、ファイル変更が互いに上書きされることはありません。
- 一意の環境: 各エージェントとタスクは、一意の分離されたポートで Next.js 開発サーバーを実行します。プロジェクト ルールに従って、サーバーは
npx next dev -p <custom_port> --turbopackで動的に起動され、ネットワークの競合なしに並列実行が保証されます。 - データベースのクローン: 並列テスト中のデータ競合を回避するため、P2ER はエージェントの起動時にメイン データベースをタスク固有のスキーマにプログラムで複製します。エージェントが検証を完了し、タスクが承認されると、自動クリーンアップ プロセスによって分離されたデータベースが削除されます。このライフサイクルにより、すべてのエージェントがクリーンなワークスペースで動作し、未処理のデータが残らないようになります。
- 対象を絞ったテスト: エージェント向けの Chrome DevTools を使用したすべてのブラウザ テストは、その特定のエージェント インスタンスに割り当てられたカスタムポートを正確にターゲットにする必要があります。テストの義務では、デフォルト ポートのハードコードが禁止されており、
http://localhost:<custom_port>などのテスト対象 URL が必要です。
影響: 品質を維持しながら開発速度を 10 倍に向上
信頼性の高いガードレールを備えたエージェント コーディングへの移行により、P2ER の出力が変化しました。これらの変更は、元々はエージェントの信頼性を確保するために必要でしたが、開発ライフサイクル全体にもメリットがありました。
- 作業サイクルの 10 倍の高速化: 以前は平均 1 ～ 3 日かかっていたほとんどの問題が、1 日以内に解決されるようになりました。デプロイ頻度が週 1 回から 1 日に複数回に増加しました。
- QA チームの戦略的焦点: エージェントが基本的な回帰と「簡単に達成できること」を検出するようになったため、人間のテストチームはより詳細で複雑なテストシナリオに集中できます。
- ステークホルダー向けの堅牢な実装: テストがプログラマーの標準的な「ハッピーパス」を超えて行われるため、実装の復元力が向上します。
- より明確なコミュニケーションとトレーサビリティ: 「人間の問題から実装のサブ問題」ルールを適用することで、関係者は、技術的な実装の詳細やテスト方法が記載されたチケットを読み解くのではなく、どのような論理的な改善が行われたかについて明確な指示を受け取ることができます。
開発速度への影響の例として、P2ER は、確立された方法では何年もかかっていたであろう新しいプラットフォームを 6 か月で構築しました。人間は最終的な品質ゲートとして、エージェントによってすでに検証されたプルリクエストをレビューします。
チーム向けの技術的な分析情報
このワークフローを構築する過程で、P2ER は、実験から成熟したエージェント支援開発モデルへの移行に役立ついくつかの戦略を特定しました。
これらの戦略は、他のチームが独自のエージェント実装を改善するうえでも役立ちます。
スクリプト挿入と CLI バッチ処理でトークンの使用量を最適化する
エージェントがステップバイステップのナビゲーション（スナップショットの取得、ID の検索、入力の入力、待機など）のみに依存している場合、長い開発セッション中に MCP サーバーのトークン使用量が増加する可能性があります。このオーバーヘッドを最小限に抑えるため、P2ER では次の 2 つのアプローチを採用しています。
- インライン スクリプトの挿入: 複雑な React フォームでの認証など、ターゲットを絞ったインタラクションの場合、エージェントは
evaluate_scriptツールを使用して、バニラ JavaScript をブラウザに直接挿入します。これにより、組み込みのセッターのオーバーライドがバイパスされ、複数のアクションが一度に実行されるため、会話のターンを大幅に節約できます。 - CLI スクリプトのバッチ処理: エージェントが「問題」に直面したり、非常に長く繰り返しの多いブラウザ フローに遭遇したりした場合、CLI バッチ処理のフォールバックに切り替えます。P2ER は、個々の MCP ツールを繰り返し使用したり、カスタム自動化スクリプトをゼロから作成したりする代わりに、Chrome DevTools CLI にブラウザ アクションを永続化してバッチ処理するよう指示します。これにより、エージェントはマルチステップ フロー全体を一度にプログラムで実行できるため、モデルとツール間の継続的な通信のオーバーヘッドを大幅に削減できます。
トレース分析でパフォーマンス トラッキングを自動化する
P2ER は、人間の認識にのみ頼るのではなく、エージェント向け DevTools を使用して自動 Lighthouse 監査とパフォーマンス トレースを実行する review-performance スキルを作成しました。
エージェントは performance_start_trace ツールと performance_analyze_insight ツールを使用して、Core Web Vitals（LCP、INP、CLS）をキャプチャして調査し、メインスレッドのボトルネックやレイアウト シフトを特定します。品質ゲートを完成させるために、エージェントは完全な lighthouse_audit を実行して、アクセシビリティ（a11y）、SEO、一般的なウェブのベスト プラクティスにおける回帰を特に防ぎ、高品質のコードのみがプルリクエスト用に送信されるようにします。
エージェント向けの Chrome DevTools で確認を強化する
P2ER は、カスタム スキルに加えて、エージェント MCP サーバーの Chrome DevTools のコア機能を使用して機能検証を行います。これには、サーバーを使用してさまざまなデバイスをエミュレートし、レスポンシブ性をテストして、さまざまな画面サイズやデバイスでユーザー インターフェースが動作することを確認することが含まれます。
MCP サーバーを使用してアプリケーションをナビゲートすることで、エージェントはレイアウトと実際の実装の間の視覚的な不一致を特定し、静的テストでは見落とされがちなエラーを特定できます。
リソース
P2ER のユースケースをさらに詳しく調べるには、関連する GitHub リポジトリで言及されているすべてのスキルを確認してください。
エージェント向けの DevTools を使用して同様のワークフローを実装する方法について詳しくは、以下のリソースをご覧ください。