高性能モデルは、雑に頼んでもそれなりに動きます。だから最初は快適です。困り始めるのは、業務に組み込んでからでした。回答が長い。進捗を細かく語りすぎる。念のための確認を何度も重ねる。作業を細かく分担しすぎる。どれも悪意はなく、むしろ真面目さの表れです。
公式ドキュメント「Prompting Claude Opus 5」には、この手の挙動をどう整えるかがまとまっています。応答の長さ、作業中の進捗報告、成果物の分量、過剰な検証、担当の分け方、自己修正、そして思考を切ったときの注意点。賢いから任せる、だけでは足りないという前提で読むと、実務にそのまま落とせます。
先にまとめ
回答の長さは、思考量のつまみでは短くなりません。見える出力の形を直接指定します。進捗報告は毎回ではなく変化があったときだけ。古い「必ず二重チェック」という指示は、いまは過剰確認の原因になります。担当を分けるのは、大きくて独立した作業だけ。この4つを書き換えるところから始めます。
Claudeを業務ツールや社内AIに組み込みたい方に向けた内容です。性能の順位や料金だけを知りたい方には向きません。
「賢い」より「よく動く」モデルとして扱う
公式では、Opus 5は複雑な開発や企業の業務向けで、長い時間をかけて進める作業に強みがあると説明されています。単発の質問に答えるだけでなく、複数の手順を自分で進める場面で力を出しやすい、という読み方ができます。
よく動くということは、放っておくと動きすぎるということでもあります。人でいえば、仕事が速くて気が利く新人です。指示がないと、頼んでいない資料まで作ってくれる。悪いことではありませんが、業務では枠が要ります。
長い回答は、出力の形で抑える
公式は、Opus 5の応答が以前より長くなりやすいと説明しています。ここで大事な点が1つ。effort は「どれだけ考えるか」の調整であって、見える回答を短くする設定ではありません。
「低い設定にすれば短くなる」と考えると、思ったとおりになりません。代わりに、表示される文章の形を書きます。「通常は3点以内」「最初の1文で結論」「詳細は聞かれたときだけ」。この3行で、ずいぶん読みやすくなります。
【回答の形】 - 最初の1文で結論を書く - 本文は3点まで。箇条書きは1点1行 - 詳細・根拠は、聞かれたときだけ出す - 前置きと謝罪は書かない
最後の1行が効きます。丁寧な前置きは、読む側にとっては毎回同じ文章です。省いてよいと伝えておくと、本題に入るまでが速くなります。
進捗報告は、変化があったときだけ
Opus 5は、作業中にこれから何をするかを語りやすいとされています。開発や調査では安心材料になります。一方で、顧客対応の道具や社内の業務フローに組み込むと、通知が多すぎて読まれなくなります。
実務での線引きは単純です。開発中は細かく、運用中は変化があったときだけ。始めたとき、止まったとき、終わったとき。この3回で足ります。読まれない通知は、無いのと同じです。
古い「必ず再確認」の指示を見直す
ここが、いちばん実害の出やすいところです。公式では、Opus 5は言われなくても自分の作業を検証しやすく、既存のプロンプトに「必ず最終検証」「別の担当で検証」といった指示が残っていると、過剰な確認につながることがあると説明されています。
誤解しないでほしいのは、確認をやめる話ではないことです。確認の目的を絞るという話です。公開、送信、削除、金額、法務、顧客への回答。人の判断に影響する部分は確かめる。軽い整形や下書きの途中まで、何度も点検させない。
消してよい可能性が高い3行
「すべての回答を必ず二重チェックしてください」「必ず別のエージェントで検証してください」「作業前に毎回、詳細な計画を確認してください」。以前のモデル向けに書いた保険が、いまは待ち時間と費用に変わっています。まず1つ外して、結果を見てから決めてください。
プロンプトは書き足すばかりで、消す機会がありません。モデルが変わったときが、唯一の見直しどきです。
担当を分けるのは、大きく独立した仕事だけ
Opus 5は、以前より作業を分身へ任せやすいと説明されています。複数の独立した調査や、大きなコードの調査では便利です。ただ、小さな作業まで分担させると、費用と時間だけが増えます。
簡単な目安を挙げます。数分で終わる確認は自分で処理する。並列にできる大きな調査だけ任せる。確認のためだけに担当を増やさない。1人で足りるなら1人にする。そして、増やせる上限を先に決めておく。
i-Styleでも、分担は「調べる対象がはっきり分かれていて、並行したほうが速いとき」だけに使っています。複数の公式資料を別々に読む、複数の原因候補を分けて見る。そのくらいの粒度です。小さな修正まで分けると、確認する量のほうが増えました。
思考を切るときの落とし穴
費用を抑えたくて、思考の設定を切りたくなることがあります。公式では、そのとき道具の呼び出しが正しい形にならず、文章として出てしまう場合や、内部のタグが見える出力に混ざる場合があると説明されています。多くの仕事では、思考は有効にしたまま、粘り方の設定を下げて調整するほうがよい、というのが公式の勧めです。
社内ツールや顧客向けに組み込むなら、「考えないで」と書くより、実務的な指示に落とすほうが安全です。使える道具が無いときはそう言う。内部のタグを出さない。必要なら短い一文を挟んでから道具を使う。
そのまま使えるテンプレート
ここまでを、業務ツールへ入れやすい形にまとめます。
【回答】最初の1文で結論。本文は3点まで。前置きは書かない 【進捗】始めた・止まった・終わったの3回だけ報告する 【検証】公開・送信・削除・金額・契約に触れる箇所だけ確認する 【分担】並列にできる大きな調査のみ。確認のために増やさない 【停止】社外に出る直前と、個人情報に触れるときは必ず止まる
i-Styleでは、プロンプトを「お願いする文章」ではなく、業務の安全柵として見ています。モデルが強くなるほど、長く複雑に書くより、どこで短く答え、どこで止まり、どこから人に渡すかを決めるほうが効きます。
まとめ：強いモデルほど、枠が要る
回答の長さは出力の形で抑える。進捗は3回だけ。確認は影響のある箇所に絞る。分担は大きな仕事だけ。この4つを直せば、同じモデルでも扱いやすさが変わります。
冒頭の、長い回答も細かい進捗も過剰な検証も、どれも真面目さの表れでした。止めるのではなく、どこで発揮してほしいかを決める。人に対しても、たぶん同じことをしています。
参考: Prompting Claude Opus 5（Claude Platform Docs / 2026年8月28日確認）
AIプロンプトと業務設計、一緒に整理します
Claude Opus 5のような高性能AIを業務に入れる時は、モデル選びだけでなく、指示文、承認ルール、ログ、通知、権限設計まで含めて整える必要があります。i-Styleでは、AI活用を現場で続く形に落とし込む支援をしています。
お問い合わせページへarrow_forward
参考リンク
参考: Prompting Claude Opus 5（Claude Platform Docs / 2026年7月25日確認）
関連記事
