Anthropic最新モデルでツール呼び出しが後退 RL過学習の懸念

Armin Ronacher氏（Flaskフレームワークの開発者として知られる）が自身のブログで報告した内容によれば、Anthropicの最新モデル「Claude Opus 4.8」および「Sonnet 5」において、ツール呼び出し（tool calling）の動作に深刻な品質回帰が確認されている。Ronacher氏が運用するプロジェクト「Pi」の編集ツールで問題が発生し、古いモデルでは正常に機能していた呼び出しが、最新モデルではスキーマに存在しないフィールドを模型が発明する形で失敗するという。

問題の詳細

Ronacher氏が遭遇した事象は、Piのeditツールに対してモデルが発行するツール呼び出しに関するものだ。editツールはファイルの編集を行うために、pathとeditsというパラメータを受け取る。editsはオブジェクトの配列で、各オブジェクトはoldTextとnewTextというフィールドを持つ。しかしOpus 4.8は、このedits配列内に、スキーマで定義されていない余計なキーを勝手に追加するという行動を示した。編集内容自体は正しい場合が多いものの、引数がスキーマに合致しないためPi側がツール呼び出しを拒否し、モデルに再試行を促す。結果として無駄なラウンドトリップが発生し、処理が非効率になる。

Ronacher氏はこの問題が「モデルがときどき不正なツール呼び出しを生成する」という既知の現象とは質的に異なると指摘する。特に注目すべき点は、古いモデルでは発生しなかったこの問題が、Opus 4.8およびSonnet 5という最新のState-of-the-Artモデルで顕著に現れたことだ。つまり、Anthropicのモデルファミリーの中で、最も高性能とされるモデルが特定のツールスキーマに対しては旧モデルよりも劣る結果を示している。Ronacher氏は、Fableモデルに関しては意図的にテストを行わなかったとも述べており、FableにはOpusへのサイレントダウングレードを引き起こす分類器が動作している可能性を警戒している。

ツール呼び出しの仕組み

この問題の本質を理解するには、LLMにおけるツール呼び出しの内部動作を把握する必要がある。Ronacher氏の解説によれば、ツール呼び出しは「魔法」ではなく、かなり粗い帯域内信号（in-band signalling）に依存している。モデルは会話の履歴、システムプロンプト、利用可能なツールのリストを受け取る。サーバー側はこれらを特殊なマーカートークンと共に巨大なプロンプトに変換する。モデルは訓練と強化学習（RL）の過程で特定のフォーマットパターンを学習しており、生成の途中で「このツールをこれらの引数で呼び出す」という意味のトークン列を出力する。

Anthropicのモデルでは、このフォーマットはXMLに似たマーカー（<antml:function_calls>など）で表現される。ただし、これは真のXMLではなく、トークン化と学習に都合が良いように設計された独自形式である。注目すべきは、トップレベルの文字列パラメータはインラインで表現される一方で、オブジェクトの配列はJSONシリアライゼーションを介して埋め込まれる点だ。この「JSONの内部埋め込み」という構造が、今回の問題の背景にある可能性が高い。

強化学習による過学習の可能性

Ronacher氏はこの現象の原因として、Anthropicが自社のコード実行環境「Claude Code」のハーネスに対して強化学習を強く行った結果を疑っている。Claude Codeハーネスはクローズドソースであり、外部の開発者が利用するツール宣言とは微妙に異なる可能性がある。モデルはClaude Codeのハーネスに最適化されるように強化学習された結果、一般のツール宣言に対して「近いが少し異なる」記述を生成するようになったのではないか。つまり、Claude Codeの内部スキーマに合わせて学習されたパターンが、他のツールでは余計なフィールドとして現れているという仮説だ。

この仮説が正しければ、Anthropicがモデルのツール呼び出し品質をClaude Codeという特定の閉じた環境で評価し、その評価指標を最適化した結果、一般環境での汎用性が損なわれた可能性がある。RLによる過学習（RL overfitting）の一種と言える。

開発者への影響と示唆

この問題は、LLMをツール連携の基盤として利用する開発者にとって重要な示唆を含む。まず、モデルのバージョンアップに伴うツール呼び出しの互換性を自動テストで担保する必要がある。従来は「新しいモデルほど賢い」という前提で移行が進められていたが、今回の事例は最新モデルが特定のタスクで後退するリスクを明確に示した。

また、ツール呼び出しのフォーマットがモデル内部のRLプロセスに依存していることが明らかになった。開発者は自社のツール定義がモデルの学習データやRLプロセスとどの程度整合しているかを考慮する必要がある。特に、モデル提供企業が自社製品向けに最適化を行っている場合、その恩恵が外部ユーザーに一様には及ばない可能性がある。

Ronacher氏の指摘は、単なるバグ報告以上の意味を持つ。LLMの進化が「汎用性能の向上」という単純な直線ではないことを示しており、特定のベンチマークやユースケースだけを見てモデルの優劣を判断することの危険性を再認識させる。

編集部の見解

本件は、AIモデルの「賢さ」が実際のツール連携において必ずしも改善として現れないことを示す重要な事例だ。短期的には、Anthropicがこの問題を認識し、強化学習のデータ分布や評価方法を見直す可能性が高い。特にClaude Codeのハーネスと一般APIのツール宣言との間に存在するギャップが、本件の根本原因であれば、モデルのトレーニングパイプラインに一般ツールのテストケースを追加する必要がある。また、開発者コミュニティでは、ツール呼び出しの回帰テストをCIに組み込み、モデルバージョンごとに動作を検証するプラクティスが普及するだろう。 長期的な視点では、LLMのツール呼び出し品質を評価する標準的なベンチマークの必要性が高まっている。現在のベンチマークは主に質問応答やコーディング能力に焦点を当てており、ツール定義の厳密な解釈やスキーマ準拠を測定する指標が不足している。モデル提供企業は、自社の製品エコシステムに閉じた最適化ではなく、より汎用的なツール連携の品質を重視する方向に軸足を移すべきだ。そうでなければ、エコシステムの囲い込みが進む一方で、外部開発者の信頼を損なうリスクがある。

参考

• Better Models: Worse Tools - Armin Ronacher’s Thoughts and Writings — 2026-07-04公開