ワークフロー

効率的な Claude Code 開発ワークフローでチームの生産性を向上

API キーが必要ですか？ 登録する →·エンドポイントと Base URL →

このガイドでは、Claude Code を日常の開発ワークフローに統合する方法を説明します。個人の効率からチームコラボレーションまで、効率的な AI 支援開発プロセスを確立します。

計画-実行ワークフロー¶

最も効果的な Claude Code の使用パターンは計画してから実行することです。AI に直接コードを書かせることは避けましょう。

基本フロー¶

1. 要件分析 → 2. 計画作成 → 3. 計画確認 → 4. 段階的実行 → 5. 結果検証

実践ステップ¶

ステップ1：Claude に要件を理解させる

> @src/services/ ディレクトリのコードを読んで、既存のアーキテクチャを理解して。
> コードは書かないで、分析だけして。

ステップ2：実装計画を作成

> 既存コードの理解に基づいて、「ユーザー権限管理」の詳細な実装計画を作成して。
> 含める内容：ファイル変更、新規ファイル、依存関係、リスクポイント。

ステップ3：計画の確認と調整

Claude の計画をレビューし、修正を提案：

> 計画のステップ3で、メモリキャッシュではなく Redis キャッシュを使いたい。計画を調整して。

ステップ4：段階的に実行

> 計画のステップ1を実行：権限モデルを作成。

各ステップ完了後、結果を確認してから次に進みます。

フィーチャーブランチワークフロー¶

Git ブランチのベストプラクティス¶

# 1. フィーチャーブランチを作成
git checkout -b feature/user-permissions

# 2. プロジェクトに移動して Claude Code を起動
cd your-project && claude

# 3. 開発中に頻繁にコミット
> この変更をコミットして  # 最初のコミット
# 開発を続ける...
> この変更をコミットして  # 2回目のコミット

# 4. 機能完了、PR を作成
> 現在のブランチの PR 説明を作成、すべてのコミットの変更をまとめて

コミット頻度のヒント¶

• 小さなコミット：独立した機能ポイントごとにコミット

• コミットメッセージ：diff から適切なメッセージを Claude に作らせる（カスタムの /commit コマンドがあるプロジェクトではそれも使える）

• 大きなコミットを避ける：多くの変更を貯めてからコミットしない

コードレビューワークフロー¶

セルフレビュー¶

PR を提出する前に、Claude にレビューさせる：

> /review
> 重点：セキュリティ、パフォーマンス、コードスタイル

他人のコードをレビュー¶

# PR の変更を取得
gh pr diff 123 | claude "この PR をレビューして、次の点に注目：
1. ロジックの正確性
2. エッジケースの処理
3. エラーハンドリング
4. コードの保守性"

多段階レビュープロセス¶

複雑な PR には構造化されたレビューを使用：

> フェーズ1：アーキテクチャ設計が妥当かチェック
> フェーズ2：実装が設計に沿っているかチェック
> フェーズ3：テストカバレッジが十分かチェック
> フェーズ4：ドキュメントが完全かチェック

テスト駆動ワークフロー¶

TDD と Claude Code¶

1. テストを書く → 2. テスト実行（失敗）→ 3. コードを書く → 4. テスト実行（成功）→ 5. リファクタリング

実践ステップ¶

ステップ1：テストを定義

> ユーザー登録のテストケースを書いて、カバーする内容：
> - 正常な登録
> - 無効なメール形式
> - 弱いパスワード
> - ユーザーが既に存在
> まずテストを書いて、機能は実装しないで。

ステップ2：テストの失敗を確認

npm test  # 期待：テストが失敗

ステップ3：機能を実装

> すべてのテストをパスするコードを実装して。

ステップ4：確認とリファクタリング

npm test  # 期待：テストがパス

> テストがパスした。テストを壊さずにコードをリファクタリングして可読性を向上させて。

デバッグワークフロー¶

構造化デバッグ¶

1. 問題を再現 → 2. 情報を収集 → 3. 原因を分析 → 4. 仮説を検証 → 5. 問題を修正

実践ステップ¶

ステップ1：問題を説明

> 問題：ログイン後、「注文履歴」をクリックすると空白ページが表示される
> 期待：ユーザーの注文リストを表示
> 再現手順：ログイン → 「注文履歴」をクリック

ステップ2：情報を収集

> これらのファイルを分析して、可能性のある問題を見つけて：
> @src/pages/MyOrders.tsx
> @src/services/OrderService.ts
> @src/api/orders.ts

ステップ3：ログを分析

# エラーログを収集
cat app.log | claude "これらのログを分析して、注文ページに関連するエラーを見つけて"

ステップ4：修正と検証

> 分析に基づいて、OrderService の問題を修正して
> 修正後、テストして確認する

サブエージェント連携ワークフロー¶

並列処理¶

サブエージェントを活用して並列タスク処理：

> 同時にこれらのタスクを実行：
> 1. Explore エージェントでプロジェクト構造を分析
> 2. Plan エージェントで新機能のアプローチを設計

専門的な役割分担¶

異なるサブエージェントには異なる強みがあります：

IDE 統合ワークフロー¶

VS Code 統合¶

1. Claude Code VS Code 拡張機能をインストール

2. Cmd+Esc / Ctrl+Esc で素早く切り替え

3. エディタでコードを選択してから Claude を呼び出す

ターミナル + IDE 連携¶

ターミナル (Claude Code)          IDE (VS Code)
         ↓                            ↓
    分析、計画                  手動調整、読み取り
         ↓                            ↓
   コードを生成  ←──────────→   差分を表示、テスト
         ↓                            ↓
   コミット                      開発を続ける

チームコラボレーションワークフロー¶

CLAUDE.md の標準化¶

チーム全体で CLAUDE.md 設定を共有：

# チーム開発規約

## コードスタイル

- ESLint 設定：.eslintrc.js
- Prettier 設定：.prettierrc

## Git 規約

- ブランチ命名：feature/xxx, fix/xxx, hotfix/xxx
- コミット形式：type(scope): description

## テスト要件

- ユニットテストカバレッジ > 80%
- E2E テストでコアフローをカバー

PR テンプレート¶

Claude に統一された PR テンプレートを使用させる：

> このテンプレートで PR 説明を作成：
> ## 変更内容
> ## テスト計画
> ## スクリーンショット（UI 変更がある場合）
> ## チェックリスト

ワークフローチェックリスト¶

新しいタスクを開始する前¶

• [ ] フィーチャーブランチを作成

• [ ] /clear でコンテキストをクリア

• [ ] まず Claude に既存コードを理解させる

• [ ] 実装計画を作成

開発中¶

• [ ] 段階的に実行、各ステップを確認

• [ ] 小さなコミット、こまめに Claude にコミットを頼む

• [ ] /context でコンテキストを監視

• [ ] 必要に応じて /compact を使用

提出前¶

• [ ] /review でセルフレビュー

• [ ] すべてのテストを実行

• [ ] lint エラーをチェック

• [ ] PR 説明を生成

ワークフローで最もよく使うスイッチ¶

2026-10-15 時点の Claude Code 公式ドキュメントによると次のとおりです。

巻き戻しの制約が 2 つあります。公式ドキュメントによると、ファイルのスナップショットはセッションごとに直近 100 個のチェックポイント分が保持され、既定ではセッションが最後に保存されてから約 30 日後に削除されます。その後は巻き戻しが No files were restored で失敗することがあります。長く残したい場合は cleanupPeriodDays を調整します。

QCode でこれらのワークフローを動かすときの注意点¶

• 同時実行：個人プランとクォータパックは API キーあたり同時 5 です（アルティメットは 10。FAQ参照）。複数の Claude Code を同時に動かしたり、多数のサブエージェントを並列にすると、先に制限（多くは 429）に当たることがあります。
• 長いセッション：計画してから実行する流れは長くなりがちで、コンテキストの上限に近づくと E015 / 429 が出ます。まず /compact、だめならセッションを再起動します。コンテキスト管理参照。
• モデルの使い分け：計画とレビューには強いモデル、一括の編集には claude-sonnet-5 を使い、/model で切り替えます。QCode はトークン単位の課金で、モデルごとの単価は qcode.cc/models にあります。

よくあるエラーと切り分け¶

よくある質問¶

必ず計画してから実行すべきですか？¶

小さな変更は直接行ってかまいません。複数のファイルにまたがる作業や、間違えたときの代償が大きい作業では、まずプランモードで計画を出させ、確認してから実行すると、やり直しが少なくなります。

/compact はどのくらいの頻度で行えばよいですか？¶

決まった頻度はありません。ひと区切りついたとき、または /context で使用量が 70〜80% になったときに圧縮するのが、あふれてから対処するより確実です。

間違えたときはどう戻しますか？¶

コードは git と /rewind の二重で守ります。小まめにコミットし、セッション内の取り消しには /rewind を使います。重要な時点でコミットしてから Claude に続きをさせてください。

別々のタスクで複数のセッションを並行しても影響しませんか？¶

会話は互いに影響しませんが、同じキーの同時実行枠を共有します。並行タスクが多いとレート制限を受けることがあるので、上記のように同時実行を減らしてください。

次のステップ¶

• CLI テクニック でより多くのコマンドを学ぶ

• カスタムコマンド でチーム固有のコマンドを作成

• ベストプラクティス でワークフローをさらに最適化

企業版 →