Claude Code と Playwright MCP を用いたE2Eテスト自動化スキルの構築

次世代システム研究室のY.Yです。Claude Code を使うようになり、機能改善やバグ修正の実装そのものは短い時間で進められるようになりました。一方で、実装後の動作確認（local や stg を実際に操作して、その修正が効いているかを確かめる作業）は手作業のまま残り、ボトルネックになっていました。そこで、GitHub の issue URL を 1 本渡すと、Claude Code がブラウザを操作してその修正の動作確認を行い、結果をレポートにまとめるツールを作りました。テストコードは書かず、確認手順は自然言語の計画として持ちます。本記事では、その概要と設計で工夫した点、そして使ってみて分かったことを中心に紹介します。

結論ファースト

• Claude Code と Playwright MCP を組み合わせると、E2Eテスト（UIからの動作確認）を自動化できます。E2Eテストを自動化することで、動作確認が面倒な作業から軽いレビューに変わります。
• 精度は実用に足る水準で、手作業でかけていた動作確認の時間は、その大半を削減できました。小さな修正であれば、生成されるレポートとスクリーンショットで確認が完結することが多く、不足を感じた分だけ自分で追えば済みます。
• 一方で Playwright MCP のためのトークン消費は多めで、多用時は注意が必要です。

目次

• 1. 背景と課題
• 2. 設計
• 3. 実測と使用感
• まとめ
• 最後に

1. 背景と課題

機能改善やバグ修正の実装そのものは、Claude Code でかなり効率化できるようになりました。コードを書く、直す、説明する、といった工程は、対話しながら短い時間で進められます。

一方で、実装後の動作確認（local / stg をひととおり操作して確かめる作業）は手作業として残り、ボトルネックになっていました。修正のたびに同じ画面を開き、同じ手順をなぞって挙動を確かめる作業です。実装が速くなったぶん、この後工程の手作業が相対的に目立つようになった、とも言えます。

この手作業には、いくつかの性質があります。一つは属人性です。どの画面をどの順で確認するか、どこまで周辺を見るかは担当者の頭の中にあり、人や日によって確認の範囲が揺れます。

もう一つは再現性の低さです。確認した結果が証跡として残らないため、「確かに動いていた」を後から示せず、同じ確認を別の人がもう一度なぞることになります。レビューの場でも、動作確認をした事実は口頭やテキストで共有されるだけで、何をどう確かめたのかは残りません。

手作業である以上、確認の抜けも起こり得ます。とくに修正の影響範囲が広いときほど、見るべき画面が増え、抜けの余地も増えます。

かといって、テストが整備されていない既存プロダクトに、今から従来型の E2E テストコードを一式書いて整備するのは手間が大きすぎます。従来型の E2E は、画面要素を指す Page Object やセレクタを整備し、それを資産として育てていく前提に立っています。資産がゼロのプロダクトにこの方式を後から入れるのは現実的に重く、最初の 1 本を通すまでに、対象画面の構造を読み解いてセレクタを定義し、ログインや前提データの段取りを組む、という準備が必要になります。Playwright などのフレームワークを使うにも前提知識が要り、書き方や待ち合わせの作法を習得する立ち上がりのコストがかかります。

さらに、テストコードは書いた後も保守の対象になります。画面の構造が変わるたびにセレクタの追従が必要で、UI の改修が入るたびにテスト側も直すことになります。動作確認のボトルネックを解消するために、保守対象を新たに抱えることになる、という構図です。

整備が進めば回帰スイートとして大きな価値を生みますが、その価値が出るまでの初期投資が、資産ゼロの状態では重くのしかかります。

二つの方式の前提を並べると、次のように整理できます。

観点	従来型 E2E（コードで書く）	自然言語＋エージェント （本ツール）
確認手順の持ち方	テストコード（Page Object・セレクタ）	自然言語の Markdown 計画
着手時の初期投資	フレームワーク整備・資産づくりが必要	ログイン手順など最小限の準備で開始
画面変更への追従	セレクタ等の保守が継続的に必要	その都度 issue から計画を生成
必要な前提知識	フレームワークの習熟	自然言語での指示
実行の速さ・安定	速く・決定的に再生できる	探索のため遅く、トークンを消費
向く対象	繰り返し回す回帰スイート	個別の修正の事後確認

そこで方針を変え、テストコードは書かずに、自然言語の計画で動作確認を自動化することにしました。狙いは三つです。一つめは、簡単な修正の動作確認を Claude にほぼ任せることです。二つめは、理想としては issue / PR の差分を読んで Claude が計画を立てて実行まで行うことです。三つめは、確認した証跡を残せるようにすることです。

テストコードを資産として持たないかわりに、毎回の確認手順を自然言語の計画として持ち、その実行結果を証跡として残す、という置き換えです。確認手順がコードでなく自然言語なので、フレームワークの習熟は前提にならず、画面が変わってもセレクタを直し続ける保守は発生しません。そのかわり、毎回その issue 向けに計画を生成するため、繰り返し同じ確認を高速に回す用途には向きません。

上の比較表のとおり、本ツールは従来型の置き換えではなく、個別の修正を事後に確認する場面に向いた、別の方式という位置づけです。両者は排他ではなく、回帰スイートは従来型で、個別修正の事後確認は本ツールで、という使い分けも考えられます。

2. 設計

どう動くか（実行フロー）

実行は次の ①〜⑦ で進みます。画面に出る表示は最小限（解析中の 1 行など）で、人が確認するのはゲート2の 1 回だけです。

③のサブエージェントによる解析は読み取り専用のため、確認を挟まずに進めています。読み取りしかしない工程は、途中で止めて承認を取る必要がないためです。表示を 1 行に抑えているのも、解析の途中経過を細かく実況しても人の判断材料にはならず、流れを煩雑にするだけだからです。④のゲート2が、人が中身を見て判断する唯一の地点になります。

生成する計画は、差分検証と回帰スモークの両面で構成します。差分検証は、今回の修正で新しく変わった挙動が効いているかの確認です。回帰スモークは、その周辺が壊れていないかの確認です。

当初は「この issue は E2E で検証できるか・できないか」という可否の判断を中心に考えていましたが、可否の二択では、UI に直接出ない修正をすべて「対象外」と弾いてしまいます。そうした修正でも、正常系が壊れていないかという観点は回帰スモークとして確認する価値があります。そこで、可否を二択で決めるのではなく、差分検証と回帰スモークという検証の中身を二面で決める、という考え方に変えました。差分検証ができない修正でも、回帰スモークだけは観点として残す、という配分ができるようになります。

仕組みと設計の要点

設計の中心は、性質の異なる 3 種類のファイルを置き場所で分けることです。変わらないもの（ログイン手順など）と、毎回変わるもの（その issue 用の計画）を分離する考え方です。動作確認の中には、毎回同じであるべき部分と、修正ごとに変わるべき部分が混ざっています。これを同じ場所に置くと、毎回 AI に手探りさせる範囲が広がってしまいます。そこで、変わらない部分は一度だけ書いて固定し、変わる部分だけを毎回生成する、という線引きにしました。

• references（変わらない知識）: ログイン手順や URL は毎回同じです。一度書けば毎回手探りさせずに済む、投資対効果が最も高い層です。事前準備（ログインやテストデータ）の負荷が高いため、ここを先に固める効果が大きい部分です。ここが固まっていないと、毎回の実行のたびに AI がログイン経路を探り直すことになり、遅く不安定になります。逆に固めておけば、毎回の計画は「何を確認するか」だけに集中できます。
• plans（毎回変わる計画）: issue ごとに自動生成します。コミットして「何をどう確認したか」を資産にします。計画は使い捨てではなく、後から「この修正はこういう観点で確認した」と振り返れる記録になります。
• reports（証跡）: 実行結果です。OK / NG とスクリーンショットを残します。計画が「何を確認するつもりか」を表すのに対し、レポートは「実際にどうだったか」を表します。

3層構造

この三つに、全体の段取りを持つスキル本体（SKILL.md）と、ブラウザ操作の実体である Playwright MCP を加えると、役割分担は次のようになります。

スキル本体は、この references を見て当該 issue 用の計画を作り、実行して結果を残す、というオーケストレーションに徹します。判断のロジックや手順そのものはスキルが持ち、ブラウザ操作の実体は Playwright MCP に任せる、という役割分担です。図のとおり、変わらない知識（references）は入力、毎回の計画（plans）とレポート（reports）は出力で、両者が混ざらないように置き場所から分けています。

安全と品質を担保する 2 つのゲート

安全と品質は 2 つのゲートで担保します。ゲート1（AI の自己判定・自動）は、その修正がどう検証できるかを切り分ける工程です。判定は二段で行います。まず、対象がそもそもブラウザを持つアプリの修正かを見ます（インフラや CI など、動作する画面を持たないものは対象外です）。次に、検証の中身を差分検証と回帰スモークの二軸で見ます。

差分検証（新しい挙動が効いているかの確認）は、修正が画面に差を生むときだけ成立します。一方の回帰スモーク（周辺が壊れていないかの確認）は、画面に差が出ない修正でも、関連する画面さえあれば残せます。そのため、画面に差が出ないからといってただちに弾くのではなく、差分検証は省いて回帰スモークだけ残す、という配分をします。停止する（計画を書かずに「E2E では検証不可。手動または unit test を推奨」と返す）のは、差分検証も回帰スモークもどちらも成り立たない、つまりブラウザで触れる意味が無いときだけです。あわせて、再現手順・期待挙動・影響する画面や機能を、issue 本文と diff、ソースから抽出します。

ゲート2（人の承認・必須）は、生成した計画を提示し、人が Go / No-Go を出すまでブラウザ操作に一切入りません。AI が issue を解釈して計画を立てる以上、解釈のズレは起こり得ます。ゲート2は、そのズレを実行前に人が止めるための工程で、人が確認するのはここだけです。計画の段階なら、ズレていても画面を触る前に直せます。

さらに、ゲート2 は単純な Go / No-Go の関門ではなく、人が計画に手を入れる場でもあります。たとえば「この観点も併せて確認してほしい」と検証項目を追加したり、「ここはどういう意図か」と疑問点をその場で確認したり、再現手順や前提条件の指示を加えたりできます。こうした指示を反映して計画を直してから実行に移るため、ゲート2 は承認であると同時に、人の意図を計画にすり合わせる調整点としても働きます。

これとは別に、本番 URL は判断に委ねず、フックが実行直前に拒否します。ゲート1・2が「これは確認すべきか」「この計画でよいか」という判断であるのに対し、本番ガードは判断を介在させません。ゲート1・2は AI と人の判断に基づくため解釈を誤る余地があるのに対し、本番ガードは判断を介さず、本番ドメインであれば理由を問わず拒否します。

本番への誤接続は実データに副作用を残し得るうえ、bot 対策に弾かれる可能性もあり、コストが高いため、ここだけは判断ではなく仕組みで止めています。

この三段の関係を図にすると次のようになります。性質が異なる三つを重ねているのが要点です。

ゲート1は AI による判断、ゲート2は人による判断、フックは判断に委ねない仕組みです。判断（ゲート1・2）が解釈・承認・調整（指示の反映）を担うのに対し、本番ガードは判断を介さず、本番 URL であれば機械的に拒否します。

技術スタック

技術スタックは次のとおりです。

• Claude Code の Skill … 全体のオーケストレーション。
• Playwright MCP … ブラウザ自動操作エンジン。
• サブエージェント … issue 解析から計画生成を読み取り専用で担当。
• PreToolUse フック（Python） … 本番 URL を実行直前にブロック。

ファイル構成は次のように、役割ごとに置き場所を分けています（簡略版）。

e2e-agent/
├── .claude/
│   ├── skills/e2e-auto/SKILL.md        ← スキル本体（起動〜レポートまでの段取り）
│   ├── hooks/playwright-url-guard.py   ← 本番URLを実行直前にブロック
│   └── settings.json                   ← 権限の許可リスト
├── .mcp.json                           ← Playwright を --secrets 付きで登録
├── .env                                ← 認証情報（コミットしない）
└── references/   【変わらない知識】login / environments / test-data
    plans/        【毎回変わる計画】issue ごとに自動生成
    reports/      【成果物＝証跡】レポート＋スクリーンショット

認証は secret-safe 方式です。パスワード等の実値はモデルに渡さず、環境変数名だけを渡します。ログイン処理は、入力欄に環境変数名を渡すと実行時に実値へ置換され、モデルへの応答はマスクされて返ります。つまり、計画にもチャットにもレポートにも実値は現れず、AI は実値を一度も見ません。認証情報そのものはリポジトリにコミットしません。

整備の初期段階では、動作確認の対象となるアプリのログイン経路を一通り実機検証し、その手順を references に固めました。アプリによってログインのフローが異なるため、ここを先に固めたことで毎回の挙動が安定しました。

工夫したところ

① 入力は issue 単体ではなく入力バンドル

issue 本文だけでは情報が足りません。再現手順は省略されがちで、期待値は暗黙のことが多いためです。書いた人にとっては自明な前提が省かれていて、後から読む AI はその欠けた前提を勝手に補完してしまいます。補完が外れれば、見当違いの計画になります。また PR の diff は「何を変えたか」しか示さず、バックエンドの変更が画面のどこに出るのかまでは分かりません。サーバ側のロジックを直した修正が、画面のどの表示やどのエラー文言に現れるのかは、diff だけを見ても結びつきません。

そこで、三つの入力を束ねて読みます。一つめは issue ツリー全体（親＋全 sub-issue・リポ横断）で、本文だけでなく親子の文脈やコメントの議論も含めて、期待挙動や再現条件の手がかりを集めます。二つめは紐づく PR の diff で、実際に何が変わったかを押さえます。三つめは、的を絞って読んだアプリのソースです。

ソースまで読むことで、変更が触れたコードから、それを呼び出す側や、それが現れる画面・機能をたどれます。diff が示す変更点を起点に、トリガーになるボタンや、表示されるラベル・エラー文言、必要な前提状態までソースで確かめる、という読み方です。

さらに、修正がコードに実際に入っているかを突合します。確認しようとしている修正が、検証する環境のコードにまだ入っていなければ、何を操作しても旧挙動しか見られず、確認になりません。そこで、PR が OPEN ならブランチ名の一致、MERGED ならコミットの祖先関係で、修正が対象に載っているかを確かめます。

これにより、リポ名だけで判断して取りこぼすことを避け、修正本体が別リポの sub-issue にあるケースも拾えます。バックエンドの修正にひもづく画面側の変更が別リポにある、といった構成でも、issue ツリーをリポ横断でたどっているため見落としません。issue 単体ではなく、issue ツリー・PR・ソースを一つの束として扱うことが、計画の精度を支えています。

この入力バンドルの流れを図にすると次のようになります。三つの入力を一つに束ね、サブエージェントが解析して計画にする、という流れです。

② 本番を絶対に触らせない 2 層ガード

本番への誤接続は、2 層で防いでいます。1 つは PreToolUse フックです。ブラウザが URL に飛ぶ瞬間に検査し、local / stg は許可、本番や想定外は拒否します。スキルの自制ではなく仕組みで止めるのが要点です。スキルの文章で「本番を開かない」と書くだけでは、AI が解釈を誤れば本番に飛び得ます。フックは、その解釈の手前で URL を機械的に検査するため、AI がどう判断しても本番には到達できません。

もう 1 つは絶対ルールで、本番ドメインを開かない、不可逆な操作（組織の解約など）は押さない、ソーシャルログインやパスキーは使わない、を明文化しています。フックは URL を実行直前に機械的に検査して止め、絶対ルールは AI の振る舞いの方針として明文化しています。両者は重ねて効かせています。

なお、フックは local と stg を区別しません。local と stg はどちらも検証対象として許可されるため、どちらに繋ぐつもりだったかという取り違えはフックでは止まりません。そこで実行直前には対象環境を 1 行復唱し、これを誤環境接続を防ぐ最終確認としています。

③ やりすぎない — 検証できる範囲を見極める

何でも自動化しようとすると、かえって時間とトークンを浪費します。そこでゲート1で、その修正をブラウザでどう確認できるかを見極め、対象を絞ります。前章のとおり、判断は一律の「対象か対象外か」ではなく、修正の性質によって三通りに分かれます。

画面に差が出る修正は差分検証で確認します。画面に差は出ないが関連する画面がある修正は、その画面が壊れていないかを回帰スモークで確認します。そして、並行処理のバグ、DB トランザクションの不整合、API レスポンスの微差、CI / IaC の変更、メール文面のみの変更のように、そもそもブラウザに現れず、回帰スモークの対象にもならないものは、「E2E では検証不可。手動または unit test を推奨」と返し、無理に操作しません。完全に弾くのはこの最後のケースだけで、多くは差分検証を省いて回帰スモークに切り替える、という絞り方です。

たとえば、あるパッケージ更新では変更がパッケージ定義とロックファイルの 2 ファイルだけで、アプリのコードは変わっていませんでした。修正そのものは画面に差を生まないため差分検証はできませんが、依存を更新してもアプリが正常に動くかは確認する価値があります。ゲート1 はこれを「差分検証は不可。回帰スモークのみ観点に残す」と自動判定しました。完全に弾くのではなく、差分検証を省いて回帰スモークに切り替えた例です。判定の根拠（どのファイルしか変わっていないか）も計画に残るため、なぜ差分検証を行わなかったのかが後から追えます。

④ 前提状態を実装から組み立てる

バグの再現には、特定のデータ状態（無効化された権限、退会状態のメンバー、空のセクションなど）が必要なことがよくあります。事前準備の負荷が高い部分でもあります。そこでソースを読んで再現条件を割り出し、local / stg を可逆な環境として扱い、テストデータを作成・削除して前提を作ります。これらのデータ操作も、ゲート2 の承認にまとめて含めることで、実行中に追加の確認を挟まずに済ませています。作成したデータは必ずレポートに記録し、可能なら復元します。

再現に手順の工夫が要るケースもあります。たとえば、単一の画面操作では再現できず、複数のタブを併用する再現手順が必要な場合があります。こうした場合でも、ソースを読んで再現条件を割り出しているため、計画の段階で正しい再現手順を組み立てられます。手順そのものをあらかじめ知らなくても、実装から逆算して前提を作れる、というのがこの工夫の要点です。

3. 実測と使用感

テストケース

動作確認は、対象の画面を実際に操作して挙動を確かめます。たとえばエラー文言の修正であれば、次のような流れになります。

事後確認（実装済みの修正が効いているか）として、いくつかのケースで計測しました。参考実測値は次のとおりです。使用トークン数は参考までに。

ケース	内容（要約）	effort	計画まで （時間/token）	実行 （時間/token）
A	モーダルのカーソル / クリック無効化	high	2m08s / 39.5k	2m49s / 18k
A	同上（effort を上げた比較）	max	4m55s / 45.0k	6m50s / 23k
B	削除済み権限の招待エラー文言（複数タブ・要再現）	high	2m25s / 54.4k	22m00s / 55k
C	登録済みメール変更時のエラー文言	high	3m53s / 47.6k	9m44s / 25k
D	パッケージ更新（差分検証不可と判定）	high	2m40s / 41.3k	7m12s / 21k

「計画まで」はサブエージェントによる自動解析から計画生成までで、人の操作はありません。おおむね 2〜4 分・40〜55k token です。「実行」はログインからブラウザ検証、レポートまでです。再現が難しいシナリオ（複数タブを使う再現）は時間がかかります。effort はチューニングのつまみで、上げると計画が丁寧になる代わりに時間・token が増えますが、計測の範囲では high で十分な精度でした。

実機で通したケースでは、検証手法に関する所見も得られました。差分検証で CSS のカーソル形状を確認するケースでは、カーソルの形はスクリーンショットに写りません（Playwright の仕様）。スクリーンショットだけを証跡にしていると、見た目には変化が無いように見えて、確認できたことにならない例です。そのため、画面の見た目ではなく要素の算出スタイルを読んで検証する必要がありました。

エラー文言の改善を確認するケースでは、招待時のエラーや、登録済みメールへの変更時のエラーが新しい文言に変わっていることを、画面上でそのまま確認できました。こちらは画面の表示にそのまま差が出るため、差分検証が素直に効くケースです。

依存更新のケースは、ゲート1 が「差分検証は不可」と自動判定し、回帰スモークのみを観点に残した好例です。差が出ない種類を無理に操作せず、観点だけ残すという配分が、自動の判定で機能しました。

複数タブを使わないと再現できないエラーについても、ソースを読んでいるため、計画の時点で正確に再現手順を立てられていました。再現に手順の工夫が要る場合でも、実装から再現条件を割り出せていれば、計画の段階で正しい段取りを組める、ということを示しています。

使ってみた所感は次のとおりです。良かった点と課題の両面で整理します。

良かった点

• 精度は良好で、動作確認に人が関わる時間の大半は削減できます。小さな修正ならレポートとスクリーンショットで十分なことが多く、不足を感じた分だけ自分で確認すればよいと考えています。確認の量も必要十分でした。
• ソースを読ませている効果が大きいと感じます。再現条件を推量でなく実装の読解から組み立てるため、複数のタブを併用するような巧妙な再現手順も、計画の段階で出てきました。想像で確認しているのではない、という安心感があります。
• 導入のハードルが低いです。テストコードを書かないので、テストが整備されていないチームでも、ログイン手順書さえ用意すれば始められました。フレームワークの習熟も前提になりません。
• 「できない」と正直に返すので、結果を過信せずに済みます。ゲート1 が検証できないものを正直に弾くため、OK という結果の意味を信用できます。
• 計画生成自体はスムーズです。タスクに関わらず、詳細な動作確認計画を5分以内に生成してくれます。

課題

• テスト計画の量は多めで、操作の粒度が細かいため、人が読むには負担がかかります。計画は機械が実行する手順書であると同時に人が承認する対象でもあるため、この読みやすさは課題として残っています。
• 入力（issue の質）に結果が左右されます。再現手順や期待値が issue に書かれているほど計画はよくなり、記述が薄いと推測に頼ることになります。良い issue を書く文化と相互に効く部分です。
• 計画生成に比べて実行には時間がかかり、再現が複雑だったり確認項目が多い場合は 20〜30 分ほどかかります。
• トークン消費量は多めです（1 回の実行で、5 時間あたりの利用枠の 5〜10% を消費することもあります。母数は契約や利用窓に依存します）。その他の用途で Claude を多用する場面では注意が必要です。
• メール確認を伴うフローは、追加の段取りが要ります。招待からメール承認へ進むような確認では、メールの受信内容を読み取るための手当て（ローカルはサーバのログ、ステージングは受信箱の連携）が別途必要になります。

限界の整理として、そもそも E2E（ブラウザ操作）では検証できない種類を、改めて表にまとめます。これらは画面の前後に差が出ないため、無理に操作しても確認になりません。代替手段は、画面に差が出ない以上 E2E の外で確かめることになり、基本は手動確認か unit test です。表に挙げた代替手段は、その中で種類ごとに想定される一例にすぎません。

検証できない種類	なぜ画面に出ないか	代替手段の例
並行処理のバグ	タイミング依存で、操作からは再現が難しい	手動 / unit test
DB トランザクションの不整合	内部状態の整合性で、画面表示に現れにくい	unit test / 結合テスト
API レスポンスの微差	画面上の見た目に差が出ない	API テスト
CI / IaC の変更	動作する画面が存在しない	パイプライン上で確認
依存パッケージの更新	アプリのコードが変わらない	回帰スモークで正常系のみ
メール文面のみの変更	送信内容で、画面操作には現れない	文面のレビュー

これからに向けて

現状を踏まえ、次の方向で拡張を検討しています。「繰り返しの高速化」「証跡の充実」「ワークフローへの組み込み」、そして「実行コスト（トークン）の削減」です。

回帰スイートへの蓄積（.spec 化）。 一度通った探索を、そのままテストコード（.spec）として書き出し、回帰スイートに貯めていく構想です。探索は遅い代わりに一度で済ませ、書き出したコードは速く何度でも再生する、という役割分担にします。スクリプト化できれば、探索に約 10 分かかっていた確認が再生 10 秒程度に短縮でき、変更のたびに気軽に回せるようになる見込みです。

証跡の充実。 現状はレポートとスクリーンショットを残していますが、これに実行の録画（動画）を加えれば、動作確認の様子をそのまま振り返れるようになります。

ワークフローへの組み込み。 確認結果を PR へ自動でコメントしたり、CI に組み込んだりすることで、人がツールを起動する手間自体を減らせます。

実行コスト（トークン）の削減 — Playwright CLI の導入検討。 先述のとおり、現状の弱点はトークン消費の多さです。これは、ブラウザ操作に Playwright MCP を使っており、各ステップで取得する画面のスナップショットが、そのままモデルの文脈（コンテキスト）に積まれることが主な要因です。

そこで、同等のブラウザ操作を提供する Playwright CLI への移行を検討しています。CLI はスナップショットをモデルの文脈ではなくディスクへ書き出すため、トークン消費を大きく抑えられる見込みです（手元で比べた範囲では、スナップショット取得まわりのコストはおおむね数分の一でした）。録画・trace・ログイン状態の再利用（storage-state）・テストコード駆動の実行も標準で備えており、前述の .spec 化とも相性のよい方式です。ただし、現在の MCP が備えるパスワードのマスク（secret-safe）は CLI には無く、本番ガードのフックも作り直しが必要になるため、安全機構を保ったまま段階的に移すことを前提に検討しています。

まとめ

作ったもの。 GitHub の issue URL を渡すだけで、テストコードを書かずに、小さめの修正の動作確認（ログインからブラウザ操作、レポート出力まで）を自動で行うツールを作りました。

実現できたこと。 手作業で行っていた動作確認の時間は、その大半を削減できました。計画づくりは人の操作なしで 2〜4 分、人が関わるのは計画をレビューする 1 回だけ、という運用が回っています。小さな修正であれば、生成されるレポートとスクリーンショットで確認が完結することが多く、その結果が証跡として残るため、PR レビューや「直したつもりが直っていない」の検出にも使えます。属人的で再現性のなかった動作確認を、誰でも追える形にできたのが一番の収穫です。

残る課題と今後。 一方で、生成される計画は粒度が細かく人が読むには負担があること、再現の複雑な確認には時間がかかること、そしてトークン消費が多いことが課題として残っています。今後は、一度通った確認をテストコード（.spec）として蓄積して高速な回帰に回すこと、トークン削減のために Playwright CLI への移行を検討すること、PR コメントや CI への組み込みを進めることで、これらを一つずつ詰めていきます。

最後に

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。 皆さんのご応募をお待ちしています。