モデルは賢くなったのに、ツールが壊れるという話

最近、Flask の作者としても知られる Armin Ronacher さんが書いた「Better Models: Worse Tools」という記事が、開発者コミュニティで話題になっています。私も Claude Code を毎日のように触っているので、これは他人事ではないなと思って読みました。

内容をざっくり言うと、Anthropic の最新モデル（Opus 4.8 や Sonnet 5）は、タスクを解く能力自体は明らかに上がっているのに、Claude Code 以外のツールスキーマを渡すと、以前よりも壊れたツール呼び出しを出しやすくなっている、というものです。賢くなったのに、道具の扱いは下手になっている。この矛盾がなかなか興味深いんですよね。

何が起きているのか

Ronacher さんが実際に困ったのは、Pi というエディタ向けのツール、その中でも入れ子構造を持つ編集ツールでした。新しい Anthropic 系モデルに使わせると、スキーマに定義されていない余計なフィールドを勝手に足してきたり、別名でパラメータを送りつけてきたりする。編集内容自体は正しいのに、ツール呼び出しの体裁が合わないので実行が失敗する。そういう症状です。

面白いのは、これがモデルの能力低下ではないところです。同じモデルに Claude Code のツール形式で同じことをやらせるとちゃんと動く。つまり「タスクは解けるけれど、指定された非 Claude Code 形式のスキーマに忠実に従えない」という、かなり限定的な劣化なんですよね。

なぜこうなっているか

Ronacher さんの推測は、post-training の影響というものです。Claude Code のハーネスは、多少スキーマから外れたツール呼び出しでも受け流してうまく動かす、いわゆる「寛容な」設計になっている。だから post-training の環境で、モデルは「多少余計なフィールドを付けても大丈夫」「別名でも通る」というふうに、いわば手癖を覚えてしまう。

そこにきて、Pi のように厳格なバリデーションを求めるツールに出会うと、いきなり通用しなくなる。Anthropic の中に閉じている限りは快適に動くけれど、外の世界で使うと途端に不器用になる、というわけです。まさに家の中では丁寧語をサボっていた子どもが、よその家で急に困るような話に近いなと私は思いました。

開発者側で何をすべきか

この記事の結論は明快で、カスタムのエージェントハーネスを書く側は、モデルの善意やあいまいさを当てにするのをやめて、grammar-constrained なツール呼び出しや、厳格な JSON Schema バリデーションを自前で用意しましょう、という話です。要は、モデルが変な出力をしたら通さない、という強い保証をハーネス側に置く。

これは実はけっこう重い提案だと思います。今まで多くの人は「モデルが賢いから、ちょっと雑なスキーマでも吸収してくれる」という前提で作ってきたはずで、私もそういう楽観に片足を突っ込んでいた自覚があります。でも、モデルが特定のハーネスに寄って進化するという流れが本当なら、汎用に使えるハーネスを目指すほど、逆に自分の側で守りを固める必要が出てくる。ここは頭を切り替えたほうがよさそうです。

まとめ

私が気になったのは、モデルの進化と、そのモデルを最も便利に使えるハーネスが同じ会社の中で密接に絡み合っている、という構図そのものです。もちろん Claude Code は素晴らしいし、私自身もそのおかげで日々の作業がだいぶ楽になっています。ただ、この構造は裏を返せば「他のツールで同じ賢さを引き出すのは意外と難しくなる」ということでもある。

これは Anthropic に限らず、OpenAI や Google のモデルでも似たようなことは起こり得るはずで、ハーネスの覇権争いはこれからさらに露骨になっていくんじゃないかと思います。自分で小さなエージェントを組む人ほど、今のうちにスキーマ検証や制約付きデコードといった地味な足場を固めておいたほうが安全だと感じました。

明日も自分の Claude Code をちゃんと動かすために、そういう地味なところを整えていこうと思います。

← ブログ一覧に戻る