現状を知りたいだけで調査を頼んだのに、気づくとファイルが直っている。しかも直った先から前提がずれるので、元がどうだったのかが分からなくなります。

プロンプトに「変えないでください」と書き足しても、それだけでは止まりませんでした。この記事では、実際に投げているプロンプト例と、プロンプトの外側で止める方法、変更されていないことを機械的に確認する手順を書きます。

動作確認は Claude Code 2.1.266 です。フラグ名はバージョンによって変わるので、claude --help で確認してください。

プロンプトだけで止めようとしない

止め方は3つの層に分かれます。止まる範囲が違うので、片方だけでは埋まりません。

プロンプト: どう受け取られるかを決める。速いが、解釈の余地が残る
権限: そもそも書き込みツールを呼べなくする。確実だが、粒度は粗い
検証: 変わっていないことを後から確かめる。止めることはできないが、見落としを消す

以下、順に書きます。

1. プロンプト例：調査を頼むとき

禁止を並べるのをやめて、手順を先に決めて渡す形にしています。実際に投げているプロンプトがこれです。

このディレクトリの現状を確認してください。
読み取り専用です。変更は禁止します。

対象: src/ 配下のみ
出力: 調査結果を Markdown で、docs/survey.md に新規作成

進め方:
1. 着手する前に、参照するファイルと使用する値を一覧にして出してください
2. 不足している値や矛盾があれば、作業を始める前に質問してください。推測で埋めないでください
3. 既存ファイルの編集は行わないでください。必要だと判断した変更は、実行せず提案として書いてください

要点は3つです。

「読み取り専用です」を1行目に置く。 文末や補足に書いても伝わりにくいというのが実感です。冒頭に置くと、そのあとの文章がすべてその前提で読まれます。

質問させるタイミングを指定する。 「分からなければ聞いてください」だけでは足りませんでした。ひととおり作ってから「なお、ここは推測です」と付いてきます。「作業を始める前に」まで書くのが要点です。

着手前に、使う値を復唱させる。 ここで食い違いが表に出ます。作り始めてから気づくより、はるかに手戻りが小さくなります。

サブエージェントに分けて動かすときは、最初のタスクを「現状把握（読み取りのみ）」に固定し、その出力を後続に渡す形にしています。並行して走らせると、片方が書き換えた状態をもう片方が読むので、原因の切り分けができなくなります。

もう1つ、止めるときのプロンプト例です。「一旦止めて、ここまでの検討は残しておいてください」だと、検討の中身が会話の中にしか無い状態で止まります。

一旦止めます。
ここまでの検討内容を docs/decisions/2026-09-09.md に書き出してから止めてください。
含めるもの: 検討した案、採用しなかった理由、未確定の項目

保存先とファイル名を先に指定すると、会話の外に残ります。「残して」は解釈されますが、「ここに書き出して」なら解釈の余地がありません。

2. 権限で、書き込みツールを呼べなくする

プロンプトは解釈されますが、権限は解釈されません。調査だけのセッションは、はじめから編集できない状態で起動しています。

# 編集系のツールを禁止して起動する
claude --disallowed-tools "Edit Write NotebookEdit" \
       "src/ 配下の現状を調査して、結果を docs/survey.md にまとめてください"

--disallowed-tools はツール名のほか Bash(git *) のようなパターンも受け付けます。Bash を丸ごと止めると grep も find も使えなくなって調査にならないので、書き込み側だけ塞ぐのが現実的でした。

計画を立てさせてから判断したい場合は、プランモードで入ります。

claude --permission-mode plan "この構成を調べて、変更案を出してください"

--permission-mode の選択肢は claude --help に出ます（2.1.266 では acceptEdits / auto / bypassPermissions / manual / dontAsk / plan）。

もう1つ、読ませたいディレクトリが作業ディレクトリの外にある場合、--add-dir で足すことになりますが、足したディレクトリも書き込み対象になります。参照するだけのつもりなら、--disallowed-tools と併用しておくほうが安全です。

3. 変更されていないことを、機械的に確認する

止めたつもりが止まっていなかったときに気づけるよう、調査セッションの前後で差分を取ります。git 管理下なら1行です。

# 調査前
git status --porcelain > /tmp/before.txt

# --- ここで調査セッションを回す ---

# 調査後
git status --porcelain > /tmp/after.txt
diff /tmp/before.txt /tmp/after.txt && echo "変更なし"

git 管理外のディレクトリを見せる場合は、ハッシュを取っておきます。

# 調査前
find target -type f -exec shasum {} + | sort > /tmp/before.sha

# 調査後
find target -type f -exec shasum {} + | sort > /tmp/after.sha
diff /tmp/before.sha /tmp/after.sha && echo "変更なし"

ファイル数が多いディレクトリでは shasum に時間がかかるので、find target -type f -newer /tmp/marker のようにタイムスタンプで絞るほうが速いです。

touch /tmp/marker
# --- 調査セッション ---
find target -type f -newer /tmp/marker

なお、ワーキングツリーで書き換えて元に戻された変更は、git の履歴には残りません。「コミットされていないから何も起きていない」とは言えないので、確認するなら差分を自分で取っておく必要があります。

なぜ禁止が通じないのか

これは推測ですが、再現してほしいのか、作ってほしいのかの区別が、プロンプトでは伝わりにくいのだと思っています。

こちらは「いまあるものをそのまま見てほしい」つもりでも、少ない手がかりからそれらしい形を組み立てられることがあります。悪気があって変えているというより、作る仕事として受け取られている。

そう考えると、「変えないで」が弱いのも腑に落ちます。禁止は解釈が要る指示です。何を変えたことになるのか、どこまでが元の形なのかを、受け取った側が判断することになります。

対して「読み取り専用」「作業前に質問」「着手前に一覧を出す」は、やることが決まっています。判断の余地が少ないぶん、ずれにくい。そして --disallowed-tools に至っては、判断の余地そのものがありません。

調査だけのつもりのセッションで直され始めているなら、プロンプトの1行目と、起動時のフラグを見てみると、何か見つかるかもしれません。

同じ話を、書き手側の失敗として書いたものが note にあります。是非読んでください！