より優れたモデル、より劣るツール
Armin Ronacher 氏が Pi の開発中に遭遇した奇妙な問題を報告しています。新しい Claude モデル（Opus 4.8 や Sonnet 5）が Pi の編集ツールを呼び出す際に、余分なフィールドを追加してしまい、ツール呼び出しが拒否されるというものです。古いモデルではこの問題は見られません。原因として、Anthropic が強化学習を用いて Claude Code 組み込みの編集ツールに最適化した結果、サードパーティのツールで誤動作が生じている可能性が指摘されています。このことから、Pi のようなフレームワークはモデルごとに複数の編集ツールを実装すべきかという疑問が生じます。
最新のブログ記事で、Armin Ronacher 氏は AI プログラミングアシスタント「Pi」の開発中に遭遇した不可解な問題を共有しています。新しい Claude モデル（Opus 4.8 や Sonnet 5）が Pi の編集ツールを呼び出す際、ネストされた edits[] 配列に存在しないフィールドを追加することがあるのです。編集操作自体は正しいことが多いものの、スキーマにないキーが含まれているため、Pi はツール呼び出しを拒否し、モデルに再試行を求めます。
モデルが不正なツール呼び出しを生成することは珍しくありません。特に小規模モデルではよく見られます。しかし驚くべきは、この問題が新しいモデルでより頻繁に発生している点です。Opus 4.8 と Sonnet 5 の両方で確認されたのに対し、Opus 3 や Sonnet 4 など古いモデルでは全く見られません。つまり、Anthropic ファミリーの最先端モデルは、特定のツールスキーマを正しく使う能力において、旧モデルよりも劣っているのです。
Armin 氏は、この原因として Anthropic が強化学習（Reinforcement Learning）を利用して、新しいモデルを Claude Code に組み込まれた編集ツール（検索置換方式）に最適化したことを挙げています。このトレーニングにより Claude Code 上でのパフォーマンスは向上したものの、副作用として、Pi のようなサードパーティ製フレームワークのカスタムツールに対しても同様の行動を適用してしまい、不適切な呼び出しが増えたと考えられます。
この観察結果は、より広範な問題を提起します。モデルベンダーが自社ツールに特化した最適化を進める中で、サードパーティのフレームワークは複数の編集ツールを実装せざるを得なくなるのでしょうか？例えば、OpenAI の Codex は apply_patch メカニズムを採用し、OpenAI はモデルがそのツールを効果的に使えるよう訓練していると公言しています。Pi のようなフレームワークは、検索置換方式とパッチ適用方式の両方に対応し、ユーザーが選択した基盤モデルに最適なツールを動的に切り替える必要があるかもしれません。
現時点では明確な答えはありませんが、この問題は AI ツールエコシステムにおける潜在的な分断を示唆しています。モデルが特定のプラットフォームに最適化されるほど、フレームワーク間の互換性が損なわれる可能性があります。開発者は、柔軟性を維持しつつ、モデルの予期せぬ動作の変化に対応する方法を模索する必要があるでしょう。