instructions ファイルに QA の知見をため込み、「こういう失敗ならこう直す」を Claude に学習させているのが面白いこの記事の発想はかなりシンプルです。
夜のあいだに Playwright の E2E テスト（画面を実際に動かして確認するテスト）が失敗したら、翌朝人間がログを見て原因を調べ、修正して、PR を作る。――これ、毎回やると地味に面倒です。
そこで著者は、「人間が寝ている間に Claude Code にやらせればいいのでは？」と考えたわけです。
この発想、かなり好きです。怠惰というより、時間の使い方がうまい。深夜にしか起きない“単純だけど面倒な作業”は、AI と相性がいいんですよね。しかも、朝起きたら Draft PR ができている。これはちょっとテンション上がると思います。
ざっくり流れはこうです。
_analyze-and-fix.yml が起動つまり、失敗したテストを人間が朝に直す代わりに、Claude が先に第一案を作るという仕組みです。
ここで大事なのは、完全自動で勝手に本番コードをいじるのではなく、まずは Draft PR にしている点です。
私はこの設計がかなり健全だと思います。AI が便利でも、いきなり自動マージは怖いですからね。
実装では、_analyze-and-fix.yml を再利用可能ワークフロー（workflow_call）として作っています。
要するに、別のワークフローから呼び出せるようにしてある、ということです。さらに workflow_dispatch でも手動実行できるので、必要なら人間が起動もできます。
面白いのは、claude コマンドに渡す --allowedTools で、使える操作をかなり絞っていることです。
ReadWriteEditGrepGlobBash(git:*)Bash(gh:*)Bash(npm:*)Bash(npx:*)Bash(jq:*)Bash(cat:*)Bash(ls:*)つまり、Claude に「何でもできる shell」を渡しているわけではなく、git や gh など必要なものだけ許可する設計です。
これはかなり重要で、AI に作業を任せるときの基本姿勢だと思います。便利さと安全性のバランスですね。
さらにこの仕組みの肝は、instructions ファイルに QA の知見をためていることです。
単なる「失敗したら直して」ではなく、失敗パターンごとの修正方針を積み上げているんですね。
たとえば、記事ではこんなパターンが紹介されています。
maxRetries を調整する。
strict mode violation
似た要素が複数あって、Playwright が「どれを指しているのか分からない」と怒るケース。
→ { exact: true } を足して絞り込む。
テーブル行ロケーターエラー
rowspan など、表の複雑な構造に追従できていないケース。
→ XPath を工夫して兄弟行も含めて探す。
ページ遷移後の操作が不安定
reload 後などに失敗するケース。
→ Playwright の auto-wait に任せる。
承認ワークフロー系での strict 違反
モーダル内の要素に対して範囲が広すぎるケース。
→ getByRole('dialog') でスコープを限定する。
さらに、
nth() は使わないwaitFor() を action の前に入れないwaitForTimeout は入れないといった「やってはいけない」原則も書いているそうです。
ここ、すごく実践的です。
AI に自由に考えさせると、それっぽいけど悪い修正をしてくることがあります。だからこそ、QA の経験をルール化して“AIの癖”を矯正するのが効くんだと思います。
個人的には、この部分がこの記事のいちばんおもしろいところでした。AI そのものより、AIに渡す知恵の整備が勝負なんですよね。
記事では、実際に直したケースとして、テーブルのロケーター修正が紹介されています。
問題は、カテゴリ列に rowspan が使われていたこと。
rowspan というのは、1つのセルが複数行にまたがる表の構造です。人間には普通に見えても、テストから見ると「どの行のデータなのか」が少し分かりにくくなります。
この画面では、
<tr> にある<tr> にあるという構造でした。
旧ロケーターは、カテゴリを含む最初の行だけを見に行っていたため、「削除」の行では見つけられず失敗していた、という話です。
Claude がやった修正は発想の転換でした。
カテゴリのある行を起点にするのではなく、操作テキストのある行を起点にして、カテゴリが同じ行か、その直前の兄弟行にあるかを見る形に変えたのです。
これ、地味ですがかなり賢いです。
私はこういう修正を見ると、「AIは雑に直すこともあるけど、ちゃんとハマると人間っぽい発想もするんだな」と思います。もちろん、そこまで導く仕組みがあってこそですが。
当然ながら、課題もあります。
ログを見て Claude が「タイムアウトが足りない」と判断すると、単純に待ち時間を伸ばす修正を提案してくることがあるそうです。
でも、これは根本解決ではなく、たまたま通るようにしているだけのことも多い。
ここは本当に大事です。
テストの世界では「とりあえず待つ」を増やすと、あとでどんどん壊れます。だから、著者も instructions に「デフォルト値は変えない」と書いているものの、完全には防げないと述べています。
結局ここは、QA の目でレビューするしかないというのが現実的な判断でしょう。
この自動修復ジョブから見えるのは、Playwright のレポートとテストコードだけ。
プロダクト本体のコードには触れません。
つまり、UI の構造変更が原因だった場合、完全な判断は難しいことがあります。
ただし、テストコードを保守しやすい構造にしてあるおかげで、Page Object（画面操作をまとめた設計）をたどれば原因にたどり着けることが多いそうです。
ここはかなり示唆的です。
AI が直せるかどうかは、AIの賢さだけじゃなくて、テスト設計の良さに左右されるんですよね。
結局、土台がぐちゃぐちゃだと、AI も人間も苦しい。これはすごく納得感があります。
今の運用では、Draft PR ができたら、QA の担当者がレビューしてマージします。
つまり、完全自動ではなく、AIは下書きを作る係です。
また、Claude が修正に失敗した場合は GitHub Issue を自動作成し、「手動確認が必要です」という状態にしてくれます。
失敗した run へのリンクも残るので、朝になって「何が起きたか分からない」という事故を防げます。
このあたりの設計も、実務っぽくていいです。
AI が止まったときに黙るのではなく、人間にちゃんと仕事を渡す。こういうフォールバックがあると、運用はかなり安定します。
記事によると、これまで発動したオートヒールは 2 件で、どちらもそのままマージできるレベルだったそうです。
頻繁に壊れるものではないが、壊れたときに自動で下処理してくれる。これはちょうどいい塩梅だと思います。
しかも、もともと「flaky にならないようにプロダクトとテストを設計する」という前提があるので、夜間テストがしょっちゅう落ちるわけではない。
つまりこの仕組みは、壊れまくる現場をAIで強引に支える話というより、ちゃんと整備された環境に、さらに便利な自動化を足した話です。ここは誤解しないほうがいいポイントです。
将来的には、PR の複雑度評価と組み合わせて、低複雑度の修正なら auto approve も考えているそうです。
ただし、テストコードは数行の変更でも広範囲に影響することがあるので、「見た目が小さいから安全」とは限りません。
この慎重さは正しいと思います。
テストはコード量よりも影響範囲が怖いので、単純な行数では判断しにくいんですよね。
ここをどうスコアリングするかは、今後の腕の見せどころでしょう。
私が特に面白いと思ったのは、この記事が「AIで何でも自動化！」という話ではなく、むしろ逆で、AIを使う前提で人間の知見をどう形式知化するかに重点があることです。
つまり、
という、かなり地に足のついた設計なんです。
AI導入の成功例って、派手なデモよりこういう“地味な運用設計”にあるんじゃないかと思います。
この取り組みは、夜間の E2E テスト失敗を Claude Code が先回りして直し、Draft PR まで作ってくれる仕組みです。
単なる自動化ではなく、QA の知見を instructions に蓄積して、AI がちゃんと“テストらしい修正”をしやすいようにしているのがポイントでした。
派手さはないけれど、実務で効くタイプの自動化です。
そして何より、朝起きたら「もう PR がある」というのは、かなり気持ちよさそうです。心もテストも Happy、という締め方にも納得感があります。