自前でツール定義やMCPサーバーを実装しているなら他人事ではない。新しいClaudeモデルほど、独自スキーマにない項目を勝手に発明して壊れたtool callを出す——という逆説的な報告があった。
「賢いモデルほど安全」という前提を疑う理由と、自前のツール定義を壊されないための検証・拒否・再試行ループ、スキーマ設計を寄せる方向の考え方。
コーディングツール「Pi」の開発者Arminが報告した現象が、Simon Willisonのブログ「Better Models: Worse Tools」で紹介されている。新しいClaudeモデル（Opus 4.8、Sonnet 5）は、より古いモデルよりもPiの独自編集ツールに対して壊れた呼び出しを出しやすいという。
具体的には、ネストされたedits[]配列の中に、スキーマに存在しない項目を勝手に追加して呼び出してくる。Piはこれをスキーマ違反として拒否し、モデルに再試行を要求する仕組みになっているため実害は防げているが、「新しいモデル＝より信頼できる出力」という前提が崩れているのがそのまま観測できる事例だ。
Arminの仮説は、モデルの知能低下ではなく、強化学習の対象が変わったことにある。
新しいClaudeモデルは、Claude Code組み込みの編集ツール——search and replace方式——に対して強化学習で強く最適化されている可能性が高い。組み込みツールの成功パターンに寄りすぎた結果、それ以外の形をしたツール定義への汎化が弱くなった。
Piの独自編集ツールは、Claudeが慣れた search and replace の形と微妙に違うネスト構造を持つ。モデルにとってはこれが「見慣れない形」であり、慣れた形に寄せようとして存在しない項目を発明してしまう、という説明がつく。
対比としてOpenAI Codexはapply_patchという別方式のメカニズムを持つ。つまり「正解の編集ツール形状」はベンダーごとに異なり、自前ツールがどちらの形にも似ていなければ、どちらのモデルでも同じ問題が起こりうる。
ここが核心。モデルのバージョンが上がるたびに、賢さは上がってもツール呼び出しの正確さが上がるとは限らない。強化学習が最適化した対象（組み込みツールの形）から外れるほど、逆に崩れやすくなる。
元記事はこの現象を報告するに留め、明確な解決策までは示していない。ただ、自分でツール定義やMCPサーバーを実装している側からすると、翻訳できる教訓ははっきりしている。
Piがそうしているように、スキーマ外の項目は黙って受け入れず、エラーとして突き返して再試行させる。壊れた呼び出しをそのまま処理してしまう実装は、モデルが賢くなるほど危険になる。
独自のネスト構造を発明するより、search and replaceのような広く学習されている形に寄せられないか検討する。奇抜な設計であるほど、モデル側の「見慣れた形に寄せたい」圧力で崩れやすい。
使っているモデルのバージョンを上げた直後は、スキーマ違反で拒否した回数が増えていないかをログで確認する。壊れた呼び出しの増加は、性能向上の裏で静かに起きるドリフトとして現れる。
独自のツール定義・MCPサーバーを持っているなら、次のモデル更新で同じことが起こりうる。