自動テストや自動チェックが失敗したとき、やり直す前に確認したい4つの順番

この記事で分かること

AIに実装や作業を任せていると、最後の確認で自動テストが失敗して、作業全体が止まることがあります。そのとき、同じ指示でやり直す前に何を見るかで、手戻りの量は変わります。J-WORKSで実際にあった2件の記録から、確認の順番を4段階にまとめました。

順番1: 失敗した1件の中身を、先に読む

商品づくりの仕組みを1つにまとめる準備の実装で、全体テストのうち1件だけが失敗しました。コードは保存されたものの、正式な記録には反映されない状態で止まっていました。ここですぐ同じ内容でやり直さず、失敗した1件のテストの中身を先に確認しました。そのテストは、特定の3つのファイルの中身を文字として調べ、「まだ本番で使っていない別の新機能」に関係する単語が含まれていないことを確かめる、以前からの安全チェックでした。実際にファイルを見ると、今回の追加が、その単語を処理の名前や説明文に使っていました。詳しくは「まだ混ぜてはいけない」を守る安全チェックが働いた話にあります。

順番2: その失敗が、今回の変更と関係しているかを確かめる

Excel商品づくりの作業では、全体テストが47個のファイルで失敗していました。調べると、原因は共有のテスト用データベースが汚れていたことで、この作業が書き込んだ内容とは関係がありませんでした。この作業はもともと、表計算のデータファイルしか書き込みません。関係のない失敗かどうかは、失敗の原因を読まないと分かりません。詳しくはExcel商品を作るAIの作業が、毎回約10分の全体テストを走らせていた不具合にあります。

順番3: チェックを緩めずに、原因のほうを直す

先の安全チェックの件では、チェックそのものを緩めることもできました。実際には、チェックの内容(何を禁止するか)は変えず、審査の仕組みへ記録を渡す処理だけを、チェックの対象になっていない新しいファイルに切り出しました。対象の3ファイルは、その単語を使わない名前と説明で新しいファイルを呼ぶだけの形になりました。2回目の実装は最後まで完了し、新しい機能のテスト25件と、安全チェック自体のテスト29件を含む合計816件が、すべて合格しました。

順番4: 失敗が、正しい成果物まで捨てていないかを見る

Excel商品づくりでは、全体テストが1件でも失敗すると、作業全体が失敗として扱われていました。そのため、正しく作られていた設計データが、不具合があるかのように捨てられていました。原因は、作業の登録上の種類が「コードを書き換える作業」になっていたことで、2026年9月19日に「コードは書き換えない作業」に変えました。もし実際にコードへ変更が及んだ場合は、その時点で作業を失敗として止める仕組みが別にあるので、安全確認は緩めていません。

4段階をまとめると

1. 失敗した1件の中身を読む。
2. その失敗が、今回の変更と関係しているかを確かめる。
3. チェックは緩めず、原因のほうを直す。
4. 失敗の扱いが、正しい成果物まで捨てていないかを見る。

この4段階は、2件の記録からの編集部の考察です。すべての自動テストに当てはまると確認したわけではありません。

まだ分かっていないこと

Excel商品づくりの修正で、実際にどれだけ速くなったかは、この記録の時点では実測していません。「全体テストが走らなくなる仕組みに直したこと」までが確認済みです。

根拠

2026年9月19日・9月22〜23日のJ-WORKS内部の実行記録と、同時に追加した検証テストの結果をまとめた記事です。数字は、上に挙げた記録ページの内容と同じです。