既存の製品を修正する

動いている製品への修正は、新しく作るより制約の多い作業です。すでに利用者、保存されたデータ、共有されたURLがあり、そのすべてが「今の動きのまま」を前提にしています。修正の腕前はClaudeが持っているため、人間の仕事は範囲の指定と確認です。

直す前に、今の動きを理解する

目的は、自分が理解することです。これはAIがあってもなくても変わらない、変更という行為の前提です。変更の影響範囲は、画面で見えているより広いことがあります。同じ部品が別の画面でも使われていたり、同じ処理を外部が呼んでいたりするためです。Claudeに説明してもらいながら先に構造を理解すると、依頼の言葉も正確になります。

この画面の「申請」ボタンを押した後、何がどの順で起きるか説明して
この文言はどこで決まってる?変えると他の画面にも影響する?

範囲を固定する

Claudeは修正のついでに周辺の改善を提案し、実行することがあります。改善自体が正しくても、diffを読んで取捨選択できない場合は、変更を依頼した範囲に固定した方が確認できる状態が保たれます。1つの修正は1つの依頼に分けます。

依頼した箇所以外は、気づいたことがあっても変更せず報告だけして

既存の形に合わせる

修正のたびに新しい書き方や新しい部品を持ち込むと、コードの一貫性が崩れ、次の修正が難しくなります。既存のコンポーネントとスタイルに合わせるよう指定します（UIの観点）。

新しいライブラリやコンポーネントは追加せず、既存のものに合わせて直して

本番に直接反映しない

修正はbranchで行い、Pull Requestとプレビュー環境で確認してから本番へ反映します（バージョン管理、環境の分離）。確認では、直した場所だけでなくその周辺を操作し、過去に作った自動テストも実行します。

この変更で壊れる可能性のある既存機能を挙げて、テストと実際の操作で確認して

互換性という約束

使われている製品には、保存済みのデータ、共有済みのURL、外部から呼ばれているAPIという「過去との約束」があります。項目の削除や名前の変更は、この約束を破ることがあります。壊れて初めて存在に気づくことが多い部分なので、修正のたびに一言確認します。

この変更は、保存済みのデータと共有済みのURLをそのまま使える?

戻せることを知っておく

公開後に問題が見つかっても、コードは変更前の状態へ戻せます。戻せると知っていれば、修正を過度に恐れる必要はありません（バージョン管理）。ただし戻せるのはコードで、保存されたデータや送信済みの通知は戻りません。そうした影響を伴う変更の前には確認を挟みます（Claudeへの権限）。

さっきの変更に問題があった。公開前の状態に戻して