AIに渡すテストデータを作る｜個人情報を使わず境界条件を再現する

再現に必要な項目だけ選ぶ

一覧検索の不具合なら、表示名、任意項目、検索対象の文字列など、判定に必要な項目を選びます。実際のメールや電話番号、住所を持ち込む代わりに、最初から架空の値で作ってください。問題と無関係な列を減らすと、AIも人も条件を読みやすくなります。ただし、形式や長さが不具合に関係する場合は、その構造まで消さず、同じ条件を満たす人工的な値を用意して再現性を保ちます。

正常・境界・失敗を分ける

正常に動く一件だけでは、修正後に必要な範囲を確認できません。任意項目あり・なし、空文字、該当なし、長い文字列など、今回の処理に関係する条件を並べます。全条件を無限に組み合わせるのではなく、どの判定を確認するための一件かをラベルで残してください。AIが見本を増やした場合も、各行が説明できるかを見ます。件数が多いことと、重要な境界を含んでいることは別です。

期待値を生成結果から作らない

テスト対象のコードで結果を作り、そのまま期待値として保存すると、同じ誤りを正解として固定することがあります。見本が小さい段階で、人が仕様を読んで件数や表示内容を決めます。期待値に迷うなら、実装を直す前に仕様を確認してください。AIへ期待値の候補を頼む場合も、根拠となる条件と照合します。テストが通ることより、なぜその答えが正しいかを別の担当者へ説明できることを重視します。

作成と後片付けを一組にする

データベースや外部サービスへ見本を作る場合は、どこへ作り、どの識別子で消すかを先に決めます。本番接続が残った設定で実行しないよう、対象環境を確認してください。広い条件で既存データを消す後片付けは避け、今回作成した範囲だけを扱います。Playwrightのfixtureのように準備と終了処理をまとめる仕組みを使う場合も、実際の外部データが自動で戻ると決めつけず、所有する資源の後片付けを明示します。

テスト間の状態を分離する

前のテストのログイン状態、保存値、作成データが残ると、単独では失敗する処理がまとめ実行で通る場合があります。ブラウザの文脈を分け、共有が必要な設定と毎回初期化する状態を整理します。Playwrightの分離されたブラウザコンテキストも、サーバー側の共有データを勝手に分離するわけではありません。並列実行するなら識別子の衝突も確認し、順序を変えても同じ期待値になるかを必要に応じて確かめます。

共有する前に見本を読み直す

名前だけを置き換えても、自由記述、添付ファイル名、URL、時刻、ログに実際の情報が残る場合があります。共有前に、人が見本の全項目を読み、今回の再現に必要かを確認します。認証情報や実際の接続先を含む設定を一緒に貼らず、必要なら変数名と役割だけを説明してください。機械的な置換を匿名化完了の根拠にせず、実データから離れた小さい人工例へ作り直せるかを検討します。

修正後も使える回帰用の見本へ残す

修正後は、見本の目的、期待値、作成方法、確認コマンドをコードと一緒に残します。例えば「部署がない顧客も検索対象に残る」という一つの条件が分かる名前にすると、後で仕様が変わった時に更新しやすくなります。架空の見本がいつの間にか実際の顧客データへ置き換わらないよう、保守の方針も記録してください。不要に大きくなった見本は役割を見直し、再現と後片付けを説明できる規模に保ちます。

• AIでユニットテストを作る｜正解の根拠と境界値を確認する
• AIへ渡すコードの文脈を絞る｜必要な情報と送信範囲
• 開発エージェントの権限設計｜読み取り・編集・公開を分ける