SHOCODE

Generatorで生成されたコードを確認する際の3つのチェックポイント（Locatorのstatic readonly、PageのJSDoc、Testのデータ定数化）がすぐ使える内容でした。実際にチェックしながら「ちゃんと既存スタイル踏襲してるな」と確認できる流れが良かったです。

Playwright AgentsのPlanner、Generator、Healerという3つのAgentの役割分担が、実際のプロジェクトでどう活用できるのかが明確に理解できました。特に計画編でのシナリオのピックアップから、ファイル名の明示までの流れは、単なるツールの使い方を超えて「AIとどう協働するか」という視点で学べたのが良かったです。Page Object Modelの3レイヤー構造も、Generatorに既存スタイルを準拠させることで一貫性のあるコードが生成される様子を見て、デザインパターンの実践的な価値を実感できました。

修正編でTrace Viewerを使って時系列で画面状態を確認しながら原因特定していくところが参考になった。カラー選択のタイミング問題をURLの変化で解決する流れは、他のテストでも使えそう。HTML Reporterとの使い分けももう少し知りたかったけど、基本的な使い方は理解できました。

「画面を見れば分かる問題は得意だが、タイミングの問題には弱い」というHealerの特性が、実際の失敗例で示されていたのが印象的でした。最初Sign Inボタンのロケーター修正は成功したのに、カラー選択では空回りする様子を見て、AIツールに何でも任せるのではなく適切に判断する必要性を実感。「目的はテストを実行できるようにすることであり、Healerに修正させることではない」という原則、肝に銘じます。

計画編の「どのシナリオをテストするか」の判断基準がめちゃくちゃ実務的。初回リリース前は全量、工数がなければ優先度つけて絞る、既存機能のリグレッションなら正常系だけ、という3パターンの使い分けが明確で即活用できる内容でした。「壊れたときに売上が止まるか」で優先度つける考え方、今まさに必要としてた視点です！

Plannerが実際のアプリを探索するための「入り口」としてSeedテストが必要という説明で、やっと理解できました。これがないと汎用的な計画しか立てられないんですね。もう少し複雑なアプリでの例も見たかったですが、基本は押さえられました。

既存ファイル更新時のDiff確認、これ超重要ですね。main-page.tsに検索機能のメソッドが追加されたとき、既存のログイン機能を壊してないか段階的にチェックする手順が丁寧で分かりやすかったです。AIツール使うときの必須プロセスとして覚えておきます。

日本語で会話、コードは英語という設定、チーム開発で使えそうです。AIの言語切り替えが不安定になる問題の解決策として参考になりました。

Planner→Generator→Healerの流れを実際のECサイトで体験できたのが良かった。各Agentの設定ファイル（.agent.md）の役割や、準備編でやったツール有効化設定の意味が後から「だからあれが必要だったのか」と腑に落ちる構成になってて、テスト自動化の全体像が掴めました。

正規表現でURLの変化を待つ解決策、実践的でした。エスケープの説明（`\?`や`\d+`の意味）も分かりやすく、正規表現の使い方として勉強になりました。

このコース、単なるPlaywrightの使い方じゃなくて「AIとどう協働するか」という視点で一貫してるのが素晴らしい。Plannerが包括的に計画→人間がピックアップ。Generatorが初期コード生成→人間がDiff確認。Healerが修正トライ→人間がTrace Viewerで本質的原因特定。この役割分担が各レクチャーで明確に示されてる。