ボタンの文言を直した後は、完了報告だけで終えません。git diffで対象行だけが変わったことを見て、lintと実画面の両方を確認します。
このLessonの結論
完了報告だけを信じず、差分、テスト、実画面から要求どおりか確かめます。
大切なのは、知識として覚えることではありません。自分の仕事を一つ選び、判断基準を当てはめ、変更前と変更後を比べられる状態まで進めることです。
- git diffで変更箇所を見る
- 変更箇所と主要回帰を試す
- 未解決を報告へ残す
なぜ、うまく進まないのか
テスト成功だけでは、要求外の変更や見た目の崩れは分かりません。差分、機械検証、利用画面を別々に確認します。
3つの基準を、実務でどう使い分けるか
ここまでの要点は、三つを同時に満たすための標語ではありません。作業の段階ごとに使う判断基準です。順番を飛ばすと、手段だけが増え、何を改善したのか分からなくなります。
1. git diffで変更箇所を見る
AIへ任せる範囲を決める観点です。入力できる情報、期待する出力、人が確認する箇所を分けます。便利かどうかではなく、誤りが出たときの影響まで見てください。
「git diffで変更箇所を見る」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
2. 変更箇所と主要回帰を試す
出力の品質を安定させる観点です。指示文だけで解決しようとせず、材料の不足、完成条件、確認方法を分けます。同じ入力で再試行すると、偶然の成功も見抜けます。
「変更箇所と主要回帰を試す」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
3. 未解決を報告へ残す
人が判断を残すための観点です。数字、固有名詞、権利、公開可否はAIへ委ねません。誤りを見つけた後に戻れるよう、入力と出力の履歴を残します。
「未解決を報告へ残す」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
変更前と変更後の間にある判断
変更前Claude Codeが『修正しました』と答えたら完了にする
変更後diffで範囲を確認し、lintと対象画面を検証してから完了にする
重要なのは、変更後の表現をそのまままねることではありません。何が曖昧だったために判断できず、どの情報を加えたことで次の行動を選べるようになったかを読み取ります。
自分の仕事へ置き換えるときは、固有名詞や数字だけを差し替えません。相手の状況、止まっている理由、決める必要があることを先に書き換えてください。
変更後の案が長くなった場合は、目的に直接関係しない説明を削ります。短さを優先するのではなく、判断に必要な情報だけが残っている状態を目指します。
手順ごとの確認点
「diffとテストで変更を検証する」を実務で使うときは、次の手順を一度に終わらせません。各段階で短い記録を残すと、途中で迷っても一つ前の判断へ戻れます。
git diffで予定外の変更がないか見る
最初の作業では、対象と出力を一文で書きます。固有の業務名、相手、利用場面のどれかが入っていると、次の手順で迷いません。
変更箇所のテストと主要回帰を実行する
二つ目の作業では、選んだ内容と理由を並べます。別の案を採用しなかった理由も一言残すと、判断基準が明確になります。
未確認事項と残課題を完了報告へ残す
三つ目の作業では、今回扱う範囲を固定します。追加したくなった内容は別のメモへ移し、最初に決めた目的から外れないように進めてください。
結果が出ないときは、どこへ戻るか
回答が毎回変わる
指示文を長くする前に、入力材料と完成形式を固定します。同じ入力を二回試し、変わった箇所と業務への影響を分けて確認してください。
もっともらしい誤りが混ざる
正しそうな文章と正しい事実は別です。数字、日付、固有名詞を原資料と照合し、確認できない内容は採用しません。
確認作業が増える
AIへ任せる範囲が広すぎます。分類、要約、下書きなど一工程へ戻し、人が確認する項目を三つ以内に固定します。
失敗は、最初からすべてやり直す合図ではありません。対象、根拠、変更、確認のうち、記録が途切れた場所だけへ戻ると改善を続けられます。
実践課題の完成条件
課題は「一つの変更について、diff、テスト結果、残課題を三点セットで確認します。」です。資料を作っただけでは完了にしません。次の四項目を第三者が読み取れる状態まで整えます。
- 誰の、どの業務や場面を扱ったかが一文で分かる
- 変更前の事実と、困っていた理由が分かれている
- 今回変えた箇所と、その判断理由が対応している
- 結果を確認する数字、行動、完成状態のどれかがある
説明を加えないと伝わらない場合は、情報量を増やす前に順番を見直します。第三者が「何を見て、何を変え、どう確かめるか」を説明できれば合格です。
つまずきやすい3つの点
最初から対象を広げすぎる
一度に多くを変えると、どの変更が効いたか分かりません。最初は一つの対象、一つの場面へ絞ります。
曖昧な目標で終える
「改善する」「注意する」だけでは、完了を判断できません。何がどう変われば成功かを、観察できる言葉で決めます。
変更前を残さない
元の状態がないと、改善したかを振り返れません。変更前、変更内容、確認結果の三つを同じ場所へ保存します。
そのまま使える作業メモ
対象今回扱う人、業務、場面を一つ書く
現状Claude Codeが『修正しました』と答えたら完了にする
変更diffで範囲を確認し、lintと対象画面を検証してから完了にする
確認何を見れば改善したと判断できるかを書く
実践課題
一つの変更について、diff、テスト結果、残課題を三点セットで確認します。
上の作業メモを使い、変更前と変更後を並べて保存します。所要時間は20〜30分が目安です。完成度を上げるより、一度試して差を確認することを優先してください。
理解度チェック
- 自分の業務では「git diffで変更箇所を見る」を、どの事実で確認しますか。
- 自分の業務では「変更箇所と主要回帰を試す」を、どの事実で確認しますか。
- 自分の業務では「未解決を報告へ残す」を、どの事実で確認しますか。
答え方の目安対象の業務名、確認する事実、合格とする状態の三つが入っていれば十分です。「意識する」「気をつける」だけで終わっていないかを見直します。
まとめ
完了報告だけを信じず、差分、テスト、実画面から要求どおりか確かめます。
まずは小さな一例で試し、結果を見てから対象を広げます。次のLessonへ進む前に作業メモを一つ残すと、学んだ内容を次の仕事でも再利用できます。