「保存しました」を信じてはいけない｜GPT-6 Astraの自動テストが人の見逃しを拾った話

バイブコーディングの「直したら壊れた」を防ぐ2つの実践スキル

著者: I.T. | AIエキスパート

AIに頼んだ修正が終わり、画面を開いて確認すると、ちゃんと動いている。これで終わったと思っていたのに、数日後、利用者から「前はできたのに、今はできません」と連絡が来る。そんなとき、壊れているのは修正した画面とは別の場所だったりします。

一か所直すたびに、ログインから設定まで全部触り直す。最初は頑張れても、修正が増えるとつらいですよね。かといって、AIの『問題ありません』だけで公開するのも落ち着かない。この面倒な確認を、毎回ゼロからやり直さずに済むようにしたくて、回帰テスト用のスキルを作りました。

使ってみると、何人かで確認しても見つからなかった不具合が出てきました。保存は成功しているのに、触っていない情報が消えていたんです。第19章で、業種や項目を置き換えて紹介します。自動でクリックさせるだけでは拾えない、不気味な壊れ方でした。

手順の説明には、架空の開発者ユイと相棒リグ、予約アプリ『ひだまり予約』が登場します。第19章だけは実際の発見をもとにした再構成例です。実在する人やサービスが分からないように変更しています。なお、同じスキルを使えば同じ不具合が必ず見つかる、という保証はできません。確認できる範囲は、渡す仕様やデータ、実行環境で変わります。

なぜ、いまテストの自動化が必要なのか

AIでアプリを作っていると、入力欄や並び順を変えたり、通知を足したりと、改善を重ねやすくなります。コードを書く負担が減っても、変更後の確認には時間がかかります。修正を入れる回数が増えるほど、この負担も増えていきます。

修正は短時間で済んでも、確認は相変わらず手作業。『今回は小さい変更だし』『この画面は昨日も見たし』と、少しずつ省きたくなります。悪気がなくても、そうなる。見ていない場所が壊れていたら、次に気づくのは利用者です。

一画面しか直していなくても、その画面が使う部品やAPIを別の機能が使っていることがあります。日付の渡し方を変えたら、管理画面の取り消し処理が動かなくなる。そんなつながりは、見た目だけでは分かりません。人が書くコードでも起こる問題ですが、AIで変更を重ねるなら、確認の回数もそれに合わせる必要があります。

手動確認だけでは、結果が人と状況に左右される

実際に触らないと分からないことはあります。説明が読みにくい、押したつもりのボタンが押せていない、次に何をすればいいか迷う。こういう確認は残したい。一方、予約を一件入れて、取り消して、枠が戻ったか見る。同じ確認を毎回繰り返す部分は、機械に渡せます。

時間がない日は確認を途中で切り上げ、担当者が変わると見る場所も変わります。普段の成功操作は試せても、権限の違う利用者や空欄、上限値、二重送信まで手が回らないこともあります。試した条件を記録していなければ、一週間後に「確認済み」と言われても、どこまで確認したのか分かりません。

一度手順を書けば、次の修正でも同じ操作を実行して、前回と比べられます。失敗したら記録も残る。『どこまで見たっけ』を思い出す負担が減るので、人は新しく変えた機能や、使いにくさの確認に時間を使えます。

必要なのは、本数ではなく「戻っていない」と分かる基準

最初は、予約を一件登録するテストだけでも構いません。慣れてきたらログインや、保存後に既存の設定が残ること、他人の情報を見られないことも加えます。まずは利用者にとって欠かせない操作を一つ選び、変更のたびに同じ条件で確かめるところから始めます。

AIが現在の動作をそのまま正解にすると、すでにある不具合に合わせたテストができてしまいます。予約が二件できる状態を正解にしてしまえば、テストは通っても利用者は困ります。付属する二つのスキルでは、期待する結果を先に書き、確認する範囲と失敗時の記録も決めてからコードを作ります。

一度作ったテストケースを次の修正でも実行できれば、確認のたびに操作手順を思い出す手間が減ります。

GPT-6 Astraで、始めるための壁が下がった

回帰テスト自体は新しい考え方ではありません。それでも個人開発や小さなチームでは、後回しになりがちでした。仕様を整理し、影響範囲を読み、テストケースを書き、失敗時の画面やログを調べ、テスト側の誤りか製品側の不具合かを切り分ける。コードを自動生成するだけでは終わらない仕事だからです。

GPT-6 Astraによって変わったのは、この「考えて整理する部分」までAIエージェントと進めやすくなったことです。仕様、変更差分、既存コード、過去の不具合、実行結果をまたいで読み、今回守るべき操作の候補を出す。Playwrightを使って確認し、失敗時のトレースやスクリーンショットから次に見る場所を絞る。人が一つずつ資料を往復していた作業を、一続きの流れとして組み立てられます。

Astraへは、『全部確認して』よりも、仕様と変更差分、今あるテストを渡して『今回、確認から漏れそうな操作はどれ？』と頼みます。決まった操作はPlaywrightで繰り返す。営業時間や権限のルールが曖昧なら、人が決める。この分担で進めます。

『自動テストは、詳しい人が時間をかけて作るもの』と思っていた方に、ここを試してほしいんです。Astraと、最初の一本を考えるところから始められる。付属のスキルには、毎回頼み方を考え直さなくて済むように、その順番を入れました。

第1章　直した場所だけ見ても足りない

予約フォームの日付を選びやすくする修正を入れました。表示に崩れはなく、試しに一件登録すると予約も通ります。

ここまで見れば、つい「修正完了」と言いたくなります。

ところが翌日、管理画面から予約を取り消そうとすると、ボタンを押しても一覧から消えません。修正したのは利用者向けフォームなのに、壊れたのは管理画面です。

ユイは新しいカレンダーを開き、一件予約してみます。受付番号も出た。公開しようとしたところで、リグに止められました。『管理画面から取り消す方は、試した？』。そこは触っていません。

「直した場所が動く」と「アプリ全体が前と同じように動く」は別です。

日付入力を変えたときは、フォームが送るデータの形式も確認します。同じAPIや部品を管理画面でも使っていれば、そちらの処理にも影響するためです。変更したファイルだけを見て、確認する範囲を決めることはできません。

回帰テストでは、昨日までできていたログインや検索、登録、取り消しが、変更後も動くかを確認します。壊れると困る操作をテストケースにしておけば、修正のたびに同じ条件で試せます。

人が頭の中だけで覚えていると、忙しい日に一つ飛ばします。確認する順番も人によって変わります。だから操作と期待結果をテストケースに残し、Playwrightに繰り返させます。

AIには、抜けている条件を探す仕事と、失敗した証拠を整理する仕事を任せます。「大丈夫そうです」という感想は合格の証拠にしません。決めた条件を実行し、その結果が合っているかで判断します。

ユイが最初に選んだのは、予約して、管理画面で取り消す流れでした。自分のアプリなら、どの操作が止まると一番困るでしょうか。まずはそこだけで十分です。

第2章　自動テストが守るもの

「ボタンを自動で押せた」。それだけでは、テストが成功したとは言えません。

自動テストが確かめるのは、変更前に決めた約束です。変更後も同じ条件で、その約束が守られているかを見ます。

予約アプリで一件登録したときは、完了画面と受付番号が出ることに加え、保存されたデータが一件で、管理画面にも同じ予約があることを確かめます。取り消した枠が再び選べるか、他人の予約が見えないかも、それぞれ別のケースで確認します。

ユイが最初に見ていたのは「予約しました」の表示だけでした。ところが、表示は一回でも保存データが二件できることがあります。逆に保存は済んでいるのに、通信が遅れてエラー表示になることもあります。

そこで、画面に見える結果と、裏に残るデータを分けて書きます。

• 何を始める前に用意するか

• どの操作をするか

• 画面で何が見えるか

• データがいくつ、どの状態で残るか

• やってはいけない操作が拒否されるか

ここを決めずにAIへコードだけ書かせると、今動いている状態をそのまま「正解」にしてしまいます。二件登録される不具合がすでにあっても、件数を見ないテストは緑になります。緑色の表示より先に、何を守るテストなのかを言葉にしておく必要があります。

自動化すると、準備、操作、期待結果を同じ順番で繰り返せます。人は、見た目の違和感や使いにくさなど、機械が拾いにくい部分へ時間を使えます。

『予約できた』の一言を、件数と状態まで分けて書いてみてください。ここがぼんやりしたままだと、何本テストを作っても、表示の裏で起きた異変を見逃します。

第3章　AIとPlaywrightの役割を分ける

AIへ「アプリを全部テストして」とだけ頼んでみる。すると一回目は入力欄を細かく見て、二回目は画面遷移を多く試す、といった具合に着眼点が変わります。探索では助かりますが、昨日と今日を同じ条件で比べたいときには困ります。

Playwrightは反対です。書かれた手順を何度でも繰り返せますが、「この金額の境界が危ない」「一般利用者にこの画面を見せてはいけない」とは考えてくれません。

ユイとリグは、仕事を三つに分けました。

AIは、仕様、変更差分、既存テスト、過去の不具合を読みます。そこから入力不備、境界値、権限、二重送信、通信失敗など、見落としやすい候補を出します。失敗後は、トレースや通信記録を並べて原因候補を絞ります。

Playwrightは実行係です。ブラウザを開き、決めた要素を操作し、決めた結果と一致するかを機械的に確かめます。

人が受け持つのは、「何を正しいとするか」です。資料同士が食い違ったときに判断し、認証、決済、個人情報、削除のような失敗時の影響が大きい変更を確認します。

AIがテストの期待値も自由に変えられると、不具合のある動作に合わせてテストを通してしまうおそれがあります。期待値を変更するときは、仕様や人の判断を根拠として示すルールにしておきます。

リグが候補を出しても、営業時間の終わりを18時にするか、18時の予約も受けるかは、ユイが決めます。決めた条件をPlaywrightへ渡す。後で失敗しても、勝手に条件を書き換えないための分担です。

第4章　最初に守る一本を決める

自動テストを作ろうとして画面一覧を開くと、すぐに手が止まります。設定、検索、プロフィール、通知。全部を対象にしたら、いつまでたっても実行まで進みません。

最初の一本は、壊れたときに利用者がどれだけ困るかを考えて選びます。

ユイの予約アプリなら、予約の新規登録が第一候補です。ここが壊れると利用者は目的を果たせません。次に管理者のキャンセル、重複予約の防止、権限の分離が続きます。文字色の微調整より先です。

候補を三つだけ書き出し、次の質問を当ててみてください。

• 壊れたら利用者の目的が止まるか

• お金、個人情報、予約枠などのデータが誤るか

• 変更のたびに人が確認しているか

• 過去に似た場所が壊れたか

• 準備データを安定して作れるか

影響が大きく、テスト用データを用意できるものを一本選びます。ログインから全画面を巡る長いシナリオにする必要はありません。予約登録を守るなら、利用者と空き枠は先に準備し、ブラウザでは予約操作へ集中します。

ログイン機能を確認したいテストでなければ、毎回ログイン画面を通す必要はありません。Playwrightの保存済み認証状態を使えば、目的外の失敗を減らせます。ただし、本番のCookieや実アカウントの認証情報は保存しません。

一本が毎回同じ条件で動いたら、取り消しや権限も足していきます。最初から広げすぎると、失敗の原因がアプリなのか、準備の不備なのか分からなくなるので、ここは急がなくていいところです。

ここまでなら、『毎回、前の機能も確認しよう』で済む話です。でも、分かっていても続かないから困るんですよね。毎回どこを見るか考えて、データを用意して、同じボタンを押す。その手間を残したままでは、忙しい日にまた省いてしまいます。

続きでは、ユイの予約アプリを使って、一本の確認を実際のテストケースにします。空欄、二度押し、別の利用者のデータも試す。赤くなったら、アプリを直す前に原因を分ける。自分の開発フォルダでも同じ順番で始められるように、スキル本体と記入用の雛形を付けています。

この先で持ち帰れるもの

• 架空の予約アプリを題材に、最初の一本をテストケースへ落とす手順

• 境界値、権限、二重送信など、人の確認で抜けやすい条件の作り方

• 失敗を七つに分類し、直すべき不具合とテスト側の問題を切り分ける方法

• 通常のAIエージェントで使える標準版スキルと、GPT-6 Astra向けQA Lead版スキル

• 人が複数人で確認しても見つけられなかった「保存すると触っていない情報が消える」不具合を、スキルがどう拾ったかを匿名化した実例

購入後、すぐ使える3つの特典

購入者向けのダウンロードページを末尾に載せています。中に入っているのは、次の3点です。

特典1　AI回帰テスト標準版スキル

普段使っているAIエージェントで、変更差分の確認、テストケース作成、Playwright実行、失敗分類、修正後の全回帰までを同じ順番で進めるためのスキル本体です。「何を頼めばいいか」から考え直さず、開発フォルダへ導入して使い始められます。

特典2　GPT-6 Astra QA Lead版スキル

仕様、変更差分、既存テスト、トレース、通信記録を横断して、テストの抜けや原因候補を探すAstra向けの強化版です。正解を資料から決められない場合は、AIが勝手に補わず、人が判断すべき項目として返すルールも組み込んでいます。

特典3　テストケース雛形・失敗分類シート

最初の一本を迷わず書くためのケース雛形と、赤くなった原因を7種類へ分ける記録シートです。予約アプリ用の開始セットも付けているため、自分のアプリへ置き換えながら使えます。

ダウンロードした後で迷わないように、フォルダの置き方と、AIへ最初に貼る依頼文も載せました。テストが失敗したときに読む記録、修正後にもう一度確認する範囲まで、一通り追えます。

次の修正でも、自分で全画面を触り直すことになりそうなら、ここから先を使ってください。最初に選んだ一本を、次回も実行できる形にしていきます。