AIが書いたテストは全部成功。それでもマージ前に利用者の動きを確かめる理由
水曜の17時26分。翌朝に操作説明を控えたレンタルスタジオの予約システムで、「予約日時をあとから変更できる機能」をAIエージェントへ任せていた。
依頼したのは、変更画面の追加、予約データの更新、テストの作成だ。返ってきた報告には、変更したファイルとともにこう書かれていた。
予約変更機能を実装しました。追加したテストを含む全24件が成功しています。
緑色の結果が並ぶ画面を見て、肩の力が抜けた。予定より早い。今夜は別の仕事へ進める。あとはマージして、運営担当者へ「準備できました」と返せばよい。
念のため開いた確認画面で、運営担当者が壁の予約表を指した。
新しい時間には移っていますね。前の時間は、別のお客さんが予約できる状態に戻りますか？
言われて初めて、変更前の枠を見ていないことに気づいた。新しい予約は表示されている。しかし、元の19時枠にも同じ利用者の名前が残っていた。
テストは全部通っている。ここで問題を認めれば、説明会までに修正が増える。「古い枠の解放は別の対応です」と言えば、今日は閉じられるかもしれない。AIへ機能もテストも任せた自分の判断が浅かったと思われるのも怖い。
すぐ返事をせず、もう一度テスト名を開く。確認されていたのは「変更後の日時が保存されること」だけだった。変更前の枠が空くことも、途中で保存に失敗した時に元の予約を守ることも書かれていない。緑色は正しかった。ただ、見ている範囲が足りなかった😰
テスト成功は、書かれた期待どおりにコードが動いた証拠だ。利用者に必要な期待をすべて書けた証拠とは限らない。
AIが実装とテストをまとめて作った時は、テストの数を増やす前に、利用者の結果、失敗時の結果、今回のコード以外で決まっている運用ルールの3つへ戻る。そこまでつながって初めて、緑色の結果をマージ判断に使える。
実装とテストが同じ前提から作られることがある
AIにテスト作成を頼むこと自体が問題なのではない。繰り返しの多い確認を短時間でそろえ、既存の書き方に合わせてもらえる。自分では忘れていた入力値や境界を候補として出してもらえることもある。
ただし、AIは渡された依頼文、開いているコード、既存テストから「何が正しいか」を考える。依頼に書かなかった業務上の約束は、実装にもテストにも入らないことがある。
全件成功は「用意した問いに答えた」という意味
予約変更の実装では、AIは新しい日時で予約データを更新した。テストも、その更新後の値を読み、指定日時と一致することを確かめていた。実装とテストは矛盾していない。
しかし、スタジオ運営に必要なのは一つの値の更新ではない。
- 利用者には変更後の予約が一つだけ見える
- 変更前の枠は、ほかの利用者が選べる状態へ戻る
- 決済や通知の処理に失敗したら、予約が二つとも失われない
- 運営側の一覧と利用者への確認メールが同じ日時を示す
このうち最初の一部しか問いにしていなければ、全問正解でも機能全体の正しさには届かない。
GitHub Docsのテスト作成ガイドも、Copilotが生成したテストはすべての場面を扱うとは限らないため、内容を確認し、必要なテストを追加するよう勧めている。AI生成コードのレビューガイドでは、自動テストを最初に実行したうえで、コードが要求や設計に合っているか、見落とした複雑な場面がないかを別に確かめる流れを示している。
つまり、「テストを通す」と「正しい問題をテストしているかを見る」は、順番にはつながっていても役割が違う。
安心したあとほど、問いを増やしたくなくなる
緑色の結果を見たあとは、頭の中で仕事を完了へ移している。そこから確認を増やすと、終わったはずの仕事を自分で戻す感じがする。
締切が近い時は、問題を見つけること自体が怖い。追加の修正時間を説明しなければならない。AIで速く作れると話していたなら、なおさら「確認に時間がかかる」と言いにくい。その気持ちが、テスト名だけ眺めて中身を読まない、気づいた違和感を別の対応として先送りする、相手へ大丈夫だと即答する行動につながる。
ここで必要なのは、AIの仕事を最初から疑い直すことではない。見る場所を3つに限定し、空いているところだけ埋めることだ🔍
1. 利用者が最後に見る結果を、一文で書く
最初にコードとテストを閉じ、機能を使う人の言葉で成功を書いてみる。
今回なら、「予約日時を変更できる」だけでは広い。次のように、操作の前後を一文にする。
19時のスタジオAを予約している利用者が20時へ変更すると、利用者の画面には20時の予約だけが表示され、19時は別の利用者が選べる。
この一文には、変更後の予約、変更前の枠、利用者画面という3つの確認先が入る。実装の関数名やデータの持ち方は書かない。
Playwrightの公式ガイドは、自動テストで関数名やCSSクラスのような内部の作りではなく、利用者が見て操作する振る舞いを確かめることを勧めている。すべてを画面テストにするという意味ではない。単体テストでも、期待する結果を利用者の一文からたどれる状態にする。
テスト名を見た時に、この一文のどこを証明しているか言えなければ、テストが不要なのではなく、マージ判断とのつながりがまだ弱い。
予約変更では、既存の「新しい日時が保存される」テストに加え、「元の枠を別の利用者が予約できる」確認を追加した。コードの中の値ではなく、予約を探す人が得る結果まで見ることで、残っていた19時枠の問題を再現できた。
2. 失敗した時と、元に戻す時の結果を書く
次に、順調に終わらなかった時を一つだけ選ぶ。考えられる失敗を全部並べる必要はない。利用者の損失が大きいもの、現場で起きやすいものから決める。
予約変更なら、決済の再確認、通知送信、データ保存の途中で止まる可能性がある。ここで確かめたいのは、例外という専門用語ではなく、利用者の予約がどう残るかだ。
20時への変更処理に失敗したら、19時の予約は消さず、利用者へ変更できなかったことを表示する。
この結果を決めずに、先に古い予約を消す実装を作ると、新しい予約の保存に失敗した時に両方を失う。反対に、新しい予約を作ったあと古い予約を消せなければ、今回のように二つ残る。
正常に終わるテストだけが通っていると、処理の途中は見えない。「失敗させる入力」だけでなく、失敗後に何を残し、何を戻すかまで期待へ入れる。
水曜は、保存処理を意図的に失敗させるテストを追加した。最初の実行では、元の予約まで消えて失敗した。そこで、変更に必要な処理がすべて成功してから予約状態を切り替えるように直した。テストが赤くなったことで、初めて不足していた条件を捕まえられた。
緑色を増やすことより、直す前の問題で一度きちんと赤くなることの方が、再発を防ぐ証拠になる。
3. 今回のコード以外で決まっている運用ルールと照らす
最後に、「何を正しいとするか」を、今回の実装とテスト以外から一つ確認する。
候補は、依頼チケット、画面仕様、契約上の条件、運用手順、過去の問い合わせ、担当者の確認だ。書類がなければ、利用者に近い人へ具体的な場面を聞く。
今回、依頼文には「日時を変更できるようにする」としか書かれていなかった。運営担当者へ聞くと、変更前の枠をすぐ販売へ戻すこと、変更失敗時は元の予約を維持すること、確認メールは一通だけ送ることが必要だと分かった。
これはAIに考えさせてはいけない領域ではない。候補を出してもらい、抜けを探すことはできる。ただし、どの候補をこのスタジオの約束にするかは、実際の運営ルールを知る人と決める。
GitHubが2026年5月に公開した、画面を操作するAIエージェントの検証実験では、エージェント自身の成功判定よりも、必ず到達すべき画面状態を外側で定義した検証の方が正確だった。対象は一般的なアプリの単体テストではないため、結果をそのまま広げることはできない。それでも、作業した側の自己判定だけにせず、成功の基準を外へ置くという考え方は、AIが実装とテストを作る場面にも使える。
NISTの安全なソフトウェア開発の手引き（SSDF）も、コードの確認と実際に動くソフトウェアのテストを分け、危険の大きさに応じて複数の確認方法を組み合わせる考え方を示している。一つの緑色へすべての保証を背負わせず、運用ルール、コード、自動テスト、利用場面をつなぐ。
15分で、テストをマージ判断の証拠へ変える
毎回、別の人に全テストを書き直してもらう必要はない。小さな変更なら、次の順番で15分だけ使う。
- コードを見ず、利用者の成功を一文で書く
- 失敗した時に守るものを一文で書く
- 2つの一文を決めた根拠を、依頼文か担当者へ戻って確認する
- 既存テストがどの文を確かめているか対応させる
- 空いている結果を一つ追加し、修正前には失敗、修正後には成功することを見る
AIには、この作業でも助けてもらえる。「この利用者の一文で、今のテストが確認していない結果を挙げて」「変更前の枠が残る不具合を再現するテストを追加して」と頼める。
ただし、AIが出した追加テストも、同じ2つの一文へ照らす。テストの作者を人へ変えることが目的ではない。期待する結果の出どころを、実装だけに閉じないことが目的だ。
AIの完了報告を3つの証拠で確認する方法では、差分、自動チェック、実際の利用場面をつなぐ全体像を扱った。今回の3つは、その中の自動チェックが「何を確かめた緑なのか」を深く見る方法だ。AIレビューで見る観点と合わせれば、影響範囲や運用上の危険まで広げられる。
問題を見つけた時は、遅れではなく判断材料として伝える
二重予約を見つけたあと、運営担当者へこう返した。
新しい日時の保存はテストできていましたが、変更前の枠を戻す確認が不足していました。いま二重予約を再現するテストを追加し、修正後は元の枠を別の利用者が選べることまで確認しました。変更に失敗した場合は元の予約を維持します。
最初は、足りないテストを認めると信頼を落とすと思っていた。実際には、何が確認済みで、何を追加したかを分けると、言い訳をせずに状況を渡せた。運営担当者も、翌朝の説明でどこを見せればよいか選べた🙂
AIで作業が速くなるほど、人の役割はテストコードを一行ずつ手で書くことから、この仕事では何が起きたら成功なのかを、利用者の言葉で決めることへ移る。
次に「全テスト成功」の報告を受け取ったら、緑色を疑い続けなくていい。利用者が最後に見る結果、失敗後に守る結果、その期待を決めた業務ルールの3つを確認する。空欄があれば、そこだけAIと一緒にテストへ足す。
テストが通ったからマージするのではなく、必要な利用者の結果を証明するテストが通ったからマージする。 その一段が、AIの速さを、現場で受け取れる品質へ変える。
AIに任せる範囲と、マージ前に見る結果を整理する
ページへ移動参考にした情報
- GitHub Blog「Validating agentic behavior when “correct” isn’t deterministic」（2026年5月6日公開、2026年5月26日更新、2026年8月12日確認）
- GitHub Docs「Writing tests with GitHub Copilot」（2026年8月12日確認）
- GitHub Docs「Review AI-generated code」（2026年8月12日確認）
- Playwright「Best Practices」（2026年8月12日確認）
- NIST「Secure Software Development Framework (SSDF) Version 1.1」（2022年2月公開、2026年8月12日確認）
