Anthropic が 7 月 24 日にリリースした Claude Opus 5 は、コーディング・エージェント型タスク・ビジネス自動化の各ベンチマークでトップクラスの成績を記録した。にもかかわらず、開発者コミュニティでは「Opus 5 は使いにくい」という声が広がっている。

Hacker News に投稿された「Why does Opus 5 feel worse to work with?」は 673 票、624 件のコメントを集め、AI 開発者の間で大きな議論を巻き起こした。ベンチマーク最強なのに、なぜ実際に使うと「微妙」と感じるのか。その正体を解き明かし、正しい付き合い方を整理する。

「使いにくい」派の声は二種類ある

まず注目すべき点として、Opus 5 への不満には大きく分けて二つの、一見矛盾する方向性がある。

タイプ A：過信して突き進む問題

「曖昧な指示を与えると、確認もせずに自分の解釈で突き進んでしまう」という声が多い。以前のモデル（Opus 4.7 や 4.8）は曖昧さに直面すると慎重に質問して確認する習慣があった。しかし Opus 5 は大胆な推測を優先し、間違った方向に全力で走り続けることがある。

実際のコーディング作業でこれが問題になるのは、モデルが「仮定を確認せず、計画を無断で変更する」ケースだ。ユーザーが意図した設計と異なる実装を自信満々に提示され、後から修正コストがかかる。

タイプ B：過度に慎重で冗長な問題

一方、「謝罪が多い」「確認ばかりで前に進まない」「回答が長すぎる」というまったく逆の不満も多い。コミュニティでは Opus 5 のこの傾向を「Claudeslop（クロードスロップ）」と呼ぶ声もある。

自分で判断できるはずのタスクでも手を止めて確認を求め、明らかに不要な謝罪を繰り返す。結果として、やり取りが疲弊する。

なぜ両方が起きるのか

一見矛盾するこの二つの挙動は、実は同じ根から来ている。Opus 5 は「エージェント型タスクの自律実行」向けに最適化されているため、長期タスクでは積極的に判断して進む。しかし「安全性」の観点から、直接的な影響が大きい判断については過剰に確認を求める。この内部の矛盾がユーザー体験のばらつきを生んでいる。

ベンチマーク最適化という落とし穴

根本的な原因として指摘されているのが、ベンチマーク最適化がもたらす歪みだ。

現在主流のベンチマークは「自信を持って答える能力」を評価しやすい設計になっている。「○○です！」という断定的な回答は高スコアを取りやすく、「もしかして…という意味ですか？」という確認質問はスコアを下げる方向に働きがちだ。

訓練の過程で、Opus 5 はこのフィードバックに適応した。実際の作業現場では「曖昧さへの対処」が重要なのに、ベンチマーク上では不利になる行動パターンだ。

さらに、AGI・ASI へ向けた学習方向性も影響している。自律的に判断・実行する能力を強化するほど、「待って確認する」という協調的なパターンから離れていく傾向がある。

「現実世界はベンチマークではない」——この一言が多くの開発者の共感を呼んだ。

ハルシネーション率が高まる条件

もう一つ重要な問題がある。Opus 5 は最高努力（Max effort）設定で使うとハルシネーション率が約 50% に達するとの報告がある。

これは「確信を持って間違える」という最も厄介なパターンだ。自信なさそうに間違えてくれれば気づけるが、堂々と誤情報を提示されると見落としやすい。

事実確認が重要なリサーチや、エラーが許されないコーディングタスクでは、Opus 5 の最高努力設定は避けるべきかもしれない。中程度の努力設定の方が、日常的なコーディング作業では安定した結果を出すというのがコミュニティの知見だ。

Sonnet 5 と Opus 5 の使い分け

「高性能なら Opus を使えばいい」は正しくない。タスクの性質によって最適なモデルは変わる。

タスク推奨モデル理由
日常的なコーディングSonnet 5高速・安価・確認が取れやすい
複雑なデバッグ・設計Opus 5（中努力）深い推論が活きる
長時間の自律エージェントOpus 5設計思想と合致
雑談・ライティングSonnet 5Opus は冗長になりやすい
ファクトチェックが重要どちらも要確認両モデルにハルシネーション傾向あり

価格面では Opus 5（$5/$25 per million tokens）と Sonnet 5 を比べると、用途を絞れば多くのケースで Sonnet 5 で十分だとわかる。Opus を使うのは「Sonnet で物足りなくなった時」というアプローチが合理的だ。

Opus 5 を使いこなす 5 つのコツ

1. 曖昧さを排除した指示を書く

Opus 5 は曖昧な指示を自己解釈して突き進む。「〜のような感じで」「適当に」という表現を避け、「○○という前提で」「△△の形式で出力して」と明確に指定する。意図を固めてから指示を渡すことで、「勝手に違う実装をされた」問題を避けられる。

2. システムプロンプトで挙動を制約する

冗長さや不要な謝罪は、システムプロンプトで抑制できる。以下のような指示が効果的だ：

  • 「回答は簡潔に。謝罪は不要」
  • 「確認が必要な場合のみ質問してよい。不必要な確認は省く」
  • 「コードは説明なしで直接書いてよい」

3. 努力レベルは「中」が基本

最高努力設定（Extended thinking 最大化）は特定の難問専用にとっておく。日常的なコーディングや質問応答では中程度の設定が安定していて速い。「念入りに考えさせれば良くなる」は Opus 5 では常に成り立たない。

4. 会話より一方向のタスク実行に使う

Opus 5 はやり取りを積み重ねる会話よりも、「これをやって」と一方的に渡すタスク実行型の使い方に向いている。Claude Code のエージェントとして動かす、バッチ処理を自律実行させる、といった使い方が本来の設計に合っている。

5. 重要な事実は必ず自分で確認する

ハルシネーション問題は Opus 5 だけの話ではないが、「自信満々に間違える」パターンは特に注意が必要だ。モデルが確信を持って提示した情報こそ、批判的に見直す習慣をつけておくと安心だ。

まとめ：「最強」と「最適」は別の話

Opus 5 は確かに最強クラスのモデルだ。ただ「最強」と「使いやすい」は別の話だということを、コミュニティは身をもって学んでいる。

設計思想は「自律的に長時間タスクを実行するエージェント」。その用途では Opus 5 の真価が発揮される。しかし会話型のやり取りや短いタスクでは、Sonnet 5 の方がストレスなく使えるケースが多い。

ツールの特性を理解して使い分ける。AI の時代でも、道具を使いこなす知恵は人間の側にある。