第 6 章
実践:実際の開発で使う
これまでの章で学んだ知識を活かし、実際の開発シナリオを通じて Claude Code をフル活用します。 「新機能を追加する」「バグを直す」「業務を自動化する」など、現場ですぐに使えるノウハウを紹介します。
6.1 実践の流れ
効果的に Claude Code を使うための基本的な進め方を押さえましょう。 毎回のセッションで以下の流れを意識すると、迷わずに作業を進められます。
-
1
プロジェクトルートで
claudeを起動するCLAUDE.md があればプロジェクトの文脈を自動で読み込む
-
2
タスクを明確に伝える
「何を」「どこに」「どんな制約で」を具体的に指示する
-
3
変更内容を確認してから承認する
ファイル変更・コマンド実行の前に内容を必ず確認する
-
4
動作確認・テストを実行する
「npm test を実行して」と依頼してテストが通ることを確認する
-
5
新しいタスクに移る前に
/clear前の文脈を引きずらないようにリセットする
6.2 シナリオ①:新しいプロジェクトを始める
Todo アプリの API サーバーをゼロから作る
# ① まず方針を確認する
> Node.js + Express + SQLite で Todo アプリの REST API を作りたい。
どんな構成で作るか方針を説明して
# ② プロジェクトの雛形を生成
> その方針で進めて。まずディレクトリ構成と
package.json を作って
# ③ 段階的に実装
> 次に DB のスキーマと接続設定を作って
> Todo の CRUD エンドポイントを実装して
> 各エンドポイントのテストを書いて
# ④ 動作確認
> npm test を実行して、全テストが通ることを確認して
# ⑤ ドキュメント整備
> README.md と CLAUDE.md を生成して
6.3 シナリオ②:バグを修正する
本番環境のエラーを調査して修正する
# ① エラーログをそのまま貼り付ける
> 本番でこのエラーが出ています。原因を調べて修正して:
UnhandledPromiseRejection: Cannot read properties of null
at getUserProfile (src/services/userService.js:34)
at async router.get (/api/profile) (src/routes/user.js:12)
# ② 関連ファイルを調べてもらう
> src/services/userService.js と src/routes/user.js を読んで、
null が渡るケースを全て洗い出して
# ③ 修正と影響範囲の確認
> 修正して。他のファイルへの影響も確認して
# ④ テストを追加してリグレッションを防ぐ
> このバグに対するテストケースを追加して
# ⑤ コミット
> 変更を git commit して。メッセージは英語で
6.4 シナリオ③:機能を追加する
既存の API にページネーション機能を追加する
# ① 現状のコードを把握してもらう
> src/routes/posts.js の GET /posts エンドポイントを読んで
現状の実装を説明して
# ② 要件を伝えて実装方針を確認
> このエンドポイントに page・limit のクエリパラメータで
ページネーションを追加したい。
デフォルトは page=1, limit=20。どう実装する?
# ③ 実装
> その方針で実装して。バリデーションも忘れずに
# ④ レスポンス形式も合わせる
> レスポンスに totalCount と totalPages も含めて
# ⑤ テストと API ドキュメントの更新
> テストを追加して、docs/api.md のエンドポイント仕様も更新して
6.5 シナリオ④:コードレビューをする
Pull Request のコードをレビューする
# ① diff を見せてレビューを依頼
> git diff main...feature/user-auth を確認して、
以下の観点でコードレビューして:
- セキュリティ上の問題
- パフォーマンスの問題
- コーディング規約の違反
- テストの網羅性
# ② 問題点の修正を依頼
> 指摘した問題を全て修正して
# ③ セキュリティの詳細チェック
> 認証・認可の実装に漏れや脆弱性がないか詳しく確認して
# GitHub MCP がある場合
> GitHub の PR #45 をレビューして、
修正依頼コメントを各行に直接書いて
6.6 シナリオ⑤:業務を自動化する
定型業務をスクリプトで自動化する
# ① CSV データの集計・レポート自動生成
> data/sales_2025.csv を読んで月別・商品別の売上を集計して
reports/monthly_report.md にまとめて
# ② ファイルの一括整形
> logs/ フォルダの全 .log ファイルから ERROR レベルのログだけ
抽出して errors_summary.txt に出力するスクリプトを作って
# ③ 定期実行スクリプトの作成
> 毎日深夜に DB をバックアップして S3 にアップロードする
シェルスクリプトを書いて。cron 設定方法も教えて
# ④ API からデータ取得して通知
> GitHub API で今週クローズされた Issue 一覧を取得して
Slack の #weekly-report チャンネルに投稿するスクリプトを作って
6.7 並列エージェントを使う
CLI 版の強みである複数エージェントの並列実行を活用すると、 大規模なタスクを効率よく処理できます。
claude を起動することで複数の作業を同時進行できます。
互いに影響しない独立したタスクを並行して進めるのに有効です。
並列化が有効なケース
複数モジュールの同時開発
フロントエンドとバックエンドを別ターミナルで同時実装
テスト・コードの並行作業
一方で実装、もう一方でテストを同時に書く
大量ファイルの一括処理
100 個のファイルを 10 個ずつ 10 並列で処理
調査と実装の並行
一方で仕様を調査、もう一方で先行実装を進める
# ターミナル 1:フロントエンドの実装
cd my-project
claude
> src/pages/Dashboard.tsx にグラフ表示コンポーネントを追加して
# ターミナル 2(別ウィンドウ):バックエンドの実装
cd my-project
claude
> /api/dashboard/stats エンドポイントを実装して
# ターミナル 3(別ウィンドウ):テストの作成
cd my-project
claude
> Dashboard コンポーネントと stats API の両方のテストを書いて
6.8 エージェントチーム ⚗ 実験的機能
エージェントチームは、複数の Claude Code インスタンスが連携して動作する仕組みです。 1 つのセッションがチームリーダーとなり、作業を調整・分担します。 各チームメンバーは独自のコンテキストウィンドウを持ち、互いに直接メッセージを送り合えます。
settings.json または環境変数で明示的に有効化する必要があります。
セッション再開・タスク調整・シャットダウン動作に既知の制限があります。
並列セッションとの違い
| 手動の並列セッション(6.7) | エージェントチーム | |
|---|---|---|
| 通信 | なし(独立して動作) | チームメンバーが互いに直接メッセージ送信 |
| 調整 | 人間が手動で管理 | 共有タスクリストで自己調整 |
| 最適な用途 | 独立した作業の並列化 | 議論・検証・相互レビューが必要な複雑な作業 |
| トークンコスト | 低 | 高(メンバー数に比例) |
有効化の方法
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
claude --version でバージョンを確認してください。アーキテクチャ
チームリーダー
チームを作成・調整し、作業を割り当てるメインセッション
チームメンバー
独自のコンテキストウィンドウを持つ独立した Claude Code インスタンス
共有タスクリスト
チーム全体の作業項目。メンバーが自己申告で担当を取得する
メールボックス
エージェント間の直接メッセージングシステム
使い方
有効化後、リーダーに自然言語でチーム構成とタスクを伝えるだけです。
# 3つの視点で並列調査させる例
> PR #142 をレビューするエージェントチームを作って。
・セキュリティの観点で確認するレビュアー
・パフォーマンスを確認するレビュアー
・テストカバレッジを確認するレビュアー
の 3 人を用意して、それぞれの調査結果をまとめて
# 競合する仮説でデバッグする例
> このバグについて 3 つの異なる仮説でチームを組んで。
互いの仮説を反証し合いながら、最も可能性の高い原因を特定して
チームメンバーの操作
In-process モード
Shift+↓ でメンバーを切り替え、直接メッセージを送れる。追加設定不要
分割ペインモード
各メンバーが独自ペインで並列表示。tmux または iTerm2 が必要
プラン承認
「実装前にプランを立てて」と指示すると、変更前にリーダーの承認が必要になる
クリーンアップ
作業完了後は「チームをクリーンアップして」でリソースを解放する
主な制限事項
- In-process モードでは
/resumeでセッションを再開できない - 1 セッションにつき 1 チームのみ管理可能
- チームメンバーが独自にチームを生成することはできない(ネスト不可)
- 分割ペインモードは VS Code 統合ターミナル・Windows Terminal では未対応
- 単一セッションより大幅にトークンを消費する
6.9 チームでの使い方
Claude Code をチームで効果的に活用するためのベストプラクティスをまとめます。
リポジトリに含めるべきもの
my-project/
├── CLAUDE.md # ← プロジェクト共通ルール(必ずコミット)
├── .claude/
│ └── settings.json # ← allowedTools などの設定(コミット推奨)
└── ...
# .gitignore に追加すべきもの
.claude/credentials.json # 個人の認証情報は含めない
チームの CLAUDE.md に書くべき内容
- レビュー基準:PR に含めるべきもの(テスト・型定義・ドキュメント更新)
- ブランチ命名規則:
feature/xxx・fix/xxxなど - コミットメッセージ規約:Conventional Commits 形式など
- 環境構築手順:初回セットアップに必要なコマンド
- 担当領域:触ってよいファイル・触ってはいけないファイル
6.10 総まとめ
全6章で学んだことを振り返りましょう。
| 章 | 学んだこと |
|---|---|
| 第1章 | Claude Code の概要・3 種類のアクセス方法・できること |
| 第2章 | Desktop アプリと CLI のセットアップ・ログイン方法 |
| 第3章 | 対話モードの基本・コード生成・説明・修正・指示のコツ |
| 第4章 | ファイル・コマンド・検索ツール・MCP による外部連携 |
| 第5章 | CLAUDE.md の書き方・settings.json・モデルの使い分け |
| 第6章 | 実践シナリオ・並列エージェント・チームでの活用 |
次のアクション
- 自分のプロジェクトに CLAUDE.md を作る
- よく使うコマンドを allowedTools に追加する
- MCP でよく使うサービスと連携する
- 並列エージェントで大きなタスクを効率化する