前提
20年近く運用しているWebサービスの保守開発に携わっています。PHPの管理画面（EUC-JP）とRails APIが共存するレガシー環境で、バグ修正PRのエビデンス（動作確認の証跡）をClaude Codeにブラウザ自動操作で取らせようとしました。
結論から言うと、5回やり直しました。その過程で見えたのは「AIはブラウザを操作できるが、何を証明すべきかは理解していない」という事実です。
失敗1: スクショを撮った、でもエビデンスではない
Claude Codeにagent-browserでエビデンス収集を依頼しました。管理画面の各ページのスクリーンショットを7枚撮影して「完了しました」と報告してきました。
必要だったのは「操作前の状態 → 操作実行 → 操作後のDB状態」という因果関係を示すフローです。AIは「画面を撮る」という行為は遂行できます。しかし「何を証明するためにどこを撮るべきか」までは考えが及びません。
失敗2: テストが通っても証跡にならない
次にPlaywrightテストを作成させました。全テスト成功。しかしテストレポートを確認すると問題が3つありました。
- テスト対象の前提条件が書かれていない
- 中間状態を確認できる箇所がない
- 操作結果を裏付ける画面のスクショがない
テストが通ることとエビデンスとして成立することは別物です。test.info().attach() で前提条件を添付し、第三者が見て「何の条件で、何を確認して、どういう結果が出たか」がわかる形にする必要がありました。
失敗3: エラーから逃げる
管理画面の詳細ページでエラーが発生しました。するとClaude Codeは「DBの値をテキストファイルに書いてエビデンスにしましょう」と回避策を提案してきました。
「ちょっと立ち止まってコードから調べてよ」と指示しました。
結果的にPHPの in_array() の引数ミスと $id 変数の未初期化という2つのバグが見つかりました。AIは「楽な迂回路」に飛びつく傾向があります。人間が「根本原因を調べろ」と方向を修正しないと、本質的な問題が見過ごされます。
失敗4: ビジネスロジックの矛盾に気づかない
あるステータスをDBで直接変更した後、画面には矛盾した表示が出ました。AIはそのまま報告してきました。
「この状態でこの表示が出るのはおかしくないか」
UIが参照しているテーブルが想定と違っていたのが原因でした。テストデータの「ビジネス的な整合性」まで考慮するにはドメイン知識が要ります。AIにはその知識がないので、矛盾をスルーしてしまいます。
失敗5: コンテキスト溢れで振り出しに
1日で8回以上のセッション断絶が起きました。ブラウザセッション（ログイン状態）も消失します。同じ「ログイン → 画面遷移 → スクショ」のフローを何度も最初からやり直すことになりました。途中でagent-browserからPlaywrightに切り替えるなど、ツール選択も揺れました。
E2Eテストのような長時間タスクはコンテキスト上限との相性が悪いです。
最終的にどう仕上げたか
3つのPlaywrightテストに落とし込みました。
// テスト1: 前提条件を添付物として明記し、操作結果を撮影
test("設定変更が正しく反映される", async ({ page }, testInfo) => {
// 前提条件をエビデンスに添付
await testInfo.attach("前提条件", {
body: "対象: テスト用アカウントn現在の設定: Aパターンn期待する結果: Bパターンに変更",
contentType: "text/plain",
});
// 操作前の状態を撮影
await page.goto("/admin/target-page");
await page.screenshot({ path: "before-change.png" });
// 設定変更を実行
await page.click('[data-action="submit"]');
// 操作後の状態を撮影
await page.screenshot({ path: "after-change.png" });
});- テスト1 — 前提条件を添付物として明記し、操作前後の状態を撮影
- テスト2 — 管理画面の変更履歴で処理待ち状態をハイライトして撮影
- テスト3 — 管理画面で現在の設定と変更後の状態を確認
途中で管理画面側のバグ2つも修正する必要がありました。結局のところ、エビデンスの「型」を人間が定義してからAIへ実行させる形に落ち着きました。
学んだこと
5つの失敗から得た教訓をまとめます。
1.「何を証明するか」を先に定義する
「操作前の状態 → 操作 → 操作後の変化」の3点セットを指示テンプレートにします。AIに「エビデンスを取って」と丸投げしても、画面キャプチャの山が返ってくるだけでした。
2. 前提条件を必ず記録させる
テストアカウントの状態や設定値など、第三者が読んでわかる情報を添付させます。テストが通ったかどうかだけでは証跡になりません。
3. ドメイン知識は人間が補完する
「この状態でこの表示はおかしい」のような判断はAIにはできません。業務ロジックの正しさは、その業務を知っている人間がチェックするしかありません。
4. 回避策ではなく根本原因を追わせる
エラーが出たときの指示は「代替案を出して」ではなく「原因を調べて」にします。AIは放っておくと最短経路で問題を迂回しようとします。
5. 長時間タスクは中間保存を設計する
ブラウザ操作のスクリプトを都度保存し、コンテキスト溢れに備えます。E2Eテストのように前後関係が重要なタスクでは、セッション切れが致命的になります。
振り返り
AIにブラウザ操作を任せること自体は十分に実用的でした。ただし「何を撮るか」「何を証明するか」の設計は人間の仕事で、そこを省略するとやり直しが増えます。
エビデンス収集は「操作の自動化」ではなく「証明の設計」が本質でした。
