「これ、何をしてほしいのか曖昧なまま投げているな」と思ったら、だいたい当たっている。Claude Code への依頼で一番もったいないのは、説明と修正を一度に混ぜることだ。読み解きと編集は別作業で、同じ呼びかけに押し込むと、返ってくる結果が中途半端になる。
たとえば「この Python スクリプトの処理を説明して、ついでに変数名も直して」と一息で頼むと、Claude Code は説明も修正もやろうとする。すると、説明は浅くなるか、修正は小さくなる。コンテキストも食うし、diff も散る。筆者は以前、文章校正を頼みながら「意図の説明も」と混ぜてしまい、返ってきた修正を見てから改めて説明を求める羽目になった。最初から分けていれば、やり取りは半分で済んだはずだ。
コツは単純で、依頼の粒度を揃えることだ。
「説明して」は理解の仕事、「直して」は変更の仕事。どちらか一方に寄せると、Claude Code の出力はかなり安定する。
たとえばコードを見せる場面なら、まずはこう分ける。
このスクリプトの処理の流れだけ説明して。
変更はしないで、箇条書きで要点を整理して。
そのあとで、修正を頼む。
今の説明を踏まえて、重複している処理を関数にまとめて。
動作は変えず、差分を最小にして。
文章ファイルでも同じだ。
「この議事録の要点を抜き出して」と「敬語を整えて読みやすくして」は、別の依頼として出したほうがいい。前者は要約で、後者は編集だ。混ぜると、要約が雑になるか、表現の修正が中途半端になる。ファイル整理でも同じで、「このフォルダに何があるか把握したい」と「不要ファイルを消したい」は分ける。先に把握して、次に消す。いきなり削除まで入れると、判断の根拠が薄くなる。
実務では、依頼文の先頭に役割を固定すると崩れにくい。
まず内容を説明して。変更は禁止。
次に、同じ対象を最小限の修正で直して。
最後に、修正理由を短く説明して。
この順にすると、Claude Code の返答も整理される。いきなり「説明と修正を両方やって」と言うより、作業のモードがはっきりするからだ。これは地味だが効く。曖昧な依頼は、出力も曖昧になる。そこを無理に押し切ると、あとで人間が読み直す時間が増える。
注意したいのは、「説明」と言いながら実はレビューを求めているケースだ。
「この設定ファイルを説明して」は理解の依頼だが、「この設定ファイルの問題点を説明して」は診断になる。ここに修正まで混ぜると、返答が散る。まず状態を読む、次に直す。順番を守ったほうが、結局早い。
筆者が一番やらかしたのは、長い Markdown 文書で「構成を説明して、冗長な部分も削って」と頼んだときだ。説明の段階で削るべき文の判定が入ってしまい、要点の把握がぼやけた。結局、先に構成だけ見せてもらって、削除は別で依頼し直した。あれは完全に依頼の粒度ミスだ。Claude Code が悪いのではなく、こっちが作業を混ぜすぎた。
粒度を揃えるもう一つの効用は、失敗したときに原因を切り分けやすいことだ。
説明が雑だったのか、修正が雑だったのか、両方を一緒に頼むと判別できない。分けておけば、「理解は合っていたが修正が足りない」「修正は合っていたが説明が浅い」と見える。ここが大事だ。AI とのやり取りは、完成品を一発で当てるゲームではない。問題の場所を素早く特定するほうが強い。
非エンジニアの用途でも同じで、むしろこちらのほうが効くことが多い。
たとえば、散らかった書類フォルダを整理したいなら、いきなり「削除候補を消して」ではなく、「このフォルダに何があるか分類して」と先に頼む。分類結果を見てから、「重複しているPDFをまとめて」「古い下書きだけ別フォルダに移して」と進める。説明と変更を混ぜないだけで、事故率がかなり下がる。
最後に、迷ったらこの雑な一文を避ければいい。
これを説明して、必要なら直して。
この「必要なら」がだるい。判断が相手任せになって、どこまでやるかがぶれる。代わりに、こう切る。
今は説明だけほしい。変更はしないで。
今は修正だけほしい。説明は最小限でいい。
この分け方を癖にすると、Claude Code の返答はかなり扱いやすくなる。説明は説明、修正は修正。混ぜない。たったこれだけで、やり取りの手戻りは目に見えて減る。