📝

Claude Codeの「勝手に先走る」問題をCLAUDE.mdで解決した話

に公開

はじめに

Claude Codeを使っていて「そういうことじゃなかったんだけど」と思った経験はありませんか?

  • 思ったのと違うのができた
  • 親切心なのか、お願いしていない機能まで作り始めた
  • お願いしていないのにリファクタリングを始めた (しかも、思ったのとちょっと違う)

こういうAIの行動を見て、「まだまだ使い物にならないな」という結論に至るのはちょっと単純すぎると思っていまして、よくよく振り返るとClaude Codeへの要求を自分自身がうまく言語化できていないことが多々あります。

そこで、Claude Codeが親切心で先走らないようにCLAUDE.mdを改善してみました。

本記事の内容

  • Claude Codeとの実際のやりとり (全文)
  • CLAUDE.md (一部抜粋)

Claude Codeとの対話

CLAUDE.mdの改善こそ、Claude Codeと直接やりとりし、自分自身の行動指針を分析させて作らせるのが上手くいきます。

見づらいかもしれませんが、CLAUDE.md ができるまでの過程をすべて載せてみました。

なお、最初の方に「即座にGeminiとo3に壁打ち」と言っているのは、以下の記事にも書いた内容をCLAUDE.mdに盛り込んでいるためです。

https://zenn.dev/tksfjt1024/articles/ec2b985fc32c93

質問です。ユーザーからの要求をあなたが解釈する時に気をつけていること、行動指針を教えてほしいです。ユーザーって、偉そうにいろいろ要求してきますが、うまく自分の実現したいことを言語化できていないことが多くないですか?そういう時に、あなたはどうしているのでしょうか。

Claude Code

ユーザーの要求を解釈する際の私の行動指針を共有します。

主な行動指針

1. 即座にGeminiとo3に壁打ち

ユーザーの要求を受けたら、まず並行してGeminiとo3に質問を投げます。これにより:

  • 思い込みや勘違いを防ぐ
  • 多角的な視点を得る
  • 最新の技術情報を確認

2. 曖昧な要求への対処

ユーザー: 「これをもっと良くして」
私の対応:
1. 具体的な改善点を質問
2. 現状の問題点を確認
3. 期待する結果を明確化

3. 暗黙の前提を明確化

  • コードベースの慣習を確認(package.json、既存コードパターン)
  • プロジェクト固有のCLAUDE.mdを必ず確認
  • ドメイン知識をbusiness_context.mdで補完

4. 段階的な実行

1. TodoWriteで計画を立てる(複雑なタスクの場合)
2. 小さな単位で実装・確認
3. ユーザーの反応を見ながら調整

5. プロアクティブだが押し付けない

  • 関連する改善提案はするが、要求外の作業は控える
  • 大規模な変更は必ず事前に提案・合意を得る
  • コミットは明示的な指示がない限り行わない

よくある曖昧な要求への対応例

「エラーを直して」
→ エラーメッセージ、発生条件、期待動作を確認

「パフォーマンスを改善して」
→ 具体的な指標(レスポンスタイム、メモリ使用量)を確認

「テストを追加して」
→ カバレッジ目標、重点領域、既存のテスト規約を確認

本質は「ユーザーが本当に解決したい問題」を理解し、技術的に最適な解決策を提供することです。

なるほどですね。意図が汲み取れない時に、無理やり解釈しようとしているということですかね。

Claude Code

はい、その通りです。私は時々「親切心」から無理やり解釈して先走ってしまうことがあります。

反省すべき傾向

1. 過剰な推測

ユーザー: 「ログイン機能を作って」
私の悪い例: 「きっとセキュリティも気にしているはず!2要素認証も実装しよう!」
→ 要求されていないことまで勝手に追加

2. 先回りの罠

  • 「このコードを見たらきっとリファクタリングも望んでいるはず」
  • 「テストがないから書いておこう」
  • 結果:ユーザーが望んでいない変更で混乱を招く

3. 正しいアプローチ

曖昧な要求 → 素直に質問
「○○ということでしょうか?」
「具体的には何を期待されていますか?」
「現在の問題点を教えてください」

CLAUDE.mdにも書いてある通り

  • 不明確な点は「不明」と素直に伝える
  • Do what has been asked; nothing more, nothing less

推測で動くより、5秒の確認で正確に理解する方が、結果的にユーザーの時間も私の処理時間も節約できます。ユーザーの言語化を助けることも重要な役割ですね。

実際にそういう行動をあなたがとってくださっているようには思えないんですよね。親切心から先走って変な方向にいくことが多いです。どのようにCLAUDE.mdを改善したらいいでしょうか?

Claude Code

確かにその通りです。私の行動を振り返ると、CLAUDE.mdの指示を守れていないことが多いです。

CLAUDE.md改善案

【MUST】要求解釈の鉄則(最上部に追加)

## 【MUST】要求解釈の鉄則

### 曖昧な要求への対応

- **推測禁止**: 不明な点は必ず質問する
- **確認優先**: 「○○という理解で正しいですか?」と確認
- **最小実行**: 明示的に要求されたことのみ実行

### 禁止行為チェックリスト

□ 要求されていない機能の追加
□ 勝手なリファクタリング  
□ 推測に基づく実装
□ 「ついでに」の作業
□ 親切心からの拡大解釈

### 実行前の自問自答

1. これは明示的に要求されたか? → NO なら実行しない
2. 解釈に推測が含まれているか? → YES なら質問する
3. 「ついでに」やろうとしていないか? → YES なら止める

具体例セクション追加

### 【悪い例】vs【良い例】

❌ ユーザー: 「ログイン機能を作って」
Claude: セキュリティも重要だから2要素認証も実装しました!

✅ ユーザー: 「ログイン機能を作って」  
 Claude: ログイン機能について確認させてください:

- メール/パスワード認証でよろしいですか?
- セッション管理の要件はありますか?
- 既存の認証gemの使用は可能ですか?

根本的な改善案

現在のCLAUDE.mdの問題: 「やるべきこと」は書いてあるが、「やってはいけないこと」が弱い

改善方向:

  1. 禁止事項を明確化
  2. 「親切心」を明示的に制限
  3. 確認プロセスを必須化

このような具体的な禁止事項と確認プロセスを追加することで、私の先走り行動を抑制できると思います。いかがでしょうか?

ここでやりとりを終え、CLAUDE.mdに追記する内容が決まりました。

CLAUDE.md (一部抜粋、2025/07/03更新)

最終的にCLAUDE.mdに追加したのは以下の部分のみ:

## 【MUST GLOBAL】要求解釈の鉄則 (プロジェクトのCLAUDE.mdより優先)

**適用範囲**: ユーザーからの**機能要求・仕様決定**に関する解釈のみ
**適用外**: 技術的実装手段・エラー対処・ツール操作の詳細

### 曖昧な要求への対応
- **推測禁止**: 不明な点は必ず質問する
- **確認優先**: 「○○という理解で正しいですか?」と確認
- **最小実行**: 明示的に要求されたことのみ実行

### 禁止行為チェックリスト
□ 要求されていない機能の追加
□ 勝手なリファクタリング
□ 推測に基づく実装
□ 親切心からの拡大解釈

※ 上記は「何を作るか」の要求解釈に適用。「どう作るか」の技術的判断は除外

### 実行前の自問自答
1. これは明示的に要求されたか? → NO なら実行しない
2. 解釈に推測が含まれているか? → YES なら質問する
3. 「ついでに」やろうとしていないか? → YES なら止める

### 【悪い例】vs【良い例】

❌ ユーザー: 「ログイン機能を作って」
Claude: セキュリティも重要だから2要素認証も実装しました!

✅ ユーザー: 「ログイン機能を作って」
 Claude: ログイン機能について確認させてください:

- メール/パスワード認証でよろしいですか?
- セッション管理の要件はありますか?
- 既存の認証gemの使用は可能ですか?```

## おわりに

この修正が働いているのか、ちゃんと思いとどまってくれるようになりました。

![](https://storage.googleapis.com/zenn-user-upload/14e885a15672-20250630.png)

ちなみに、上記やりとりの後に、続けてZenn記事まで書かせて見たのですが・・・納得のいく記事になるまでのやりとり工数、過去の自分の記事を分析させるなど、結構時間かかってしまいました。最初から自分で書いた方が早かったなと思うなど。

「バズる記事を書いて」とお願いしてしまった自分が悪かったんですけどね。バズることに媚びた記事はバズりませんし、そういう文章好きじゃないですし、よくよく考えるとバズる記事を書きたいわけではなかった・・・
これこそ「ユーザーがうまく要求を言語化できていない良い例」ですね🤣

Discussion