6月22日、thoughtbotが「AI's "overnight" solution for our flaky tests took two weeks to adopt」と題した記事を公開した。ClaudeがフレイキーなテストをAIで一晩解決したものの、その結果を本番に投入できる状態にするまでさらに2週間を要したという実体験だ。「AIが動くコードを出した」と「そのコードが使える状態にある」は別の話であることを、具体的なコード差分と後処理の詳細から示している。
何年も解けなかったフレイキーテスト問題
このプロジェクトでは、複数の開発者が数年にわたってフレイキー（不安定）なテストと格闘してきた。問題のテスト群には:flakyラベルを付けて隔離する運用が続けられており、CIの60%が失敗するほど深刻な状態だった。
フレイキーなテストの中心は、StimulusやHotwireを使ったインタラクティブなページに関するもので、複数の開発者がそれぞれ1週間単位で挑んだが、いずれも失敗に終わった。Playwrightへの移行も一部では改善をもたらしたが、常に失敗するテストが残り、スキップせざるを得ない状況だった。筆者はマネージャーとして「過去5回の挑戦でどれも統計値は変わらなかった」と繰り返し警告を発しており、信頼する開発者からはテスト群ごと削除すべきという意見まで出ていた。
Claude（Opus 4.6）が一晩で「解決」した
ある夜、Claude Code上でOpus 4.6（元記事の表記による）を動かしたところ、フレイキーなテスト群を数百回実行して失敗を分析するというアプローチで問題を解決した。プロンプトには「早合点しないこと」「問題は繰り返しなしでは再現できない」という注意書きと、進捗を記録するMarkdownファイルを渡しただけで、特別なカスタマイズはしていない。
Claudeの動き方も興味深い。最初は5回実行すれば足りた（エラーが20%の頻度で発生していたため）が、それらを修正すると10回、50回、100回と必要なバッチ数が増えていった。数時間放置したまま別の作業ができたのも、フレイキーテストという問題がAIエージェントに向いている理由の一つだ。トークン消費もさほど多くない——長い実行を開始して、内部で会話してから次のバッチを走らせるだけの繰り返しだからだ。
「使える状態」にするまで2週間かかった理由
問題はここからだ。Claudeが出力したコードは、確かに動いた。しかし本質的な改善の周りにノイズが大量に混入していた。
元記事のコード例を引用する。修正前のテストが次のようなものだとすると：
1 オブジェクトを作成
2 ページを訪問
3 Aをクリック
4 Bをクリック
5 式1がtrueであることを確認
6 Cをクリック
7 式2がtrueであることを確認
Claudeが手を加えると、こうなる：
1 特に意味のない微妙に違う方法でオブジェクトを作成
2 ページを訪問
3 明示的なsleep
4 ページの特定セクションへの不要なスコープ
5 Aをクリック
6 スコープ終了
7 Bをクリック（3秒waitオプション付き）
8 本来3行目にあるべきだった有益な改善
9 式1がtrueであることを確認
10 Cをクリック
11 他のテストでは有効だが今回は無関係な改善
12 式2がtrueであることを確認
つまり、1テストあたり本当に重要な変更は1箇所（この例では8行目）なのに、意味のない変更（3、4、6、7、11行目）の山に埋もれている。
この「ゴミ」を取り除くために費やした2週間の作業は次の通りだ：
- 偶然の一致と本当の成果を分離する
- 差分をもたらさない変更を削除する
- 重要な変更にベストプラクティスを適用する
- 同じ変更の微妙なバリエーションを統一する
- テストスイート全体に一般化する
- 適切なコミットにまとめる
sleepの明示的な呼び出しはそれだけで即座に怪しいと判断できるが、「この追加は本当に効果があるか」をClaudeに再確認させるために、また数百回のテスト実行が必要になる場面もあった。
筆者が整理した3つの反応
筆者はこの体験を通じて、自分の中に3つの反応があったと述べている。
①「まだ自分が役に立った」という安堵。 RailsとRSpecの10年以上の経験がなければ、Claudeの提案を持続可能な形に整理するのは不可能だった。ノイズと本質を見分ける判断軸そのものが、長年の経験から来ている。
②「AIはひどい」という不満——ただし筆者はすぐに否定している。 人間が何年も解けなかった並行処理に関するコードの問題を、ClaudeはおそらくContext取得に10分かかっただけで推論できた。数時間単位の待機をはさみながら細かな変更を繰り返すという作業は、そもそも人間の得意な仕事ではない。また、テストがフレイキーであっても「コードが何をすべきか」の記録としては有効で、Claudeのコード理解を助けたという観察も興味深い。不満はもっともだが、視点を変えれば「人間が苦手なことをAIが担い、AIが生んだ混乱を人間が整理する」という分業として読める。
③「なぜ2週間も続けたのか」という自問。 AIが一晩でCIを通過させたなら、そこで終わりにして2週間を節約することもできた。しかし放置すれば、人間もAIエージェントも新しいアンチパターンをカーゴカルトし、将来の本当の問題を隠蔽する。「先に整理してから作業する」という原則は、AIが出力したコードにも同様に適用される。
「AIが解いた」と「チームが使える状態になった」の間には、ドメイン知識と地道な検証作業が詰まっている。この2週間を惜しんだ場合に何が起きるかを想像すれば、後処理のコストは単なる非効率ではなく、技術的負債の予防に払った費用だったとも言える。AIツールの導入を検討するチームにとって、見積もりに含めるべき工数の議論として参照価値が高い。
詳細はAI's "overnight" solution for our flaky tests took two weeks to adoptを参照していただきたい。
