Claude Codeに最初の1タスクを安全に任せる手順｜選び方・依頼文・commitまで

Claude Codeを入れた初日、僕は調子に乗って「このプロジェクトのテスト、全部直して」と打ちました。

5分後、画面には18ファイルの差分が並んでいました。動いているものもあった。でも、なぜ変えたのか僕には説明できないコードが半分以上で、結局ぜんぶ捨てました。45分が消えました。

その日に学んだのは、AIに最初に渡す仕事の大きさが、その後ぜんぶを決めるということです。大きい仕事を投げると、賢いかどうか以前に「確認できない差分」が一気に出てくる。逆に、転んでも捨てられる小さな仕事を1個だけ渡すと、信頼は驚くほど早く積み上がります。

この記事は、Claude Codeに最初の1タスクを任せて、最後にcommitするまでを、僕が毎回なぞっている手順書（Runbook）としてまとめたものです。インストール直後の30分の流れは最初の30分でやったことに、既存リポジトリへの初手プロンプトは既存コードで最初に投げるプロンプト集に分けてあります。ここでは「1個のタスクを安全に回し切る実務」だけに絞ります。

この記事の要点

• 最初のタスクは成果の大きさではなく「小さい・戻せる・確かめられる」で選ぶ。これだけで事故の大半は消える。
• 依頼は一気に投げない。読む → 計画 → 編集 → commit前レビューの4段に割る。各段に貼れる依頼文を用意した。
• 編集の前に必ずgit statusでworktreeをきれいにする。汚れたまま始めると、AIの差分と自分の差分が混ざって地獄を見る。
• commit前は人間がgit diffを読む。最初の1タスクで自動commitや強い権限モードは使わない。
• 終わったら3行の引き継ぎメモを残す。次のセッションの立ち上がりが段違いに速くなる。

なぜ「最初の1タスク」が全部を決めるのか

Claude Codeは、頼めば本当に手を動かします。ファイルを読み、検索し、編集し、テストを走らせる。ここが普通のチャットAIと違うところで、便利な反面、最初に渡す仕事を間違えると被害もそのまま大きくなります。

僕の18ファイル事故は、Claude Codeが下手だったわけではありません。「テスト全部」という曖昧で大きい依頼が悪かった。範囲が見えない、終了条件がない、差分が読み切れない。この3つが同時に起きると、出てきたものが正しいかどうかを人間が判断できなくなります。判断できない成果物は、良くても捨てるしかない。

逆に、30分で終わる小さな仕事を1個きれいに通すと、次に任せる範囲を自分で決められるようになります。「ここまでは任せて平気」という感覚は、説明ではなく成功体験でしか手に入りません。だから最初の1タスクは、性能テストではなく信頼を積む最初の一歩として選ぶのが正解です。

公式のクイックスタートも、いきなり大改修ではなく小さな操作から始める流れになっています。考え方は同じです。

良い最初のタスクの選び方

迷ったら、次の4つを全部満たすものを選びます。3つしか満たさないなら、もっと小さくできないか考えます。

条件	かみくだくと	良い例
小さい	触るファイルと「終わり」が見える	1ファイル、1テスト、1文言
戻せる	悪い差分をすぐ捨てられる	生成物や設定ではなく普通のソース
確かめられる	成功をコマンドか画面で示せる	npm test、git diff --check、表示確認
説明できる	なぜ変えたかを人間が追える	変更理由・リスク・未確認点が書ける

この4つを言葉にしておくと、依頼の前に自分でブレーキを踏めます。僕は「これ、戻せる？確かめられる？」と口に出してから打つようにしてから、捨てる差分がほぼなくなりました。

逆に最初は避けたいのが、こういう依頼です。

• 「認証まわりを全部直して」——範囲が無限で、確認も無理。
• 「古いコードをモダンにして」——どこで終わりか誰も決められない。
• 「CIもデプロイも直して」——本番や外部に手が伸びる。戻すのが難しい。

大きいタスクが悪いのではなく、最初に渡すには情報が足りなさすぎるのです。

安全な最初のタスク一覧

選ぶのが面倒なら、この表から1つ取るだけでも十分です。どれも「小さいけど実務に効く」ものに絞りました。

タスク	依頼の狙い	成功の判定
リポジトリの地図を作らせる	いきなり編集させず理解力を見る	entry point・主要コマンド・危険領域が出る
失敗テスト1件を要約させる	原因調査の粒度を見る	失敗箇所・仮説・次の最小手が出る
READMEの古いコマンドを直す	影響の小さい実編集を試す	コマンドが実際に動き、差分が小さい
既存テストにassertionを1つ足す	仕様理解とテスト観を見る	落ちる理由と通る理由を説明できる
UI文言を1箇所だけ直す	ファイル探索と最小変更を見る	対象コンポーネントだけが変わる
lint警告を1つだけ消す	変更の局所性を見る	警告が1件減り、挙動は変わらない

最初の1個は「リポジトリの地図を作らせる」が無難です。編集を伴わないので事故りようがなく、Claude Codeがこのコードベースをどう読んでいるかが分かる。地図がズレていたら、その時点で大きいタスクを任せていなくて本当によかった、と思えます。

依頼は4段に割る

ここが手順書の中心です。最初の1タスクでは、1回の依頼で全部やらせないでください。読む → 計画 → 編集 → commit前レビューの4段に割って、各段で一度立ち止まります。

段1：読ませて、候補を出させる

まだ編集させません。読んで、要約して、候補を出すところまで。

このリポジトリを読んで、まだ編集せずに次を返してください。

1. 主要なentry point
2. よく使うbuild / test / lint コマンド
3. 触ると危険なディレクトリや生成物
4. 30分で安全に終わるタスク候補を3つ
5. 各候補の確認方法と、失敗したときの戻し方

段2：1つに絞って、計画だけ出させる

候補から1つ選び、いきなり書かせず計画を先に見ます。

候補2だけを進めます。まだ編集しないでください。
変えるファイル、変える理由、想定する差分、確認コマンド、リスクを先に書いてください。
範囲が広がりそうなら、もっと小さい代替案も出してください。

ここで「もっと小さい代替案」を毎回求めるのがコツです。Claude Codeは放っておくと親切心で範囲を広げます。先に縮める方向の圧をかけておくと、差分が読める大きさに収まります。

段3：計画どおり、最小差分で編集させる

計画に納得してから、初めて編集を許可します。

計画どおり、最小差分で編集してください。
依頼外のファイルは触らないでください。
編集後に、実行した確認コマンド・失敗した確認・残ったリスクをまとめてください。

段4：commit前にレビューさせる

編集が終わっても、すぐcommitしません。まずClaude Code自身にレビューさせて、それから人間がgit diffを読みます。

commit前レビューをしてください。

1. git diff を読んで、依頼外の変更が混ざっていないか
2. テスト不足・確認不足がないか
3. セキュリティ・データ破壊・設定変更のリスクがないか
4. commitに含めるべきでないファイルがないか
5. まだ人間が判断すべき点はないか

結論は「commitしてよい」「修正してから」「止める」の3択で返してください。

3択で結論を出させると、レビューが感想で終わりません。「止める」が返ってきたら、それは事故を1件防げたということです。

軽量検証だけを定型化したくなったら、型チェック・テスト・確認の3つだけ回す軽量ハーネスのワークフローが次のステップになります。

30分の実行フロー

時間で区切ると迷いません。僕は毎回この配分でやっています。

最初の5分は、Claude Codeに渡す前に人間側で状態を固定します。worktreeが汚れていると、AIの差分なのか自分のやりかけなのか分からなくなる。これが一番よくある事故です。Windows PowerShellならこう。

Get-Location
git status --short
git branch --show-current

MacやLinuxならこう。

pwd
git status --short
git branch --show-current

未commitの変更が残っていたら、片付けるか、Claude Codeに「これは僕の変更。触らないで」と最初に伝えます。ここを飛ばすと、あとで差分の切り分けに30分溶かします（経験者は語る）。

次の10分で、候補から1つに絞ります。最初の1個は前述のとおり「リポジトリの地図」か「READMEの古いコマンド修正」が安全です。新機能はまだ早い。

20分地点では、実装より確認を優先します。差分を広げるより、いま出ている1つの変更が本当に正しいと示すほうが、2回目以降がずっと安定します。

最後の5分で、引き継ぎメモを3行だけ残します。Claude Codeは長い会話の途中で文脈が薄くなることがあるので、次に読み返せるメモがあるだけで立ち上がりが変わります。

commit前のdiffレビュー手順

Claude Codeが編集したら、必ず人間のレビューに戻します。最初の1タスクで自動commitや自動pushは避けてください。権限モードについては公式の共通ワークフローが参考になりますが、初回は通常確認かplan modeで十分です。bypassPermissionsのような強い権限は、隔離環境以外で最初から使わないほうがいい。

まずは差分の広がりから見ます。

git diff --stat
git diff --check
git diff

git diff --statで「思ったより広くないか」を確認。git diff --checkで末尾スペースや壊れたパッチを検出。最後に本文の差分を読んで、依頼していないリファクタ、勝手な命名変更、テストのない仕様変更が紛れていないかを見ます。

読みながら、頭の中ではこのチェックを回しています。

• 依頼したファイルだけが変わっているか
• 生成物・秘密情報・ローカル設定が混ざっていないか
• テストか代替確認の結果が残っているか
• 失敗した確認コマンドが隠されていないか
• 自分の言葉で説明できない変更がないか

ここまで通って初めてcommitします。逆に1つでも引っかかったら、段2の「もっと小さい代替案」に戻ります。

コピペで使う：30分ランブックの最小スクリプト

最初の状態固定とcommit前確認は、毎回手で打つと忘れます。僕は次のシェルスクリプトをfirst-task.shとして置いて、bash first-task.sh checkのように呼んでいます。Mac / Linux、WindowsならGit Bashで動きます。

#!/usr/bin/env bash
# Claude Codeに最初の1タスクを任せる前後で使う最小ランブック
set -euo pipefail

step="${1:-help}"

case "$step" in
  start)
    # 段0：状態を固定する（worktreeが汚れていないか確認）
    echo "== 現在地 =="
    pwd
    echo "== ブランチ =="
    git branch --show-current
    echo "== 未commitの変更（空ならクリーン）=="
    git status --short
    echo "→ 上に何か出たら、片付けるか『触らないで』と伝えてから依頼する"
    ;;
  check)
    # 段4：commit前に人間が差分を読む
    echo "== 変更の広がり =="
    git diff --stat
    echo "== 末尾スペースや壊れたパッチ =="
    git diff --check
    echo "→ このあと git diff を必ず通読してからcommitする"
    ;;
  *)
    echo "使い方: bash first-task.sh [start|check]"
    echo "  start … 依頼前に状態を固定する"
    echo "  check … commit前に差分を確認する"
    ;;
esac

やっていることは単純です。でも「依頼の前にstart、commitの前にcheck」を機械にしておくだけで、worktreeの汚れと読まずcommitという二大事故が消えます。

引き継ぎメモのテンプレート

作業の最後に、これを貼って埋めます。3分で書けて、次回の自分を確実に救います。

## 引き継ぎメモ

- やったタスク:
- 変えたファイル:
- 実行した確認:
- やっていない確認:
- 差分で要注意の点:
- 残っているリスク:
- 次回これは触らない:
- 次にやるべき最小タスク:

commitするならPR説明の下書きになり、commitしないなら次回の開始点になります。CLAUDE.mdに書くべき「ずっと守るルール」と、この「今回だけのメモ」を混ぜないのも地味に大事です。

よくある質問

Q. 最初のタスクは何分くらいで終わるべき? 30分以内で終わるものを選んでください。30分を超えそうなら、それは最初の1タスクとしては大きすぎます。段2で「もっと小さい代替案」を出させて縮めましょう。

Q. テストがないプロジェクトでも任せていい? 任せていいですが、代わりの確認を先に決めます。画面表示、型チェック、git diff --check、READMEのコマンド実行など、証拠が1つ残ればOKです。「できました」を確認なしで受け入れないのが肝心です。

Q. Claude Codeに自動でcommitさせてもいい? 最初の1タスクでは避けてください。git diffを人間が読んでから手でcommitします。任せる範囲は、何回か成功して信頼ができてから広げれば十分です。

Q. 権限の確認（permission prompt）が毎回出て面倒。全部許可していい? やめたほうがいいです。何のコマンドか、どのパスに触るか、削除やネットワークを含むかを見てから判断します。面倒なら、先に許可するコマンドを絞るほうが安全です。

Q. チームに広げるときの最初の一歩は? 個人で1タスクを通す手順は本記事で十分です。複数人に広げるなら、ルール（CLAUDE.md）・証跡（diffと引き継ぎメモ）・教育（この手順の共有）の3つを先に揃えると崩れにくくなります。教材としてまとめて使いたい場合は教材一覧も用意しています。

実際に試した結果

冒頭の18ファイル事故のあと、僕は「Claude Codeは賢いか」で悩むのをやめました。代わりに固定したのは、読ませる → 1ファイルだけ変えさせる → git diffを一緒に読む → 引き継ぎメモを残すの4点だけです。

最初から大きい修正を任せた回は、確認コストが膨らんで結局人間が巻き取りました。逆に、30分で終わる小さいタスクを1個きれいに通した回は、次に任せる範囲を自分で判断できて、チームの誰かに説明するのも簡単でした。

最初の1タスクは、能力テストではなく信頼づくりです。小さく・戻せる・確かめられる仕事を1個選んで、4段に割って回す。たったこれだけで、AIへの「任せ方」は驚くほど安定します。