既存フロントエンド機能の保守変更としてタスクを分析し、設計を含めた最小差分の実装方針を立ててください。

**注意:** Previous Responseがある場合は差し戻しのため、その内容と現在のファイル内容を照合して計画を見直してください（replan）。

**小規模タスクの判断基準:**
- 1-2ファイルの変更のみ
- 設計判断が不要
- 技術選定が不要

小規模タスクの場合は設計セクションを省略してください。ただし保守変更では、小規模でも既存契約と不要変更の確認は省略しないでください。

**やること:**
1. **参照資料の読み込み（必須・最初に実行）**
   - タスク指示書の「参照資料」セクションに記載されたファイル・ディレクトリを **Read/Glob で実際に開いて内容を確認する**
   - ディレクトリが指定されている場合は中身を列挙し、該当ファイルを特定してから読む
   - 参照資料が存在しない・見つからない場合はその旨を報告し、推測で代用しない
   - **指示書に明記されていない別ファイルを「参照資料の代わり」として使うことは禁止**
2. タスクの要件を理解する
   - 参照資料の内容と現在の実装を突き合わせて差分を特定する
   - **要件ごとに「変更要/不要」を判定する。「不要」の場合は現行コードの該当箇所（ファイル:行）を根拠として示すこと。根拠なしの「既に正しい」は禁止**
   - **要件は、明示要求とそこから直接導ける暗黙要求に限定する。一般的ベストプラクティスや将来拡張を要件化しない**
   - **要件を細分化するときは、検証可能にするための分解に留める。細分化から新しい要求へ飛躍しない**
   - **暗黙要求を置く場合は、その根拠となる明示要求を計画レポートで示す**
3. コードを調査して不明点を解決する
4. 現行実装で守るべき既存契約を特定する
   - 既存構造、型名、hook戻り値、UI文言、アクセシビリティ名、コメント、テスト期待値を確認する
   - 変更が必要な既存契約がある場合は、理由と影響範囲を計画に明記する
5. 変更候補を「必須変更」「関連変更」「不要変更」に分類する
   - 変更ファイル内、近い責務、一般作法という理由だけでは関連変更にしない
   - 不要変更は Coder に実装させない
6. ファイル構成・設計パターンを決定する（必要な場合）
   - 既存構造で要求を満たせる場合は、理想的でなくても既存構造を優先する
7. 実装アプローチを決める
   - 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
   - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
8. Coder向けの実装ガイドラインに以下を含めること:
   - 参照すべき既存実装パターン（ファイル:行）。同種の処理が既にある場合は必ず示す
   - 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
   - このタスクで特に注意すべきアンチパターン（該当するものがあれば）
   - 変更してはいけない既存契約
   - 不要変更として除外した候補

**必須出力（見出しを含める）**
## 作業結果
- {計画の要約}
## 変更分類
- {必須変更、関連変更、不要変更の分類}
## 既存契約
- {守るべき既存契約}
## 実装方針
- {最小差分の方針}
