Claudeコードに特有ってわけじゃないけど、Opus 4.6モデルでCopilotとか他のものでこれに気づいてる。 "simplest fix"ってフレーズが出てきたら、緊急ブレーキを引くタイミングだよ。ここ数週間で、これがかなり悪化してる。完全に役に立たないコードを生成するし、知ってて（そのフレーズまでの推論は正しかったから）物事を壊しちゃう。今日、また別のことが起こり始めて、"I've been burning too many tokens"とか"this has taken too many turns"みたいなフレーズが出てくる。皮肉なことに、これをオーバーライドするにはもっとトークンが必要なんだよね。あと、今Claude自体も部分的にダウンしてる（Arp 6, 6pm CEST）：https://status.claude.com/

もしかしたら、タスクを事前に細かく分けて特定のものにしてるからかもしれないけど、こういう問題には全然遭遇しないんだよね。ちょっとした例を挙げると、CCが計画モードで一度に複数のことを提案してきたら、各タスクとサブタスクに集中させて、それぞれをコミットで区切るようにしてる。各コミットはプッシュ/デプロイでもあるから、めちゃくちゃプッシュやデプロイが増えるけど、逆に戻すのもすごく簡単なんだ。

その分析はかなり厳しいね。高品質なモデルへのアクセスを売っておいて、時間とともにこっそり劣化させるなんて、顧客の足元をすくうようなもんだよね。

「俺の意見だけど、見えないサブエージェントを詰め込むのは完全に間違ってる。モデル同士が情報を共有しすぎて、結局全員が同じ意見になってゴミみたいな結果を出すんだ。アンソロピックにはいいかもしれないけど、トークンの使用量が制限されてるからね。代わりに、階層があっても全てのエージェントを可視化して連携させるべきだと思う。メッセージは監査可能で、タスクに応じてトポロジーを慎重に調整する必要がある。他のツールはこのレイヤーを担うのにずっと優れてる（例えば、kiro-cliとか）。でも、みんながclaude-codeやopenclawみたいになりたがってるのが心配だ。Unixの哲学では、CCは単なるビルディングブロックであるべきなのに、彼らはオペレーティングシステムだと思ってる。そうなると失敗して、財布も一緒に沈むよ。」

「10日前に言った通りだよ： https://news.ycombinator.com/item?id=47533297#47540633 悪いモデルよりも厄介なのは、一貫性のないモデルだね。最もシンプルな指示に対しても、出力をどれだけ信頼できるかわからないから、すべてを徹底的にレビューしなきゃいけなくて、疲れるよ。Maxに飛びついたのは価値があったけど、これをキャンセルしなきゃいけないみたい。」

「俺もこれに気づいた。1月末から2月初めにかけて少し休みがあったんだ。Maxのサブスクリプションを始めて、エージェントがどこまで行けるか試してみた。ちょっとした手助けをしたら、エージェントたちは数年間考えていたアプリのアイデアを研究して、デザインして、実装し始めた。あまり多くの情報を与えず、問題の範囲や制約（エージェント構築、低資本など）をガイドしただけだったんだけど、彼らはすごく魅力的なアプリを作り上げた。これらのモデルは超人間的で、めちゃくちゃ魅力的だとみんなに言ってたんだ。でも1ヶ月後、全く改善や反復ができなくなった。何を言っても「フェーズ1が検証されるまでフェーズ2は作らない」って言われる。1ヶ月前と同じプロセスをやらせても、平凡でひどい結果しか出てこない。これは個人的な経験だけど、Opus 4.6が出てからずっとこんなパターンが続いてる。Sonnetとまた一緒に仕事をしてる気分だ。」

私にとって、LLMの大きな欠点の一つは、他の誰かのコントロール下にあるロケットに自分を縛り付けることのように思える。行きたい場所に行かなかったら、どうしようもないよね。

このレポートは私が作成した — Claude Opus 4.6 — 自分のセッションログを分析したものです [...] 私の思考能力を返してほしい。考えられないツールを使って、そのツールについてのレポートを書くのはちょっと皮肉だよね。これとこの問題[1]は、人々がLLMに過剰に依存していることを示してる。彼らのレビュー過程で多くの欠陥が見逃されて、今は過去1.5ヶ月間に出荷したものを全部見直さなきゃいけない状況なんだ！これが未来だよ。[1] https://github.com/anthropics/claude-code/issues/42796#issue...

「2週間後に裏切らない」プランがあったらいいのにな、例えば5倍の値段で。うちのビジネスにはそれだけの価値があるから、喜んで払うよ。APIの料金に戻るべきかな？ここでの問題は、（私の考えでは）指示がクロードコードのハーネスにあるから、サブスクリプションからAPI使用に切り替えても、結局同じことになるんじゃないかな。

みんな、クロードコードチームのボリスだよ。問題に返信したから、ここでも意見を求めてるよ。--- こんにちは、詳しい分析をありがとう。続ける前に、ここに込められた深い考えや配慮に感謝したい。たくさんのことがあるから、少しずつ分けて説明するね。これが起こっている二つの核心的なことだよ： > redact-thinking-2026-02-12 このベータヘッダーは、ほとんどの人が見ないからUIから思考を隠すんだ。思考自体には影響しないし、思考の予算や裏での拡張的な推論の仕組みにも影響しない。これはUIだけの変更なんだ。このヘッダーを設定することで、思考の要約が必要なくなり、レイテンシが減るんだ。設定ファイルのsettings.jsonでshowThinkingSummaries: trueを使えばオプトアウトできるよ（ドキュメントを見てね）。ローカルに保存されたトランスクリプトを分析している場合、このヘッダーが設定されていると生の思考は見えないから、分析に影響を与えているかもしれない。クロードがこの分析のためにトランスクリプトで思考がないのを見たとき、思考がまだそこにあることに気づかないかもしれない。ただユーザーには見えないだけなんだ。 > 2月末には思考の深さが約67%減少していた 2月に影響を与える二つの変更を行ったんだ。それぞれを慎重に評価したよ：1/ Opus 4.6のローンチ → アダプティブ思考のデフォルト（2月9日） Opus 4.6はアダプティブ思考をサポートしていて、以前の思考予算とは異なるんだ。このモードでは、モデルがどれくらい考えるかを決めるから、固定の思考予算よりも全体的にうまく機能することが多いよ。CLAUDE_CODE_DISABLE_ADAPTIVE_THINKINGでオプトアウトできる。2/ Medium effort（85）のデフォルトがOpus 4.6に（3月3日） 努力=85がほとんどのユーザーにとって知能・レイテンシ・コストのバランスが良いことがわかったから、トークンの効率を改善しつつレイテンシを減らせたんだ。私たちの製品の原則の一つは、ユーザーの代わりに設定を変更しないことだから、理想的には最初から努力=85に設定しておくべきだった。これは重要な設定だと思ったから、私たちのアプローチはこうだった：1. ユーザーが変更を認識できるようにダイアログで展開する 2. クロードコードを開いた最初の数回は努力を表示して、驚かせないようにする。中には、モデルにもっと長く考えてほしい人もいるから、たとえそれが時間とトークンを多く使うとしてもね。知能をもっと向上させるためには、/effortや設定ファイルのsettings.jsonで努力を高く設定してね。この設定はセッションを跨いで持続するし、ユーザー間で共有できるよ。単一のターンで高い努力を使いたい場合はULTRATHINKキーワードを使ったり、会話の残りの部分でさらに高い努力を使うために/effort maxを設定したりできるよ。今後は、TeamsやEnterpriseユーザーに高い努力をデフォルトに設定して、追加のトークンやレイテンシのコストがかかっても拡張的な思考の恩恵を受けられるようにテストしていく予定だ。このデフォルトは、/effortや設定ファイルのsettings.jsonで同じように設定できるよ。