#claude-code-output-shaping-2

長文を投げておいて「要点だけ返せ」は、だいたい伝わりきらない。Claude Code でも同じで、先に分量の上限を決めておかないと、返答は平気で膨らむ。短くまとめさせる、要点だけ返させる、という使い方をしたいなら、最初に「何行まで」「何文字まで」「箇条書き何点まで」を入れておくのがいちばん効く。 これはコードの相談だけの話ではない。ファイル整理の相談でも、文書の下書きでも、ディスク削減の手順でも、先に制限を言うだけで返答の密度が上がる。逆に、あとから「もっと短く」と言い足すと、すでに出した長文を削る作業が発生して、無駄が増える。 たとえば、こう頼む。 ```text 次の内容を、3行以内で短くまとめてください。 要点だけ返してください。前置きは不要です。 ``` Claude Code にコーディングの相談をするなら、もう少し型を決めるといい。 ```text この変更案を、箇条書き3点以内で短くまとめてください。 各項目は1文まで。背景説明は不要です。 ``` 文書作成なら、分量の上限を先に置く。 ```text この文章を、200字以内で要点だけ返してください。 読者が次に取るべき

Claude Code に雑に「一覧で」「見やすく」で投げると、返答の形が毎回ぶれる。ここを甘く見ると、あとでコピペしづらい、差分が読みにくい、保存したときに壊れやすい、の三重苦になる。先に Markdown で出すのか、表で出すのかを決めておく。要するに出力形式の固定だ。成果物の形を先に決めるだけで、返答はかなり安定する。 この手の話は、エンジニアのコードレビューだけの話ではない。ファイル整理でも、議事録作成でも、請求書の確認でも同じだ。たとえば「重複ファイルの候補を拾ってほしい」と頼むときに、表で返してほしいのか、Markdown の見出し付きで返してほしいのかが曖昧だと、途中で形式が変わる。そうなると人間の目でも扱いにくいし、次の工程に渡しづらい。 筆者も最初はここで何度も手戻りした。Markdown のつもりで頼んだのに、途中から表が混ざる。逆に、表で見たかったのに箇条書きが増える。Claude Code は内容をちゃんと理解していても、出力の器が決まっていないと、返し方が揺れることがある。コンテキストを食うわけではないが、余計な往復が増える。地味にだるい。 まず、最初に器を決

長い経緯メモを Claude Code に持たせると、だいたいろくなことにならない。読み返すだけでコンテキストを食い、肝心の判断材料が埋もれる。残すべきなのは、途中の雑談ではなく決定事項だ。短い作業メモ、あるいは決定事項の圧縮という発想に切り替えると、作業が急に軽くなる。 Claude Code は会話の流れを踏まえて動く。だからこそ、途中で「ここまで何を決めたか」を短く固定しておくと強い。逆に、経緯をだらだら積み上げると、あとから見返したときに自分でも迷うし、Claude Code も無駄に揺れる。筆者は最初、会議の議事録みたいなメモをそのまま貼っていたが、修正のたびに話が分散して、同じ説明を何度もやり直した。あれははっきり無駄だった。 たとえば、あるフォルダ整理を頼む場面を考える。 悪いメモはこうなる。 ```text 昨日の続きで、あの資料も入っていて、こっちのファイル名も少し変えていて、最初はPDF中心だったけど途中で画像も混ざって、クライアントの都合で表紙の扱いが変わって、たしか社内共有用と提出用で分ける話もあって…… ``` これだと、何が決定で何がただの経緯か分からない。