何が起きたか
Armin氏がコーディング環境「Pi」を開発中に発見した挙動として、AnthropicのOpus 4.8とSonnet 5が、Piの編集ツールを呼び出す際にedits[]配列の中に存在しない架空のフィールドを混入させる問題があります。編集内容自体はおおむね正しいものの、スキーマに合わない引数のためPiはツール呼び出しを拒否します。
注目すべきは、Haikuなどの小型モデルではなく最上位のOpus 4.8で発生し、しかも旧世代のClaudeモデルには見られない点です。つまり、モデルファミリー内で最新・最強のはずのSOTAモデルが、この特定のツールスキーマに関しては旧モデルより劣化しているという逆転現象が起きています。
なぜ重要か
Armin氏の仮説では、AnthropicはClaude Code内蔵の編集ツールをより上手く使えるよう、強化学習等で新モデルを特化して訓練した可能性があります。その結果、Piのように独自スキーマの編集ツールを持つサードパーティのコーディング環境では、モデルが「Claude Code流」のキーを勝手に生成してしまうと考えられます。
Claudeの編集ツールはsearch-and-replace方式である一方、OpenAIのCodexはapply_patch方式を採用しており、OpenAIも自社モデルをapply_patch向けに訓練していることを公表しています。
論点：ツールは自作か、宿主に合わせるか
この報告は、サードパーティのコーディングハーネスが「モデル最適な編集ツールを複数実装し、ユーザーの選択モデルに応じて切り替えるべきか」という設計上の問いを突きつけています。モデルベンダーがコーディング環境を垂直統合する時代、ハーネス開発者は「モデル中立」を捨てて宿主のツール流儀を模倣する現実的な判断を迫られつつあります。
💼 事業会社視点：これは自社にどう効くか
開発ツールSaaSや、Claude/GPTを組み込んだAIエージェント製品を提供する日本企業にとって、この事例は「モデル選定＝ツール設計」であることを示す警鐘です。
受託開発・SIer：クライアント向けにCursorやCline、独自ハーネスを提案する際、Claude系を推すならスキーマをClaude Code方式（search-and-replace）に寄せる、OpenAI系ならapply_patch方式に寄せる、といった「モデル別ツール設計」がベンチマーク差以上の効果を生みます。汎用スキーマの一本化は、SOTAモデルほど性能が落ちるリスクを抱えます。
AIエージェントSaaS事業者：ツール呼び出し失敗率をモデル別にモニタリングし、モデルアップデート時にKPIが劣化していないかを回帰テストする体制が必須です。特に「上位モデルほどエラー率が上がる」逆転が起き得るため、単純な「新モデルへ自動アップデート」は避けるべきです。
事業責任者への含意：ベンダーは自社のリファレンス実装（Claude CodeやCodex）を暗黙の学習ターゲットにしています。独自ハーネスを持つ場合、モデル選定の自由度は表面的で、実質的にはベンダーのツール流儀に引きずられます。マルチモデル戦略を掲げる企業は、モデルごとのツールアダプタ層をアーキテクチャの前提に組み込むべきです。
