Opus5優秀だけど今までと動きが違って扱いづらい。
でもこれ、モデルの問題じゃない。前のモデルで正解だった頼み方と設定が、そのまま残っているのが原因だ。
AnthropicがOpus5専用のプロンプトガイドを公式に公開した。
そこには、これまで正解とされてきた指示が今は逆効果になると書いてある。
知らないまま使い続けると、同じ作業に前より多いトークンを払い続けることになる。
こんな状態に心当たりないか
- 返答が長くて読むのがしんどい
- 作業中の実況が細かすぎる
- 頼んでない範囲まで勝手に手を広げられる
- サブエージェントを何体も立ち上げてコストが跳ねる
- 書かせたドキュメントが毎回無駄に長い
1つでも当てはまるならこの記事は役に立つ。
全部、公式ガイドに「こう指示すれば直る」と書いてある挙動だ。
この記事では公式が挙げた変化と対処を11個わかりやすく紹介する。
最後に今日から気をつける点だけをまとめたので、ブクマして使い倒してほしい。
ここで宣伝ですが、現在Claude Codeの教科書や導入方法、マネタイズ方法までをセットにした55大特典を無料配布中です。以下のリンクからすぐ受け取れるので、まだ受け取ってない方はぜひ受け取ってください。
↓
https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet
それでは本題です。
**
何が公開されたのか
Anthropicの公式ドキュメントに、Opus5だけを対象にしたプロンプトのページが追加された。
機能の一覧ページではない。「Opus5はここが前のモデルと違うから、こう指示しろ」に絞って書かれた実務用のページだ。性能が上がった箇所も、プロンプトに関係するものだけが挙がっている。
公式は前提としてこう書いている。Opus4.8向けに書いたプロンプトのままでも十分動く。ただしチューニングが必要になりやすい挙動がある、と。
つまり動くから気づかない。気づかないまま無駄を払い続けるのが一番損なパターンだ。
①返答が長い。思考量を下げても喋る量は減らない
Opus5の返答は前のモデルより長い。これは公式が認めている。
ややこしいのは、effort（思考量のつまみ）を下げても喋る量は確実には減らない点だ。公式に「effortが制御するのは考える量であって喋る量ではない」と明記されている。
長さを削りたいなら長さを明示的に指示するしかない。公式が載せている指示がこれだ。
1返答は短く、要点だけにしてください。2前置きや但し書きは最小限にして、答えそのものに文字数を使ってください。3説明を頼んだときは、詳しく知りたいと僕が言わない限り、要点のまとめだけ返してください。
CLAUDE.mdやシステムプロンプトが長い人は、これを書いた上で末尾にもう一度短く念押しを置く。公式もこのやり方を推奨している。
1<tone_preference>2出力は簡潔に。3</tone_preference>
長い指示書の真ん中に埋もれた指示は効きが弱い。末尾のリマインダーはそれを補う。
設定を書かない人はもっと簡単だ。長いと感じたその場で「短く」と一言返す。
②作業中の実況が多すぎる
Opus5は作業中によく喋る。これから何をするかを毎回宣言する傾向があり、1メッセージあたりの出力も前のモデルより長い。
減らし方は「実況するな」ではない。いつ、どんな形で報告してほしいかを書く。
1作業を始める前に、これから何をするかを一文だけ言ってください。2作業中の報告は、重要なことが分かったときと方針を変えるときだけにしてください。3終わったら結論から書いてください。最初の一文で「何をしたか」「何が分かったか」に答えて、細かい話はその後に回してください。
逆に実況を増やしたい人も同じやり方でいい。公式は「してほしくないことの禁止よりも、してほしい形の実例を見せるほうが効く」と書いている。
③書かせたドキュメントが毎回長い
会話の長さとは別に、ファイルに書き出すもの（レポート・mdのドキュメント・まとめ）も長くなりやすい。
AIに調査結果をmdで残させている人はここが効く。長さの基準を1行入れておくだけで変わる。
1ファイルに書き出す文書は、必要な長さに収めてください。2中身は省かなくていいですが、埋めるための章・同じ内容の要約の繰り返し・お決まりの前置きで長くしないでください。
④「必ず検証して」「ダブルチェックして」は不要
ここが一番大きい。
先に言っておくと、設定に何も書いていない人はそのままでいい。この項目は「書いてあるなら消す」と「都度の指示で言わない」の両方の話だ。
Opus5は言われなくても自分の作業を検証する。だから公式は、プロンプトに検証を命じる指示が入っているなら削除しろと書いている。名指しされているのはこの類だ。
- 「非自明なタスクでは必ず最後に検証ステップを入れて」
- 「サブエージェントを使って検証させて」
- 「答える前にダブルチェックして」
これらはOpus5の自前の検証と重なって過剰検証を起こす。公式の記述では「削除すると品質を落とさずに無駄なトークンが減る」となっている。品質とのトレードオフではなくただの無駄が消える。
古いハーネスに検証ステップを足す仕組みが残っている場合も同じ扱いになる。
一方で、Opus5は前のモデルより訂正の実況が増えている。「さっきの発言を訂正します」が細かく入るのが邪魔なら消すのではなく絞る指示を足す。
1前に言ったことを訂正するのは、その間違いで僕のコードや判断が変わるときだけにしてください。2訂正は短く言って、そのまま作業を続けてください。3何も変わらない些細な言い間違いは、黙って直して進めてください。
**
⑤頼んでない範囲まで勝手に広げる
Opus5は自分の判断で作業の範囲を広げることがある。頼んでいない手順を足す。何をすべきかを自分で決め直す。
範囲を狭く保ちたい作業では、スコープを明示的に縛る。
1頼んだことを、頼んだ範囲でやってください。2細かい判断は自分で決めてください。確認を挟むのは、解釈によって出来上がるものが大きく変わるときだけにしてください。3僕の頼み方が間違っていそうなときや、もっといい方法があるときは、一言だけ指摘してから、頼んだとおりに進めてください。4勝手に範囲を狭めたり広げたり、別のものに変えたりしないでください。5頼んだ範囲は最後までやりきってください。明らかに頼んでいないことはやらないでください。
これを入れると「1ファイル直して」でプロジェクト全体まで変更される事故が減る。
⑥サブエージェントを立てすぎる
Opus5は前のモデルより気軽にサブエージェントへ委任する。
委任自体は悪くない。公式も、本当に独立した大きい作業では効くと書いている。書き手と検証役を分ける形も機能するし、エージェント同士が互いの作業を上書きする事故も少ないと評価されている。
問題は小さい作業に使ったときだ。台数分のコストと時間がそのまま乗る。
1サブエージェントに任せるのは、大きくて独立していて並列にできる作業だけにしてください（例: 広い範囲にまたがる複数ファイルの調査）。2自分で数回で終わる作業は任せないでください。
設定を書かない人でも使える手がある。頼むときに体数を自分で言うことだ。「サブエージェントは使わず自分でやって」か「使うなら○体まで」を最初のメッセージに入れる。
⑦レビューで「重大なものだけ教えて」と書くと報告が減り見落とすリスクが上がる
Opus5はコードレビューが強い。1回で本物のバグを見つける率が高く、追加で挙げてくる指摘も誤検知より本物が多いと公式は書いている。低い思考量でも精度が落ちにくいので、レビュー時に軽く1回、後でじっくり1回という運用ができる。
ただし落とし穴がある。レビュー用のプロンプトに「重大な問題だけ報告して」「保守的に見て」と書いていると、Opus5はその指示に文字どおり従って報告を減らすことがある。
公式の推奨は「全部報告させて、絞るのは別の工程でやる」だ。出させてから捨てる。最初から出させないのは損になる。
頼み方はこれでいい。「気になるところを全部出して。重要度をつけて並べて」。どれを直すかは出てきたリストを見てから自分で決める。
⑧effortはlowとmediumを主軸にする
Claude Codeでは「/effort」で思考量を切り替えられる。Opus5で使えるのはlow・medium・high・xhigh・maxの5段階で、デフォルトはhighだ。maxだけはそのセッション限りで、他の4つは次のセッションにも引き継がれる。
公式の推奨はこうだ。highから始めて、品質が落ちないところはlowとmediumを積極的に使いコストと待ち時間の主コントロールにする。重いコーディングやエージェント作業だけxhighに上げる。
副業勢に関係が深いのは、ここを触っていないと軽い作業にまで高い思考量を払い続けることになる点だ。ファイル探しや簡単なテキスト生成にhighは要らない。
前のモデル時代の設定をそのまま引き継いでいる人は、一度自分の作業で測り直せと公式も書いている。
今日やることは1つだ。軽い作業を始める前に「/effort medium」と打つ。重い実装に入るときだけ「/effort high」に戻す。これだけで待ち時間と消費が変わる。
**
⑨仕様は最初に全部渡して放置する
ここから先は、性能が上がったせいで頼み方を変えたほうがいい話だ。
公式はOpus5を「難しいコーディングに一番強い」と位置づけている。得意分野として挙がっているのは複数ファイルにまたがる機能追加、大きめのリファクタ、機能をひと通り仕上げきる作業だ。スタブや「ここは後で」のプレースホルダを置いて逃げない、とも明記されている。
肝心なのは指示の出し方のほうだ。公式の書き方はこうなっている。タスクの仕様を最初に全部渡して、あとは走らせておくのが一番性能が出る。
小出しに指示を足していく使い方は、Opus5では損になる。頼む前に条件を書き切るほうが速い。
最初のメッセージに入れるのはこの4つでいい。触っていいファイル、どこまでやるか、守ってほしい約束、終わったと判断する条件。走り出してから条件を足すのが一番遅い。
1行修正のような軽い作業でも普通に使えるが、前のモデルとの差が出るのは重い作業のほうだと公式は書いている。
⑩画像まわりの自作の回避策は不要
図表・ドキュメント・図の読み取りと、UIやフロントエンドの見た目の再現が強くなった。
公式がわざわざ書いているのは、前のモデル向けにプロンプト側で仕込んだ画像系の回避策は見直せという点だ。もう不要になっている可能性がある。
もう1つある。画像で精度が一番出るのは、切り出しや目視確認をモデル自身にやらせるツールを持たせたときだ。思考量を上げるよりツールを持たせるほうが費用対効果が高いと明記されている。
Claude Codeで使うなら、画像を貼って感想を聞く形をやめる。画像ファイルの置き場所を渡して、自分で開いて拡大して確認しながら直させる。思考量を上げるより先にこっちをやったほうがいい。
⑪スプレッドシートとスライドはスタイルを渡す
複数シートにまたがるスプレッドシートを、単純ではない数式込みで作れるようになった。スライドも構造の整ったものが出る。
ここでの公式の指示は1つだけだ。守らせたいスタイルやテンプレートがあるなら、それをプロンプトに入れる。
毎回できあがった資料の見た目を直している人は、直す作業を増やすより先に渡す情報を増やしたほうが早い。
一番手っ取り早いのは、前に自分で作った資料を1つ渡して「この体裁に合わせて」と言うことだ。色やフォントを言葉で説明するより、実物を1つ見せるほうが早い。
まとめ
- 返答とドキュメントの長さは思考量では減らない。長さは明示的に指示する
- 検証・ダブルチェックを命じる指示は削除する。Opus5は言われなくてもやる
- スコープの縛りとサブエージェントの委任条件は書いたほうがいい
- レビューは「全部出させて後で絞る」。最初から絞らせない
- 思考量はlowとmediumを主軸に。
- 仕様は小出しにせず最初に全部渡して放置する。重い作業ほど差が出る
モデルが変われば、正解だった頼み方も古くなる。
去年おぼえたコツが、今は待ち時間とコストを増やしているだけかもしれない。
今日は1つでいいからブクマして試していってほしい。
僕は普段AIの最新情報やAIを活用したマネタイズ方法について発信しています。この記事が役に立ったらぜひフォローしてください。
最後に、
現在Claude Codeの教科書や導入方法、マネタイズ方法まで含んだ55大特典を無料配布中です。まだの方はぜひこちらから受け取ってください。
https://utage-system.com/line/open/cwgwX1a35XDK?mtid=FNAamIuYaEet
参考ページ
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
