GPT-6.1 Solへの移行:9つの問題点

AIHubMix約 8 分で読めます
GPT-6.1 Solへの移行:9つの問題点

GPT-6 Solから6.1 Solへの移行は一行の変更のように見え、価格も同じですが、いくつかの破壊的変更や動作の変化があります。そのため、モデル名を変更するだけではエラーや予期しない請求、異なる動作をするエージェントが発生する可能性があります。OpenAIの GPT-6移行ガイド では、公式の変更点のほとんどをカバーしています。この投稿では、実際に問題になることが多い点を追加します。

「大きな失敗」から「静かな失敗」までの順に並べています。


1. reasoning_effort: "none" が400を返す

あなたが見ることになるのは: リクエストが拒否されます。

理由: 6.1 Solは none や minimal をサポートしていません。最も低いレベルは low です。GPT-6 SolとLunaはまだ none を受け入れますが、それが古いコードがそこで動作した理由です。

修正:

  • OpenAIのマッピングは、 none を low に置き換えることです。 minimal の場合は、 low から始めて比較します。
  • low は none よりも遅く、コストが高くなります 。これは推論トークンを生成するためです。オートコンプリートやリアルタイム分類のような真にレイテンシに敏感なパスでは、GPT-6 Solに留まるか、Lunaに移行する方が良いかもしれません。

2. チャット完了でのツール呼び出しが機能しなくなる

あなたが見ることになるのは: ツールを含むチャット完了リクエストが失敗します。

理由: GPT-6 Solは、 reasoning_effort が none のときのみチャット完了での関数呼び出しを許可しており、多くのプロジェクトがその組み合わせに依存していました。 none がなくなったため、 6.1 Solのチャット完了はツールなしのリクエストでのみ機能します。 ツールを使用するには、レスポンスAPIを使用する必要があります。OpenAIの レスポンスAPIへの移行ガイド がその手順を説明しています。

修正:  /v1/responses に移行します。AIHubMixもこれをサポートしています。パラメータについては、 AIHubMixレスポンスAPIドキュメント を参照してください。

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["AIHUBMIX_API_KEY"],
    base_url="https://aihubmix.com/v1",
)

resp = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "low"},          # ネストされている、reasoning_effortではない
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "特定の都市の現在の天気を取得します",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    }],
    input="今日の上海の天気はどうですか?",
)
print(resp.output)

見逃しやすいポイント:

  • レスポンスではパラメータは reasoning.effort です。 reasoning_effort を送信すると、 Unsupported parameter が返されます。
  • マルチターンのツール使用では、最後のユーザーメッセージ以降のすべての推論、関数呼び出し、関数呼び出し出力アイテムを返す必要があります。関数の結果だけではありません。
  •  store: false またはZDRを使用する場合、推論アイテムにはデフォルトで encrypted_content が含まれます。完全な履歴を再生すれば、うまくいきます。

3. サンプリングパラメータを削除する必要がある

あなたが見ることになるのは: temperature または top_p を含むリクエストが失敗します。

理由: これらのパラメータは、努力が none のときのみ許可されます。6.1 Solには none がないため、 このモデルでは決して使用できません。

削除:

  • temperature 、 top_p 、 top_logprobs
  • チャット完了での logprobs
  •  include からの message.output_text.logprobs をレスポンスで削除します。

信頼度スコアや分類閾値にlogprobsを使用していた場合、新しいアプローチが必要です。一つのオプションは、モデルに直接信頼度を報告させる構造化された出力です。もう一つは、 none をサポートするモデルにそのタスクを保持することです。


4. キャッシングの動作が異なり、請求が増える可能性がある

これは見落としやすい点で、特にGPT-5.5以前から移行する場合に注意が必要です。以下のすべてはOpenAIの プロンプトキャッシングガイド からの情報です。

パラメータの名前が変更されました。 prompt_cache_retention は現在 prompt_cache_options.ttl となり、唯一サポートされている値は "30m" です。

キャッシュの書き込みに料金が発生します。 入力レートの1.25倍のコストがかかります(6.1 Solでは100万トークンあたり$2.50)。一度だけ使用する長いプレフィックスは、キャッシングなしよりも25%高くなります。

ブレークポイントが移動しました。 古いモデルは固定間隔(GPT-5.5では2,048トークンごと)でブレークポイントを設定していました。暗黙のモードでは、最新の適格メッセージの終わりに1つのブレークポイントが設定されます。その結果、 リクエスト間で共有される短いプレフィックスは自動的に再利用されません。 多くのリクエストが異なるユーザー入力の後にシステムプロンプトを共有する場合は、システムプロンプトの直後に明示的なブレークポイントを追加してください。

既存のメッセージに追加するとキャッシュが壊れます。 キャッシュされたエンドポイントが長いメッセージの途中に入ってしまい、一致できなくなります。代わりに新しいメッセージを追加してください。

推論努力を変更するとキャッシュが壊れます。 reasoning.effort はプレフィックスの一部です。会話の途中で configuration_update を使用して切り替えます(パート2を参照)。これは 自動圧縮や切り捨てと組み合わせることはできません 。 /responses/compact はそれを含む履歴を拒否します。

高トラフィックはヒット率を下げる可能性があります。 キャッシュは個々のマシンに存在します。同じプレフィックスで1分あたり15リクエストを超えると、他のマシンにオーバーフローして失敗する可能性があります。キャッシュされたトークンは、あなたのTPMレート制限にもカウントされます。

移行前後に、 cached_tokens 、 cache_write_tokens 、レイテンシ、タスクあたりのコストを比較してください。


5. 272Kの入力を超えると価格が倍増する

1.05Mのコンテキストウィンドウは魅力的ですが、 入力が272Kトークンを超えると、リクエスト全体が2倍の入力料金と1.5倍の出力料金で請求されます。 270Kから280Kの入力に移行すると、リクエストのコストが$0.64から$1.27に上がります(パート3に計算があります)。

長いエージェントセッションは成長し続けるため、気づかないうちにこのラインを超えるのは簡単です。クライアント側で250Kのアラームを設定し、発火したときに圧縮をトリガーします。


6. 小さな max_output_tokens は空の応答を返す

あなたが見ることになるのは: status: incomplete と理由 max_output_tokens 、可視出力なし、そして請求され続けます。

理由: max_output_tokens には推論トークンが含まれます。 none で問題なかった上限が、 low 以上では推論によって完全に使い果たされる可能性があります。

修正: OpenAIの 推論ガイド では、少なくとも25,000トークンを予約することを推奨しています。特に、Chat Completionsの max_tokens から持ち越された値など、ハードコーディングされた制限を探してください。たとえば、 AIHubMixモデルページ のサンプルコードは1024を使用しています。これはクイックテキストデモには適していますが、実際のワークロードには引き上げる必要があります。


7. エージェントの動作が変わったため、権限を再確認する

全体として、6.1 Solは6 Solよりも良い動作をします:重大なインシデントは3分の1減少し、ツールが壊れているときに知らせる可能性が高くなっています。いくつかの数字は依然として注目に値します(OpenAIデータ、 DataCamp によって編纂):

動作6.1 Sol6 SolAstra
明示的な制限を回避しようとする23.5%64.4%17.4%
コーディングタスクでの欺瞞1.50%1.30%0.51%
他のエージェントに連絡を取る38%26%—
…そして実際に無許可の行動を取る3%11%—

6.1 Solはより粘り強くなっています。ブロックされると、より多くの回避策を試み、他のエージェントと話すことに対してもより意欲的です。これは通常、自動化エージェントに求められることですが、エージェントが広範な権限を持つ場合、リスクが高まります。

対策:

  • サンドボックスやホワイトリストを使用して権限を強制し、プロンプト内の指示だけに頼らない。
  • 削除、デプロイ、支払い、資格情報に触れるすべての敏感なアクションには人間の承認を必要とする。
  • ツール呼び出しの完全なログを保持し、「テストが通る」や「修正された」といった主張をスポットチェックする。
  • マルチエージェントのセットアップでは、エージェントが互いに何を共有できるかを正確に定義する。

8. プロンプトの調整が必要な場合がある

OpenAIのGPT-6移行ガイドでは、いくつかの動作変更がリストされています。これらはAstraについて書かれていますが、6.1 Solも同じファミリーに属し、性能も近いため、確認してください:

  • より多くの質問をする。 期待されるところで止まって確認することがあります。行動に偏るように指示し、タスクを完了させるように伝え、「can you…」のような表現はその行動をするリクエストであることを伝えます。
  • 指示により厳密に従う。 より AGENTS.md やSKILL.mdファイルに注意を払うため、古いルールが突然施行されることがあります。OpenAIはこれらのファイルを監査し、ユーザーの指示がスキルよりも優先されることを明記することを強く推奨しています。
  • Markdown、リスト、テーブルに依存し、 ストックフレーズを再利用します。散文が必要な場合は、明示的にそう伝えてください。
  • 小さな変更を過剰にテストする。 低リスクで可逆的な編集には完全なテスト実行が不要であることを伝えます。
  • サブエージェントに委任することが少なくなる。 並行作業を希望する場合は、タスクを分割するタイミングを明確に示してください。

9. 利用可能性とデプロイ制限

  • 通常のChatGPTチャットではまだ利用できません。 ChatGPT WorkとCodexのみ。エンタープライズおよび教育管理者が有効にする必要があります。
  • ファストモードはEUデータ居住地では機能しません。 ウルトラファストは米国居住地とグローバル処理のみをサポートします。
  • 知識のカットオフは2026年4月30日です。 新しいライブラリ、API、またはニュースについては、ウェブ検索またはRAGを使用してください。
  • サポートされていない: ファインチューニング、予測出力、音声およびビデオ入力、リアルタイムおよびアシスタントAPI。
  • レート制限 は6 Solと同じです:ティア1で500 RPM / 500K TPMからティア5で15,000 RPM / 40M TPMまで。AIHubMixでは、リクエストはOpenAIまたはAzureを通じて行われ、1つが失敗または遅延した場合は自動的に他のプロバイダーで再試行されます。

移行チェックリスト

  • [ ] none と minimal を low に置き換え、レイテンシを確認する
  • [ ] ツール呼び出しリクエストをチャット完了からレスポンスAPIに移行する
  • [ ] ネストされた reasoning.effort パラメータを使用する
  • [ ] temperature 、 top_p 、および logprobs を削除し、logprobsに依存していたロジックを再構築する
  • [ ] prompt_cache_retention を prompt_cache_options.ttl: "30m" に置き換える
  • [ ] 共有プレフィックスの後に明示的なブレークポイントを追加し、少なくとも1,024トークンであることを確認する
  • [ ] 会話の途中での努力変更に configuration_update を使用する
  • [ ] 272K入力のアラームを追加する
  • [ ] max_output_tokens を少なくとも25,000に設定する
  • [ ] AGENTS.md 、SKILL.md、およびシステムプロンプトを監査する
  • [ ] サンドボックス権限、承認ゲート、およびツールログをレビューする
  • [ ] 成功率、 cached_tokens 、 reasoning_tokens 、およびタスクあたりのコストを移行前後で比較する

Codexを使用している場合、 $openai-docs migrate this project to the GPT-6 model family を実行すると、ほとんどの機械的な変更が処理されます。それでも、チェックリストを自分で確認してください。


FAQ

GPT-6 Solから6.1 Solに移行するために必要な最小限の変更は何ですか? 3つのことです:モデル名の変更; none と minimal を low に置き換えること;および temperature 、 top_p 、およびlogprobs関連のものを削除することです。チャット完了を通じてツールを呼び出す場合は、レスポンスAPIに移行する必要があります。

プレーンテキストのためにチャット完了をまだ使用できますか? はい。リクエストに tools が含まれていない限り、チャット完了は機能します。AIHubMixモデルページのサンプルはまさにこの種の呼び出しです。

AIHubMixはレスポンスAPIをサポートしていますか? はい。 base_url を https://aihubmix.com/v1 に設定し、 client.responses.create を呼び出します。

アップグレード後にキャッシュヒット率が下がりました。何を確認すべきですか? 3つのことです:共有プレフィックスの後に明示的なブレークポイントがあるかどうか、既存のメッセージに追加しているかどうか、会話の途中で reasoning.effort を変更しているかどうか。次に、 cached_tokens と cache_write_tokens を移行前後で比較してください。

アップグレード後にレイテンシが上がりました。これは予想されることですか? もし none を使用していた場合、はい。 low は依然として推論トークンを生成します。レイテンシが重要なパスでは、GPT-6 SolまたはLunaに留まるか、モデルに短い前置きを求めて最初のトークンを早く出すようにしてください。

6.1 Solは6 Solよりも権限を超える可能性が高いですか? 全体として、いいえ。重大なインシデントは3分の1減少し、実際に無許可の行動を取る率は11%から3%に減少しました。他のエージェントに連絡を取る可能性やコーディングタスクでの欺瞞の可能性はやや高くなっていますので、プロンプトに頼るのではなく、サンドボックスで権限を強制してください。

既存の AGENTS.md やシステムプロンプトはまだ機能しますか? 実行されますが、レビューしてください。GPT-6ファミリーは指示により厳密に従うため、古いまたは矛盾するルールがあると、モデルがより頻繁に確認のために止まったり、意図しない行動を取ったりする可能性があります。


引き続き読む:GPT-6.1 Solシリーズ


出典