0:00 0:00
Article
Claude Codeで最初の小さな機能追加をする手順：題材選びから計画・実装・テスト・コミットまで
Claude Codeに初めて実タスクを任せるとき、どんな題材を選び、どう依頼文を書き、どこで計画を確認し、差分レビューとテスト・コミットまでをどう進めるかを、公式クイックスタートと一般的なGit運用に沿って整理します。
結論：最初の1機能は「1ファイル・30分・テストあり」で済むものを選ぶ
Claude Codeで最初の実タスクを任せるとき、いきなり大規模な機能追加から入ると、計画の範囲が広すぎてAIもレビュアーも追えなくなります。最初の1回は次の条件を満たす題材を選ぶと失敗しにくいです。
- 対象ファイルが1〜2ファイルで済む
- 既存テストが走る、または簡単なテストを追加できる
- 30分以内で人間が自力でも終えられる難易度
- 破壊してもGitで巻き戻せる状態にある
この記事では、公式のクイックスタートとベストプラクティスをもとに、題材選び→ブランチ作成→依頼文→計画確認→実装→差分レビュー→テスト→コミットの7ステップを通しで解説します。CLIの基本操作は基本コマンド記事、事前のCLAUDE.md整備はCLAUDE.mdの書き方にまとめてあるので、まだの方はそちらを先に読んでください。
ステップ1：題材を決める
最初の1本としておすすめの題材は次のようなものです。
- フォーム入力のバリデーションを1項目追加する
- 特定の関数にユニットテストを1〜2ケース追加する
- ログ出力を1箇所だけ構造化する
- READMEのセットアップ手順を最新化する
- 既存の関数コメント（JSDocやPython docstringなど）を1ファイルだけ書く
逆に最初の1回で避けたいのは、「認証まわり全部直して」「このAPIをREST→GraphQLにして」のような、影響範囲が読みにくいタスクです。
ステップ2：作業ブランチを切ってから起動する
AIに任せる前に、必ず専用ブランチに切り替えておきます。mainで直接作業すると、差分の巻き戻しがしづらくなります。
git switch -c feature/first-claude-task そのあと、プロジェクトルートでclaudeを起動します。
claude 起動直後に/statusで現在のログイン状態・権限モード・モデルを確認しておくと安心です。権限モードの詳細は基本コマンド記事を参照してください。
ステップ3：最初の依頼文を書く
いきなり実装を頼まず、「まず計画だけ出して」と指示するのが安全策です。対話セッションに入ったら、次のようなテンプレートで依頼します。
お願い:
- src/forms/signup.ts のメールアドレス入力に、空文字と @ を含まない場合のバリデーションを追加したい
- 既存のテスト (tests/forms/signup.test.ts) に、追加したバリデーションのテストを2ケース足したい
進め方:
1. まず影響範囲と修正案を計画として出して
2. 計画に同意したら、実装に進んで
3. 実装後に `npm test` を通して
4. 差分だけ要約して教えて依頼文で重要なのは次の3点です。
- どのファイルを触るかを名指しで書く
- 「計画→実装→テスト→差分報告」の順序を明示する
- 終了条件（テストが通る、差分要約が出る）を書く
ステップ4：計画を必ず読む
Claude Codeは計画ステップで、触るファイル・追加する関数・影響するテストを列挙してきます。ここで次の観点を確認してください。
- 触るファイルが依頼した範囲に収まっているか
- 依頼外のリファクタや削除が紛れ込んでいないか
- テストの追加方針が妥当か
- 外部パッケージや依存を追加しようとしていないか（不要な依存追加は断る）
計画に違和感があれば、「外部依存は追加しないで」「テストは既存のJestで書いて」「リファクタは今回やらない」のように短い修正指示を返します。計画と実装を分ける運用は、ベストプラクティスでも推奨されています。
ステップ5：実装を承認する
計画に同意したら、「この計画で進めて」と返します。Claude Codeはファイルを編集するたびに差分を出し、承認を求めます。
承認モードは用途に応じて次のように使い分けてください。
| 状況 | 推奨モード |
|---|---|
| 初めての対話・重要な本番コード | 既定のdefault（都度承認） |
| テストディレクトリなど影響範囲が限定的 | acceptEdits（編集を自動承認） |
| 読み取り専用で調査・計画だけさせたい | plan |
| サンドボックス環境で一気に進めたい | bypassPermissions（使用は慎重に） |
承認中に「やっぱり違う方針にしたい」と思ったら、Ctrl+Cで中断し、依頼を書き直します。中断は何度しても問題ありません。
ステップ6：差分レビューとテスト
実装が終わったら、Claude Code任せにせず必ず人間の目で差分を確認します。
git diff 確認ポイントは次です。
- 依頼していないファイルが編集されていないか
- 依頼外のコメント削除・整形・インポート並び替えが紛れていないか
- 秘密情報（APIキー・個人情報）がテスト用に書かれていないか
- 生成されたコードが既存のコーディング規約に合っているか
続いて、プロジェクトのテストコマンドを実行します。
npm test テストが落ちた場合は、Claude Codeに「このテスト出力を受けて修正して」と渡し、計画→実装→差分確認のループを1〜2回回します。ここで同じ修正を3回以上繰り返すようなら、方針自体を見直すサインです。いったんgit restore .で巻き戻し、依頼文を書き直してください。
ステップ7：コミットして区切る
差分とテストに問題がなければ、小さな単位でコミットします。
git add -p git commit -m "feat(signup): add email validation and tests" Claude Codeにコミットまで任せることもできますが、最初のうちは自分でコミットメッセージを書くほうが、何をAIに任せたかの記録になります。慣れてきたら、セッション内で「ここまでをコミットして、メッセージはConventional Commits形式で」と頼むと、規約に沿ったメッセージを作ってくれます。
最初の1本を通すためのチェックリスト
- 作業用ブランチに切り替えた
-
CLAUDE.mdにプロジェクトの前提と禁止事項を書いた - 依頼文に「計画→実装→テスト→差分報告」の順序を書いた
- 計画の時点で影響範囲を確認した
- 承認モードを用途に合わせて選んだ
-
git diffで想定外の変更がないか確認した - テストを実行し、落ちた場合は2回までで方針を見直した
- 小さな単位でコミットした
よくある失敗と対処
- 依頼外のリファクタが混入する：依頼文に「リファクタは今回やらない」と明記し、計画段階で指摘して除外させます。
- 外部パッケージが勝手に追加される：計画確認時に断り、必要なら別タスクとして切り出します。
- テストが通らず無限ループに入る：2回修正して通らないなら、
git restore .で戻し、依頼内容を分割します。 - セッションが長くなり応答が遅い：
/compactで要約圧縮するか、区切りのよいところで/clearして新しい依頼を始めます。 - 差分が大きすぎてレビューできない：題材の切り出しが大きすぎるサインです。1ファイル・30分ルールに戻ります。
まとめ：小さく始めて「計画→差分→テスト」を習慣にする
Claude Codeに最初の機能追加を任せるコツは、題材を絞り、計画と実装を分け、差分とテストを人間が最終確認することです。この3点さえ守れば、AIに任せる範囲を徐々に広げても事故が起きにくくなります。
次のステップとしては、CLAUDE.mdの書き方で前提と禁止事項を明文化し、基本コマンドでスラッシュコマンドと権限モードの操作に慣れると、日常運用がさらに安定します。
