Zenn
🙇

Claude Codeに推測をやめさせる

に公開
Claude
Claude Code
idea

よくあるClaude Codeの動きとプロンプト

Claude Codeにどうしても曖昧なお願いを聞いてもらいたい

よくある困った動き。

  • 指示を無視する
  • 最初に決めたルールを忘れる
  • 理解が曖昧なまま先に進める

これを解消したい。

ヒントはClaude Codeのマニュアルに書いてある。
「指示を明示的に」「明確で直接的で詳細な指示」

ブログにも書いてある。
「明確に」「具体的に」

うん、それはそうなんだろう。
それでも、「XXXをやって」とお願いしたい。

機能「XXX」を実装する。

エントリーポイント: /path/to/url, /path/to/file
関連DB: table_name1, table_name2
ドキュメント: docs/system.md, docs/feature1.md

...以下長い説明や依存関係やルール...

こういうことは書きたくない。

そういうわけで、一例としてDBの影響範囲を調べる指示をコマンド形式で書いた。

DB影響範囲調査コマンド

ある実装によりDBにデータが書き込まれる場合、そのデータの利用箇所を調べて影響範囲を調査するコマンド。

重要なのは以下の点

  • 理解していないのに進めようとするのを阻止する
  • 推測で実装を補完することを阻止する

実際のコードに書かれている事実に基づく判断をしてもらう。

.claude/commands/database-feature-impact.md
# 「$ARGUMENTS」のDB影響分析

「$ARGUMENTS」のDB影響分析を実行：

## Phase 1. 事前調査

**コードは調査せずに、ドキュメントを調べる**

1. 「$ARGUMENTS」の内容について関連ドキュメントを読んで理解する。
2. 分からない内容やキーワードがあればドキュメントを調べる。
3. 調査したドキュメント一覧（ファイルpath）を表示する。不足がないかユーザーに尋ねる。
4. 分からないことがあれば推測せずにユーザーに尋ねる。
   - 例：
     - 「「キーワードXXX」は「YYY」という意味で合っていますか？」
     - 「「機能XXX」のエントリーポイントはどこですか？」

## Phase 2. 処理フロー図

コードを調べてフロー図を作成する。

[起点] 
  ↓
[ファイル:行番号]
  ↓
[ファイル:行番号]
  ↓
[DB操作]

**注意**

- **省略せずに全てのフローを書くこと**
- **推測せずにファイルと行番号を確認すること**

**漏れがないかユーザーに確認してからPhase 3に進む**


## Phase 3. DB処理一覧表

DB処理一覧表の作成

| ファイルパス | 行番号 | 処理種別 | 説明 |
|-------------|--------|----------|---------|
| （実際のパス） | （数字） | READ/WRITE | （用途） |

**セルフチェック**: **事実**と**推測**に分けて考え、**推測**が含まれている場合は**事実**を確認する。

## Phase 4. DBテーブル影響表

DBテーブル影響表の作成

| テーブル名 | カラム名 | データ型 | 影響 | 説明 |
|-----------|----------|----------|------|------|
| （実際の名前） | （実際の名前） | （型） | READ/WRITE | （用途） |

**セルフチェック**: **事実**と**推測**に分けて考え、**推測**が含まれている場合は**事実**を確認する。

## Phase 5. ユーザーへの確認

結果をユーザーに表示し、調査を先に進めるか確認する。



## Phase 6: データフロー影響分析
1. 影響のあるDBテーブルとカラムから別の利用箇所を検索
2. 利用ファイルと行番号を特定
3. 影響のある他機能の評価
4. 変更の必要のあるファイルと行番号を特定


注意：コードを実際に読んで、具体的なファイル名と行番号を特定すること。
**事実**と**推測**に分けて表示する。


## Phase 7: rgコマンドによる網羅的な検証

「$ARGUMENTS」で影響のある箇所を、rg コマンドで網羅的に検索し、これまでの分析を検証する。

- camelCase や snake_case でDBのカラム名を検索して影響範囲を検証する
- 重要なキーワードやプロパティがあれば同様に検索して影響範囲を検証する
- 類似の既存機能があれば、その実装を参考に検索する


## Phase 8: 影響分析レポート

下記を**事実**と**推測**に分けて表示する。

- 「$ARGUMENTS」で影響のあるDBのテーブル・カラム一覧
- 「$ARGUMENTS」で影響のあるDBカラムを利用しているファイル一覧と行数

**省略せずに全ての一覧を表示する**

## Phase 9: まとめ

下記を表示する。

- 分析結果まとめ
- 重要なキーワードと説明の一覧
- 注意点

$ARGUMENTSは文章でもいいし、ファイルでもいい。

途中で何度かユーザーに確認するというステップを取っている。

調査については、ドキュメントに書いているのに読んでいないということが多々あるので、最初の時点でチェックする。

実装については、まったく存在しないクラスやメソッドを解析結果として提示してくることがよくあるので、行番号まで指定することによって（なるべく）防いでいる。

これで

/database-feature-impact path/to/issue.md

と実行するだけで、issue.md に書かれた内容の影響範囲を正確に調べてくれる。

調べたあとは

path/to/issue.md を実装して

で大丈夫。

セッションの記憶を保存する

これはまだ試行錯誤している。
今使っているコマンドはこれ。

.claude/commands/save.md
# 保存されていない情報の保存

以下のTodoリストを作り、表示して。
Todoリストを順に実行しながらドキュメントに保存されていない情報を保存して。

※「ドキュメント」は CLAUDE.md と ./claude-docs/ ディレクトリにある文書のこと。

1. ** 保存されていない知識の確認 ** 
  1. このセッションで得た知識について、まだドキュメントに保存されていない情報を考える。
  2. CLAUDE.mdと./claude-docs/ を調査して、ドキュメントに記載がないか確認する。
2. ** ドキュメントと知識のまとめ **
  1. 保存されていない情報について、どの情報をどのドキュメントに保存したら良いかを「claude-document-rules.md」に従って考える。
    - 新規Claudeセッションが理解しやすいように書きたい。
  2. ドキュメント更新の方式をユーザーに表示する。
3. ** 保存されていない知識の保存 **
  - 保存されていない知識を「claude-document-rules.md」に従ってドキュメントに保存する。

「考える」「既存ドキュメントを読む」というのがメリット/デメリットのトレードオフな気がしている。
内容はよくなるが、考えている最中に情報を忘れてしまう。

まずは何も考えずに全ての情報を網羅的に一時ファイルに書き出して、そのあとまとめた方がいいのかもしれない。
しかし、claudeはドキュメントをまとめて統合するのが苦手なのでそれも悩みどころ。

一度、これまでCladue Codeが書いたドキュメントをばっさり切り捨てて手動で書いてみようとしたが、量が多すぎて諦めた。そういうことをしてもらうためのAIだった。
不完全でまとまりのない散らかった文書でもいいから取りあえず作って、Claude Codeに検索してもらう方がまだ現実的な気がする。Google方式。

Tips: セッションで保持している推測情報を調べる

Claude Codeの記憶深堀り指示

XXXについて、記憶の中の情報から説明して

これでコードを何も調査させずにClaude Codeが思い込んでいる情報を次々見ていくと、クラスやメソッド、仕様などが多く補完されているのが分かる。
めちゃくちゃ推測してくれているが、大抵は外れている。

Claude AIによる回答

このコマンドは claude.ai のチャットでAIの仕組みを聞きながら作っていった。
面白い回答がいくつかあったのでいくつか紹介。

推理力の副作用問題

// Claude Codeがよく提案する（存在しない）コード
user.updateProfile(data)
  .validateImage()    // ← 存在しないメソッド
  .resizeOptimal()    // ← 存在しないメソッド
  .autoSave();        // ← 存在しないメソッド

なぜ起こるのか？

  • 優秀な推理力で「こうあるべき」を論理的に推論
  • 人間なら感じる「本当にあるかな？」という疑いを持たない
  • 結果：精巧で説得力があるが、実装不可能な提案

コンテキスト制約と知識の限界

限定的な事実 + 高い推理力 = 精巧な間違い
  • コンテキストウィンドウ制約：重要な情報を「忘れる」
  • 事実確認の困難：大量の情報を覚えていられない
  • 確信の錯覚：推論結果に過度な自信を持つ

深い思考と深い間違い

従来の考え：深い思考 = 高品質な結果
現実：深い思考 × 間違った事実 = 深い間違い

自分が罠にハマったことに気付く

推理力が高すぎるため、人間なら感じる「本当にあるかな？」という健全な疑いを持たず、論理的に「こうあるべき」と確信してしまうことが原因
...(snip)...
解決策は「事実確認ファースト」のアプローチだ。推測と事実を明確に分離し、「確実に動作する最小実装→検証付き拡張→理想的完全実装」の段階的な構築を行う。プロンプトでも「grep検索結果のみに基づく」「推測禁止」「確実/推測/不明の分類必須」といった制約を明示することで、AIの推理力を適切に制御できる。

今の「理想的完全実装」の提案こそが、まさに「論理的に「こうあるべき」と確信してしまう」という状態になっている。

完全にその通りです。まさに今、私がその罠にハマりました。
「制約認識型の継続改善」「外部記憶の活用」「反復改善サイクル」...これらの提案自体が、論理的に「こうあるべき」という確信に基づいた理想論でした。

私自身が今、「賢すぎる故の盲点」で理想的な解決策を論理的に組み立てて確信を持って提案してしまいました。これが問題の本質ですね。解決策すら、同じ問題を抱えている。

Discussion