OpenAIのPython向けエージェント開発ツールが、外部ツールの説明情報を読み取り、関数の実行エラーを実行全体の共通ルールで整えられるようになった。外部ツールを接続する開発者はエラー案内を一元管理でき、人の承認を待つ作業では会話履歴を縮める処理が後回しになる。
1. ツールの説明情報は権限ではなく参考資料だ
2026年10月15日に公開された0.24.0は、MCPサーバーのツールを関数ツールに変換する際、サーバーが付けた補足説明も公開する。MCPはエージェントが外部ツールに接続する際に使うプロトコルで、今回の情報はツールを把握するための参考表示に当たる。
開発者はFunctionTool.mcp_annotationsからこの情報を読み取れる。値はコピーとして返されるため、読み取った値を変更しても元の情報には反映されない。
MCP以外のツールや補足説明のないツールはNoneを返す。サーバーが省略したヒントも省略されたままなので、デフォルト値が必要なら、開発者が使用中のMCPバージョンのデフォルト値ルールを適用する必要がある。
リリースノートは、この情報を信頼が保証されていないヒントとして扱うよう案内している。実行の承認を与えるものではなく、モデルに渡すツール定義やシリアライズされたツールの出所情報にも含まれない。説明札が入場許可証の代わりにならないのと同じだ。
2. 関数のエラーメッセージを実行全体で定める
RunConfig.tool_error_formatterは、実行全体でツールのエラーメッセージを作るコールバック、つまりエラー発生時に呼び出されるカスタム関数だ。今回は、関数をツールとして登録する印（デコレーター）を付けた関数ツールの実行例外も、この経路で処理する。
エラー分類にkind="tool_exception"が追加された。既存のハンドラーが拒否以外のエラーをツール不在としか解釈していなければ、実際には実行中に失敗した関数を、見つからなかったと誤って案内する可能性がある。
既存のコールバックは、新しい分類を直接処理するか、その分類でNoneを返してデフォルトのメッセージを使うように変更する。カスタムハンドラーがない場合のデフォルト動作は変わらない。
任意フィールドのerrorには例外情報が渡される。モデルに見せるメッセージに詳細を含めるには、開発者が意図的に内容を精査する必要がある。例外情報を受け取れることと、その情報を公開してよいかどうかは別の問題だ。
ツールごとに明示したハンドラーが、実行全体の設定より優先される。明示的に指定したNoneやデフォルトハンドラーも、この優先順位を維持する。
生成関数で作ったMCPツールと、Agent.as_toolでラップしたエージェントの失敗は、別の動作を維持する。タイムアウト、キャンセル、定められたデータ構造（スキーマ）に従うプログラム呼び出しも、新しい共通処理経路には統合されない。
3. 承認待ちの間は履歴の圧縮を保留する
自動圧縮は会話履歴を縮めて管理する処理だ。今回の修正では、保留中の承認要求がある場合、この処理を延期する。承認手続きが残っている間に履歴整理が先行しないよう、処理順序を変えたものだ。
承認を待つ間に保留した履歴も、実行の再開後まで保持するよう修正された。リリースページに含まれるレビュー報告書は、出力の安全性検査の段階まで履歴の保存を延期すると説明している。したがって、承認履歴を保持するという説明を、検査前から無条件に保存するという意味に読んではならない。
4. 導入前にエラー分類と保存済みの実行を確認する
既存のハンドラーが拒否かどうかだけでツール不在を判断していた場合、新バージョンでは実行の失敗まで「存在しないツール」と案内する可能性がある。エラー案内を一元化する利便性を得るには、まずツール不在と実行失敗を区別するよう分類を補う必要がある。
ただし、保存済みの実行を使う場合は更新時期も検討しなければならない。リリースのレビュー報告書によると、同名のエージェントを含む過去の一部の構成は、新バージョンでは読み込めない。該当する作業は、保存時のSDKと元のエージェントコードで完了させる必要がある。
リリースノートには実行可能なコード例は示されていない。
導入の判断基準は新機能の数よりも、既存のエラー分類が新しい入力を区別できるか、保存済みの作業をどのバージョンで完了させるべきかにある。