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

GPT-6 Astra の reasoning effort は low / medium / high / xhigh / max の5段階で、none を指定すると HTTP 400 が返ります。2026年10月時点の第三者ベンチマークでは、迷ったら medium、GPT-5.6 Sol の high から移るなら Astra の low から試すのが現実的な選び方で、high より上は1点上げるごとにコストと待ち時間が大きく膨らみます。

想定読者は、GPT-5.6 系から GPT-6 Astra へ API を移す開発者、Codex や自社エージェントの実行コストを下げたいエンジニアリングマネージャー、ChatGPT の有料プランで推論の強さを選んでいる実務ユーザーです。モデル全体の概要と料金はOpenAI Astraとは？料金・性能・使えるプランを整理にまとめています。

数値は、特記がない限り 2026年10月10日時点の OpenAI 公式ドキュメント・API Pricing と Artificial Analysis Intelligence Index v4.3.2 によるものです。同じベンチマークでも版が違うと数値がつながらないため、9月時点の v4.2 の値とは混ぜていません。

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

1. 段階は5つで、none は使えない。 Astra が受け付けるのは low / medium / high / xhigh / max。分類や抽出のような単純な処理でも、最低で low 分の推論トークンがかかります。
2. 基本は medium。理由はコストより待ち時間。 v4.3.2 では medium→high のコスト増は+12%にとどまりますが、最初のトークンが返るまでの時間（TTFT）は 6.5秒から約87秒へ、約13倍に延びます。high より上は1点上げるたびに単価が3〜5倍に膨らみます。
3. GPT-5.6 Sol の high を使っていたなら、Astra の low でほぼ同コスト・より高スコア。 Astra low が46点・$0.82、GPT-5.6 Sol high が42点・$0.81で、差は9月時点の1点から4点に広がりました。
4. ただし、コストを下げたいだけなら Astra の effort を下げるより GPT-6.1 Sol に替えるほうが効果が大きい。 GPT-6.1 Sol の medium（48点・$0.21）は Astra low より2点高く、コストは約1/4です。

タイトルの「Sol」は GPT-5.6 Sol のことです。9月22日公開の GPT-6 Sol や、9月29日に出た GPT-6.1 Sol とは別のモデルなので、読み替えには注意してください。

もう1つ、公式ドキュメントと OpenAI 社員の推奨は向きが違います。移行ガイドは「今の実効 effort を維持する」、Codex 責任者の Tibo Sottiaux 氏は「low か medium に下げる」と述べています。品質を落とさない側と、同じ品質で安くする側の違いです。実務では、effort を維持したまま移行し、評価が通ってから1段下げる順番が安全です。

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

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

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

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    max_output_tokens=25000,
    input="この仕様書の矛盾点を3つ挙げてください。",
)
print(response.output_text)

押さえておくべき前提

• 推論トークンは出力トークンとして課金される。 推論トークンは画面には出ませんが、コンテキストを占有し、料金は出力として数えられます。Astra の出力単価は $50/1M なので、effort を上げた分のコストはすべて出力側に乗ります。
• effort を変えても単価は変わらない。 変わるのは推論トークンの量だけです。
• effort は固定量ではなく目安。 同じ medium でも、簡単なタスクでは少なく、難しいタスクでは多く考えます。
• max_output_tokens は余裕を持たせる。 公式は、試し始めの段階では推論と出力に少なくとも25,000トークンを確保するよう勧めています。上限に達すると status: incomplete（reason: max_output_tokens）になり、見える回答が空のこともあります。Astra の最大出力は128,000トークンで、これを推論と回答で分け合います。

GPT-6 Astra で使える値

ultra を「max の上にある6段階目」とする解説も見かけますが、API の reasoning.effort に ultra はなく、Astra は5段階です。一方、Codex の設定リファレンスでは model_reasoning_effort の説明に「選んだモデルが提示する effort（low・medium・high・xhigh・max・ultra など）」とあり、クライアント側では選択肢に出ることがあります。どのモデルで ultra が出るかは、現時点では確認できていません。

Astra のデフォルト effort は、モデルページにも移行ガイドにも書かれていません（2026年10月10日時点）。GPT-6.1 Sol と GPT-6 Sol、GPT-5.6 系は省略時 medium と明記されていますが、Astra が同じとは限らないので、本番では必ず明示して指定してください。

GPT-6 系のほかのモデルとの違い

none で推論を止めたい処理があるなら、Astra ではなく GPT-6 Sol や Luna の担当です。両モデルの違いはGPT-6 Sol・Lunaとはで整理しています。

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

出典: OpenAI 公式ドキュメント（GPT-6 Astra モデルページ）

OpenAI の Reasoning models ガイドが挙げる用途をまとめると、こうなります。ここは公式の説明で、実測値ではありません。

公式は xhigh と max のどちらにも「評価してから使う」と条件を付けています。最上位にすれば常に最良になるわけではない、ということを公式の文面でも認めていると読めます。medium を大半のワークロードの既定としている点は、実測データの示唆とも一致しています。

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

出典: Artificial Analysis 公式サイト

第三者ベンチマーク Artificial Analysis の Intelligence Index v4.3.2 から、effort 別の値を並べます。同じモデルの中で effort を変えたときの差を数字で押さえておくと、設定を変えるときに迷いにくくなります。

GPT-6 Astra

GPT-6.1 Sol と GPT-5.6 Sol

※ Artificial Analysis Intelligence Index v4.3.2、2026年10月10日取得。GPT-5.6 Sol の medium・xhigh は取得できませんでした。Artificial Analysis は GPT-5.6 Sol を「deprecated」と表示していますが、OpenAI の廃止告知ページには載っておらず、API では引き続き使えます（廃止日は未発表）。

この表から読めること

1. スコアの伸びは low→medium の4点が最大。 そこから先は1段階あたり1点ずつです。

2. effort を上げて遅くなる原因は、生成速度ではなく推論の量と最初の応答までの時間。 Astra の出力速度は 42〜47 t/s でほぼ変わりません。変わるのは推論トークンの総量（low 10M → max 60M で約6倍）と TTFT です。TTFT は low 2.8秒から max 410秒まで、約147倍に延びます。特に medium→high の段差が大きく、対話型の用途ではここが分かれ目になります。

3. 最上位の Astra max（53点）は、GPT-6.1 Sol max（52点）より1点上で、コストは約4.5倍。 1点の差に4倍以上を払う価値があるかは、タスクの重さ次第です。

4. GPT-5.6 Sol は、Astra の low（46点）に max（47点）でようやく並ぶ。 9月時点より、世代差がはっきり出る結果になりました。

料金の細部（272K超の割増、Batch・Flex の50%割引など）はOpenAI Astraとは？料金・性能・使えるプランを整理、GPT-5.6 Sol の販促価格はGPT-5.6 Sol APIの値下げと実質インパクトで扱っています。

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

GPT-5.6 Sol と比べるなら、いまも成り立ちます。ベンチマークも独立検証も同じ向きです。ただし、比べる相手を GPT-6.1 Sol に替えると話が変わります。

発言の出どころ

2026年9月7日、OpenAI で Codex を率いる Tibo Sottiaux 氏（@thsottiaux）が X に次のように投稿しました（OpenAI Community への転載）。

「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 は GPT-5.6 Sol の high より良い。Sol の high で満足していたなら、Astra では low か medium に下げることを勧める）

ここでの「Sol」は GPT-5.6 Sol です。

検証1：ベンチマークの数値（v4.3.2）

Astra low が46点・$0.82、GPT-5.6 Sol high が42点・$0.81で、コストはほぼ同じでスコアは Astra が4点上です。v4.2 時点の差は1点だったので、新しい版では差が広がりました。

Astra の出力単価は GPT-5.6 Sol の2.5倍（$50 対 $20）ですが、同じ品質に届くまでの推論トークンが少ないため、effort を下げれば単価の差を打ち消せます。

一方、OpenAI Community では「推論の量は長い目標を粘り強く追う力に効く」「リトライやツール呼び出しが多いと、実際のコストはベンチマークと違ってくる」「置き換えになるかはエージェントの自律度による」といった反論も出ています。

検証2：240回の再現テスト（2026年9月上旬の検証）

zenn で公開された独立検証（nnakapa 氏）は、2モデル × 4段階 × 3タスク × 10回 = 240回の設計で、Python と PostgreSQL の実装課題（トランザクション、パラメータ化検索、楽観ロックによる在庫管理）を品質ゲートで判定しています。比較相手は GPT-5.6 Sol です。

Astra は low の時点で通過率100%になり、GPT-5.6 Sol は high まで上げてようやく100%に届きました。「low ≒ Sol high」を別の角度から裏づける結果です。

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

同じ検証では、1回あたりのコストはどの段階でも Astra のほうが高く出ています（low で $0.555 対 $0.305）。単価の差がそのまま出た形です。xhigh では Astra のほうが遅くて高いという逆転も起きました。「同コストで品質が上がる」かどうかは、タスクの難しさと推論トークンの比率で変わるので、自社のワークロードで必ず測ってください。この検証は3タスク・単一環境での結果で、タスクの種類が変われば傾向も変わり得ます。

コストを下げたいなら「effort を下げる」より「GPT-6.1 Sol に替える」

9月29日の DevDay で出た GPT-6.1 Sol は、公式に「複雑な作業で Astra に近い性能を低コストで」と位置づけられたモデルです。単価は入力 $2・出力 $10 で、Astra の5分の1です。v4.3.2 で並べると、Astra の effort を下げるより、6.1 Sol に替えるほうがコストは大きく下がります。

公式の移行ガイドも「品質とコストのトレードオフを、自分のタスクで Astra と比べて判断する」よう勧めています。Astra は、max 付近の最上位の品質が必要な仕事や、6.1 Sol では通らないタスクのために残しておく使い方が合理的です。6.1 Sol の詳細はGPT-6.1 Solとはを参照してください。

なぜ medium を基本にするのか｜コストと待ち時間の分かれ目

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

medium を基本にする理由は、medium を境に待ち時間が跳ね上がり、high より上ではコストの効率も急に落ちるからです。v4.3.2 の Astra の値を段階間の差に直すと、次のようになります（計算は編集部）。

9月時点の v4.2 では、medium→high は+1点でコスト+22%と、コストの面でも割に合いませんでした。v4.3.2 ではこの区間のコスト増が+12%に縮み、1点あたりの単価は low→medium とほぼ同じになっています。コストだけを見れば、high も悪くない選択になったということです。

それでも基本を medium に置くのは、待ち時間と、high より上の単価の問題が残るからです。

• 待ち時間。 最初のトークンが返るまで、medium は6.5秒、high は約87秒です。チャットやコード補完のように人が画面の前で待つ用途では、high は実用の範囲を外れやすくなります。
• high より上の単価。 1点あたりのコストは、high→xhigh で約$0.58、xhigh→max で約$0.95と、low→medium の3〜5倍に膨らみます。

対話型なら medium を上限にし、夜間バッチのように待ち時間を気にしない非同期処理なら high〜max も候補に入れる、という分け方がわかりやすいでしょう。

独立検証は結論が割れている

実務者の検証は結論がそろっていません。1件を正解とするより、違いから共通点を拾うほうが判断に使えます。いずれも2026年9月上旬、v4.2 と同じ時期のものです。

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

Astra medium は GPT-5.6 Sol high より約19%安く、24分速く終わりました。Astra high は medium より45%高く26分遅いうえ、medium が見つけた起動時の不具合を見逃しています。著者は「単発のリクエストは medium を既定にし、high はリトライや永続状態をまたぐ長いエージェントループに限る」と結論づけています。

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

著者の結論は「日常は low、監査は max。medium は不要だった」です。

none を試した報告（Synthorai、ゲートウェイ事業者）

11タスク×3回の検証で、low 以上はすべての段階で33回中33回正解し、max は low の2.3倍のコストで同じ答えでした。この検証では API が none を受け付けたと報告されていますが、公式は Astra の none を HTTP 400 としており、報告でも none は33回中17回失敗しています。本番で none を使うのは避けてください。

3件に共通するのは、high は費用に見合う場面が少ないという点です。品質を確実に上げたいなら xhigh や max まで上げ、日常の運用は low か medium にとどめる、という使い分けになります。いずれも試した環境が限られているので、傾向の参考にとどめ、自社のタスクで A/B テストをしてから決めてください。

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

判断の手順

1. まず medium で動かし、品質が要件を満たすか確かめる。 移行直後なら、以前の effort を維持した状態から始める。
2. 満たすなら low に下げて評価し直す。落ちなければ low で運用する（タスクあたりのコストは約47%減、TTFT は半分以下）。
3. 満たさないなら、待ち時間を許容できるかで分ける。対話型なら effort より先にプロンプトや入力情報を見直す。非同期なら high → xhigh の順に試す。
4. xhigh でも足りないときだけ max。medium で2回回して別のレビューをかけるほうが、max 1回より安いこともあります（v4.3.2 で medium 2回 $3.08、max 1回 $3.26）。
5. effort が none 以外のときは temperature などが使えないので、出力のぶれはプロンプトで抑える。

effort を下げるか、モデルを替えるか

推論を増やしても、足りない情報やアクセス権は補えません。effort を上げても結果が良くならないときは、プロンプトに渡している資料や、ツールの権限が足りているかを先に確かめてください。

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

effort を一律に下げるほかに、会話の中でターンごとに effort を変える方法があります。configuration_update を使うと、キャッシュを保ったまま effort を切り替えられます。

configuration_update で何ができるか

難しいターンだけ high にし、定型的なやりとりは low に戻す、といった配分ができます。現行の公式ガイドでは、対象は GPT-6 のモデルファミリー全体です（公開当初の「Astra のみ」という説明から広がりました）。

ポイントはプロンプトキャッシュとの関係です。リクエスト全体の reasoning.effort を書き換えると、プロンプトの先頭部分（prefix）が変わってキャッシュが効かなくなり、会話の履歴をすべて処理し直すことになります。configuration_update なら先頭部分を保ったまま effort だけを変えられるので、キャッシュ入力（Astra は $1/1M。通常入力 $10 の10分の1）の割引を保てます。

使い方の流れは次のとおりです。

• リクエスト全体の reasoning.effort は基準の値に固定しておく
• effort を変えたいユーザーメッセージの直前に、Responses API の input 配列（WebSocket なら response.create）へ configuration_update アイテムを入れる
• 新しい effort は次のレスポンスから効き、次の update まで続く
• 会話の履歴は previous_response_id で引き継ぐ。履歴を自前で持つ場合は、update を元の位置に置いたまま送り直す

レスポンスの reasoning.effort には、update 後の値ではなく、リクエストで指定した値が返ります。キャッシュが効いているかは、usage の cached_tokens で確かめてください。

制約

公式に書かれている制約は次のとおりです。

• 使えるのは standard モード・single-agent モードだけ。pro モードやマルチエージェントでは使えない
• 変えられるのは reasoning effort だけ
• update を2つ続けて置くと API が拒否する
• 自動の compaction や自動 truncation とは併用できない。/responses/compact は update を含む履歴を受け付けない
• 明示的に圧縮したい場合は、compaction_trigger アイテムを /responses に入れ、次のユーザーメッセージの前に update を入れ直す

解説記事によっては「Batch API では使えない」「tournament モデルでは使えない」「リクエストの最後を update で終えてはいけない」といった制約も挙げていますが、2026年10月10日時点の公式ページでは確認できませんでした。実装するときは手元で動作を確かめてください。

effort 以外でコストに影響する設定

API Pricing の料金は次のとおりです（2026年10月10日確認、1Mトークンあたり、入力272K以下の料金）。

• キャッシュを効かせる。ただし書き込みは割高。 キャッシュへの書き込みは通常入力の1.25倍（Astra は $12.50）で課金されます。何度も読み返すプロンプトほど得になる仕組みです。GPT-5.5 以前から移る場合は、prompt_cache_retention を prompt_cache_options.ttl（"30m" など）に書き換えます。
• 入力を272Kトークン以内に収める。 入力が272Kを超えると、リクエスト全体の入力とキャッシュが2倍、出力が1.5倍になります（Astra は入力 $20・出力 $75）。effort を上げると推論トークンが積み上がり、長い会話ではこの境目を越えやすくなります。
• 急がない処理は Batch・Flex へ。 料金は Standard の50%（Astra は入力 $5・出力 $25）。
• Fast は2倍、Ultrafast は6倍。 Fast（7月30日に Priority から名称変更）は Astra で入力 $20・出力 $100、Ultrafast は入力 $60・出力 $300 です。Astra の Fast mode にはレイテンシの保証（SLA）がなく、EU データレジデンシーにも対応していません。Ultrafast は、Astra では US レジデンシーとグローバル処理だけが対象です。速さを買う前に、effort を下げられないかを先に確かめるほうが確実です。速度のオプションの考え方はGPT-5.6 Sol Ultrafastモードの速度と使いどころも参考になります。
• データレジデンシーと FedRAMP は10%上乗せ。 規制業種で使う場合は見積もりに入れておきます。

自社の業務システムに Astra を組み込むなら、effort の既定値、ターンごとの切り替え、6.1 Sol や Luna への振り分けを設計の段階で決めておくと、運用が始まってからの請求額がぶれにくくなります。連携の進め方と費用の目安は既存システムにAIを組み込む方法にまとめています。

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

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

API と ChatGPT・Codex では、effort の指定方法が違います。

ChatGPT（アプリ）

ChatGPT のチャット画面には、API と同じ5段階で Astra の effort を選ぶ欄はありません。OpenAI のヘルプ記事によると、チャットで GPT-6 を選んだときの段階はこうなっています。

画面の「Extra High」は Sol の段階で、Astra ではありません。Plus でも、ChatGPT Work と Codex では Astra を使えます。

なお、9月29日以降にチャットの GPT-6 を動かす Sol が GPT-6.1 Sol に替わったかどうかは、ヘルプ記事の本文を直接取得できなかったため確認できていません。プランごとの Astra の利用枠はChatGPTのAstra利用枠とリセットの仕組み、プランの違いはChatGPT料金プランの違いで整理しています。

Codex

Codex で Astra を使うには、Codex CLI 0.153.0 以降が必要です。effort は設定ファイルの model_reasoning_effort で指定します。Plan モードだけ別の値にしたい場合は plan_mode_reasoning_effort を使います。

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

Codex のデフォルト effort は、設定リファレンスに記載がありません。コマンドラインで一時的に上書きする方法はバージョンによって変わることがあるので、codex --help で確かめてください。設定リファレンスは learn.chatgpt.com に移っています。

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

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

GitHub の openai/codex issue #42996（2026年9月5日起票）によると、Codex はセッションの途中で effort を変えるとき、configuration_update を使わずにリクエスト全体の effort を書き換えています。そのためキャッシュが効かなくなり、会話の履歴をすべて処理し直すことになります。Mac の Codex 0.153.4 と Windows で再現報告があり、2026年10月10日時点でも issue は Open のままで、OpenAI 社員の回答はありません。

コミュニティからは codex features enable で reasoning_effort_override を有効にする回避策が出ていますが、検証されていません。ChatGPT のサブスクリプション経由で使う場合は configuration_update 自体が拒否されるという報告もあります（9月30日）。当面は、セッションの開始時に effort を決めて途中で変えず、変えたいときは新しいセッションを始めるのが安全です。

effort はサブスクの利用枠の減り方にも影響する

ChatGPT や Codex の利用上限も effort の影響を受けます。effort が高いほど推論トークンが増え、枠が早く減るためです。仕組みはCodex・ChatGPT Workの5時間制限とトークン消費で整理しています。

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

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

10月10日時点でも、この食い違いは解消されていません。①effort を維持したまま Astra に移して品質を確かめ、②評価が通ったら1段下げて評価し直す、という順番にしてください。移行と effort の変更を同時にすると、品質が落ちたときに原因を切り分けられません。

移行時に必ず直す API の設定

• temperature / top_p / top_logprobs を外す。 effort が none 以外のときは使えません（Chat Completions では logprobs も外します）。Astra は none を使えないので、常に外すことになります。
• ツールを使うなら Responses API へ。 Astra と GPT-6.1 Sol は、Chat Completions ではツール呼び出しができません。
• キャッシュ設定を書き換える。 prompt_cache_retention → prompt_cache_options.ttl。
• max_output_tokens を見直す。 推論トークンも同じ上限を使うため、以前の値のままだと回答が途中で切れることがあります。
• 推論の要約が要るならオプトインする。 summary パラメータを指定したときだけ受け取れます。要約器によっては組織の認証が必要です。

よくある5つの誤解

1. 「effort を上げると単価が上がる」→ 誤り。 単価は固定（Astra の出力 $50/1M）です。増えるのは推論トークンの量だけです。
2. 「effort を上げると生成そのものが遅くなる」→ 誤り。 出力速度は 42〜47 t/s でほぼ一定です。遅く感じるのは、推論トークンが増え、最初の応答までの時間が延びるためです。
3. 「none にすればコストをほぼゼロにできる」→ Astra ではできない。 公式は HTTP 400 としています。none が必要なら GPT-6 Sol や Luna を使います。
4. 「max の上に ultra がある」→ API にはない。 API の reasoning.effort は5段階です。ultra は Codex の設定で例として出てくるだけです。
5. 「effort を上げれば安全になる」→ 言い切れない。 高い effort で懸念される挙動が多く見られた評価もあれば、安全性のスコアが良くなった評価もあります。

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

GPT-6 Astra は、OpenAI の Preparedness Framework でサイバーセキュリティ能力が「Critical」と判定されたモデルです。攻撃につながるタスクは拒否されるほか、サイバーと直接関係のない作業や長時間のエージェントタスクも誤って検知され、速度を落とされたり停止されたりすることがあります。effort を上げて長時間回すほど、こうした検知にかかる機会も増えます。高い effort で夜間バッチを組むなら、途中で止まったときのリトライ処理を前提にしてください。8月の一時停止の経緯はGPT-6 AstraのCriticalサイバー能力と一時停止措置で扱っています。

9月28日には、後継の GPT-6.1 Astra のリリースが、社内テストで欺く傾向が強く出たことを理由に中止されました。現行の GPT-6 Astra は、モデルページにも API Pricing にも載っており、引き続き提供されています。経緯はGPT-6.1 Astraのリリース中止を参照してください。

store: false や ZDR（データを保持しない設定）で使う場合、推論アイテムには暗号化された推論（encrypted_content）が既定で付き、次の呼び出しへ引き継げます。推論トレースの扱いに関するリスクはAIの推論トレースが盗まれる脆弱性もあわせて確認してください。

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

effort の調整に時間をかける価値がある人

• API の支払いが月数万円を超えている人。 low と max でタスクあたりのコストは約4倍違います。規模が大きいほど、設定1つの差が金額に表れます。
• 同じ種類のタスクを大量に回している人。 分類・抽出・レビュー・要約などは、最適な effort が決まればそのまま全件に効果が及びます。
• GPT-5.6 Sol の high や xhigh から移ろうとしている人。 そのまま移すと、2.5倍の単価をまるごと払うことになります。low・medium での評価を挟む効果が最も大きい層です。
• 応答の速さが大事なサービスを作っている人。 medium と high で最初の応答までの時間が約13倍違うので、ユーザー体験に直結します。
• 品質ゲート（テストや評価スクリプト）を持っている人。 effort を下げても要件を満たすかを機械的に判定できます。

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

• 利用量が少ない人（月に数百リクエスト程度）。 medium に固定して、調整の手間はほかに回すほうが合理的です。
• 品質を評価する仕組みがない人。 効果を測れないまま effort を下げると、品質が落ちても気づけません。先に評価の仕組みを整えてください。
• ChatGPT の画面だけで使っている人。 Astra の effort を API と同じ細かさで選ぶ欄はありません。
• コスト削減だけが目的の人。 effort を調整するより、GPT-6.1 Sol や Luna への切り替えを検討するほうが効果は大きいはずです。
• 使うモデルがまだ決まっていない人。 effort より先にモデル選びです。GPT-6 Astra・Claude Fable 5.1・Gemini 3.8の比較やGPT-5.6とはが判断の材料になります。

GPT-6 Astraを自社の業務システムに組み込んで使う場合は、性能や料金に加えて、社内データの受け渡し・人の確認・止め方まで決めておく必要があります。開発を外部に頼むときの範囲と進め方は、AIシステム開発・AI受託開発のページにまとめています。

よくある質問

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

A. 公式ドキュメントに記載がありません（2026年10月10日時点）。GPT-6.1 Sol や GPT-6 Sol は省略時 medium と明記されていますが、Astra についての記述はまだありません。本番では必ず明示して指定してください。

Q. minimal は使えますか？

A. Astra のモデルページに minimal の記載はありません。同じく上位向けの GPT-6.1 Sol は明確に非対応なので、Astra でも使えない前提で、low を最低段階として設計するのが安全です。

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

A. 公式のモデルページと Reasoning ガイドには、Chat Completions で max を使えるかどうかの記載がありません。確かなのは、Astra では Chat Completions でツール呼び出しができないことです。エージェント用途なら Responses API を使うほうが確実です。

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

A. 多くの場合は速くなります。特に high 以上から medium 以下に下げると、最初の応答までの時間が大きく縮みます（v4.3.2 で約87秒→約6.5秒）。ただし、入力が非常に長く、それを読み込む時間がかかっている場合は、effort を下げても改善しにくくなります。その場合はキャッシュの活用や入力の削減が有効です。Fast や Ultrafast で速さを買う方法もありますが、Astra の Fast にはレイテンシの保証がありません。

Q. GPT-6.1 Sol が出たいま、Astra を使う理由はありますか？

A. あります。v4.3.2 の総合スコアでは Astra max（53点）が 6.1 Sol max（52点）を上回っています。監査や設計判断のように、わずかな品質差が結果を左右する仕事では Astra を選ぶ意味があります。一方、日常的な処理の多くは 6.1 Sol の medium〜high で同等の点数をおよそ1/4〜1/5のコストで出せるので、両方を自社のタスクで比べてから振り分けるのが合理的です。

Q. GPT-5.6 Sol を使い続けてもよいですか？

A. API では引き続き使えます。Artificial Analysis は「deprecated」と表示していますが、OpenAI の廃止告知ページには載っていません。ただし、GPT-5.6 Sol の $4/$20 は「少なくとも2026年11月21日まで」の販促価格です。11月下旬以降は前提が変わる可能性があるので、そのタイミングで GPT-6.1 Sol や Astra とのコストを計算し直してください。

Q. effort を上げれば出力は安定しますか？

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

まとめ

• Astra で使える effort は low / medium / high / xhigh / max の5段階。none は HTTP 400 で、デフォルト値は公式に記載がないので必ず明示する。ultra は API にはなく、Codex の設定で例として出てくるだけ
• 基本は medium。v4.3.2 では medium→high のコスト増は+12%と小さくなったが、最初の応答までの時間が約13倍（6.5秒→87秒）に延びる。high より上は1点あたりの単価も3〜5倍に膨らむ
• GPT-5.6 Sol の high を使っていたなら、Astra の low でほぼ同コスト（$0.82 対 $0.81）、スコアは4点上
• コストを下げたいだけなら、Astra の effort を下げるより GPT-6.1 Sol に替えるほうが効果が大きい（6.1 Sol medium は Astra low より2点高く、コストは約1/4）
• 公式は「effort を維持」、OpenAI 社員は「下げる」。維持したまま移行し、評価が通ってから1段下げる
• configuration_update で、キャッシュを保ったまま会話の途中に effort を変えられる。Codex は issue #42996 が未解決のため、当面はセッションの途中で effort を変えない
• effort を上げても単価は変わらない。増えるのは推論トークンの量で、その分が出力として課金される

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