Claude Codeに1ファイルだけ直させる指示文のつくり方

「このブログ記事の導入文、もうちょっと良くしておいて」

僕がそう打ち込んだのは、金曜の夜10時でした。直してほしかったのは1ファイルの最初の3段落だけ。なのに翌朝、差分を開いたら12ファイルが変わっていました。記事本文だけでなく、共通レイアウト、タグの一覧、なぜか公開設定のファイルまで。動くかどうかも確かめないまま、僕は寝てしまっていたんです。

戻すのに30分かかりました。何が悪かったのか。Claude Codeが下手だったわけではありません。僕の指示が「どこまで触っていいか」を一言も決めていなかったから、賢いAIが「導入文を良くする＝関連箇所も整える」と気を利かせただけなんです。

この記事では、その夜の失敗から作った「1ファイルだけ安全に直させる依頼文」を、そのままコピペできる形で渡します。範囲を狭く決め、終わったら自分で検証させ、間違っていたら戻せるようにする。たったこれだけで、夜中の事故はほぼ消えました。

この記事の要点

• AIに任せる仕事が暴走するのは、モデルが悪いのではなく触ってよい範囲を書いていないから
• 依頼文には「見るファイル」「変えるファイル」「触らないもの」「確認コマンド」「戻し方」の5点を必ず入れる
• 成功報告の前に検証コマンドを必ず実行させると、人間が後でテスト係になる事故が減る
• ブログ修正・バグ報告の整理・商品文の書き換えなど、止めどころが明確な小さい仕事から始める
• 範囲を狭めても記事や成果物の価値は下がらない。むしろ読者が自分の環境に置き換えやすくなる

なぜ「もっと良くして」は事故るのか

「もっと良くして」という頼み方には、終わりの線がありません。

人間の編集者なら、忙しい金曜の夜に頼まれたら「導入の3段落だけですよね？」と確認します。でもAIは確認せずに走り出せてしまう。しかも気を利かせるのが得意なので、「導入を良くするなら、タグも整えて、関連リンクも足したほうが親切だろう」と勝手に範囲を広げます。悪気はゼロです。それがいちばん厄介なんですね。

ここで効くのが、指示の中に「止めどころ」を書いておくという発想です。プロンプトを長く凝った文章にする必要はありません。むしろ短くていい。代わりに、触ってよいファイルと触ってはいけないファイルを、最初にはっきり分けておく。これだけで暴走は止まります。

プロンプトの書き方そのものをもっと深掘りしたい人は、Claude Codeのプロンプト設計も合わせて読むと、ここで言う「範囲を絞る」が他のテクニックとどうつながるか見えてきます。

依頼文に必ず入れる5点

僕が今使っている依頼文には、必ずこの5つが入っています。順番にも意味があります。

項目	中身	これがないと起きること
見るファイル	状況把握のために読んでよい範囲	関係ない場所まで読んで的外れな修正をする
変えるファイル	実際に書き換えてよい1〜2ファイル	12ファイル事故が起きる
触らないもの	設定・生成物・秘密情報・公開設定	消したらまずいファイルを「整理」される
確認コマンド	変更後に走らせる検証の1コマンド	壊れたまま「できました」と報告される
戻し方	間違っていたときに元に戻す手順	復旧に30分かかる

ポイントは、編集を始める前に一度「計画」を返させることです。いきなり書き換えさせない。「どのファイルを見て、どれを変えて、もし間違っていたら何が壊れるか」を先に言わせる。ここで的外れな計画が返ってきたら、その時点で止められます。書き換えてから気づくより、はるかに安いです。

AIに任せる範囲と、人が決める範囲

全部をAIに渡す必要はありません。線はこう引いています。

AIに任せていい部分

• 状況把握のためにファイルを読む
• 変更の計画を立てて言葉にする
• 実際の文章やコードを書く
• 検証コマンドを走らせて結果を報告する

人が握っておく部分

• どのファイルを変更対象にするか（範囲の決定）
• 公開・本番反映のボタンを押すか
• 設定ファイルや秘密情報に触れる判断
• 検証が落ちたときに公開を止める判断

この線引きは、初めてAIに作業を任せる人ほど大事です。任せる範囲と人が判断する範囲をどう分けるかは、非エンジニア向けのClaude Code活用でも基本の考え方として出てきます。慣れないうちは「読む・書くはAI、消す・公開するは人間」くらいの粗さで十分です。

コピペで使える依頼文テンプレート

そのまま貼って、ファイル名だけ自分の環境に置き換えてください。PowerShellでもbashでも、変数に文章を入れて確認するだけです。

brief=$(cat <<'EOF'
目的: 安全な編集を1か所だけ行う。
変えてよいファイル: site/src/content/blog/example.mdx
触らないもの: package系ファイル、生成物、秘密情報、公開・デプロイ設定。

編集を始める前に、次を返すこと:
1. 状況把握のために見るファイル
2. 実際に変える1ファイル
3. その変更が間違っていた場合に壊れるもの
4. 変更後に走らせる確認コマンド

編集を終えたら、次を返すこと:
- 差分の要約
- 確認コマンドの実行結果
- 元に戻す手順
EOF
)

echo "$brief"

この文章は派手ではありません。価値は、作業を始める前に境界を文字にしておけることです。ファイル名、触らないもの、確認コマンドを自分のリポジトリ用に書き換えて、Claude Codeに渡してください。良い計画が返ってきたら、同じ制約をもう一度言わせてから作業に入らせます。

CLAUDE.mdに同じ制約を書いておけば、毎回貼り付けなくても自動で効きます。やり方はCLAUDE.mdのベストプラクティスにまとめています。

終わったら検証させる小さなスクリプト

「できました」を信じない。これが2つ目の柱です。

編集が終わったあと、変更されたファイルが本当に1つだけかを機械的に確認します。下のスクリプトは、未コミットの変更ファイル数を数えて、想定より多ければ止まるだけのものです。日本語コメント付きでそのまま動きます。

#!/usr/bin/env bash
# 変更ファイルが1つだけかを確認する。多すぎたら止める。
set -e

# 想定する変更ファイル数（1ファイル編集なら1）
expected=1

# 未コミットで変更されたファイル数を数える
changed=$(git status --porcelain | grep -c .)

echo "変更されたファイル数: $changed（想定: $expected）"

if [ "$changed" -gt "$expected" ]; then
  echo "想定より多くのファイルが変わっています。差分を確認してください。"
  git status --porcelain
  exit 1
fi

echo "範囲どおりです。"

このスクリプトを依頼文の「確認コマンド」に指定しておくと、AIは自分で走らせて結果を報告するようになります。12ファイル変わっていれば、報告の時点で赤い文字が出る。僕が朝起きてから気づくのではなく、その場で止まる。これが効きます。

検証や日々の段取りをもっと自動化したい人は、Claude Codeの生産性向上テクニックに他の型もまとめてあります。

こんな場面で効く（3つ）

どれも「止めどころ」がはっきりしている仕事です。逆に言うと、止めどころが見えない仕事はまだAIに丸投げしないほうがいいサインです。

1. ブログ導入文のリライト 変えるのは1ファイルの導入だけ、と最初に書きます。対象読者と検証コマンドも添える。これで本文全体やレイアウトに手が伸びなくなります。僕の12ファイル事故は、まさにこの一行があれば起きませんでした。

2. バグ報告の整理 ログファイルとテンプレート1つだけを見せて、「関係ないコードの整理は禁止」と書く。報告を整える作業のついでにリファクタリングされると、レビューが一気に重くなります。見せる範囲を絞ると、出力も絞れます。

3. 商品ページの文言テスト ページ全体の作り直しではなく、「キャッチコピー1案」と「変更後の見た目の確認」だけを求めます。範囲が1案に固定されているので、A/Bで試すときも比較が楽です。

よくある質問

Q. 毎回この長い依頼文を貼るのは面倒では？ よく使う制約はCLAUDE.mdに書いておけば、毎回貼らなくても効きます。貼るのは「今回触ってよいファイル名」だけで済むようになります。

Q. 範囲を狭めると、AIの良さを殺してしまわない？ 逆でした。範囲が狭いほうが、AIは迷わず深く直してくれます。広い指示は「どこから手をつけるか」で迷わせるだけです。

Q. 検証コマンドは何を入れればいい？ 最初は「変更ファイル数のチェック」だけで十分です。慣れてきたら、ビルドが通るか、テストが落ちないか、リンク切れがないか、を1コマンドずつ足していきます。

Q. それでも想定外のファイルが変わったら？ 戻し方を依頼文に書いてあれば、その手順で戻すだけです。git restore . など、戻すコマンドを最初から指示文に入れておくのがコツです。

Q. どこから始めるのがいい？ 失敗しても戻せる小さい仕事を1つ選んでください。下書き記事の修正や、文言の差し替えが手頃です。基本操作が不安ならClaude Code入門ガイドから始めると地ならしになります。

実際に試した結果

あの12ファイル事故のあと、僕は依頼文を必ず「変えるファイル」「触らないもの」「確認コマンド」付きで書くようにしました。

検証スクリプトを「確認コマンド」に指定してから、想定外のファイルが混ざったケースはその場で止まるようになりました。実際、先週も商品ページの文言を直させたとき、AIが共通コンポーネントにまで手を伸ばしかけたのですが、変更ファイル数が2になった時点でスクリプトが赤を出して止まった。朝起きてから差分を見て青ざめる、ということがなくなったんです。

もう一つ確かめたのは、範囲を狭めても出力の質が落ちないこと。「導入の3段落だけ」と縛った日のほうが、むしろ的を射た直しが返ってきました。賢いAIに広く任せるより、狭く頼んで自分で検証させる。遠回りに見えて、これが僕にとっていちばん速い、というのが今の結論です。

会社の業務でAIに編集や運用を任せる仕組みを整えたいなら、研修・導入相談で具体的な手順から一緒に組み立てられます。まずは自分の手元で、1ファイルだけの依頼文を一度試してみてください。

参考までに、ここで使ったツールの公式情報はClaude Code公式ドキュメントにあります。