2026-09-21 追記: 記事を見直しました
- 実測値や効果の記述に、観測の範囲（私の環境・計測方法）を明記しました
- 示した根拠の範囲を超えていた断定表現を、事実に合わせて弱めました
内容の骨子は変えていません。
個人開発の最大の敵は「時間」です。本業が終わって帰宅し、可処分時間は1日2〜3時間。この限られた時間で設計・実装・テスト・デバッグ・ドキュメントを全部やるのは、正直しんどい。
私はClaude Code（AnthropicのAIエージェントCLI）を個人開発に導入してから、体感で開発速度が3倍 になりました。魔法ではなく、「AIに仕事を任せるための設定」をきちんとやった結果です。
この記事では、実際に効果が大きかった 5つの設定 を、数字とコード付きで紹介します。
前提: 個人開発者がClaude Codeで詰まるポイント
Claude Codeをインストールして「コード書いて」と指示するだけでは、思ったほど速くなりません。私も最初はそうでした。毎回プロジェクトの前提を説明し直す、コードのスタイルがバラバラ、テストも書いてくれない——逆に手間が増えた時期すらありました。
転機は「AIへの指示を構造化する」と決めてからです。以下の5つを設定したことで、開発フローが一変しました。
設定1: CLAUDE.mdを「AIへの引き継ぎ書」として書く
Claude Codeは、プロジェクトルートに置いた CLAUDE.md をセッション開始時に自動で読みます。ここに 技術スタック・コーディング規約・ディレクトリ構成・禁止事項 を書いておくと、毎回の前提説明が不要になります。
# CLAUDE.md（例: 個人開発プロジェクト）
## Tech Stack
- Frontend: React 18 + TypeScript + Vite
- Backend: Node.js + Express + Prisma
- DB: PostgreSQL 15
- Test: Vitest + React Testing Library
## Coding Rules
- 変数名は camelCase、コンポーネントは PascalCase
- 関数は50行以内。超える場合は分割する
- console.log はデバッグ後に必ず削除
- any 型は禁止。型定義を必ず書く
## Directory Structure
src/
├── components/ # UIコンポーネント
├── hooks/ # カスタムフック
├── api/ # APIクライアント
├── types/ # 型定義
└── utils/ # ユーティリティ
以前は新しいセッションを開くたびに「このプロジェクトはReact + TypeScriptで……」と5〜10分かけて説明していました。CLAUDE.mdを置いてからは 1日あたり約30分の時間を削減 できています。人間の新人エンジニアに渡す「プロジェクト概要書」と同じ感覚で書くのがコツです。
ハマりポイント: CLAUDE.mdの肥大化
ただし、ルールを追記し続けると CLAUDE.md が肥大化して逆効果になります。私の場合、500行を超えた時点でClaude Codeの応答が遅くなり、指示の遵守率も落ちました。
解決策は 階層化 です。ルートの CLAUDE.md には方針だけ書き、詳細はサブディレクトリの CLAUDE.md に分けます。サブディレクトリの CLAUDE.md はルートと同時に一括ロードされるわけではなく、Claude Codeがそのディレクトリ配下のファイルを扱うタイミングでオンデマンドに読み込まれる仕組みです。この特性のおかげで、常に必要なわけではない詳細ルールをルートから追い出せます。
project/
├── CLAUDE.md # 全体方針（50行以内）
├── src/
│ └── CLAUDE.md # コーディング規約の詳細
└── tests/
└── CLAUDE.md # テストの書き方
この分割で 応答速度が体感1.5倍に改善（あくまで体感の参考値で、厳密な計測ではありません）し、コーディング規約違反も減りました。CLAUDE.mdにも情報設計が要るということです。
設定2: テスト自動生成をCLAUDE.mdに組み込む
個人開発でテストを書く人は少数派でしょう。時間が足りないから後回しにして、結果的に「動いてるけどテストがない」コードが積み上がる。
私はClaude Codeにテスト生成を任せるようにしました。あるプロジェクトでは約50本のAPIエンドポイントにテストがない状態でしたが、CLAUDE.mdにテストの命名規約とアサーション方針を書いた上でClaude Codeに生成を指示したところ、3日で約200本のテストケースを生成 できました。うち 85%はそのまま通り、残り15%は軽微な修正で対応できています。
CLAUDE.mdに追記する例:
## Test Policy
- テスト命名: `describe('対象') > it('should 期待する振る舞い')`
- 正常系・異常系・境界値の3パターンは必須
- モックは最小限に。DBはテスト用コンテナを使う
- カバレッジ80%を目標とする
手動で書けば2週間（稼働日換算で10日）かかる見積もりでした。実際は3日で完了したので、工数は約70%削減（暦日換算では約79%）できた計算です。個人開発で2週間をテストに費やす余裕はありません。AIに生成させれば、私はビジネスロジックの境界値テストだけ補完すればよくなります。
設定3: レガシーコードのリファクタリングを段階的に任せる
個人開発を長くやっていると、過去の自分が書いた「動いているが触りたくないコード」が必ず溜まります。
以前携わったプロジェクトには、8年前に書かれた約1万行のPHPコードがありました。関数が500行を超えるものもあり、手動リファクタリングは怖くて手が出せませんでした。
Claude Codeに任せたアプローチは以下の通りです:
- 構造分析 — まず既存コードの依存関係マップを作成させる
- 関数分割 — 500行関数を50行以内の小関数に分割
- クラス化 — 関連する関数をクラスにまとめる
- 各段階でテスト実行 — リグレッションを即検出
結果、約1万行のコードが3,500行に圧縮 されました。既存テストはすべてパスしています。
ポイントは「一気にやらない」ことです。Claude Codeに「全部リファクタリングして」と投げると事故ります。ステップを区切って、各段階でテストを回す。人間が怖がる「動いているコードに触る」作業を、AIは淡々とやってくれます。
設定4: ハルシネーション対策をCLAUDE.mdに仕込む
Claude Codeが生成したコードに、存在しないライブラリのメソッドが含まれていたことがあります。そのまま動かしてエラー、原因調査に30分——という無駄が何度かありました。
対策として、CLAUDE.mdに以下のルールを追加しました:
## LLM Safety Rules
- 外部ライブラリのメソッドを使う場合は、公式ドキュメントのURLを添えること
- 不確かなAPIは使用前に確認を求めること
- コード生成後は必ずテストを実行すること
さらに、Claude Code の Hooks機能 で、Edit/Writeツールによるファイル変更のあとにリンターとテストを自動実行する設定を .claude/settings.json に入れました。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npm run lint && npm test"
}
]
}
]
}
}
PostToolUseのmatcherをEdit|Writeにしているため、これらのツール経由の変更だけが対象です。Bash経由（sed -iやスクリプト実行など）でのファイル変更はこの設定では捕捉できないので、「ファイル変更時」ではなく「Edit/Writeツールでの変更時」が正確な表現です。
この2段構えで ハルシネーション由来のエラーが月10件から2件に減少 しています。LLMの出力は「信頼するが検証する」が鉄則。自動でlint/testを実行する設定を入れておけば、手動でテストコマンドを起動する手間は減らせますが、テストの実行時間や失敗原因の調査コストがゼロになるわけではありません。
設定5: AIを「壁打ち相手」にする設計レビュー
個人開発の最大の弱点は レビュー相手がいない ことです。一人で設計すると盲点が必ずあります。
私は設計書を書いたあと、Claude Codeに「経験20年のシニアアーキテクトとして、この設計の問題点を指摘して」と依頼しています。非機能要件（スケーラビリティ・障害耐性）の観点も指定します。
ある新機能の設計レビューで、5つの改善提案を受けました。そのうち 2つは本番障害につながる可能性のある重大な設計リスク で、実装前に修正できました。
また、同じくClaude Codeにコードレビューを任せています。ここでのコツは 重要度レベルの分類基準をFew-shot例で渡す ことです。
## Code Review Levels
- **Critical**: セキュリティ脆弱性、データ損失の可能性、本番障害のリスク
例: SQLインジェクション、未バリデーションの入力値
- **Warning**: パフォーマンス問題、保守性の低下
例: N+1クエリ、500行超の関数
- **Info**: スタイル、命名、コメント
例: camelCase違反、不要なコメント
この例を渡してからは、私が確認したレビュー対象の範囲では重要度の分類が安定するようになり、レビュー結果の確認時間が半分に短縮されました（網羅的にCriticalを検出できると保証するものではありません）。
「3倍速」の内訳
5つの設定による時間削減を整理します。
| 設定 | 削減効果 | 具体的な数字 |
|---|---|---|
| CLAUDE.md設計 | 前提説明の省略 | 1日30分削減 |
| テスト自動生成 | テスト工数の約70%削減（稼働日換算） | 2週間→3日／生成200ケース中85%は無修正で通過 |
| リファクタリング | 怖くて手が出ないコードを処理 | 1万行→3,500行 |
| ハルシネーション対策 | 無駄なデバッグ削減 | 月10件→2件のエラー |
| 設計レビュー | レビュー相手の確保 | 本番障害につながりうる設計リスク2件を実装前に修正 |
個人開発の可処分時間が1日2〜3時間だとすると、前提説明だけで30分消えるのは致命的です。テストやリファクタリングを先送りにしているのは「時間がない」からであって、AIが代行してくれるなら話が変わります。
開発速度が3倍になった というのは、「今まで3日かかっていた作業が1日で終わる」感覚です。特にテスト生成とリファクタリングの効果が大きく、個人開発でもコード品質を維持できるようになりました。
まとめ: CLAUDE.mdが個人開発の生産性を決める
Claude Codeは「入れるだけ」では速くなりません。CLAUDE.mdにルールを書き、テスト方針を決め、安全装置を入れる——この初期設定にかける1〜2時間が、その後の何十時間を節約します。
個人開発は一人だからこそ、AIを「もう一人のチームメンバー」として機能させる設計が効きます。まずは CLAUDE.md を50行書くところから始めてみてください。
この記事が参考になったら、いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。
フォロー しておくと新着が届きます。
みなさんは個人開発でAIツールをどう活用していますか？ 「こういう使い方が効いた」「逆にうまくいかなかった」など、ぜひコメントで教えてください。