#claude-code-output-control

会話がぐだるのは、相手が悪いからではない。前提を言葉にしていないからだ。 Claude Code に頼みごとをするときも同じで、いきなり「これ直して」「整理して」「要約して」と投げると、返ってくるものが妙に広がる。修正対象が曖昧なまま進むので、途中で「いや、そうじゃない」と戻す羽目になる。これは開発でも文書作成でもファイル整理でも同じだ。先に前提を 1 行で置くだけで、会話の往復がかなり減る。筆者はこれをサボって、あとから手戻りして diff が膨らんだことが何度もある。地味にだるい。 ここで言う前提は、立派な仕様書ではない。現在地の明文化、前提の再確認、呼び方はいろいろあるが、要するに「今どこから始めるか」を 1 行で固定することだ。Claude Code は文脈を読んで進めるぶん、こちらが土台を曖昧にすると、広く解釈して広く返してくる。そこを最初に狭める。 たとえば、文章を直したいなら、いきなり「読みやすくして」ではなく、こう書く。 ```text この原稿は、技術に詳しくない人も読む想定です。専門用語は減らし、難しい語は言い換えてください。 ``` コードを直したいなら、前提を先

作業がだれる人は、始め方より終わり方が雑だ。これを決めずにClaude Codeを走らせると、修正がだらだら伸びる。diffは太り、指示はあいまいになり、最後の数回でいちばんコンテキストを食う。そこで先に「止まりどころを指定する」「出口条件を明示する」。要するに、どこで手を止めるかを先に決めておく話だ。 Claude Codeは、こちらが終点を渡すとかなり扱いやすい。逆に終点がないと、見た目は進んでいるのに、実は作業の輪郭がぼやけていく。ファイル整理でも文書作成でも同じで、「ここまでやったら終わり」を先に言うだけで、戻し作業が減る。 たとえば文書なら、こんな頼み方でいい。 ```text この下書きを、3段落だけ整えてください。 やることは以下に限定します。 文章の重複を減らす 箇条書きを2つまでにまとめる 結論は変えない 終わり方は「修正案を出した時点」で止めてください。 追加の案は出さなくていいです。 ``` ここで大事なのは、「何をやるか」だけでなく「どこで止まるか」まで書くことだ。Claude Codeは、うっかりすると親切に広げてくる。文面を整えるつもりが、構成の組み替えまで

Claude Code に雑に投げて、返ってきた返答が長すぎて読む気を失う。これ、かなりありがちな失敗だ。分量を絞る、短く要約させる、そういう指定を先に入れておかないと、こちらの意図よりも「丁寧さ」が勝ってしまい、出力がだらっと伸びる。 特に Claude Code は、説明を求めると親切に広げやすい。調べ物でも、文書作成でも、ファイル整理でも、返答が長いと次の判断が遅れる。だから「返答の長さに上限をかける」は、地味だが効く。要は、最初からゴールを狭く切るのだ。 たとえば、要点だけほしいなら、依頼文に最初からこう入れる。 ```text 以下を300字以内で答えてください。 結論を先に、細かい説明は不要です。 「このフォルダ内の重複ファイルをどう扱うべきか」 ``` もう少し実務寄りなら、こうだ。 ```text 次の内容を、箇条書き3点以内で短く要約してください。 各項目は1文まで。 余計な前置きは不要です。 ``` 長さを制御したいときは、単に「短くして」では弱い。Claude Code はそこを雑に受け取って、まだ長い返答を返すことがある。そこで、文字数、文数、箇条書き数、段落数

Claude Code で地味に効くのに、みんな後回しにするのがこれだ。 最初に「Markdown で返すのか、表で返すのか」を決めないまま投げると、あとで整形し直す羽目になる。内容は合っているのに、出力がバラけていてそのまま使えない。あれはかなりだるい。 たとえば議事録、ファイル一覧、比較表、手順書。どれも似ているようで、欲しい形は違う。ここを曖昧にすると、Claude Code はそれなりに頑張ってしまうが、こちらの用途には微妙に噛み合わない返答を返しやすい。逆に、先に形式を固定すると、同じ材料でもぐっと使いやすくなる。Markdown か表かを決める、出力形式を指定する。たったそれだけで、手戻りが減る。 いちばん簡単なのは、依頼文の最初に「出力形式」を書くことだ。Claude Code に作業を頼むとき、いきなり中身から入らない。まず箱を決める。 ```text 次の内容を、Markdown の見出しと箇条書きで返してください。 表にはしないでください。 対象: 契約書レビューのメモ 出力したい項目: 論点、気になる表現、確認先、次にやること ``` 逆に、一覧性が大事なら表を先

長文の依頼を一気に投げて、そのまま最後まで走らせる。これ、かなりの確率で手戻りになる。Claude Code は賢いが、会話が長くなるほど前提が散り、途中で「どの話を軸にしていたか」がぼやけるからだ。そこで効くのが途中要約、つまり前提の圧縮である。 要するに、長い会話の節目ごとに「ここまでの理解」を短く固定する。すると、指示の食い違いが減るし、後半で出る修正もだいぶ軽くなる。ファイル整理でも、文書作成でも、ディスク削減でも同じだ。最初の前提を詰めたつもりでも、会話が続くと細部が積もって、どこかでズレる。そこで一回、話を畳む。 たとえば、案件ごとの文書を整える場面を考える。最初に「このフォルダ内の重複ファイルを探して、不要なものを候補にして」と頼み、そのあとに「やっぱり契約書だけ対象にしたい」「ただし最終判断は人間がやる」と追加していく。ここで要約がないと、Claude Code の中では古い条件と新しい条件が混ざったまま残りやすい。筆者はこれで一度、対象範囲が広がりすぎて、見なくていい資料まで候補に上げられた。手戻りがだるい。節目で要約しておけば、そういう無駄をかなり抑えられる。 やり

検索しただけで満足して、長い出力をそのまま次の作業に持ち込むと、だいたい後で詰まる。ログも、記事の下書きも、調査メモも、全部そのままだと長すぎるのだ。 Claude Code は、調べた内容をその場で短く圧縮して、次の指示に渡すのがうまい。ここでいう圧縮は、雑な要約ではない。必要な論点だけを抜き出して、次の作業で扱える密度に落とすことだ。調査メモ、検索結果の圧縮、と呼んだほうが通りがいい場面もある。 この使い方を覚えると、調べる → 読む → また調べ直す、という無駄な往復が減る。特に Claude Code では、長い出力をそのまま食わせるより、先に短く整えておいたほうが、その後の修正や比較が楽になる。 まずやることは単純だ。Claude Code に「要点だけ」「次に渡せる形で」「長文にしない」と明示する。ふわっと「まとめて」だけだと、やたら丁寧な長文が返ってきて、結局また読む羽目になる。そこがいちばん無駄だ。 たとえば、調べ物をした直後にこう頼む。 ```text 以下の調査結果を、次の作業にそのまま渡せる短いメモに圧縮して。 条件: 200〜400字くらい 事実、判断、未確認点

作業ログを丸ごと次の依頼に貼るのは、だいたい無駄だ。しかも、長いログほど Claude Code の思考を散らす。必要なのは全部ではなく、迷った地点だけである。ここを切り出すやり方は、振り返りテンプレにもなるし、迷いポイントの抽出としても使える。 このやり方のうまみは単純だ。前回の作業で「どこで判断に詰まったか」「どの分岐で止まったか」だけを次回に渡せるので、同じ迷いをもう一度なぞらなくて済む。ファイル整理でも、文書作成でも、コード修正でも効く。全部を引き継ぐと重い。迷った地点だけ戻すと、次の一手が速くなる。 たとえば、前回の依頼で「古い資料を年度ごとに分けてほしい」と頼んだのに、年度の切り方がファイル名基準なのか更新日基準なのかで止まったとする。このとき次回に必要なのは、作業ログ全文ではない。「年度の境目をファイル名で見るのか、更新日で見るのか迷った」という一点だ。ここだけ戻せば、Claude Code は同じ確認を繰り返さずに済む。 実際には、ログを見て次の三つだけ拾えばいい。 まず、判断が止まった場所だ。 次に、そのとき迷った選択肢だ。 最後に、決め手にならなかった理由だ