Pydantic AI 2.62.0：推論強度の調整、モデルエラーの分類

1. 会話中に推論強度を調整

推論強度は、モデルが回答を生成する際に推論へどれほど労力を費やすかを決める設定だ。今回の変更により、会話全体で同じ強度を維持する代わりに、会話の途中で調整できる。OpenAIではconfiguration_updateで変更を伝え、Anthropicはメッセージごとにoutput_configを送る。両プロバイダーのリクエスト形式は異なるが、実行中に設定を調整するという用途は同じだ。

変更された設定はModelSettingsDeltaPartとして会話履歴に保存される。そのため、会話履歴には推論強度が変わった時点と変更内容が別の項目として反映される。既存の会話履歴を扱うコードは、新しい履歴項目を考慮する必要がある。リリースノートは、この変更を互換性に関する注意事項にも含めた。

OpenAI互換プロバイダー経由でClaudeを使う経路も修正された。そのプロバイダー固有の形式ではない推論情報をユーザーメッセージに含めて送るようにし、変更対象はOpenAIChatModelとOpenAIResponsesModelだ。推論強度を設定する機能とともに、推論情報そのものを送る経路も見直した。

2. モデルリクエストのエラーを原因別に分類

リクエストの拒否にはModelRequestRejectedError、認証の失敗にはModelAuthenticationErrorというエラー分類が追加された。アプリケーションは、失敗を一つのエラーにまとめる代わりに、この分類に基づいて後続処理の流れを分けられる。

モデルが見つからない場合にはModelNotFoundErrorが追加された。例えば、認証情報を点検すべき状況とモデル名を点検すべき状況に、それぞれ異なる案内を付けるために活用できる。新しい分類の実用的な意義は、失敗の原因に合わせてアプリケーションの対応を設計する手掛かりが増えた点にある。

3. キャッシュ維持と履歴変更を併せて考慮

推論強度を変更する機能の利点は、会話ごとに同じ設定を固定する必要がないことだ。OpenRouterでは、変更をconfiguration_updateシステムメッセージで伝え、繰り返し入力を再利用する一時保存機能であるプロンプトキャッシュを維持するよう修正した。設定変更の柔軟性を高めながらキャッシュを保持することが、今回の修正の具体的な効果だ。

一方で、開発者が管理する対象も増える。会話履歴を保存したり読み込んだりするコードには設定変更の項目を反映し、リクエストを直接構成するコードにはプロバイダー別の送信方式を反映する作業が伴う。設定を柔軟に変更する利点と、履歴・リクエスト処理を調整する負担が同時に生じる。

リリースノートはキャッシュ保持の修正と新しいエラー分類を示しているが、コスト・応答時間の測定値や、プロバイダーの応答別の例外対応表までは提供していない。

4. エラー分類と再試行の流れを併せて点検

Azureでは、応答を分割して受信する途中で発生するtoo_many_requestsエラーを、代替モデル処理用のFallbackModelが分類するよう修正した。エラーが返される経路に応じて、代替モデルに引き渡す流れを扱う修正だ。Azureでこの機能を使う開発者は、新しいエラー分類だけでなく、この経路も併せて点検するとよい。

ユーザーとの会話とは別に実行されるバックグラウンドツールのステップ終了後に発生したModelRetryも、max_retriesの回数に含めるようにした。再試行の要求が発生したタイミングによって、回数の計算から漏れていた経路を見直した。

適用時には、設定変更が会話履歴に残る流れと、各エラー分類を受けて処理する流れを分けて確認すると有用だ。リリースノートが推論強度の変更と新しいエラー分類をいずれも互換性の注意事項に挙げているため、機能の追加と既存の履歴・エラー処理の点検を併せて進めるほうがよい。

2.62.0は、プロバイダー別の推論設定を会話中に変更する経路を整え、モデルの失敗を原因別に処理する基盤を追加したアップデートだ。