Claude Code に雑に「見やすくして」と投げると、だいたい出力が揺れる。段落になったり、箇条書きが増えたり、表に寄ったりする。人間が読むには気にならないことも多いが、何度も使う作業だと地味に効いてくる。ここで先にやるべきなのは、内容を考える前に出力形式固定を決めることだ。Markdown指定でもいいし、最初から表に寄せるでもいい。これだけで、後から「思ってたのと違う」を減らせる。
筆者は最初、この手の依頼をかなり曖昧にしていた。たとえば「この資料を整理して」とだけ投げる。すると、あるときは見出し付きの長文、別のときは箇条書きの羅列、また別のときは表が混ざる。人間相手なら「まあいいか」で済むが、Claude Code 相手だと毎回の微調整が増える。しかも、同じ内容を何度も言い直す羽目になる。これが一番だるい。先に形式を縛ったほうが、コンテキストの無駄が減るし、出力のブレも抑えやすい。
たとえば、Markdownで出すなら最初からそう言い切る。箇条書き、見出し、コードブロックまで含めて、最終出力の形を指定する。ファイル整理でも文書作成でも同じだ。要点を短く並べたいならMarkdown、項目を比較したいなら表、という選び方でいい。迷ったら「人間があとで追記しやすいか」で決めると外しにくい。
次の内容を、Markdown で出力してほしい。
見出しは h2 相当、要点は箇条書き、最後に短い注意点を 3 つ付ける。
表にはしないでください。
逆に、一覧比較や棚卸しなら表のほうが強い。重複ファイルの候補、案件ごとの作業状況、文書の差分確認みたいな用途では、表にした瞬間に見通しがよくなる。特に非エンジニアの作業だと、「どれが処理済みで、どれが未確認か」を一発で見たい場面が多い。そこをMarkdownの長文で返されると、読めるけど探しにくい。
次の項目を表で整理してください。
列は「ファイル名」「場所」「削除候補か」「理由」の4列にしてください。
余計な説明は表の外に出さないでください。
ここで大事なのは、形式を決めるだけで終わらせないことだ。Markdownなら「どこまでを見出しにするか」、表なら「列名を何にするか」まで先に縛る。ここが曖昧だと、Claude Code はまだ暴れる。人間でも同じで、骨組みがないと見た目だけ整って中身が散る。形式固定は、単なる見栄えの話ではない。出力の責任範囲を狭くする作業だ。
やりがちな失敗もある。Markdownにしたいのに、「見やすく」とだけ頼んでしまうやつだ。これだと、見出しが増えすぎたり、箇条書きが細切れになったりする。表にしたいのに、項目説明が本文に逃げることもある。筆者はこれで一度、ファイル整理の一覧を作らせたのに、表と段落が混在した中途半端な出力を食らった。修正は可能だが、最初から「表だけで」「列はこの3つ」と言っておけば一発だった。手戻りを減らしたいなら、最初に口を酸っぱくして縛るほうが早い。
もう一つ、形式を先に決めるときのコツがある。内容がまだ固まっていないなら、まずはMarkdownで下書きを出させ、その後で表に変えるか判断する流れが使いやすい。最初から表を強制すると、細かいニュアンスを削りすぎることがあるからだ。逆に、比較や棚卸しのように項目が確定しているなら、最初から表に固定したほうがいい。要は、考えるための出力か、見るための出力かを分けるだけである。
少し踏み込むなら、依頼文の中で「何をしないか」も書いておくとさらに安定する。Markdownなら「表にはしない」、表なら「本文を増やさない」と明言する。Claude Code は与えた枠の中でかなり素直に動くので、禁止事項を一つ足すだけでも暴れ方が変わる。ふわっとした依頼を減らし、形を先に決める。これだけで、出力のブレはかなり抑えられる。細かい作業ほど効く。文書整理でも、比較表づくりでも、コードまわりの説明でも同じだ。
形式を先に固定する癖がつくと、次は「どの粒度で出すか」を詰めたくなる。そこまで行けば、Claude Code への依頼はかなり安定する。Markdownか表かを先に決める、これは小さいようで効き目が大きい。出力が暴れるたびに直すより、最初に枠をはめたほうがずっと楽だ。