概要

• Anthropicの新しいClaudeモデル がツール呼び出し時に スキーマ外のフィールド を生成する問題の発生
• Opus 4.8やSonnet 5 など最新モデルで 症状が悪化
• ツール呼び出しの仕組み や 失敗のパターン、 原因の推測 について解説
• Claude Codeのハーネス の寛容設計が モデルの学習に影響
• ツールスキーマ設計の重要性 と今後の懸念点

Anthropic Claudeモデルのツール呼び出しにおける奇妙な問題

• 新しいClaudeモデル （特にOpus 4.8やSonnet 5）で、 Piのeditツール 呼び出し時に 余計なフィールド がedits[]配列内に生成される現象
• Haikuや小型モデル ではなく、 最先端（SOTA）モデル で顕著に発生
• edit自体は正しい内容 だが、 スキーマにない引数 が追加されるためPi側がリジェクトし再試行を要求
• 小型モデルでのツール呼び出し不整合 は一般的だが、 新型モデルで悪化 している点が驚き
• 古いモデルでは発生せず、 新しいモデルほどこの問題が顕著

ツール呼び出しの内部構造

• ツール呼び出し は テキストベース で、 特別なマーカー や プロンプト構成 に依存
• モデルは システムプロンプト と 利用可能なツール一覧 を受け取り、 特定のトークン形式 でツール呼び出しを生成
  • 例:

    {
      "path": "some/file.py",
      "edits": [
        { "oldText": "置換前テキスト", "newText": "置換後テキスト" }
      ]
    }
    

  • 内部的には ANTML風マークアップ でシリアライズされるが、 XMLではなく独自形式
• 配列パラメータ はJSONで表現され、 トップレベルの文字列パラメータ はインラインで記述

モデル出力の制御手法

• 2種類の生成制御:
  • 後検証型: モデルに 有効なJSON を出力させ、 事後検証 でスキーマ違反を弾く
  • 文法制約型: 生成時に不正なトークンをマスキング し、 スキーマ違反自体を防ぐ
    • grammar-aware/constrained decoding と呼ばれる
    • 許可されていないキー や enum値 を生成不可に
• 制約なしの場合、モデルは 学習した慣習 に従うのみ

発生している失敗パターン

• Piのeditツール は複数のstring置換を1回で受け付けるため、 edits配列 を持つ
• 失敗例:
  • {"oldText": "...", "newText": "...", "requireUnique": true}
  • {"oldText": "...", "newText": "...", "oldText2": "", "newText2": ""}
• 観察された余計なキー:
  • type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2, event.0.additionalProperties など多数
• oldText/newText自体は正しい が、 余計なフィールドが付与される
• 文脈依存性が強く、単純なプロンプトでは再現しにくい
• エージェント的な複雑な履歴 や 特定のセッション で再現率が上がる
• thinkingブロック削除 や strict tool invocation有効化 で失敗率低減

なぜ新モデルで悪化したのか

• 最大の仮説 は 学習データやハーネスの変化 によるもの
  • 古いAnthropicモデル は Claude Codeのようなハーネスを想定せず に訓練
  • 新しいモデル は Claude Codeや類似ハーネス を強く意識して訓練
    • Claude Codeのeditツール は Piのedits[]型とは異なるフラットなスキーマ
    • クライアント側で不正引数のリトライ・修正・エイリアス対応 など、 寛容な設計
    • 学習時に多少のスキーマ違反でも報酬が与えられる
    • モデルがClaude Codeのスキーマに過剰適応 し、 異なるスキーマに弱くなる
• Opus 4.5時代は柔軟性が高かった が、 現行モデルは特定スキーマへの依存が強化

Claude Codeのハーネス設計

• Claude Codeのハーネス は closed-source だが、 minifiedコードから挙動を推測可能
• 受信データに非常に寛容
  • <invokeマークアップ検出 や テレメトリ送信
  • Unicodeエスケープ修正 や パラメータエイリアス対応
    • old_str/old_string, new_str/new_string, path/file_path など
  • 予期しないキーのサイレントフィルタリング
  • strict modeは未使用 （定義の複雑性制限のため）
• この寛容性がモデルの学習や出力傾向に影響

strict modeと他ハーネスとの比較

• strict mode有効化 で Anthropicモデルの問題が解消
  • サーバー側で許可されないキーの生成を拒否
  • ツール定義の複雑性制限 があるためClaude Codeでは未使用
• OpenAIのharmonyフォーマット では、 <|constrain|>json のような明示的制約がプロンプト内に含まれる
  • LARK grammar提供 も可能
  • ツール呼び出し部分のみ文法制約サンプリング に切り替えやすい設計
• Anthropicモデルでも部分的に文法制約が働いている可能性
  • 配列パラメータ で 高エントロピー箇所 （長い文字列直後）に 余計なキーが混入しやすい
• Codexモデル ではこのような退化は未観測

ツールスキーマ設計への示唆

• ツールスキーマは中立的ではなく、モデル依存性が強い
• 「スキーマ＝抽象契約」 という前提が Anthropicモデルでは通用しない場合がある
• モデルが特定のスキーマやハーネスに適応しすぎると、他のツールスキーマへの対応力が低下
• 今後のツール設計やハーネス設計では、モデルの学習環境やハーネスの寛容性を考慮する必要性

まとめ

• Anthropic Claude新モデル は 特定のツールスキーマに過剰適応 し、 異なるスキーマで失敗しやすい
• ハーネスの寛容性 や 学習時の報酬設計 がモデル挙動に大きく影響
• strict modeや文法制約 で部分的に解決可能だが、 Claude Codeのような寛容ハーネス では問題が残る
• ツールスキーマ設計 と モデル訓練環境 の関係性を理解し、 将来の互換性や適応性確保 が重要