GPT-6 Solから6.1 Solへの移行は、1行変更するだけのように見え、価格も同じです。しかし、いくつかの破壊的変更や挙動の変化があるため、モデル名だけを変更すると、エラーや予想外の請求、あるいは挙動の異なるエージェントにつながることがあります。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. Chat Completionsでのツール呼び出しが動かなくなる
表示される内容： tools を含むChat Completionsのリクエストが失敗します。
理由： GPT-6 Solでは、Chat Completionsでの関数呼び出しが許可されるのは reasoning_effort が none の場合のみでした。この組み合わせを使って低コストでツールを呼び出していたプロジェクトは少なくありません。 none がなくなったため、6.1 SolのChat Completionsはツールを含まないリクエストでしか機能しません。 ツールを使うにはResponses APIを使用する必要があります。OpenAIのResponses APIへの移行ガイドで手順を確認できます。
対処方法： /v1/responses に移行してください。AIHubMixも対応しています。パラメーターについては AIHubMix Responses 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"}, # nested, not reasoning_effort
tools=[{
"type": "function",
"name": "get_weather",
"description": "Get the current weather for a city",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
}],
input="What's the weather in Shanghai today?",
)
print(resp.output)
見落としやすい点：
- Responsesではパラメーター名が
reasoning.effortです。reasoning_effortを送るとUnsupported parameterが返されます。 - 複数ターンにわたるツール利用では、関数の結果だけではなく、直近のユーザーメッセージ以降の推論、function_call、function_call_outputの項目をすべて 返送してください。
store: falseまたはZDRを使用する場合、推論項目にはデフォルトでencrypted_contentが含まれます。履歴全体を再送すれば、そのまま動作します。
3. サンプリングパラメーターは削除が必要
表示される内容： temperature または top_p を含むリクエストが失敗します。
理由： これらのパラメーターを使用できるのは、effortが none の場合のみです。6.1 Solには none がないため、このモデルでは決して使用できません。
削除する項目：
temperature,top_p,top_logprobs- Chat Completionsの
logprobs - Responsesの
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つ置かれます。そのため、複数のリクエストで共有される短いプレフィックスは、自動的には再利用されません。 多くのリクエストで、システムプロンプトの後に異なるユーザー入力が続く場合は、システムプロンプトの直後に明示的なブレークポイントを追加してください。
既存のメッセージに追記するとキャッシュが無効になります。 キャッシュの終端が長くなったメッセージの途中に位置することになり、一致しなくなります。代わりに新しいメッセージを追加してください。
推論effortを変更するとキャッシュが無効になります。 reasoning.effort はプレフィックスの一部です。会話の途中で切り替えるには configuration_update を使ってください（第2部を参照）。なお、自動コンパクションや切り詰めとは併用できません。また、 /responses/compact は、これを含む履歴を拒否します。
トラフィックが多いとキャッシュヒット率が下がる可能性があります。 キャッシュは個々のマシン上に保存されます。同じプレフィックスに対して1分あたり約15件を超えるリクエストがあると、別のマシンに振り分けられてキャッシュがヒットしないことがあります。キャッシュされたトークンもTPMのレート制限にカウントされます。
移行の前後で、 cached_tokens、 cache_write_tokens、レイテンシ、タスクごとのコストを比較してください。
5. 入力が272Kを超えると価格が2倍になる
コンテキストウィンドウが1.05Mあるのは魅力的ですが、入力が272Kトークンを超えると、リクエスト全体に入力料金の2倍、出力料金の1.5倍が適用されます。 入力が270Kから280Kになると、1リクエストあたりの料金は$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 Sol | 6 Sol | Astra |
|---|---|---|---|
| 明示的な制限を回避しようとし続ける | 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も同じファミリーに属し、性能も近いため、以下の点を確認してください。
- 質問が増えます。 そのまま進めてほしい場面で、確認のために処理を止めることがあります。行動を優先してタスクを完了するよう指示し、「〜してもらえますか」のような表現は実行依頼であると伝えてください。
- 指示により文字どおり従うようになります。
AGENTS.mdやSKILL.mdファイルをより厳密に参照するため、古いルールが突然適用されることがあります。OpenAIは、これらのファイルを監査し、ユーザーの指示がスキルより優先されることを明記するよう強く推奨しています。 - Markdown、箇条書き、表を多用し、 定型的な表現を繰り返します。文章形式で回答してほしい場合は、明示的に指示してください。
- 小さな変更でもテストをやりすぎます。 リスクが低く、元に戻せる変更なら、テストをすべて実行する必要はないと伝えてください。
- サブエージェントへの委任が期待より少なくなります。 並行して作業させたい場合は、どのタイミングでタスクを分割するか明示してください。
9. 利用可能な環境とデプロイの制限
- 通常のChatGPTチャットではまだ利用できません。 利用できるのはChatGPT WorkとCodexのみです。EnterpriseとEduの管理者は有効にする必要があります。
- FastモードはEUデータレジデンシーに対応していません。 Ultrafastが対応するのは、米国のデータレジデンシーとグローバル処理のみです。
- 知識のカットオフは2026年4月30日です。 それ以降のライブラリ、API、ニュースには、ウェブ検索またはRAGを使用してください。
- 非対応： ファインチューニング、Predicted Outputs、音声・動画入力、Realtime API、Assistants API。
- レート制限 は6 Solと同じです。Tier 1では500 RPM / 500K TPMから、Tier 5では15,000 RPM / 40M TPMまでとなっています。AIHubMixではOpenAIまたはAzure経由でリクエストを送信でき、一方のプロバイダーで障害や遅延が発生した場合は、もう一方に自動で再試行します。
移行チェックリスト
- [ ]
noneとminimalをlowに置き換え、レイテンシを確認する - [ ] ツール呼び出しを含むリクエストをChat CompletionsからResponses APIに移行する
- [ ] ネストされたパラメーター
reasoning.effortを使用する - [ ]
temperature、top_p、logprobsを削除し、logprobsに依存していたロジックを見直す - [ ]
prompt_cache_retentionをprompt_cache_options.ttl: "30m"に置き換える - [ ] 共有プレフィックスの後に明示的なブレークポイントを追加し、それらが少なくとも1,024トークンあることを確認する
- [ ] 会話中にeffortを変更する場合は
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を実行すると、機械的な変更のほとんどを処理できます。それでもチェックリストは自分で確認してください。
よくある質問
GPT-6 Solから6.1 Solに移行するには、最低限何を変更すればよいですか？ 変更点は3つです。モデル名を変更すること、noneとminimalをlowに置き換えること、そしてtemperature、top_p、logprobs関連の設定をすべて削除することです。Chat Completions経由でツールを呼び出している場合は、Responses APIへの移行も必要です。
プレーンテキストなら、引き続きChat Completionsを使えますか？ はい。リクエストにtoolsが含まれていなければ、Chat Completionsを使えます。AIHubMixのモデルページにあるサンプルは、まさにこの種の呼び出しです。
AIHubMixはResponses 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シリーズ
- 移行する価値があるか迷っていますか？ 6.1 Solが6 Solを上回る点と、Astraにどれだけ及ばないかを解説します。GPT-6.1 Sol vs GPT-6 Sol：Astraにあと一歩まで迫る、わずか1週間のアップグレード。
noneをlowに置き換えました。他に何をすればよいですか？ ユースケース別の推奨設定と調整手順はこちら：GPT-6.1 Solの推論強度の選び方：lowからmaxまで。- 移行後に請求額を確認しましょう。 キャッシュヒット、272Kのしきい値、推論トークンについて解説します：GPT-6.1 Solの実際のコスト：$2 / $10という価格の先にあるもの。
