Claude Code に雑に頼むと、まず返答の形がブレる。文章でほしいのに箇条書きが増えたり、表でほしいのに説明が長くなったりする。中身以前に、器が決まっていないのが原因だ。ここを先に固定すると、出力形式の指定が効いて、成果物の形を固定するだけで手戻りがかなり減る。
筆者はこれで何度も痛い目を見た。たとえばファイル整理の依頼で、最初は「不要なものを洗い出して」とだけ投げていた。すると、ある回は長文の方針説明、別の回は箇条書き、さらに別の回は見出しだけ妙に立派なメモになった。欲しいのは「そのまま使える一覧」なのに、毎回整形し直す羽目になる。これが地味にだるい。
だから最初にやることは単純だ。Markdown で返すのか、表で返すのか、先に決める。迷うなら、まずは Markdown に寄せる。理由は簡単で、Claude Code は説明文、手順、注意点、短い例をひとまとめにしやすいからだ。逆に、項目同士を並べて比較したいなら表が向く。どちらでもいい、ではなく、最初の一手で固定するのが大事になる。
実際の頼み方はこうだ。
この内容を Markdown で出力してください。
見出しは 2 階層までにしてください。
箇条書きは必要最小限にしてください。
最後に要点を 3 行でまとめてください。
比較表がほしいなら、最初から表と宣言する。
次の情報を表で整理してください。
列は「項目」「内容」「補足」の 3 列にしてください。
説明文は表の外に出さず、表の中だけで完結させてください。
ここで効くのは、「何を言うか」より「どう並べるか」を先に決めることだ。Claude Code は指示が曖昧だと、説明を厚くしてごまかしに行く。人間の目には親切でも、あとでコピペして使うには弱い。表にするなら表に徹する。Markdown にするなら、段落、見出し、箇条書きの役割を分ける。中途半端がいちばん散る。
非エンジニアの作業でも同じだ。たとえば契約書の草案を案件ごとに整理したいなら、Markdown は使いやすい。案件名、論点、未確定点、次のアクションを見出し付きで並べれば、そのままメモとして残せる。逆に、複数フォルダの重複ファイル候補を洗い出すような場面では、表のほうが強い。ファイル名、場所、サイズ、削除候補かどうかを横並びにしたほうが、目で追いやすい。
ただし、表を万能にしないほうがいい。長い説明を無理やり表に押し込むと、セルの中が読みにくくなる。反対に、複雑な内容を Markdown でだらだら書かせると、どこが比較ポイントなのか見えなくなる。筆者はここでも失敗した。仕様の差分を整理させたのに、表にしたせいで注釈が各セルに散り、結局また整え直した。比較の軸が多いなら表、流れや手順を見せたいなら Markdown。この分け方でだいたい外さない。
依頼文には、形式だけでなく「その形式で何を守るか」まで書くと安定する。たとえば Markdown なら、次のように条件を足す。
Markdown で出力してください。
各見出しの下は 3〜5 文に収めてください。
箇条書きは手順だけに使い、雑な要約はしないでください。
コード例があればそのままコピーできる形で示してください。
表なら、列の意味をはっきりさせる。
表で出力してください。
「項目」は短く、「内容」は具体的に、「補足」は注意点だけにしてください。
空欄が出る場合は「なし」と書いてください。
この「空欄はどうするか」みたいな細部が地味に効く。出力形式を決めただけだと、Claude Code は妙に親切に空欄や補足を増やすことがある。後で機械的に扱いたいなら、例外を先に潰すべきだ。成果物の形を固定するとは、見た目だけでなく、例外処理まで固定することを含む。
やってはいけないのは、最初から「いい感じに整理して」と投げることだ。これはかなり危ない。いい感じの基準が読めないから、返答は毎回ぶれる。しかも一度ぶれた出力を人間が直すと、次の依頼でも似たぶれ方を誘発しやすい。最初に型を渡したほうが、Claude Code も迷わない。
少し進めるなら、用途ごとに自分の定番を持つといい。文章メモは Markdown、一覧と比較は表、手順書は Markdown の箇条書き、チェック対象の洗い出しは表。これを毎回明文化しておくと、依頼のたびに悩まない。Claude Code を使う人ほど、実は内容より形式の迷いで時間を取られている。そこを先に潰すだけで、返答の暴れ方が目に見えて減る。
仕様の細部や最新の出力挙動は、必要なら公式ドキュメントで確認するといい。だが、基本は変わらない。最初に Markdown か表かを決める。それだけで、返答はかなり素直になる。