AI研修 LMS

Claude Code チュートリアル｜最初の 1 時間で実務に効く 5 タスク【2026年版】

公開: 2026-05-09

この記事でわかること

  • Claude Code に最初に投げるべき 5 つの実例タスク (バグ修正/テスト/リファクタ/ドキュメント/依存更新)
  • 各タスクの「最低限の指示」と「詰まりやすいポイント」
  • Sonnet で十分なタスクと Opus が必要なタスクの判別軸
  • 1 時間後に身につく Claude Code の運用感覚 (タスク粒度・差分確認・コミット粒度)

入門のあとに必要なのは「実例で動かす」こと

Claude Code 入門 で CLI 設定までは終わったとして、その次に必要なのは「実際のリポジトリで何ができるか」を体感することです。本記事は 最初の 1 時間で実務に効く 5 つの実例タスク を順に紹介します。各タスクの「最低限の指示」「詰まりやすいポイント」「コミット例」を具体的に示します。

開始前の準備:

  • 既存のリポジトリ (テスト済の Node.js or Python プロジェクト推奨)
  • 別ブランチで作業 (git checkout -b experiment/claude-tutorial)
  • CLAUDE.md にプロジェクト規約を記載済

実例 1: バグ修正 (10 分)

最初に投げるタスクとして最も学びが多いのが バグ修正 です。

最低限の指示

> npm test を実行してエラーがあれば修正して

これだけで Claude Code は:

  1. npm test を実行
  2. 失敗したテストの出力を解析
  3. 失敗原因のコードを特定 (Read + Grep ツール)
  4. 修正コードを Edit で書き換え
  5. 再度 npm test で確認
  6. 全 PASS まで自律的に繰り返す

詰まりやすいポイント

  • 環境依存のテスト: DB 接続が必要なテスト (integration_test) はローカルで動かない場合がある → CLAUDE.md に「integration_test は除外」と書いておく
  • flaky test: 時々失敗するテストを「常に失敗」と判断してしまう → /clear でセッションリセットして再試行
  • 修正範囲の暴走: 1 つのテストを通すために大量ファイルを書き換える → 「修正は最小範囲で」と明示

コミット例

fix: handle null user in getDisplayName()

null チェックが漏れて TypeError が出る件を修正。
related test: tests/test_user.py::test_get_display_name_null

実例 2: テスト追加 (15 分)

カバレッジを上げたい関数を 1 つ選び、テストを追加してもらいます。

最低限の指示

> src/utils.ts の formatCurrency 関数にカバレッジ 90% のテストを追加して。
> Edge case (負の数、ゼロ、超大きな数、小数桁) も網羅して。

詰まりやすいポイント

  • 仕様の確認: 「ゼロを渡したら 0 円表示か空文字列か」のような仕様判断を AI に丸投げしない。事前に決めて指示に含める
  • 既存テストの形式踏襲: 既存の test ファイルを参照しないと別形式で書かれることがある → 「既存の test_utils.py と同じスタイルで」と明示
  • 過剰な mock: 本来 mock 不要なところで mock を入れる → 「外部 I/O 以外は mock しないで」と指示

実例 3: リファクタ (15 分)

Claude Code が最も得意なタスクの 1 つです。

最低限の指示

> src/handler.ts の processRequest 関数 (200 行) を、
> 責務ごとに 3 つの関数に分割してください。
> 既存テストは全て通る状態を維持してください。

詰まりやすいポイント

  • 分割の粒度: 「3 つに分けて」と数字で指定するのが安定。「適切に分けて」だと 7-8 分割になることも
  • テスト追加の暴走: リファクタなのに新規テストを大量追加 → 「テストは追加しない、既存が通れば良い」と明示
  • commit 粒度: 1 commit になりがち → 「ステップごとに commit を分けて」と指示

コミット例

refactor: split processRequest into 3 functions

- validateInput: 入力 schema の検証
- transform: business logic の本体
- formatResponse: レスポンス整形

既存テスト 24 件全て PASS。

実例 4: ドキュメント生成 (10 分)

意外と効くのがドキュメント生成。Claude Code は コードを読んで実態に即した docs を書けます。

最低限の指示

> src/api/orders.ts の API クライアント向けドキュメント (Markdown) を
> docs/api/orders.md に書いてください。
> 各エンドポイントの 入力/出力/エラーレスポンス/サンプルコードを含めて。

詰まりやすいポイント

  • 過剰な docstring: 自明なところまで丁寧に書きすぎる → 「冗長なコメントは削って」と後で削減
  • 古い API の混入: 廃止済 API が残ったまま docs に書かれる → 「対象は v2 のみ、v1 は除外」と明示
  • 専門用語の正確性: 人間が校正必須。Claude は「だいたい合っている」レベルで止まる

実例 5: 依存パッケージ更新 (15 分)

最も嫌な作業を AI に任せられる場面。

最低限の指示

> package.json の依存を、breaking change のないマイナー/パッチ版まで上げて。
> Major 版は別 PR 用にリストだけ作って。

詰まりやすいポイント

  • lockfile: npm install 後の package-lock.json の差分が巨大になる → コミットを別に分ける
  • CI が通らない: リモートで CI 失敗 → ローカルで全テスト + lint + build を通してからコミット
  • 依存の依存: 直接依存だけ上げて transitive 依存が古いまま → npm audit fix を併用

1 時間後に身につく感覚

5 つを通すと、以下の感覚が身につきます。

感覚内容
タスク粒度30 分〜2 時間が適正。それ以上は分割
差分確認必ず git diff を目視。Claude が「やった」と言っても見る
コミット粒度意味的に分ける指示を最初に出す
暴走の予兆50+ ファイル変更、新規 lib 大量追加、テスト改変
モデル選択9 割は Sonnet、複雑な設計や大規模リファクタで Opus

次のステップ

ここまでの 5 タスクは「実例を一通り触る」段階。実務で使えるレベルまで定着させるには、提出物テンプレ・採点ルーブリック・期待ログ付きの 演習を繰り返す 必要があります。

次に手を動かす: バイブコーディング実践編は /lms/free/vibe-practice で 4 週間限定無料公開中。各レッスンに「やってみる」演習が必ず付いており、提出すると採点されます。

関連ガイド: