Claude Code 実践ワークフロー集

Claude Code を「何かわからないことがあったときに質問する」ツールとして使っていませんか？実は Claude Code は、作業フロー全体に組み込むことで本来の力を発揮します。

この記事では、開発者から非エンジニアまで幅広く使える実践的なワークフローを紹介します。それぞれ「いつ使うか」「具体的な手順」「コピペ可能なコマンド例」を統一フォーマットでまとめています。

ワークフローの考え方

Claude Code を使いこなすポイントは2つあります。

単発の質問より「フロー全体への組み込み」

多くの人は「このバグを直して」「このコードを説明して」という単発の質問から始めます。これでも十分便利ですが、Claude Code の真価は作業の流れ全体に組み込んだときに発揮されます。

たとえばコードレビューのワークフローを考えてみましょう。

単発の使い方（効率が低い）:

# 毎回手動でファイルを指定して質問する
> src/components/Button.tsx を確認してください
> では src/hooks/useAuth.ts も確認してください

フロー全体への組み込み（効率が高い）:

# PR の差分全体を一度にレビューさせる
git diff main | claude -p "この変更をレビューして、問題点をリスト形式でまとめて"

CLAUDE.md で文脈を設定する

Claude Code はプロジェクトの文脈を知らない状態で起動します。毎回「このプロジェクトは TypeScript で書かれていて、テストは Vitest を使っていて...」と説明するのは非効率です。

CLAUDE.md をプロジェクトルートに置くと、Claude Code が起動するたびに自動的に読み込まれます。一度書いておけば、以後の会話で毎回説明する必要がなくなります。

# プロジェクトルートに CLAUDE.md を作成
touch CLAUDE.md

CLAUDE.md に書くべき内容：

# プロジェクト概要
このプロジェクトは〇〇のための Web アプリです。

## 技術スタック
- 言語: TypeScript
- フレームワーク: Next.js 15 (App Router)
- テスト: Vitest + Testing Library
- パッケージマネージャー: pnpm

## コーディング規約
- コンポーネントは関数型で書く
- 型は明示的に定義する（any を避ける）
- テストファイルは __tests__ ディレクトリに置く

## よく使うコマンド
- `pnpm dev` — 開発サーバー
- `pnpm test` — テスト実行
- `pnpm build` — 本番ビルド

Tips: CLAUDE.md は育てるものです。作業しながら「毎回同じ説明をしているな」と気づいたら、その内容を CLAUDE.md に追記していきましょう。半月ほどでかなり賢い指示書になります。

対話モードとワンショットモードの使い分け

モード	コマンド	向いている場面
対話モード	`claude`	結果を確認しながら進めたい、複数ステップの作業
ワンショットモード	`claude -p "..."`	1回で完結するタスク、スクリプトへの組み込み
パイプモード	`コマンド \| claude -p "..."`	別コマンドの出力を解析・加工したい

コードレビュー

難易度: ★☆☆（初級）

いつ使うか

PR を出す前に自分でセルフレビューしたいとき
レビュアーが捕まらないが早めに品質確認したいとき
コードの問題点を網羅的に洗い出したいとき

手順

パターン1: git diff を使ったワンショットレビュー（推奨）

# main ブランチとの差分を全部レビューさせる
git diff main | claude -p "このコードの変更をレビューして。バグの可能性、パフォーマンス上の懸念、可読性の問題を指摘してリスト形式でまとめて"

# ステージング済みの変更だけをレビューする
git diff --staged | claude -p "このコードの変更をレビューして、問題点を箇条書きで教えて"

パターン2: 特定ファイルをレビューする

# 対話モードで特定ファイルを詳しくレビュー
claude
> @src/lib/auth.ts このファイルをレビューして。特にセキュリティ上の問題がないか確認して

パターン3: PR のコミット履歴を元にレビューコメントを生成する

# 最新コミットのメッセージを含めてレビューさせる
git log --oneline -10 | claude -p "これらのコミットに含まれる変更について、レビュアーが確認すべきポイントを教えて"

Tips

つまづきポイント: git diff main を実行したときに差分が大量になってしまう場合は、ファイルを絞り込む方法が有効です。git diff main -- src/components/ のようにディレクトリを絞るか、対話モードで重要なファイルを順番にレビューしてもらいましょう。

コミットメッセージを自動生成するワンショット：

# git diff の内容からコミットメッセージを生成する
git diff --staged | claude -p "この変更の内容を Conventional Commits 形式のコミットメッセージにまとめて（1行で）"

バグ修正

難易度: ★☆☆（初級）

いつ使うか

エラーメッセージの意味がわからないとき
スタックトレースをどう読めばいいかわからないとき
原因は特定できたが修正方法がわからないとき

手順

パターン1: エラーログをそのまま貼り付ける（最も手軽）

# エラーログをパイプで渡す
cat error.log | claude -p "このエラーの原因を特定して、修正方法を教えて"

# コマンドの実行結果とエラーを一緒に渡す
pnpm build 2>&1 | claude -p "このビルドエラーを解析して、どのファイルの何行目を修正すればいいか教えて"

パターン2: 対話モードでデバッグを進める

claude
> TypeError: Cannot read properties of undefined (reading 'map') というエラーが出ています
> スタックトレースはこちらです: [スタックトレースを貼り付ける]
> @src/components/UserList.tsx このファイルを確認して原因を特定して

パターン3: テストを使ってバグを再現・修正する

claude
> pnpm test を実行したら以下のテストが失敗しました
> [テスト失敗のログを貼り付ける]
> テストが通るように修正してください

Tips

つまづきポイント: 「エラーが出ています」だけでは Claude に情報が少なすぎます。エラーメッセージ全文とどの操作をしたときに発生するかをセットで伝えると、格段に精度が上がります。「ログインボタンをクリックしたときに以下のエラーが出ます」という形式が理想的です。

再現手順を明示した指示の例：

> 以下の状況でエラーが発生します：
> 1. http://localhost:3000/dashboard にアクセス
> 2. ユーザー名とパスワードを入力してログインボタンをクリック
> 3. 以下のエラーが発生する：
>    [エラーメッセージを貼り付け]
>
> @src/app/api/auth/route.ts と @src/lib/session.ts を確認して、原因を特定して修正してください

リファクタリング

難易度: ★★☆（中級）

いつ使うか

コードが複雑になってきて整理したいとき
関数やコンポーネントが大きくなりすぎたとき
技術的負債を段階的に解消したいとき
大規模リファクタリングを安全に進めたいとき

手順

パターン1: 単一ファイルの整理（小規模）

claude
> @src/utils/data-transform.ts このファイルをリファクタリングしてください
> 目標：
> - 1つの関数が1つのことだけをやるように分割する
> - 変数名をわかりやすくする
> - 重複するロジックをまとめる
> テストが通ることを確認しながら進めてください

パターン2: 大規模リファクタリングの分割戦略

大規模なリファクタリングを一度にやろうとすると、予期せぬ問題が多発します。段階的に進めることが重要です。

まずリファクタリング計画を立てさせます：

claude
> src/services/ ディレクトリ全体のコードを整理したいと思っています
> まずは現状の問題点を分析して、どの順番でリファクタリングを進めるべきか計画を立ててください
> 各ステップは独立してマージできるサイズに分割してください

計画が決まったら、1ステップずつ進めます：

claude
> 先ほどの計画のステップ1（UserService の分割）を実装してください
> 変更後はテストを実行して、既存のテストが全て通ることを確認してください

パターン3: パフォーマンス改善

# 特定の処理が遅い場合
cat src/lib/heavy-computation.ts | claude -p "このコードのパフォーマンス上のボトルネックを特定して、改善案を示してください"

Tips

つまづきポイント: リファクタリング中に「これも直したい」「あれも気になる」と範囲を広げてしまうと、収拾がつかなくなります。「今回のスコープはこのファイルだけ」と明示的に伝えることが重要です。Claude も同様の問題を起こすことがあるので、「このファイルだけを変更してください。他のファイルには触れないでください」と指示しましょう。

リファクタリング前後の確認フロー：

# 1. リファクタリング前にテストを確認
pnpm test

# 2. リファクタリングを実行
claude
> @src/components/Form.tsx をリファクタリングしてください

# 3. リファクタリング後にテストを再実行して確認
pnpm test

テスト生成

難易度: ★★☆（中級）

いつ使うか

テストを書くのが後回しになっているコードがあるとき
新機能を実装したあとにテストを追加したいとき
テストカバレッジを上げたいとき
どんなテストを書けばいいかわからないとき

手順

パターン1: 既存の関数に対するユニットテストを生成する

claude
> @src/lib/format.ts このファイルの全関数に対するユニットテストを生成してください
> - テストフレームワーク: Vitest
> - テストファイルの保存先: src/lib/__tests__/format.test.ts
> - エッジケース（空文字列、null、undefined、境界値）も含めてください

パターン2: React コンポーネントのテストを生成する

claude
> @src/components/SearchInput.tsx このコンポーネントのテストを生成してください
> - Testing Library を使ってください
> - ユーザー操作（入力、クリア）のテストを含めてください
> - アクセシビリティの確認（aria 属性など）もテストしてください

パターン3: API エンドポイントのテストを生成する

claude
> @src/app/api/users/route.ts この API エンドポイントのテストを生成してください
> - 正常系（200 レスポンス）と異常系（400、401、500）のケースを含めてください
> - モックが必要なデータベース呼び出しは適切にモックしてください

パターン4: テストカバレッジを確認して足りない部分を補う

# カバレッジレポートを生成
pnpm test --coverage 2>&1 | claude -p "このカバレッジレポートを見て、テストが不足している重要な部分を特定して、追加すべきテストケースを教えて"

Tips

つまづきポイント: 生成されたテストをそのまま使うと、「テストのためのテスト」（実際の動作を確認していないテスト）になることがあります。生成後は必ずテストの内容を確認し、「このテストは何を確認しているか」を理解してから使いましょう。Claude に「このテストが何を確認しているか説明して」と聞くと理解が深まります。

テスト生成後の確認手順：

# 生成したテストを実行して通ることを確認
pnpm test src/lib/__tests__/format.test.ts

# テストの説明を求める
claude
> 生成したテストのうち、一番複雑なテストケースを説明してください

ドキュメント生成

難易度: ★☆☆（初級）

いつ使うか

コードの説明が不足していてチームメンバーが理解しにくいとき
API を公開するために仕様書を作りたいとき
README が古くなっているとき
JSDoc コメントを一括で追加したいとき

手順

パターン1: README を自動生成する

claude -p "このプロジェクトの README.md を生成してください。以下を含めてください：概要、インストール方法、使い方、設定オプション、ライセンス"

または既存の README を更新する場合：

claude
> @README.md を読んで、現在の状態を確認してください
> 次に、実際のプロジェクト構成（ディレクトリ構造、package.json）を確認して、README.md の内容が古くなっている箇所を特定してください
> 最新の状態に更新してください

パターン2: 関数・クラスに JSDoc コメントを追加する

claude
> @src/lib/api-client.ts このファイルの全ての関数・クラスに JSDoc コメントを追加してください
> - パラメータの型と説明
> - 戻り値の型と説明
> - 使用例（@example）
> を含めてください。日本語で書いてください

パターン3: API ドキュメントを生成する

claude
> src/app/api/ ディレクトリを調べて、全 API エンドポイントの一覧とその仕様を Markdown 形式でまとめてください
> エンドポイントごとに：メソッド、パス、リクエストボディ、レスポンス形式、認証の要否を含めてください

パターン4: 変更履歴（CHANGELOG）を生成する

# git log を使って変更履歴を生成する
git log --oneline v1.0.0..HEAD | claude -p "このコミット一覧から CHANGELOG を生成してください。バグ修正、新機能、破壊的変更を分類して Markdown 形式でまとめてください"

Tips

つまづきポイント: ドキュメントは生成後に必ず確認が必要です。Claude はコードの意図を推測してドキュメントを書くため、実際の動作と異なる説明が含まれることがあります。特に「副作用」や「エラーハンドリング」の説明は要確認です。

ワンショットで素早くドキュメントを生成する場合：

cat src/utils/validation.ts | claude -p "このコードのドキュメントをコードに直接埋め込む形式で書いて。JSDoc 形式でコメントを付けたコード全体を出力して"

新規プロジェクトの立ち上げ

難易度: ★★☆（中級）

いつ使うか

新しいプロジェクトをゼロから始めるとき
既存のプロジェクトに新しい機能モジュールを追加するとき
ボイラープレートのセットアップを効率化したいとき

手順

フェーズ1: CLAUDE.md の設計

新規プロジェクトでまず最初にすべきことは CLAUDE.md の作成です。プロジェクトの全体像を Claude に伝えることで、以後の作業精度が大幅に上がります。

mkdir my-new-project && cd my-new-project
claude
> 新しい Web アプリを作ります。以下の要件で CLAUDE.md を作成してください：
> - 概要: 社内向けの勤怠管理システム
> - 技術スタック: Next.js 15, TypeScript, Prisma, PostgreSQL, Tailwind CSS
> - 開発規約: Conventional Commits, テストは Vitest
> - デプロイ先: Vercel

フェーズ2: スキャフォールディング（雛形の生成）

claude
> 先ほど作成した CLAUDE.md の要件に基づいて、プロジェクトの雛形を作成してください
> 以下をセットアップしてください：
> 1. Next.js プロジェクトの初期化
> 2. TypeScript と ESLint の設定
> 3. Tailwind CSS の設定
> 4. Prisma の設定と初期スキーマ
> 5. Vitest のセットアップ
> 6. 基本的なディレクトリ構成の作成

フェーズ3: 機能の実装

claude
> ユーザー認証機能を実装してください
> - メール/パスワードでのサインアップ・ログイン
> - JWT を使ったセッション管理
> - ログイン状態に応じたリダイレクト
> 既存の技術スタック（Next.js App Router, Prisma）に合わせて実装してください

Tips

つまづきポイント: 一度に全機能を実装しようとすると、Claude のコンテキスト（覚えられる情報量）が足りなくなります。機能を小さな単位に分割して、1機能ずつ実装するのが安全です。「ユーザー認証まで実装したら、次の会話セッションで商品管理機能を追加する」という進め方を心がけましょう。

大きなプロジェクトでのコンテキスト管理：

# セッションが長くなってきたらコンテキストを圧縮する
> /compact

# 新しいセッションで作業を再開するときは、まず現状把握から始める
claude
> @CLAUDE.md を読んで、このプロジェクトの構成を把握してください
> 次に src/ ディレクトリの構成を確認して、現在の実装状況を教えてください

非エンジニア向けワークフロー

プログラミングを知らなくても、Claude Code で自動化できる日常業務はたくさんあります。ここでは特に実用度の高いワークフローを3つ紹介します。

ファイル整理・一括リネーム

難易度: ★☆☆（初級）

いつ使うか: フォルダが散らかっているとき、写真や資料のファイル名をルールに沿って整理したいとき

claude
> デスクトップの「2025年撮影」フォルダの中にある jpg ファイルを
> 「YYYYMMDD_連番.jpg」の形式（例: 20250615_001.jpg）でリネームしてください
> ファイルの作成日時を日付として使ってください
> 実行前にどんな変更をするか一覧を見せてください

claude
> 「プロジェクト資料」フォルダの中のファイルを整理してください
> - PDF ファイル → 「PDF」サブフォルダに移動
> - Excel/CSV ファイル → 「データ」サブフォルダに移動
> - Word ファイル → 「文書」サブフォルダに移動
> - 画像ファイル（jpg/png） → 「画像」サブフォルダに移動

データ変換・集計レポート

難易度: ★☆☆（初級）

いつ使うか: CSV の集計、複数ファイルのデータ統合、Excel では難しいデータ加工をしたいとき

# CSV ファイルを集計する
claude
> デスクトップの「売上データ2025.csv」を開いて、以下の集計を行ってください：
> 1. 商品カテゴリ別の月次売上合計
> 2. 売上上位10商品のランキング
> 3. 前月比（対先月の売上変化率）
> 結果を「売上集計レポート.csv」として保存してください

# 複数の CSV を1つにまとめる
claude
> 「月次データ」フォルダの中にある CSV ファイルを全部読み込んで
> 1つのファイルにまとめてください
> 各行にどの月のデータかわかるように「月」列を追加してください

つまづきポイント: 「デスクトップの〇〇ファイル」と指示するとき、Claude Code は現在のディレクトリを基準にファイルを探します。Claude Code を起動したディレクトリと、対象ファイルの場所が合っているか確認してください。cd ~/Desktop でデスクトップに移動してから Claude Code を起動するのが確実です。

テキスト変換・翻訳・要約

難易度: ★☆☆（初級）

いつ使うか: 大量のテキストファイルを一括処理したいとき、英語の資料を読みたいとき

# フォルダ内の全テキストファイルを要約する
claude
> 「会議メモ」フォルダの中にある .txt ファイルを全部読んで
> それぞれ3行ずつ要点を抜き出し、「会議サマリー.md」にまとめてください
> ファイル名と日付順に並べてください

# 英語の PDF を日本語に翻訳する
claude
> デスクトップにある「report_en.pdf」を日本語に翻訳してください
> 翻訳結果を「report_ja.txt」として保存してください
> 専門用語はビジネス文書で使われる一般的な日本語訳を使ってください

# テキストファイルを特定のフォーマットに変換する
claude
> 「顧客リスト.txt」（名前とメールアドレスがタブ区切りで並んでいます）を
> 「顧客リスト.csv」（カンマ区切り、ヘッダー行あり）に変換してください

ワンショットモードでの定期タスク自動化

定型作業はワンショットモード（-p）とシェルスクリプトを組み合わせて自動化できます：

#!/bin/bash
# 毎朝の日次レポート生成スクリプト例
# （このファイルを cron 等で毎朝実行する）

claude -p "昨日の売上データ（$(date -d yesterday +%Y%m%d)_sales.csv）を集計して、日次レポートを daily_report_$(date +%Y%m%d).txt に保存してください"

Tips: claude -p に渡す指示文は、シングルクォートで囲むと $ などの特殊文字が展開されません。変数を使いたい場合はダブルクォートを使いましょう。

次のステップ

各ワークフローを試してみたら、さらに効率を高めるための機能も探ってみてください。

エディタと組み合わせて使いたい方:

IDE 統合 — VS Code や JetBrains と Claude Code を連携させる方法。エディタを離れずに AI の力を活用する

ターミナル操作の基礎から学びたい方:

非エンジニア向け Claude Code ガイド — ターミナルの基礎からわかりやすく解説

Claude Code のインストールがまだの方:

Claude Code をはじめよう — インストールから最初のコマンド実行まで

料金・プランを確認したい方:

Claude の料金プラン比較 — Claude Code が使えるプランと利用量の目安