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

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

ユイ、リグ、予約管理アプリは、手順を追いやすくするために作った架空の物語です。ただし第19章には、付属スキルを実際のシステムへ使ったときに、人の確認では見つからなかった不具合を発見した経験が反映されています。関係者を推測できないよう、業種、項目、数値、登録経路は置き換えました。付属スキルは不具合ゼロを保証するものではありません。結果は、仕様、コード、データ、実行環境によって変わります。

AIに頼んだ修正が終わり、画面を開いて確認すると、ちゃんと動いている。これで終わったと思っていたのに、数日後、利用者から「前まで使えていた機能が動きません」と連絡が来る。バイブコーディングで変更を重ねるときは、修正した画面以外への影響も気になります。

毎回すべての画面を自分で触り直すのは、時間がかかります。AIの「問題ありません」だけで公開するのも不安です。この記事では、守りたい操作をテストケースにして、AIとPlaywrightで同じ条件を繰り返し確認する手順を紹介します。専門のテスト担当者がいなくても、一本ずつ始められるようにしました。

読み終える頃には、「何となく確認した」ではなく、どの操作を、何から守り、何を証拠に合格とするかを自分の言葉で決められる状態を目指します。

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

以前は、一つの機能を作るにも時間がかかりました。設計し、コードを書き、エラーを直す。その間に、人が確認する時間も確保しやすかったのです。AIエージェントの登場で、このバランスが変わりました。数時間かかっていた修正が数分で終わり、思いついた改善を次々と入れられます。

しかし、変更する速度が上がっても、人が確認できる時間は増えません。むしろ修正回数が増えるほど、毎回すべてを触り直すのは難しくなります。「前回も大丈夫だったから」「今回は小さな変更だから」と確認範囲が少しずつ狭まり、見ていない場所に不具合が残ります。

AIが書くコードが特別に危険だから、自動化するのではありません。人が書いたコードでも回帰は起こります。違いは、AIによって変更の回数と範囲が増え、作る速度に確認が追いつきにくくなったことです。見た目は一画面の修正でも、共通部品、API、データ形式、権限判定を通じて別画面へ影響が届きます。作った本人ほど変更した場所へ注意が向くため、離れた機能の異変は見落としやすくなります。

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

手動確認には大切な役割があります。文章の分かりにくさ、操作時の違和感、利用者の迷いは、人が実際に触るから見つけられます。ただし、同じ二十項目を毎回、同じ順序、同じデータ、同じ期待結果で確認し続ける仕事は、人に向いているとは言えません。

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

自動テストを用意すると、決めた操作を同じ順序で実行し、成功と失敗の記録を残せます。繰り返しの確認を任せられた分、人は今回の変更箇所や使いにくさ、仕様の判断に時間を使えます。

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

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

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

テストケースと実行記録が残っていれば、どの操作を確認し、何が未確認なのかを説明できます。確認を担当する人が変わったときも、その記録を引き継げます。

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

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

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

仕様や変更差分、今あるテストをAstraへ渡し、確認から漏れそうな操作を探してもらいます。決まった操作はPlaywrightで繰り返し、営業時間や権限のルールが曖昧なら人が決めます。付属スキルでも、この分担で進めます。

テストを整える時間が取れなかった方も、まずは守りたい操作を一つ書き、Astraとケースを考えるところから試せます。仕様の整理や失敗原因の調査をAIと進め、繰り返す操作をPlaywrightへ渡す。付属スキルには、そのための手順をまとめました。

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

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

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

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

物語に登場する個人開発者のユイも、同じところで手を止めかけました。AIに日付選択の部品を交換させ、直したフォームだけを確認して公開しようとしたのです。そこで相棒のリグが声をかけます。

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

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

修正が離れた機能へ伝わる様子

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

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

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

百本のテストから始めなくて大丈夫です。まず、壊れたら一番困る操作を一本だけ選んでください。ユイは「予約を一件入れ、管理画面から取り消す」流れから始めました。

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

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

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

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

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

操作と表示と保存結果を分けて確認する

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

何を始める前に用意するか
どの操作をするか
画面で何が見えるか
データがいくつ、どの状態で残るか
やってはいけない操作が拒否されるか

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

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

もちろん、テストを増やせば不具合がゼロになるわけではありません。ただ、「前はできたのに」を早い段階で見つける確率は上げられます。まずは本数ではなく、守る約束が書けているかを見てください。

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

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

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

AIが考えPlaywrightが繰り返す役割分担

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

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

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

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

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

GPT-6 Astraのように広い範囲を読めるモデルほど、役割分担を先に決めておきます。Astraが候補を考え、Playwrightが繰り返し、人が曖昧な期待値を決める。この順番は、付属する二つのスキルでも変わりません。

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

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

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

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

重要度と発生しやすさで最初のテストを選ぶ

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

壊れたら利用者の目的が止まるか
お金、個人情報、予約枠などのデータが誤るか
変更のたびに人が確認しているか
過去に似た場所が壊れたか
準備データを安定して作れるか

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

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

一本が安定したら、取り消し、変更、権限へ広げます。十本作って半分が気まぐれに落ちる状態より、約束がはっきりした三本を毎回走らせる方が、異変に気づきやすくなります。ここまで読んで、「まさに今、直した画面しか確認していない」「AIの完了報告を信じるしかなかった」と感じたかもしれません。一方で、自動テストと聞くと、設定やコードが難しそうで後回しにしたくなるのも自然です。

続きでは、ユイの予約アプリを題材に、予約やキャンセルをテストケースにする手順を追います。空欄や二重送信を試し、失敗したときの記録を読み、自分のアプリへ置き換えながら進められる構成です。

この先で持ち帰れるもの

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

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

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

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

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

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

購入者向けのダウンロードページを末尾に載せています。スキル本体に加えて、自分の開発環境で使うための雛形も入っています。

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

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

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

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

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

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

本文には、スキルの配置方法とAIへ最初に渡す依頼文を載せています。実行結果のどこを人が確認するか、失敗したらどの記録を見るかも説明します。

公開後に利用者から知らされる前に、自分で異変を見つけられる開発へ変えたい方は、このまま実践編へ進んでください。