「Claudeが劣化した」「以前より使えなくなった」という声を、SNS上で見かけることが増えました。
しかし、本当にAIモデルそのものが劣化しているのでしょうか。
Reddit のClaudeAIコミュニティで、興味深い投稿が話題を集めました。
「毎週のように不満スレッドを目にするが、いったいどんなワークフローで使っているのか」という問いかけです。
投稿者はFortune 500企業のソフトウェアエンジニア。
そして、Claudeの最新版(Opus 4.7)について「むしろ良くなっている」と語っていました。
この投稿には1000以上の支持がつきました。
そして、コメント欄では実務家による白熱した議論が交わされたのです。
本記事では、その議論から見えてきた「不満の正体」と、その対処法をまとめます。
1. 投稿者の問題提起：「あなたのワークフローは大丈夫ですか」
投稿者の主張はシンプルでした。
AIが生成したコードは、人間がレビューする責任を持つべきだ、という考え方です。
「AIにコードを書かせたら、それはあなたのコード」「バグがあれば、それはあなたのバグ」
この姿勢を10年のキャリアで貫いてきた、と投稿者は語っています。
AIの非決定性(同じ入力でも異なる出力が返ること)を理解する。
その上で、決定論的な処理にはコードの監査を組み合わせる。
並列で走らせるタスクは、別フォルダや別ブランチで隔離する。
最後に手動で調整を加える。
この投稿者にとって、Opus 4.7はむしろ推論力が向上したモデルでした。
高性能ソフトウェアの開発で、大きく貢献しているそうです。
具体的には、アセンブリ解析やアルゴリズム上の検討で時間短縮に役立っているとのこと。
それなのに、なぜ「Claudeが壊れた」「すべてが台無し」という声が絶えないのか。
2. 寄せられたコメントの大勢：「不満は、ワークフローを語っている」
コメント欄では、投稿者に同意する声が多数を占めました。
最も支持を集めた指摘のひとつが、こちらです。
コードベースを理解している人は、AIに渡すタスクを小さなチャンクに分解しています。
一方で、丸投げのプロンプトを書く人もいる。
例えば「Amazonより良いものを間違いなく作って」のような指示です。
そして、後者の人たちが不満を述べているのだ、という分析でした。
別のコメントには、心に刺さる短い一言がありました。
不満を訴えるスレッド自体が、その人の作業のやり方を物語っている、というものです。
少し辛辣ではあります。
それでも、コメント欄全体の総意に近い見解と言えるでしょう。
3. 「言葉の精度」という落とし穴
特に印象的だった議論が、プロンプトで使う言葉の精度についてのものでした。
あるコメントは、ドライバーの比喩でこの問題を説明していました。
プラスドライバーを穴あけパンチ代わりにする人がいる。
柄の部分をハンマー代わりに使う人もいる。
そういう人は「ねじを締めて」と言うだけです。
どんなねじでどの工具を使うべきか、本質的には理解していません。
LLMへの指示も、まったく同じ構造です。
「直して」と「エンドツーエンドの統合をデバッグして」では、求められる動作がまったく違います。
「検索機能を追加して」と「このリストの値を使ったコンボボックスを作って」も同じ。
伝わる情報量が大きく異なるのです。
別のコメントが、興味深い具体例を紹介していました。
動画処理の文脈では、「タイムスタンプ(timestamp)」ではなく「タイムコード(timecode)」を使うといい。
その方が、より良い結果が返ってくるそうです。
なぜなら、実際の映像のプロは「タイムコード」を使うから。
LLMは正しい単語を入力されると、ベクトル空間の正しい領域から応答を引き出せる。
そういうわけです。
LLMは文字通り「言語モデル」です。
だからこそ、正しい言語を使うことが致命的に重要なのです。
4. Opus 4.7 は「推測しない」モデル
なぜOpus 4.7で違和感を覚える人が増えたのか。
コメント欄での有力な仮説は、こうでした。
新しいモデルは、より高い精度を期待するように設計されている。
そして、より少なく推測する。
つまり、曖昧なプロンプトに対して空気を読んで補完する力を、あえて抑えているのです。
10年以上の経験を持つあるシニアエンジニアは、こう表現していました。
Opus 4.7は、ユーザー側により強い責任を求めてくる。
具体的には、正しい枠組みと文脈を整える責任です。
賢くなくなったわけではありません。
むしろ、矛盾する要件に直面したら明確化を求めてくる。
要件を満たすための近道があれば、それを取る。
「AIスロップ(雑に生成されたAIコード)を毎日量産している人」の立場に立ってみると、こう感じるはずです。
「この道具はバカだ。私の意図を理解しない。詳しく説明したのに、予想外のことをする」と。
しかし実態は違うかもしれません。
自分が何を求めているのか、自分自身が把握できていなかっただけ。
そういうケースが多い、という指摘でした。
5. 杖と魔法使いの比喩
非エンジニアからのコメントも、深い洞察を含んでいました。
マーケティング職のあるコメント投稿者は、自分の経験をこう振り返ります。
Claudeのおかげで、作業速度は3倍に、効果は2倍になった。
しかし、それはAIが登場する前から、自分の仕事の本質を理解していたからだそうです。
そして、こんな比喩を紹介していました。
優れた杖は、未熟な魔法使いを名魔法使いに変える力を持たない。
逆に、優れた魔法使いは、ボロボロの杖でも使いこなしてしまう。
別のコメントが、これに気の利いた皮肉を返していました。
「優れた杖は、未熟な魔法使いに自分の足を吹き飛ばさせる。そして、それを得意げに自慢させることもできる」と。
笑いを誘いつつ、本質を突く指摘ですね。
6. Claudeを「ジュニア開発者」として扱う
コメント欄で繰り返し出てきた助言が、Claudeをジュニア開発者として扱うという考え方でした。
ジュニア開発者がプルリクエストを出してきたら、レビューせずにマージしますか。
普通はしません。
同じ姿勢でAIのコードに向き合うべきだ、という主張です。
具体的なワークフローとして、以下のような実践が紹介されていました。
- プランモードで先に計画を立てる
- プロジェクトのドキュメントとエージェント用ルールを作成し、実装後に更新する
- 開発ブランチで作業し、マージ前にレビューする
- ひとつのフィーチャーにつき、ひとつのワークツリーを使う
- 別のモデル(例えばCodex)に、Claudeが書いた差分をレビューさせる
これを実行すれば、「AIが書いたコード」が「自分が責任を持つコード」に変わります。
7. 反論も存在する：トークン消費と研究用途
ここまで「ユーザーの問題だ」という論調を紹介してきました。
ただし、コメント欄には反論もあったことに触れておきます。
第一の反論は、トークン消費に関するものです。
Opus 4.7はOpus 4.6と比べて、明らかにトークンを多く消費する。
週次の利用上限がある契約プランでは、これは死活問題です。
「賢くなった」と言っても、コスト増に見合う賢さなのか。
そういう疑問が残るわけです。
第二の反論は、用途による相性です。
あいまいで探索的な研究タスクでは、Opus 4.6の方が向いていたという声が複数ありました。
つまり、「何を作るべきかをまだ模索している段階」での話です。
一度作るべきものが決まれば、Opus 4.7は完璧に走ります。
けれども、ゼロから方針を考える局面では、より「推測しない」設計が裏目に出るというのです。
第三の反論は、特殊な要件への対応です。
あるユーザーは、「乱数を真のエントロピーから取りたい」という特殊な要件を伝えました。
すると、Opus 4.7は何度も決定論的な乱数で代替しようとしたそうです。
普通のケースなら正しい判断でしょう。
しかし、特殊な要件には対応しきれない局面もあるのです。
8. 「文脈の腐敗」という別の視点
ある冷静なコメントは、不満が増えている別の要因を指摘していました。
第一に、最初の感動が薄れる現象です。
AIに初めて触れたときの魔法は、千回目にはもう魔法ではなくなります。
慣れるほど、限界も見えてきます。
第二に、文脈の腐敗です。
プロジェクトを始めた当初は、コードベースは小さい。
コンテキストウィンドウにもきちんと収まっていました。
しかし時間が経つにつれ、コードは複雑化していきます。
そして、3つの異なる画面に微妙に違う「削除」ボタンが並ぶような状態になる。
すると、AIも以前は理解できていたことを「これは何ですか」と聞き返すようになるのです。
第三に、利用上限の問題です。
以前なら、間違ったコードもすぐ修正できました。
それが今は、トークン上限に到達してしまう。
半端な実装のまま、5時間や1週間も待たされる事態が起きます。
これがフラストレーションを増幅させている、という指摘でした。
9. チームに展開すると、話が変わる
個人で完璧なワークフローを持っていても、チームに展開すると別の問題が発生します。
あるコメントが、この点を深く分析していました。
一人のエンジニアが、質の高いCLAUDE.mdを維持しているとします。
これは、Claudeに渡すプロジェクト固有の指示書のことです。
ただし、そのパターンは自動的にチーム全体には広がりません。
共有コンテキストは、誰かが「生きているドキュメント」として継続的に管理する必要があります。
モデルの更新もあれば、コードベースの変化もある。
すると、半年前は正確だった文脈が、今は古くなっていることもあるのです。
「Claudeが劣化した」と感じる現象の多くは、こうした問題かもしれません。
つまり、共有コンテキストが古くなったのに、誰も気づいていないだけ。
そういうケースです。
個人のワークフロー規律は、最低限の必須条件にすぎない。
チームでの共有コンテキストの統治こそが、本当の分かれ目になる。
組織として複利的に成長するか、徐々に衰退するか。
それを決める要因だ、という指摘でした。
まとめ
Redditの議論を通して見えてきたのは、ひとつの共通認識でした。
Claudeへの不満の多くが、AIモデルそのものではなく、使う側のワークフローに起因している、という見解です。
もちろん、正当な不満も存在します。
トークン消費の増加や、研究用途での相性などの声です。
これらは無視すべきではありません。
しかし、「期待通りに動かない」という不満の大部分は、姿勢を変えることで解消できる可能性があります。
具体的には、以下のような実践です。
- タスクを小さく分解する
- プロンプトに使う言葉の精度を上げる
- 生成されたコードに自分が責任を持つ意識を保つ
- プランモードや別ブランチでの隔離など、適切なガードレールを設ける
特に印象に残ったのは、ある一行のコメントでした。
不満を訴えるスレッドの多くは、結局のところ書き手のやり方を物語っている、という指摘です。
辛辣ではあります。
それでも、自分のAI活用法を見つめ直すきっかけになる言葉と言えるのではないでしょうか。
AIがどれだけ使いこなせるかは、結局のところ使い手次第。
不満を述べる前に、自分のワークフローを点検してみる。
これが、生産性向上へのいちばんの近道になるのかもしれません。
