コードカバレッジ超え Playwright による機能テスト—マイクロソフト マーレン・ハンガミ氏

AI 時代の新・テスト戦略：コード量より「機能」を検証する Playwright の役割

マイクロソフトのマーレン・ハンガミ氏は、AI エージェントによるコード生成量が急増する現代において、「単なるコードカバレッジ重視」から「ユーザー視点の機能テスト」への転換を提唱しました。スタンフォード大学の研究が示す通り、クリーンなコードベースこそが AI の生産性を最大化する鍵であり、そのためには従来の TDD（テスト駆動開発）の限界を超え、Playwright を活用したエンドツーエンド検証が不可欠です。

AI 導入とコード品質：エントロピー増大のリスク

2025 年、GitHub へのコミット数は過去最多の約 10 億件を記録し、2026 年にはそのペースがさらに加速して年間 140 億件に達すると予測されています。AI エージェントとの共著によるコード増加は目覚ましいものですが、マーレン氏は「AI が開発者の生産性を本当に高めるのか」という問いを投げかけます。

スタンフォード大学が 12 万人の開発者を対象に行った研究では、AI の導入自体が生産性向上に寄与することは確認されましたが、「開発者が AI をどう活用するか」が結果を分ける重要な要因であることが示されています。特に注目すべきは、クリーンなコードベースがない状態で AI を無制限に投入すると、システムのエントロピー（乱雑さ）が増大し、生産性が低下するという事実です。

管理されていない AI の導入は、コード品質の低下を招き、リファクタリングや再作業に多くの時間を費やす結果をもたらします。最終的な有効出力はわずかに増加するだけで、チーム全体の生産性は向上しません。

この課題を解決するためには、テストカバレッジや型カバレッジの充実、ドキュメントの質、モジュール性といった「コードベースのクリーンさ」を標準化するプラクティスが不可欠です。

従来の TDD と単体テストが抱える限界

コード品質を保つための伝統的な手法として「テスト駆動開発（TDD）」が挙げられます。しかし、近年の AI 活用環境において、従来のアプローチには明確な限界があります。

まず、実装詳細への過度な依存です。多くの単体テストは特定のメソッド名や内部ロジックに紐付いています。例えば「割引を含む注文計算」をテストする場合、calculate() という関数名がテストコードに直接記述されていると、関数名を変更しただけでテストが失敗してしまいます。これはシステムの振る舞いが正常であっても、実装の細部変更によってテストが壊れるという問題を生みます。

さらに深刻なのがAI による「自己肯定型テスト」の生成です。開発者が AI にテスト作成を依頼すると、コードカバレッジは満たすものの、システムの実際の動作を検証していないテストが生成されてしまうケースがあります。結果として、テストスイートはすべて緑色（合格）ですが、システムの機能としては欠陥があるという「偽りの安心」が生じてしまいます。

Playwright がもたらす「機能テスト」への転換

これらの課題を解決し、AI 時代に適したテスト戦略として提案されたのが、マイクロソフトが提供するオープンソースフレームワークPlaywrightを用いた機能テストです。Playwright はブラウザ上で実際のユーザー操作（クリック、入力など）をシミュレートすることで、エンドユーザーの視点からシステムの振る舞いを検証します。

Playwright を使用すれば、関数名の変更や内部リファクタリングに左右されず、あくまで「システムが期待通りに動作しているか」を検証できます。これにより、AI 生成コードの品質保証と、開発者のリファクタリングへの集中が可能になります。

Playwright は Python、TypeScript、C# など主要な言語をサポートし、ヘッドレスモード（画面を表示せずバックグラウンドで実行）での運用も可能です。これにより、CI/CD パイプラインに組み込みつつ、開発中のリアルタイム検証にも活用できます。

AI エージェントと連携する高速 TDD プロセス

マーレン氏は、Playwright と AI エージェントを組み合わせることで、従来の「遅い」と言われていた TDD プロセスを劇的に高速化できると示しました。このアプローチでは、AI エージェントに以下の 3 つの役割を持たせます。

1. Planner（プランナー）: どの機能テストを実行すべきかを計画する
2. Generator（ジェネレーター）: 失敗する Playwright テストを自動生成し、実装コードを作成する
3. Healer（ヒーラー）: テストが失敗した場合の原因を特定し、修正を行う

具体的なワークフローは以下の通りです。

1. 機能リクエストの取得: Outlook や M365 スイートから新しい機能要件を取得し、ターミナルに反映します。ここでは「検索バーの追加」や「フィルタ機能の実装」など、具体的な振る舞いを定義します。
2. レッドフェーズ（テスト作成）: AI エージェントに対し、Red-Green TDD の原則に基づき、まず失敗する Playwright テストを作成させます。これは単体テストではなく、ブラウザ上で検索バーに入力し、結果が表示されるかを確認するような機能テストです。
3. グリーンフェーズ（実装）: エージェントが生成したテストをパスさせるための実装コードを自動生成します。開発者はこの間、AI に任せて作業を進めます。
4. リファクタリング: テストが合格した後、最も時間を費やすべきは「リファクタリング」です。AI が生成したコードを確認し、より良い設計へと改善する作業に集中します。

デモでは、Copilot CLI と Playwright MCP サーバーを連携させ、開発者がキーボードから手を離すことなく、検索機能や価格フィルタの動作が自動で検証される様子が示されました。AI がコードを書き、ブラウザ上で実際にユーザー操作を行い、期待通りに結果が表示されることで、システム全体の安定性が視覚的に確認できます。

実践のためのベストプラクティス

この新しいテスト戦略をチームに導入する際、マーレン氏は以下の具体的なプラクティスを推奨しています。

• PR にスクリーンショットを追加: Playwright はテスト実行時に画面のスクリーンショットを取得します。変更を加えた際は、そのスクリーンショットをプルリクエスト（PR）に添付し、視覚的な差分を確認できるようにしましょう。
• ヘッドレスモードの活用: 常にブラウザを開く必要はありません。バックグラウンドで高速に実行できるヘッドレスモードを活用して、開発フローを阻害しないようにします。
• コミット前のスナップショット: テストを修正する前やコード変更を加える前に必ずコミットを行い、過去の状態を記録しておきましょう。これにより、問題発生時の原因特定が容易になります。
• 機能ごとのテスト設計: 各機能に対して 1 つの明確なテストを作成し、網羅的なカバレッジよりも「重要な振る舞い」の検証に注力します。

複雑な状態管理が必要な場合や、API レベルでの検証が必要なケースでは、Playwright エージェント専用の設定ファイル（agent.mmd）を活用するか、直接 API をテストする選択肢もあります。また、デスクトップ版とモバイル版など、異なるデバイスサイズでの動作確認も Playwright なら容易に可能です。

まとめ

AI エージェントがコード生成の中心となるこれからの時代において、開発者の役割は「コードを書くこと」から「システムが正しく機能しているか検証すること」へとシフトしています。Playwright を活用した機能テストと AI エージェントの連携は、単なるカバレッジの数値向上ではなく、エンドユーザー視点での品質保証を実現する強力な手段です。クリーンなコードベースを維持し、AI の力を最大限に引き出すためには、この「機能テスト」への転換が不可欠です。