GPT‑6.1 Solのツール呼び出しを直す：Responsesへの移行手順

モデル名を gpt-6.1-sol に変えた途端にツールが動かなくなったら、プロンプトより先にエンドポイントを確認します。Solのツール呼び出しはResponses APIが必要で、Chat Completionsはツールなしの要求のみ対応です。また none と minimal の推論設定は使えません。名前だけの移行では旧要求が非互換のまま残ります。

この記事は読み取り専用の在庫検索を使い、要求、関数実行、結果返却まで一巡させます。配布Pythonには合成レスポンスによるオフラインテストがあります。アプリのロジックの検証であり、有料API試験や性能評価ではありません。2026年9月30日にモデル仕様、移行ガイド、関数呼び出しを確認しました。

どの段階が失敗したか分ける

クライアントが要求を作り、APIが構造化呼び出しを返し、アプリが許可された関数を実行し、結果を次の要求へ戻します。「動かない」だけではこの4段階を区別できません。

原因不明のまま再送しないでください。非対応パラメータは5回目でも非対応です。認証失敗とレート制限にも別の処理が必要です。

実際の英語ドキュメントです。API制約の証拠であり、在庫関数の実行画面ではありません。

名前だけでなく要求形式を変える

Responsesでは関数定義の各項目をツールオブジェクトの直下に置きます。Chat Completionsの function ラッパーをそのまま移さないでください。

tool = {
    "type": "function",
    "name": "lookup_stock",
    "description": "Read stock for one known product SKU.",
    "parameters": {
        "type": "object",
        "properties": {"sku": {"type": "string"}},
        "required": ["sku"],
        "additionalProperties": False,
    },
    "strict": True,
}

最小要求では client.responses.create、input、reasoning={"effort":"medium"} と適切な max_output_tokens を使います。対応値は low、medium、high、xhigh、max。製品UIのUltraをAPI列挙値にしません。

移行ガイドに従い、こうした推論要求では非対応の temperature、top_p、top_logprobs、該当する出力log probabilities指定を除きます。SDKやプロキシが既定値を加える場合もあるため、エラーで名指しされた項目を最終設定で調べます。エンドポイント、モデル、項目名、状態、要求IDを記録し、秘密情報は残さないようにします。

一連の処理を含む読み取り専用サンプルを動かす

tool_loop.pyをダウンロードできます。Schema、架空の2商品、引数検証、許可リスト、有限ループとテストを含みます。実在の業務在庫ではなく教材です。

Python 3.9以降でまず実行します。

python3 tool_loop.py --self-test

期待出力は offline checks passed。この経路は標準ライブラリだけを使い、キーを読まず、クライアントを導入せず、通信しません。正常系、壊れたJSON、不正引数、未知関数・SKU、未完了応答、回数上限、誤った成功判定を確認します。

自分の許可されたAPIプロジェクトで有料実行する場合は、別環境を用意します。

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade openai
# OPENAI_API_KEYを環境に設定し、リポジトリへ保存しない。
python tool_loop.py --live

--live はAPI用量を消費し、モデルのアクセス権が必要です。本記事では実行していません。スクリプトは公式OpenAIのURLを明示し、環境の別base URLで経路が変わらないようにしています。対象 DEMO-A の教材在庫は12です。実際の lookup_stock、一致する結果、12と整合する最終回答を確認してください。自然な文章だけでは成功ではありません。

使用SDKの版も保存します。インストール命令は現行公式パッケージを取得するもので、その版の有料接続試験をこの記事で終えたという意味ではありません。

outputと元のcall_idを保持する

ループの中心は次の処理です。

history.extend(response.output)
for call in calls:
    result = dispatch(call.name, call.arguments)
    history.append({
        "type": "function_call_output",
        "call_id": call.call_id,
        "output": json.dumps(result),
    })

必要な推論項目を含め response.output 全体を保持します。response.output_text から履歴を作り直すと、文章以外の情報を落とします。複数呼び出しにはそれぞれのIDで結果を返し、関数名や新しく作ったIDで代用しません。

この実装は累積履歴を再送し、previous_response_id を併用しません。文書化された状態参照方式も使えますが、サーバー側に残る内容を理解せず全履歴と混ぜると文脈が重複します。一方式を選び、次の入力を確認します。

呼び出しがない最終ターンでは、完了状態、空でない文章、それ以前の正しい DEMO-A=12 の照会結果を要求します。未知ツールや未知SKUでは成功になりません。ただし自然言語回答と在庫の一致は別途確認が必要です。拒否、未完了、通信エラー、空出力を成功表示へ変換しないでください。

実行権限と検証はアプリが管理する

strictなSchemaは引数を制約する助けであり、サーバー検証や実行許可の代わりではありません。サンプルはJSONを解析し、文字列 sku ひとつだけを許可し、関数名を確認します。不明商品には unknown_sku を返します。モデルのshell文字列は実行せず、ツール出力を新たな指示にもしません。

不正引数は小さなエラーオブジェクトとして次のターンに渡します。実サービスでは種別も記録し、同じ不正動作が続けば停止します。必要以上のデータベース内容や機密情報を含む例外のスタックトレースをモデルへ送らず、タスクに必要な情報だけ返します。

書き込みでは追加設計が必要です。タイムアウト時、サーバー側では既に実行済みかもしれず、再送で二重実行になります。操作ID、永続状態、決済・削除・公開などに応じた承認が必要です。本例はプロトコルを教えるため読み取り専用にしており、書き込み権限の全問題を解決したとは扱いません。

時間・回数・予算は別々に制限する

サンプルはモデル呼び出し回数を制限し、実接続ではSDKタイムアウトを設定して自動再試行を止めています。失敗を見えやすくする教材用の設定であり、万能な本番推奨値ではありません。

回数上限は金額上限ではありません。毎回の入出力量は違い、履歴が長い料金帯に入ることもあります。サービス化するなら料金計算ガイドの要求台帳と予算制限を足します。

一時的な通信・レート制限は残予算内で待機を伴う再試行を検討できます。無効項目、非対応経路、アクセス権不足は先に原因を直します。ツールがタイムアウトしても在庫を推測しません。回数を使い切ったら未完了として診断IDを残します。

旧経路を置き換える前の検証

隔離プロジェクトで、実際のResponses経路とモデル、構造化呼び出し、許可関数の実行、元項目と結果IDを含む次の要求、教材と一致する回答を確認します。オフラインの失敗例も統合試験へ持ち込みます。

モデルと経路を戻せる設定を残し、同じタスクで比較します。移行と同時にプロンプト、ツール、権限まで変えると原因を切り分けにくくなります。英語の全体移行ガイドは更新判断、Codexアクセス手順は製品クライアントが対象です。自作APIループの検証を省略する根拠にはなりません。