GPT-6 Astraのreasoning effort設定ガイド｜low=Sol high相当・medium推奨の理由とコスト最適化【2026年9月】

GPT-6 Astra の reasoning effort（推論努力）は low / medium / high / xhigh / max の5段階で、GPT-5.6 Sol までで使えた none は指定するとHTTP 400を返します。第三者ベンチマークと複数の独立検証を突き合わせると、実務上の落としどころは「まずは medium。上げる価値があるのは low→medium までで、high 以上は費用に対する伸びが急激に落ちる」という結論になります。

想定読者は、GPT-5.6 Sol / Terra / Luna から GPT-6 Astra へ API を移行する開発者、Codex や自社エージェントの実行コストを下げたいエンジニアリングマネージャー、ChatGPT の有料プランで推論レベルを選ぶ実務ユーザーです。effort の全段階と公式が示す使いどころ、Astra と Sol を並べた実測値、configuration_update を使ったコスト最適化、移行時の失敗までを扱います。モデルそのものの概要や料金体系の全体像は、OpenAI Astraとは？料金・性能・使えるプランを整理でまとめています。

ここで扱う数値は、特記のない限り 2026年9月7日時点の OpenAI 公式ドキュメント／公式Pricing、および Artificial Analysis Intelligence Index v4.2（2026年9月時点） に基づいています。

迷ったら medium。Sol の high を使っていたなら Astra の low から試す

1. 段階は5つ。none は使えない。 GPT-6 Astra が受け付けるのは low / medium / high / xhigh / max。分類・抽出のような「考えなくてよい」タスクでも、最低 low 分の推論トークンは必ず発生します。
2. 上げる価値があるのは low→medium まで。 Artificial Analysis Intelligence Index v4.2 では、low(49)→medium(52) がスコア+3・コスト+84%なのに対し、medium(52)→high(53) は+1点でコスト+22%。以降も1段階あたり+1点ずつしか伸びません。
3. GPT-5.6 Sol の high を使っていたなら、Astra の low がほぼ同コストで同等以上。 Astra low が49／$0.63、Sol high が48／$0.61。単価が2.5倍のモデルに移っても、effort を下げれば実質的な支払いはほぼ変わらない、という構図です。

一方で注意すべき点もあります。公式ドキュメントと OpenAI 社員の推奨は方向が食い違っています。 移行ガイドは「現在の実効 effort を維持せよ」、OpenAI の Tibo Sottiaux 氏は X で「low か medium に下げよ」と述べています。安全側（品質を落とさない）と最適側（同等品質で安く）の違いなので、まず維持して移行し、評価が通ってから1段下げるのが実務的な折衷案です。

GPT-6 Astra の reasoning effort とは｜「どれだけ考えるか」の指定

出典: OpenAI 公式ドキュメント（Reasoning models）

reasoning effort は、推論モデルに対して「答える前にどれだけ考えるか」を指定する API パラメータです。Responses API では reasoning.effort、Chat Completions API では reasoning_effort で指定します。

押さえておくべき前提

• 推論トークンは出力トークンとして課金される。 モデルが内部で使う思考のトークンは、コンテキストウィンドウを消費し、料金上は出力扱いになります。GPT-6 Astra の Standard 出力単価は $50/1M なので、effort を上げたコストは全額「出力側」に乗ります。
• effort は固定量ではなく傾向の指定。 公式は「モデルは effort をまたいで適応的に推論し、簡単なタスクでは少ないトークン、複雑なタスクではより深く考える」と記載しています。同じ medium でも、タスクによって実際の推論トークン数は大きく変わります。
• max_output_tokens で総量を制御できる。 公式は「これらのモデルを試し始めるときは、推論と出力に最低25,000トークンを確保する」ことを推奨しています。

GPT-6 Astra で使える値

「effort は6段階で、max の上に ultra がある」という日本語記事が一部にありますが、これは公式ドキュメントでは確認できません。 ultra は GPT-5.6 世代の「ultra mode（サブエージェントの並列実行）」との混同と思われます。Astra の reasoning.effort は上記の5段階です。

なお、GPT-6 Astra のデフォルト effort は公式ドキュメントに明記がありません。 GPT-5.5 / GPT-5.6 については「省略時 medium」と公式に記載がありますが、Astra は同じとは限らないため、本番運用では明示指定することを推奨します。

5段階それぞれの意味と、公式が示す使いどころ

出典: OpenAI 公式ドキュメント（Models）

OpenAI の Reasoning models ガイドが挙げている用途は次のとおりです。ここは公式の記述であり、実測値そのものではありません。

注目すべきは、公式自身が max について「xhigh より優れているかを評価したうえで使う」と条件付きの書き方をしている点です。「最上位＝常に最良」ではないことを、公式ドキュメントのレベルで認めていると読めます。

medium については明確に「大半のワークロードの既定」と書かれており、公式の立場も実測データの示唆も、この点では一致しています。

effort別の実測比較｜スコア・コスト・速度（Astra × GPT-5.6 Sol）

出典: Artificial Analysis 公式サイト

第三者ベンチマークである Artificial Analysis Intelligence Index v4.2（2026年9月時点） の値を、GPT-6 Astra と GPT-5.6 Sol の5段階すべてで並べます。モデル間ではなく「同一モデル内で effort を振ったときの差」を数値で押さえておくと、設定変更の判断がぶれにくくなります。

※ Artificial Analysis Intelligence Index v4.2、2026年9月時点。同ベンチマークは版によって数値系列が変わるため、他の記事の数字と混在させないでください。

この表から読めること

1. どの段階でも Astra が Sol を上回る。 最も差が大きいのは low 同士で、49 対 41 の8ポイント差。Sol の最上位である max(51) ですら、Astra の medium(52) に届いていません。

2. 出力速度（t/s）は effort でほとんど変わらない。 Astra は 55→62 t/s の範囲に収まっています。effort を上げて体感が遅くなる原因は、1トークンあたりの生成速度ではなく、生成する推論トークンの総量が増えることです。ここは誤解が多い部分です。

3. 推論トークン量は段階的にではなく指数的に増える。 同ベンチマーク由来の Index 全体の消費出力トークンは、low 5.4M / medium 12M / high 19M / xhigh 30M / max 49M。low → max で約9倍です。コストが4.1倍にとどまるのは、入力側やキャッシュの比率があるためで、出力トークンの伸びはそれより急です。

4. 単価は effort で変わらない。 Astra の Standard 単価は入力 $10 / キャッシュ入力 $1 / 出力 $50（いずれも1Mトークンあたり）で固定です。effort を上げても「1トークンあたりの値段」は1円も上がりません。増えるのはトークンの本数だけです。この区別を押さえておくと、コスト試算のブレが減ります。

料金体系そのものの詳細（272Kトークン超の割増、Batch/Flex の50%割引、Fast モードの2倍単価など）は、OpenAI Astraとは？料金・性能・使えるプランを整理を参照してください。比較対象の Sol 側の価格改定についてはGPT-5.6 Sol APIが20%超値下げ｜入力$4・出力$20の実質インパクトでまとめています。

「Astra の low は Sol の high より良い」は本当か

2つの独立したデータが、同じ方向の結果を示しています。 ただし「常に安くなる」という話ではない点に注意が必要です。

発言の出どころ

OpenAI の Tibo Sottiaux 氏（@thsottiaux）が X で次のように述べています。

「GPT-6 Astra on low performs better than GPT-5.6 Sol on high. If you were using high reasoning efforts with Sol and were happy, I suggest you move down to low or medium for Astra.」
（Astra の low は Sol の high より良い。Sol で high を使って満足していたなら、Astra では low か medium に下げることを勧める）

検証1：ベンチマークの数値

Artificial Analysis Intelligence Index v4.2 では、Astra low = 49 に対し Sol high = 48。コストは $0.63 対 $0.61 でほぼ同額です。つまり、Sol の high を使っていたユーザーが Astra の low に移ると、支払いはほぼ据え置きでスコアが1ポイント上がるという計算になります。

Astra の単価は Sol の約2.5倍（出力 $50 対 $20）ですが、Astra は同じ品質に到達するまでに使う推論トークンが少ないため、単価の差を effort の引き下げで打ち消せる、という構図です。公式も「Astra はより少ない出力トークンでより強い結果を出す」と移行ガイドに記載しています。

検証2：240試行の再現性テスト

zenn で公開された独立検証（nnakapa 氏）は、2モデル × 4 effort × 3タスク × 10試行 = 240 run の設計で、Python/PostgreSQL の実装課題（原子的トランザクション、パラメータ化検索、楽観ロック在庫）を品質ゲートで評価しています。

Astra は low の時点で品質ゲート100%に到達し、Sol は high まで上げないと100%に届いていません。 別の角度から「low ≒ Sol high」を裏付ける結果です。推論トークン数も、Astra の low/medium は Sol の20分の1以下（11.5 対 240、24 対 492.5）。Astra は「考えていない」のではなく、少ない思考で同じ結論に到達していると読むのが妥当です。

ただし「Astra に替えれば安くなる」とは限らない

同じ検証で、1回あたりのコストは全段階で Astra のほうが高い（low で $0.555 対 $0.305）という結果も出ています。単価が2.5倍あるためです。「Sol high → Astra low で同コスト」が成立するのは、タスクの難易度と推論トークン比率が特定の範囲にある場合であり、自分のワークロードでは必ず実測してください。

もう1点、xhigh では Astra が Sol より遅く高い（260.0s / $1.008 対 203.1s / $0.427）という逆転も観測されています。上げれば上げるほど有利、という単純な関係にはなっていません。

※ この検証は3タスク・単一環境での結果です。試行回数は多いものの、タスク種別が変われば傾向は変わり得ます。

なぜ medium が基本線なのか｜コストの折り返し点はここ

出典: OpenAI 公式ドキュメント（Latency optimization）

medium が推奨される理由は「バランスが良いから」といった曖昧なものではなく、限界効用（1段階上げたときの伸び幅）が medium を境に急落するからです。

Intelligence Index v4.2 の値を段階間の差分に直すと、次のようになります。

1ポイント買うための値段が、low→medium の $0.18 から、xhigh→max では $0.72 へと4倍に膨らみます。 しかも medium 以降はどの段階も+1ポイントずつ。「上げる価値が明確にあるのは low→medium だけ」というのが、この表から導ける一番シンプルな結論です。

独立検証は結論が割れている──共通しているのは「high が中途半端」

実務者による独立検証の結論は一致していません。どれか1件を正解として採るより、3件の差から共通項を取り出すほうが判断材料になります。

medium 派：エージェント型開発タスク（dev.to / shinpr 氏）

無人開発ツールで同一リポジトリに対し4条件を比較した結果です。

Astra medium は Sol high より約19%安く、24分速い。 さらに Astra high は medium より46%高く26分遅いのに、medium が見つけた起動時の不具合を見逃したという結果でした。著者の結論は「単発リクエスト（抽出・分類・下書き）は medium を既定にし、high はリトライ・所有権・永続状態をまたぐ長いエージェントループに限定する」というものです。

low 派：コードレビュータスク（paddo.dev）

著者の結論は「low が日常のレビュー・調査用、max が監査用。medium は不要だった」。

3件を突き合わせて残る共通項は、「high はコストに見合う場面が最も少ない」という点です。 品質を確実に上げたいなら xhigh / max まで振り切り、日常運用なら low / medium に留める。high は「上げた気になるだけで伸びない」ゾーンになりやすい、というのが実務的な読み方です。

※ 上記の検証はいずれも試行環境が限定的（1リポジトリ1回、単一レビュー対象）です。傾向の参考として扱い、自分のタスクで A/B を取るのが前提になります。

タスク別の選び方｜このタスクにはこの effort

用途別の推奨をまとめます。数字の裏付けがある部分と、判断が分かれる部分を分けて示します。

判断の手順

1. まず medium で動かし、品質が要件を満たすか確認する。
2. 満たすなら low に下げて再評価する。落ちなければ low で運用（コストは約45%減）。
3. 満たさないなら high を飛ばして xhigh を試す。high は+1ポイントに+22%を払う区間で、改善が体感しにくい。
4. xhigh でも足りない場合のみ max。ただし「別途レビューパスを1回走らせる」ほうが安く効くケースが多い（medium 2回 = $2.32 に対し max 1回 = $2.57）。
5. どの段階でも temperature による調整はできないため、出力のブレはプロンプト側で抑える。

コストを下げる設定｜configuration_update が本命

effort を「一律で下げる」以外に、会話の中で effort を配分する方法があります。GPT-6 Astra で追加された configuration_update が該当し、現時点でのコスト最適化の本命です。

configuration_update で何ができるか

会話の途中で reasoning effort を上げ下げできます。 難しいターンだけ high にし、定型的なフォローアップは low に戻す、といった運用が可能です。

重要なのはプロンプトキャッシュとの関係です。リクエストレベルの reasoning.effort を書き換えると、プロンプトのプレフィックスが変わりキャッシュが無効化されます。会話履歴全体を再処理することになり、レイテンシもコストも悪化します。configuration_update はプレフィックスを保ったまま effort だけを変えられるため、キャッシュ入力（$1/1M、通常入力 $10/1M の10分の1）を維持したままコストを配分できます。

使い方は、リクエストレベルの reasoning.effort をベースラインとして固定したうえで、effort を変えたいユーザーメッセージの直前に configuration_update アイテムを差し込む形です。Responses API では input 配列にオブジェクトとして追加、Chat Completions API では空コンテンツの system メッセージに configuration_update フィールドを付けます。効いているかは、レスポンスの usage 内 cached_tokens でプレフィックスが再利用されているかを確認します。

制約（公式に明記されているもの）

• GPT-6 Astra の標準・単一エージェントモードのみ対応
• pro モード（reasoning.mode: "pro" / gpt-6-astra-pro）および tournament モデルでは非対応
• configuration_update を隣接して2つ並べてはいけない（API が拒否）
• リクエストの末尾を configuration_update で終えてはいけない
• 自動 compaction / truncation: "auto" との併用不可。/responses/compact エンドポイントも同アイテムを含む履歴を拒否
• Batch API では非対応
• 会話を再送する際は、元の位置のまま保持する

effort 以外に効くコスト設定

• プロンプトキャッシュを効かせる。 キャッシュ入力は $1/1M。キャッシュ保持は prompt_cache_retention から prompt_cache_options.ttl（"30m" など）に変更されているため、旧コードは要修正です。
• 272Kトークンを超えさせない。 入力プロンプトが272Kを超えるとリクエスト全体が割増（入力・キャッシュ2倍／出力1.5倍）になります。effort を上げると推論トークンが増え、長い会話ではこの閾値を越えやすくなるため、effort とコンテキスト長は連動して効きます。
• 急がない処理は Batch / Flex に回す。 50%割引（入力$5・出力$25）。ただし Batch では configuration_update が使えません。
• Fast モードは単価が2倍。 入力$20・出力$100。しかもAstra の Fast モードにはレイテンシSLAが付かないと公式に明記されています。EU データレジデンシー環境では service_tier: "fast" / "priority" 自体が使えません。速度を買う前に、まず effort を下げるほうが確実です（速度と effort の関係はGPT-5.6 Sol Ultrafastモードの速度と使いどころの考え方も参考になります）。

ChatGPT・Codex で effort を変える方法と注意点

出典: OpenAI Codex 公式ドキュメント

API と ChatGPT アプリでは、effort の指定体系が別物です。

ChatGPT（アプリ側）

ChatGPT の UI には、API と同じ low/medium/high/xhigh/max の指定欄はありません。 モデルピッカー側に Terra Light / Sol Light / Sol Medium / Astra Light / Astra Medium / Astra Extra High といった名称の選択肢が、対象プラン（Pro・Business・Enterprise 等）に展開されていると報じられています。

ただし、この UI ラベルと API の effort 値の対応関係は公式ドキュメントで確認できていません。 「Astra Medium = reasoning.effort: "medium"」と断定するのは避けるべきです。OpenAI の案内自体は「既定の設定から始め、タスクがより多くのプランニングや分析を必要とするときだけ推論を上げる」という、API 側と同じ方針になっています。プラン別の提供範囲はChatGPT料金プランの違いを整理を参照してください。

Codex

Codex では設定ファイルまたは CLI フラグで指定します。

# ~/.codex/config.toml
model = "gpt-6-astra"
model_provider = "openai"
model_reasoning_effort = "high"

codex -m gpt-6-astra --reasoning-effort xhigh "..."

※ 参照した技術ブログの間でキー名が model_reasoning_effort と reasoning_effort に分かれています。設定前に Codex 公式ドキュメントまたは codex config で実際のキー名を確認してください。

Codex 利用者が今知っておくべき不具合

現時点の Codex では、セッション途中で effort を切り替えないほうが無難です。

GitHub の openai/codex issue #42996（2026年9月5日起票・オープン）によれば、Codex はセッション途中で effort を変える際に configuration_update ではなくリクエストレベルの reasoning.effort を書き換えています。結果としてプロンプトキャッシュが無効化され、会話履歴全体を再処理することになり、レイテンシとコストが悪化します。基盤となるコード（PR #42328）は入っているものの未接続とされています。

当面の回避策は単純で、セッション開始時に effort を決め、途中で変えないこと。変えたい場合は新しいセッションを開始するほうが安く済みます。

サブスクの利用枠にも effort は効く

API 課金だけでなく、ChatGPT / Codex の利用上限も effort の影響を受けます。effort が高いほど推論トークンが増え、枠の消費が速くなるためです。

Codex のクレジット換算では「Astra は入力100万トークンあたり250クレジット、出力1,250クレジット（Sol は 100 / 500）」と報じられていますが、OpenAI 公式ページでは確認できていません。また、2026年9月6〜7日に「ヘビーユーザーの上限が最大4分の1に削減された」との報道もありますが、OpenAI の公式声明はありません。いずれも報道ベースとして扱い、実際の消費は自分の利用状況ページで確認してください。上限の仕組みそのものはCodex・ChatGPT Workの5時間制限とトークン消費で整理しています。

移行時にやりがちな失敗と、よくある誤解

公式と OpenAI 社員の推奨が食い違っている問題

実務手順としては、①まず effort を維持したまま Astra に移行して品質を確認 → ②評価パスが通ったら1段階下げて再評価、の順が安全です。 移行と effort 変更を同時にやると、品質が落ちたときに原因の切り分けができません。

移行時に必ず直すべき API パラメータ

• temperature / top_p / top_logprobs は非対応。既存スクリプトから削除しないと、エラーになるか無視されます。「出力のブレを temperature で抑える」旧来の手法は使えず、effort とプロンプトで制御することになります。
• ツール呼び出しは Responses API への移行が推奨されています。
• プロンプトキャッシュの指定は prompt_cache_retention → prompt_cache_options.ttl（"30m" など）へ。

併せて調整すべきプロンプト側の指示（公式ガイダンス）

• 自律性：確認のために止まるのではなく「行動に寄せ、ユーザーが意図したタスクを完遂する」よう指示する
• 指示の優先順位：「ユーザーの指示は skill 内のガイドラインより優先される」と明示する
• 文体：箇条書き偏重を避けたいなら「明確で簡潔な段落で」と指示する
• テスト量：「可逆な変更には広範なテストは不要」と較正する

よくある5つの誤解

1. 「effort を上げると単価が上がる」→ 誤り。 単価は固定（出力 $50/1M）。増えるのは推論トークンの本数だけです。
2. 「effort を上げると1トークンあたりの生成が遅くなる」→ 誤り。 出力速度は 55〜62 t/s とほぼ一定。総時間が延びるのは、生成するトークンが増えるからです。
3. 「none にすればコストゼロに近づく」→ Astra では不可能。 HTTP 400 が返ります。最低でも low の推論トークンが発生します。
4. 「effort は6段階で max の上に ultra がある」→ 公式ドキュメントでは確認できません。 5段階です。
5. 「公式ベンチマークの数字が手元でも出る」→ 出ません。 公開されている評価は effort を明示しないもの、high、xhigh、max を使ったものが混在しています。手元の medium で同じスコアは再現しません。

長時間エージェントを回すときの安全側の注意

GPT-6 Astra は OpenAI の Preparedness Framework でサイバーセキュリティ能力が「Critical」と判定された初のモデルです。攻撃寄りのタスクは拒否されますが、公式は「サイバーと直接関係ない作業や長時間動作するエージェントタスクも誤ってフラグされ、減速・一時停止・停止されうる」と明記しています。

effort を上げて長時間エージェントを回すほど、このセーフガードに接触する確率は上がります。 高 effort で夜間バッチを組む場合は、途中停止時のリトライ設計を前提にしてください。詳細はGPT-6 AstraのCriticalサイバー能力と一時停止措置で扱っています。

また、システムカードでは「高い effort でアラインメント上の懸念挙動がより多く観測されるケースがある一方、安全性スコアが改善する評価もある」とされています。「effort を上げれば安全になる」とは断定できません。

なお store: false（ステートレス）運用では、推論アイテムに encrypted_content が付き、暗号化された推論トークンを次の呼び出しへ引き継げます。推論トレースの取り扱いに関するリスクはAIの推論トレースが盗まれる脆弱性も併せて確認してください。

こんな人におすすめ / おすすめしない人

effort のチューニングに時間をかける価値がある人

• 月あたりの API 支払いが数万円を超えている — low→medium の差だけで約1.8倍、low→max で4.1倍。規模が大きいほど設定1つの金額差が効きます
• 同種のタスクを大量に回している（分類・抽出・レビュー・要約など） — 1回あたりの最適 effort が決まれば、そのまま全件に効きます
• GPT-5.6 Sol の high / xhigh から移行しようとしている — そのまま移すと単価2.5倍を素で払うことになります。まず low / medium での評価を挟む価値が最も大きい層です
• エージェントを長時間ループさせている — リクエスト数・所要時間の差が最も大きく出る領域です
• 品質ゲート（テスト・評価スクリプト）を持っている — effort を下げても要件を満たすか、機械的に判定できます

今は深追いしなくてよい人

• 利用量が少ない（月に数百リクエスト程度） — medium 固定にして、チューニング工数を別に回すほうが合理的です
• 品質評価の仕組みがない — 効果を測れないまま effort を下げると、品質劣化に気づけません。まず評価パスの整備が先です
• ChatGPT の UI だけで使っている — API と同じ粒度の指定はできません。既定から始め、必要なときだけ上位を選ぶ運用で十分です
• Batch API 中心の処理をしている — configuration_update が使えないため、会話途中の effort 配分という最大の最適化手段が使えません
• pro モードや tournament モデルを使っている — 同じく configuration_update が非対応です
• そもそもモデル選定が固まっていない — effort より先に、どのモデルを使うかの判断が優先です。GPT-6 Astra・Claude Fable 5.1・Gemini 3.8の比較やGPT-5.6とはが判断材料になります

よくある質問

Q. GPT-6 Astra のデフォルトの effort は何ですか？

A. 公式ドキュメントに明記がありません。 GPT-5.5 / GPT-5.6 については「省略時 medium」と公式に記載がありますが、Astra が同じという記述は現時点で確認できていません。本番運用では明示的に指定してください。

Q. minimal は使えますか？

A. 公式のレベル一覧には minimal が存在しますが、GPT-6 Astra のモデルページには記載がありません。現時点では未確認です。確実に使えるのは low 以上の5段階なので、low を実質の最低段階として設計するのが安全です。

Q. max は Chat Completions API でも使えますか？

A. 「max は Responses API のみで、Chat Completions は xhigh まで」という記述が複数の技術ブログにありますが、OpenAI 公式のモデルページおよび Reasoning ガイドでは確認できませんでした。実装前に自分の環境で疎通確認することをおすすめします。

Q. トークン効率は他社モデルと比べてどうですか？

A. Artificial Analysis の計測では、Astra は Coding Agent 系タスクで GPT-5.6 Sol（max）の約3分の1、Claude Opus 5（xhigh）の約5分の1のトークンで済むとされています。Intelligence Index 全体では、max effort 時に Sol 比で出力トークン約10%減。比較対象の詳細はClaude Opus 5とはを参照してください。

Q. 応答が遅いとき、effort を下げれば速くなりますか？

A. 多くの場合は速くなりますが、理由の理解が重要です。1トークンあたりの生成速度はほぼ変わらないため、短縮されるのは「生成する推論トークンが減る」分です。したがって、入力が巨大で first token までが遅い場合は、effort を下げても改善しません。その場合はプロンプトキャッシュや入力の削減が効きます。なお Astra の low は、Artificial Analysis の計測で全モデル中最短の初回応答時間（2.53秒）を記録しています。

Q. Sol と Astra、どちらを使い続けるべきですか？

A. 品質要件が満たせているなら Sol を続ける選択も合理的です。ただし Sol の $4/$20 は「少なくとも2026年11月21日まで」の販促価格と公式に明記されています。11月下旬以降は前提が変わる可能性があるため、その時点で再計算が必要です。

Q. effort を上げれば出力の安定性は上がりますか？

A. 一概には言えません。240試行の再現性テストでは、Astra は low の時点で品質ゲート通過率100%かつ再現性も高い結果でした。一方、エージェント型のタスクでは high が medium の見つけた不具合を見逃したという報告もあります。安定性はプロンプトと評価設計に依存する部分が大きく、effort を上げれば解決するとは限りません。

まとめ

• 使えるのは low / medium / high / xhigh / max の5段階。none は HTTP 400 で使えず、ultra という段階は公式ドキュメントに存在しない
• 上げる価値が明確なのは low→medium まで。 +3ポイントに対しコスト+84%。以降は1段階ごとに+1ポイントずつで、1ポイントあたりの単価は最大4倍に膨らむ
• GPT-5.6 Sol の high を使っていたなら、Astra の low がほぼ同コストで同等以上。 ベンチマーク（49対48／$0.63対$0.61）と240試行の検証（Astra low で品質ゲート100%）の2つが同じ方向を示している
• 公式は「effort を維持せよ」、OpenAI 社員は「下げよ」。 まず維持して移行し、評価が通ってから1段下げるのが実務的
• configuration_update で会話途中に effort を配分できるが、pro モード・Batch・隣接配置は不可。Codex は既知の不具合（issue #42996）でこの恩恵を受けられていないため、当面はセッション途中で effort を変えない
• effort を上げても単価は変わらない。 増えるのは推論トークンの本数で、その分が出力トークンとして課金される

前提が変わりやすいのは料金側です。GPT-5.6 Sol の販促価格が「少なくとも2026年11月21日まで」とされているため、11月下旬には Astra と Sol のコスト比較をやり直す必要があります。モデル全体の仕様と料金はOpenAI Astraとは？料金・性能・使えるプランを整理、他社モデルとの選び分けはGPT-6 Astra・Claude Fable 5.1・Gemini 3.8の比較で確認してください。