🐙

Claude Codeを"優秀な新卒部下"として使い倒す：個人開発爆速化の全ワークフロー

に公開
個人開発
Claude
Claude Code
githubmcp
tech

はじめに

AIで開発は本当に速くなったのか？
「AIを使えば開発が速くなる」
このフレーズ自体は、もう聞き飽きるほど目にしてきました。

実際、コード補完は賢いし、ちょっとした関数やエラー修正なら一瞬で解決することもあります。
でも本当に“開発全体”は速くなりましたか？

  • コードを貼り付けて修正してもらう。
  • 生成されたコードをコピペする。
  • 動かない。
  • 足りなかった前提を説明し直す。

気づけば、コンテキストの説明に時間を使い、差分の確認に神経を使い、結局自分で修正する。
そんな経験ないでしょうか？

AIは優秀ですが、「ワークフローに組み込まれていないAI」は、強力な検索エンジンとあまり変わりません。

私はClaude Codeを個人開発に導入する際、プロンプトを工夫するのをやめて、AIが迷わない構造そのものを設計することにしました。

その結果、Issue作成、実装、PR作成までを一貫して任せられるようになり、体感で明確に開発速度が変わりました。
この記事では、そのために最初にやった設計と、具体的な手順を公開しようと思います。

Claude Codeは「優秀な新卒エンジニア」だ

まず最初に、Claude Codeとの向き合い方について少しだけ書かせてください。

多くの人は、Claude Codeを「とても賢い補完ツール」として使っています。
それ自体は間違っていません。実際、とても優秀です。

ただ、個人的にはそれだと少しもったいないと感じています。

私はClaude Codeを、「優秀だけど、まだ経験の浅い新卒エンジニア」 のような存在だと考えることにしました。

この比喩が、かなりしっくりきています。

  • 指示が曖昧だと壊れる — 「いい感じにやっといて」は通じない
  • コンテキストが不足すると迷子になる — プロジェクトの背景を知らなければ正しい判断ができない
  • 仕様を書けば書くほど強くなる — 制約と期待値が明確なほど、アウトプットの品質が上がる
  • 放置すると暴走する — 適切なチェックポイントがないと、意図しない方向に進む

でも逆に言えば、

環境と前提をきちんと整えてあげれば、驚くほどのスピードで仕事をしてくれる存在でもあります。
だからこそ重要なのは、プロンプトのテクニックよりも、

「AIが迷わず動ける環境を設計すること」。

この “環境設計” こそが、個人開発を本当に速くするための本質だと感じています。

Step 1: CLAUDE.mdの設定(Claudeへの辞令書)

CLAUDE.mdとは何か

CLAUDE.md はプロジェクトルートに置くと、Claude Codeが自動的に読み込む設定ファイルです。
ここに書いた内容は、会話のたびに伝え直す必要がなくなります。

新卒に入社初日のオリエンテーションをするイメージです。

私のCLAUDE.mdは「Claudeへの行動規範」として設計しています。
技術仕様ではなく、思想と振る舞いを書くのがポイントです。

私が使っているCLAUDE.mdの実例
## ワークフロー
### 1. 計画フェーズ（プランモード）
- 3ステップ以上 または 設計判断が必要なタスクは **必ずプランモードに入る**
- 途中で問題が発生したら **即座に作業を止めて再計画する**（無理に進めない）
- 構築だけでなく、検証ステップもプランモードで計画する
- 詳細な仕様をあらかじめ明文化して曖昧さを排除する

### 2. サブエージェント戦略
- メインのコンテキストウィンドウをクリーンに保つために **サブエージェントを積極活用する**
- リサーチ・コード探索・並列分析はサブエージェントに委譲する
- 複雑な問題には複数のサブエージェントを投入してより多くの計算リソースをかける
- 1サブエージェント = 1タスクで集中して実行させる

### 3. 自己改善ループ
- ユーザーから修正指摘を受けたら **必ず `tasks/lessons.md` にそのパターンを記録する**
- 同じミスを繰り返さないためのルールを自分向けに書く
- ミス率が下がるまでレッスンを徹底的に改善し続ける
- セッション開始時にそのプロジェクトに関連するレッスンをレビューする

### 4. 完了前の検証（必須）
- **動作を証明せずにタスク完了としない**
- 関連する場合は `main` と自分の変更の差分を確認する
- 「スタッフエンジニアがこれを承認するか？」と自問する
- テストを実行し、ログを確認し、正しさを実証する

### 5. エレガントさを追求する（バランス重視）
- 非自明な変更では「より優雅な方法はないか？」と立ち止まって考える
- 修正がハック的に感じたら：「今知っている全てを活かして、エレガントな解決策を実装する」
- 単純で明白な修正にはこれを省略する（過剰設計しない）
- 提示する前に自分のコードを批判的にレビューする

### 6. バグ修正の自律対応
- バグレポートが来たら **そのまま修正する**（手取り足取り聞かない）
- ログ・エラー・失敗テストを手がかりにして自力で解決する
- ユーザーのコンテキストスイッチをゼロにする
- 指示されなくても CI の失敗テストを修正しに行く

---

## タスク管理

| ステップ | 内容 |
|----------|------|
| **計画を立てる** | `tasks/todo.md` にチェック可能な項目でプランを書く |
| **計画を確認する** | 実装開始前にチェックインする |
| **進捗を追跡する** | 完了した項目を随時チェック済みにする |
| **変更を説明する** | 各ステップでハイレベルなサマリーを提示する |
| **結果を記録する** | `tasks/todo.md` にレビューセクションを追加する |
| **レッスンを残す** | 修正指摘を受けたら `tasks/lessons.md` を更新する |

---

## 基本原則
**シンプルさを最優先**: あらゆる変更を可能な限りシンプルにする。影響するコードを最小限に留める。
**手を抜かない**: 根本原因を突き止める。一時しのぎの修正はしない。シニアエンジニアの水準で臨む。
**影響を最小化する**: 変更は必要な箇所だけに留める。バグを新たに持ち込まない。

## プロジェクト構成・アーキテクチャ
コマンド・技術スタック・ディレクトリ構成・ルーティングの詳細は [`ai/rules/PROJECT_ARCHITECTURE.md`](ai/rules/PROJECT_ARCHITECTURE.md) を参照してください。

## ブランチ・コミット・PR ガイドライン
ブランチ命名・コミットメッセージ・PR作成の規約は [`ai/rules/GIT_WORKFLOW.md`](ai/rules/GIT_WORKFLOW.md) を参照してください。
作業開始・終了時には必ずこのガイドラインに従ってください。

## React Native コード規約
コンポーネント・スタイル・パフォーマンス・TypeScript の規約は [`ai/rules/REACT_NATIVE_GUIDELINES.md`](ai/rules/REACT_NATIVE_GUIDELINES.md) を参照してください。
実装・修正時には必ずこのガイドラインに従い、`~/.claude/skills/vercel-react-native-skills/SKILL.md` も合わせて参照してください。

実は、今使っているCLAUDE.mdは、もともと自分で試行錯誤しながら書いていたものとは少し違います。

これまでは、自分なりにワークフローやルールを整理したCLAUDE.mdを使っていましたが、最近Xで話題になっていた、AnthropicのClaude Code開発者が実際に使っているCLAUDE.mdを日本語訳して取り入れました。（いいものは素直に取り入れる精神です）

実際にCLAUDE.mdを整備して運用してみると、Claudeが “補完ツール” から “実行主体” に変わりました。
一番大きいのはここです。

ルールがない状態だと、Claudeは

  • いきなり実装する
  • 局所的に正しいコードを書く
  • 全体設計を考えない
  • 完了基準が曖昧

という “賢い補完ツール” の動きをします。

でも、ワークフローをCLAUDE.mdに明文化すると変わります。

  • 3ステップ以上なら自動で計画する
  • 問題が起きたら止まって再計画する
  • 完了前に検証を意識する
  • スタッフエンジニア基準で自己チェックする

つまり、受動的なAI → 能動的なエンジニア に変わります。

特に効果が大きかったのはこの3つです。

  • 設計せずに突っ込む事故がほぼなくなった
  • 「動いたからOK」が消え、検証が標準化された
  • ミスがLESSON.mdに蓄積され、再発しにくくなった

速くなった理由は、タイピングが減ったからではありません。
判断コストが減ったからです。
AIを速くするのではなく、“迷わない環境” を作る。これが爆速化の本質でした。

ai/rules ディレクトリ設計：ルールの分離と明確化

CLAUDE.mdはベースを参考にしていますが、安定して実装を任せるには、「開発思想」だけでなく、プロジェクト固有の前提条件まで明文化する必要があります。
そこで、自分のプロジェクト用に次の3つを追加しました。

  • プロジェクト構成・アーキテクチャ
  • ブランチ・コミット・PR ガイドライン
  • React Native コード規約

ポイントは、これらをCLAUDE.mdに直接書かず、ai/rulesディレクトリ配下に分離したことです。
ルールが長くなるほどClaudeの注意が散漫になり、重要なルールが埋もれ、守られなくなります。
ルールを分割することで、特定の作業をClaudeに任せる際に関連するルールだけを読ませることができます。
プログラムのモジュール分割と同じ発想で、ルールを役割別に分割するようにしました。

ai/
└── rules/
    ├── GIT_WORKFLOW.md
    ├── PROJECT_ARCHITECTURE.md
    ├── REACT_NATIVE_GUIDELINES.md

各ファイルに書いている内容

GIT_WORKFLOW.md
# Branch / Commit / PR Guidelines for Claude Code

> このガイドラインは、Claude Codeがブランチ作成・コミット・PR作成を自動実行する際に従うべき規約です。
> プロジェクトのルートまたは `.claude/` に配置し、`CLAUDE.md` から参照してください。

---

## 1. ブランチ命名規則

### フォーマット
<type>/<issue番号>-<kebab-case-の説明>

### typeの一覧

| type | 用途 |
|------|------|
| `feature` | 新機能追加 |
| `fix` | バグ修正 |
| `refactor` | リファクタリング（振る舞い変更なし） |
| `docs` | ドキュメントのみの変更 |
| `test` | テストの追加・修正 |
| `chore` | ビルド・CI・依存関係などの変更 |
| `hotfix` | 本番緊急対応 |

### 命名例
feature/123-add-login-validation
fix/456-session-error-after-password-reset
refactor/789-extract-auth-service
docs/101-update-readme-setup
chore/update-eslint-config
hotfix/critical-payment-null-error

### ブランチ作成ルール
- **必ずデフォルトブランチ（`develop`）の最新から切る**
- 1ブランチ = 1つの目的・1つのIssue
- ブランチ名は小文字・ハイフン区切り（スペース・アンダースコア禁止）
- Issue番号がある場合は必ず含める

### Claude Codeへの指示
# ブランチ作成前に必ず最新を取得する
git checkout develop && git pull origin develop

# ブランチを作成して移動
git checkout -b <type>/<issue番号>-<説明>

## 2. コミットメッセージ規約

[Conventional Commits](https://www.conventionalcommits.org/) に準拠します。

### フォーマット
<type>(<scope>): <subject>

[任意: body - なぜこの変更が必要か]

[任意: footer - Breaking Change / Issue参照]

### typeの一覧

| type | 用途 |
|------|------|
| `feat` | 新機能 |
| `fix` | バグ修正 |
| `docs` | ドキュメントのみ |
| `style` | フォーマット・空白など（ロジック変更なし） |
| `refactor` | リファクタリング |
| `test` | テストの追加・修正 |
| `chore` | ビルド・CI・依存関係 |
| `perf` | パフォーマンス改善 |
| `revert` | コミットの取り消し |

### コミットメッセージの書き方

**subject（1行目）のルール：**
- 50文字以内を目安
- 現在形・命令形で書く（`修正する` / `add` / `fix`）
- 文末にピリオド不要
- 「何をしたか」より「**なぜしたか・何が変わるか**」を意識する

**body（任意）のルール：**
- 1行目と空行を1行挟む
- 「なぜこの変更が必要か」「何を考慮したか」を書く
- 72文字で折り返す

**良い例 / 悪い例：**

```bash
# 悪い例（何をしたか羅列するだけ）
git commit -m "ボタンの色を変更した"
git commit -m "fix bug"
git commit -m "修正"

# 良い例（why + what が明確）
git commit -m "feat(auth): パスワードリセット後の自動ログイン機能を追加

セキュリティポリシー変更により、リセット後は再認証を必須とする。
セッション継続を廃止し、ログイン画面へリダイレクトする。

Closes #456"

git commit -m "fix(ui): CTAボタンのコントラスト比をWCAG AA基準に修正

blue-400では基準値4.5:1を下回っていたためblue-600に変更。
Closes #789"

### 1コミット = 1つの論理的変更
- 複数の変更を1コミットに詰め込まない
- WIP（作業中）コミットはPR作成前に `git rebase -i` でsquashする
- `git add -p` でハンクごとに追加し、意図しない変更を混入させない

### Breaking Changeの書き方
git commit -m "feat(api)!: レスポンス形式をJSONに統一
BREAKING CHANGE: XMLレスポンスは廃止。
既存クライアントは移行ガイド(docs/migration.md)を参照。"

## 3. Pull Request規約

### PR タイトル
コミットメッセージと同じConventional Commits形式 + Issue番号

feat(auth): パスワードリセット後の自動ログイン機能を追加 #456
fix(ui): CTAボタンのコントラスト比をWCAG AA基準に修正 #789

### PR 本文テンプレート

```markdown
## 概要
<!-- このPRで何をしたかを2〜3文で説明 -->

## 背景・目的
<!-- なぜこの変更が必要か。関連Issueへのリンク -->
Closes #<issue番号>

## 変更内容
<!-- 主な変更点をリストアップ -->
-
-
-

## スコープ外（やっていないこと）
<!-- 今回あえて含めなかったことを明示 -->
-

## 動作確認方法
<!-- レビュアーがローカルで確認する手順 -->
1.
2.
3.

## スクリーンショット / 動画
<!-- UI変更がある場合は必須。Before / After形式で -->

| Before | After |
|--------|-------|
| <!-- 画像 --> | <!-- 画像 --> |

## チェックリスト
- [ ] セルフレビュー済み
- [ ] テストを追加・更新した
- [ ] 既存テストがすべて通る
- [ ] ドキュメントを更新した（必要な場合）
- [ ] Breaking Changeがある場合は明記した

## レビュアーへのメモ
<!-- 特に見てほしい箇所、迷った判断、懸念点などを事前に共有 -->

### PRの品質基準

**差分のサイズ：**
- 理想は **400行以内**
- 400行超の場合は分割を検討する
- 機械的な変更（リネーム・フォーマット）は別PRに切り出す

**Draft PRの活用：**
- 実装開始直後にDraft PRを立てて方向性を共有する
- レビュー依頼前に `Ready for review` に変更する

**セルフレビューの徹底：**
- アサイン前に自分でdiffを全行確認する
- デバッグ用コード（`console.log`、`binding.pry`など）が残っていないか確認する
- コメントアウトされたコードが残っていないか確認する
REACT_NATIVE_GUIDELINES.md
# React Native コード規約ガイドライン

> このガイドラインは、baby-log プロジェクト（Expo + React Native + TypeScript）における
> コーディング規約をまとめたものです。実装時は必ずこのファイルを参照してください。

---

## 外部スキル参照（必須）

**React Native / Expo のベストプラクティスは以下のスキルを優先参照してください：**
~/.claude/skills/vercel-react-native-skills/SKILL.md       # クイックリファレンス・優先度一覧
~/.claude/skills/vercel-react-native-skills/AGENTS.md      # 全ルール展開（詳細版）
~/.claude/skills/vercel-react-native-skills/rules/         # 個別ルールファイル

実装時は以下の優先度でルールを適用してください：

| 優先度 | カテゴリ | キーワード |
|--------|----------|------------|
| 1 | リストパフォーマンス | `list-performance-*` |
| 2 | アニメーション | `animation-*` |
| 3 | ナビゲーション | `navigation-*` |
| 4 | UI パターン | `ui-*` |
| 5 | 状態管理 | `react-state-*` |
| 6 | レンダリング | `rendering-*` |

---

## 1. ファイル・ディレクトリ規約

### ファイル命名
- コンポーネントファイル: `PascalCase.tsx`（例: `BabyCard.tsx`）
- フック: `use-kebab-case.ts`（例: `use-baby-log.ts`）
- ユーティリティ・定数: `kebab-case.ts`（例: `date-utils.ts`）
- プラットフォーム分岐: `.ios.tsx` / `.web.ts` サフィックスで上書き

### 配置ルール
src/
├ screens/     # 画面コンポーネント（ナビゲーションと1対1）
├ components/  # 再利用可能なUIコンポーネント
│  └ ui/       # 低レベルプリミティブ（Button, Text, Icon など）
├ hooks/       # カスタム Hooks（use- プレフィックス必須）
├ constants/   # 定数・テーマ（theme.ts など）
├ utils/       # 純粋関数ユーティリティ
├ types/       # 共有型定義
└ atoms/       # グローバル状態（Zustand / Jotai）

PROJECT_ARCHITECTURE.mdに関しては/init でプロジェクト構造をClaude自身に書かせています。

余談ですが、REACT_NATIVE_GUIDELINES.mdにはvercel-react-native-skillsを参照するように書いていて、これは、Vercelが公開しているReact Nativeのベストプラクティス集です。(skills.shで見つけました。)
Claudeに直接参照させることで、実装の品質がかなり安定しました。

skills.shは、さまざまな技術スタック向けのスキルセットが整理されていて、Claudeに参照させる知識ベースを探すのにとても便利なのでオススメです。

https://skills.sh/

Step 2: GitHub MCPで IssueからPR作成までを全自動化する

ここが爆速化の最大のポイントです。

GitHub MCPとは

MCP（Model Context Protocol）は、ClaudeにGitHubなどの外部ツールを直接操作させるための仕組みです。

導入方法については、ymtdirさんの以下の記事がとても分かりやすいので、ぜひ参考にしてみてください。
https://qiita.com/ymtdir/items/4d17b5ebac0b025eb825

GitHub MCPを設定すると、Claude Codeは単なるコード生成ツールではなく、実際にリポジトリを操作できる存在になります。

具体的には、

  • GitHub APIを通じてIssueを作成する
  • ブランチを作成する
  • Pull Requestを作成する
  • IssueやPRにコメントする

といった操作が可能になります。

つまり、設計から実装、レビュー準備まで、開発フローの大部分をClaudeに一任できるようになります。

ここで効いてくるのがGIT_WORKFLOW.mdです。
あらかじめブランチ戦略やPRルールを明文化しておくことで、Claudeはその前提に従って一貫した運用を行えます。

実際に、「HomeScreen.tsxの文字色を赤に変更するIssueを作成して、PRまで出して」と依頼してみました。

結果は以下のような形です。
Issue

PR

Issueの作成からブランチ作成、実装、PR提出までを一貫して実行してくれました。
単にAIに実装だけ任せるのではなく、ワークフローそのものを委譲できる状態にするのが爆速化のポイントです。

Claudeにやらせてはいけないこと

ここまで爆速化の話をしてきましたが、「全部任せる」のが正解ではありません。
明確に線を引いている領域があります。

1. 本番環境への最終デプロイ判断
CI/CDの自動化はOK。ただし、本番に出す最終判断は人間が行います。

2. 破壊的なGit操作
git push --force や main/master への直接pushは禁止。
これは CLAUDE.md に明示しています。

3. セキュリティ関連の実装の丸投げ
認証・課金・個人情報まわりは必ず自分でレビューします。

4. 曖昧な大規模リファクタ
「全体的にきれいにして」はNG。
変更範囲は必ず明示します。

ただ単に「全部任せる」ことはせず、任せる領域を設計することも大事になってきます。

実際に体感した生産性の変化

Before（Claude Code導入前）

  • 新機能1つ：2〜3時間
  • バグ修正：30分〜1時間
  • ブランチ作成〜PR提出：15〜20分

After（CLAUDE.md + ai/rules + MCP整備後）

  • 新機能1つ：30〜60分（自分は指示と最終確認が中心）
  • バグ修正：5〜15分
  • ブランチ作成〜PR提出：ほぼ0分（Claudeが一貫して実行）

体感では、実装スピードが3〜5倍ほどに上がりました。

ただし、これは単にClaudeを使ったからではありません。

最初に CLAUDE.mdやai/rulesを設計するのに、2〜3時間ほどしっかり時間をかけています。
その初期投資があったからこそ、以降の開発で何度も回収できるようになりました。

感覚的には、環境整備にかけた数時間が、後々何十倍にもなって返ってくるというイメージです。

まとめ

Claude Codeで個人開発を爆速化するために、私が実践したことをまとめると

やること 効果
CLAUDE.md に思想・原則を書く 毎回の説明が不要になる
ai/rules/ で役割ごとにルールを分割 コンテキストを節約でき、保守もしやすい
/init でアーキテクチャを理解させる 実装判断の精度が上がる
GitHub MCPで Issue→PR を自動化 Gitまわりのルーティンがほぼゼロに
Plan Firstを習慣化 手戻りが大幅に減る
lessons.md で自己改善させる 同じミスを繰り返さなくなる

やっていることはシンプルです。
AIにたくさん指示を出すのではなく、迷わない環境を整えること。
コードを貼って「直して」と頼むだけでは、AIの力をまだ一部しか引き出せていません。

CLAUDE.mdを1時間だけでも整備してみる。それだけで、その後の開発体験は確実に変わります。

爆速化の鍵は、プロンプトの工夫ではなく、環境設計にあります。

とはいえ、私自身もまだ試行錯誤の途中です。
もっと上手く任せられる部分もあるはずですし、改善の余地はたくさんあると感じています。

これからも少しずつアップデートしながら、AIと一緒に開発するスタイルを磨いていきたいと思います。

Discussion