はじめに
GMOコネクトの永田です。
「既存システムに E2E 回帰試験を自動化したい。試験項目は揃っている、AI に任せれば早いはず」── そう思って Claude に振ったら、数ステップおきに「この画面ってどの URL ですか？」「OK 条件は？」「このデータって事前に必要ですか？」が飛んできた😇
直近 2 案件でこれを経験しました。テストコードの生成自体はむしろ強力で、Playwright のセレクタも DOM を見ながら書いてくれるし、落ちたテストの修正も速い。それなのに止まる。原因をたどると毎回、テストコードを書くより前の "地ならし" 不足でした。逆に、そこを先に整えた瞬間に Claude は呼び戻しなく自走し始めます。
まさに 「段取り八分」 を地で行く感覚だったので、本記事は「委譲スタイルの応用」を主役にするのではなく、これから実案件で E2E 自動化を試す人が、事前にやっておくと段取りが効く準備・整理のノウハウとしてまとめます。題材にした 2 案件は、認証基盤も UI フレームワークも別物でしたが、地ならしとして効いた型は結果的にほぼ共通でした。
軸としては前回までの engineer to delegate to (Anthropic 公式解説) と地続きですが、今回はそれを前面には出さず、QA/E2E の現場ノウハウとして書きます。
先にまとめ
いきなり「テスト書いて」と振らない。まず ①→②→③ の明確化を Claude にやらせ、それが終わってから振る。これだけで Claude が呼び戻しなく自走し始める。
段取りは次の 4 本柱でした。
| # | 段取り | これをやらないと | 効くこと |
|---|---|---|---|
| 1 | 試験項目の明確化 (トレーサビリティ + OK 条件 + 正解データ) | 画面名と実装が結びつかず Claude が当て推量、OK 判定がブレる | 「この項目 = この画面 = この URL/API、OK はこれ」が地図になり Claude が迷わない |
| 2 | 事前 SEED の明確化 | 「データが無い」で全落ち、何を入れるべきかが毎回不明 | 必要なマスタ/SEED/config の内容が確定し、投入を任せられる |
| 3 | 自動化スコープの設計 | どこまでやるかが曖昧で過剰実装 or 抜け漏れ | smoke 先行・API 併用・round-trip 可否を先に決め、Claude の実装範囲が定まる |
| 4 | Claude が環境を直接さわれる準備 | 「出力 → 人が実行 → 結果を貼る」の往復 | Data API/scale を Claude が自走 (※シリーズ既出なので軽く) |
この 4 つのうち ①〜③ は、古典的な QA / E2E 自動化の文脈ではむしろ標準的な準備項目 （トレーサビリティ確保、テストデータ管理、スコープ設計）で、特段新しい話ではありません。ただし AI × E2E 自動化の「やってみた」系記事ではほとんど語られていない領域でもあり、本記事は古典 QA のノウハウが AI 委譲の文脈で改めて効くという観点でまとめ直すものです。④ の「Claude が CLI を直接叩ける環境づくり」はこれまでのシリーズでも繰り返し書いてきたので、本記事では軽く触れる程度にします。
第1部: なぜ「段取りが八分」なのか ── 地ならしの正体は暗黙知
最初に断っておくと、この重さは「既存システムだから」でも「新規アプリだから」でもありません。 新規でも、今回の段取りをやらなければ同じだけ苦労します。逆に、既存システムでも段取りさえ事前に終わっていれば Claude はスムーズに自走します。重さを決めているのは新旧ではなく、暗黙知と段取りの有無でした。
E2E を 1 回でも安定して通すまでに立ちはだかる暗黙知は、だいたい次の 3 種類でした。
-
試験手順の画面名と実装のトレーサビリティ欠如 ── 試験項目書の
/loginや/admin/*が汎用表記で、実装の実ルートと違う (ロール値で着地が分岐する、管理者向けと顧客向けで同じパスを別画面が使う、等)。「どの試験項目が、どの画面の、どの URL/API を叩くのか」の地図が存在しない。 - 明文化されていないマスタ/SEED/CSV ── 「業務処理が完了し、明細まで揃った状態のデータ」のような前提データはテストを流しても溜まらず、事前投入が必須。集計レポートが読む CSV が特定パスに要る、スキーマは最新版で初期化しないと現行アプリが落ちる、等。「アプリを普通に操作して作られたデータ」を前提にしていて、DB 直接投入だと欠落する。
- 設計書に載っていない暗黙値・運用上の有効値 ── ロール種別や状態を表すカラムが取り得る値 (enum) が明文化されておらず、コード上は定義があっても実環境のマスタには存在せず実質未稼働、という値が紛れていたりする。「どの値が正常系で、どの値は実は使われていないのか」は、コード上の定義だけからは判断できません (deprecated 扱いなのか、まだ機能していないだけなのかは、運用判断を知る人に聞かないと埋まらない)。バッチ完了フラグのようなカラムも、どの値が「完了」を意味するのかは仕様書に書かれていない。特定の条件で OTP がスキップされる、初回ログインの利用規約モーダルが特定カラム値で出る/出ない、といった条件分岐も同様で、コードを読んでも「運用上こうなっている」値はすぐには出てきません。
これらは Claude がいくらコードを読んでも埋まらない部分があり、今回もアプリ担当に仕様を確認する場面は多々ありました。その確認自体が段取りの一部です。逆に言えば、この暗黙知を解消して整理した状態を Claude に渡せれば、テストコードの生成は最後の一押しに過ぎません。
ここで一つ気づいたのは、この段取りは「AI だから必要」というものではなかったことです。やっていることは、新しくプロジェクトに参画したメンバーが E2E 試験をスムーズに実施できるようにするための段取りと、ほぼ一致しています。試験項目と画面・API の対応、前提データ、どこまでやるかの線引き ── 人間の新メンバーが「これ、どの画面ですか？」「このデータ事前に要りますか？」と詰まるポイントと、Claude が人を呼び戻してくるポイントは同じでした。Claude を新しくチームに加わるメンバーとして迎える準備だと考えると、何を整えるべきかが見通しやすくなります。
実際、後で挙げる ①〜③ は、古典的な QA / E2E 自動化の文脈ではむしろ標準的な準備項目で、特段新しい発見ではありません。新しいのは、これらが AI 委譲の現場で「Claude が人を呼び戻すかどうか」という形で症状として可視化されたことで、AI × E2E の「やってみた」系記事ではむしろ抜け落ちがちな観点でした。
だから可逆的にこう言えます ── 地ならし (段取り) こそが、Claude 自走の律速。以降はその段取りを 4 本の柱に分けて、具体的に何をやっておくと効くかを書きます。
第2部: 段取りの 4 本柱
ここが本記事の核です。各柱を「何をやるか → 具体 → これから試す人へのコツ」でまとめます。
2.1 〈柱①〉試験項目の明確化 ── トレーサビリティ・OK 条件・正解データ
一番効いたのがここでした。そして大事なのは、この明確化そのものを Claude にやらせたことです。人がすべての地図を用意してから渡したのではなく、spec を書く前段として、まず Claude に設計書・実装・試験項目書を突き合わせて整理させ、どうしても確定できない点だけをアプリ担当に確認しました。「何をテストするのか」「どうなれば OK なのか」を Claude 自身が迷わない形に整理しきってから spec 実装に入る、という順序です。整理は次の 3 つに分けました。
(a) 操作手順の画面名 → 画面ID → アクセス先 URL/API のトレーサビリティ
試験項目書に書かれた画面名は、たいてい汎用表記で実装の実ルートと一致しません。そこで間に 画面ID 略号 を挟み、「画面名 → 画面ID → 実 URL (ハッシュルート等) / 実 API パス」の対応表を Claude に作らせました。Claude は実装のルート定義を読みながら、試験項目書 (Excel) を一度 Markdown 化し、各試験項目 ↔ 画面ID ↔ spec ファイル ↔ 実 URL/API を一覧で引ける形に整理します。これがあると、後続で Claude 自身が「この試験項目はこの画面のこの API」と迷いなく辿れます。
ロール認可が絡むと特に効きます。同じパスでもロール値で着地画面が変わったり、画面パスと API パスの分類が一致しなかったりするため、ルート定義のロール gate を先に表に落としておくと、Claude が認可エラーを仕様と取り違えずに済みます。
(b) 確認観点・OK 条件の明確化
「クリックできた」では試験になりません。「何が表示されれば / 何が返れば OK か」を、試験項目書の確認観点から事前に言語化・確定しておきます。
拒否系 (権限外操作) は特に注意が要ります。「権限外の操作ができない」は必ずしも 403 とは限らず、入力検証で 400 になることもあるので、まずソースを調査して、正規の拒否応答コードを確定する (例: ロール gate で 403、入力検証で 400 等)。その上で OK 条件は 「許容コードのいずれかであること (例: ステータスが [400, 401, 403] に含まれる)」 で握ります。単に「成功 (2xx) しないこと」だけにすると、500 系のバグまで「拒否されたから OK」と素通りしてしまうので、許容コードを明示的に列挙しておくのがポイント。他社データの非参照系も同様に許容コードを確定した上で、加えて 「他社の識別子が結果に含まれないこと」 を観点として握る、という具合に、OK 条件を観点ベースで定義しておくと Claude のアサーションが堅くなります。
(c) 正解データの整備
レポートや CSV 出力のように「出力の中身まで」検証する項目は、期待値そのもの (正解 CSV 等) を資産として用意しておきます。ここが無いと Claude は「出力された」までしか確認できません。正解データを置いておけば、「この入力 SEED に対してこの出力になるはず」まで握れます。集計値の正解は業務的な正しさを伴うので、初回だけアプリ/業務担当のレビューを通し、以降は repo の fixture として版管理して diff で退行を見る運用に倒す方針です。
(a)〜(c) の整理を Claude に進めさせると、コードからは確定できない暗黙知 ── 運用上の有効値、CSV のバリデーション、ロール対応など ── が必ず残ります。これは最終的にアプリ担当に聞くしかありませんが、ここでも工数を下げる工夫をしました。「これ何ですか？」と丸投げするのではなく、Claude にコードから読み取れる範囲を埋めさせ、こちらの想定 (dummy 行案・SEED 案・ロール対応案など) を提示した上で「この理解で合っていますか / この値で通りますか」とピンポイントに確認する形にします。アプリ担当は 0 から書くのでなく ○× と補足を返すだけで済むので、確認の往復が一気に軽くなりました。
コツ: (a)〜(c) の整理は spec を書く前段でまとめて Claude にやらせます。ここを整理しきる前に「テスト書いて」と振ると、当て推量でそれっぽい spec を書き、後で観点不足が露呈します。逆にこの地図と採点基準が揃えば、spec 実装はほぼ作業に落ちます。
2.2 〈柱②〉事前 SEED の明確化
柱①で「何を・どうなれば OK か」が決まったら、次は その試験を成立させる前提データの中身を洗い出して明文化します。ポイントは「どう投入するか」(それは柱④) ではなく、「何を投入すべきか」を先に確定させることです。
- マスターデータ + E2E 固有の前提 SEED ── 企業・部門・ユーザー・ロール別アカウントといったマスタに加え、「業務処理が完了し、明細まで揃った状態のデータ」のような 流しても溜まらない前提データを列挙する。リグレッション試験のスコープには、その前提状態を作るための操作が含まれないこともあるため、こうした状態は事前に作り込むしかありません。
- CSV インポート用 fixture と、そのインポート仕様 ── マスタの一括登録/更新を試すなら、投入する CSV の中身だけでなく、ヘッダ列・必須/任意・バリデーションルール・文字コード、そして 1 ファイルに insert/update/delete を action 列で混在させるのか、操作種別ごとにファイルを分けるのかといったインポート仕様を先に確定する。ここが曖昧だと、fixture を作っても import がバリデーションで弾かれ、「操作できた/できない」の判定にすら入れません。
- スキーマ/初期化データのバージョン ── 旧版スキーマで初期化すると現行アプリの集計やレポートが落ちることがある。どの初期化データを正とするかを明記しておく。
- 認証・運用上の有効値を「テストごとにブレない状態」にする ── OTP の自動スキップ条件、利用規約同意バージョンなど、テストを確実に通すために前もって潰しておく config。あわせて、ロール種別や状態カラムが取り得る 有効な enum 値も「どれが正常系か」を明確化しておく (コードに定義はあっても実環境では未稼働、という値が紛れることがある)。これらは「投入する値」というより 事前に確定しておく前提で、SEED と同じく明確化の対象です。
ここを「何が必要か」のリストとして書き出しておくと、Claude は不足分を自分で特定して足しに行けます。逆にリストが無いと、落ちるたびに「このデータ要りますか？」で止まります。
2.3 〈柱③〉自動化スコープの設計
「どこまで自動化するか」を先に設計しておかないと、Claude は良かれと思って過剰に作り込んだり、逆に観点を取りこぼしたりします。実案件では次の観点で線を引きました。
- そもそも自動化できるか (app 側の test hook 待ち) ── 時間経過に依存する項目 (パスワード有効期限、締切後の挙動など) や、バッチ完了を前提とする項目は、バッチの手動実行手段や時刻オフセットの仕組みが無いと自動化スコープに入れられません。実時間を待つのは非現実的なので、app 側に test 用の強制実行/時刻短縮フックを足してもらうか、いったんスコープ外にするかを先に決める。「頑張れば自動化できる」と「環境的に無理」の線引きをスコープ設計の段階でやっておくと、Claude が再現不能な項目に時間を溶かしません。
- smoke or full ── まず全画面に到達できる smoke で土台を作り、CRUD の詳細 (一覧/編集/登録/削除) は後続フェーズに回す。フェーズを切っておくと、Claude が「今どこまでやるか」で迷わない。
- hybrid or all-UI ── 全部を UI 操作で検証するか、一部を API 直叩きで検証するか。たとえば CSV ダウンロードは、署名付き URL がブラウザの download イベントを発火しないことがあるため、UI クリックに依存せず API を叩いて URL を取得 → 中身を検証するほうが堅実でした。「ここは UI、ここは API」を設計しておく。
- round-trip or verify-only ── 副作用を伴う操作は、戻せるものは 「紐付け → 確認 → 解除 → 確認」の self-cleaning round-trip にし、戻せないもの (アカウント生成 + 通知メール送信など) は verify-only に倒す。これを操作ごとに先に決めておくと、共有環境を汚さずに何度でも回せます。
コツ: スコープ設計は「Claude にやらせない範囲を決める」作業でもあります。線が引けていれば、Claude は範囲内で目一杯自走し、範囲外を勝手に作り込みません。
2.4 〈柱④〉Claude が環境を直接さわれる準備 (軽め)
最後は、Claude が CLI を直接叩いて環境を操作できる状態づくりです。ここはこれまでのシリーズで繰り返し書いてきたので、要点だけ:
-
Data API で SEED を直接投入 ──
aws rds-data execute-statementで SQL を直接流せると、psql クライアントも踏み台も要らず、Claude が柱②で明確化した SEED を FK 順に自己投入できる。 -
共有 DEV 環境のライフサイクル ── コスト最適化で ECS desired=0 / DB 最小容量 0 になっている環境を、Claude が
scale up → 投入 → spec → cleanup → scale=0のルーチンで自分で起こして片付ける。破壊・更新系の DB write と scale 変更だけは人承認のガードを残す。 -
テストの不安定さは構造で潰す ── 全リクエスト完了を待つ書き方 (Playwright の
networkidle等) は禁止 (テスト一式の実行時間が数倍に劣化した)。コールドスタート直後の login 失敗は環境要因と割り切って retry で吸収する。このあたりは規約に落として固定しておく。
補足: spec を書くときのノウハウ (残りの「二分」)
段取り (八分) が済めば spec 実装はほぼ作業ですが、1 つだけ spec 側で効かせている規約があるので補足します。spec の各実装行に「操作」「観点」を 1 行コメントで添え、試験項目書の「手順」「確認観点」と spec が 1:1 で読めるようにすることです。
これは段取りというより spec 内のトレーサビリティ確保ですが、後から「このアサーションは試験項目書のどの観点を担保しているのか」を spec 単独で追えるようになり、レビューや引き継ぎが楽になります。柱① で作った「試験項目 ↔ 画面ID ↔ spec」の対応表と合わせると、試験項目書 ⇄ spec の双方向トレーサビリティが効きます。
繰り返しですが、④ は「やってみた」記事でも比較的語られている領域です。本記事で強調したいのは、④ の前に ①〜③ の明確化・設計が終わっているかどうかで、Claude の自走度がまるで変わるという点です。
第3部: 段取りが効いた瞬間
①〜③ の明確化が済んでいると、あとは Goal (Acceptance criteria) を渡すだけで、Claude は呼び戻しなく自走を始めます。段取りが効いたと感じた瞬間を 2 つ。
- 量産が始まる ── 試験項目書を Claude が一人で読み下せる ── 柱①(a) のトレーサビリティ (試験項目 → 画面ID → 実 URL/API → spec) が揃った時点で、Claude は試験項目書を頭から読み下しながら spec を次々と書けるようになりました。認証関連、マスタ画面の到達、操作系 (filter / import / row click / sidebar nav 等) まで、同一セッション内で数十 spec が一気に積まれ、人は spec 単位のレビューと、Claude がまとめて git issue のコメントに整理した不明点 (案つき) のアプリ担当確認に専念するだけで済みました。地図が無ければ「この試験項目ってどの画面ですか」が毎回飛んできていたはずです。
- 構造の選択を Claude が自分でやる ── 副作用の扱いを判定して型を選ぶ ── 柱③で「戻せる操作は round-trip、戻せない操作は verify-only」を先に決め、柱④で Data API ヘルパを整えておいたので、Claude は新しいマスタの CRUD 試験を実装するとき、副作用が戻せるかを自分で判定して型を選びました。戻せるなら「紐付け → 確認 → 解除 → 確認」を Data API で組み、戻せないなら verify-only に倒す。操作ごとに「どう実装すべきか」を人が指示しなくても、Claude が型を選んで使えるようになりました。
どちらも、①〜③ で「何が正しいか / どう扱うか」が明確だからこそ、Claude が判断と量産を自分で進められた例です。落ちた spec ですら、Claude は「これは SEED 不足 (柱②) / 環境要因 (柱④) / 仕様確定が必要 (柱①)」と原因を自分で振り分けるので、人が呼び戻される回数は劇的に減りました。
まとめ
Before / After
いきなり「テスト書いて」と振る Before と、①〜③ の段取りを先に終えてから渡す After で並べます。
| 観点 | Before | After |
|---|---|---|
| 試験項目の解釈 | 画面名と実装が結びつかず Claude が当て推量 | 画面ID 経由のトレーサビリティで「項目 = 画面 = URL/API」が一意 |
| OK 判定 | 「クリックできた」止まり、観点が抜ける | 観点・OK 条件 (2xx しない/識別子が漏れない 等) を先に定義 |
| 期待値の検証 | 「出力された」までしか見られない | 正解データを用意し、中身まで検証 |
| 前提データ | 「データが無い」で全落ち、毎回人に確認 | 必要 SEED/config を明確化し、Claude が自己投入 |
| 実装範囲 | 過剰実装 or 観点の取りこぼし | smoke 先行・API 併用・round-trip 可否を先に設計 |
| 環境操作 | 出力 → 人が実行 → 結果を貼る | Data API/scale を Claude が自走 (シリーズ既出) |
体験として大きかったのは、「段取りが八分」という言葉どおり、テストコードを書く前の "明確化と設計" に労力の大半が乗っていたことです。そしてその段取りは、認証基盤も UI も別物の 2 案件で、結果的にほぼ共通の型に落ちました。さらに振り返ると、この段取りは AI 固有のものですらなく、新しく参画したメンバーが E2E 試験をスムーズに回せるようにするための準備とほぼ同じでした。Claude を新メンバーとして迎えるつもりで地ならしする、というのが一番しっくりくる捉え方だと思います。
これから実案件で E2E 自動化を Claude に任せる方は、いきなり「テスト書いて」と振る前に、本記事の ①試験項目の明確化 → ②事前 SEED の明確化 → ③スコープ設計 を先に整えてみてください。 ④ の環境準備が終わっていれば、あとは Goal を渡して別の作業をしながら待つだけになります。
前回 の「ドキュメントが失われた環境の移植は属人化案件、を過去のものにする」に続いて、今回は 「実案件 E2E 自動化は段取り八分」 という話として、QA/E2E 領域への Opus 4.7 の応用事例を書き残しておきます。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。