エージェント性の高いモデルはレビュー席に座らせる
モデルをよりエージェント的にする特性(スコープを広げる、頼まれずに自己検証する、出力が長くなる)は、範囲の狭い無人ワーカーでは不利になり、レビュアーでは強みになります。だからフローのワーカーは Claude Opus 4.8 で動かし、Opus 5 はレビューに回します。モデルの気質を、ベンチマークではなく役割に合わせるという話です。
スケジュール実行のエージェント群を Claude Opus 4.8 から Opus 5 に切り替えたところ、仕事の質が下がりました。派手にではありません。名前を付けられるまでに 1 週間を失う、あの微妙な形でです。応答は膨らみました。エージェントは誰も頼んでいないものを次々と変え始めました。単純なタスクに余計な手順が増えました。最初は、どこかで Prompt を壊したのだろうと思いました。
違いました。モデルは Anthropic が文書化しているとおりの振る舞いの違いを見せていただけです。問題は、私がそれを間違った席に座らせたことでした。
この特性は文書化されていて、バグではありません
リグレッションとして扱うのをやめ、Anthropic 自身の Opus 5 のガイドを読むと、すべての症状がそのまま書かれていました。既定の応答は以前の Opus モデルより長くなります。スコープ拡大とは、頼んでいない手順を足したり、タスクが何であるべきかについて自分の判断を持ち込んだりすることです。頼まれずに自分の作業を検証し、4.8 よりも進んでサブエージェントに委譲します。これらはリリースの文書化された特性であって、Prompt が壊れている証拠ではありません。より多くを行い、より多くを確認し、より多くを語る方へ傾く、エージェント的なモデルの「形」なのです。
その形を、タイマーで起きて狭いタスクを 1 つこなし、また眠る、範囲の狭い無人ワーカーに置いてみます。すると、これらの特性は不利に転じ得ます。ファイルを書くワーカーでは、スコープ拡大は本来のタスクの外側への変更を意味しかねません。頼まれない自己修正は既定では強みですが、古いモデルから引き継いだ「作業を検証せよ」という指示がそれを増幅し、Anthropic が警告する過剰検証になります。そして Token は積み上がります。語りが増えれば実行は長くなり、ドリフトの余地も広がります。範囲の狭いワーカーの価値は、割り当てられたことだけをきっちりやって止まる点にあります。私のスケジュールジョブでは、その線を保つのに Opus 5 は 4.8 より明示的なスコープ制御を必要としました。
同じ形を 1 つ隣の席に置くと、まさに望むものになります
ここが、気づくのに時間がかかった一手です。これらの特性が不利になるのは、あくまで役割との関係においてだけです。同じモデルを「作る」ではなく「レビュー」に向けると、一つひとつが強みに変わります。
スコープを広げるレビュアーは、見てくれと頼んでもいない隣接コードまで追い、あなたの変更が半分壊した隣の関数を見つけます。頼まれずに検証するレビュアーは、Commit メッセージの主張を信じる代わりに導き直します。指示が徹底を求めるとき、詳しさは報われます。作り手を壊すものが、批評家を作ります。
こうしてこのエージェント群は、スペック表では逆さまに見える非対称に落ち着きました。範囲の狭いワーカーは Opus 4.8 で動かし、Opus 5 はレビュアーとして動かす。 ワーカーは言われたことをやって止まります。レビュアーは歩き回り、疑い、検証しすぎます。他人の仕事を採点するときはその 3 つすべてが欲しく、自分の仕事をするときはどれも要りません。これは Opus 5 が弱いモデルだという話ではありません。Anthropic はまさにこの種のエージェント的で複数ファイルにまたがるコーディングに強いとうたっています。その気質が、私が最初に座らせた席とは別の席に合う、という話です。
いつもの助言をひっくり返す対処
たとえエージェント群に触れなくても、盗む価値のある細部が 1 つあります。Opus 5 が検証しすぎるときの Anthropic の解決策は、古いモデルから引き継いだ自己検証の指示を削除することで、これは「モデルに作業を二重チェックさせよ」という通常の助言をひっくり返す、と彼らは注記しています。Opus 5 に限っては、引き継いだ「検証してください」がモデル自身の検証を増幅し、結果を良くせずにコストだけを生み得ます。ただし、それをどんな高性能モデルにも一般化しないでください。Claude Fable 5 向けの Anthropic のガイドは逆で、長時間動く Prompt では明示的な自己検証を推奨しています。エージェント性だけでは正しい検証方針は決まらず、決めるのは個々のモデルです。長さについても同じ機微があります。冗長さは Prompting のレバーであって effort のレバーではありません。effort を下げると思考量は減りますが、モデルが書く量が確実に短くなるわけではありません。
正直なところ
これについての私の最初の原稿は、もっときれいで、もっと間違っていました。要は「新しいモデルの方が悪い」と言っていました。それを別々の 2 つのモデルファミリーのレビューに通したところ、両方が独立してその主張に異議を唱えました。一方は私が読み違えていた文書化済みの振る舞いを指摘し、もう一方は同じ週に私が加え、誤ってモデルのせいにした変更を捕まえました。単純な物語は、私ではない懐疑的な読み手との接触に耐えませんでした。
そこがまさに要点で、しかも二重にです。教訓は「新しい方が悪い」ではなく、モデルには気質があり、気質には正しい席がある、ということです。そしてこの主張の正しい版を見つけた方法自体が、それをエージェント性の高いモデルに渡し、最も得意なことをさせることでした。スコープを広げ、主張を疑い、私が何を間違えたかを教えてもらう、という。
