Claude Codeに最初の1タスクを任せる依頼文の書き方

「このリポジトリ、READMEまわりをいい感じに直しといて」

インストールして30分、僕が最初にClaude Codeへ投げた依頼がこれでした。返ってきたのは、READMEだけのつもりがpackage.jsonのスクリプト名まで書き換わった差分。動きはするけど、本当に直したかった手順とは別の場所が3ファイル変わっている。「これ、公開していいやつ？」と画面の前で固まりました。

賢いはずのClaude Codeが、なぜ頼んでもいない場所まで触るのか。能力の問題ではありません。こちらが「どこまでやっていいか」を一言も決めていなかっただけです。新人に「店、いい感じにしといて」と言って出かけたら、棚ごと並べ替えられていた、みたいな話です。

この記事は、その「どこまで」を1枚の紙に書く話です。僕はこれを依頼文（最初のタスクの依頼文）と呼んでいます。

この記事の要点

• 最初の依頼で事故るのは、目的・許可範囲・検証・戻し方を決めずに「いい感じに」と頼むから。
• 依頼文には9項目（目的／読者の状態／読んでよい／編集してよい／実行してよい／触らない／検証／戻し方／次の一歩）を書く。
• Claude Codeに任せるのは「読む・直す・検証コマンドを走らせる」まで。削除・本番反映・課金は人が判断する。
• コピペで使える依頼文テンプレートと、依頼文の不備を自動チェックするJavaScriptを置いた。
• まずは「失敗してもgitで戻せる小さな1タスク」を1つだけ選ぶのが、最短の成功体験。

なぜ最初の1タスクで事故るのか

Claude Codeを入れた直後、多くの人がやるのは「広い依頼」です。「リポジトリを整理して」「READMEを直して」。気持ちはわかります。何ができるか試したいんですよね。

でも広い依頼を投げると、最初の10分は探索に消えます。Claude Codeはファイルをあちこち読み、関連しそうな場所を勝手に直し、最後は「たぶん動きます」という曖昧な報告で終わる。あなたは差分を全部読み直すはめになり、結局「自分でやったほうが速かった」となる。

原因はモデルの賢さではありません。ゴールと境界を渡していないことです。人間の新人でも、初日に「自由にやって」と言われたら手が止まるか、暴走するかのどちらかです。境界を先に決めるだけで、この事故はほぼ消えます。

操作の基本そのものに不安がある人は、先にClaude Codeの始め方に目を通してから戻ってくると、この依頼文の話がすっと入ります。

依頼文に書く9つの項目

僕が毎回1枚に書くのは、次の9項目です。難しい言葉はいりません。各行に1つずつ答えを埋めるだけです。

項目	何を書くか	悪い例 → 良い例
目的	終わったらどうなっていれば成功か	「READMEを直す」→「READMEの手順をpackage.jsonに合わせる」
読者の状態	誰のための作業か	（空欄）→「初心者、1回だけ確実に成功したい」
読んでよい	参照を許すファイル	（全部）→「README.mdとpackage.jsonだけ」
編集してよい	書き換えを許すファイル	（全部）→「README.mdだけ」
実行してよい	走らせてよいコマンド	（何でも）→「npm run build だけ」
触らない	絶対に変えさせない場所	（未指定）→「package-lock、デプロイ設定、価格」
検証	成功の証拠になるもの	「動けばOK」→「buildが通る／差分がREADMEだけ」
戻し方	失敗時にどう元へ戻すか	（なし）→「READMEをgitから戻す」
次の一歩	読者が次に進む先を1つ	（3つ並べる）→「まず無料の入門資料だけ」

ポイントは「触らない」と「検証」と「戻し方」です。ここを書いた瞬間に、依頼が「お願い」から「安全に任せられる仕事」に変わります。

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

そのまま使える雛形です。コードブロックなのは、Claude Codeにそのまま貼って渡せるようにするためです。自分のリポジトリ名と直したい場所に書き換えてください。

# 最初のタスクの依頼文

目的: READMEのセットアップ手順を package.json の内容に合わせる。
読者の状態: 初心者。1回だけ確実に成功したい。
読んでよい:
- README.md
- package.json
編集してよい:
- README.md だけ
実行してよい:
- npm run build
触らない:
- package-lock.json
- デプロイ設定（環境変数・公開設定）
- 価格や申込みリンク
検証:
- npm run build が通る
- git diff が README.md だけの変更になっている
戻し方:
- 検証に失敗したら README.md を git から元に戻す
次の一歩:
- まずは無料の入門資料だけ案内する

実際の依頼例で言うと、READMEの手順をpackage.jsonに合わせるだけなら、読むのはREADMEとpackage.json、編集はREADMEだけ、証拠はnpm run build。この粒度なら、失敗してもgit checkout -- README.mdの一発で戻せます。最初の1回はこれくらい狭くていい。むしろ狭いほうが、成功したかどうかをあなた自身が判断できます。

Claude Codeに任せる範囲と、人が判断する範囲

依頼文を書くとき、僕は頭の中でこの線を引いています。境界があいまいだと、Claude Codeは「親切のつもり」で線を越えてきます。

Claude Codeに任せてよい	人が判断する（自動化しない）
指定ファイルを読む	どのファイルを触らせるかの決定
指定ファイルだけ直す	ファイルの削除
npm run buildなど検証コマンドを走らせる	本番への反映・デプロイ
差分の要約を返す	課金が発生する操作
失敗の原因を報告する	git push --forceなど戻せない操作

左側は任せる。右側は、最初は全部「実行前に人へ確認」にしておく。安全だと分かった操作だけ、あとから少しずつ自動の側へ動かす。この順番を守るだけで、夜中に肝を冷やす回数が激減します。

依頼を渡すときは、こう一言添えます。

この依頼文の範囲だけで、1つの小さなタスクを実行してください。
範囲外だと判断したことは、実行せず提案だけにしてください。

最初に次の5つを返してください。
1. これから読むファイル
2. これから編集するファイル
3. 作業前後に走らせる検証コマンド
4. 変更の差分の要約
5. 失敗したときの戻し方

「実装の前に計画と検証を返して」と頼むのが肝です。返ってきた計画が依頼文の範囲を超えていたら、その場で止められます。手を動かす前に止められると、後始末がいりません。

依頼文の不備を自動チェックするコード

依頼文を書いたつもりでも、項目が抜けることはよくあります。僕は項目の有無を機械でチェックしています。コピペで動くJavaScriptです。Node.jsでnode check-brief.mjsのように動かせます。

// 依頼文に必要な項目がそろっているか機械的に確認する
const requiredFields = [
  "目的",
  "読んでよい",
  "編集してよい",
  "実行してよい",
  "触らない",
  "検証",
  "戻し方",
  "次の一歩",
];

export function validateFirstTaskBrief(markdown) {
  // 含まれていない項目を洗い出す
  const missing = requiredFields.filter((field) => !markdown.includes(field));

  // 検証コマンド（ここでは npm run build）まで書いてあるかも見る
  const hasProofCommand = markdown.includes("npm run build");

  return {
    ok: missing.length === 0,
    missing,
    readyForClaudeCode: missing.length === 0 && hasProofCommand,
  };
}

// 動作確認の例
const sample = `
目的: READMEを package.json に合わせる
読んでよい: README.md
編集してよい: README.md
実行してよい: npm run build
触らない: package-lock.json
検証: npm run build が通る
戻し方: git から README.md を戻す
次の一歩: 無料の入門資料
`;

const result = validateFirstTaskBrief(sample);
console.log(result);
// → { ok: true, missing: [], readyForClaudeCode: true }

このチェックを通してから依頼文を渡すようにすると、「触らない」と「戻し方」の書き忘れが消えます。人間の目だけに頼ると、忙しい日に必ずどこか抜けます。機械でわかることは機械に任せるのが楽です。

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

1. READMEや手順書の修正 「ドキュメントを最新化して」だと範囲が無限です。「READMEのセットアップ章だけ、package.jsonのスクリプト名に合わせる」と絞れば、差分が1ファイルに収まり、npm run buildで確かめられます。最初の1タスクにいちばん向いています。

2. プルリクエストの一次レビュー 「このPRを見て」ではなく、「変更ファイルのうちsrc/配下だけ読んで、テストが落ちそうな箇所を指摘して。コードは直さず指摘だけ」。読むのは任せ、直す判断は人に残す。これで「勝手に直して別のバグを生む」事故が防げます。

3. CTA（読者の次の一歩への導線）の差し替え 人気記事の下にあるボタンを1つだけ差し替える作業でも、「関連コンポーネントを探して直して」は広すぎます。先に「触ってよいファイル」「確認する公開URL」「差し替えるリンク」を依頼文で決める。作業後の確認が「なんとなく良さそう」から「この証拠なら出せる」に変わります。

僕がやらかした失敗3つ

正直に書きます。依頼文を使い始める前、僕は同じ失敗を繰り返していました。

ひとつ目は、「触らない」を書かなかったこと。READMEを直してほしいだけなのに、Claude Codeが親切心でpackage.jsonまで整えてくれて、buildが通らなくなりました。触らない: package-lock.json, デプロイ設定の3行を足しただけで、これは二度と起きなくなりました。

ふたつ目は、検証を「動けばOK」で済ませたこと。何をもって「動く」のか決めていないので、毎回差分を目で全部追っていました。検証: npm run build が通る／差分がREADMEだけと具体的なコマンドにしたら、確認が10秒で終わるようになりました。

みっつ目は、次の一歩を3つ並べたこと。記事末尾に資料も教材も相談も全部貼ったら、読者の反応がぼやけました。読者の状態に合わせて1つに絞ったほうが、結局その1つがちゃんとクリックされます。何を書くべきかはCLAUDE.mdの書き方にプロジェクト規約として残しておくと、毎回ぶれません。

よくある質問

Q. 毎回この9項目を全部書くのは面倒では？ 最初の数回だけです。テンプレートを1つ作ってfirst-task-brief.mdとして置いておけば、次からは中身を3〜4行差し替えるだけ。書く時間より、暴走した差分を読み直す時間のほうがずっと長いです。

Q. 簡単な作業でも依頼文がいりますか？ 「1ファイルの誤字直し」レベルなら口頭の依頼で十分です。依頼文が効くのは、複数ファイルに触れる可能性がある作業や、本番・課金・削除がかすめる作業です。迷ったら書く、で損はしません。

Q. 英語のキー名（Goal, May editなど）で書くべき？ チームでログを並べて比較するなら英語キーが揃って便利ですが、1人で使うなら日本語で十分です。Claude Codeはどちらでも理解します。大事なのは言語ではなく、項目が抜けていないことです。

Q. プログラミングをしない人でも使えますか？ 使えます。記事執筆や資料整理でも、「読んでよい・編集してよい・触らない」の考え方は同じです。非エンジニア向けの入り口はエンジニアじゃない人のClaude Codeにまとめています。

Q. Claude Codeが依頼文を無視して範囲外を触ったら？ まず「最初に計画と検証を返して」と頼み、手を動かす前に止めるのが基本です。それでも越えたら、依頼文の「触らない」が具体的でない可能性が高いです。フォルダ名やファイル名まで明記すると効きます。

実際に試した結果

この依頼文を、READMEをpackage.jsonに合わせる小さな作業で試したのが一番わかりやすかったです。編集してよい: README.md だけと先に書いておくと、Claude Codeがpackage-lockや設定ファイルへ手を伸ばす流れが、実行前の計画の段階で止まりました。差分を読み直す手間がそのまま消えたのが大きい。

検証にnpm run buildとgit diffの2つを入れたのも効きました。作業後の判断が「雰囲気で良さそう」ではなく、「buildが緑、差分はREADMEだけ、だから出せる」という言い切りに変わった。逆に次の一歩を空欄にした回は、自分でも「次に何を案内するんだっけ」と迷い、記事末の導線がぼやけました。

結局わかったのは、Claude Codeに大きな自由を渡すことが価値ではない、ということです。最初の1タスクを小さく切って、成功・失敗・次の行動を自分の目で見える状態にする。これが一番速い。境界を1枚書く面倒くささは、暴走した差分を後で読み直す面倒くささに比べたら、ないも同然でした。

外側の仕組みをもっと詰めたい人は、AnthropicのClaude Code公式ドキュメントで許可設定の挙動を確認しておくと、依頼文と設定の役割分担がはっきりします。会社の業務にClaude Codeを入れて運用ルールごと整えたい場合は、研修・相談で実際の作業に合わせた依頼文の型づくりから一緒に進められます。