GPT-5.6 Solへ移行する前に、ツール引数の癖を見ておきたい
新しいモデルが速い、安い、賢い。そう聞くと、開発者としてはかなり気になります。けれど Agent を本番で動かしているなら、最初に見るのはベンチマークより trace かもしれない。返答がよくても、既存ツールに渡す引数が少しずれたら、作業は静かに壊れることがある。
今日、自分の小さな Agent 実験で「モデルを替えるなら、どこから見るんだろう」とメモを開いていました。その流れで読んだのが、Ploy の GPT-5.6 Sol 移行記事。私はまだ GPT-5.6 Sol を本番に入れたわけではない。だから今回は「速くなったらしい」で終わらせず、Ploy が実際に踏んだ引数まわりの落とし穴を、自分の移行前チェックとして置き直してみます。
Ployの移行で起きたこと
Ploy は、Webサイトを作ったり編集したりする production AI agent を GPT-5.6 Sol に移行した、と説明しています。公式情報としては、OpenAI も GPT-5.6 シリーズを限定プレビューとして出していて、Sol はその flagship tier という位置づけ。ただし、現時点では限られた trusted partners と organizations 向けの preview なので、誰でもすぐ同じ環境で試せる話ではない。
Ploy の記事で私が止まったのは、速度やコストの数字よりも、移行の途中で出た tool call の癖でした。彼らの agent は code tool を使い、実際の workspace に対して読み書きする。そこで GPT-5.6 は、使っていない optional parameters まで毎回ほぼ全部送ってしまった、という報告がありました。
デフォルト引数が問題になった理由
ここが少しややこしい。引数が多いだけなら、ログがうるさいだけで終わるかもしれません。でも、使っていない値が null ではなく、それっぽい default value として入ってくると、ツール側には「モデルが意図して渡した値」に見える。
Ploy の例では、offset: 0 や timeout: 120000 のような値が入り、file read が空で返るケースにつながったと書かれています。しかも tool は success: true を返していたため、モデルから見ると「読めたはずなのに中身がない」状態になる。こうなると、モデルの賢さというより、境界の設計問題です。
私はここを読んで、TypeScript の optional な props を思い出しました。省略された値と、明示的に入った値は違う。人間のコードならそこを分けて扱うのに、Agent の tool schema では意外と雑に通してしまうことがある。
モデル移行前に作る評価項目
モデルを替える前に見たいのは、「正しい答えが出るか」だけではありません。Agent の場合は、答えにたどり着くまでの tool call が仕事そのものなので、途中の引数、回数、失敗の見え方まで含めて評価したいところ。
この表は、GPT-5.6 Sol だけを見るためのものではなく、モデルを替えるたびに使う小さな点検表です。特に tool call は、見た目の文章品質より早く本番の動作へ出るので、評価ログに残しておきたい。
本番投入を段階化する方法
いきなり全ユーザーの agent を新モデルに切り替えるのは、私は少し怖いです。まずは fixture workspace や sandbox repo で、同じ task を旧モデルと新モデルに流す。そこで output だけでなく、tool call の shape、空 read、再読回数、cache hit、処理時間を見るほうが落ち着く。
次に、小さい割合で canary を出します。対象は read-only に近い作業から始めたい。コードを書き換える task、外部へ publish する task、顧客データを読む task は、最後に回すくらいでいいと思う。モデルが強いほど、失敗したときの移動距離も伸びるからです。
今回の Ploy 記事でおもしろかったのは、「モデル移行」は単に model name を差し替える作業ではなかったところです。tool schema、cache、reasoning replay、eval harness。周辺の小さな前提が、全部モデルごとの癖を吸っている。新しいモデルを試す前に、自分の Agent がどこで前のモデルに最適化されているかを一度見ておきたい。続きでは、実際に coding agent の移行テストを作るなら、trace にどの項目を残すかをもう少し細かくメモします。
これから、記事の最後に「今日のしらす」という小さなおまけを置いてみようと思います。
しらすは、家にいるネコです。コードを書いていると、なぜかキーボードの近くに来ます。開発の役には立たないけれど、エラー文を追いすぎて頭が固くなったとき、横で何も気にしていない顔をしているだけで少し助かることがあります。
AI やコードの話は、どうしてもまじめになりがちです。なので最後だけ、しらすとの一コマで少し息を抜く場所にします。技術メモのあとに残る、ちいさな生活ログみたいなものです。
