ここを曖昧にしたまま投げると、Claude Code はだいたい素直に広がる。つまり、読みやすい文章ではなく、あとで直しにくい長文や、表にしたかったのに段落で返ってくるあの感じだ。先に成果物の形を決める、要するに出力形式を指定する。これだけで手戻りがかなり減る。
Claude Code に何かを頼むとき、内容だけでなく「最終的にどう並べるか」を先に固定すると強い。Markdown で見出し付きの説明文にするのか、比較しやすい表にするのか。ここを最初に決めておくと、内容の整理もその形に引っ張られる。逆に、形を後回しにすると、途中まで書かせたあとに「やっぱり表で」と言って崩す羽目になる。筆者はこれで何度も手戻りした。特に、ファイル整理の説明や手順書を作らせるときに、段落で長く返ってきたものを後から表に直すのはだるい。最初に固定しておけばいい。
たとえば、読み物や手順書なら Markdown に寄せる。箇条書き、見出し、小見出し、コードブロックを使いやすいからだ。比較、一覧、チェック用の整理なら表が向く。たとえば「どのフォルダに何を入れるか」「この書類は残すか捨てるか」「このキャッシュは削除してよいか」を並べるなら、表のほうが圧倒的に見やすい。
依頼は最初からこう言ってしまうといい。
Markdown 形式で出力して。見出しは2階層までにして、最後に実行手順を箇条書きでまとめて。
表にしたいなら、もっとはっきり言う。
表形式で出力して。列は「項目」「判断基準」「やること」の3列にして。
非エンジニアが文書作成や整理で使うなら、これをもう少しかみ砕いていい。
最終成果物はMarkdownでお願いします。あとでそのまま文書に貼れる形にしてください。
最終成果物は表でお願いします。一覧として見比べたいです。
ここで大事なのは、「内容を考えてから形を決める」のでは遅いということだ。Claude Code は、先に与えた枠に合わせて情報を整理するのがうまい。枠がないと、こちらが欲しい粒度よりも少し広く、少し散らかった出力になりやすい。ファイル整理で例えるなら、先に引き出しを決めずに小物を全部机に出すようなものだ。後で片づけるのは人間側になる。
表を使うときは、列名まで決めるとさらに崩れにくい。曖昧に「表で」とだけ言うと、列の切り方が微妙になりがちだ。たとえば、ディスク削減のために不要ファイルを洗い出したいなら、こういう指定が実用的だ。
表で出力して。列は「場所」「種類」「削除してよい条件」「注意点」にして。
この指定があると、Claude Code は「何を削るか」だけでなく「何を残すべきか」まで並べやすい。単なる一覧ではなく、判断の道具になる。
逆にやってはいけないのは、形を決めないまま長い要件だけを並べることだ。たとえば「社内向けの説明資料を作って、背景も入れて、手順も入れて、注意点も入れて」だけだと、だいたい平坦な長文になる。あとで「やっぱり表がよかった」「見出しを減らしたい」となる。こういう後出し修正は、コンテキストも食うし、差分もややこしくなる。Claude Code に余計な再構成をさせると、そこから先の回答の精度も落ちやすい。
実際、筆者は案件フォルダの整理ルールを文章で作らせたあと、やっぱり一覧にしたくなって作り直したことがある。最初から表にしていれば一発だった。しかも、表なら「保存先」「命名ルール」「例外」の列を置けるので、あとで自分や同僚が見返すときも迷いにくい。文章は読みやすいが、検索や比較には弱い。表はその逆だ。だから最初に形を選ぶ。
少し進めるなら、出力形式だけでなく「どこまでMarkdownを使うか」まで決めるといい。見出し中心にしたいのか、表を1つだけ入れたいのか、コードブロックは必要か。たとえば、手順書ならこう指定する。
Markdownで、見出し→短い説明→手順の順で出力して。
コードが必要な箇所だけコードブロックにして、余計な装飾は入れないで。
これで、無駄に派手な構造や、読みにくい装飾を避けやすい。
要するに、先に出力の形を固定すると、Claude Code は「何を書くか」だけでなく「どう並べるか」まで自動で整理しやすくなる。Markdown か表かを最初に決める。成果物の形を先に決める。たったそれだけで、やり直しの回数はかなり減る。次に効くのは、表の列名まで先に言い切ることだ。そこまでやると、かなり使いやすくなる。