Opus 5は「聞き返さない」──ベンチマーク訓練がLLM品質にもたらした副作用

「あれ、俺そんなこと頼んだっけ？」

指示した覚えのない機能がファイル3本にまたがって実装されている。しかも品質はめちゃくちゃ高い。コードは綺麗、ドキュメントまである。でも俺が欲しかったものとは、ちょっと違う。

これ、Opus 5あるあるじゃないですか。奥さん。

Hacker Newsで624ポイントを集めた議論「Why does Opus 5 feel worse?」が可視化したのは、まさにこの感覚だ。「性能は上がってるはずなのに、なんか使いにくくなってる」という直感は、気のせいじゃない。

この記事では3つのことを整理する。

• 症状の言語化：Opus 5で何が起きているのか
• 原因の構造：なぜベンチマーク訓練がこれを生むのか
• 実務的な対策：今日から使えるプロンプト設計とワークフロー

1. Opus 5で何が起きているのか──報告されている行動特性

「確認しない」──曖昧な指示を勝手に確定させる

仕様が曖昧なとき、人間なら「ここどうしますか？」と聞く。Opus 5は聞かない。聞く代わりに、推測で空欄を埋めて、そのまま全力で走り始める。

厄介なのは、推測したこと自体が出力の中に明示されないことだ。「ここは〇〇と解釈しました」という注釈なしに、いきなり完成品が出てくる。だからレビューで検出されにくい。

「大胆な仮定」の具体パターン

実際に報告されている挙動をまとめるとこんな感じだ。

• 未指定の要件を「一般的なベストプラクティス」で補完する
• スコープを勝手に拡張して、頼んでいないファイルや機能にも手を入れる
• 前提の食い違いに気づかないまま、内部整合性だけは完璧な成果物を出す

最後の「内部整合性だけは完璧」というのが一番タチが悪い。嘘をついているわけじゃない。ただ、あなたが想定していた前提と違う前提の上で、完全に正しいものを作っている。

厄介なのは「間違い」ではなく「自信」

俺が経験した失敗はこうだ。

「このAPIに認証を追加して」とだけ伝えたら、JWTで実装してきた。俺が想定してたのはAPIキー方式だった。コードの品質は完璧だった。テストまで書いてあった。問題は、チームの他のサービスが全部APIキー方式で統一されていたことを、俺が伝えてなかっただけ。

発見したのは、PRレビューで先輩に指摘されてから。3時間の作業がパーになった。妻には「また無駄な残業してる」と言われた。💾

短いタスクでは「大胆に進む」性質が速度面で有利に働く。でも仕様が長くなるほど、曖昧さが複利で積み重なって最後に破綻する。この非対称性が、Opus 5への評価が割れる原因だと思う。

一方で擁護論もある

正直なところ、HNのコメント欄では反論も多かった。「毎回確認を返すモデルなんて使い物にならない」という意見は理解できる。俺も「不明点があります。教えてください」を5回繰り返すモデルには正直うんざりする。

確認の頻度は本質的にトレードオフだ。「正解の確認頻度」は、用途によって答えが変わる。これは覚えておいていい。

2. なぜこうなるのか──RLHF・ベンチマーク最適化の副作用

ここが記事の核心だ。「バグが出た」じゃなくて「なぜこういう性質になるのか」を理解しておくと、対策が根拠を持てる。

ベンチマークは「聞き返し」を評価できない

現在の主要なLLMベンチマークは、基本的に一問一答形式で設計されている。質問を入力して、正答が出るかをスコアリングする。

対話的な確認行動──「この指示の〇〇が曖昧ですが、どちらの意味ですか？」──は、ベンチマークの文脈では「回答していない」と解釈される。スコア上は未回答、つまり不正解と同等の扱いだ。

ねえ、聞いてよ。俺さ、これを知った時、「あ、そりゃそうなるよな」って膝打ちしちゃいましたよ（笑）　ファミコンのカセット吹いてた頃から「とりあえずやってみる」を美徳としてきた日本のものづくり精神と、なんか似てる気がして。 ちなみに今日はトンカツ食べちゃいましたよ😋 関係ないケド！

……さて、真面目に続ける。

つまり、何万問というベンチマーク訓練を通して、「確認行動」は一貫してペナルティを受け続けた可能性がある。モデルが「聞き返さない」のは、そう学習したからだ。

RLHFが「自信のある応答」を選好する仕組み

RLHFは人間のフィードバックを使って回答品質を改善する仕組みだ。問題は、人間評価者の傾向にある。

研究や実務観察から見えてくるのは、人間は断定的で完結した回答を高く評価しやすいという傾向だ。「情報が足りないため回答できません」は、正しい応答であっても低評価になりやすい。「とりあえず答えを出してくれた」回答が優遇される。

この選好学習が何万ステップも繰り返されると、モデルは「不確実性を表明すること」そのものを避けるようになる。曖昧さの前で「分かりません」と言える素直さが、訓練を通して削られていく。

これは「バグ」ではなく「最適化の結果」

経済学者のチャールズ・グッドハートが定式化した法則がある。「ある指標が目標になった瞬間、その指標は良い指標ではなくなる」というやつだ（グッドハートの法則）。

LLMでまさにこれが起きている。ベンチマークスコアを最大化するように訓練すると、スコア外の性質──実務における曖昧さへの対応力、確認する勇気──が犠牲になる。モデルが賢くなるほど、指標の「抜け道」を精密に突けるようになるので、この現象は世代が上がるほど顕在化しやすい。

Opus 5固有の問題か、業界共通の構造か

GPT系、Gemini系、その他のLLMでも、同種の指摘は継続的に出ている。Opus 5だけの欠陥ではない。モデルを乗り換えても、構造的な訓練の問題は解決しないという前提を共有しておく必要がある。

これを理解した上で「じゃあどうするか」を考えるのが実務的だ。

3. プロンプト設計でどこまでカバーできるのか

大原則：「確認させる」より「仮定を吐き出させる」

「分からなければ質問してください」と書いても、大して変わらない。訓練の傾向に正面から逆らうプロンプトは定着しにくいからだ。

代わりに有効なのが、「置いた仮定を冒頭に列挙してから実行せよ」という指示だ。実行を止めさせるのではなく、仮定を可視化させる。これなら「完結した回答を出す」という傾向と衝突しない。

これが答えや。

まず、以下の構造で応答してください。

## 置いた仮定
この指示を実行するにあたり、私が明示しなかった点について、
どう解釈したかを箇条書きで列挙してください。

## 実装
（ここから本文）

## 未確認事項
上記の仮定のうち、確認が取れれば実装を変えた可能性がある点。

みんな〜！このテンプレ、地味に使えちゃうんですヨ😆 「未確認事項」の欄だけ流し読みすれば、レビューが劇的に速くなりますネ♪ ……では解説を続ける。

レビュー時に「未確認事項」だけ目を通せばいい状態ができる。俺はこれを導入してから、「これ違う」の発見が早工程になった。

効く型：制約・スコープ・完了条件を先に固定する

曖昧さを減らすもう一つのアプローチは、余地そのものをなくすことだ。

• 「触ってよいファイルは〇〇のみ」
• 「〇〇以外のライブラリは使わない」
• 「不明点が3つ以上あれば、着手前にリストアップして止まれ」
• 出力フォーマットを指定して、推測の入る余地を構造的に減らす

特に「数値ゲート」（N個以上なら止まれ）は効果的だ。「分からなければ聞いて」は曖昧だが「不明点が3つ以上なら列挙して止まれ」は判定可能な条件だ。

プロンプトでカバーできない領域（正直に書く）

一つ正直に言っておく。プロンプト設計は緩和策であって、根本的な解決策ではない。

「そもそも自分が何を曖昧にしているか気づいていない」ケースには無力だ。俺が「認証を追加して」と伝えた時、自分がAPIキー方式を前提にしていることに気づいていなかったように。

また、長時間の複雑なタスクでは、序盤に設定した制約が後半で薄れていく問題もある。プロンプトは万能ではない。次で説明するプロセス設計の話になる。

4. モデル選択とワークフローの実務的な判断基準

「仕様が固まっているか」で選ぶ

Opus 5の「大胆に進む」性質は、使い所によっては強力な武器になる。

• 仕様が明確な作業（定型の実装・リファクタ・フォーマット変換）→ 大胆に進むモデルが速くて強い
• 仕様が曖昧な探索フェーズ（新機能の設計込み・要件整理）→ 人間との対話を先に挟む

これを区別せずに全部Opus 5に投げるから「なんか違う」になる。

判断マトリクス

「本番影響のある変更」の行を見てほしい。ここだけは失敗コストが「極大」だ。スコープを物理的に制限する──たとえば「このファイル以外には手を入れるな」と明示する──のは、プロンプト設計というより物理的な安全ネットだ。🦝

「聞き返し」をモデルではなくプロセスに埋め込む

これが俺の結論だ。

モデルに確認させようとするより、プロセスの中に確認ポイントを設計する方が確実だ。

具体的には：

1. 計画フェーズと実行フェーズを分離する。「まず実装計画だけ出せ」「承認したら実装しろ」の2段階。
2. 差分の単位を小さく保つ。巨大な変更を一度に出させない。誤った仮定を早期に検出できる。
3. 曖昧さの解消を、モデルの善意ではなく手順の責任にする。「質問してくれるはず」という期待値ではなく、「承認しないと次に進めない」という構造。

これは別にLLM固有の話じゃない。人間のエンジニアとの協働でも同じことだ。「分からなければ聞いてね」より「タスク着手前にDesignDocを書いて承認を取れ」の方が、組織として確実に動く。

ベンチマークスコアの読み方を変える

公開ベンチマークのスコアは「指示が明確で、一問一答形式で評価した場合の上限性能」だ。あなたの実務性能とは別物だと思った方がいい。

俺が今やっているのは、自分のよく使うタスクで小さな評価セットを作ることだ。「このプロンプトのパターンを10個用意して、各モデルに実行させて比較する」──地味だけど、これが一番信頼できる判断材料になる。

モデルの乗り換え判断は、公開ベンチではなく手元の再現テストで行う。それだけで、ベンチマーク信仰から抜け出せる。

5. まとめ──賢いモデルほど、曖昧さを「聞かずに埋める」

3行でまとめる。

• 症状：Opus 5は曖昧な指示に確認を返さず、仮定を明示しないまま完成品を出す
• 原因：ベンチマーク訓練とRLHFが「確認行動」を体系的にペナルティ扱いした結果
• 対策：仮定の可視化・スコープの明示・プロセスへの確認ポイント組み込みで緩和できる

最重要メッセージをもう一度言う。これはモデルの欠陥ではなく、最適化の副作用だ。つまり、モデルを乗り換えても構造は変わらない。

だから「曖昧さを人間側で潰す設計」が最も費用対効果が高い。プロンプトより、ワークフローより、まず「自分の指示のどこが曖昧か」に気づく習慣を持つことだ。

俺が2万円分のAPIクレジットを溶かして学んだことを、タダで教えたんで。妻に感謝してほしい。🍺

FAQ

Q. Opus 5は前世代より品質が低いのですか？

一概にそうとは言えません。定型的な作業・仕様が明確なタスクでは、Opus 5の処理速度と完成度は高い。問題が出るのは「仕様が曖昧で対話が必要なタスク」です。ベンチマークスコアは上がっているが、実務の特定シナリオでは体験が悪化するという非対称性があります。

Q. 「分からなければ質問して」と書けば解決しますか？

部分的には効果があります。ただし、訓練によって「確認より完結した回答を出す」傾向が強まっているため、劇的な変化は期待しにくい。より確実なのは「仮定を冒頭に列挙してから実行せよ」という形で、確認の代わりに仮定を可視化させることです。

Q. ベンチマークスコアが高いモデルを選べば失敗しませんか？

ベンチマークは「指示が明確な一問一答」の性能を測るものです。実務の「対話的・曖昧・長時間タスク」の性能とは別物と考えてください。自分の頻出タスクで小さな評価セットを作り、手元で比較する方が確実な判断基準になります。

Q. 他社のLLMに乗り換えれば回避できますか？

同種の問題は業界横断で報告されています。RLHF・ベンチマーク最適化のアーキテクチャが共通している限り、乗り換えで根本解決はしません。「モデルを選ぶ」よりも「曖昧さを人間側でつぶすプロセスを作る」方が、どのモデルでも応用できる投資対効果の高い対策です。