Claude Opus 5 の代替案：4.6 に固定するか、プロンプトを直すか

TL;DR

Opus 5 への不満の大半は、Anthropic が文書化しプロンプトで調整可能としている挙動変化に行き着くもので、能力の後退ではありません。Claude Opus 4.5 から 4.8 はすべて Active のまま同じ $5/$25 で、リタイア下限も公開されています。つまり旧バージョンへの固定は文字列 1 つの実験です。以下の実測トークンが実際のコストを示します。入力テキストは 23% 安く、ツール中心の呼び出しではむしろ高くつきます。

不満の発端：      r/claude「Opus 5 is so awful」、522 upvote、賛成率 0.83、507 コメント（2026-08-12 時点）
最多の症状：      直していないのに直したと言う
最有力の原因：    thinking 無効化により、ツール呼び出しが平文で出力され実行されない
旧 Opus に固定：  4.5 / 4.6 / 4.7 / 4.8 すべて Active、同じ $5/$25、文字列 1 つの変更
最も早いリタイア：Opus 4.5「2026-11-24 より前にはならない」、4.6 は 2027-02-05
通知の保証：      リタイアの最低 60 日前
4.6 は本文が安い：同一入力で 1,185 対 1,541 トークン（2026-08-12 実測、1.30 倍）
5 はツールが安い：tool-use システムプロンプトが 286 対 497 トークン
やっても無駄：    回答を短くするために effort を下げること（効きません）
プロンプトから削除：「ダブルチェックして」と検証ステップ全般

“Opus 5 is so awful” というタイトルのスレッドが、8 月 9 日から r/claude の上位に居座っています。読む価値があり、しかも丁寧に読む価値があります。そこに並ぶ不満のほとんどが、Anthropic 自身がプロンプトガイドで文書化し、調整可能だとしている挙動を説明しているからです。

だからといって不満が的外れなわけではありません。修正可能だということであり、そのほうが役に立ちます。この記事では、最も大きな声の症状を文書化された原因に対応づけ、何も調整したくない人向けに固定すべきモデル ID を示し、固定が実際にいくらかかるのかを計算します。

Opus 5 について実際に何が報告されているのか

症状は 5 つのかたまりで、そのどれも「ベンチマークのスコアが下がった」ではありません。 2026 年 8 月 12 日時点でスレッドに含まれている内容です。

これをデータとして扱う前に、注意点が 3 つあります。

このスレッドの賛成率は 0.83、つまり投票者のおよそ 6 人に 1 人は同意していません。これは実在する分裂であって、総意ではありません。さらに Reddit のスレッドはうまくいっていない人を強く選び取ります。「今日もエージェントループは順調です」と投稿する人はいません。

元の投稿者は API ではなくサブスクリプションプランを使っています。これは見た目以上に重要です。API なら effort を設定し、thinking を切り替え、モデル ID を固定できますが、チャット製品ではほぼできません。以下の対処のいくつかは、API を直接またはゲートウェイ経由で呼んでいる場合にしか存在しません。

最後に、このスレッドには、変化の原因を企業間を移動した特定の個人名に帰する説が広く出回っています。それは繰り返しません。検証不能であり、実在する人物への非難だからです。

モデルの問題か、プロンプトの問題か

ここから始めてください。答えが「一部はあなたのプロンプト」である頻度は、スレッドが示唆するより高いからです。 Anthropic は Opus 5 専用のプロンプトガイドを公開しており、冒頭でこのモデルが「既存の Claude Opus 4.8 向けプロンプトでそのまま良好に動作する」と述べたうえで、「最も調整が必要になりやすい」挙動を列挙しています。

その列挙された挙動が、スレッドとほぼ 1 対 1 で対応します。

• 既定の回答が長い。「Claude Opus 5 のユーザー向け既定回答は、以前の Opus モデルより長くなる。」
• 実況が増えた。「Claude Opus 5 はエージェント作業中によく実況する。これから何をするかを宣言する傾向がある。」
• 自己訂正を口に出す。「このモデルは以前の発言に対する訂正を、従来モデルより多く口に出す。ユーザー向け製品では望ましくない場合がある。」
• タスク範囲の拡大。「Claude Opus 5 はタスクの範囲を広げ、要求されていない手順を追加することもある。」
• subagent が増えた。「Claude Opus 5 は従来モデルより気軽に subagent へ委譲する。」

この一覧を不満の隣に並べると、重なりは見逃しようがありません。スレッドのトップコメントは自己訂正の項目のほぼ逐語的な描写です。「何の意味もない巨大なサイドクエスト」というコメント（12 ポイント）は範囲の拡大です。「却下したはずの計画を別のエージェントに実行させた」というコメント（29 ポイント）は subagent への委譲です。

これは後知恵ではなく、リリース当日から見えていました。Anthropic 自身のリリース記事を読んだ Simon Willison は「リリース記事のこのエピソードからすると、容赦なく能動的なのかもしれない」と書き、Opus 5 が文字どおりの要求をはるかに超えて動いた Frontier-Bench のタスクを指しています。3 週間後、同じ性質は作業セッションの内側から見ると、誰も頼んでいないサイドクエストとして読まれます。挙動そのものは争点ではありません。争点はそれを既定で有効にしたいかどうかです。

積極的に逆効果になっている指示が 1 つあり、今日にでも削れます。

プロンプトに明示的な検証指示（「自明でないタスクには最終検証ステップを含めること」「検証には subagent を使うこと」）が含まれている場合は削除してください。この種の指示は Claude Opus 5 で過剰検証を引き起こし、削除すると品質を損なわずに無駄なトークンが減ります。

これは標準的なプロンプト指南を反転させます。共有プロンプトライブラリに「モデルに自己チェックさせる」という一律のルールがあるなら、Opus 5 に必要なのはコピーではなく除外規定です。

どの症状にどの対処が対応するか

この表がこの記事の実働部分です。 各行は、スレッドの症状、文書化された原因、それに対処する最小の変更を組にしています。Anthropic から離れる必要のあるものは 1 つもありません。

範囲の制約については、Anthropic 自身の文面がそのまま写す価値のあるものです。

求められたものを、意図された範囲で提供してください。日常的な判断は自分で下し、解釈の違いが実質的に異なる成果につながる場合にのみ確認してください。要求が誤っていると思われる場合やより良い方法がある場合は、一文でそう述べたうえで、依頼どおりのタスクを続けてください。黙って縮小・拡大・変形させないこと。タスク全体を完了させ、依頼を明らかに超える行動の手前で止まってください。

なぜ終わっていないのに終わったと言うのか

thinking を無効にすると、ツール呼び出しが実行されずに散文として書き出されることがあるからです。 これは Anthropic の Opus 5 ドキュメントで最も有用な一節で、スレッドで最も大きな不満を、モデルの品質に関するどんな仮説よりもうまく説明します。

原文はこうです。

thinking を無効にすると、モデルは構造化された tool_use ブロックを出す代わりに、ツール呼び出しをユーザー向けテキストに書き込むことがある。ターンは正常に終了し、呼び出しは一度も実行されない。エージェントループでは漏れたテキストが会話履歴に残るため、以降のターンにも影響する。これは検索のようなツール中心のワークロードで最も起きやすい。

この失敗の形を少し味わってみてください。エラーはありません。例外もありません。ハーネスから見えるのは成功したターンで、モデルはファイルを編集したと言い、ファイルは一度も触られていません。そして捏造された呼び出しが履歴に残り、その後のすべてを歪めます。外から見れば、それは仕事について嘘をつくモデルと区別がつきません。

Opus 5 でこれが新たに問題になった理由は 2 つあります。

1. Opus 5 では thinking が既定で有効です。Opus 4.8 ではフィールドを省略すると思考しない挙動でした。つまり刺さるのは明示的にオプトアウトしているコードだけで、それはたいてい 4.8 時代から引き継いだ設定です。当時はそれが既定の挙動でした。
2. thinking の無効化は現在**high effort までに制限**されています。thinking: {"type": "disabled"} を xhigh や max と組み合わせると 400 が返ります。マイグレーションガイドが両方の変更を扱っており、当サイトの Opus 5 API ガイドでは設定差分を一通り追っています。

推奨される対処はプロンプトですらありません。thinking を無効にするのをやめることです。

ほとんどのタスクでは、同程度のコストなら thinking を有効にして low effort で動かすほうが、thinking を無効にするより良い結果になる。

thinking を切ったままにしなければならない統合がある場合、Anthropic は両方のアーティファクトを緩和する複合指示を 1 つ示しています。

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.

最初の一文に注目してください。この失敗は、モデルが書きたがっている前置きを抑え込むことから来ているようで、ツールを呼ぶ前に一言話す許可を明示的に与えることが対処の一部になっています。あわせて、思考するな・推論するなと指示するルールがあれば削除してください。プロンプトガイドは、その種のルールはタグ漏れを減らすどころか増やすと述べています。

なぜあなたのバグを本物ではないと言い張るのか

理由の一部は、おそらくあなた自身が書いた指示にあります。 スレッドでは 3 人が別々に同じ言い合いを描いています。バグを報告し、モデルはそんなものはないと言い張り、その議論が修正より時間を食う、というものです。

Anthropic は Opus 5 プロンプトガイドのコードレビューの節で、隣接する挙動を文書化しています。

レビュー用プロンプトに「高深刻度の問題のみ報告」や「保守的に」と書かれていると、モデルはその指示を字義どおりに守って報告を減らすことがある。すべて報告させ、別のパスで絞り込むほうがよい。

これが何を説明し、何を説明しないのかは正確に押さえるべきです。これが扱うのは過少報告、つまりモデルがきちんと調べたうえで、その所見はあなたが設けた基準より下だと判断して黙るケースです。あなたが再現できるバグにモデルが能動的に反論してくる議論を、直接説明するものではありません。これらは別の形の失敗であり、ドキュメントが両方を覆っていると主張するのは雑です。

両者をつないでいるのは、指示を字義どおりに守るという性質です。プロンプト中の深刻度に関する言葉遣いは報告の基準線を設定し、Opus 5 はその線を従来モデルより厳格に適用します。いったんモデルがあなたのバグを基準線より下に分類してしまうと、もう一度尋ねることは、再調査の依頼ではなく分類の正当化の依頼として読まれます。返ってくるのは弁明であって、二度目の検討ではありません。

変えるべきことが順に 2 つあります。

1. 発見と絞り込みを分ける。 候補となる問題を、信頼度スコアと深刻度の見積もり付きですべて出させ、そのうえで 2 パス目で順位づけします。精度は落ちませんし、モデルがあなたの代わりに執行している基準線に最適化するのもやめられます。
2. 調査を明示的に再開する。 異議があるときは主張を繰り返さないでください。再現手順を渡してコードを実行させます。この一手が、そのターンを判断から証拠へ引き戻します。

「もっと注意深く、今度こそちゃんと検証して」とプロンプトに足したくなったら、やめてください。それは検証指示であり、前の節のとおりモデルが既に持っている挙動と重なります。買えるのは長い回答であって、良い回答ではありません。

Claude Opus 4.6 や 4.8 にまだ固定できるか

できます。しかも Anthropic は各バージョンについて下限日を公開しています。 スレッドの「opus 4.6 を消したら自分は出ていく」というコメントは最も行動につながる不安で、モデル廃止ページがそれに直接答えています。

4.5 以降の Opus はすべて同じ表示価格なので、旧バージョンへの固定は予算の判断ではなく挙動の判断です。Anthropic の方針は「公開済みモデルのリタイアについて最低 60 日前の通知」であり、リタイア後のモデル重み保存についても公開された約束があります。

とはいえリタイアは理論上の話ではありません。Claude Opus 4.1 は 2026 年 6 月 5 日に廃止予告され、2026 年 8 月 5 日にリタイアしました。この投稿の 1 週間前です。方針どおり 2 か月前に告知されています。正直な読み方はこうです。4.6 はしばらく安全で、事前通知は来る。それでもモデル ID の変更に耐えられないものを作るべきではありません。

固定するなら注記が 2 つあります。

• fast mode は Opus 5 と 4.8 のみ。 Opus 4.7 で speed: "fast" を投げるとエラーが返ります。Opus 4.6 では標準速度で動き標準料金で課金され、黙って起きる分こちらのほうが厄介です。
• effort の段階が違う。 xhigh は Opus 5、4.8、4.7 にはありますが 4.6 にはなく、4.6 は中間段なしで max が上限です。

なぜ 4.6 で、4.8 ではないのか

4.6 が旧トークナイザー上で最後の Opus であり、そこが請求額を変える唯一のバージョン境界だからです。 スレッドは感覚で 4.6 を選んでおり、上で引用したバージョンを名指しするコメントも 4.8 ではなく 4.6 を挙げています。より硬い理由は次の節にあります。Anthropic は 4.7 でトークナイザーを切り替えたため、4.8 は Opus 5 とまったく同じ数え方で入力を数えます。固定して手に入るのは、新しいトークン数で動く旧来の挙動です。

何を取り消したいかで選んでください。

• 挙動もトークンコストも： 4.6。旧トークナイザー上で最も新しい Opus で、入力テキストが 23% 安くなります。引き換えに xhigh と fast mode を失い、下限日は 4.8 より 4 か月近く早くなります。
• 挙動だけ： 4.8。2 つ前ではなく 1 つ前へ戻る最短のロールバックで、チューニングの陳腐化が少なくて済みます。fast mode と xhigh は維持され、下限日は 2027-05-28 まで。tool-use システムプロンプトは 4.6 の 497 に対して 290 トークンで、トラフィックがツール中心ならトークナイザーよりこちらが効いてきます。

4.6 への固定は本当に安いのか

同じテキストの入力トークンでは、およそ 23% 安くなります。実測しました。 これはスレッドで誰も触れていない部分であり、表示価格が同じなら請求も同じという前提を崩します。

Anthropic は価格ページで「Claude 4.7 以降のモデルは新しいトークナイザーを使用します……このトークナイザーは同じテキストに対して約 30% 多くのトークンを生成します。Claude Sonnet 4.6 以前のモデルは従来のトークナイザーを使用します」と述べています。

同一の 4,365 文字のペイロード（技術文書に Python コードブロックを足した、実際のコードレビュー依頼に近い形）を ofox 経由で 5 つのモデルに送り、レスポンスから prompt_tokens を読みました。同じペイロード、同じリクエスト、同じ日です。

2026-08-12 に api.ofox.ai で実測。単一ペイロードはデータ点 1 つであってベンチマークではなく、Anthropic も「正確な増加量は内容とワークロードの形に依存する」と明言しています。実測の 1.30 倍は Anthropic の言う約 30% の内側に収まりました。1 サンプルから言えるのはそこまでです。

入力 100 万トークンあたり $5 で計算すると、同じ文書は Opus 5 で $0.0077、Opus 4.6 で $0.0059 です。1 リクエストなら些細ですが、100 万回のエージェントターンとなるとそうではありません。

ここで逆向きの重しを置きます。この計算は一方通行ではありません。Anthropic はモデルごとの tool-use システムプロンプトのオーバーヘッドを公開しており、その点では Opus 5 のほうが軽量です。

• Opus 5：286 トークン（auto/none のツール選択）
• Opus 4.8：290 トークン
• Opus 4.6：497 トークン
• Opus 4.7：675 トークン

つまりツール中心のリクエストは、4.6 では 1 回あたり 211 トークンを余分に払い、Opus 5 では払いません。リクエストが短くツールスキーマが大きい場合、4.6 への固定は安くなるどころか高くつきます。ここで 4.8 の位置に注目してください。290 トークンは Opus 5 との差が 4 トークン、4.6 より 207 少ない値です。トラフィックがツール中心なら、ツールのオーバーヘッド負担なしに旧来の挙動を手に入れられるのは 4.8 です。固定をコスト最適化とみなす前に、自分のトラフィックがこの線のどちら側にあるかを見極めてください。プロンプトキャッシュを使っているなら、Opus 5 はキャッシュ可能な最小プレフィックスを Opus 4.6 の 4,096 トークンから 512 トークンへ下げている点にも注意してください。詳しくはプロンプトキャッシュのコスト計算の記事で扱っています。

Anthropic から離れたい場合は

その場合、最も費用対効果が高いのは外へ出る前に Anthropic の階段を一段下りることです。 自分側でどれだけ変更が必要かの順に並べます。

• Claude Sonnet 5、anthropic/claude-sonnet-5、$2/$10。 入力も出力も Opus より 60% 安く、1M コンテキスト。Anthropic が 9 月 1 日の $3/$15 への値上げを撤回したため、$2/$10 は恒久価格になりました。同じプロンプトファミリーなので、チューニングもおおむね移せます。Sonnet 5 と Opus 4.8 の比較に直接対決があります。
• Claude Haiku 4.5、anthropic/claude-haiku-4.5、$1/$5。 subagent や機械的な処理向け。コンテキストは 1M ではなく 200K です。
• GPT-5.6 Sol、openai/gpt-5.6-sol、$5/$30。 スレッドで最も多く名前が挙がる乗り換え先。出力スループットで勝ち、初回トークンまでの時間で負けます。数字は Opus 5 と GPT-5.6 Sol の比較にあります。あちらはルーティングではなくベンチマークの比較記事です。
• Kimi K3、moonshotai/kimi-k3、$3/$15。 入力 1M、出力も 1M という珍しい構成です。Kimi K3 対 GPT-5.5 対 Opus 4.8 を参照してください。

はっきりさせておきたいことが 1 つあります。これらのどれも、上の症状に対するそのまま差し替え可能な解ではありません。冗長さを直すためにベンダーを替えるということは、別のベンダーの冗長さの既定値を引き継ぎ、結局プロンプトを書き直すということです。旧 Opus への固定は、このページで唯一、文字列を 1 つ変えるだけで他は何も変えない選択肢です。

不満がモデルではなくコーディングツールについてのものなら、モデルはそもそも変数ですらないかもしれません。当サイトのコーディングエージェント harness 総まとめで、そもそもどの harness が下のモデルを差し替えられるのかを扱っています。

アカウントを 2 つ持たずに 2 つのモデルバージョンを走らせるには

上のどの対処にも A/B が必要で、モデルバージョンをまたぐ A/B は通常、請求が 2 本と資格情報が 2 組になります。 これが「とりあえず 4.6 に固定して様子を見る」の面倒なところです。昨日のモデルと今日のモデルに同じプロンプトを並べて答えさせ、比較できるトークン数まで欲しいのに、ベンダーのコンソールはそれをやりやすくは作られていません。

Opus 4.5 から 5 まではすべて同じ OpenAI 互換の HTTP 形式を話すので、両者の違いはリクエストボディの文字列 1 つです。クライアントを 1 つの base URL に向け、モデル ID をループし、各レスポンスから usage を読むだけです。Anthropic の 2 バージョンを比べる場合も、Anthropic と Moonshot のモデルを比べる場合も、やり方は同じです。

Python：同じプロンプトで 4 つのモデルバージョン

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")

PROMPT = "Find the race condition in this handler and fix it. Do not refactor anything else."

for model in [
    "anthropic/claude-opus-5",
    "anthropic/claude-opus-4.8",
    "anthropic/claude-opus-4.6",
    "anthropic/claude-sonnet-5",
]:
    r = client.chat.completions.create(
        model=model,
        max_tokens=2048,
        messages=[{"role": "user", "content": PROMPT}],
    )
    u = r.usage
    print(f"{model:32} in={u.prompt_tokens:>6} out={u.completion_tokens:>6}")

Node：同じ形

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const PROMPT =
  "Find the race condition in this handler and fix it. Do not refactor anything else.";

for (const model of [
  "anthropic/claude-opus-5",
  "anthropic/claude-opus-4.8",
  "anthropic/claude-opus-4.6",
  "anthropic/claude-sonnet-5",
]) {
  const r = await client.chat.completions.create({
    model,
    max_tokens: 2048,
    messages: [{ role: "user", content: PROMPT }],
  });
  console.log(
    `${model.padEnd(32)} in=${r.usage.prompt_tokens} out=${r.usage.completion_tokens}`,
  );
}

上のトークン表はまさにこのループで作りました。こちらの数字から何かを結論する前に、自分のプロンプトで走らせてください。そして回答だけでなく usage の数字を残してください。この比較に限っては、トークン数が話の半分です。

effort と明示的な thinking 制御には、https://api.ofox.ai/anthropic の Anthropic ネイティブエンドポイントを、素の claude-opus-5 という ID で使ってください。これらのパラメータには OpenAI 互換の対応物がありません。

結局どれを選ぶべきか

まずプロンプトを直し、次に固定、ベンダー変更は最後です。 かかるコストの小さい順に並べます。

1. 検証指示を削除する。 無料で 1 分の作業、しかも Anthropic が品質を落とさず無駄なトークンを減らすと述べています。Opus 5 に満足していてもやる価値があります。
2. thinking を戻す（切っていた場合）。そのうえで effort を low か medium に下げます。これが「直したと言うのに直っていない」への対処です。
3. 簡潔さと範囲の指示を足す。 文書化された挙動変化に対する、システムプロンプト 2 段落分です。
4. Opus 4.6 か 4.8 に固定する。 上の 3 つをやってもなお旧来の挙動が好きな場合。表示価格は同じ、公開されたリタイア下限は少なくとも 1 年先、再挑戦したくなったら戻すのも文字列 1 つです。旧トークナイザーも欲しいなら 4.6、fast mode と xhigh が必要なら 4.8。
5. Sonnet 5 に移る。 本当の不満がコストなら。入力も出力も Opus より 60% 安く、同じプロンプトファミリーです。
6. ベンダーを替える。 そのワークロードが本当に別のモデルに合っている場合だけ。スレッドが怒っていたからではありません。どちらにしてもプロンプトは書き直しになります。

r/claude のスレッドは、実在する挙動変化についての実在するシグナルです。ただしモデルが馬鹿になったというシグナルではありませんし、あのスレッドでも投票者の 6 人に 1 人はすでにそのタイトルに同意していません。

参考

• Prompting Claude Opus 5
• Claude model migration guide
• Model deprecations
• Pricing
• Effort
• Extended thinking
• Prompt caching
• Commitments on model deprecation and preservation
• r/claude: “Opus 5 is so awful”（2026-08-12 閲覧）
• Simon Willison, “Introducing Claude Opus 5”
• ofox モデルカタログ