実データ（機密・個人情報でリポジトリに置けない入力など）でしか再現しない不具合を合成データで固定しようとして、何度やっても再現しないことがある。このとき「この不具合は合成では作れない」と結論しやすいが、実際には「不具合を成立させている条件をまだ特定できていない」ことの現れであることが多い。同じセッションで、機序が曖昧なうちは3案とも失敗し、后に「どの辺の信号が欠けているか」まで特定できた後は2回の調整で合成再現が成立した。

判断基準

• 合成再現の失敗を「テスト不可能」の結論にしない。まず実データ側で「どの入力特性があると壊れ、ないと壊れないか」を一つに絞り込む。絞れていないうちは、合成のパラメータをいくら振っても当たりにならない
• 逆に、機序が特定できたら合成は短時間で作れる。作るべきは「見た目の再現」ではなく「機序の再現」で、壊れるのに必要な条件だけを作り込む（余分なリアリティは不要）
• 作った合成テストは必ず変更前のコードで実行し、落ちることを確かめる。通ってしまう合成は不具合を再現できていないので、リポジトリに残しても検知力ゼロで有害（守られていると誤認させる）
• 合成パラメータは一発で決めず、機序を握っている変数（ノイズの周期と振幅、境界のなまり幅など）を振って、「旧コードで落ち、新コードで通る」窓を探す。窓の両端も控えておくと、後で周辺実装が変わったときにこのテストがどちらに倒れやすいか判断できる

なぜ

合成は「原因の理解をコードに書き出したもの」であり、再現しないのは理解が足りないことの対偶である。この対偶を使えば、合成の成否自体が原因分析の自己採点になる。

残る制約の扱い

それでも合成できない場合は、実データハーネス依存のままにし、「この変更のうち CI で回帰検知できるのはどこまでか」を明示して引き継ぐ。黙ってローカル検証だけで閉じない。