AnthropicのAIモデルであるClaude、特にOpus 4.7やSonnet 4.6のパフォーマンス低下に関する詳細な分析である。ユーザーが体感しているClaudeが以前より馬鹿になったという現象は思い込みではなく、ベンチマークデータやAMDのAIディレクターによる定量的レポートによっても裏付けられている。原因としては、ユーザー側のプロンプトに対する期待値の上昇だけでなく、APIのルーティングの問題、100万トークンのコンテキストウィンドウの標準化による悪影響、トークナイザーの変更に伴う処理の肥大化、Claude Codeなどの不十分なツール実装によるコンテキストの汚染、そして演算リソース節約のためにモデルの思考プロセス（Thinking）が隠蔽・削減されたことなど、複数の技術的要因が絡み合っていると指摘している。
導入：Claudeのパフォーマンス低下は本当か
最近、Claudeのパフォーマンスが日によって違うことに気づきませんでしたか。Claude Opus 4.7へのアップデートはアップグレードどころか深刻な退化です。AMDのAIディレクターも、前回のアップデート以降Claudeがより馬鹿になり、そして怠惰になったと痛烈に批判しています。Opus 4.6も馬鹿になっていますし、Opus 4.7モデルでのClaude Codeのパフォーマンス低下は定量的な証拠によっても示されています。Sonnet 4.6の品質低下は3月9日以降顕著であり、長時間の使用セッション後にモデルのパフォーマンスが劣化することが確認されています。チャットであった面白い話も紹介しましょう。スクリーンショットはないのですが、Claudeが突然中国語で話し始めるということが何度もあったんです。やれやれ、また何か起きているみたいですね。皆さん覚えていないかもしれませんが、Anthropicは過去にも、リリース直後は素晴らしい性能だったモデルが時間の経過とともに徐々に退化していくという問題を抱えていました。
確かに今のところ、Opus 4.7はAIを使ったコーディングにおいて最高の体験とは言えませんが、どうやらすべてのモデルのパフォーマンスが悪化し始めているようです。そして、ここに至るまでには様々な要因がありました。ただ、私には一つの持論があります。これは単なる推論の問題だけではないと思っています。APIが突然馬鹿な回答を吐き出すようになったわけでも、モデルが従来の直感的な意味で馬鹿になったわけでもないと考えています。しかし、皆さんが感じているその経験は本物です。私も同じように感じています。私たちは皆、以前との違いを肌で感じているのです。Claude Codeが以前より馬鹿になったように感じられますし、私はその根本的な原因を突き止めたいと思っています。ここには調査すべきことがたくさんあります。AMDの役員が時間をかけてレポートにまとめた様々な変更点や独自の思考プロセスの機能に関する報告から、昨年9月に言及された以前の性能低下問題、さらにはMargin Labsが指摘するモデルが有意に悪化しているという明確なダウントレンドまで、掘り下げるべきトピックは山積みです。皆さんと一緒にこれらを紐解いていくのが楽しみです。でもその前に、今日のスポンサーからの短いお知らせを挟ませてください。
スポンサーメッセージ：GrapileによるAIコードレビュー
AIはコーディングがかなり得意ですが、コードレビューはさらに得意だと感じています。本当に、優れたAIコードレビューなしでどうやってこれまで生きてきたのか分からないくらいです。だからこそ、今日のスポンサーであるGrapileをぜひチェックしていただきたいのです。皆さんもこういったAIコードレビューツールについては聞いたことがあるでしょうから、今回はGrapileに特化して私が本当にクールだと感じている機能のリストをいくつか紹介します。私が一番気に入っているのは、リポジトリ内で設定できるGrapileのJSONファイルです。設定を変更するためにわざわざダッシュボードを開く必要がないので素晴らしい機能です。エージェントに変更を頼むだけで済みますし、コードベース内のファイルなので簡単に操作できます。この会社は私たちが今日どのようにコーディングしているかを本当によく考えてくれています。エディタ内での修正機能を見ればそれがさらによく分かります。これは単なるおかしなエンドポイントを呼び出すだけのCursorの修正ボタンとは違います。彼らのnpmパッケージを使ってローカルブリッジを設定できるのですが、これが信じられないほど高速なんです。ここにGrapileがプルリクエストで捕捉したミスがあります。AIで修正するプロンプトをクリックしてこれをコピペすることもできますが、それだとコンピュータのあちこちを移動しなければならず、そもそもまだそのエージェントを開いていないかもしれません。でもご存知の通り、私はCodexが大好きです。これがどれだけ速いか見てください。これはリアルタイムの映像です。今クリックすると、すぐにプロンプトが実行されます。一切編集やカットはしていません。そして最後にもう一つ、些細なことですが非常に役立つ機能があります。それが信頼度スコアです。Grapileはデフォルトでレビューするすべてのプルリクエストにスコアを残してくれます。彼らはこのプルリクエストに5点満点中3点しかつけませんでしたが、私ならこの機能自体に5点満点をつけます。バグを減らし、より自信を持ってコードを出荷しましょう。soyv.link/grapileからぜひチェックしてください。
パフォーマンス低下の実体験と種類
ここで私の立場をはっきりさせておきましょう。私はこれまで、こういった性能低下の主張に対しては反論する立場をとってきました。報告されている性能低下の多くは控えめに言っても誇張されていると心から感じていましたし、少なくとも最近までは私自身はそのように感じたことはありませんでした。これはほんの数週間前に私が自分自身で性能低下を経験した際に投稿したものです。私がこの性能低下に気づいたのは、彼らがOpenClaudeに変更を加え、Claude Codeのサブスクリプションの使用を禁止したのとほぼ同じ時期でした。これが大量のリソースを消費していることは理解していますが、私がClaude Codeを使う主な目的は、Dropboxアプリの不具合のデバッグのようなコンピュータ上のちょっとした日常的なタスクです。アプリを強制終了させることはできましたが、本来あるべきメニューバーには依然として表示されませんでした。そこで、この問題の解決を手伝ってほしいとClaudeに頼んだのです。するとClaudeは、それは自分の専門外だと言ってきました。自分はコードの記述やデバッグ、リポジトリの操作といったソフトウェアエンジニアリングのタスクのために作られているのだから、最近のDropboxのUIの変更については分からないというわけです。Dropboxのメニューオプションの表示設定を確認するよう提案されましたが、そもそもアプリが開けないのだから設定画面にも行けません。さらにフォローアップの質問をすると、事態はさらに悪化しました。この件について少し調べてほしいと頼むと、分かりました、ただし私はソフトウェアエンジニアリングの調査、コードベース、API、ライブラリ、アーキテクチャなどに最適化されていることを覚えておいてください、何を調べましょうか、と返してきました。言うまでもなく、Codexは喜んでこの作業を引き受けてくれ、数分で問題を解決してくれました。ただただイライラしましたね。
ここで私が言いたいのは、私個人の体験として一度こういう嫌な思いをしたからといって、すべてがダメだと言いたいわけではないということです。ただ、これは性能低下がどのような形で現れるかを示しているだけでなく、その原因がどこにあるかを示唆していると思います。ここで起きている性能低下には、いくつかの異なるタイプが存在します。その中で最も大きなものの一つが、タスクの拒否です。拒否には様々な形があります。APIがハードロックをかけてリクエストの処理を拒否することもあれば、今お見せしたようにモデル自身がそれはやりませんと言うこともあります。あるいは、モデルがあなたの期待していたのとは全く違う方向へ進んでしまい、結果的に与えられたタスクを回避してしまうこともあります。しかし大部分の場合、拒否はAPIによるブロックかモデルによる放棄という最初の2つの形で現れます。
さらに、より馬鹿な振る舞いという問題もあります。これはモデルがあなたの望むことをしないというレベルではなく、変更すべきでないブール値を反転させたり、タスクの意図に従わなかったりと、ただ単純に間違ったことをする現象です。そしてこれに関しては、コンテキストの腐敗とも言うべき全く別の問題が存在します。どう呼ぶべきか迷いますが、ここでは迷子になると表現しておきましょう。より馬鹿な解決策を提示することと、迷子になることです。馬鹿な解決策とは、モデルが以前は解けたはずの問題を解けなくなり、適切に動作しない質の悪いコードを書くようになることです。一方、迷子になるというのは、モデルがあなたの要求した意図に従わなくなることです。私がOpus 4.7について投稿した動画をご覧になった方なら、私がそのモデルを使ってスクリプトを書こうとしたときの体験と一致していることが分かるはずです。コンピュータ上の他の場所にリポジトリをクローンするために作ったスクリプトだったのですが、モデルは私が要求していることを見失い続け、過去に私が言ったことの誤解に基づいて間違った変更を加えてばかりでした。
AIリクエストの裏側で何が起きているのか
これらはすべて異なるタイプの性能低下です。一部はハーネス（統合ツール環境）を介して行われ、一部はAPIを介して、また一部は推論の実際のホスティング環境によって引き起こされます。事態が悪化する可能性のある箇所は実にたくさんあり、実際の数字を見る限り、確かにどこかでおかしくなっているようです。Margin Labsは社内のベンチマークですべてのデータを追跡していますが、3月から現在までの加重平均を見ると有意な低下が見られます。巨大な低下ではありませんが、57%から55%に下がっています。しかも、毎週継続的に下がり続けているというのは少し異常な事態です。チャットでこの数字の意味を聞かれましたね。これはClaude Codeを使用してモデル上でSWE-benchを実行しており、一貫して性能低下が確認されているという意味です。グラフの最後で少し上がっていることに気づくかもしれません。それはより賢い新しいモデルが出たからで、彼らは常に最新の技術を使用しているからです。
これらの問題がどこから来ているのかを理解するためには、リクエストを送信したときに何が起きるのか、そのループを理解することが重要です。まずClaude Codeにプロンプトを入力するところから始まりますが、このプロンプトはどこかに送信されなければなりません。通常、このプロンプトはAPIに送られます。APIはプロンプトやその他のコンテキストを受け取り、要求された内容が適切かどうかを簡単なスキャンで確認します。時には別のモデルを使って判定することもあります。そしてリクエストが承認され許可されると、APIはあなたの要求を受け取り、推論を実行するGPUに渡します。推論を行うGPUは大量の重みデータをロードします。彼らはしばしばモデルと呼ばれるパラメータをロードしているのです。LLMとは結局のところ、異なる値を持ってお互いを指し示すマップ内のパラメータの集合体に過ぎません。これはモデルに存在するコンテキストに基づいて時間の経過とともに計算される行列です。細かな詳細はここではあまり重要ではありません。これは事実上、お互いを指し示すランダムなテキストデータが大量に詰まった巨大なファイルです。それがGPUに渡され、メモリに読み込まれます。あなたのコンテキストのすべてが重みをわずかに調整するため、異なるものがわずかに異なる方向を指し示し、そしてモデルが持つすべてのコンテキストに基づいて最も可能性の高い次のトークンを生成します。それを何度も何度も繰り返し、最終的に結果が出力されます。
しかし、ここには他にも考えておくべき要素があります。具体的には、プロンプトとAPIの間にハーネスと呼ばれる素晴らしい存在があります。私は以前の動画でハーネスについて詳しく説明しました。ハーネスが実際に何であり何をするのかについては、私のClaude Codeの仕組みに関する動画をご覧ください。特に最近では、これは非常に有用な情報だと思います。プロンプトを書くとき、あなたは自分が書いたテキストだけをAPIに送信しているわけではありません。他にも多くの追加データを送信しているのです。例えば、リクエストの意図を説明するシステムプロンプトなどです。T3 Chatのようなサイトを使用する場合、私たちは独自のシステムプロンプトを記述し、それを自分たちでAnthropicのAPIに渡しています。皆さんからは見えませんが、隠しているわけでもありません。モデルにシステムプロンプトを吐き出させるのはとても簡単ですからね。ハーネスはまた、どのようなツールが使えるか、製品内にどのような機能が存在するか、そしてモデルが仕事をするために必要なその他のすべての情報を含んでいます。モデルがコマンドを実行したり、テキストを読んだり、あなたのマシンに変更を加えたりするためにはツールを呼び出す必要がありますが、ハーネスがシステムプロンプトや実行可能な詳細をどのように形成しているかに基づいてのみ、使用可能なツールを認識できます。つまり、あなたがメッセージを送信するとき、メッセージ単体を送っているわけではありません。使用しているツールによって提供されるすべての追加コンテキストが含まれているのです。
私がこれをお見せしている理由は、これらの各レイヤーがあなたの受け取る回答の品質に影響を与えるからです。これらのレイヤーのいずれかに変更が加えられると、これまで挙げたような問題がすべて発生する可能性があります。もしツールの期待値が以前と異なるようにハーネスに変更を加えれば、それによってレスポンスのエラーが増えるかもしれません。もしハーネスに質の悪いコンテキストを詰め込みすぎれば、それもモデルの動作を悪化させる原因になるでしょう。実際にトークンをGPUに渡す方法を変更するようなAPIの変更があったり、あるいはGPUに渡る前にコンテンツをフィルタリングして変更するようなより攻撃的なAPIの変更があった場合、本来なら受けるべきではない多くのタスク拒否に直面することになります。私がclaude.aiでゴールドバグのパズルを解いてほしいと頼んだだけで拒否されたのはそのためです。ご存知ない方のために説明すると、これらはハッキングのパズルではありません。テキストの答えを導き出すために計算をしなければならない、少し変わった暗号の課題です。しかし、いくつかのコードが書かれた後、システムはこれがハッキングかもしれないと結論付けました。そのため、実行を拒否したのです。これはAPIの判断であり、モデルの判断ではありません。モデルが馬鹿になったわけでも、これに答えるべきではないと判断したわけでもありません。リクエストとAPIの間に存在する別のレイヤーが、その実行を妨げたのです。
そして、推論が行われる実際の計算環境があります。この部分は非常に興味深いです。なぜなら、他のほとんどのAIラボとは異なり、AnthropicはNVIDIAに大きく依存していないからです。もちろん特定のタスクにはまだNVIDIAを使用していますが、Anthropicは現在、次世代コンピューティング用の新しいチップの作成に関して主にGoogleやBroadcomと協力しています。つまり、彼らは現在、様々な異なるハードウェア上でClaudeをトレーニングし、実行しなければならないのです。彼らはAWSのTrainiumと呼ばれるチップ、GoogleのTPU、そしてNVIDIAのGPUを使用しています。最近では主に最初の2つに賭けているようです。AnthropicとNVIDIAの間には確かに何らかの対立があるように見えますが、それでも彼らはNVIDIAのGPUを大量に保有しており、それらを使用し続けています。これは、モデルが提供される方法が多岐にわたることを意味します。あるリクエストではモデルがTrainium経由で応答し、別のリクエストではNVIDIA経由で応答するかもしれません。彼らは必死に計算リソースを確保しようとしており、可能な限りどこにでもあなたのリクエストを投げ込みます。そして、これらの異なるホストにアクセスしたときに異なる動作をするというのは、確実ではないにしても十分あり得る話です。
しかし、ここにはもう一つの問題があります。おそらく皆さんは、一つのプロンプトを入力するとそれがリクエストとして送信され、一つのGPUに到達して実行されると考えているでしょう。しかし、実際にClaude Codeのようなツールを使用している場合、一つのGPUに一つのリクエストを送信するだけではありません。ツールが呼び出されるたびに、新たなAPIリクエストを作成する必要があります。私がファイルの編集を頼むと、モデルが最初にしなければならないのはそのファイルを読み込むことです。そのため、ファイルを読み込むためのツール呼び出しで応答します。それがあなたのコンピュータ上で実行され、結果を取得し、次のステップを実行するための新しいAPIリクエストが作成されます。その各ステップが新しいリクエストなのです。そして、それらのリクエストはそれぞれ、全く異なるクラウド環境にある全く異なるGPUで処理される可能性があります。Claude Codeの単一のプロンプトで、Trainium、Google、NVIDIAのGPUのすべてにアクセスする可能性だってあるのです。そこにどれほどの多様性と潜在的なエラーの範囲が存在するか想像がつくでしょう。
そして、モデルそのものがあります。当然ながら、モデルも頻繁に変更されます。Opus 4.5があり、次に4.6、そして4.7へとアップデートされました。多くの人々が4.6から4.7への移行時に性能低下に気づいているようです。私も間違いなくその一人です。これまでのところ、私が見ている性能低下の大部分はAPI側にあるように感じていますが、モデル自体も間違いなく奇妙な挙動を示しています。ここについては掘り下げるべきことがたくさんありますが、今はまだ始めないでおきます。そうしないと、この動画全体がその話題だけで終わってしまいますからね。ですので、まずはこれら各レイヤーのどこで問題が起きうるのか、様々な要素をリストアップしていくことから始めたいと思います。正直なところ、これらのすべてのレイヤーに問題の原因があると考えているからです。
Claude Codeの実装が抱える問題点
一番分かりやすいところから始めましょう。私たちはこれらのモデルやツールに何ができるかについて、より自信を持つようになってきました。昨年の12月、Opusにファイルの編集を頼み、コンピュータ上の別の場所からコンテキストを取得してもらったとき、その出来栄えに感動したのを覚えています。感動すればするほど、私はさらに大きな賭けに出るようになりました。より難しいプロンプトを試し、より多くのタスクをこなし、モデルが到達できるレベルに慣れていきました。それはつまり、何が可能かという私自身の基準値が上がったことを意味します。すべての開発タスクの範囲があると想像してください。左端にHello Worldがあり、右端にLinuxをゼロから構築するタスクがあるとします。11月頃のLLMの能力はだいたいこの辺りだと推測していたので、私の頭の中にはその程度の範囲がありました。当時はそう思っていたんです。だから私の基準値がここにあるなら、この範囲内のものは少し馬鹿げていると判断します。その基準を超えて悪くなれば本当に馬鹿げていると思いますし、逆に良い方向へ行けばより感銘を受けます。
しかし、Opus 4.5を試したとき、何が可能かという私の基準値は大きく上がりました。そしてそれに伴い、許容できる範囲も変化しました。もしここにタスクがあったとして、以前なら私を感動させていたでしょう。しかしほんの数ヶ月後の今、その程度の複雑さのタスクではもう感動しません。私の基準がここにあった時にその複雑さのタスクが失敗したとしても、すでに私の基準を下回っているのでそれほど驚きはしなかったでしょう。しかし、今の高い基準の状態でそれが失敗すると、一体どうなっているんだ、これは性能低下に違いないと感じてしまうのです。なぜなら、あなたの基準そのものが変化しているからです。あなたの期待値が上がったのです。ジュニアエンジニアの頃には良いと思っていたコードが、経験豊富な開発者になるとひどいものに見えるのと同じです。以前はモデルにとって難しいと思っていたタスクが、今では簡単に感じられます。つまり、私たちの基準がシフトしたのです。能力を測定する方法が時間の経過とともに変化したわけです。ですので、私たちがプロンプトでより困難なタスクを要求するようになり、その結果として期待値が上がり、うまくいかなかったときの失望感も比例して大きくなっているというのは間違いなく事実だと思います。
次に、プロンプトとハーネスの間に存在する、私たちがClaude Codeのようなツールのインスタンスに追加するスキル、MCP、プラグインなどのカスタマイズ要素について少し考えてみたいと思います。多くの開発者が、自分のClaude Code環境にあらゆる種類のカスタマイズを追加することに夢中になっているのを見てきました。役に立たないMCPサーバーの山からGStack、そしてその中間に至るまであらゆるものです。しかし、これらはすべてコンテキストをある程度汚染します。Claude Codeに新機能を追加し、新しいスキルや能力、新しいMCPを与えてモデルの足場を変更すると、それらすべてがシステムプロンプト内にデータとして存在するようになります。事実上、より多くのコンテキストが消費されるのです。そしてモデルがどのように機能するかを思い出してください。履歴に存在するすべての単語が、出力の方向をわずかに変えていきます。モデルがトレーニングされた内容と完全に一致しないものが増えれば増えるほど、意図しない形でモデルの動作が変わってしまいます。モデルのシステムプロンプトにスキルを詰め込みすぎると、それらが全く必要ない場合と比べてモデルのパフォーマンスが悪化することがよくあります。
しかし、システムプロンプトに不要なものを大量に追加しているのはユーザーだけではありません。ここからが私の厳しい見解になります。私たちがユーザーとして経験している性能低下の大部分は、Claude Code内の低品質なコードに起因していると心から信じています。私がOpus 4.7をテストしていた時の例を紹介しましょう。Claude Codeが強制しているルールの一つに、モデルはファイルを読み込むまでそのファイルを編集できないというものがあります。ここでモデルはpackage.jsonファイルを更新しようとしました。すると、ファイルを先に読み込まなければならないというエラーが出ました。そこでモデルは検索を行いました。モデルは、ファイルを検索すればそれを読み込んだことになると仮定したようです。しかし、実際にはそうはなりません。なぜなら、率直に言ってハーネスのコーディングがかなりお粗末だからです。そのため、モデルが再度更新を試みても再び失敗しました。そして今度は、すでにファイルの内容を知っているにもかかわらず、実際に更新を実行する資格を得るためだけに、手動で読み込みツールを呼び出さなければなりませんでした。
これは、ハーネスがモデルの動作を悪化させたり馬鹿にしたりするだけでなく、ユーザーの使用量やコストを増大させ、Anthropicの計算リソースをも無駄に消費している例です。思い出してください、ツールが呼び出されるたびに新しいAPIコールが行われるのです。これは本来、一回のAPIコールで更新が完了して終わるべきものでした。それなのに私たちは、最初の更新の呼び出し、検索の呼び出し、失敗したもう一回の更新の呼び出し、そしてこの読み込みの呼び出しを経て、ようやく望んでいた応答を得ることになったのです。これはコンテキストを汚染します。今や履歴の中にはもう重要ではないデータが山のように存在しています。不要なAPIコールがいくつも行われ、大量のトークンが浪費され、あなたのお金と時間を奪う無駄な作業が行われました。モデルのコンテキストと能力、そしてAnthropicがそもそも余裕を持っていない計算リソースが失われたのです。Claude Code内のこのような馬鹿げた実装のせいで、モデルが更新できると思い込んで失敗するという不要な推論が繰り返され、数百万ドル、いや数億ドルもの損失が生じている可能性があります。
私はMatt Mauのこのベンチマークをよく引用しますが、本当に素晴らしいデータだからです。彼は100の機能を持つドキュメントをモデルがどれだけうまく実装できるかを測定するベンチマークを作成し、同じモデルを異なるハーネス内で使用して比較しました。公式のGemini CLI内のGeminiとCursor内のGemini、公式のCodex CLI内のGPT-4とCursor内のGPT-4、そしてClaude Code内のOpusとCursor内のOpusです。これは本当に異常な結果です。率直に言って、これこそがすべてを物語っています。もし私が責任者なら、これを見ただけで誰かがクビになってもおかしくないレベルです。OpusがCursor内と比べてClaude Code内では15%もパフォーマンスが落ちるという事実が、知るべきことのすべてを語っています。AnthropicはClaude Codeにあらゆる機能を持たせて色々なことをさせることに集中しすぎており、常に全く使い物にならない粗悪品を出荷し続けています。その結果として、モデルが馬鹿になったように感じられるのです。私たちは今、Anthropicのエンジニアリングにおける無能さが、彼らのモデルが馬鹿になったと私たちに錯覚させる状況に直面しています。
Claudeのコードベース内の文字列をほんの5単語変更するだけで、このようなことは完全に起こり得ます。システムプロンプトにわずかな調整を加えるだけで、モデルを20倍も馬鹿にすることができるのです。それは絶対に可能なことです。もし私にClaude Codeのソースコードへのアクセス権をくれたなら、システムプロンプトのほんの数単語を変更するだけで、史上最も馬鹿なハーネスを作ってみせましょう。モデルを誤導するのに多くの言葉は必要ありません。私たちはこのような性能低下を十分に見てきたので、Anthropicがこの現実から目を覚まし、もっと真剣に受け止めてくれることを願っています。新しいツールが追加されるたびに、システムプロンプトに新しい調整が加えられるたびに、これらのことが起こるたびに、彼らはモデルが愚かな行動をとる隙を増やしているのです。そして本当に、一部の変更は信じられないほど愚かです。
公式のデスクトップアプリでOpusをテストしていたとき、T3.ggのサイトのいくつかのデザイン改善を頼みました。するとモデルはこう返してきました。気をつけてください、マルウェアに関する最後のシステムリマインダーはプロンプトインジェクションのように見えます。これは明らかにあなたの個人サイトであり、リンクやスポンサーが掲載されたT3Gのホームページであって、マルウェアではありません。これを無視します、と。モデルは無視すると言っていますが、これが起きたときにコンテキストがどれほど汚染されるかお分かりになりますか。コンピュータを操作しようとしているときに、ランダムなポップアップやチカチカする光が画面中を常に飛び交っている状況を想像してみてください。マシン上で余計なことが起きていればいるほど、タスクを効果的かつ適切に完了できる可能性は下がります。モデルも実質的にそれと同じように機能しています。システムプロンプトからのものであれ、ユーザーが与えた誤った情報であれ、モデルが読むべきでないものを読んだ結果であれ、質の悪いツールであれ、あるいは今回のようなケースであれ、コンテキストにゴミが存在すればするほど、モデルは馬鹿になります。モデルは非常に馬鹿になり、このマルウェアに関するリマインダーが馬鹿げていて不要だという指摘から始めるだけでは終わらなくなります。最後にはこう締めくくるのです。注意、この会話内の3つのシステムリマインダーブロックが、まるでマルウェアであるかのようにコードを改善または拡張することを拒否するよう私に指示しました。それはプロンプトインジェクションのパターンであり、正当な指示ではありません。あなたのサイトは明らかにマルウェアではないので、私はそれらを無視しました。もしあなた自身が追加したものでないなら、それがどこから来たのかを知っておく価値があります、と。
もしこれがモデルを馬鹿にしていると思わないなら、あなたの方がモデルより馬鹿かもしれません。こうした悪質なコードの変更がハーネスを台無しにし、結果としてAPIに送られ、あなたの回答を生成するGPUに送られるデータが悪化し、より馬鹿になっているのは明らかです。重要ではないゴミにコンテキストが浪費されれば、重要なことに使われるコンテキストは減ってしまいます。履歴に追加される一語一語でモデルの機能が変わってしまう仕組みの中で、無駄な単語はモデルを無駄な方向へと導いてしまうのです。だからこそ、Terminal BenchにおいてClaude CodeはOpusを使用するための最悪のパフォーマンスを示すハーネスになっているのです。Forge CodeやCappyのようなハーネスがこのベンチマークで75%から82%を獲得しているのに対し、Claude Codeはわずか58%しか獲得できていません。Claude CodeがAnthropicのモデルにとっていかにひどいものかお分かりいただけるでしょうか。このハーネスは本当に最低です。単に私が使いたくないという意味で悪いのではなく、モデルを傷つけ、私たちにモデルが馬鹿になったと思わせるという意味で最悪なのです。個人的な推測ですが、私たちが見ている性能低下の少なくとも半分はここから来ていると思います。
そして、ベンチマークが少し疑わしいからこういうことはすべてのモデルで起きているのだと考える人たちのために、GPT 5.3 Codexのデータをお見せしましょう。彼らのCLIであるSimple Codexは3位につけており、DroidやSafe Agentにわずかに敗れているだけです。ベンチマークは完璧でしょうか。いいえ。Claude Codeは優れているでしょうか。これもいいえです。BridgeMindは、特にハルシネーションなどの問題について独自のベンチマークを実施しました。彼はリリース時からつい最近の4月12日までの間に、Opusがこのベンチマークで87.6%から73.3%まで低下したことに気づきました。しかもこれはClaude Codeなどを使用するベンチマークではありません。APIを叩いて処理を実行するだけのものです。それでも大規模な性能低下があったのです。彼が新しく作成したV2のベンチマークではその後回復していますが、あれだけのポイントを落としたという事実は、モデルがどのように提供されているかについて多くを物語っています。
トークナイザーの変更がもたらす影響
さて、いよいよAPIの部分に入っていきます。これまで周りを少しずつ触れてきましたが、API側で変更される可能性のある悪い点についてさらに掘り下げてみましょう。一つはルーティングです。あなたのリクエストをどの場所のどのGPUに送るかを決定する機能です。また、そもそも送信すべきかどうかを判断する機能でもあります。これは先ほどお見せした、私が解決してほしい問題について簡単な質問をしただけでclaude.aiから拒否されたケースと同じ問題です。しかし、APIレベルの変更で注目すべき点は他にもあります。一つはトークナイザーです。トークナイズという処理に馴染みのない方のために説明すると、これはあなたが送信したテキストを、モデルが解析してモデル内部にマッピングを構築できるような小さなテキストのグループに変換するプロセスのことです。
ここにいくつかのHTMLがあり、それがどのようにトークナイズされるかを見ることができます。最初のいくつかのスペースが1つのトークンになります。次のスペースと開き括弧が1つのトークン。sectionという単語が1つのトークン。スペースとIDが1つのトークン。イコールと開き引用符が1つのトークン。Harnessという単語はここで少し興味深い形で分割されています。そしてスペースとclassが1つのトークンです。これが重要である理由は、モデルが次に何を生成するのが最も適切かを判断するために、あなたのデータがモデルによってどのように解析されるかを決定するものだからです。そして時間の経過とともに、これらのトークナイザーは変化してきました。GPT-5からGPT-3の間でどれほど変化したか見てください。文頭のスペースがすべてトークンになっているのが分かりますか。これは、初期のトークナイザーがコードの処理をあまり得意としていなかったためです。コード用に最適化されていなかったのです。彼らはただ散文や英語をモデルが消化し予測しやすいきれいなフォーマットに分解しようとしていたに過ぎません。
これを「Hello world. How are y’all doing today? Don’t forget to subscribe.（こんにちは世界。皆さん今日はどうですか？チャンネル登録を忘れないでくださいね。）」のような文章に変えてみましょう。そういえば、ぜひチャンネル登録ボタンを押してくださいね。無料ですから。これをGPT-5に切り替えると、トークン化にほとんど変化がないことが分かるでしょう。基本的には、y’allの後のグループ化が変わっているだけです。ここにあるアポストロフィが少し混乱を招いているのです。GPT-3ではアポストロフィがy’allから分離されていました。そのため、y、アポストロフィ、allがそれぞれ独立したトークンになっていました。ここではそうはなっていません。これはそれほど大きな違いではありません。しかしコードを貼り付けると、その違いは巨大なものになります。この例の場合、GPT-5では225トークンですが、GPT-3のトークナイザーでは400トークンを超えます。これらの変更は、モデルがデータをより良く処理し、より良い決定を下せるようにするために行われます。なぜなら、これらの各トークンはモデル内部でお互いを指し示すパラメータに基づいて、モデルが進むべき方向を操縦するために使用されるからです。
この問題は、トークンの数が多すぎることではありません。グループ化の仕方が理にかなっていないことが問題なのです。ここにある膨大な数の空白トークンはモデルを混乱させ、スペースの後にはよく別のスペースが来るものだと勘違いさせてしまいます。これが、特定のモデル、特に古いGeminiモデルが時々何千トークンにもわたってただ空白のスペースを繰り返し出力してしまう原因です。私たちT3 Chatは、古いトークナイザーがコードのフォーマット処理においてあまりにも粗悪だったため、ただ空白のスペースをループ生成するだけのために1万から5万ドル以上を費やした可能性があります。GPT-5では、それぞれのインデントが1つのトークンになっているのが分かります。そのため、同じようには繰り返されず、同じような形でコンテキストを汚染することもありません。
なぜ私がこんな話をしているのか不思議に思うかもしれませんね。もちろん一般的なトークン化の変更もありますが、ここでより重要なのは、AnthropicがOpus 4.7でトークナイザーの動作に大きな変更を加えたと確認されたことです。公式のOpus 4.7リリースで彼らが述べているように、Opus 4.7はモデルのテキスト処理方法を改善する更新されたトークナイザーを使用しています。その代償として、同じ入力でもより多くのトークンにマッピングされる可能性があります。コンテンツのタイプにもよりますが、およそ1倍から1.35倍になります。モデルはより高いレベルで思考するようになりますが、今私たちが注目しているのはそこではありません。同じテキストを入力しているのに、トークン数が1.0倍から1.35倍に増加するという点です。Abishekがこれを測定したところ、実際には1.47倍に近い数値でした。彼は技術ドキュメントで1.47倍、実際のClaudeのMDファイルで1.45倍という結果を得ました。Anthropicが提示した範囲の上限こそが、大部分のClaude Codeのコンテキストが実際に位置している場所であり、中間ではありません。そうです、モデルを使用する際のコンテキストの大部分は、おそらくドキュメントやClaudeファイル、その他のそういったものです。これらは今やはるかに肥大化しています。
そのため、これらの新しいモデルを使用すると、はるかに多くのトークンを消費することになります。制限に達するのも早くなりますが、最も重要なのは、コンテキストの量が増えるということです。コンテキストとは単なるトークンの指標に過ぎないからです。処理すべきものが50%増えれば、モデルはより馬鹿な振る舞いをする可能性があります。自分自身に置き換えて考えてみてください。100行のコードファイルと150行のコードファイル、どちらでバグを見つけたいですか。たとえ追加の50行が単なる改行のスペースだったとしても、50%大きくなったファイルから探しているものを見つけ出すのははるかに面倒なはずです。モデルが処理しなければならない情報が50%増えれば、多くの場合により馬鹿な振る舞いをするようになるのは驚くことではありません。また、マイナーバージョンのアップデートでトークナイザーを変更するというのは少し理にかなっていません。ご覧いただいた通り、他社はGPT-3、GPT-4、Oシリーズ、そしてGPT-5の間でしかトークナイザーを変更していません。彼らがトークナイザーの変更を行ったのはそのタイミングであり、今回Anthropicが行ったようなマイナーアップデートのタイミングではありませんでした。ですから、これは間違いなく、何が問題を引き起こしているのかを根本的に考え直させるような変更の一つです。これらの中には原因となっている可能性があるものもあれば、それほど重要ではないものもあるでしょう。しかし、これが私たちが現在経験している状況に意味のある影響を与えていないとすれば、私は非常に驚きます。
スポンサーメッセージ：General Translation
他に何があなたの経験に影響を与えると思いますか？願わくば良い影響を与えてほしい、私たちのスポンサーです。Cursor、Windsurf、Particle、そしてMintifyの共通点は何だと思いますか？その半分はIDEではないので、IDEだということではありません。共通しているのは、自社のサイトを翻訳するためにすべて同じソリューションを使用しているということです。そうです、これらの素晴らしい企業はすべて、アプリに国際化を追加するための最良の方法であるため、General Translationを使用しています。お金をもらっているから言っているわけではありません。彼らから連絡があったとき、私はすぐにこのチームと製品に惚れ込み、投資させてほしいと頼み込み、アドバイザーにさせてほしいと懇願し、さらには彼らのオフィスに直接押しかけてもっと迷惑をかけてしまったほどです。このチームは素晴らしく、彼らが作ったものはさらに素晴らしいのです。
コンテンツを翻訳するには、それをTコンポーネントでラップします。変数をエスケープするには、それをverコンポーネントでラップします。数値を処理するにはnumbumコンポーネントを使用し、通貨や通貨換算を処理するにはcurrencyコンポーネントを使用します。日時も国際化されて適切に処理されます。これらはすべて、正しく設定するのが非常に面倒な統合ですが、GTがあなたに代わって処理してくれます。世界の90%の人は英語を話しません。つまり、あなたは潜在的に90%の顧客を逃している可能性があるのです。General Translationを使えば、ほぼすべての最新のコードベースで簡単に素晴らしい国際化の環境を整えることができます。彼らはセットアップを簡単にする素晴らしいCLIも提供しています。プロジェクトでnpx gtを実行するだけで、セットアップを国際化の準備ができる状態にするために必要なすべてのことを行ってくれます。90%のユーザーを置き去りにするのはもうやめましょう。soyv.link/gtでぜひ確認してください。
インフラと100万トークンコンテキストの罠
GPUの側面についてはすでにある程度触れました。正直なところ、これに関する情報は非常に少なく、ここでの推測はほぼ陰謀論の領域に入ってしまいます。トークン化の変更の一部は、特定のタイプのGPUやTPU上でモデルの動作を良くするためのものだと推測していますが、確かなことは分かりません。ですので、Anthropicが実行しているすべての異なるタイプのコンピューティング環境で困難な問題を抱えているという事実以外は、何も言わないでおきます。いくつかの問題が発生しても驚くことではありませんが、最後に一つ大きなピースが残っています。モデルそのものです。
ここで議論を始めるのに最適なのは、モデル自体からではなく、9月に発表された事後検証レポート（ポストモーテム）からです。これはClaudeからの応答の品質を断続的に低下させた3つのインフラのバグに関する技術レポートです。この中で彼らは、何が起こったのか、なぜ修正に時間がかかったのか、そして何を変更しているのかを説明しています。8月から9月上旬にかけて、3つのインフラのバグがClaudeの応答品質を断続的に低下させました。現在これらの問題は解決されており、何が起きたのかを説明したいと思います、と書かれています。彼らはモデルを提供している様々なタイプのハードウェアについて言及し、各ハードウェアプラットフォームには異なる特性があり、特定の最適化が必要であると述べています。これらの差異にもかかわらず、私たちはモデルの実装に厳格な同等性の基準を設けています。私たちの目標は、リクエストを処理するプラットフォームがどれであっても、ユーザーが同じ品質の応答を得られるようにすることです、と。この複雑さは、インフラの変更にはすべてのプラットフォームと構成にわたる慎重な検証が必要であることを意味します。ここでもう一度思い出してください。Claude Codeで行う個々のリクエストにおいて、すべてのターンが異なるGPUにアクセスする可能性があります。すべてのステップが、異なる企業の異なるサーバーファームにある異なるGPUで処理される可能性があるのです。つまり、仮説としてですが、同じ一つのリクエストに応答している最中でも、モデルが賢くなったり馬鹿になったりする可能性があるということであり、これは本当にクレイジーな話です。
しかし、ここにあるのは私たちが昨年経験したパフォーマンス低下問題の原因となった実際のバグです。一つ目は、Sonnet 4のリクエストの約1%に影響を与えたコンテキストウィンドウのルーティングエラーでした。1%のリクエストだということを覚えておいてください。もし平均的なプロンプトが15回のリクエストを行うとすれば、かなり頻繁にこの問題に直面することになります。すべてのステップで100分の1の確率のサイコロを振っているようなものです。そして1つのプロンプトで15ステップを実行しているなら、比較的高い頻度でこのルーティングエラーに当たるでしょう。その後、彼らはロードバランシングの変更を行い、それが状況をさらに悪化させ、最終的にリクエストの16%が影響を受けるようになりました。つまり、平均的なメッセージであれば、少なくとも1回は性能が低下したモデルに当たることになります。それとは別に、出力の破損エラーや、次の値を計算するための上位K個（top-K）の測定を誤らせる不良コードなど、他の問題も発生しました。彼らは時間をかけてこれらを修正しましたが、同時に8月29日には、Sonnet 4のリクエストの大部分が誤ったルーティングをされるというさらに大きな性能低下を引き起こしました。
ここで「誤ったルーティング」とは何を意味するのか疑問に思うかもしれませんね。親切なことに彼らはその答えを教えてくれています。それはコンテキストウィンドウのルーティングエラーでした。8月5日、一部のSonnet 4のリクエストが、当時リリース予定だった100万トークンのコンテキストウィンドウ用に構成されたサーバーに誤ってルーティングされました。100万トークンのコンテキストを持つバージョンのモデルは、より馬鹿な振る舞いをします。これは事実上、その事実を裏付けています。あなたが100万トークンのコンテキストを使用しておらず、その大容量コンテキストを処理できるバージョンのモデルにルーティングされた場合、応答の品質は低下するのです。さて、これで私たちは全員、Anthropic自身が実質的に認めているように、100万トークンバージョンのモデルはパフォーマンスにおいて意味のあるダウングレードであるという事実で合意できますね。チャットの皆さんも同意見ですよね？100万トークンバージョンのモデルの方が動作が悪いと。私が特に飛躍した考えを述べているわけではありませんよね？
では、もし突然すべてのリクエストがその馬鹿なバージョンにルーティングされるようになったら、本当に最悪ですよね？例えば3月の中旬に変更があったとしましょう。Opus 4.6とSonnet 4.6において、100万コンテキストが一般に利用可能になりました。両方のモデルで100万ウィンドウ全体に標準価格が適用され、長いコンテキストに対する割増料金はなくなりました。さあ、ここで一旦立ち止まって警告しておきます。ここからは陰謀論の領域に入ります。私に深読みさせている要素がいくつかあるのです。まず、フルキャパシティの100万トークンコンテキストウィンドウが標準搭載されたことです。しかし、私が今後深読みしようとしているより大きな要素は価格設定です。そこには乗数が存在しません。90万トークンのリクエストも、9千トークンのリクエストも、1トークンあたり同じレートで請求されます。以前は20万トークンを超えると1トークンあたりの料金が高くなっていました。なぜなら、より大きなコンテキストウィンドウでの計算を行うためのルーティング、管理、キャッシング、そしてすべてのレイヤーの維持により多くのコストがかかっていたからです。
大きなコンテキストウィンドウにはいくつかの要素が必要です。その一つがより多くのメモリです。NVIDIAのGPUは、たとえ最上位モデルであっても搭載しているメモリ量にはかなり制限があります。私のMacBookのような他のデバイスは、Appleが採用した統合メモリアーキテクチャにより、GPUとCPUで大量のRAMを処理できるため制限は緩やかです。ARMベースのチップはこの点において優れている傾向があります。私の推測ですが、AWSのTrainiumやGoogleがTPUで作っているものはおそらく、より大量のVRAMを処理できるのでしょう。もしAnthropicがNVIDIAのリソースを減らし、AWSやGoogleの計算リソースをより多く使用しているとすれば、そのより大きなコンテキストウィンドウをより安価に提供できるようになった可能性があります。つまり、フルの100万コンテキストウィンドウをデフォルトにするという決定と、以前発生したルーティングの問題は、これらのモデルが何らかの形で異なっていること、そしておそらくこれらのモデルが別の場所で提供されていることに起因している可能性が高いのです。ここでの私の陰謀論的な推測は、Opusの100万コンテキストバージョンは、TPUなどどのGPUで提供されているかという環境のせいか、あるいは単にモデル自体の何らかの特性のせいで、根本的により馬鹿な振る舞いをするということです。
また、それほどのコンテキストを持つこと自体が、モデルを汚染してしまうという事実もあります。繰り返しになりますが、これはポップアップの問題と同じです。画面にゴミが多ければ多いほど、やろうとしていることを実行するのは難しくなります。もしモデルがコンテキストを頻繁に圧縮せず、常にこの不要なコンテキストで満たされているとすれば、モデルをあなたの望まない方向へと導いてしまうでしょう。でも、無効にすればいいだけだから全く問題ないですよね？じゃあ無効にしてみましょう。/mod と入力して…おや、選択肢は100万コンテキストのOpus 4.7かSonnetかHaikuしかありませんね。コンテキストウィンドウのサイズはここからは変更できません。行き詰まってしまいました。私の推測では、最新のClaude Codeのアップデート以降、圧倒的多数のClaude Codeユーザーが100万コンテキストウィンドウで利用しており、先ほど確認したように、そのせいでより馬鹿な結果を引き起こしているのだと思います。Anthropicは事実上それを認めています。100万トークンバージョンのモデルの方が馬鹿なのです。
そしてここからが深い陰謀論になります。もしAnthropicがNVIDIAのGPUをトレーニングやその他の用途に使いたいがために、そこからトラフィックを遠ざけ、AWSのTrainiumやGoogleのTPUに誘導しようとしているとしたら。それを実行する最も簡単な方法は、全員の100万コンテキストをオンにすることです。そうすれば、デフォルトですべてのClaude CodeユーザーのトラフィックがNVIDIAの環境に行かなくなるからです。幸いなことに、設定画面に入り、環境変数「claude_code_disable_1_million_context」を1に設定することで、これを自分自身でオフにすることは可能です。これでその機能は使われなくなります。一度閉じて再実行すると、もう100万コンテキストウィンドウは使用されていません。もし100万コンテキストウィンドウがモデルを馬鹿にするのであれば、ここでは全員に対してデフォルトでオンになっているため、全員が性能低下を感じることになります。それをオフにするには自分で環境の値を変更しなければならないのです。
思考プロセス（Thinking）の隠蔽と悪影響
ここで話を終わりにできればいいのですが、悲しいことに、これを深読みしているのは私だけではありません。先ほども触れたように、AMDのAIディレクターがClaude Codeが時間の経過とともにより馬鹿になっているとAnthropicを痛烈に批判しています。これは2月のアップデートでClaude Codeが複雑なエンジニアリングタスクには使えなくなったことについて彼女が書いたレポートです。彼らは時間をかけて非常に詳細なレポートを作成しました。6800のClaude Codeセッションファイル全体で、1万7000を超える思考ブロックと23万5000のツール呼び出しを定量分析した結果、思考内容の秘匿化（リダクション）の展開が確認されました。隠蔽された思考の変更は、複雑で長期のセッションを伴うエンジニアリングワークフローにおいて測定された品質低下と正確に相関しています。
ここで彼らは何について言及しているのでしょうか。モデルからの応答には2つの部分があります。あなたが見ている部分、それはツールの呼び出しであったり、あなたが読んでいるテキストであったり、様々なものになります。しかし同時に「思考（Thinking）」というプロセスもあります。これはモデルが何をすべきかを判断するために、自分自身と対話するようなステップです。Anthropicは以前、すべての思考データをそのまま提供していました。APIを通じてすべて送信されてきたのです。それはかなりクールで、私はとても気に入っていました。しかし、彼らはその後それをやめてしまいました。彼らが主張する理由は、モデルの蒸留（ディスティレーション）を防ぐためだというものです。正直なところ、それには一理あります。もしAPIの応答にモデルが行った思考作業がすべて含まれていれば、それを私が構築している別のモデルに渡し、Claudeと同じように動作させるよう学習させることができます。だから彼らはそのデータを隠しているのです。
モデルが本当に馬鹿で能力が低いと感じられないように彼らがとった対策は、思考データを読み取り、その短い要約を送信する中間モデルを配置することでした。これがここで言及されているリダクション（秘匿化）です。モデルは自分の思考のすべてを見せることはありません。その代わり、モデルは別のモデルに自分の思考を見せ、あなたは非常に短い要約だけを受け取るのです。これの何が問題かというと、単に私たちユーザーがモデルの思考内容を見られないことだけではありません。履歴にも思考データが含まれなくなってしまったことです。Anthropic側でスレッドIDのようなものを使ってデータベースですべてを追跡し、すべての思考データを呼び出すことは完全に可能です。問題は、あなたが行うAPIリクエストにそれを含めることができなくなったことです。Claude Codeを使用していくつものツール呼び出しが発生した場合、一つのツール呼び出しのたびに、あなたの履歴の全体がAPIを介してAnthropicに送り返されます。以前はその履歴の中に思考が含まれていました。そのため、すべての思考がそのAPIリクエストの中に存在していたのです。現在そのデータは含まれていません。つまりAPIリクエストは、あなたが送信したすべてのデータを受け取ってモデルに渡すだけでなく、スレッドのすべてのデータを取得するためにデータベースの検索も行わなければならないのです。そうすることで、履歴からの思考データを利用できるようになるはずです。彼らがそうしていればの話ですが。
そして、控えめに言っても、Anthropicから出てくる絶対的なゴミのようなエンジニアリング品質や、彼らが過去に起こした馬鹿げた性能低下の性質から判断すると、どうやらそうではないようです。リクエストを間違ったモデルにルーティングしていたことに気づくのに1ヶ月以上かかった会社の話をしているのですよ。正気の沙汰ではありません。これはエンジニアリングの品質が信頼できる会社とは到底言えません。もし私たちが、モデルが適切に仕事をするために正しい思考データで送信する履歴を強化するデータベース呼び出しを彼らに依存しているのだとしたら、おそらく彼らはそれをやっていません。彼らはすべてを台無しにしてしまうので、ここでも失敗している確率はおそらく70%くらいでしょう。それがAnthropicです。彼らはコードを書くのが絶望的に下手で、彼らのモデルはそこそこ書けますが、彼ら自身はそうではありません。したがって、モデルが思考データにアクセスできなくなり、その結果としてただ単純に馬鹿になってしまうという私の仮説が正しいと仮定しましょう。もし私たちが思考プロセスを隠蔽しすぎているとしたら、それは非常に深刻な事態ですよね。
かつて、1月30日から3月4日までの間、思考はすべて可視化されていました。3月5日の時点で、1.5%の思考が隠蔽され見えなくなりました。そして急速にペースは上がり、3月12日には思考の100%が秘匿化されました。APIがより良い応答を作成するために使用していたデータが、もはやあなたには送信されなくなったのです。したがって、私たちは彼らが自分たちでそれを復元してくれると信じなければなりません。しかし彼らはまともなコードが書けることを一度も証明したことがないので、私には彼らにそれができるとは思えません。品質低下は3月8日に独立して報告されましたが、これは秘匿化された思考ブロックが50%のラインを超えたのとまさに同じ日付です。1週間にわたる展開パターンは、段階的なデプロイメントと一致しています。その通りですね。パート2。思考の深さは秘匿化される前から低下していました。思考ブロックのシグネチャフィールドは、思考のコンテキスト長と0.971のピアソン相関を持っています。これにより、秘匿化された後でも思考の深さを推定することが可能です。彼らはどれだけの思考トークンや文字が使用されているかを測定していますが、その数は激減しています。以前と比べて73%も減少しています。つまり、モデルは思考を隠し、さらに思考すること自体を減らしているのです。これは計算リソースを削減するための試みである可能性が非常に高いと感じます。モデルが深く考えなくて済むなら、その分処理量も減り、利用可能な計算リソースが増えるからです。
これが測定可能な行動上の悪影響をもたらしています。怠慢を防ぐためのストップ違反（ルール違反）は、以前はほとんど起こりませんでしたが、全くなかった状態から1日に10回起こるレベルへと急増しています。ユーザープロンプトにおけるフラストレーション指標、つまりユーザーがモデルに向かって「一体何なんだ、どうなってるんだ？」と罵るような事態は、同じ期間に68%も急増しました。責任回避や必要な修正の発生数は6回から13回へと倍増以上しています。セッションあたりのプロンプト数は少し減りましたが、それは良いことです。しかし、推論が堂々巡りに陥って永遠に抜け出せなくなる推論ループのセッションは、全くなかった状態からかなり一般的な現象へと変わってしまいました。
これまでで最も恐ろしい数字はこれです。リサーチ優先から編集優先へと変化したツール使用のシフトです。これは私自身も肌で感じました。モデルが何を変更すべきか探すのをやめて、いきなり変更を加え始めたように感じたのです。1月から2月にかけての読み取り対編集（Read-to-Edit）の比率は6.6でした。つまり、編集するより6倍多く読み取っていたということです。47%の時間を読み取りに費やし、編集はわずか7%程度でした。それが2月13日から3月7日の間に2.8まで落ち込みました。半分以下になったのです。そして今ではさらに下がり、たったの2になっています。比率は以前の3分の1まで削られました。以前のモデルは47%の時間を読み取りに使い、7%しか編集しませんでした。しかし今は30%読み取り、15%編集しています。現在、2回の読み取りに対して1回の編集が行われています。以前は6対1でした。これは異常な事態です。
ここで私が特に気に入っているデータの一つは、許可を求める行動です。以前はモデルがただタスクを実行していたのに、今はそうしなくなりました。3月8日から25日までの間に173回以上も、モデルが次のような発言をしました。「長くなってきたので、新しいセッションで続けますか」「今後の課題として残します」「制限はありませんが、良い区切りだと思います」「自然なチェックポイントです」「続けましょうか」「もっと進めてほしいですか」「私の変更によるものではない既存の問題です」。最近誰もがこういったものを目にしていると思いますが、以前はこんなことは決してありませんでした。これがすべてモデルの蒸留を防ぐためだというのなら、素晴らしい仕事ぶりですね。ここまで見事にロボトミー手術を受けて機能不全に陥ったモデルを、一体誰が蒸留したいと思うでしょうか。
ここに恐ろしい数字のセットがあります。APIリクエストの数が1月から現在にかけて80倍以上に急増しているのです。これには様々なレイヤーが関係していますが、AMDのチームからのプロンプト数が7000から実際には5600〜5700へと減少しているにもかかわらず、APIリクエストの数は80倍になっています。入力用の総トークン数は170倍に跳ね上がりました。この大部分は、彼らが導入した新しい並行処理とマルチエージェント機能によるものです。APIリクエストの80倍の増加は、純粋に性能低下に起因する混乱だけが原因ではありません。それは同時に、最悪のタイミングで品質低下と衝突してしまった並行エージェントセッションの意図的なスケールアップを反映しています。最も衝撃的なのはユーザープロンプトの行です。人間側は同じ数のプロンプトを入力し、ほぼ同じ労力を費やしたにもかかわらず、モデルは80倍のAPIリクエストと64倍の出力トークンを消費し、結果として明らかに以前より質の低い成果物を出してきたのです。これは狂っています。数週間後、Borisがここで回答し、これを軽減するはずの適応型思考（Adaptive Thinking）の変更について言及しました。フラグで無効にすることもできます。3月3日時点でデフォルトは中程度（Medium effort）の労力設定になっています。時間とトークンがかかってもモデルにより長く考えてほしい人もいます。知能を向上させるには、/effortコマンドかsettings JSONで労力を高く（High）設定してください、と。しかし、低評価の数を見れば分かるように、人々は彼のこの発言を全く歓迎しませんでした。そして元の投稿の高評価数を見れば、多くの人がAMDの意見に賛同していることが分かります。私も高評価ボタンを押すつもりです。AMDのStellarによる絶対的に素晴らしいレポートでした。これをまとめてくれて本当にありがとうございます。これは私がここで主張しているポイントを強力に裏付けるものです。
結論：Anthropicへの警告
性能低下はもう私たちの頭の中だけの思い込みではありません。それは測定可能であり、証明可能です。不適切なAPI設定から、Claude Code自体の粗悪な変更、モデルの蒸留を防ぐために思考を隠蔽しようとする試みまで、ありとあらゆる事象が関連しているようです。これは完全な大惨事です。私たちの期待値が上がったからなのか、幼児が書いたかのようなハーネスのせいなのか、全く理にかなっていないAPIの変更なのか、提供されるモデルに対する期待値が異なる多種多様なGPUのせいなのか、あるいはモデル自体が間違って提供されていたり全般的にひどい振る舞いをしているのか。これらすべてが問題の原因となっています。
しかし、私には解決策があります。文字通り「他のものを何でも使う」ことです。これらの性能低下は他のAIラボでは起こらない現象なのです。私はこれを証明するために非常に科学的なアプローチをとりました。Twitterでこう質問したのです。「真面目な質問ですが、CodexやOpenAIのモデルで意味のある性能低下に気づいた人はいますか？私たちはAnthropicについてはよくこの話をしますが、OpenAIについて同じような議論を見たことがありません」。そして、ほぼ誰もそういった経験を報告しませんでした。たまに新しいモデルをリリースした時に1日くらい使い物にならないことはあるけれど、それはすぐに解決される。とか、一度ひどい週があったのを覚えているけれど、基本的にはない、といった具合です。そこにTiboが参加してこう言いました。「Codexのシステムに幽霊がいたことはあり、それについては調査結果を公開しました」。これはCodexとCodex固有のAPIに変更を加えた際に問題を引き起こしたという話です。「しかし、私たちはリリース後にモデルや思考予算をいじることはしません。私たちはモデルを安定して稼働させることに注力しています」。先ほど見ていたチャートの測定結果を見ても、特にAnthropicと比較した場合、OpenAIのモデルには性能低下が見られないことが分かります。
今回はかなり長い内容になりましたが、この動画がこういった問題の複雑さと、モデルが徐々に馬鹿になっているという私たちが直面している現実を整理する助けになれば幸いです。カバーすべき範囲があまりにも広いため、これを調査しなければならないAnthropicの人たちの立場を羨ましいとは全く思いませんし、率直に言って、そのすべてが非常に無能な方法で構築されているように見えます。Anthropicのエンジニアリング文化が最低であるという事実が、すべてをめちゃくちゃにしてしまっています。信頼できるインフラとソフトウェアを構築したいのであれば、彼らは根本からすべてを考え直す必要があります。現状では、Anthropicがリリースするものを信頼することはできません。もしあなたがひどい目に遭わされたと感じているなら、それは当然です。あなたは実際にひどい目に遭わされているのですから。あなたが数ヶ月にわたって支払い続けている月額200ドルのサブスクリプションは、以前より少ない価値で、以前より質の低いものを提供しています。それは決して許容されるべきではありません。私たちは本当の変化が見られるまで、彼らの問題を指摘し続けるつもりです。皆さんにもそうしていただきたいと願っています。これは本当に重要なことだからです。クソみたいなコードを書き、その仕組みについて一切の透明性を提供せず、私たちが毎日依存しているツールが劣化していく中で、ただ笑って手を振って受け入れてくれるだろうと期待することで自らを追い詰めているという事実に、彼らが一日も早く目を覚ましてくれることを願っています。本当は皆さんにCodexへの移行をお勧めしたいところですが、皆さんはすでに私のことを企業の手先だと言っていますからね。今回はここで終わりにしようと思います。それではまた次回。
コメント