Claude Code最初の1タスクRunbook: 失敗しない依頼・確認・commit前レビュー

最初の1タスクでClaude Codeへの信頼は決まる

Claude Codeを入れた直後に、いきなり「この機能を全部作って」「アプリ全体を直して」と頼むと失敗しやすくなります。理由は単純で、Claude Codeが悪いというより、依頼の範囲、確認方法、権限、前提知識がまだ共有されていないからです。

このRunbookは、Claude Codeを初めて実務リポジトリに入れる人、チームに導入する人、オンボーディングの最初の30分を整えたい人向けの手順書です。Runbookとは「同じ状況で何度も使える作業手順」のことです。ここでは、最初の1タスクを「小さく依頼する」「作業前に確認する」「差分を読む」「commit前にレビューする」「次回へ引き継ぐ」までに分解します。

基本操作がまだ不安なら、先にClaude Code入門ガイドを読んでください。プロジェクト固有の指示を整える段階ではCLAUDE.mdテンプレート集が役立ちます。公式情報はClaude Code overview、memoryとCLAUDE.md、permission modes、common workflows、CLI referenceを基準に確認します。

flowchart LR
  A["リポジトリを読む"] --> B["安全な候補を3つ出す"]
  B --> C["1タスクに絞る"]
  C --> D["計画だけ確認する"]
  D --> E["最小差分を作る"]
  E --> F["テストとdiffを確認する"]
  F --> G["handoff noteを残す"]

良い最初のタスクの条件

最初のタスクは、成果の大きさより「安心して任せ続けられるか」を見るためのものです。次の5条件を満たすほど、初心者にもチームにも向いています。

条件	初心者向けの言い換え	良い例
ローカルで完結する	本番、顧客データ、外部送信に触らない	READMEのコマンド確認、既存テストの1件追加
範囲が小さい	触るファイルと終了条件が見える	1コンポーネント、1テスト、1ドキュメント
検証できる	成功をコマンドや画面で確かめられる	npm.cmd run test、git diff --check
戻せる	悪い差分をすぐ捨てられる	生成物や設定ではなく通常ファイル
説明できる	なぜその変更かを人間が追える	変更理由、リスク、未確認点が書ける

逆に、最初から「認証を全部作って」「古いコードを全部モダン化して」「CIもデプロイも直して」と頼むのは危険です。Claude Codeの能力を測っているつもりでも、実際には前提不足、権限確認、テスト不足、レビュー不能なdiffが同時に起きます。

安全な最初のタスク一覧

チーム導入では、この表から選ぶだけでも事故が減ります。

タスク	依頼の狙い	成功条件
リポジトリ地図を作る	いきなり編集させず、理解力を見る	entry point、主要コマンド、危険領域が説明される
失敗テストを1つ要約する	原因調査の粒度を見る	失敗箇所、仮説、次の最小手が出る
READMEの古いコマンドを直す	影響の小さい実編集を試す	コマンドが実行でき、差分が小さい
既存テストにassertionを1つ足す	仕様理解とテスト観を見る	テストが落ちる理由と通る理由を説明できる
UI文言を1箇所だけ直す	ファイル探索と最小変更を見る	対象コンポーネントだけが変わる
lint警告を1つだけ直す	変更の局所性を見る	警告が1件減り、挙動は変わらない
最小のCLAUDE.mdを作る	次回以降の作業品質を上げる	コマンド、禁止事項、レビュー方法が短く書かれる

ここで重要なのは「小さいが実務に効く」ことです。単なるお試しではなく、オンボーディング、バグ調査、ドキュメント整備、テスト強化のどれかに接続します。

そのまま使える依頼テンプレート

最初の依頼では、編集を許可する前に読む、要約する、候補を出す、の順にします。

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

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

候補が出たら、1つだけ選んで計画を出させます。

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

計画に納得したら、編集許可を明示します。

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

commit前のレビュー依頼もテンプレート化します。

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

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

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

30分の実行フロー

最初の5分は、Claude Codeに任せる前に人間側で状態を固定します。Windows PowerShellなら次をそのまま使えます。

Get-Location
git status --short
git branch --show-current
rg --files | Select-Object -First 40

MacやLinuxなら次です。

pwd
git status --short
git branch --show-current
rg --files | head -n 40

汚れたworktreeで始めると、Claude Codeの差分なのか既存変更なのかが分からなくなります。未commitの作業がある場合は「これは人間の変更。触らない」と最初に伝えます。

次の10分で、候補から1つに絞ります。おすすめは「READMEの古いコマンド修正」「既存テストのassertion追加」「失敗テスト1件の原因要約」です。新機能追加はまだ早いです。

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

git diff --stat
git diff --check
git diff
git status --short

最後の5分でhandoff noteを残します。handoff noteとは、次の人または次のセッションに渡す短い引き継ぎメモです。Claude Codeは長い会話の途中で文脈が薄くなることがあります。あとから読み返せるメモを残すだけで、次回の立ち上がりが速くなります。

3つの具体的なユースケース

ユースケース1: 新メンバーのオンボーディング

新しく入った開発者に、最初から大きなissueを渡すのは重いです。Claude Codeには、リポジトリ地図、主要コマンド、触ってはいけないディレクトリ、最初に読むファイルをまとめさせます。

依頼例は「このrepoを新人向けに説明するメモを作って。推測と事実を分けて、コマンドは実行結果つきで書いて」です。成功条件は、READMEを読むだけでは分からない実務上の注意が出ることです。たとえば、生成ファイル、ローカルだけの設定、CIとローカルの差分が分かれば十分価値があります。

ユースケース2: 既に見えているバグの再現メモ

「たまに壊れる」をいきなり修正させると、Claude Codeは広い仮説に飛びがちです。まずは再現条件、期待値、実際の結果、関係しそうなファイルを整理させます。詳しい書き方はClaude Codeバグ報告テンプレートと相性が良いです。

成功条件は、修正コードではなく「次に人間が確認できるメモ」です。再現できないなら、再現できない事実と追加で必要なログを明記させます。ここで無理に修正させないことが、後の手戻りを減らします。

ユースケース3: ドキュメントやUI文言の小修正

マーケティングサイト、管理画面、社内ツールでは、最初の作業として文言修正が向いています。ただし「全部自然にして」では広すぎます。「料金ページのCTA文言を1箇所だけ」「設定画面の説明を1行だけ」のように絞ります。

成功条件は、対象ファイル以外が変わっていないこと、表示文言の意味が変わっていないこと、必要ならスクリーンショットやローカル表示で確認できることです。多言語サイトなら、日本語だけ直して他言語を放置しない確認も入れます。

ユースケース4: 既存テストの小さな強化

テストがあるプロジェクトなら、最初の実装タスクは新機能よりassertion追加が安全です。たとえば、既存のバリデーションテストに境界値を1つ足す、エラーメッセージの期待値を明示する、空配列のケースを足す、という粒度です。

成功条件は、テストが通ることだけではありません。「そのassertionが何を守るのか」を説明できることです。説明できないassertionは、将来の保守でノイズになります。

commit前のdiffレビュー手順

Claude Codeが編集したら、必ず人間のレビューに戻します。最初の1タスクでは、自動commitや自動pushは避けます。公式のpermission modesにもある通り、権限モードは便利さと監督のバランスです。初回はplan modeや通常確認を使い、bypassPermissionsのような強い権限は隔離環境以外で使わないほうが安全です。

commit前チェックリスト

[ ] 依頼したファイルだけが変わっている
[ ] 生成物、秘密情報、ローカル設定が混ざっていない
[ ] テストまたは代替確認の結果が残っている
[ ] 失敗した確認コマンドが隠されていない
[ ] diffを読んで説明できない変更がない
[ ] 次回に残すTODOがhandoff noteに書かれている

レビュー時は、まずgit diff --statで広がりを見ます。次にgit diff --checkで末尾スペースや基本的なpatch問題を見ます。最後に本文のdiffを読み、依頼外のリファクタ、勝手な命名変更、テストを伴わない仕様変更がないかを確認します。

よくある失敗と避け方

1つ目の失敗は、範囲が大きすぎることです。「ログインを全部直して」ではなく、「ログイン失敗時のエラーメッセージ表示を1テストで確認して」と言います。Claude Codeに自由度を渡すのは、信頼ができてからで十分です。

2つ目は、テストや確認方法がないまま「できました」を受け入れることです。テストがないなら、代替確認を先に決めます。画面確認、型チェック、git diff --check、ログの比較、READMEコマンドの実行など、何か1つは証拠を残します。

3つ目は、permission promptを雑に承認することです。権限確認が出たら、何のためのコマンドか、どのパスに触るか、ネットワークや削除を含むかを確認します。毎回止まるのが面倒なら、先に許可するコマンドを絞るほうが安全です。

4つ目は、文脈喪失です。長い会話や複数の修正をまたぐと、最初に決めた境界が薄れます。作業前の境界、実行したコマンド、残リスクはhandoff noteに残します。CLAUDE.mdに書くべき永続ルールと、今回だけのメモを混ぜないことも大事です。

5つ目は、既存の未commit変更を壊すことです。チーム開発では他の人や別エージェントが同じリポジトリを触っていることがあります。最初にgit status --shortを取り、依頼外の変更は「触らない」と明示します。

handoff noteテンプレート

作業の最後に、次のテンプレートをそのまま貼って埋めます。

## Handoff note

- Task:
- Changed files:
- Verification run:
- Verification not run:
- Important diff points:
- Remaining risks:
- Do not touch next time:
- Suggested next smallest task:

このメモは、commit messageより少し広い情報を残す場所です。commitする前ならPR説明の下書きになり、commitしない場合でも次回の開始点になります。

次に読むものと有料導線

初回タスクが成功したら、次は「毎回同じ品質で進める仕組み」を作ります。個人ならCLAUDE.mdテンプレート集で作業ルールを短くまとめます。承認やsandboxの考え方を固めたい場合はClaude Code Approval and Sandbox Guideを読みます。

テンプレート、チェックリスト、チーム導入用の教材をまとめて使いたい場合は/products/を確認してください。自社リポジトリに合わせたオンボーディング、権限設計、レビュー運用まで一緒に整えたい場合は/training/から相談できます。最初の1タスクだけならこの記事で十分ですが、複数人に広げるならルール、証跡、教育の3点を先に揃えたほうが安定します。

実際に試した結果、Masaの作業では「まずrepoを読ませる」「1ファイルだけ変更させる」「git diffを一緒に読む」「handoff noteを残す」の4点を固定したときが一番安定しました。最初から大きな修正を任せた回は、確認コストが増えて結局人間が巻き取りました。逆に、30分で終わる小さなタスクを成功させると、2回目以降に任せる範囲を判断しやすくなり、チームメンバーにも説明しやすくなりました。