AIが書いたE2Eテストは証跡まで出す：録画・赤枠スクショ・レポート

1. 「テストの工数がない」をどう解くか
2. プロンプト1本で出てくる3種類の証跡
3. 8つのテストシナリオは何を見ているか
4. 証跡①：フルHDの操作録画
5. 証跡②：赤枠付きの連番スクショ40枚
6. 証跡③：Markdownのテストレポート
7. 中小企業の現場らしいテスト項目
8. 自社ツールに当てはめるときの書き換えポイント
9. まとめとキットの入手先

1. 「テストの工数がない」をどう解くか

社内ツールの内製で最初に削られるのはテストです。動くことは作った本人がわかっている。でも「本当に大丈夫なのか」を上司や情シスに説明する材料がない。手作業で画面をポチポチ確認し、スクショを撮り、Excel に貼って、説明を書く。この作業に半日から1日かかるため、結局「作ったけど検証していないツール」が社内に増えていきます。

この記事で紹介するのは、Claude Code にプロンプトを1本渡すだけで、Playwright のE2Eテストを自動生成・実行し、証跡（録画、スクショ、レポート）まで一式出力させる方法です。題材は、BOOTHで販売している「完全ローカルAI業務アシスタント構築キット」に同梱の2本目のプロンプト tasks/02_E2Eテスト自動化_自動バグ修正プロンプト.md と、その実行結果です。

この記事では「何が出てくるか」に絞ります。テスト中に Claude Code が自分で見つけて直した5件のバグについては、別記事 {T2} で扱います。

2. プロンプト1本で出てくる3種類の証跡

プロンプトを実行すると、テスト結果_{日時}/ というフォルダが作られ、次の3種類が揃います。

証跡	中身	実機の結果
操作録画	1920×1080 のブラウザ操作動画（.webm）	`video/e2e_operation.webm`
連番スクショ	操作対象を赤枠で強調した PNG と JPG	各40枚（`step_01_起動確認` から `step_40_文字起こし結果` まで）
テストレポート	総合評価、項目数、成功・失敗数、自動修正したバグ一覧、項目別の確認内容と判定	`テストレポート_20260924_033130.md`、総合評価 PASS

重要なのは、この3つを「人が後から作る」のではなく、テストスクリプト（test_automation_runner.py、約2,000行）が実行と同時に生成する点です。テストを回すたびに証跡が更新されるので、改修後の再テストでも同じ品質の資料が自動で出ます。

3. 8つのテストシナリオは何を見ているか

プロンプトには、中小企業の実務で起きやすい事故を前提にした8つのシナリオが書かれています。実機のレポートに記録された項目は次の通りです。

#	シナリオ	主な確認内容
1	起動とセキュリティ設定	ポート8501のクリーンアップ、127.0.0.1での起動、Deploy ボタンやヘッダーメニューの非表示、SQLite の WAL モード
2	業務フォルダの作成・切替・削除	DB への反映、選択中フォルダを削除しても例外画面が出ない
3	多形式の資料登録と全選択・全解除	PDF・CSV・TXT・MD・XLSX の5件を一括登録、インクリメンタル検索、全解除で0件、全選択で5件、個別チェックで5→4件
4	旧Office形式の混入	中身が旧形式の .xlsx と拡張子 .xls を投入してもクラッシュせず、変換案内を表示
5	実務プロンプトのCRUD	検索・追加・編集・削除が SQLite に即時反映、続けて選び直したときの入力欄の切替
6	業務相談チャット	ローカルLLMへの送信（最大120秒待機）、文字数カウント、引用番号クリックで該当箇所を展開
7	エクスポート	Word・Excel・PowerPoint・Markdown の4形式を出力し、python-docx 等で開いて段落数・シート数・スライド数まで検証
8	音声議事録タブ	タブ切替、文字起こしモデル選択、無音の音声を入れても例外で止まらず案内を表示

シナリオ3のように、資料を5件登録してからチェックボックスの一括操作を検証するテストは、手作業だと毎回同じ条件を再現するのが面倒です。自動化すると、資料の生成から登録、操作、件数の照合まで同じ手順で繰り返せます。

4. 証跡①：フルHDの操作録画

録画は Playwright の record_video_dir で、ビューポート 1920×1080 のまま保存されます。プロンプトには「超高速な自動操作は厳禁」「各操作の間に1,000〜1,800ミリ秒のウェイトを挟む」「テキスト入力は1文字ずつタイプする演出を入れる」という条件が書かれているため、人が目で追える速度の動画になります。

録画の用途は2つあります。1つは、情シスや上司への説明資料です。「このツールは何をどう検証したのか」を、動画を流すだけで共有できます。もう1つは、失敗したときの原因調査です。どの操作の直後に画面が崩れたかを、スクショより細かく追えます。

5. 証跡②：赤枠付きの連番スクショ40枚

スクショは、操作対象（ボタン、入力欄、タブ）を赤枠で囲んでから撮影し、撮影後に枠を外す方式です。プロンプトでは「操作直前に scroll_into_view_if_needed() で画面内に収める」「PNG と JPG の両形式で連番保存する」ことを条件にしています。

連番のファイル名には操作内容が日本語で入ります（例: step_12_全解除ボタン.png、step_13_全解除の結果.png）。レポートからも同じファイル名で参照されるので、Markdown を開くだけで「操作」と「結果」の対応が追えます。

6. 証跡③：Markdownのテストレポート

レポートは、プロンプトで指定したフォーマットに従って生成されます。冒頭に総合評価と項目数、成功・失敗数、自動修正されたバグ数が並び、続いて自動修正したバグの一覧表、さらに項目ごとに「テスト内容」「説明」「確認した内容」「判定」「該当スクショ」の順で並びます。

実機のレポートで印象的だったのは、シナリオ7のエクスポート検証です。ボタンを押してファイルが落ちたことを確認するだけでなく、ダウンロードした .docx を python-docx で開いて段落11件、.xlsx を openpyxl で開いてシート1枚、.pptx を python-pptx で開いてスライド2枚、と中身まで検証しています。「ファイルが出た」ではなく「開ける正しいファイルが出た」まで確認しているので、提出用の証跡として使えます。

7. 中小企業の現場らしいテスト項目

このプロンプトが汎用的なE2Eテストのテンプレートと違うのは、中小企業の現場で実際に起きる事故をシナリオに織り込んでいる点です。

旧形式の .xls や .doc が混ざって投入される（シナリオ4）。誰かが古い見積書をそのまま投げ込むのは日常です。落ちないこと、案内が出ること、他のファイルは正常に登録されることを同時に見ます
無音や録音レベルが極端に低い音声が入る（シナリオ8）。会議の録音失敗は珍しくありません。例外で止まらず「発話を検出できませんでした」と案内して終わることを確認します
Deploy ボタンが隠れている（シナリオ1）。Streamlit 標準の右上メニューには外部公開につながるボタンがあり、社内利用ではそれ自体がリスクです。DOM に存在しないことまで検証します

テストの観点が実務から逆算されているので、「テストは通ったのに現場で落ちる」が起きにくくなります。

8. 自社ツールに当てはめるときの書き換えポイント

このプロンプトは、同梱の参照用コード（app.py など）向けに書かれています。自社のツールに使うときは、使い方.md の「自社適用時の書き換え対応表」にある次の箇所を差し替えます。

書き換える箇所	内容
検証すべきテストシナリオ	8項目の一覧を自社ツールの画面と機能に置き換える
柔軟なタイムアウト設計	LLM 推論や重い処理の待機上限（既定120秒）を自社の処理時間に合わせる
成果物の出力先・命名規則	フォルダ名、スクショの命名を自社の規約に合わせる
レポートのフォーマット	見出し構成を社内の報告書様式に寄せる

書き換えても変わらないのは、「ポート競合の解消と終了時のプロセス停止」「赤枠とスクロールの撮影ルール」「失敗時に Claude Code 自身がコードを直して再実行する」という骨格です。ここがプロンプトの価値で、ゼロから書くと一番時間がかかる部分です。