AnthropicのClaudeモデルは、コード生成とエージェントの信頼性で技術的課題に直面

Anthropicは最近、Claudeモデルの複数の技術的課題に直面している。コード生成はウォーターマークの埋め込み制約により自由度が低下している。Sonnet 5のアダプティブシンキング機構により、同一モデルが異なる計算リソースを調整可能になり、製品ラインの能力境界が曖昧になっている。1Mのコンテキストは表面上豊富に見えるが、長時間のエージェント会話ではモデルが実質的に20%～30%程度しか効果的に使用できず、その後状態の混乱や見落としが発生する。コンテキスト圧縮時に、どの情報が依然として有効かを判別することが困難であり、一時的な仮定が事実として誤って扱われる可能性がある。エージェントが環境を自ら変更した後、モデルは元の問題ではなく、自身が作り出した新たなエラーを分析し始める。この記事は、長時間エージェントの信頼性が、単なるモデルの単一ステップ性能ではなく、状態の明確さ、アクションの検証可能性、エラーのロールバック可能性にますます依存していると指摘している。

記事執筆者、出典：雷锋网

モデルのスコアが下がるよりも深刻なのは、モデルがまだアップグレード中なのに、ユーザーが使いにくくなってきたと感じ始めていることだ。

Anthropicは最近少しそのような雰囲気だ。

この数日、X 上には、Claude が最近いくつかの典型的な不満をまとめた投稿がありました：テキストとコードに機械可読マークが追加され始めたこと、Sonnet 5 の実際の体験がモデルのアップグレードの勢いに追いついていないこと、Fable 5 はより高価で販売されているが、Opus 5 よりもはるかに優れていると感じられる点が明確でないこと、そしてさらに目立つフィードバックとして、Fable 5 のコンテキストは約20％～30％までしか使用されておらず、その後の能力は低下し始めるという点です。

これらの問題は表面上関係ないように見えますが、一つは生成メカニズムの問題、一つはモデルの能力の問題、一つは価格設定の問題、もう一つは長文コンテキストに不具合が生じているように見えます。

しかし、Claude の現在の技術スタックから見ると、それらは実際には5つの具体的なポイントで課題に直面している：モデルがどのように生成するか、推論時にどの程度の計算リソースを割くか、異なるモデルがなぜますます層化しにくくなっているか、長文コンテキストが満たされる前になぜ機能が失われるか、そして実験での能力が実際のエージェントタスクでなぜしばしば低下するか。

したがって、Anthropic の最近の問題は、単に「モデルの性能が低下した」というものではない可能性があります。むしろ、Claude がますます強力になったことで、生成、計算、コンテキスト、およびエージェントの実行時が互いに引きずり合うようになっているように見えます。

01

機械可読マーカーを通常のテキストに組み込む際の技術的課題は、安定したシグナルを残しつつ、生成品質への影響を最小限に抑えることです。コードになると、この問題は明確に難しくなります。なぜなら、自然言語とコードのトークン分布は異なるからです。

論文：https://arxiv.org/pdf/2301.10226

自然言語では、意味が類似する複数の候補が存在することがよくあります。同じ意味を表現する際に、語を変更したり語順を変えることができ、モデルは多くの位置で一定の生成冗長性を持っています。テキストのウォーターマークの一般的なアプローチの一つは、この冗長性を利用して、複数の許容可能なトークン間でサンプリング確率をわずかに変更し、十分に長く積み重ねることで統計的パターンを残すことです。

コードには多くの低エントロピー領域が存在する。変数宣言後、その後の参照ではほぼ同じ名前しか使用できない；JSONのフィールド、引用符、括弧は厳密な構造制約を受ける；関数のパラメータはインターフェースに準拠しなければならない；パス、正規表現、SQL、Shellコマンドでは、1つのトークンが変化すると動作が直接変わる可能性がある。

確率分布を見ると、これらの位置は非常に鋭い傾向があります。正しいトークンが高確率を占め、他の候補は別の表現ではなく、むしろ誤りである可能性があります。したがって、コードウォーターマークが直面する核心的な制限は、実際の符号化容量です。

ある位置に唯一の合理的出力しかない場合、その位置には追加のシグナルを担う余地がほとんどない。一方、システムが高エントロピー位置にのみマーカーを埋め込むと、コードが短くなり、構造化トークンの割合が高くなり、利用可能な位置が不足する問題が生じる。

したがって、検出強度、生成品質、および改変耐性の間には直接的なトレードオフが生じます。信号が弱すぎると検出が難しくなり、制約が強すぎると正しい生成に影響を与える可能性があり、フォーマット変更や局所的な書き換え後も検出能力を維持するには、より高い信号冗長性が必要です。

AnthropicはClaudeのテキストタグがどのようにサンプリングを変更するかを公開していないため、Claude Codeの品質変化を特定のウォーターマークアルゴリズムに直接帰因することはできません。

ここで確実に言えるのは、もう一つの変化である：コード生成は、ますます多くの制約を同時に担っているということだ。意味的正しさと実行の正確性に加えて、ツールプロトコル、構造化フォーマット、セキュリティルール、およびソースタグに従う必要がある可能性があり、コード自体がこれらの追加制約を取り込む自由度は、自然言語よりもはるかに小さい。

02

Sonnet 5 のアダプティブシンキングがもたらす変化は、モデルがもう少し考えるようになるだけではありません。

以前谈论Sonnet、Opus、Fable时，很容易将它们理解为几个固定的能力点。现在加入了effort之后，同一个模型可以落在不同的test-time compute区间内，型号本身已无法完整代表一次请求实际投入了多少能力。

参考リンク：https://platform.claude.com/docs/en/build-with-claude/effort

この変化は、Coding Agent において特に顕著である。Claude がバグに直面したとき、修正案を生成するだけでなく、どのファイルを読み込むか、どの呼び出しチェーンを追跡するか、いくつの候補仮説を保持するか、テストを実行するか、依存関係のチェックを継続するか、そしてどの時点で証拠が十分であると判断するかを決定しなければならない。

これらの動作は検索木と見なすことができます。計算リソースの投入が少ないほど、枝を早期にカットし、判断を迅速に形成します。一方、投入を増やすことでモデルは検索と検証を継続でき、証拠が不十分な状況での行動実行の確率を低下させます。

参考リンク：https://platform.claude.com/docs/en/build-with-claude/effort

したがってeffortは単なるthinkingの長さを調整するのではなく、1つのAgentタスクが許可する検索範囲の広さを制御します。これはAnthropicのモデルの階層に直接影響を与えます。

もし通常のコーディングタスクがOpusにとってすでに難しくない場合、effortを上げれば、Opusはすぐにパフォーマンスプラットフォーム領域に入ると考えられます。Fableはより強力なベースモデルを持っていても、明確な体験の差に変換できる難易度はそれほど残っていません。

ユーザーはリクエスト開始時からモデル間の価格差を支払う必要があります。したがって、Fableが価値をより明確に示すのは、通常のコード解釈、小規模なリファクタリング、または一般的なデバッグではなく、未知のコードベース、複数段階の計画、複数ツール間の操作、長時間の自律実行、およびエラー発生後の復旧が必要なタスクです。

参考リンク：https://www.anthropic.com/news/claude-opus-5

これは、高階モデルが販売しているものが変化していることを意味します。今や、単に「このラウンドの回答がより優れている」だけでなく、より複雑なトレジャクトにおける追加の信頼性を提供しています。

問題は、このような優位性はタスクが十分に長くなければ発揮されず、タスクが長くなると、モデルの能力が唯一の決定要因ではなくなり、コンテキスト状態が中心的な役割を果たし始めるということです。

03

1Mのコンテキストを見ると、それは巨大な作業メモリのように思えるため、Claudeが200Kまたは300Kトークンしか使用していないのに、情報を見落としたり、繰り返したり、状態が混乱したりするのは非常に直感に反する。

しかし、コンテキストウィンドウは容量を測定するものであり、状態の一貫性を測るものではありません。長いエージェントセッションは静的なドキュメントではなく、継続的に追加される実行履歴です。

参考リンク：https://platform.claude.com/docs/en/build-with-claude/context-windows

ファイルは複数回更新される可能性があります。あるバグは当初キャッシュの問題と判断されましたが、後に並列処理が原因であることが判明しました。あるテストは最初に失敗し、その後成功しましたが、新たな変更により再び失敗しました。古い内容は状態の変化に伴って自動的に削除されず、新しい内容は常に後方に追加されます。

ここに生じている問題は、リトリーバルを超えたものである。モデルは現在のタスクに関連する情報を検索するだけでなく、その情報が現在も有効であるかどうかを判断しなければならない。

旧バージョンの関数と新バージョンの関数は非常に類似しており、旧テストログと新テストログには多数の同じトークンが含まれています。すでに否定された分析でも、現在の問題と意味的に非常に関連している可能性があります。Attention はこれらのコンテンツを見つけるのは難しくありませんが、それら間のカバー関係を特定することが難しいです。

データベースはバージョン番号、更新時間、トランザクション、明示的なフィールドによって現在の状態を維持できますが、自然言語のコンテキストには通常このような構造がありません。それはアペンドオンリーなログに近いものであり、モデルはイベントの順序から現在の世界がどのような状態であるかを自ら復元する必要があります。

参考リンク：https://platform.claude.com/docs/en/build-with-claude/context-windows

したがって、長いコンテキストの複雑さは、トークンの占有比率と単純には対応しません。250Kトークンの静的ドキュメントは、後者が多数の変更されたオブジェクト、段階的な判断、ツールの結果、および無効となったステータスを含んでいるため、250Kトークンのエージェントの履歴よりもはるかに処理しやすい可能性があります。

Thinking history はさらにこの複雑さを増すでしょう。会話に保存されるのは、「何が起きたか」だけでなく、「当時なぜそのように判断したか」も含まれる可能性があります。早期の推理が後に否定された仮定に基づいている場合でも、その推理は現在の問題と非常に関連性が高いため、今後の判断に引き続き参加する可能性があります。

したがって、1Mのコンテキストの真の制限は、どれだけ多くの情報を格納できるかではなく、同じオブジェクトの履歴バージョンが増えるにつれて、モデルが現在のバージョンを安定して復元できるかどうかです。

04

コンテキストが継続して増加するにつれ、コンパクションは自然な解決策のように見えます：古い履歴を短縮し、処理を継続します。しかし、エージェントのシナリオにおけるコンパクションは、一般的な要約とは異なります。

要約文で例が一つ欠けている場合、影響は情報の完全性にとどまることが多いが、エージェントの軌跡を圧縮する際に、依然として有効な制約条件を一つ見落とすと、その後の実行パスが直接変化する可能性がある。

参考リンク：https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

コンパクションが解決すべきは「どの内容が重要か」ではなく、「どの内容が現在有効か」である。歴史の中には、完了したタスク、後に却下された判断、現在も有効なインターフェース制約、期限切れのテスト結果、一時的なワークアラウンドが同時に存在する可能性がある。コンパクタは、これらの時間的状態を再整理し、次のラウンドで継続して使用できる形に再構成する必要がある。

「現在、問題はキャッシュに由来すると疑われている」が「問題はキャッシュに由来する」と短縮されると、仮説が事実になってしまう。廃止された方案が依然として要約に含まれる場合、後続のエージェントは古いパスを再実行する可能性がある。重要な制約が要約に含まれない場合、モデルはその後、その制約を再び認識しなくなる。

したがって、コンパクションの重要な指標は圧縮率ではなく、状態の忠実性です。これは、Git、テスト、タスクファイル、メモリ、構造化されたハンドオフが長期エージェントにおいてますます重要になる理由でもあります。

それらは、モデルが見られる情報を単に増やすのではなく、長期的に成立する状態を自然言語の履歴から外部システムに移動させています。Gitは現在のコードバージョンを明確にし、テストは検証可能な結果を提供し、タスクファイルは完了状況を記録し、構造化された状態は現在の結論と過去の試行を区別します。

コンテキストは豊富な履歴を保持できますが、すべてのステート管理の責任を長期的に担うことはできません。

参照リンク：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

前のいくつかの質問は、モデルが入力をどのように処理するかという点で理解できます。エージェントはさらに一歩進み、環境を積極的に変更します。

通常のチャットでは、モデルが1回間違えると、その誤りは出力テキストにとどまります。エージェントはコードを変更し、コマンドを実行し、依存関係をインストールし、設定を調整して、これらのアクションによって生成される新しい結果を読み取ることができます。

したがって、エラーは単なる判断ミスではなく、環境の変化にもなり得ます。Claudeがバグをキャッシュの問題と誤判断し、キャッシュロジックやリトライメカニズム、複数の呼び出し箇所を修正したところ、テストで新たな異常が多数発生しました。

これらの異常は実在するが、元のバグが自然に生じたものではなく、前の修正によって生み出されたものである。これにより、エージェントは非常に特異な失敗モードに陥る：モデルは自分自身が生成したデータ分布を分析し始める。

参考リンク：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

それが「これらの新しいエラーは前回の修正後に発生した」と認識できれば、ロールバックして元の仮定を再確認できるが、この因果関係が構築されていないと、新しいエラーを個別の問題と見なして次々と修正し続けてしまう可能性がある。

この時点では、各ステップの局所的な操作には根拠がある可能性があるが、タスクの全体的な経路は元の問題から逸脱している。したがって、長距離エージェントの信頼性は単一ステップの正解率だけでは評価できない。より重要なのは、エラーが環境に侵入した後、システムがそれを検出・原因特定・回復できるかどうかである。

Git diff は、モデルに直近で発生した変更を伝えることができ、テストは特定の動作が破壊されていないかを検証できます。checkpoint と rollback はエラーの拡散を制限し、独立した evaluator はモデル自身の説明に加えて追加の検証を提供します。

これらのコンポーネントの役割は、本質的にエージェントにフィードバックループによる誤り修正機能を付与することです。

参考リンク：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

多くのベンチマークは、モデルに初期化された環境を与え、その環境でタスクを完了できるかどうかを測定します。しかし、実際のエージェントにはさらに一つの困難が加わります。環境はモデル自身の行動によって常に変化します。したがって、最終的な通過率がほぼ同じでも、実際の体験は大きく異なる可能性があります。

あるモデルは初期の判断は正確だが、一度間違えるとその誤った道筋を繰り返し修正し続ける。一方、別のモデルは単一のステップで明らかに優れているわけではないが、ある修正が新たな問題を生み出したことをより速く見抜き、ロールバックして別の道筋を選択できる。

終点だけを見ても、この二つの行動を区別するのは難しい。Agentのタスクがさらに長くなると、より意味のある指標は、コンパクション後にどの程度の重要な状態が保持されているか、誤った修正が発生した後にエラーを引き起こしたステップを特定できるか、ツール呼び出しの増加に伴い内部タスク状態が実環境と一致し続けるか、そして逸脱した後に回復するのにどの程度のコストが必要かとなる。

これらの指標は、1回の応答がどれほど賢いかを測るのではなく、トレジャクトリーが制御可能であるかどうかを測っています。

以上のように、Anthropicが最近暴露した複数の問題は、異なるレベルに属しています。これらの問題が集中して発生したことで、Claudeの技術的ボトルネックも変化し始めています。

過去はモデルが特定の問題を解けるかどうかを問うものだったが、現在はさらに難しい課題がある：タスクが数時間実行され、数十回のツール呼び出し、数回の状態圧縮、複数回のコード変更を経た後、システムは依然として信頼できる現在の世界を維持できるのか。

モデルの能力は引き続き成長し、各ステップの判断上限を高めることしかできない。一方で、長距離エージェントが安定して動作できるかどうかは、状態が明確かどうか、アクションが検証可能かどうか、エラーがロールバック可能かどうかという別の能力にますます依存するようになっている。