「とりあえず答えて」で始めると、あとで整形し直す羽目になる。Claude Code でもここは同じで、返答の形を先に固定するだけで手戻りがかなり減る。出力形式の指定、返答フォーマットを先に渡しておく、というやつだ。
たとえば、作業メモを整えたいのに段落だらけの文章が返ってくると、結局こちらで見出しを切り直すことになる。逆に、最初から Markdown で返させれば、見出し、箇条書き、コードブロックがそのまま使える。表が欲しいなら表に寄せる。ここを曖昧にしたまま進めるのは、箱を開けてから「やっぱりこの棚は縦じゃなく横だった」と言っているようなものだ。
Claude Code に頼むときは、まず使い道を一言で言い切る。そのうえで、返答形式を最初の条件として置く。たとえばこうだ。
この作業はMarkdownで返してください。見出しは h2 相当、要点は箇条書き、最後に次の作業だけ短く書いてください。
表で欲しいなら、最初からそう言う。
この内容は表で返してください。列は「項目」「内容」「補足」の3つで固定し、余計な前置きは不要です。
ファイル整理や文書作成なら、さらに具体的にしておくと効く。
このディレクトリの中身を整理する方針を、Markdownで返してください。
見出しは「現状」「分け方」「残すもの」「捨てるもの」にしてください。
重複ファイルの確認手順を、表で返してください。
列は「確認対象」「やること」「注意点」です。
ここで大事なのは、内容を先に決めるより、形を先に決めることだ。人間相手でもそうだが、AI 相手ではなおさら効く。返答の器が決まると、Claude Code は中身の組み立てに集中しやすい。逆に器がないと、説明が長くなったり、項目の粒度がバラついたりして、こちらの編集コストが増える。
筆者は最初、作業指示だけをざっくり投げて、返ってきた文章を毎回コピペし直していた。Markdown にしたいのに普通の段落で返ってくる。表にしたいのに箇条書きで返ってくる。小さい話に見えて、これが地味にだるい。しかも、あとから「この行だけ表にして」「ここだけ箇条書きにして」と直すと、内容の意味まで少しずつ崩れる。最初から形を決めておけば、そういう摩擦はほぼ消える。
ただし、形を固定するだけで全部うまくいくわけではない。欲張って条件を盛りすぎると、今度は返答が窮屈になる。たとえば「Markdownで、見出しは5段階、各段落は80字以内、必ず表も入れて、最後にチェックリストも」と詰め込むと、かえって読みにくくなる。返答フォーマットは便利だが、盛りすぎるとただの縛りになる。そこは割り切ったほうがいい。
もうひとつ、表を指定するときの注意がある。表は見やすいが、細かい手順や例外の説明には向かないことがある。ファイル削除の判断基準を表にするときも、「残していい理由」と「消していい理由」を同じ列に押し込むと、かえって雑になる。そんなときは、表で全体像を出してから、その下に短い補足を Markdown で足す、という分け方が扱いやすい。
この回答はまず表で全体像を示し、そのあとにMarkdownで補足を書いてください。
表は「対象」「判断」「理由」の3列にしてください。
この頼み方にしておくと、一覧性と説明の両方を取りやすい。逆に、どちらでもいいと雑に投げると、毎回フォーマットが揺れる。揺れる返答は、再利用しづらい。そこが一番もったいない。
非エンジニアが使う場面でも、この癖はかなり効く。たとえば、案件ごとの書類整理をしたいなら、最初から Markdown で手順を出させると読み返しやすい。会議メモを整えたいなら、表で「決定事項」「保留」「担当」を切らせると、そのまま共有しやすい。ディスク整理なら、表で「消してよい候補」「確認が必要な候補」を分けたほうが事故が少ない。要するに、人に渡す形で受け取る発想にすると強い。
最後に、よくある落とし穴をひとつだけ押さえておく。返答形式を固定したあとに、曖昧な言い方を混ぜないことだ。「読みやすく」「いい感じに」「適切に」は便利そうで、だいたい役に立たない。Claude Code に対しては、Markdown か表か、列は何か、見出しは何か、そこまで言ってしまったほうが速い。迷ったら、まず形を決める。中身の良し悪しはそのあとだ。