Claude Opus 5のレポートが長いときの調整 — 成果物の長さを一文で絞る
Opus 5がディスクに書くレポートやMarkdownは旧モデルより長くなりがちです。会話の冗長さとは別の対策が要る理由と、成果物の長さをそろえる一文の入れ方を示します。
Claude Opus 5にレポートやMarkdownを書かせると、旧モデルより長い文書が返ってきます。Opus 5のプロンプト解説は、ディスクに書き出す成果物が長くなりやすいと明記し、対策として文書の長さをそろえる一文を勧めています。
会話の返答が長い問題とは別の対策です。ここでは、その一文の中身と置き場所、効いたかどうかの確かめ方を扱います。
会話の返答を短くしても、成果物は短くならない
Opus 5のプロンプト解説は、長さの問題を2つに分けています。1つは画面に出る返答の長さ(Response length and verbosity)、もう1つはレポートやMarkdown、要約といったファイルとして書き出す成果物の長さ(Written deliverable length)です。後者は「会話の冗長さとは別に」起きる、という書き方です。
つまり、返答用の簡潔さの指示を入れても、書き出されるファイルが締まるとは限りません。返答用に勧められている指示は次の文面です。
Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.対象は「responses」、つまり返答です。文書の長さを縛る文言は入っていません。成果物には専用の一文を別に用意します。
effortを下げても長さは変わらない
もう1つの落とし穴がeffortです。effortのドキュメントは、Opus 5ではeffortが考える量を調整するもので、見える応答の長さを確実に短くはしない、と説明しています。プロンプト解説も、effortを下げるとthinkingの量は減っても、見える返答が短くなるとは限らないとしています。
「長いからeffortをlowに」は、成果物の長さには効かない対処です。effortは費用と速度の調整に使い、長さは文面で指定します。effortの選び方はOpus 5のeffort使い分けで扱っています。
成果物の長さをそろえる一文
プロンプト解説が示す、成果物向けの長さ調整の一文は次のとおりです。自社のプロダクトがClaudeに文書を書かせるなら、この一文を足すよう勧められています。
Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.訳すと「文書の長さは、タスクに必要な分に合わせる。中身は網羅するが、水増しの節や、重複する要約、定型文は入れない」という意味です。この一文には、削る対象が3つ名指しされています。
| 名指しされた対象 | 実際に出やすい形 |
|---|---|
| filler sections(埋め草の節) | 実際に出やすい形「背景」「今後の展望」など、頼んでいない節 |
| redundant summaries(重複する要約) | 実際に出やすい形冒頭の概要、各節末のまとめ、文末の総括が同じことを繰り返す |
| boilerplate(定型文) | 実際に出やすい形免責の文言、「以上です」で終わる結びの定型句 |
右の列は、記事側で用意した例です。公式が列挙しているのは左の3語までで、具体的な形は自分の出力を見て確認します。
数値で縛る必要はあるか
公式の例文は、字数や行数の目標を入れていません。「タスクに必要な分」という基準で足りるという前提です。それでも長さが定まらないなら、文書の種類ごとに目安を足す手があります。たとえば「週次報告は1画面に収まる分量」のような書き方です。数値を足す場合は、公式の一文を土台に、自分の文書の型に合わせた条件を加える形になります。この足し方は記事側の応用で、公式の推奨ではありません。
どこに書くか
一文を置く場所は、Claudeの使い方で変わります。
- API経由で自社プロダクトを作っている: システムプロンプトに入れる
- Claude Codeで文書を作らせている: プロジェクトの
CLAUDE.mdに入れる
システムプロンプトが長い場合、返答の簡潔さの指示は末尾にも短い念押しを置くよう、プロンプト解説が勧めています。例は次のとおりです。
<tone_preference>
Keep outputs reasonably concise.
</tone_preference>この念押しの対象も返答です。成果物の一文を使うときは、本文の中ほどに1回入れれば足ります。末尾の念押しにも「文書の長さ」を重ねるかは、出力を見て判断します。
Claude Codeでの書き方
Claude Codeは、調査メモや設計書、READMEといった文書をファイルに書きます。CLAUDE.mdには、上の一文に加えて、書く対象を絞る行を並べると効きます。
## 文書を書くとき
- 文書の長さは、タスクに必要な分に合わせる。中身は網羅するが、
水増しの節、重複する要約、定型文は入れない。
- 頼まれていない文書(調査メモ、要約ファイル、README)を新しく
作らない。
- 既存の文書への追記を頼まれたときは、追記部分だけを書き、
既存の節を書き直さない。1行目は公式の一文の訳で、2行目と3行目は記事側の追加です。2行目と3行目はOpus 5が頼んでいない作業を足すことがあるという公式の指摘(範囲の拡大)に合わせた行ですが、公式が成果物向けに勧めている文言ではありません。範囲の拡大についてはOpus 5のプロンプトから検証の指示を外すで、範囲を決める一文を取り上げています。CLAUDE.md自体の書き方はCLAUDE.mdを実用に引き上げる10のパターンにまとめています。
長さが変わったかを測る
一文を入れたら、同じ依頼で入れる前と後を比べます。文書の長さは、見た目の印象より数字で見たほうが確実です。
# 出力ディレクトリのMarkdownを文字数の多い順に並べる
find reports -name '*.md' -print0 | xargs -0 wc -m | sort -rn | head比べるときの注意が4つあります。
- 依頼文を変えない。依頼の書き方を変えると、長さの差が一文の効果か依頼の違いか分からなくなります
- 1回で判断しない。同じ依頼を複数回走らせ、長さの幅で見ます
- 文字数だけで判断しない。短くなった代わりに、必要な節が消えていないかを読んで確かめます
- APIでトークン数を見るときは、thinkingの分が混ざることに注意する。effortのドキュメントによると、
max_tokensはthinkingと応答テキストを合わせた出力の上限なので、文書そのものの長さは、書き出したファイルの文字数で測るほうが確実です
一文の目的は、中身を削ることではなく、埋め草を削ることです。「中身は網羅する」の側が守られているかが、評価の半分です。
それでも長いときの次の手
一文を入れても長さが落ち着かない場合の切り分けを、順に挙げます。
- 依頼文の側に、長さを引き上げる言い方がないか見る。「詳細に」「網羅的に」「丁寧に」は、そのまま長さの指示として読まれます
- プロンプトの書式が出力に影響していないか見る。Claudeの一般的なプロンプト解説は、プロンプトの書き方が応答の書き方に影響するとしており、箇条書きと見出しだらけのプロンプトは、箇条書きと見出しだらけの出力を招きます
- 書式の量を絞りたいなら、「やらないこと」ではなく「やること」で書く。解説の例では、「Markdownを使わない」ではなく、滑らかに流れる散文の段落で構成する、という書き方が勧められています
書式の指示は、長さの指示とは別の軸です。箇条書きを減らせば文書が短くなる、とは限りません。長さには長さの一文、書式には書式の指示、と分けて入れます。
長さの問題は3つある — 切り分けの早見表
Opus 5で「長い」と感じる出力は、原因が3つに分かれます。プロンプト解説は、それぞれに別の節を割り当てています。
| 長くなる場所 | 症状 | 対処の節 |
|---|---|---|
| 画面に出る返答 | 症状説明が長い、注意書きが多い | 対処の節Response length and verbosity |
| 作業中のメッセージ | 症状ツール呼び出しの前に毎回予定を語る | 対処の節User-facing progress updates |
| ディスクに書く文書 | 症状レポートやMarkdownが膨らむ | 対処の節Written deliverable length |
Claude Codeのようなエージェント作業では、3つが同時に起きます。作業中は予定を語り、終わると長い返答で説明し、書いた文書も長い。1つの指示では3つとも収まりません。
作業中の語りには、頻度と形を決める文面
2行目の作業中のメッセージには、プロンプト解説が別の文面を示しています。要旨は次のとおりです(訳)。最初のツール呼び出しの前に、何をするかを一文で言う。作業中は、重要な発見があったときか方針を変えたときだけ短く知らせる。終わったら結果から書き始め、最初の一文で「何が起きたか」「何が分かったか」に答える。
この文面は、成果物ではなく会話の語りを締めるものです。文書の長さに効く一文と混ぜずに、別の行として並べます。語りを増やしたいときは、望む更新の形を例で示すほうが、禁止の指示より効くとも書かれています。
文書を読む人が欲しいのは結論だったりする
上の文面にある「結果から書き始める」は、成果物の書き方にも使える考え方です。長い報告書の読み手は、結論を先に読みたいことが多いからです。ただし、文書の構成(結論先出しにするか、経緯を残すか)は文書の用途で決まる話で、公式が成果物について指定しているのは、長さを必要な分にそろえることまでです。構成まで指定したいときは、文書の型を依頼文に書きます。
Opus 5.5でも同じ一文を使えるか
2026年9月に出たOpus 5.5には、専用のプロンプト解説があります。ただし、そのページには、文書の長さを扱う節がありません。Opus 5の節を、そのままOpus 5.5にも当てはめてよいかは、公式の記述だけでは決まりません。
分かっている違いは、effortの既定値です。effortのドキュメントでは、Opus 5.5の既定はmediumで、Opus 5はhighです。モデルを切り替えると、省略したeffortの意味が変わります。ただ、effortはどちらのモデルでも考える量の調整で、成果物の長さの調整手段ではありません。Opus 5.5を使っていて文書が長いと感じたら、同じ一文を入れて、同じ方法で前後を比べるのが現実的です。モデル全体の違いはOpus 5の使い方と仕様に整理しています。
返答の文体が癖として出る場合
文書の長さではなく、「Xではない。Yだ」型の言い回しなど文体の癖が気になる場合は、対処の種類が違います。症状と抑え方はClaudeの文章の癖が抜けない問題で扱っています。長さの一文は、この種の癖には効きません。
まとめ
Opus 5の成果物が長いときは、返答用の簡潔さの指示とeffortの調整では足りません。文書の長さをタスクに合わせる一文を、システムプロンプトかCLAUDE.mdに別に入れます。入れたあとは、同じ依頼を複数回走らせて文字数を比べ、必要な節が消えていないかを読んで確かめます。最初の一歩は、いま長いと感じている文書の依頼を1つ選び、一文を入れる前後でwc -mの値を並べることです。