GPT-6 Astra を API から使い始めるときに、いちばん時間を取られるのは「動かない理由が分からない」状態です。旧モデル用のリクエストをそのまま model 名だけ差し替えると、エラーで弾かれるか、意図しない挙動になります。この記事では、OpenAI の公式ドキュメント（Model guidance / Models / Pricing）に書かれている変更点だけを拾い、実際に手を動かす順番に並べ直します。2026年9月10日時点の記載にもとづきます。
結論｜書き換えるのは5か所だけ
公式の移行ガイドに列挙されている作業は、実務では次の5つに畳めます。
- model を
gpt-6-astraにする temperature/top_p/top_logprobsを消す（Chat Completions ではlogprobsも）- ツール（関数）呼び出しを Responses API に寄せる
- 推論強度（reasoning effort）を置き換える（
none/minimalを使っていたならlowから） - プロンプトキャッシュの設定名を差し替える（
prompt_cache_retention→prompt_cache_options.ttl）
逆に言うと、この5つを潰さないまま「モデル名だけ変えて様子を見る」のは、失敗する確率がとても高いやり方です。以下、順に見ていきます。
手順1｜model を gpt-6-astra にして、スペックの前提を更新する
公式ドキュメントでは、Astra を使うときは Responses API のリクエストで model を gpt-6-astra に設定する、と明記されています。エイリアスではなく、このモデル ID をそのまま指定します。
項目 | GPT-6 Astra | GPT-5.6 Sol（前世代の旗艦） |
|---|---|---|
モデル ID | gpt-6-astra | gpt-5.6-sol（エイリアス gpt-5.6） |
コンテキスト | 1.05M トークン | 1.05M トークン |
最大出力 | 128K トークン | 128K トークン |
知識のカットオフ | 2026年4月30日 | 2026年2月16日 |
推論強度 | low / medium / high / xhigh / max | none / low / medium / high / xhigh / max |
ツール | Functions・Web search・File search・Computer use | Functions・Web search・File search・Computer use |
表で見落としやすいのが推論強度の一覧に none が無いことです。GPT-5.6 系で none を使って「考えさせずに速く返す」運用をしていた場合、Astra ではその選択肢がありません。ここが後述の手順4につながります。
手順2｜使えなくなるパラメータを消す
公式ガイドは、移行時に削除するパラメータを名指ししています。残したままだとリクエストが通りません。
- 共通で削除:
temperature、top_p、top_logprobs - Chat Completions を使う場合はさらに:
logprobs - Responses API を使う場合はさらに:
includeからmessage.output_text.logprobs
実務でいちばん影響が出るのは temperature です。「出力のばらつきを 0.2 に固定して安定させる」といった作り込みをしているコードは、その前提ごと組み直す必要があります。ばらつきの制御は温度ではなく、プロンプトで出力形式を固定する側に移すのが Astra 以降のやり方になります。構造化出力（JSON スキーマ）を使っている箇所は、そのまま活かせます。
手順3｜ツール呼び出しは Responses API へ移す
ここが移行で最も工数の読み違いが起きるところです。公式ガイドには、GPT-6 Astra は Chat Completions もサポートするがツール呼び出しには Responses API が必要と書かれています。
つまり、Chat Completions の tools / tool_calls で関数呼び出しを組んでいるアプリケーションは、モデル差し替えだけでは済まず、API そのものの移行が同時に発生します。逆に、ツールを使わない生成・要約・分類だけの処理なら、Chat Completions のまま model 名の差し替えで動きます。
移行の見積もりを立てるときは、まず自社のリクエストを「ツールを使う／使わない」で仕分けてください。この仕分けだけで、必要な工数が数倍変わります。
手順4｜推論強度（reasoning effort）を置き換える
公式ガイドの指示はシンプルです。いま none または minimal を使っているなら、まず low に置いて結果を比べる。それ以外は、現在の実効的な推論強度をそのまま保つ、とされています。指定先は Responses API なら reasoning.effort、Chat Completions なら reasoning_effort です。
もう一つ、Astra で追加された仕組みがあります。会話の途中で推論強度を変えたい場合、configuration_update という入力アイテムを送ると、リクエスト単位の reasoning.effort を書き換えずに強度だけを切り替えられます。プロンプトの先頭部分（prefix）が変わらないため、プロンプトキャッシュを壊さずに済むのが利点です。難しい工程だけ強度を上げ、定型の追い返答では下げる、といった運用ができます。
手順5｜プロンプトキャッシュの設定名を差し替える
GPT-5.5 以前から移行する場合、prompt_cache_retention を prompt_cache_options.ttl に置き換え、値を "30m" に設定するよう案内されています。あわせて、キャッシュの境界とキャッシュ書き込みの課金についても変更点があるため、料金試算をしている場合は前提を引き直す必要があります。
キャッシュは費用に直結します。Astra の標準料金は、入力 $10 / 100万トークン に対しキャッシュ読み取りが $1.00、キャッシュ書き込みが $12.50（いずれも短コンテキスト）です。「毎回同じ長い前提を読ませる」設計の社内 AI では、ここが月額を最も動かします。
Fast mode と EU データレジデンシーの制約
速度を優先する Fast mode（旧 Priority processing）には、Astra 固有の注意があります。公式の料金ページと移行ガイドに、次のとおり明記されています。
- EU データレジデンシーでは Astra の Fast mode を使えない。
service_tier: "fast"もservice_tier: "priority"も指定できず、Standard 処理を使う - Astra の Fast mode にはレイテンシ SLA が付かない
- リージョン処理（データレジデンシー）のエンドポイントは、2026年3月5日以降にリリースされたモデルについて10%の上乗せで課金される
国内企業でも、EU 拠点や EU 顧客のデータを扱う場合はこの制約に当たります。「速さ」を売りにした機能を EU 向けに設計しないことを、要件定義の段階で確認しておいてください。
移行前に押さえる単価の差
料金は処理方式で4段階に分かれます。100万トークンあたり・短コンテキストの標準料金は次のとおりです。
処理方式 | 入力 | キャッシュ読取 | キャッシュ書込 | 出力 |
|---|---|---|---|---|
Standard | $10.00 | $1.00 | $12.50 | $50.00 |
Batch | $5.00 | $0.50 | $6.25 | $25.00 |
Flex | $5.00 | $0.50 | $6.25 | $25.00 |
Fast mode | $20.00 | $2.00 | $25.00 | $100.00 |
長コンテキスト側はこの2倍（Standard で入力 $20 / 出力 $75）です。急がない処理を Batch か Flex に寄せるだけで単価は半額になるので、移行と同時に「即時性が要るリクエスト」と「夜間にまとめて回せるリクエスト」を仕分けておくと、費用の増分をかなり吸収できます。実際に月額がいくらになるかは、GPT-6 Astra の料金と移行の費用試算で件数を置いて計算しています。
なお、Astra は per-token 単価こそ高いものの、公式ガイドでは「出力トークンを大幅に少なく使いながら強い結果を出すため、1タスクあたりの推定 API コストは旧モデルより低い」と説明されています。単価表だけを見て判断せず、自社の代表タスクで実測してから決めてください。
移行後に「挙動が違う」と感じたら｜プロンプトで直せる4つ
公式ガイドは、Astra の癖と、それをプロンプトで調整する方法まで踏み込んで書いています。実装が終わったあとに効いてくるのはこちらです。
1. 確認を求めて止まる
Astra は旧モデルより「前提が曖昧なときに勝手に決めず、質問する」方向に振られています。自動処理のパイプラインに組み込むと、そこで止まります。ガイドでは「ユーザーの意図と作業範囲を文脈から推定し、行動に寄せて完遂せよ」という趣旨の指示文を最初に置くことを勧めています。破壊的・不可逆な操作以外は自律的に進める、という線引きを明示するのがコツです。
2. 指示ファイルに敏感すぎる
Astra は長い指示によく従う一方、AGENTS.md のようなファイルに書かれた指示にも強く反応します。ガイドは「モデルがアクセスできるスキルやファイルの内容を監査すること」を強く推奨したうえで、ユーザーの指示がスキルの指示に優先する、と明記するプロンプトを提示しています。複数の指示ファイルを読ませている構成では、まずここを疑ってください。
3. 出力が箇条書きと表だらけになる
Astra は既定で、リスト・表・Markdown を多用して読みやすくしようとします。文章として出したい用途では、段落で書く・リストは並列や手順のときだけ使う、と明示的に指定する必要があります。
4. 小さな変更にも過剰にテストを書く
コーディング用途では、タスクの規模に対してテストが広くなりがちです。「可逆で影響の小さい変更にはテストを書かない」「必要な検査が通ったら、新しい失敗や懸念が出ない限り広げない」といった指示で調整できます。
どれも「モデルが悪い」のではなく、既定の振る舞いが変わったのに指示を更新していないだけです。移行時は、コードと同じくらいシステムプロンプトを見直してください。
移行チェックリスト
- リクエストを「ツールを使う／使わない」で仕分けた
- ツールを使う経路を Responses API に移した
temperature/top_p/top_logprobs（と該当するlogprobs）を削除したnone/minimalだった推論強度をlowに置き、結果を比べたprompt_cache_retentionをprompt_cache_options.ttl: "30m"に置き換えた- EU データレジデンシーを使う経路から Fast mode を外した
- 急がない処理を Batch / Flex に寄せた
- システムプロンプトを Astra 向けに更新した（自律性・書式・テスト量）
- 代表タスク10件で旧モデルと出力・コストを実測した
移行そのものは、この順に潰していけば数日で終わる規模です。時間がかかるのは、たいてい「どの処理を Astra に載せるか」を決める部分で、そこは GPT-6 Astra と Claude Fable 5.1・Gemini 3.8 の比較と使い分け が判断材料になります。
まとめ
GPT-6 Astra への API 移行は、model 名の差し替え・使えないパラメータの削除・ツール呼び出しの Responses API 化・推論強度の置き換え・キャッシュ設定の改名の5点に集約されます。加えて、EU データレジデンシーでは Fast mode が使えず、Batch / Flex なら単価は半額です。そして、実装が終わったあとに効いてくるのはシステムプロンプトの更新のほうです。
自社の処理をどこまで Astra に載せるべきか、移行の切り分けから一緒に整理したい場合は、お気軽にご相談ください。
Astra が ChatGPT の画面や Codex に出てこない場合は API とは別の原因なので、GPT-6 Astra が使えない・出てこないときの原因と確認手順と、プラン別の利用上限と管理者設定を先に確認してください。自社のクラウド基盤で動かせるかは Azure AI Foundry と AWS Bedrock での提供状況にまとめています。
よくある質問
GPT-6 Astra のモデル ID は何ですか？
gpt-6-astra です。OpenAI の公式ドキュメントでは、Responses API のリクエストで model に gpt-6-astra を設定するよう案内されています。コンテキストは1.05Mトークン、最大出力は128Kトークン、知識のカットオフは2026年4月30日です。
GPT-6 Astra で temperature は使えますか？
使えません。公式の移行ガイドでは temperature・top_p・top_logprobs を削除するよう明記されています。Chat Completions を使う場合は logprobs も、Responses API を使う場合は include から message.output_text.logprobs も削除します。出力のばらつきは温度ではなくプロンプトや構造化出力で制御する形になります。
Chat Completions のままでも GPT-6 Astra を使えますか？
生成や要約のようにツールを使わない処理であれば使えます。ただし公式ガイドには、GPT-6 Astra は Chat Completions をサポートするがツール呼び出しには Responses API が必要と書かれています。関数呼び出しを組んでいる場合は、API そのものの移行が同時に必要になります。
推論強度は何に設定すればよいですか？
公式ガイドでは、これまで none または minimal を使っていた場合は low から始めて結果を比べ、それ以外は現在の実効的な推論強度をそのまま保つよう案内されています。会話の途中で強度を変えたい場合は、configuration_update という入力アイテムを使うとプロンプトのキャッシュを壊さずに切り替えられます。
EU のデータレジデンシーでも Fast mode を使えますか？
使えません。公式の料金ページと移行ガイドに、EU データレジデンシーでは GPT-6 Astra の Fast mode が利用できず Standard 処理を使うこと、また Astra の Fast mode にはレイテンシ SLA が付かないことが明記されています。リージョン処理のエンドポイントは10%の上乗せ課金にもなります。