実行済みの合成テスト · 2026年9月8日

実行した証拠と、証明できた範囲。

予約の保存処理を欠いたコードで失敗を検出し、ソースを修正してから復旧を確認しました。結果と実行記録を公開します。

テスト情報を使ったローカルアプリでの検証です。修正は担当者が作成した差分の再現実行であり、AIの自律修復や実顧客での成功実績ではありません。

保存結果を確認済み

1. 予約が正常に動く

ブラウザで固有のテスト番号を送信。別の読み取りで、その予約が保存されたことを確認。

失敗を検出

画面も完了表示も正常に見え、予約APIも201を返します。しかし保存結果の読み取りは404。検査は失敗と判定し、ローカルの通知先が障害通知を受信。

保存結果を確認済み

担当者が作成した修正で保存処理を戻し、アプリを再起動。同じ合格条件で操作を再実行し、新しい予約の保存と以前の記録の保持を確認。

3回とも画面内のテストモード表示はhealthyのままです。2回目はソースファイルの保存処理が欠けているため失敗します。この修正はモード切替ではありません。

何を合格条件にしたか

実行ごとに新しい番号を使い、ブラウザ操作、応答、完了表示、別の読み取りによる保存記録のすべてを確認します。完了表示が出ても、保存記録がなければ復旧通知は出しません。

成功応答の前に保存処理を戻し、書き込みの完了を待ちます。

await writeFile(recordPath, JSON.stringify(record));
send(201, record);

上は要約したコードです。正確な差分とソースは下から取得できます。

12回のブラウザ実行で、故障、重複通知の抑制、通知の再送を確認しました。1つのテストアプリで条件を決めた検証であり、未知のアプリでの成功率ではありません。

通知はローカルの受信先への実HTTP送信で確認しました。未設定・拒否時には保留して再送します。この試験で、実顧客のメールやチャットへの到達、担当者の受領を確認したわけではありません。

実行日時、検査結果、通知ID、ソースのハッシュを含む記録です。画面にはテスト情報のみを使用しています。

対象アプリ、安全に繰り返せる予約、保存結果の確認方法、通知先、運用頻度を先に決めます。そのアプリでの初回確認と書面の提供条件を確認してから、月額利用を判断できます。