Opus 5.5のツール移行、入力形式の保証と実行の確認は別
Claude Opus 5.5ではツール使用を強制する従来の設定が拒否される。代替として案内されるstrict tool useの保証範囲を調べ、入力形式が正しいこと、必要な照会をしたこと、業務が成功したことを分けて検証する移行上の論点を整理した。
Claude Opus 5.5への移行では、ツールを必ず使わせる従来の指定を、そのまま引き継げない。Anthropicの移行ガイドは、tool_choiceのanyとtoolが400エラーになると明記する。代わりにautoを使い、ツールが必要になる条件を指示文で説明する方法を案内している。
同時に推奨されるstrict tool useは、ツールへ渡す値の形式を制約する機能だ。たとえば人数を整数で受け取る定義なら、文字列で人数を返すような型の不一致を防ぐ。だが、値が決めた形式に合うことと、必要な場面でツールを呼んだことは別の確認事項になる。
日本語の業務アプリで外部の在庫や予約情報を照会する場合も、この区別が重要だ。応答が読みやすい日本語になっていても、実際に照会を行ったかは文章の印象だけでは判断できない。移行後の検証では、ツール呼び出しの記録と、アプリに渡された入力内容を分けて確認する必要がある。
strictを有効にするには、ツール定義にstrict: trueを加える。ただし、対応するJSON Schemaには範囲の制限がある。移行ガイドは、各オブジェクトで追加のプロパティを認めない設定を求める。既存の定義へフラグだけを付ければ、どんな形式でも受け付けられるという説明ではない。
また、すべてのツールに同じ指定が使えるわけではない。公式のstrict tool use文書は、computer useとbrowser useのツールセット項目ではstrict: trueを受け付けず、その指定を含む要求は拒否されると説明する。独自関数と画面操作用のツールセットを一括で変更すると、この差を見落としかねない。
形式を守る仕組みは、業務上の値の正しさを自動的に保証するものとも区別したい。予約日の文字列が決めた形式に合っていても、利用者が希望した日付か、空きがあるかは別の情報だ。提供元が説明する入力の型への保証を、業務処理全体の成功という意味に広げないことが重要になる。
この変更は、エラーを避けるための設定変更にとどまらない。移行前に強制指定へ任せていた処理について、何をもって照会済み、実行済みと判断するかを見直す契機になる。本稿は公式文書の整理であり、個別の予約システムを接続して成功率を測った結果ではない。
入力形式と実行の確認は分けて記録することが必要だ。
프리즘코리아 편집국 > 水野遼
