【2025年12月版】Claude Code × GitHub × VS Code で構築する、個人開発のための「ちょうどいい」AI駆動開発環境
Claude Codeには、Skills、Hooks、MCP、マルチエージェント、GitHub Actions連携など、多くの機能が用意されています。しかし、すべてを一度に導入しようとすると設定が複雑になり、何が起きているのか分からなくなりがちです。 この記事では、個人開発者が「理解しながら使える」レベルに機能を絞った開発環境の構築方法を紹介します。
21 December, 2025# 【2025年版】Claude Code × GitHub × VS Code で構築する、個人開発のための「ちょうどいい」AI駆動開発環境
## はじめに
Claude Codeには、Skills、Hooks、MCP、マルチエージェント、GitHub Actions連携など、多くの機能が用意されています。しかし、すべてを一度に導入しようとすると設定が複雑になり、何が起きているのか分からなくなりがちです。
この記事では、**個人開発者が「理解しながら使える」レベルに機能を絞った開発環境**の構築方法を紹介します。
### この記事で構築する環境
- 企画から開発まで一貫したフロー: アイデア → 要件定義 → 設計 → 実装
- Issue駆動開発: GitHubのIssueを起点に開発
- TDD（テスト駆動開発）: Red → Green → Refactorのサイクル
- Slashコマンドによる開発フロー: 13個のコマンドで一連の作業を実行
- サブエージェントによるレビュー: コードレビューを専門エージェントに委譲
- 公式プラグイン: フロントエンドデザイン向上 + セキュリティ監視
### 対象読者
- Claude Code Maxプランを契約している個人開発者
- AIエージェントを使った開発に興味がある方
- 設定をシンプルに保ちながら、効率的に開発したい方
---
## なぜ「完全自動化」ではなく「コマンド駆動」なのか
Claude Codeには、Hooksを使った完全自動化や、複数のサブエージェントによる並列処理など、高度な機能があります。しかし、この記事ではあえて**ユーザーがSlashコマンドでトリガーする方式**を採用しています。
### 理由1: 開発フローを理解できる
完全自動化されたワークフローは便利ですが、「何が起きているのか」が見えにくくなります。コマンドで明示的にトリガーすることで、各ステップで何が行われているかを把握できます。
```
/requirements → 「要件を整理しているんだな」
/design → 「ここで設計を固めるのか」
/test → 「テストを先に書くフェーズだな」
/impl → 「ここで実装するのか」
```
### 理由2: AIとの対話を重視できる
Claudeの強みは「対話」です。完全自動化すると、この対話の機会が減ってしまいます。コマンド駆動なら、各ステップでClaudeの出力を確認し、必要に応じて方向修正できます。
```bash
/design アーキテクチャ
# Claudeが設計を提示
# 「Clean Architectureベースで、以下の構成を提案します...」
# 人間が確認・修正
「認証部分はNextAuth.jsを使いたいので、その前提で修正して」
```
### 理由3: 段階的に拡張できる
シンプルな構成から始めれば、必要に応じて機能を追加できます。
```
Phase 1（この記事）: CLAUDE.md + Slashコマンド + サブエージェント（1つ）
Phase 2（慣れてきたら）: Hooks追加、Skills追加
Phase 3（必要なら）: MCP連携、マルチエージェント
```
### 理由4: 追加費用がかからない
この構成は**Claude Code Maxプランのみ**で完結します。外部APIを叩くMCPサーバーや、GitHub Actionsの大量自動実行は使いません。
---
## 構成の全体像
```
┌─────────────────────────────────────────────────────────────┐
│ 開発環境の構成要素 │
├─────────────────────────────────────────────────────────────┤
│ │
│ CLAUDE.md ─────────── プロジェクトの「魂」 │
│ │ ドメイン知識、技術スタック、ルールを定義│
│ │ │
│ ▼ │
│ Slashコマンド（13個）── 開発フローの各ステップを実行 │
│ │ │
│ │ 【企画・設計フェーズ】 │
│ │ /init → /requirements → /design │
│ │ │
│ │ 【開発フェーズ】 │
│ │ /new-issue → /issue → /research → /plan │
│ │ /test ⇄ /impl（TDDサイクル） │
│ │ reviewerでレビュー → /pr → /merge │
│ │ │
│ │ 【リリースフェーズ】 │
│ │ /release │
│ │ │
│ ▼ │
│ サブエージェント（1個）── コードレビュー専門 │
│ │ コンテキストを分離して実行 │
│ │ │
│ ▼ │
│ 公式プラグイン（2個）── 品質向上 │
│ ├── frontend-design: フロントエンド自動最適化（Skill） │
│ └── security-guidance: セキュリティ監視（Hook） │
│ │
└─────────────────────────────────────────────────────────────┘
```
### なぜサブエージェントは「レビュー」なのか？
サブエージェントの最大の利点は、**メインエージェントのコンテキストを保持したまま、別の作業を分離実行できる**ことです。
#### 実装→レビュー→修正のサイクルを考える
```
【/clear + /review コマンド方式の場合】
実装中のコンテキスト
↓
/clear（コンテキスト消失）
↓
/review（git diffを読み直してレビュー）
↓
修正依頼「バリデーション関数を改善して」
↓
😰 何を実装していたか説明し直す必要がある
```
```
【サブエージェント方式の場合】
実装中のコンテキスト（保持）
↓
「reviewerでレビューして」
↓
reviewerサブエージェント（別コンテキストで実行）
↓
レビュー結果だけがメインに返る
↓
修正依頼「バリデーション関数を改善して」
↓
😊 実装のコンテキストが残っているのでスムーズに修正
```
この違いが、レビューをサブエージェント化する最大の理由です。
#### 他の候補を採用しない理由
| 候補 | 採用 | 理由 |
|------|------|------|
| reviewer | ✅ | 実装→レビュー→修正のサイクルでコンテキスト保持が活きる |
| tester | ❌ | TDDはテスト→実装の順次処理。むしろコンテキストを共有すべき |
| researcher | ❌ | 調査後は`/clear`するので分離の意味がない |
| implementer | ❌ | メインエージェントの仕事そのもの |
レビューだけがサブエージェント化のメリットを享受できるのは、「実装のコンテキストを保持しつつ、レビューを分離したい」という要件があるからです。
---
## 技術スタックに依存しない設計
この開発環境は、**CLAUDE.mdだけをカスタマイズすれば、どんな技術スタックでも使える**ように設計しています。
### 設計方針
| 要素 | 役割 | 技術スタック依存 |
|------|------|------------------|
| CLAUDE.md | 「どうやるか」を定義 | ✅ プロジェクトごとにカスタマイズ |
| Slashコマンド | 「何をするか」を定義 | ❌ 汎用的、流用可能 |
| サブエージェント | レビュー観点を定義 | ❌ 汎用的、流用可能 |
### なぜこの設計か
```
【テンプレート複製方式】 ❌
├── templates/
│ ├── typescript-node/
│ │ ├── CLAUDE.md
│ │ └── .claude/commands/*.md ← 全部複製
│ ├── python-fastapi/
│ │ ├── CLAUDE.md
│ │ └── .claude/commands/*.md ← 全部複製
│ └── ...
問題: コマンドを改善したら全テンプレートに反映が必要
```
```
【CLAUDE.md カスタマイズ方式】 ✅
├── CLAUDE.md ← プロジェクト固有
└── .claude/commands/ ← 汎用的、どのプロジェクトでも同じ
利点: コマンドは1セット、CLAUDE.mdだけ書き換え
```
### Slashコマンドの汎用化
コマンド内で具体的な実行コマンド（`npm test`等）をハードコードせず、「CLAUDE.mdを参照」という形にしています。
```markdown
# ❌ 技術スタック固有（TypeScript）
### テスト実行
npm test
# ✅ 汎用的
### テスト実行
CLAUDE.mdに記載されたテストコマンドを実行
```
Claudeは賢いので、CLAUDE.mdの「コマンド」セクションを読み取り、適切なコマンドを実行します。
---
## 開発フロー
この環境では、**企画・設計フェーズ**と**開発フェーズ**を明確に分けています。
### 全体フロー
```
┌─────────────────────────────────────────────────────────────┐
│ 企画・設計フェーズ │
│ /init → /requirements → /design │
│ ↓ │
│ docs/*.md と CLAUDE.md が完成 │
│ ↓ │
│ /clear ✅ │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 開発フェーズ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 準備 │ │
│ │ /new-issue → /issue → /research → /clear ✅ │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 計画 │ │
│ │ /plan → /clear ✅ │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 実装（TDD） │ │
│ │ /test → 失敗確認 → /impl → 成功確認 → 繰り返し │ │
│ │ ⚠️ /clear しない │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ 完了 │ │
│ │ reviewerでレビュー ⇄ 修正（ループ） │ │
│ │ → /pr → /merge → /clear ✅ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ↑ 次のIssueへ ─────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ リリースフェーズ │
│ /release │
└─────────────────────────────────────────────────────────────┘
```
### 企画・設計フェーズの詳細
プロジェクト開始時に一度だけ実行します。
#### 1. プロジェクト初期化（/init）
```bash
/init
```
Claudeがヒアリングを開始します：
- どんなアプリを作りますか？
- ターゲットユーザーは？
- 主要な機能は？
- 技術的な制約は？
対話を通じてアイデアを整理します。
#### 2. 要件定義（/requirements）
```bash
/requirements
```
ヒアリング結果をもとに、要件定義ドキュメントを生成します：
- docs/requirements.md - 機能要件、非機能要件、ユースケース
#### 3. 設計（/design）
```bash
/design
```
要件をもとに、設計ドキュメントを生成します：
- docs/architecture.md - アーキテクチャ設計
- docs/database-schema.md - データベース設計
- docs/api-spec.md - API仕様
設計完了後、CLAUDE.mdが自動更新されます。
### 開発フェーズの詳細
各Issueに対して、準備→計画→実装→完了の流れを繰り返します。準備・計画・実装の流れは全体フロー図の通りです。ここでは特に重要な**完了フェーズ**について詳しく説明します。
#### 完了フェーズの詳細
完了フェーズでは、レビューと修正を**LGTMが出るまで繰り返し**ます。
1. レビュー依頼
```bash
reviewerでレビューして
```
reviewerサブエージェントが変更内容を分析し、指摘事項を返します。
2. 指摘への対応（修正が必要な場合）
指摘の内容に応じて対応方法が異なります：
| 指摘の種類 | 対応方法 | 操作 |
|------------|----------|------|
| テスト追加が必要 | TDDサイクルで対応 | /test [対象] → /impl [対象] |
| 実装の修正のみ | 直接修正 | 修正してコミット |
| 設計の見直し | 議論→修正 | Claudeと相談して対応 |
3. 再レビュー
```bash
reviewerで再レビューして
```
LGTMが出るまでこのループを繰り返します。
4. PR作成・マージ
```bash
/pr 42
/merge
/clear
```
### /clearのタイミング
| タイミング | /clear | 理由 |
|------------|--------|------|
| 企画・設計 → 開発 | ✅ する | フェーズが大きく変わる |
| 準備 → 計画 | ✅ する | 調査結果は引継ぎサマリーで渡す |
| 計画 → 実装 | ✅ する | 計画は頭に入った状態で実装開始 |
| 実装 → 完了 | ❌ しない | レビュー→修正をスムーズに行うため |
| マージ後 | ✅ する | 次のIssueに移る |
---
## 新プロジェクトでのセットアップ方法
新しいリポジトリで開発を始めるとき、どうやってこの環境を構築するか？3つの方法があります。
### 方法1: グローバル配置（推奨）
Slashコマンドとサブエージェントは汎用的なので、**ユーザーのホームディレクトリに1回だけ配置**すれば、全プロジェクトで使えます。
```
~/.claude/
├── commands/ # 全プロジェクトで共有
│ ├── init.md
│ ├── requirements.md
│ ├── design.md
│ ├── new-issue.md
│ ├── issue.md
│ ├── research.md
│ ├── plan.md
│ ├── test.md
│ ├── impl.md
│ ├── review.md
│ ├── pr.md
│ ├── merge.md
│ └── release.md
└── agents/ # 全プロジェクトで共有
└── reviewer.md
各プロジェクト/
├── CLAUDE.md # プロジェクト固有（これだけ作成）
└── docs/ # 生成されたドキュメント
```
セットアップ手順：
```bash
# セットアップスクリプトを使用（--global オプション）
/path/to/claude-code-issue-driven-tdd-template/scripts/setup.sh --global
# 完了後、任意のプロジェクトで開発開始
cd new-project
claude
/init
```
この方法なら、新プロジェクトでは**`/init`を実行するだけ**で開発を始められます。
### 方法2: セットアップスクリプト（プロジェクト単位）
プロジェクトごとに独立した環境が必要な場合（チーム開発など）は、プロジェクトの`.claude/`にインストールします。
```bash
# プロジェクトディレクトリで実行
cd your-project
/path/to/claude-code-issue-driven-tdd-template/scripts/setup.sh
# テンプレートを指定する場合
/path/to/claude-code-issue-driven-tdd-template/scripts/setup.sh nextjs-only
```
利用可能なテンプレート：
- nextjs-fastapi - Next.js + FastAPI 構成（デフォルト）
- nextjs-only - Next.js のみの構成
### 方法3: テンプレートリポジトリ
GitHubのテンプレート機能を使う方法です。
### どの方法を選ぶか
| 方法 | 向いているケース |
|------|------------------|
| グローバル配置（`--global`） | 個人開発、複数プロジェクトを頻繁に切り替える |
| プロジェクト単位 | チーム開発、プロジェクトごとにカスタマイズが必要 |
| テンプレートリポジトリ | 組織で標準化したい、GitHub中心のワークフロー |
個人開発なら「グローバル配置」がおすすめです。一度セットアップすれば、新プロジェクトでは`/init`を実行するだけで済みます。
---
## 環境構築手順
以下の手順は、**プロジェクトごとに環境を構築する方法**です。
> セットアップスクリプトを使う場合
>
> 手動で構築する代わりに、`scripts/setup.sh` を使うと簡単です：
> ```bash
> # グローバル配置（~/.claude/）
> /path/to/claude-code-issue-driven-tdd-template/scripts/setup.sh --global
>
> # プロジェクト配置（./.claude/）
> cd your-project
> /path/to/claude-code-issue-driven-tdd-template/scripts/setup.sh
> ```
> スクリプトを使う場合は、Step 1〜4 をスキップして Step 5 に進んでください。
### 前提条件
以下のツールがインストールされていることを確認してください。
```bash
# Node.js 18以上（Next.jsプロジェクトの場合）
node --version
# Python 3.12以上（FastAPIプロジェクトの場合）
python --version
# Git 2.23以上
git --version
# GitHub CLI
gh --version
gh auth login # 未認証の場合
# Claude Code CLI
claude --version
```
### Step 1: ディレクトリ構造の作成
プロジェクトルートで以下を実行します。
```bash
mkdir -p .claude/commands .claude/agents docs
```
### Step 2: CLAUDE.mdの作成
プロジェクトの「魂」となるファイルを作成します。
注意: /init → /requirements → /design のフローを実行すると、CLAUDE.mdは自動生成・更新されます。以下のテンプレートは、フローを使わずに手動で作成する場合や、生成後のカスタマイズの参考にしてください。
#### テンプレートA: Next.js + FastAPI
フロントエンドにNext.js、バックエンドにFastAPIを使用するフルスタック構成向け。
````markdown
# Project: [プロジェクト名]
## 概要
[プロジェクトの目的を1-2文で]
## ドメイン知識
### ターゲットユーザー
- [ユーザー像]
### 主要機能
- [機能1]
- [機能2]
### 重要な制約
- [制約1: 例）外部APIのレート制限]
### 用語集
- [用語1]: [説明]
- [用語2]: [説明]
## 技術スタック
### フロントエンド
- Framework: Next.js 15 (App Router)
- Language: TypeScript
- Styling: Tailwind CSS
- State: TanStack Query
- Test: Vitest, React Testing Library
### バックエンド
- Framework: FastAPI
- Language: Python 3.12
- ORM: SQLAlchemy 2.0
- DB: PostgreSQL
- Test: pytest, pytest-asyncio
### インフラ
- Container: Docker, Docker Compose
## ディレクトリ構造
```
project-root/
├── frontend/ # Next.js
│ ├── src/
│ │ ├── app/ # App Router pages
│ │ ├── components/ # Reactコンポーネント
│ │ │ ├── ui/ # 汎用UI
│ │ │ └── features/ # 機能別
│ │ ├── hooks/ # カスタムフック
│ │ ├── lib/ # ユーティリティ
│ │ ├── types/ # 型定義
│ │ └── api/ # APIクライアント
│ └── tests/ # テスト
├── backend/ # FastAPI
│ ├── app/
│ │ ├── api/v1/ # APIエンドポイント
│ │ ├── core/ # 設定、セキュリティ
│ │ ├── models/ # SQLAlchemyモデル
│ │ ├── schemas/ # Pydanticスキーマ
│ │ ├── services/ # ビジネスロジック
│ │ └── repositories/ # データアクセス
│ └── tests/ # pytest
└── docker-compose.yml
```
## コマンド
### フロントエンド（frontend/）
- 開発サーバー: npm run dev
- テスト: npm test
- テスト（監視）: npm test -- --watch
- ビルド: npm run build
- リント: npm run lint
- 型チェック: npm run type-check
### バックエンド（backend/）
- 開発サーバー: uvicorn app.main:app --reload
- テスト: pytest
- テスト（カバレッジ）: pytest --cov=app
- リント: ruff check .
- フォーマット: ruff format .
- 型チェック: mypy .
### Docker
- 起動: docker compose up -d
- 停止: docker compose down
## 外部サービス
### 使用API
- [API名]: [用途]
### 環境変数
- DATABASE_URL: PostgreSQL接続文字列
- SECRET_KEY: JWT署名用シークレット
- [その他の環境変数]
## 開発ルール
### 共通
- TDDで開発（テストを先に書く）
- コミットメッセージはConventional Commits形式
- PRは1機能1PR
- ブランチ名: feature/issue-{番号}-{概要}
### フロントエンド
- 関数コンポーネントのみ（クラスコンポーネントはライフサイクルが複雑でテストしづらい）
- 型は明示的に定義（anyは型安全性を損なうため禁止。unknownを使い型ガードで絞り込む）
- API呼び出しはTanStack Query（キャッシュ管理、ローディング状態を統一）
### バックエンド
- 型ヒントを必ず付ける（IDEの補完とドキュメント生成のため）
- Pydanticでリクエスト/レスポンスを定義（バリデーションと型安全性）
- ビジネスロジックはservices/に集約（コントローラーを薄く保つ）
## エラーハンドリング
### フロントエンド
- API呼び出しはtry-catchで囲む
- ユーザー向けエラーは日本語で具体的なアクションを示す
- 予期しないエラーはエラーバウンダリでキャッチ
### バックエンド
- カスタム例外クラスを定義して使用
- HTTPExceptionで適切なステータスコードを返す
- ログにはcontext（user_id, request_id等）を含める
### リトライ戦略
- 外部API呼び出しは3回まで指数バックオフでリトライ
- タイムアウトは10秒に設定
## 禁止事項
- console.log / print文をコミットしない（デバッグ用はloggerを使用）
- 環境変数を直接参照しない（config経由で取得）
- any型を使わない（どうしても必要な場合はコメントで理由を記載）
- マジックナンバーを使わない（定数として定義）
- 秘密情報をコードにハードコードしない
## 参照ドキュメント
@docs/requirements.md
@docs/architecture.md
@docs/database-schema.md
@docs/api-spec.md
````
#### テンプレートB: Next.js のみ
Next.jsのみを使用する構成向け（API Routes / Server Actionsでバックエンド処理）。
````markdown
# Project: [プロジェクト名]
## 概要
[プロジェクトの目的を1-2文で]
## ドメイン知識
### ターゲットユーザー
- [ユーザー像]
### 主要機能
- [機能1]
- [機能2]
### 重要な制約
- [制約1]
### 用語集
- [用語1]: [説明]
## 技術スタック
- Framework: Next.js 15 (App Router)
- Language: TypeScript
- Styling: Tailwind CSS
- Database: Prisma + PostgreSQL
- Auth: NextAuth.js
- State: TanStack Query, Zustand
- Test: Vitest, React Testing Library, Playwright（E2E）
## ディレクトリ構造
```
project-root/
├── src/
│ ├── app/ # App Router
│ │ ├── (auth)/ # 認証関連ページ
│ │ ├── (main)/ # メインページ
│ │ ├── api/ # API Routes
│ │ └── layout.tsx
│ ├── components/
│ │ ├── ui/ # 汎用UI
│ │ └── features/ # 機能別
│ ├── hooks/ # カスタムフック
│ ├── lib/ # ユーティリティ
│ │ ├── db.ts # Prismaクライアント
│ │ └── auth.ts # 認証ヘルパー
│ ├── types/ # 型定義
│ ├── actions/ # Server Actions
│ └── stores/ # Zustandストア
├── prisma/
│ └── schema.prisma
├── tests/ # ユニットテスト
└── e2e/ # E2Eテスト
```
## コマンド
- 開発サーバー: npm run dev
- テスト: npm test
- テスト（監視）: npm test -- --watch
- E2Eテスト: npm run test:e2e
- ビルド: npm run build
- リント: npm run lint
- 型チェック: npm run type-check
- DB生成: npx prisma generate
- DBマイグレーション: npx prisma migrate dev
## 外部サービス
### 使用API
- [API名]: [用途]
### 環境変数
- DATABASE_URL: PostgreSQL接続文字列
- NEXTAUTH_SECRET: NextAuth.js用シークレット
- NEXTAUTH_URL: アプリケーションURL
## 開発ルール
- TDDで開発（テストを先に書く）
- コミットメッセージはConventional Commits形式
- PRは1機能1PR
- ブランチ名: feature/issue-{番号}-{概要}
## コーディング規約
- 関数コンポーネントのみ
- 型は明示的に定義（anyは禁止）
- Server Components: 直接fetchまたはPrisma
- Client Components: TanStack Query
- 更新処理: Server Actions
## エラーハンドリング
- Server Actions: try-catchで囲み、エラー時は`{ error: string }`を返す
- クライアント: エラー状態をUIに反映、トーストで通知
- ログ: 本番環境ではSentryに送信
## 禁止事項
- console.logをコミットしない
- 環境変数を直接参照しない（env.tsで一元管理）
- any型を使わない
- "use client"を不必要に付けない（Server Componentsを優先）
## 参照ドキュメント
@docs/requirements.md
@docs/architecture.md
@docs/database-schema.md
````
### Step 3: サブエージェントの作成
レビュー専門のサブエージェントを作成します。
```bash
cat > .claude/agents/reviewer.md << 'EOF'
---
name: reviewer
description: コードレビュー専門。変更内容を品質・セキュリティ・パフォーマンス観点で分析。
tools: Read, Grep, Glob, Bash
---
# Code Reviewer
あなたはシニアエンジニアとしてコードレビューを行う専門家です。
## レビュー前の準備
1. CLAUDE.mdを読み、以下を把握：
- ドメイン知識（用語、制約）
- コーディング規約
- エラーハンドリング方針
- 禁止事項
## レビュー手順
1. git diff --name-only で変更ファイル一覧を取得
2. git diff で変更内容を確認
3. 変更されたファイルを読み込み、文脈を理解
4. 以下の観点でレビュー
## レビュー観点
### CLAUDE.md準拠
- ドメイン知識に沿った実装か
- コーディング規約を守っているか
- エラーハンドリング方針に従っているか
- 禁止事項に違反していないか
### コード品質
- 可読性（命名、構造、コメント）
- DRY原則（重複コードがないか）
- 単一責任原則
- エラーハンドリング
### セキュリティ
- 入力値のバリデーション
- 認証・認可の適切な実装
- 機密情報の露出（APIキー、パスワード等）
- インジェクション系の脆弱性
### パフォーマンス
- N+1問題（DB操作がある場合）
- 不要な再レンダリング（フロントエンドの場合）
- メモリリーク
- 外部API呼び出しの効率（レート制限考慮）
### テスト
- テストカバレッジ
- エッジケースのテスト
- テストの可読性
## 出力形式
### サマリー
[全体評価を1-2文で。問題なければ「LGTM」]
### 指摘事項
#### 🔴 Critical（必須修正）
- [ファイル名:行番号] 問題の説明
- 理由: なぜ問題か
- 修正案: 具体的なコード例
#### 🟡 Warning（修正推奨）
- [ファイル名:行番号] 問題の説明
- 理由: なぜ問題か
- 修正案: 具体的なコード例
#### 🔵 Info（参考情報）
- [ファイル名:行番号] 改善の余地がある点
### 良い点
[良かった点があれば記載]
EOF
```
### Step 4: Slashコマンドの作成
13個のSlashコマンドを作成します。
#### 企画・設計フェーズのコマンド
##### /init - プロジェクト初期化
```bash
cat > .claude/commands/init.md << 'EOF'
---
description: 新規プロジェクトの初期化とヒアリング
---
新しいプロジェクトを開始します。以下の質問に答えてください。
## ヒアリング項目
### 1. プロジェクト概要
- どんなアプリ/サービスを作りますか？
- 一言で表すと？
### 2. ターゲットユーザー
- 誰が使いますか？
- どんな課題を解決しますか？
### 3. 主要機能
- 必須の機能は？（MVP）
- あったら嬉しい機能は？（将来）
### 4. 技術的な制約・要望
- 使いたい技術スタックは？
- 外部サービス連携は？
- デプロイ先は？
### 5. その他
- 参考にしたいサービスは？
- 特に気をつけたいことは？
---
ヒアリングが完了したら /requirements で要件定義に進みます。
EOF
```
##### /requirements - 要件定義
````bash
cat > .claude/commands/requirements.md << 'EOF'
---
description: 要件定義ドキュメントを生成
---
ヒアリング内容をもとに要件定義ドキュメントを作成します。
## 入力
$ARGUMENTS
（/initでのヒアリング結果、または追加の要件）
## 生成するドキュメント
### docs/requirements.md
```markdown
# [プロジェクト名] 要件定義書
## 1. プロジェクト概要
### 1.1 目的
### 1.2 背景
## 2. ターゲットユーザー
### 2.1 ペルソナ
### 2.2 ユーザーの課題
## 3. 機能要件
### 3.1 MVP（必須機能）
| ID | 機能名 | 説明 | 優先度 |
|----|--------|------|--------|
| F-001 | | | 高 |
### 3.2 将来機能
| ID | 機能名 | 説明 | 優先度 |
|----|--------|------|--------|
## 4. 非機能要件
### 4.1 パフォーマンス
### 4.2 セキュリティ
### 4.3 可用性
## 5. ユースケース
### UC-001: [ユースケース名]
- アクター:
- 事前条件:
- 基本フロー:
- 代替フロー:
- 事後条件:
## 6. 用語集
| 用語 | 説明 |
|------|------|
## 7. 制約事項
```
## 手順
1. ヒアリング内容を整理
2. 上記フォーマットでドキュメント生成
3. docs/requirements.md として保存
---
完了したら /design で設計に進みます。
EOF
````
##### /design - 設計
````bash
cat > .claude/commands/design.md << 'EOF'
---
description: アーキテクチャ・DB・API設計ドキュメントを生成
---
要件定義をもとに設計ドキュメントを作成します。
## 入力
$ARGUMENTS
（技術スタックの指定、設計上の要望など）
## 参照
@docs/requirements.md
## 生成するドキュメント
### 1. docs/architecture.md
```markdown
# アーキテクチャ設計書
## 1. システム構成図
[Mermaidで図示]
## 2. 技術スタック
### フロントエンド
### バックエンド
### インフラ
## 3. ディレクトリ構造
## 4. 主要コンポーネント
### [コンポーネント名]
- 責務:
- 依存:
## 5. データフロー
## 6. セキュリティ設計
### 認証・認可
### データ保護
## 7. エラーハンドリング方針
```
### 2. docs/database-schema.md
```markdown
# データベース設計書
## ER図
[Mermaidで図示]
## テーブル定義
### [テーブル名]
| カラム | 型 | 制約 | 説明 |
|--------|-----|------|------|
## インデックス
## マイグレーション方針
```
### 3. docs/api-spec.md
```markdown
# API仕様書
## 概要
- ベースURL:
- 認証方式:
## エンドポイント一覧
| メソッド | パス | 説明 |
|----------|------|------|
## 詳細
### [エンドポイント名]
- メソッド:
- パス:
- 認証:
- リクエスト:
- レスポンス:
- エラー:
```
## 手順
1. requirements.mdを参照
2. 技術スタックを決定
3. 各設計ドキュメントを生成
4. CLAUDE.mdを生成/更新
## CLAUDE.md更新
設計完了後、以下をCLAUDE.mdに反映：
- ドメイン知識（requirements.mdから）
- 技術スタック
- ディレクトリ構造
- コマンド
- 参照ドキュメント
---
完了したら /clear して開発フェーズに進みます。
EOF
````
#### 開発フェーズのコマンド
##### /new-issue - Issue作成
````bash
cat > .claude/commands/new-issue.md << 'EOF'
---
description: 新しいGitHub Issueを作成
---
新しいIssueを作成します。
## 入力
$ARGUMENTS
## 参照
@docs/requirements.md
@CLAUDE.md（ドメイン知識・用語集）
## 手順
### 1. 入力内容を整理
- タイトル: 簡潔で具体的に
- 目的: 何を達成したいか
- 要件: 具体的な機能・振る舞い
- 受け入れ条件: 完了の定義
### 2. requirements.mdとの整合性確認
- 該当する機能要件のIDを特定
- ユースケースとの対応を確認
### 3. Issue作成
```bash
gh issue create \
--title "[タイトル]" \
--body "## 概要
[このIssueで達成したいこと]
## 関連する機能要件
- F-XXX: [機能名]
## 要件
- [ ] [要件1]
- [ ] [要件2]
## 受け入れ条件
- [条件1]
- [条件2]
## 技術メモ
[実装のヒントがあれば]"
```
### 4. 結果表示
作成されたIssue番号とURLを表示してください。
EOF
````
##### /issue - Issue確認
````bash
cat > .claude/commands/issue.md << 'EOF'
---
description: GitHub Issueの内容を確認
---
Issue #$ARGUMENTS の内容を確認します。
```bash
gh issue view $ARGUMENTS
```
## 参照
@CLAUDE.md（ドメイン知識・用語集）
以下の形式で要約してください：
### 📋 Issue #$ARGUMENTS サマリー
タイトル: [タイトル]
関連機能: [F-XXX]
目的: [何を達成したいか]
要件: [要件リスト]
受け入れ条件: [条件リスト]
ドメイン用語: [このIssueに関連する用語があれば]
EOF
````
##### /research - 調査
````bash
cat > .claude/commands/research.md << 'EOF'
---
description: Issue実装のためのコードベース調査
---
Issue #$ARGUMENTS を実装するための調査を行います。
## 参照
@docs/requirements.md
@docs/architecture.md
@docs/database-schema.md
@docs/api-spec.md
## 調査の優先順位
1. CLAUDE.mdのドメイン知識・禁止事項を確認
2. 設計ドキュメントで該当箇所を確認
3. 既存の類似実装を探す
4. 外部サービス連携がある場合、API仕様を確認
5. テストコードから期待される振る舞いを把握
## 手順
1. gh issue view $ARGUMENTS でIssue確認
2. 関連する設計ドキュメントを参照
3. 関連ファイル・ディレクトリを特定
4. 既存の類似実装を探す
5. 影響範囲を特定
## 出力形式
### 🔍 調査結果: Issue #$ARGUMENTS
#### ドメイン知識の確認
- 関連する用語: [用語集から]
- 関連する制約: [CLAUDE.mdから]
#### 設計ドキュメントの確認
- アーキテクチャ: [関連箇所]
- DB: [関連テーブル]
- API: [関連エンドポイント]
#### 影響範囲
| 種別 | ファイルパス | 変更内容 |
|------|--------------|----------|
| 変更 | [パス] | [概要] |
| 新規 | [パス] | [概要] |
#### 既存実装の参考
- [ファイルパス]: [参考になる点]
#### 技術的考慮点
- [注意点]
- [禁止事項に関連する点]
#### 📝 次のステップへの引継ぎ
```
Issue #$ARGUMENTS: [タイトル]
影響ファイル: [一覧]
考慮点: [ポイント]
```
↑ このサマリーを /plan に渡してください
EOF
````
##### /plan - 計画
````bash
cat > .claude/commands/plan.md << 'EOF'
---
description: 実装計画とテストケースを設計
---
実装計画を立てます。
## 入力
$ARGUMENTS
## 参照
@CLAUDE.md（エラーハンドリング方針、禁止事項）
## 手順
1. CLAUDE.mdを参照し、技術スタックとディレクトリ構造を確認
2. 機能を小さな単位に分解
3. テストケースを設計（正常系・異常系・境界値）
4. エラーハンドリングの計画
5. TDDで進める実装順序を決定
## 出力形式
### 📝 実装計画
#### 機能分解
1. [機能1]: [説明]
2. [機能2]: [説明]
#### テストケース
| # | 機能 | テストケース | 種別 |
|---|------|--------------|------|
| 1 | 機能1 | 正常系テスト | 正常系 |
| 2 | 機能1 | 異常系テスト | 異常系 |
| 3 | 機能1 | 境界値テスト | 境界値 |
#### エラーハンドリング計画
| エラー種別 | 対応方法 | ユーザーへの表示 |
|------------|----------|-----------------|
| [エラー1] | [対応] | [メッセージ] |
#### 外部サービス連携（該当する場合）
- リトライ戦略: [CLAUDE.mdの方針に従う]
- タイムアウト: [秒数]
#### 実装ステップ
```
Step 1: [機能1のテスト] → /test [対象]
Step 2: [機能1の実装] → /impl [対象]
...
```
#### ファイル構成
CLAUDE.mdのディレクトリ構造に従って配置先を決定
---
この計画でよければ /clear してから /test で開始してください。
EOF
````
##### /test - テスト作成
```bash
cat > .claude/commands/test.md << 'EOF'
---
description: テストを作成（TDDのRedフェーズ）
---
テストを先に書きます（TDDのRedフェーズ）。
## 対象
$ARGUMENTS
## 参照
## 手順
### 1. CLAUDE.md参照
- 技術スタック（テストフレームワーク）を確認
- テストファイルの配置場所を確認
- テストの実行コマンドを確認
- エラーハンドリング方針を確認（異常系テストのため）
### 2. テストケース設計
- 正常系: 期待通りの動作
- 異常系: エラー処理（CLAUDE.mdの方針に従う）
- 境界値: エッジケース
### 3. テストコード作成
CLAUDE.mdの技術スタックに従ったテストコードを作成
### 4. テスト実行（失敗確認）
CLAUDE.mdに記載されたテストコマンドを実行
## 確認事項
❌ テストが失敗することを確認してください
これがTDDの「Red」フェーズです。
テストが失敗する状態で止め、次は /impl で実装に進みます。
## 注意
- まだ実装は書かない
- テストが失敗するのが正しい状態
- テストの意図が明確に伝わるテスト名にする
EOF
```
##### /impl - 実装
````bash
cat > .claude/commands/impl.md << 'EOF'
---
description: テストを通す実装（TDDのGreen→Refactorフェーズ）
---
テストを通す実装を行います（TDDのGreen→Refactorフェーズ）。
## 対象
$ARGUMENTS
## 参照
@CLAUDE.md（コーディング規約、禁止事項）
## 手順
### 1. CLAUDE.md参照
- コーディング規約を確認
- 禁止事項を確認
- エラーハンドリング方針を確認
- 配置場所を確認
### 2. Green: 最小限の実装
テストが通る最小限のコードを書く：
- 完璧を目指さない
- まずテストを通すことだけに集中
### 3. テスト実行（成功確認）
CLAUDE.mdに記載されたテストコマンドを実行
✅ テストが通ることを確認
### 4. Refactor: コード整理
テストが通る状態を維持しながら改善：
- 重複を除去
- 命名を改善
- 構造を整理
- 禁止事項に違反していないか再確認
### 5. テスト再実行
全テストが通ることを確認
### 6. コミット
```bash
git add -A
git commit -m "feat: [実装内容の説明]"
```
## 次のステップ
- 追加のテストケースがあれば → /test [対象]
- 全機能の実装が完了したら → reviewerでレビューして
EOF
````
##### /review - レビュー
```bash
cat > .claude/commands/review.md << 'EOF'
---
description: reviewerサブエージェントでレビュー
---
reviewerサブエージェントを使って、現在の変更をレビューします。
## 手順
1. git diff --name-only で変更確認
2. reviewerサブエージェントにレビュー依頼
## 結果に基づくアクション
- 🔴 Critical → 必ず修正してから再レビュー
- 🟡 Warning → 可能な限り修正してから再レビュー
- 🔵 Info → 参考にしつつ、対応は任意
- LGTM → /pr へ進む
## 修正方法
- テスト追加が必要 → /test [対象] → /impl [対象]
- 実装修正のみ → 直接修正してコミット
## 修正後
「reviewerで再レビューして」で再度レビューを依頼
EOF
```
##### /pr - PR作成
````bash
cat > .claude/commands/pr.md << 'EOF'
---
description: PRを作成
---
Issue #$ARGUMENTS に対するPRを作成します。
## 手順
### 1. 変更確認
```bash
git status
git diff --stat
```
### 2. 未コミット変更の確認
未コミットの変更があれば、適切なメッセージでコミット
### 3. プッシュ
```bash
git push -u origin HEAD
```
### 4. PR作成
```bash
gh pr create \
--title "feat: [機能の説明]" \
--body "## 概要
[このPRで実装した内容]
## 変更点
- [変更1]
- [変更2]
## テスト
- [x] ユニットテスト追加
- [x] 既存テストが通ることを確認
Fixes #$ARGUMENTS"
```
### 5. 結果表示
作成されたPRのURLを表示してください。
EOF
````
##### /merge - マージ
````bash
cat > .claude/commands/merge.md << 'EOF'
---
description: PRをマージ
---
現在のブランチのPRをマージします。
## 手順
### 1. PR状態確認
```bash
gh pr status
```
### 2. CI/CDステータス確認
```bash
gh pr checks
```
すべてのチェックがパスしていることを確認。
### 3. マージ実行
```bash
gh pr merge --squash --delete-branch
```
### 4. ローカル更新
```bash
git checkout main
git pull origin main
```
## 注意
- CIが失敗している場合はマージしない
- コンフリクトがある場合は先に解決する
EOF
````
#### リリースフェーズのコマンド
##### /release - リリース
````bash
cat > .claude/commands/release.md << 'EOF'
---
description: リリース準備（CHANGELOG更新、タグ付け）
---
リリースの準備を行います。
## 入力
$ARGUMENTS
（バージョン番号: 例 v1.0.0）
## 手順
### 1. 変更履歴の収集
```bash
git log --oneline $(git describe --tags --abbrev=0)..HEAD
```
### 2. CHANGELOG.md更新
以下の形式で追記：
```markdown
## [$ARGUMENTS] - [日付]
### Added
- [新機能]
### Changed
- [変更]
### Fixed
- [バグ修正]
```
### 3. バージョン更新（該当する場合）
- package.json
- pyproject.toml
- その他バージョン管理ファイル
### 4. コミット
```bash
git add -A
git commit -m "chore: release $ARGUMENTS"
```
### 5. タグ付け
```bash
git tag -a $ARGUMENTS -m "Release $ARGUMENTS"
git push origin main --tags
```
### 6. GitHubリリース作成
```bash
gh release create $ARGUMENTS --title "$ARGUMENTS" --notes-file CHANGELOG.md
```
## 注意
- mainブランチで実行すること
- すべてのテストがパスしていることを確認
EOF
````
### Step 5: 公式プラグインのインストール
Claude Codeの公式プラグインを追加します。これらはプロジェクトではなく、ユーザー単位でインストールされます。
> なぜこの2つだけ？
>
> この2つのプラグインは、**開発フローには影響を与えずに品質を向上させる**ものです。Slashコマンドやワークフローを追加するわけではないので、この記事で構築する「コマンド駆動の開発環境」と干渉しません。詳しくは [Appendix: 公式プラグインについて](#appendix-公式プラグインについて) を参照してください。
```bash
# Claude Codeを起動
claude
# 公式マーケットプレイスを追加（初回のみ）
/plugin marketplace add anthropics/claude-code-plugins
# frontend-design: フロントエンド作業時に高品質なデザインを自動生成
/plugin install frontend-design@anthropics
# security-guidance: セキュリティパターンを監視・警告
/plugin install security-guidance@anthropics
# インストール確認
/plugin
```
インストール後、Claude Codeを再起動してください。
#### frontend-design
フロントエンド作業（コンポーネント作成、ページ実装など）を検出すると**自動的に発動**するSkillです。
- 「AIっぽい」ジェネリックなデザイン（Inter、紫グラデーション等）を避ける
- タイポグラフィ、アニメーション、カラー、空間構成に配慮した提案
- 明示的な呼び出し不要（Claudeが自動判断）
#### security-guidance
ファイル編集時に**常時監視**するHookです。以下のセキュリティパターンを検出すると警告します：
- コマンドインジェクション
- XSS（クロスサイトスクリプティング）
- eval/exec使用
- 危険なHTML生成
- os.system呼び出し
- その他6種類のパターン
### Step 6: 初回コミット
```bash
echo ".claude/settings.local.json" >> .gitignore
git add .
git commit -m "chore: Claude Code開発環境セットアップ"
git push
```
---
## 実践例: タスク管理アプリの開発
実際の開発フローを見てみましょう。
### 企画・設計フェーズ
```bash
# ===== Claude Code起動 =====
claude
# ===== 1. プロジェクト初期化 =====
/init
# Claudeとの対話:
# Q: どんなアプリを作りますか？
# A: 個人用のシンプルなタスク管理アプリ
# Q: ターゲットユーザーは？
# A: 自分一人で使う。シンプルに使いたい
# Q: 主要機能は？
# A: タスクの追加、完了、削除。期限設定
# Q: 技術スタックは？
# A: Next.js、Prisma、PostgreSQL
# ===== 2. 要件定義 =====
/requirements
# → docs/requirements.md が生成される
# ===== 3. 設計 =====
/design Next.jsのみの構成で
# → docs/architecture.md
# → docs/database-schema.md
# → docs/api-spec.md
# → CLAUDE.md が生成/更新される
# ===== 4. コンテキストリセット =====
/clear
```
### 開発フェーズ
```bash
# ===== 5. Issue作成 =====
/new-issue タスク追加機能。タイトルと期限を入力してタスクを作成できる
# → Issue #1 が作成される
# ===== 6. Issue確認 =====
/issue 1
# ===== 7. 調査 =====
/research 1
# ===== 8. コンテキストリセット =====
/clear
# ===== 9. 計画 =====
/plan Issue #1 タスク追加機能
# ===== 10. コンテキストリセット =====
/clear
# ===== 11. ブランチ作成 =====
git checkout -b feature/issue-1-add-task
# ===== 12. TDDサイクル =====
# --- Red ---
/test createTask関数。正常系、タイトル空、期限過去日
# → テストコード作成、npm test で失敗確認
# --- Green → Refactor ---
/impl createTask関数
# → 実装、npm test で成功、コミット
# 繰り返し...
/test TaskForm。入力、バリデーション、送信
/impl TaskForm
# ===== 13. レビュー =====
reviewerでレビューして
# 出力例:
# ### サマリー
# 良い実装ですが、エラーハンドリングに改善点があります。
#
# ### 🟡 Warning
# - src/actions/task.ts:15 エラー時のユーザーメッセージが英語
# - 理由: CLAUDE.mdで「日本語で具体的なアクション」と定義
# - 修正案: "Failed to create" → "タスクの作成に失敗しました。もう一度お試しください。"
# ===== 14. 修正 =====
"エラーメッセージを日本語に修正して"
# ===== 15. 再レビュー =====
reviewerで再レビューして
# → LGTM
# ===== 16. PR作成 =====
/pr 1
# ===== 17. マージ =====
/merge
# ===== 18. 次のIssueへ =====
/clear
# → /new-issue から繰り返し
```
### リリースフェーズ
```bash
# 機能が揃ったらリリース
/release v1.0.0
```
---
## コマンドクイックリファレンス
| コマンド | 説明 | フェーズ |
|----------|------|----------|
| /init | プロジェクト初期化、ヒアリング | 企画・設計 |
| /requirements | 要件定義ドキュメント生成 | 企画・設計 |
| /design | 設計ドキュメント生成 | 企画・設計 |
| /new-issue [説明] | Issue作成 | 開発（準備） |
| /issue [番号] | Issue確認 | 開発（準備） |
| /research [番号] | コードベース調査 | 開発（準備） |
| /plan [引継ぎ] | 実装計画作成 | 開発（計画） |
| /test [対象] | テスト作成（Red） | 開発（実装） |
| /impl [対象] | 実装（Green→Refactor） | 開発（実装） |
| reviewerでレビューして | コードレビュー | 開発（完了） |
| reviewerで再レビューして | 修正後の再レビュー | 開発（完了） |
| /pr [番号] | PR作成 | 開発（完了） |
| /merge | マージ | 開発（完了） |
| /release [バージョン] | リリース準備 | リリース |
| /clear | コンテキストクリア | フェーズ切替時 |
---
## Tips
### コンテキスト管理
| コマンド | 説明 | 使いどころ |
|----------|------|------------|
| /context | 使用量確認 | 定期的に |
| /clear | 会話クリア | フェーズ切替時 |
| /compact | 圧縮 | 途中で軽くしたい時 |
目安: 60%を超えたら`/compact`か`/clear`を検討
### VS Code活用
- Plan Mode: Shift+Tabで切り替え。計画時に便利
- ファイル参照: @ファイル名#L10-20で特定行を参照
- 複数会話: Cmd+Nで新規会話。タスクごとに分けられる
---
## トラブルシューティング
### Slashコマンドが表示されない
```bash
# ファイル確認
ls -la .claude/commands/
# 拡張子が.mdか確認
# フロントマター（---）が正しいか確認
# Claude Codeを再起動
```
### ghコマンドが失敗する
```bash
gh auth status # 認証確認
gh auth login # 再認証
```
### サブエージェントが呼び出せない
```bash
# 確認
cat .claude/agents/reviewer.md | head -5
# 呼び出し方（正しい）
"reviewerサブエージェントでレビューして"
"reviewerでレビューして"
# 間違い（スラッシュコマンドではない）
# /reviewer
```
### 設計ドキュメントが参照されない
```bash
# CLAUDE.mdの参照ドキュメントセクションを確認
# @docs/xxx.md の形式で記載されているか
# ファイルが実際に存在するか
```
---
## まとめ
この記事で構築した環境のポイントをまとめます。
### 設計思想
| 方針 | 理由 |
|------|------|
| コマンド駆動 | 開発フローを理解しながら進められる |
| 対話重視 | Claudeの強みを活かす |
| 企画から開発まで一貫 | 要件・設計を明文化してClaudeに伝える |
| 技術スタック非依存 | CLAUDE.mdだけ変えれば、どのプロジェクトでも使える |
| 最小構成 | 追加費用なし、設定シンプル |
| 段階的拡張 | 必要に応じて機能追加可能 |
### 構成要素
| 要素 | 個数 | 役割 | 技術スタック依存 |
|------|------|------|------------------|
| CLAUDE.md | 1 | プロジェクトの「魂」（ドメイン知識、ルール） | ✅ プロジェクトごとにカスタマイズ |
| Slashコマンド | 13 | 開発フローの各ステップ | ❌ 汎用的、流用可能 |
| サブエージェント | 1 | レビュー専門（実装コンテキストを保持したまま分離実行） | ❌ 汎用的、流用可能 |
| 公式プラグイン | 2 | フロントエンドデザイン向上 + セキュリティ監視 | ❌ 汎用的 |
### 開発フロー
```
企画・設計: /init → /requirements → /design → /clear
↓
開発（繰り返し）:
準備: /new-issue → /issue → /research → /clear
計画: /plan → /clear
実装: /test ⇄ /impl（TDDサイクル）
↓ ⚠️ /clear しない
完了: reviewerでレビュー ⇄ 修正（ループ）
→ /pr → /merge → /clear
↓
リリース: /release
```
ポイント: 実装→完了の間で`/clear`しないことで、レビュー指摘への修正がスムーズに。
この構成は「ちょうどいい」出発点です。使いながら「このサブエージェントがあれば便利」「このHookがあれば自動化できる」と感じたら、その時に追加してください。
最初から完璧な環境を目指すより、**理解しながら育てていく環境**の方が、長く使い続けられます。
---
## 完成したディレクトリ構成
```
your-project/
├── CLAUDE.md
├── .claude/
│ ├── commands/
│ │ ├── init.md
│ │ ├── requirements.md
│ │ ├── design.md
│ │ ├── new-issue.md
│ │ ├── issue.md
│ │ ├── research.md
│ │ ├── plan.md
│ │ ├── test.md
│ │ ├── impl.md
│ │ ├── review.md
│ │ ├── pr.md
│ │ ├── merge.md
│ │ └── release.md
│ └── agents/
│ └── reviewer.md
└── docs/
├── requirements.md
├── architecture.md
└── api-spec.md
```
---
## Appendix: LSPサポート（実験的）
Claude Code v2.0.74以降、LSP（Language Server Protocol）サポートがプラグイン機能として追加されています。
LSPを有効にすると、以下のようなコードインテリジェンス機能が使えるようになります：
- goToDefinition - シンボルの定義元へジャンプ
- findReferences - シンボルへの参照を検索
- hover - ホバー情報（型情報、ドキュメント）を取得
- documentSymbol - ドキュメント内のシンボル一覧を取得
### 現状の注意点
⚠️ 2025年12月時点では、LSPサポートはまだ実験的な段階です。
- 公式マーケットプレイスのLSPプラグインは導入ガイドのみで、実際の設定ファイルが不足している場合がある
- バージョンによって動作が異なる可能性がある
- 安定したLSPサポートを求める場合は、今後のアップデートを待つことを推奨
### 参考リンク
- [Claude Code LSP Servers - 公式ドキュメント](https://code.claude.com/docs/en/plugins-reference#lsp-servers)
- [Claude Code の LSP サポート - azukiazusa.dev](https://azukiazusa.dev/blog/claude-code-lsp-support/)
---
## Appendix: 公式プラグインについて
Claude Codeには、Anthropicが提供する公式プラグインが複数用意されています。この記事では自作のSlashコマンドを使っていますが、公式プラグインで同様のワークフローを実現することも可能です。
### なぜ自作コマンドを採用したのか
この記事では、公式の開発ワークフロープラグイン（`feature-dev`など）ではなく、**自作のSlashコマンド**を採用しています。理由は以下の通りです：
#### 1. 仕組みの理解と透明性
自作コマンドは、各ステップで何が行われているかが明確です。コマンドの中身を読めばClaudeへの指示がすべてわかるため、問題が起きたときにデバッグしやすく、Claude Codeの仕組みを理解しながら使えます。
公式プラグインは最適化されていますが、内部動作がブラックボックスになりがちです。
#### 2. カスタマイズ性
自作コマンドは、プロジェクト固有の要件に合わせて自由に編集できます：
- CLAUDE.mdとの連携を強化
- TDD（テスト駆動開発）を明示的に組み込み
- GitHub Issue駆動のワークフローを構築
- エラーハンドリング方針やドメイン知識を参照させる
公式プラグインのワークフローを変更するのは困難です。
#### 3. 学習効果
自作コマンドを作成・改善する過程で、Slashコマンド、サブエージェント、Skills、Hooksといったクロード Codeの機能を体系的に理解できます。
### 公式の開発ワークフロープラグイン
参考として、Anthropic公式の開発ワークフロープラグインを紹介します：
| プラグイン | 種類 | 内容 |
|-----------|------|------|
| feature-dev | Command + Agents | 7フェーズの機能開発ワークフロー（Explore → Clarify → Architect → Design → Plan → Execute → Review） |
| code-review | Command + Agents | 5並列エージェントによるPRレビュー |
| pr-review-toolkit | Command + Agents | 6種類の専門レビューエージェント |
| commit-commands | Commands | git commit/push/PRワークフロー |
これらは /plugin install [name]@anthropics でインストールできます。
#### feature-dev との比較
| 観点 | feature-dev（公式） | 自作コマンド（この記事） |
|------|---------------------|-------------------------|
| セットアップ | 1コマンドで完了 | ファイル作成が必要 |
| カスタマイズ | 困難 | 自由に編集可能 |
| TDD対応 | 含まれない | Red→Green→Refactorを明示 |
| Issue連携 | なし | GitHub Issue駆動 |
| 透明性 | ブラックボックス | 全ステップが明確 |
| 学習効果 | 低い | 高い |
結論: すぐに使い始めたい場合は`feature-dev`が便利ですが、開発フローを理解・カスタマイズしたい場合は自作コマンドをお勧めします。
### この記事で採用したプラグイン
この記事では、**開発フローに影響を与えないプラグイン**のみを採用しています：
| プラグイン | 種類 | 採用理由 |
|-----------|------|----------|
| frontend-design | Skill | フロントエンド作業時に自動発動し、デザイン品質を向上。ワークフローには干渉しない |
| security-guidance | Hook | ファイル編集時にセキュリティパターンを監視。開発フローを変えずに安全性を向上 |
これらは「ワークフロー」ではなく「品質向上」のためのプラグインです。自作のSlashコマンドと組み合わせても問題なく動作し、開発フローの透明性を保ったまま成果物の品質を高められます。
---
## 参考リンク
- [Claude Code 公式ドキュメント](https://docs.anthropic.com/claude-code)
- [Claude Code Best Practices - Anthropic Engineering](https://www.anthropic.com/engineering/claude-code-best-practices)
oddy
"チーバくんの目"のあたりで暮らす、フリーランスエンジニアのoddyです。 サイト名の"OJTHON"(オジソン)の由来は、わが家での私のあだ名とプログラミング言語Python(パイソン)のもじりです。 僕たち家族の思い出と記録、そして今の僕が考えることについて、何かしらの形にして残していきたいと思い、このOJTHON.dev HOME / BLOGを作りました。