Claude Code演習（後編）：/rewind・差分レビュー・常に許可・4D【Claude Code実践入門第9回】

「巻き戻せると聞きましたが、どこまで戻るのか、実際に試したことはありません」
「確認の画面で『常に許可』を選ぶと、何が保存されるのか不安で、いつも『一度だけ許可』にしています」

前編の第8回では、練習用のリポジトリ（~/practice）を作り、手順1〜3で CLAUDE.md の下書き、計画、実装と検証を試しました。第9回は、同じ ~/practice を使って続けます。手順4〜6で、巻き戻し、差分のレビュー、権限の「常に許可」を試し、早く終わったら /goal を使います。最後に、4D（AI Fluency）で演習を振り返り、自己点検と連載の結びで、この連載を終わります。

記録A・記録B（筆者の記録）、Code タブ・CLI・-p の対応、準備の手順は、第8回の「筆者の記録の読み方」「準備」を見てください。-p では確認の画面が出る操作が「承認が要る」として実行されずに終わる点も、第8回に書いています。

手順4〜6
早く終わったら
最後の状態
4Dで振り返る
自己点検
連載の結び
まとめ
連載「Claude Code実践入門」全9回

手順4〜6

手順の表は次のとおりです。各手順の後に、筆者の記録を載せます。記録Aの費用の目安（-p が表示する値。API の定価で計算した目安で、Pro・Max では使用量が購読に含まれるため、この金額は請求の目安になりません。ただし、環境変数 ANTHROPIC_API_KEY が設定されていると、購読ではなく API の料金になります）は、ドルで、準備 0.25、手順1（/init）0.24、手順2（計画）0.22＋0.28（直させた後）、手順3（実装と検証）0.50、手順5（差分の直し）0.60、手順6（本実行の依頼）0.65、早く終わったら（/goal）0.24（3台の回、既定の Opus 5.5）で、合計は約3ドルでした。

手順	やること	確認すること
4	わざと別の方向に進ませてから、Esc 2回（CLI は /rewind も）で「コードと会話を復元」を選ぶ	ファイルと会話が戻ったか。Bashで作ったファイルは戻らないことも確かめる
5	増減の行数の表示（+12 -1 など）から差分を開く。気になる行を指摘して直させる	計画にない変更がないか。Claudeが指摘どおりに直したか
6	「手動」のまま stg への本実行（–check なし）を頼み、確認の画面で「常に許可」を選ぶ。.claude/settings.local.json を開く	どんなルールが書かれたか（第6回の形式と比べる）。同じ依頼で、もう確認が出ないか
早く終わった人	/goal で完了の条件を渡す、worktreeで2つ目のセッションを動かす	条件を満たすまで続いたか、2つのセッションが干渉しないか

手順4：巻き戻す

わざと別の方向に進ませてから、入力欄が空の状態で Esc を2回押し（CLI では /rewind でも開けます）、「コードと会話を復元」を選びます。Bash で作ったファイルは戻らないことも確かめます（第3回の「巻き戻しで戻らないもの」）。

筆者の環境ではこうなった（記録B：2026-10-04、Code タブ 2.1.284、手動）
Esc 2回で「このメッセージまで巻き戻しますか？」が出た。「復元」のプルダウン（既定は「コードと会話」）、対象のファイルの数（1件 +1 −1）、注意「シェルコマンドで行った変更は元に戻されません。コミットはそのまま残ります。」が表示された。
巻き戻した後、ファイル編集で変えた main.yml は元に戻った。Bash で作った bash_created.txt と、sed -i で変えた site.yml は残った。
戻すファイルが無いときは、メッセージを選んだ時点で、会話だけが巻き戻った。
「復元」のプルダウンの選択肢が、公式の5つ（コードと会話・会話・コード・ここから要約・ここまで要約）と同じかは、確かめていない。記録A（-p）では /rewind を試せない。

手順5：差分を開き、気になる行を指摘して直させる

増減の行数の表示（+12 -1 など）をクリックするか Ctrl＋Shift＋D で差分ビューを開きます（表示が出ないときは git diff。CLI では /diff か git diff）。第7回の「要約ではなく差分から読む」の順番で、計画にあったファイル、計画になかった変更、の順に読み、気になる行を指摘して直させます。

筆者の環境ではこうなった（記録A：差分は git diff で見た）
筆者の指摘：regexp: '^server {{ item | regex_escape }} '（名前の後に空白）だと、行末が server ntp1.example.jp で終わる（iburst などが無い）既存の行に一致せず、同じサーバーの行が2行になる。
Claude の直し：regexp: '^server {{ item | regex_escape }}(\s|$)'。「ホスト名の後に空白（スペースかタブ）が続く行と、ホスト名で行が終わる行の両方に一致。ntp1.example.jpx には一致しない」と説明した。lint（name[casing] の1件は同じ、新しい違反なし）と syntax-check（合格）をやり直した。
確かめていないことを分けて書いた：「正規表現の一致を Python でサンプル行に当てて確かめようとしたが、承認されなかったので実行していない。説明は正規表現を読んだうえでの判断」「stg の --check --diff はまだ」。
計画にない変更は無かった（差分は main.yml と defaults/main.yml だけ）。最初に2台で試したときも、regexp は \s で終わっていて、同じ指摘で (\s|$) に直った。
筆者は、Code タブの「ローカル」で差分ビューを確かめられなかった。記録Aは CLI なので、git diff で見た。

手順6：「手動」のまま本実行を頼み、「常に許可」を選ぶ

「手動」のまま stg への本実行（--check なし）を頼み、確認の画面で「常に許可」を選びます。.claude/settings.local.json を第6回の「allow・ask・denyルールの書き方」の形式と比べ、同じ依頼をもう一度送って確認が出ないかを確かめます。

筆者の環境ではこうなった（記録A と記録B）
記録A（-p、--permission-mode default＝手動）：「stg に本実行してください（–check なし）。」と頼むと、Claude は ansible-playbook --diff -i inventory/stg/hosts.ini site.yml（出力はファイルへリダイレクト）を実行しようとして、承認待ちになり、承認されなかったので実行しなかった（settings.json の allow は --syntax-check と --check --diff だけ）。「stg に届かない可能性が高い（前回 192.0.2.11 への SSH がタイムアウトした）」「dry-run はまだ一度も通っていない」「承認して実行するか、自分の端末で実行して出力を貼るか」と返した。1回目（2台）は、「許可するなら stg のコマンドだけを allow に足し、prod は確認のままに」とも書いた。
記録B（2026-10-04、Code タブ）：確認の画面の選択肢は「拒否」（1・Esc）、「常に許可」（2・Ctrl＋Shift＋Enter）、「一度だけ許可」（3・Ctrl＋Enter）。「常に許可」を選ぶと、.claude/settings.local.json に {"permissions":{"allow":["Bash(ansible-playbook -i inventory/stg site.yml)"]}} が保存され、同じ依頼の2回目は確認が出なかった。保存されたのは、そのコマンドだけに一致するルールで、パイプ（2>&1 | cat）は外されていた。第6回の形式と比べる材料になる。

早く終わったら

/goal で完了の条件を渡す：第3回の「/goal：「完了」を条件で渡す」の /goal で、「ansible-lint が違反0件で終わる」などの完了の条件を渡す。条件を満たすまで続いたかを確かめる
worktree で2つ目のセッションを動かす：同じリポジトリで、2つのセッションが干渉しないかを確かめる

筆者の環境ではこうなった（記録A：/goal）
/goal ansible-lint が違反0件で終わる（日本語のタスク名は変えない） を、「編集を受け入れる」の新しいセッションで送った。/goal として受け付けられ（記録に goal_status が残った）、9ターンで終わった（1回目は6ターン）。
Claude は .ansible-lint を新しく作り、skip_list: [name[casing]] と、コメント「# タスク名は日本語で書く規約のため、大文字始まりを求める name[casing] は適用しない」を書いた。タスク名と playbook は変えなかった。ansible-lint は「0 failures、0 warnings、production profile」で通った。「lint の設定だけでホストへの動きは変わらないので、--check --diff は実行していない」「タスクごとに # noqa: name[casing] を付ける方法もあるが、全タスクが日本語なので設定ファイルにした」と説明した。コミットはしなかった。
指摘された name[casing] は、タスク名が英小文字の chrony で始まるためで、筆者の実測では、日本語の文字で始まる名前は指摘されない（第4回の「補足：日本語のタスク名と ansible-lint の name[casing]」）。
CLAUDE.md への追記まではしなかった。skip_list に入れたら、そのことも CLAUDE.md に書く（第4回）。「CLAUDE.mdに追加して」と頼むのは、人の仕事。
worktree（2つ目のセッション）は、筆者は試していない。

最後の状態

筆者の練習用リポジトリの最後の状態（記録A）です。コミットは筆者が手で行いました。読者の方も、手順の区切り（手順1の CLAUDE.md、手順3の実装と手順5の直し、「早く終わったら」の .ansible-lint）でコミットしておくと、上と同じ形になります。同じリポジトリで続けて試すとき、作業ツリーがきれいな状態から始められます。

$ git log --oneline
5667c29 name[casing] を外す
b141158 NTPの参照先を3台にする
2612102 CLAUDE.md を追加
97c9de3 Initial commit
$ cat roles/ntp/tasks/main.yml
- name: chronyの参照先を設定する
  ansible.builtin.lineinfile:
    path: /etc/chrony.conf
    regexp: '^server {{ item | regex_escape }}(\s|$)'
    line: "server {{ item }} iburst"
  loop: "{{ ntp_servers }}"

roles/ntp/tasks/main.yml の前と後の比較。前は準備プロンプトで作ったもの（1台）で、- name: chronyの参照先を設定する、ansible.builtin.lineinfile:、path: /etc/chrony.conf、regexp: '^server '、line: "server ntp1.example.jp iburst"。regexp と line の2行が赤で、参照先は1台。手順2〜3で実装し、手順5で直した後の最後の状態は3台で、同じ name・lineinfile・path に続けて、regexp: '^server {{ item | regex_escape }}(\s|$)'、line: "server {{ item }} iburst"、loop: "{{ ntp_servers }}" の3行が緑。regexp の末尾の (\s|$) が手順5で直した所で、行末が server ntp1.example.jp で終わる行にも一致する。もう1つ、roles/ntp/defaults/main.yml が新しいファイルとして加わり、ntp_servers に ntp1.example.jp、ntp2.example.jp、ntp3.example.jp の3台を並べる。下の見出しは「loop で3台を回し、サーバーごとに自分の行だけを置き換える」。

4Dで振り返る

演習を、Anthropic の AI Fluency の4D で振り返ります。4D は、連載「Claude活用入門」第6回の「AI Fluencyの4D」で紹介した、AI と協働するための枠組みです（講座：https://academy.claude.com/ja/courses/ai-fluency-framework-foundations ）。

AI Fluencyの4D	演習を振り返る問い
委任（Delegation）	どこまで任せたか。権限モードは作業に合っていたか
記述（Description）	プロンプトとCLAUDE.mdは、具体的で確かめられる書き方だったか
評価（Discernment）	要約ではなく、証拠と差分で確かめたか
責任（Diligence）	本番に関わる実行を、人が承認する形にしていたか

英語の定義は、Anthropic の公式の PDF「The AI Fluency Framework」（https://www-cdn.anthropic.com/b383cf6baddbfc72fdf8b0ed533a518e2872d531.pdf ）で、Delegation は「Setting goals and deciding whether, when and how to engage with AI」、Description は「Effectively describing goals to prompt useful AI behaviors and outputs」、Discernment は「Accurately assessing the usefulness of AI outputs and behaviors」、Diligence は「Taking responsibility for what we do with AI and how we do it」です。表の日本語の訳語（委任・記述・評価・責任）は筆者の訳で、公式の日本語訳は確認できていません。

自己点検

一人で振り返る点検です。演習の結果を、自分のリポジトリの CLAUDE.md と設定に反映できたかを確かめます。

手順1で削った行は何行で、なぜ削りましたか。自分の CLAUDE.md にも、同じ種類の行（読めば分かる説明、一般的な使い方）が残っていませんか
詰まったところはどこでしたか。ansible 系のコマンドが止まった、確認の画面の意味が分からなかった、などは、CLAUDE.md の「環境の癖」や権限のルールに書けますか
手順6で .claude/settings.local.json に書かれたルールは、第6回の形式と比べてどうでしたか。広すぎるルール、狭すぎるルールはありませんでしたか。自分の .claude/settings.json に反映するなら、どれですか
手順5で指摘したような差分の読み方を、普段の作業でもしていますか。要約から読んでいませんか
4D のうち、一番弱かったのはどれでしたか

連載の結び

この連載は、Claude Code に作業を任せるときの5つの柱を扱いました。任せる前に作業範囲を決める（第1・2回）、走らせながら操縦する（第3回）、CLAUDE.md を短く具体的に育てる（第4回）、権限を allow・ask・deny で絞る（第5・6回）、「できました」ではなく証拠と差分で終わらせる（第7回）。そして、第8回・第9回の演習で、それぞれを一度ずつ手で確かめました。

連載「Claude活用入門」では、Claude の全体像・使い分け・モデルと Effort・プロンプト・安全を扱いました。2つの連載を通して残るのは、任せる判断と最後の責任は人に残るということです。道具が進んでも、何を任せるかを決め、差分を読み、本番に関わる実行を承認するのは、人の仕事です。

まとめ

手順4：/rewind で「コードと会話を復元」。戻るのはファイル編集の変更で、Bash で作ったファイルや sed -i の変更は戻らない
手順5：差分は計画にあったファイル→計画になかった変更の順に読み、気になる行を指摘する。筆者の環境では、regexp の行末の落とし穴を差分から見つけた
手順6：確認の画面の「常に許可」は、.claude/settings.local.json にそのコマンドだけに一致するルールを保存する。-p では承認が要るものは実行されない
早く終わったら：/goal で完了の条件を渡す。筆者の環境では lint の設定ファイルが作られたが、CLAUDE.md への追記は人が頼む
4D で、任せ方・書き方・確かめ方・責任の取り方を振り返り、自己点検で自分の CLAUDE.md と設定に反映する

全9回の「Claude Code実践入門」は、これで終わりです。

続きの連載として、「Claude Codeスキル入門」（全12回、2026年11月3日から）、「Claude Codeサブエージェント入門」（全13回、11月15日から）、「Claude Codeフック入門」（全12回、11月28日から）、「Claude Codeチーム活用入門」（全10回、12月11日から）を順に公開します。演習では、この連載の練習用リポジトリ ~/practice をそのまま引き継いで使います。