Claude Codeを半年使って、「やってはいけない使い方」がわかってきた話

はじめに

2024年末からClaude Codeを本格的に使い始めて、約半年が経ちました。

この間、個人開発で宅建試験のAI対策アプリ（takkenai.jp）を開発しており、1250問以上の問題データの管理、Next.jsでのフロントエンド、Supabaseでのバックエンドなど、ほぼすべての開発工程でClaude Codeを活用してきました。

最初の頃は「すごい、何でもできる」と感動していたのですが、半年使い続けると明確にやってはいけないパターンが見えてきます。

この記事では、僕が実際にやらかした5つのアンチパターンと、そこから学んだ正しい使い方をまとめます。同じ轍を踏む人が一人でも減れば幸いです。

アンチパターン1: コンテキストを説明せずにいきなりコードを投げる

やらかしたエピソード

開発初期、問題データのバリデーション処理にバグがあったとき、僕はこんな感じでClaude Codeに投げていました。

# ❌ 悪い例
このコードがバグってるので直して

export const validateQuestion = (q: Question) => {
  return q.choices.length === 4 && q.answer <= 4
}

返ってきた修正は「動く」のですが、うちのアプリの仕様とまったく合っていないものでした。当然です。Question型の定義も、answerが0始まりなのか1始まりなのかも、何も伝えていないのですから。

Claude Codeは賢いので「それっぽい修正」を返してくれます。でもそれが一番厄介で、一見正しそうなのに仕様に合っていないコードがいちばんデバッグに時間がかかります。

正しい使い方

# ✅ 良い例
## 背景
宅建試験対策アプリで、問題データのバリデーション処理を修正したい。

## 現在の仕様
- Question型: { id: string, text: string, choices: string[], answer: number, category: string }
- answerは0始まりのインデックス（0〜3）
- choicesは必ず4択
- categoryは"権利関係" | "宅建業法" | "法令上の制限" | "税・その他"の4種

## 問題
answer が 0〜3 の範囲外でもバリデーションを通過してしまう。
categoryの検証も抜けている。

## 期待する動作
不正なデータの場合、具体的なエラーメッセージとともにfalseを返したい。

たった2分のコンテキスト説明で、手戻り30分を防げます。 これは半年間で最も再現性高く実感したことです。

アンチパターン2: 長いセッションを続けすぎてコンテキストが劣化する

やらかしたエピソード

ある日、問題のインポート機能を作りながら、同じセッションでUIの修正、API設計、データベースのマイグレーションまで一気にやろうとしました。3時間くらいの長いセッションです。

途中から明らかにおかしくなりました。序盤に伝えた型定義を忘れる。さっき決めたAPI設計と矛盾するコードを生成する。 同じ修正を2回提案してくる。

セッション後半で生成されたマイグレーションファイルは、序盤に作ったテーブル定義と整合性が取れておらず、本番環境に適用する前に気づいたから良かったものの、冷や汗をかきました。

正しい使い方

今は1セッション = 1タスクを徹底しています。

# ✅ セッションの区切り方（僕のルール）

セッション1: 問題インポート機能のAPI設計 → 完了・コミット
セッション2: インポートAPIの実装 → 完了・コミット
セッション3: インポート画面のUI実装 → 完了・コミット

新しいセッションを始めるとき、前のセッションの成果物を簡潔にまとめて渡します。面倒に見えますが、「コンテキストの劣化したAIに修正させる → おかしくなる → さらに修正させる」の負のループに比べたら圧倒的に速いです。

CLAUDE.mdにプロジェクトの基本情報を書いておくと、セッション開始時の立ち上がりがかなり速くなります。これは本当におすすめです。

アンチパターン3: 「なんかいい感じに直して」系の曖昧な指示

やらかしたエピソード

問題一覧画面のパフォーマンスが悪かったとき、こう投げました。

# ❌ 悪い例
問題一覧ページが重いからパフォーマンス改善して

Claude Codeは素直に「改善」してくれました。仮想スクロールの導入、React.memoの追加、useMemoでの最適化……。技術的には正しいのですが、実際のボトルネックはAPIレスポンスが遅いことで、フロント側の最適化はほぼ効果がなかったのです。

1時間かけてフロントを最適化した後に「全然速くならないな」と気づいて、DevToolsのNetworkタブを見て愕然としました。

正しい使い方

# ✅ 良い例
## 問題
問題一覧ページ(/questions)の初期表示が遅い（体感3秒以上）

## 計測結果
- API /api/questions のレスポンス: 2.8秒
- 1250件の問題データを全件取得している
- フロント側のレンダリングは200ms程度

## 制約
- Supabaseを使用（PostgreSQL）
- 現在ページネーションなし

## やりたいこと
APIレスポンスを500ms以内にしたい。
カーソルベースのページネーション導入を検討しているが、他に良い方法があれば提案してほしい。

曖昧な指示は曖昧な結果を生みます。「何が問題で」「どこがボトルネックで」「どうなってほしいのか」を自分の言葉で言語化する。 その言語化の過程で、自分自身が問題を理解できるという副次効果もあります。

アンチパターン4: 生成されたコードをレビューせずにそのままコミット

やらかしたエピソード

これは一番恥ずかしいやらかしです。

問題の正答率を計算するユーティリティ関数をClaude Codeに書いてもらい、動作確認もそこそこにコミット&デプロイしました。数日後、ユーザーさん（テスターとして手伝ってくれていた友人）から「正答率が100%を超えてるんだけど」と連絡が。

原因は単純で、同じ問題を複数回正解したときに正解数が重複カウントされる実装になっていました。Claude Codeが生成したコードは「一見正しいロジック」に見えるので、つい信頼してしまったのです。

// ❌ Claude Codeが生成した（バグのある）コード
const correctRate = (answers: Answer[]) => {
  const correct = answers.filter(a => a.isCorrect).length
  const total = answers.length
  return Math.round((correct / total) * 100)
}
// → 同じ問題に3回正解すると、正解数3としてカウントされる

正しい使い方

今は生成されたコードに対して、Claude Code自身にレビューを依頼するワークフローにしています。

# ✅ レビュー依頼の例
さっき生成したcorrectRate関数をレビューしてほしい。

特に以下の観点で:
- 同じ問題を複数回解いた場合の処理は正しいか？
- 0除算のケースは考慮されているか？
- 問題数が0のときの戻り値は何が適切か？

これだけで、Claude Code自身がバグに気づいてくれることが大半です。生成とレビューを別のステップとして明示的に分けるのがポイントです。人間のコードレビューと同じ発想ですね。

アンチパターン5: テストなしで複数ファイルの大規模変更をさせる

やらかしたエピソード

問題カテゴリの分類体系を変更したとき、「関連ファイルを全部一括で変更して」とClaude Codeに頼みました。型定義、API、フロントのフィルタリング、Seedデータ、バリデーション……十数ファイルにまたがる変更です。

結果、8割は正しく変更されていたのですが、残り2割がサイレントに壊れていました。 特にSeedデータの旧カテゴリ名が残っていたのに気づいたのは1週間後。テストもなかったので、壊れたことに気づくのが遅れました。

正しい使い方

今は大規模変更の前に、まずテストを書いてもらうようにしています。

# ✅ 良い例（段階的アプローチ）

## Step 1: まず現状の動作を確認するテストを書いて
問題カテゴリのフィルタリング処理について、
現在の動作を保証するテストを書いてほしい。

## Step 2: テストが通ることを確認

## Step 3: カテゴリ体系を変更して（変更内容の詳細を記載）
テストの期待値も新しいカテゴリに更新してから、
実装を変更して全テストが通るようにして。

## Step 4: 変更差分を確認してコミット

テストがあると、Claude Codeの変更が正しいかどうかを機械的に検証できます。 当たり前のことなのですが、AIの生成速度が速いと「テスト書く時間がもったいない」と感じてスキップしがちなんですよね。半年かけて、これが最も高くつくショートカットだと学びました。

半年使って思うこと

Claude Codeは間違いなく生産性を爆上げしてくれるツールです。でもそれは正しく使えばの話であって、使い方を間違えると「速いスピードで間違った方向に進む」ことになります。

5つのアンチパターンに共通するのは、結局**「人間側の責任を放棄している」**ということです。

コンテキストを伝えるのは人間の責任
セッションを管理するのは人間の責任
要件を明確にするのは人間の責任
コードの品質を保証するのは人間の責任
テスト戦略を決めるのは人間の責任

Claude Codeは優秀な「ジュニアエンジニア」だと思っています。背景を丁寧に伝えれば驚くほどいい仕事をしてくれるけど、丸投げすると予想外の方向に走っていく。マネジメントの質が、そのままアウトプットの質になります。

おわりに

この半年、Claude Codeのおかげでtakkenai.jpを個人で開発・運用できています。1250問以上の宅建試験対策問題をAIで学習できるアプリで、問題のインポート、カテゴリ管理、正答率の分析など、ほぼすべての機能開発にClaude Codeが関わっています。

一人で開発していると「相談相手」がいないのが辛いのですが、Claude Codeは壁打ち相手としても優秀です。ただし、壁打ち相手が何でも「いいですね！」と言ってくれる相手だからこそ、自分自身の判断力を鈍らせないことが大事だと、半年かけて実感しています。

この記事が、Claude Codeを使い始めた方、あるいはこれから使おうとしている方の参考になれば嬉しいです。