Claude Opus 5向けプロンプト設計｜長い回答・過剰検証・サブエージェントを業務で制御するコツ

Claude Opus 5のような高性能モデルは、雑に頼んでもそれなりに動きます。ただ、業務で使うなら「賢いから任せる」だけでは足りません。長く話しすぎる、進捗を細かく語りすぎる、検証を重ねすぎる、サブエージェントを増やしすぎる──こうした挙動を、最初から運用ルールとして整えておく必要があります。

Anthropicの公式ドキュメント「Prompting Claude Opus 5」では、Opus 5固有のプロンプト調整として、応答の長さ、agentic work中の進捗報告、成果物の長さ、過剰検証、subagent delegation、self-correction、thinking disabled時の注意点が整理されています。

この記事では、その内容を中小企業のAI運用に引き寄せて、「Opus 5を業務で使うとき、プロンプトに何を書いておくべきか」という視点でまとめます。

Opus 5は「賢い」だけでなく「よく動く」モデルとして扱う

公式ドキュメントでは、Claude Opus 5は complex agentic coding and enterprise work 向けで、long-horizon agentic tasksに強みがあると説明されています。これは、単発の質問に答えるだけでなく、複数手順の作業を進める場面で力を出しやすい、という読み方ができます。

長い回答は、effortではなく「見える出力」の指示で制御する

Anthropicは、Opus 5のユーザー向け応答は以前のOpusモデルより長くなりやすいと説明しています。ここで重要なのは、effort parameterはモデルがどれだけ考えるかを調整するもので、見える回答の長さを確実に短くするものではない、という点です。

回答は短く、最初の1文で結論を述べてください。
通常は箇条書き3点以内にまとめ、詳しい説明はユーザーが求めた場合だけ追加してください。
注意書きや前提条件は必要最小限にしてください。

進捗報告は「毎回」ではなく、変化があった時だけでいい

Opus 5はagentic work中に、これから何をするかを語りやすいとされています。これは開発や調査では安心材料になる一方、顧客対応ツールや社内ワークフローでは、通知が多すぎて読みにくくなることがあります。

過剰検証を防ぐには、古い「必ず再確認」指示を見直す

公式ドキュメントでは、Opus 5は自分の作業を言われなくても検証しやすく、既存プロンプトに「非自明なタスクでは必ず最終検証」「subagentで検証」といった指示があると、過剰検証につながることがあると説明されています。

これは「検証しなくてよい」という意味ではありません。むしろ、検証の目的を絞るということです。公開、送信、削除、金額、法務、顧客回答など、人の判断に影響する部分は確認し、軽い整形や下書きの途中経過まで何度も再確認しない設計にします。

サブエージェントは「大きく独立した仕事」だけに使う

Opus 5は、以前のモデルよりsubagentに委任しやすいと説明されています。複数の独立した調査や大きなコードベース調査では便利ですが、小さな作業にまで分担を広げると、コストと時間が増えます。

i-Styleでは、subagentを「確認のために増やす」のではなく、調査対象が明確に分かれていて、並列に進めた方が早い時だけ使うようにしています。たとえば複数の公式資料を別々に読む、複数リポジトリの原因候補を分けて見る、といった場面です。小さな修正や単一ページの確認まで分担させると、かえってコストと確認量が増えるため、最初に使う条件を決めておく方が現場では扱いやすくなります。

thinking disabled時は、ツール呼び出しの漏れに注意する

公式ドキュメントでは、thinking disabled時に、ツール呼び出しが構造化されたtool_useではなく、見える文章として出てしまう場合や、内部XMLタグが見える出力に出る場合があると説明されています。多くのタスクでは、thinkingを有効にしたままlower effortでコストを調整する方がよい、というのが公式の推奨です。

社内ツールや顧客向けAIに組み込む場合は、単に「考えないで」と書くよりも、ツールが合わない時はそう言う、内部タグを出さない、必要なら短い一文を挟んでからツールを使う、といった実務的な指示に落とす方が安全です。

中小企業向けのOpus 5プロンプトテンプレ

最後に、公式ドキュメントの考え方を、業務ツールに入れやすい日本語テンプレにすると次のようになります。

あなたは業務支援AIです。

- 最初の1文で結論を述べる
- 通常は箇条書き3〜5点以内にまとめる
- 詳細説明は、ユーザーが求めた時だけ追加する
- 作業中の報告は、重要な発見・方向転換・ブロッカーがある時だけ行う
- 依頼範囲を勝手に広げない。明らかに別作業になる場合は一文で確認する
- 送信、公開、削除、購入、契約判断は人の承認を待つ
- subagentは、大きく独立した並列作業に限って使う
- 重要な誤りだけ短く訂正し、判断に影響しない細かな修正は黙って直す
- 内部タグやシステム向けのXMLタグを出力しない

i-Styleでは、プロンプトを「AIにお願いする文章」ではなく、業務の安全柵として見ています。モデルが強くなるほど、プロンプトは長く複雑にするより、どこで短く答えるか、どこで止まるか、どこから人に渡すかを明確にする方が効きます。

まとめ

• check_circleClaude Opus 5は、長い業務やagentic workに強い一方、応答や進捗報告が長くなりやすい
• check_circleeffortはthinking量の制御であり、見える回答の長さは明示的に指示する必要がある
• check_circle古い「必ず再確認」「必ず別エージェントで検証」指示は、過剰検証になる可能性がある
• check_circlesubagentは、大きく独立した並列作業に限定すると費用と時間を管理しやすい
• check_circle中小企業のAI運用では、「短く答える」「範囲を広げない」「人の承認で止まる」指示が特に効く