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