Claude Codeへ修正を依頼する：完了条件と変更範囲を小さく定める

再現できる利用場面を書く

誰がどの画面で何を行い、現在はどうなり、どうなればよいかを示します。たとえば「未入力で送信すると別画面へ移る。必須欄のエラーを表示し、その欄へ移動できるようにする」なら完了条件が明確になります。

実装方法を細かく固定する前に、既存の部品や検証方法を調べます。新しい仕組みを足さなくても、現在の処理を再利用できる可能性があります。

維持する条件を別に挙げる

利用者の権限、保存されるデータ、既存のURLなど、変えてはいけない条件を明記します。表面上の動作が改善しても、既存の用途を壊していれば完了ではありません。対象外を定めることは、必要な修正を避けるためではなく、無関係な改造を防ぐために行います。

作業途中で範囲が広がる根拠が見つかったら、何が必要で何が独立しているかを説明できるようにします。曖昧な「将来のため」を理由に、別の機能まで追加しないようにします。

検証と公開の判断を分ける

テストや画面確認が終わったこと、変更を共有できる形にしたこと、実際に公開したことは別です。どこまで依頼されているかを明確にし、許可された範囲の結果を具体的に残します。進捗報告では変更した行数より、利用者が何をできるようになったかを伝えます。

範囲が広がる兆候を早く見つける

小さな機能追加の途中で、多数のファイルを整理する必要があると分かった場合、その変更が機能の成立に必要かを切り分けます。既存の実装を一部利用すれば完了できるのか、別の改造を前提にしていないかを確認します。変更範囲を狭くすることと、必要な検証を省くことは違います。利用者の動作を満たす最小の完成形を先に作る考え方が役立ちます。

完了報告には、操作前後の違いと検証した条件を残します。実装ファイルやテスト数だけを列挙しても、利用者が何をできるようになったかは分かりません。未確認の環境がある場合はその範囲を区別し、ローカル確認を実機や公開環境の確認として扱わないようにします。証拠が示す内容と、まだ示していない内容を明確に伝えることが重要です。

修正依頼へ、操作の前後と提出する証拠を書く

たとえば必須欄を空にして送信したときだけ画面遷移を止めたいなら、入力、操作、現在の結果、期待する結果を一組で示します。見た目のエラー表示に加え、保存や通信が始まっていないことも条件へ入れます。通常入力での送信まで止まる実装は合格にしないため、正常な入力の条件も同じ依頼に残します。

以下は架空のフォーム修正に使う依頼書です。実際のリポジトリ、ファイル名、確認コマンドを調べた後で書き換えてください。存在しないコマンドを例から推測して実行する必要はありません。既存のテスト、部品、制御を再利用する方針と、変更した場合に示すべき証拠を先に決めます。

追加調査が必要なとき、依頼全体を勝手に広げない

フォームの表示だけではなくAPIの入力検証に不足が見つかった場合、表示修正とサーバー側の修正がそれぞれ必要かを説明します。既存の認証を緩める、権限を広げる、保存形式を変えるといった別の判断まで、同じ「使いやすさ改善」に含めません。必要な変更を隠すのではなく、具体的な理由と確認範囲を添えて切り分けます。

完了時は、以前失敗した入力がどう変わったか、通常の入力は維持できたか、実際に行った確認と未確認の条件を提出します。「コードを書いた」「テストを追加した」は中間の作業記録です。ローカルで再現を確認したこと、共有できる変更を用意したこと、本番で利用可能になったことを別々に書けば、後から担当者が状態を誤認しにくくなります。

具体例で考える

架空の問い合わせフォームで、必須欄が空でも送信要求が始まる問題を直します。ログイン方式や保存形式を変えず、表示と送信条件を確認する依頼書の例です。

【Claude Codeへの修正依頼テンプレート】
対象：問い合わせフォームの必須欄チェック。
再現：必須欄を空にして送信すると、送信要求が始まる。
期待：エラーを読み取れ、該当欄へ移動でき、送信要求は始まらない。
正常系：正しい入力は従来と同じ送信経路を使う。
維持：認証、アクセス権、入力データの保存形式、既存URL。
進め方：既存実装とチェックを調べ、必要な部品を再利用する。
停止・相談：別の認証方式や保存形式の変更が必要だと分かったとき。
確認：未入力／正しい入力／通信失敗／送信中の再操作。
提出：操作の前後、変更範囲、実行した確認の結果、未確認の環境。
公開範囲：この依頼で許可された実装・検証・公開の範囲を記入。

【確認する観察結果。実測ではなく事前条件】
未入力：エラーあり、送信なし。
正常入力：従来の送信経路で一件として処理。
通信失敗：入力と失敗状態を保ち、無断の再送を増やさない。

この依頼書は具体的な実装の正しさを保証しません。現状を再現した証拠と、修正後の同じ操作で得た結果を照合して初めて変更を判断できます。エラー文を追加するだけでは送信条件が変わった証拠にならず、正常な送信を止めることで未入力のケースだけを通す実装も不十分です。

確認課題と合格の目安

一つの「改善して」という依頼を、現状・期待・維持・確認の四項目へ書き換えてください。

• 利用者の操作で完了を説明できる。
• 既存の制約を維持している。
• 実装、検証、公開の範囲が分かる。