Claude Code に「要点だけ頼む」と言っても、返ってくる文章が妙に長い。あれはツールが悪いというより、こちらが出力の型を渡していないことが多い。出力制約とか成果物の型を先に決めておくと、返答の長さはかなり扱いやすくなる。
雑に頼むと、Claude Code は親切に広げる。しかも、説明が増えるほどタスクは見失いやすい。ファイル整理でも文書作成でも同じで、「何をどの形で返すか」を先に縛ったほうが、あとで読む側が圧倒的に楽だ。筆者は以前、3 ファイルだけ確認したいのに、背景説明つきで長文を返され、結局自分で見直した。あれは地味にだるい。最初から形式を指定していれば済んだ話だった。
まず効くのは、指示文の頭で「長さ」と「形式」を固定することだ。たとえば、こんな頼み方にする。
次の条件で返答してください。
- 3項目だけ
- 各項目は1文
- 余計な前置きは不要
- 箇条書き以外は書かない
対象:
...
この手の制約は、単に短くさせるためだけのものではない。何を出力してほしいかの輪郭をはっきりさせるために入れる。Claude Code は、曖昧な依頼に対しては補足や説明を足しがちだ。だから「短くして」とだけ言うより、「3項目」「1行ずつ」「表にする」「JSONで返す」のように、成果物の型を先に渡したほうが強い。
開発寄りなら、形式をもっと機械的に縛っていい。
次の変更点を、必ずこの形式で返してください。
1. 変更ファイル名
2. 何を変えたかを1行
3. 注意点を1行
補足説明は禁止。
出力は最大6行。
文書作成なら、こういう縛りが効く。
次の文章を要約してください。
- 200字以内
- です・ます調にしない
- 箇条書きは2点まで
- 結論を先頭に置く
ファイル整理やディスク削減でも同じだ。たとえば「不要なものを見つけて」と丸投げすると、説明が長くなりやすい。代わりに「削除候補だけを表で」「サイズ順に上位10件だけ」「パスと理由だけ」と型を決める。
次の条件で整理候補を出してください。
- 出力は表
- 列は「パス」「理由」「削除してよいか」
- 上位5件だけ
- 推測で断定しない
ここで大事なのは、短くしたいから型を決めるのではないことだ。長い返答は、だいたい「何を省いていいか」が伝わっていないときに起きる。だから、先に出力の形を固定すると、Claude Code は迷わずに済む。こちらも読み飛ばしやすくなる。両方に効く。
ただし、型を細かくしすぎると逆に詰まる。以前、筆者は「各項目は必ず12文字以内」みたいな無茶な制約を入れて、かえって意味が壊れたことがある。長さを削ることが目的化すると、肝心の情報が死ぬ。制約は、読み手が欲しい粒度に合わせるのが筋だ。短ければいいわけではない。
もう一つ、長文化の原因として見落としやすいのが、依頼の中に「背景説明も欲しい」「理由も欲しい」「例も欲しい」が混ざっているケースだ。これを全部のせにすると、当然長くなる。だから、最初にどれを捨てるかを決める。
次の優先順位で出してください。
1. 結論
2. 手順
3. 補足は不要
あるいは、こう切る。
今回は概要だけ返してください。理由や補足は不要です。
この切り方は、非エンジニアの作業でもかなり使える。たとえば契約書の下書き、案内文、社内メモ、議事録の整形では、「全文説明」より「1分で読める形」が先だ。Claude Code に最初からその前提を渡せば、出力が暴れにくい。
少し進めるなら、最初の指示で「禁止事項」も決めるといい。長い返答は、余計な気配りが混ざっていることが多いからだ。
次のルールで返してください。
- 前置き禁止
- 定義の説明禁止
- 例は1つだけ
- 最後に要点を1行で再掲
このやり方は、返答の長さだけでなく、後から読み返すときの見通しも良くする。出力の形を先に固定する、ただそれだけで作業のストレスはかなり減る。Claude Code を使う場面がコード修正でも、フォルダ整理でも、文章の圧縮でも、この考え方はそのまま通る。
迷ったら、こう覚えておけばいい。内容を細かく詰める前に、まず器を決める。長文を嫌うなら、先に型を渡す。Claude Code は、その器の中でちゃんと働く。