## 背景

- 未入力のまま保存してしまい問い合わせが増加（直近2週間で20件、誤操作率 5%）

## 目的

- 誤操作率を 5% → 1% 以下に低減し、問い合わせを減らす

## スコープ

- 入力フォームの必須項目バリデーション
- エラー文言の具体化（どの項目が不足か）

## 非スコープ

- 画面全体のデザイン刷新
- 文言ポリシーの全画面統一

## 受け入れ条件

- [ ] Given: 必須項目が未入力
- [ ] When: 保存を押す
- [ ] Then: 保存されず、どの項目が不足か分かる
- [ ] 計測: 誤操作率が 5% → 1% 以下（2週間移動平均、例）

## 確認方法

- Given/When/Then: 単体テスト、E2E、手動 UI 確認
- 計測: リリース後2週間の操作ログと問い合わせ件数
- PR で示す証跡: テスト結果、確認画面、メトリクス確認先

## ログ/証跡の分離

- 公開用要約: 個人を識別できない集計で、未入力保存による問い合わせが直近2週間で20件、誤操作率が5%と確認
- 公開可否: マスキング後に公開可
- マスキング確認: 顧客名、メールアドレス、session-id、問い合わせ本文を除去済み（確認者=Issue Owner、確認日=YYYY-MM-DD）
- 公開用証跡: 集計値、マスキング済み画面、テスト結果だけを Issue / PR へ記載
- 非公開証跡の保管先/参照方法: 制限付き記録 `EVD-EXAMPLE-002`。原本確認が必要な Reviewer は Issue Owner へアクセス申請
- 禁止: 元ログ、内部保管パス、認証情報を公開 Issue / PR へ転記しない

## 影響

- リスク: 既存の自動入力が弾かれる可能性
- 依存: 文言ポリシー（別 Issue）と整合が必要

## 根拠・未確定点

- 根拠: 問い合わせログ、操作ログ、CS からの報告
- 未確定点: 文言ポリシーの最終表現、計測期間中の季節要因
- 再確認条件: 誤操作率が 1% 以下に下がらない場合、入力導線を再調査する

## 責任分界（例）

- 判断: PM
- 実行: 開発
- 確認: CS

## 現状

- 子 Issue A は再現できた。原因はサーバ側の必須項目チェック不足
- 子 Issue B は実装中（feature flag で切替）

## 次にやること

- サーバ側のバリデーションを追加し、テストを整備
- E2E で主要導線を確認

## ブロッカー

- 文言ポリシー（レビュー待ち）

## 期限

- YYYY-MM-DD（例）

## 次回更新予定時刻

- YYYY-MM-DD HH:mm（例）

## 支援依頼

- 文言ポリシーの決定（レビュー30分）

## 何を

- サーバ側の必須項目バリデーションを追加（不正入力で500にならない）
- エラー内容を項目単位で返す

## なぜ

- 不正入力が混入すると500になり、利用者も運用も原因が分からない

## 影響

- 影響範囲: 保存 API（入力エラー時のレスポンスが変わる）
- リスク: クライアント側で想定していないエラー形式だと表示が崩れる

## テスト

- 単体: 必須/境界値のテスト追加
- E2E: 作成→保存→エラー表示→再保存

## 受け入れ条件との対応

|Issue の受け入れ条件|対応する変更|確認結果|残タスク|
|---|---|---|---|
|必須項目が未入力なら保存されない|サーバ側バリデーション追加|単体 / E2E PASS|なし|
|どの項目が不足か分かる|項目別エラー文言を返す|手動 UI 確認 PASS|文言ポリシー全体統一は別 Issue|
|誤操作率 1% 以下|計測イベントを追加|PR 時点では未判定|2週間後に follow-up Issue で確認|

## ロールバック

- feature flag を OFF（Runbook に手順を追記）

## レビュー対応メモ

- review 本文・inline comment・suggestion を全件確認する
- 修正する場合はコミットと返信を残す
- 対応しない場合は理由と follow-up Issue を返信する
- 未解決 review thread が 0 であることを確認してから merge する

## 関連 Issue

- #123（親 Issue、例）

結論: 必須項目チェックを追加し、不正入力時に500にならないようにした
変更: PR #456
影響: 入力エラー時のレスポンス形式が変わる（互換性に注意）
運用: Runbook を更新（リンク）。監視ダッシュボードを更新（リンク）
ADR: バリデーション方式の決定を記録（リンク）
計測: 誤操作率 5% → 1.2%（暫定、今後2週間で再評価）

## 完了判断

- 判定: 現時点では対応しない（後日再評価）
- クローズ理由: 現行の影響と緊急度では実装コスト・互換性リスクを上回る価値を確認できないため
- この判断は恒久的な却下ではなく、下記条件で再オープンする

## 理由と根拠

- 直近90日の要望は2件で、契約期限、データ損失、セキュリティ、法令への影響はない
- 現行 CSV は表計算ソフトで列を並べ替えられ、1回あたりの追加作業は約2分
- 列順を利用者別にすると、既存の連携処理とエクスポート API の互換性確認が必要になる
- 根拠: 問い合わせ集計 `REQ-EXAMPLE-2026Q3`、現行 Runbook の操作計測、API 利用一覧

## 代替案

- 当面は FAQ に「列を並べ替えて保存する手順」を掲載する
- 定型作業の利用者には、列順を変換する共有テンプレートを案内する

## 再オープン条件

- 同じ要望が30日間で10件以上になる
- 列順固定が契約または監査上の期限をブロックする
- 代替手順が1回10分を超える、または手作業による誤りが月3件以上発生する
- エクスポート API の互換性リスクを解消する前提 Issue が完了する

## 再確認

- 再確認期限: 2026-10-01（四半期トリアージ）
- Owner: Product Owner
- follow-up Issue: #790（問い合わせ件数、代替手順の所要時間、誤り件数を月次集計する。例）
- 再確認時の判断: 条件を満たせば本 Issue を再オープンし、満たさなければ根拠と次回期限を追記する

## 関連

- FAQ: 列順を並べ替えて保存する手順（例）
- 前提 Issue: #789（エクスポート API 互換性調査、例）