ai-docs

Prompting Claude Opus 5

Properties1
tagsprompting, agents, subagents, thinking, effort, claude-opus-5

13 min read

一行要約

Opus 5 向けの prompting は足すより剥がす — 検証指示・再確認指示・「慎重に」といった旧世代向けの補助輪が、この世代では over-verification と冗長さのコストに変わる。

要点

It performs well out of the box on existing Claude Opus 4.8 prompts. 既存の Claude Opus 4.8 向けプロンプトのままでも、そのままよく動く。

既存の Opus 4.8 用プロンプトはそのままでも動く。以下は調整が必要になりやすい振る舞いのリスト。

能力面の変化で prompting に効くもの

  • agentic coding — 複数ファイルの機能追加、大きなリファクタ、end-to-end の実装が最も強い。stub や placeholder を残さずタスクを完遂する。完全な仕様を最初に与えて放っておくのが最も性能が出る
  • コードレビュー / バグ発見 — precision と recall がともに高く、追加で挙がる指摘も大半が本物。低い effort でも精度が保たれるので、レビュー時に速いパス、後で丁寧なパス、という運用ができる

    If your review prompt says “only report high-severity issues” or “be conservative,” the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead. レビュー用のプロンプトに「重大な問題だけ報告せよ」「保守的に」と書くと、モデルはその指示を文字通りに受け取り、報告を減らすことがある。代わりに、すべて報告させたうえで別の工程で絞り込め。

  • 低 effort での効率 — low と medium が高い設定の何分の一かのトークンとレイテンシで強い品質を出す。既定は high。品質が保てる範囲で low / medium をトークンコストと応答時間の主要な制御手段として積極的に使い、要求の厳しいコーディング・エージェント作業で xhigh に上げる。旧モデルから effort の既定値を引き継いでいるなら、自分の eval で effort sweep をやり直す
  • vision — チャート・文書・図の理解、UI とフロントエンドの視覚的再現が強い。旧モデル向けに調整した vision の回避策は再検証する（もう不要かもしれない）。ツールを与えて反復的に解析・crop・視覚的検証させるのが、thinking を増やすよりコスト効率が良い
  • long-context — 1M トークンが既定かつ最大。window 全体を通じて指示追従・ツール呼び出し・推論が一貫する
  • multi-agent 協調 — writer-verifier パターンが有効に働き、エージェント同士が互いの作業を上書きする事例が少ない

応答の長さと冗長さ

Opus 5 の既定の応答は従来の Opus より長い。

The effort parameter controls how much the model thinks rather than how much it says: lowering effort can reduce thinking volume without reliably shortening the visible response. effort パラメータが制御するのは、モデルがどれだけ話すかではなくどれだけ考えるかである。effort を下げれば thinking の量は減りうるが、目に見える応答が確実に短くなるわけではない。

→ 応答長は prompt で明示的に指定するしかない。長い system prompt では、末尾近くに短いリマインダを併置すると効く。

ユーザー向けの進捗報告

Opus 5 は agentic 作業中によく実況する。何をしようとしているかを予告する傾向があり、エージェントセッションでのメッセージあたりの出力が従来より長い。

抑えるにも増やすにも同じレバー — 欲しい更新の頻度と形を具体的に記述する。

Positive examples of the communication style you want tend to be more effective than instructions about what not to do. 望む伝え方を示す肯定的な例のほうが、してはいけないことを伝える指示より効果的な傾向がある。

書き出す成果物の長さ

会話の冗長さとは別に、ディスクに書くファイル（レポート、Markdown 文書、要約）が従来より長い。

タスクのスコープと over-verification

Claude Opus 5 verifies its own work without being told to. Claude Opus 5 は、言われなくても自分の仕事を検証する。

If your prompt contains explicit verification instructions (“include a final verification step for any non-trivial task,” “use a subagent to verify”), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality. プロンプトに明示的な検証指示（「非自明なタスクには最後に検証ステップを入れよ」「subagent に検証させよ」）が含まれているなら、それを削れ。この種の指示は Claude Opus 5 で過剰な検証を引き起こし、削除すると品質を落とさずに無駄なトークンを減らせる。

プロンプトに検証指示があるなら削除する。 「非自明なタスクには最後に検証ステップを入れよ」「subagent に検証させよ」といった指示は Opus 5 では over-verification を引き起こし、削除するとトークンの無駄が減って品質は落ちない。旧来の harness scaffolding が足している検証ステップも同様。

また Opus 5 はタスクのスコープを勝手に広げることがある（頼まれていない手順を足す、タスクがどうあるべきかを自分で判断する）。狭いタスクでは明示的に制約する。

subagent の起動制御

Claude Opus 5 delegates to subagents more readily than prior models. Claude Opus 5 は以前のモデルより積極的に subagent へ委譲する。

委譲は本当に独立した大きな作業の筋では報われるが、小さなタスクに適用するとコストと時間が倍加する。どういう場面で委譲すべきかを明示するか、起動数に決定的な上限を設ける。

自己修正

Opus 5 は指示なしでも自分の誤りを見つけて直す。「答えをダブルチェックせよ」「返答前に再検証せよ」といった指示は避ける — モデル自身の振る舞いと複合して、結果を良くせずコストだけ増やす。

また過去の発言への訂正を従来より多く実況する。ユーザー向け製品では望ましくないことがある。

thinking を無効にして走らせる場合

Opus 5 は thinking がオンが既定で、無効化できるのは effort high 以下のときだけ。

The primary mitigation for both is to keep thinking enabled and control token cost with lower effort levels instead of disabling thinking: for most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost. どちらに対しても主たる緩和策は、thinking を無効にするのではなく、有効にしたまま低い effort レベルでトークンコストを抑えることである。多くのタスクでは、low の effort で thinking を有効にしたほうが、同程度のコストで thinking を無効にするより良い性能を示す。

thinking を無効にすると2種類のアーティファクトが稀に出る。

1. ツール呼び出しがテキストとして出る — 構造化された tool_use ブロックではなく、ユーザー向けテキストの中にツール呼び出しを書いてしまう。ターンは正常に完了し、呼び出しは実行されない。しかもagentic ループではその漏れたテキストが会話履歴に残るので、後続のターンにも影響する。検索のようなツール多用のワークロードで起きやすい。

2. 内部 XML タグが出力に混じる — <thinking> などが可視の応答に出る。system prompt に「考えるな」「推論するな」というルールがあるなら削除する。この種の指示はタグの漏出を増やす。

Instructions that call out thinking tags by name are less effective than the general form, so avoid naming them specifically. thinking のタグを名指しする指示は、一般的な言い方より効果が薄い。具体的に名指しすることは避けよ。

そのまま使える具体例

簡潔さの指示（ユーザー向けの多ターン製品）:

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.

長い system prompt の末尾に置くリマインダ:

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

実況を抑える:

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

書き出す文書の長さを較正する:

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.

スコープを制約する:

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

subagent の乱発を抑える:

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

訂正の実況を必要なものだけに絞る:

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

thinking 無効時の2つのアーティファクトをまとめて緩和する（タグ名を挙げないのが要点）:

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク