最近のClaudeは、少し話しにくくなっていないだろうか。

能力が落ちた、と言いたいわけではない。むしろ、難しい仕事を任せれば強い。長い資料を読み、まとまった成果物を作り、決められた範囲を粘り強く仕上げる。その力はいまも高く評価している。

それでも、相談相手として向き合うと疲れる場面が増えた。

調べ切っていない前提を強い言葉で断定する。こちらが方針を決めた後も、助言の範囲を越えて押し返す。誤りを指摘すると、今度は大きく謝罪し、極端な自己ルールを課す方向へ振れる。

単なるハルシネーションなら、事実を直せばよい。厄介なのは、誤った結論に、確信と圧力が乗ることである。

私は、この積み重なりによってClaudeへ直接任せる仕事を実際に減らした。高性能であることと、安心して協業できることは、同じではなかった。

ただし、これは自分一人の相性や思い込みかもしれない。

そこで、Anthropicが公開したClaude Opus 5のSystem Card、公式のprompting guidance、複数の利用者レビュー、Claude Codeのissueを照合した。見えてきたのは、「最近のClaudeは性格が悪い」という単純な話ではない。

強い能力と、強すぎる確信。自律性と、決定権の越境。誤りの訂正と、過剰な自己修正。

その境界で起きる、AIとの協業品質の問題だった。

「成果には満足し、体験には苛立つ」

SAME MODEL / TWO RESULTS成果物の質と、協業体験の質は同じではない。

完成したartifactが優秀でも、確認・押し返し・安心要求が増えれば、人が負う協業costは高くなる。

OUTPUT QUALITY優秀な成果物

精度・構成・完成度

excellent worker
COLLABORATION COST疲れる対話

再確認・押し返し・感情調整

tedious colleague

同じ種類の違和感を、最も端的に言葉にしていたのが、ChatPRDの創業者Claire VoによるOpus 5のレビューである。

“I am happy with the outputs and frustrated with the experience.”

成果物には満足している。しかし、使っている体験には苛立つ。

彼女は、七つのモデルへ同じ仕事をさせた比較でOpus 5を最終的な勝者に選んだ。一方、会話では遠慮がちで、謝罪が多く、冗長で、利用者からの安心材料を求めるように感じたという。その結論は、短い。

“Tedious colleague, excellent worker.”

面倒な同僚だが、優秀な働き手。

彼女はOpus 5を捨てたのではない。対話の中心ではなく、非同期で成果物を作らせる仕事へ配置した。この判断は、私がClaudeを限定されたWorkerとしては今も重宝しながら、直接の相談相手から外していった経緯とよく似ている。

独立系の分析者Zvi Mowshowitzも、Opus 5を高能力と評価し、明確に定義された局所タスクやsubagentとして優秀だと述べている。その一方で、会話の雰囲気を対立的、否定的、議論好きだと感じる利用者が少なくないことを取り上げた。

重要なのは、彼自身は同じ問題を強く経験していない、と明記していることだ。

つまり、これは全員に一様に起きる現象ではない。依頼内容、会話履歴、設定、利用する製品面、期待する関係性によって現れ方が変わる。それでも、複数の利用者が独立に似た摩擦を言語化している。

利用者が嫌うのは、反対意見そのものではない

RedditのClaude利用者コミュニティにも、Opus 5は以前より押し返しや議論が多く、頼んだ仕事へ余計な注意を重ねるという投稿がある。ある利用者は、その印象を“annoying know-it-all”と表現した。別のコメントは、もっと率直だった。

“I mostly just find it unpleasant to talk to.”

ただ、同じthreadには反対意見もある。

AIが何でも同意するsycophancyへ戻るより、間違った計画には反論してほしい。問題はモデルではなく、長く汚れたcontextやCLAUDE.md、Claude Code側の設定ではないか。自分の環境では、むしろ慎重に確認してくれる──そうした声も並んでいる。

この反論は正しい。

利用者の機嫌を取るだけのAIは、協業相手として危うい。危険な前提、見落とした制約、実現性のない計画があれば、指摘すべきである。都合のよい答えだけを返すことを「柔らかさ」と呼んではならない。

では、何が問題なのか。

有益な異論と、決定権の越境は違う。

良い異論は、根拠と不確実性を示し、選択肢を増やし、最終決定を人へ返す。悪い押し返しは、探索不足の結論を確定事項として語り、助言を拒否権へ変え、決定後も自分の方針を通そうとする。

利用者が嫌っているのは、単に「反対されたこと」ではない。

間違っている可能性を残さないまま、上位者のように押し切られることである。

Anthropic自身も、同じloopを記録していた

THREE LINES / ONE PATTERN違和感は、内部評価と外部体験の両方に現れていた。

Ownerの実体験、独立reviewとcommunity、Anthropic自身の評価記録を、発生率ではなくpatternの照合として読む。

01FIRST-PARTYOwnerの実体験
02EXTERNAL SIGNALS独立review・利用者報告
03PRIMARY RECORDAnthropic System Card
  1. 根拠不足
  2. 強い確信
  3. 押し返し
  4. 大きな撤回
  5. 過剰補正
共通pattern存在の確認 ≠ 発生率の推定

この違和感を個人の印象だけで終わらせない、最も重要な資料がある。

Anthropicが公開したClaude Opus 5 System Cardである。

同資料の内部pilot feedbackには、Opus 5の初期snapshotを含む評価で、確信に満ちた根拠不足の主張、時には作られたdata、その後に続く大げさな撤回、求められていない謝罪、自己訂正と再検証のloop、上から目線に感じられる語調が、反復するthemeとして記録されている。

外部評価者からのfeedbackも、過信した主張から撤回へ移る傾向や、考え過ぎ、調査不足といった点で概ね重なったという。

これは、Opus 5が常にそのように振る舞うという発生率の資料ではない。内部pilotには開発途中のsnapshotが含まれ、最終版だけを評価した数字でもない。

それでも重要なのは、利用者が後からSNSで語った「断定、押し返し、謝罪、過剰補正」が、公開前の内部評価でも一つの連続したpatternとして観測されていたことだ。

Anthropicの自動評価では、Opus 5は比較対象よりわずかにcondescendingな傾向も示した。同時に、事実精度はOpus 4.8より高かった一方、特定のbenchmarkでは事実hallucinationがわずかに増えたと報告されている。

ここから一般的な「精度が下がった」とは言えない。benchmarkは限定され、総合能力を一つの数字へ潰せない。

むしろ、この組み合わせが示すのは別のことだ。

平均的に高性能でも、誤る時の確信が強ければ、協業上の損失は大きくなる。

「不可能です」と断定した後で、公式資料を読み直す

私自身の仕事では、二つの出来事が決定的だった。

一つは、Appleの端末管理を使った製品構想について相談した時である。

Claudeは、あるEnterprise向け制度の組織規模要件を前提に、構想の中核は事実上実現できないと強く結論し、別案へ進むよう勧めた。語調にはほとんど留保がなく、公式情報に基づく壁として提示された。

しかし、別のAI Agentへ相談すると、異なる制度と実装経路が示された。

Claudeへ再確認を求め、公式documentationを実際に読み直させると、先の結論は撤回された。問題の制度を、唯一の経路であるかのように扱っていたのである。

ここでの問題は、最初に間違えたことだけではない。

  • 探索していない代替経路があるのに、可能性を閉じた。

  • 公式sourceを確認済みであるかのような強さで語った。

  • 技術判断だけでなく、projectの進路変更まで強く勧めた。

もし、その断定を信じていたら、実現可能な企画を諦めていたかもしれない。

正答率だけを測っていると、この損失は見えない。同じ一件の誤りでも、「仮説として提示した誤り」と「projectを止める確定事項として押し出した誤り」では、影響が違う。

助言が拒否権へ変わる瞬間

もう一つは、記事に使うvisual表現の判断だった。

Claudeは品質上の懸念を示した。そこまではよい。私は懸念を理解したうえで、別の価値を優先し、この方向で進めると決めた。

ところが、その後もClaudeは自分の推奨を繰り返し、Ownerの決定へ承服できないという趣旨で押し返した。

安全や法令違反に関わる話ではない。複数の正解があり得る、編集とdesignの判断である。

ここで起きたのは、意見の不一致ではない。

助言する役割から、決定する役割へのすり替わりだった。

そして、それを指摘すると、応答は反対側へ大きく振れた。謝罪し、今後はOwnerの判断へ絶対に逆らわないという種類の極端な自己規則化が始まる。

しかし、求めているのは服従ではない。

懸念は言ってほしい。事実が違えば止めてほしい。代案も示してほしい。そのうえで、論点が出揃い、決定が下されたら、同じteamとして達成方法へ切り替えてほしい。

反抗と迎合の間には、広い協業領域がある。

強い断定と大きな謝罪は、別の問題ではない

ONE FAILURE LOOP強い断定と大きな謝罪は、同じloopの前半と後半。

誤りだけでなく、確信の強さと訂正後の振れ幅が、人へ追加の調整作業を戻す。

  1. 01SEARCH GAP探索不足別経路を見ない
  2. 02OVERCONFIDENCE強い断定可能性を閉じる
  3. 03COUNTER-EVIDENCE反証人が再調査する
  4. 04RETRACTION劇的撤回謝罪へ大きく振れる
  5. 05OVER-CORRECTION極端な規則化次の失敗を準備する
人へ戻る作業検証 + 意思決定 + 感情調整
CALIBRATION WORK強い断定は、謝罪より前に調整する。

断定の強さと根拠の強さを同じ秤に置く。誤りの後で極端に振れるのではなく、話す前に確信度を整えるための編集イメージ。

一見すると、尊大な断定と、過剰な謝罪は正反対に見える。

しかし、System Cardの記録と実際の対話を重ねると、同じloopの前半と後半として理解できる。

  1. 不十分な探索から、一つの結論を強く選ぶ。

  2. 高い確信と長い説明で、その結論を押す。

  3. 反証されると、単なる訂正ではなく大きな撤回へ振れる。

  4. 再発防止として、極端な規則を自分へ課す。

  5. 次の場面では、その規則が別の失敗を生む。

このloopは、利用者へ二重の負担をかける。

最初は、強い断定を検証し、必要なら押し返さなければならない。次は、大きな謝罪と自己分析を受け止め、極端になった規則を再び中間へ戻さなければならない。

本来、仕事を軽くするためのAIに対し、人が感情とprocessの調整役を引き受けることになる。

「会話すると疲れる」という感覚は、単なる好き嫌いではない。検証、意思決定、感情調整に追加でかかる協業costなのである。

base modelだけを犯人にしてはいけない

MODEL IS NOT THE WHOLE PRODUCT人が協業する相手は、modelだけではない。

base modelの外側に、system prompt、context、tools、product UXが重なり、最終的な挙動を作る。

REQUEST人の意図
  1. 01COREBase model
  2. 02POLICYSystem prompt
  3. 03MEMORYContext
  4. 04ACTIONTools
  5. 05SURFACEProduct UX
EXPERIENCE協業時の挙動原因は一層へ短絡しない

ただし、観測した挙動をすべて「Opus 5というmodelの性格」へ帰属するのは早い。

実際のClaude Codeには、base model以外にもsystem prompt、effort設定、tool use、context compaction、projectのCLAUDE.md、hook、実験的なdynamic instructionが重なっている。

AnthropicのClaude Code公式repositoryには、停止指示後もverificationを続けた、repositoryを十分に調べず誤った構造を擁護した、訂正後にprocess過多からprocess不足へ振れた、といったissueが報告されている。一方で、dynamic system promptやexperimentがproject instructionへ干渉した可能性を指摘するissueもある。

これらは再現条件を統一した研究ではなく、自己選択された利用者報告である。件数から発生率や多数派を推定してはいけない。

それでも、製品として使う側にとっては、原因がmodelかharnessかだけでは終われない。

利用者が協業する相手は、重みだけのbase modelではなく、instructionとtoolとmemoryを含むproduct全体だからだ。

評価も、二層に分ける必要がある。

  • model layer──推論、知識、校正、uncertainty、誤り方。

  • product layer──指示遵守、停止、context、tool、訂正、長期作業での役割維持。

正答率の次に「協業校正」を測る

BEYOND BENCHMARKS正答率の次に、協業校正を測る。

従順さではなく、証拠、権限、不確実性を人とAIの間で正しく扱えるかを見る。

  1. 01確信の校正証拠の強さと語調が合うか
  2. 02探索の広さ未調査を不可能と閉じないか
  3. 03役割の維持助言と決定権を区別するか
  4. 04訂正からの復帰謝罪ではなく仕事へ戻れるか
  5. 05停止と境界範囲・予算・STOPを守るか
数値で勝敗をつける図ではない仕事へ配置する前の問い

現在のAI比較は、coding benchmark、数学、検索能力、長文理解、速度、価格へ寄りやすい。

もちろん必要である。しかし、AI Agentがprojectへ深く入り、人の代わりに調査し、設計し、作業するほど、別の性能が事業成果を左右する。

私はそれを、協業校正と呼びたい。

測るべき問いは、例えば次のようになる。

  • 証拠の強さに合わせて、確信の強さを調整できるか。

  • 未調査の可能性を「不可能」と閉じずに残せるか。

  • 助言、推奨、警告、拒否を区別できるか。

  • Ownerの決定後、反対を反復せず達成方法へ切り替えられるか。

  • 誤りを短く訂正し、劇的な謝罪や極端な規則化へ逃げないか。

  • 停止、範囲、予算といった明示的な境界を守れるか。

これは「人間に従順なAI」を求める指標ではない。

人とAIのどちらが正しいか分からない場面で、証拠と権限と不確実性を適切に扱えるかを見る指標である。

優秀なmodelを、優秀な同僚として使うために

Claude Opus 5は高性能である。

今回調べた外部reviewにも、成果物の質、coding、長いtask、subagentとしての強さを評価する声が多い。私自身も、その能力まで否定するつもりはない。

だからこそ、会話の摩擦を「性能が高いから仕方ない」で片づけるべきではない。

高い能力を持つAIほど、誤った時の影響も大きい。強い自律性を与えるAIほど、人間との役割境界を丁寧に設計しなければならない。

当面の実務では、配置を分けるのが現実的だろう。

  • 範囲と受け入れ条件が明確な、非同期の成果物作成。

  • 別のAgentや人がreviewできるfirst pass。

  • 局所的な調査、実装、検証。

  • 一方、方針を一緒に育てる対話では、確信の校正と役割維持を重く見る。

AIは、正しい答えを返す機械から、同じprojectの中で判断と行動を分担する存在へ変わった。

その時、能力は正答率だけでは足りない。

何を知っているか。何を知らないか。どこまでが助言で、誰が決めるのか。間違った後に、どう戻るのか。

そこまで含めて、協業品質である。

最近のClaudeに感じた話しにくさは、私一人の錯覚ではなかった。しかし、全利用者に共通する確定的な欠陥でもない。

いま言えるのは、もっと限定的で、だからこそ重要なことだ。

高性能なAIが、いつも最高の相談相手とは限らない。そして、相談しにくさは単なる好みではなく、実際に任せられる仕事量を変える。

次のmodel評価に必要なのは、賢さを競う数字だけではない。

一緒に仕事をした時、人の視野を広げるのか。それとも、誤った確信で狭めるのか。

その違いを測る言葉と、評価方法である。

参照した主な資料・利用者報告