画面レビューで使える「危険信号チェック」

なぜ書いたか

UIレビューを「見た目が同じか」から始めると、危険な操作の差分を最後まで見つけられないことがあります。「危険信号」だけは最初に見にいく という運用に切り替えてから、ブロッカーを早く拾えるようになりました。今回はその観点リストの話です。

危険信号リスト

レビュー時に最初に見るのは、以下の4つです。

1. 破壊的コントロール: 削除、決定、確定、取消ボタン。元実装と同じテーブル・条件・権限で動くか
2. 決定済み行のロック: 「もう確定された行は触れない」のような業務ルールが正しく実装されているか
3. モード別の制約: 履歴モード時の操作可否。最新モード時の操作可否
4. 権限分岐: 高権限ユーザーのみ、特定ロール限定の操作

これらはUIを見ただけでは分かりません。コードと業務シナリオを両方見る必要があります。

観点ごとの典型バグ

破壊的コントロール

• 削除ボタンが違うテーブルを消している
• 決定ボタンの保存先SQLが古い
• 取消ボタンがロールバック処理を呼んでいない

業務同等性の話 と被ります。一番事故ったのもここでした。

決定済み行のロック

• 決定済みの行に対する編集ボタンが押せてしまう
• 決定後に削除可能になっている（業務ルール上NG）
• 決定状態のアイコン表示が違うステータスを参照している

モード別の制約

• 履歴モード時に削除が押せる（元実装ではブロック）
• 最新モード時に履歴専用の操作が見える
• モード切り替え時に状態がリセットされない

権限分岐

• 高権限者専用ボタンが一般ユーザーに見えている
• API側に同じ権限ガードがない（二重防御の話）
• 権限フラグの計算式がUIとAPIでズレている

やったこと

Reviewer Sub Agentのチェックリストに、上記の4観点を 固定で必ず確認する項目 として組み込みました。AIレビューでも人間のレビューでも、最初にこれだけはスキャンする。見た目のチェックはその後で。

わかったこと

• 危険信号の観点を 固定リスト化 すると、レビューの抜け漏れが激減します
• 「全部チェック」ではなく「これだけは外さない」観点を絞るのが現実的
• AIレビューに固定観点を渡すと、自由レビューより指摘の精度が上がります。「自由に見て」はAIに向かない

次にやること / 未解決の問題

• 危険信号リストを画面種別ごとにカスタマイズしたい（マスタ系 / トランザクション系 / レポート系で見るべき観点が違う）
• 決定済み行のロックは、UI側の disabled だけでなくAPI側の IsDecided チェックも要る。ここの自動テストカバレッジを上げたい