GPT-5.6が使えない? 6つの原因と対処法(2026年版)

GPT-5.6は稼働しているので、「model not available」エラーがモデルの消失を意味することはほぼありません。 これは、あなたのリクエストとOpenAIのルーターの間で6つの特定の問題のいずれかが起きていることを意味し、そのうち5つは1分以内で修正できます。最も多い原因はアクセスとはまったく無関係です。ティアの明示を求めるゲートウェイで、素の gpt-5.6 IDを呼び出しているのです。

GPT-5.6が使えない? 30秒で切り分ける

次の3つのチェックを順に実行してください。ほとんどの人は最初のチェックで解決します。

よくあるケースの手早い対処法: モデル文字列を gpt-5.6-sol(OpenAI直接)または openai/gpt-5.6-sol(ofoxのようなゲートウェイ)に変えて再実行します。モデル一覧チェックでIDが完全に欠けている場合は、以下のアクセス原因へ飛んでください。

同じ3つのチェックを決定木にすると次のようになります。

flowchart TD
    A[GPT-5.6 model not available] --> B{Called bare gpt-5.6?}
    B -->|Yes| C[Use gpt-5.6-sol / -terra / -luna] --> Z[Retry]
    B -->|No| D{Tier ID in GET /v1/models?}
    D -->|Yes| E[Request problem: model string, endpoint, or org header] --> Z
    D -->|No| F{Behind a VPN or proxy?}
    F -->|Yes| G[Disconnect and retry] --> Z
    F -->|No| H{Within 24h of GA?}
    H -->|Yes| I[Rollout lag: wait and recheck, or switch gateway]
    H -->|No| J[Access scope: check org, workspace, account, verification]

多くの人が引っかかるのは一番最初の分岐です。どのGPT-5.6ティアを使いたいかを考えたことがないなら、おそらく素のIDを送っています。それが最も早く除外できる要因です。

直すべきとき、待つべきとき、切り替えるべきとき

すべての「model not available」が自分側でデバッグする価値があるわけではありません。時間を投入する前に、自分の状況を次の3つの対応のいずれかに当てはめてください。

自分のコードで直すべきなのは、モデル一覧エンドポイントがティアIDを表示している場合です。これはモデルが自分のキーに対して存在することを意味するので、エラーは自分の管理下にある命名、エンドポイント、または組織ヘッダーの問題であり、1行の変更で済みます。これはほとんどの人が該当するのに気づいていないケースです。エラー文言(「存在しないか、アクセス権がありません」)のせいで、モデルが一覧にちゃんとあるのに提供状況の問題のように聞こえてしまうからです。

待つべきなのは、2026年7月9日または10日で、かつ一覧にIDが欠けている場合です。一般提供の展開は約24時間かけて伝播したため、初日にIDが欠けているのは、通常アカウントの不具合ではなく、展開がまだ自分の組織に到達していないだけです。サポートチケットを開く前に、1〜2時間おきにモデル一覧を再確認してください。展開期間中に提出したチケットには「展開をお待ちください」という返信が来るだけです。

上流に切り替えるべきなのは、本番環境で今日モデルが必要で、自分の組織への付与を待てない場合です。3つのティアをすべて掲載済みのゲートウェイなら即座にブロックを解除でき、自分で制御できない展開のためにローンチを止める理由はありません。呼び出しの形は同一なので、自分の組織が追いついたらいつでも直接キーに戻せます。

停止ルール: GET /v1/models がティアIDを掲載していて、かつVPNの背後にいないなら、問題はOpenAIの提供状況ではなくあなたのリクエスト(モデル文字列、エンドポイント、または組織ヘッダー)にあります。この3つを確認するまでサポートチケットを提出しないでください。サポートはまさにその3つの確認を最初に求めてきます。

エラーの理解: 404 model_not_found と 403 no-access

同じ「model not available」という感覚の裏には、2つの異なるHTTPステータスが隠れており、それぞれ意味が異なります。

OpenAIの直接APIはこの404ボディを返します。

{
  "error": {
    "message": "The model `gpt-5.6` does not exist or you do not have access to it.",
    "type": "invalid_request_error",
    "param": null,
    "code": "model_not_found"
  }
}

このメッセージは意図的に2つの原因を混同しています(「存在しないか、アクセス権がありません」)。切り分け方法は、診断表にあるモデル一覧チェックです。IDが自分の一覧にあれば、それは自分にとって存在しており、問題はリクエスト側です。欠けていれば、それはアクセスの問題です。

このJSONはOpenAI直接の形式で、ゲートウェイは同じエラーを独自のエンベロープで包むため、正確な文言は移植できません。ofoxでは、素の openai/gpt-5.6 は {"error":{"message":"Model 'openai/gpt-5.6' not found","type":"model_not_found","code":404}} を返します。ここでは機械可読な model_not_found が type に入り、code はOpenAI直接ボディがそこに置く文字列ではなく数値のHTTPステータスになっています。1つの正確なメッセージをgrepしないでください。code または type に model_not_found を含む404はすべて、この同じエラーとして扱ってください。

あらゆるOpenAIモデルに共通するこのエラーの一般版については、OpenAI 404 model-does-not-existガイドがGPT-5.6固有ではない原因をすべて解説しています。

GAで何が変わり、なぜ古い「アクセスなし」のアドバイスが古びたのか

GPT-5.6のプレビュー期間中にこのエラーを検索し、古いアドバイスを読んでいるなら、その古いアドバイスは捨ててください。2026年6月26日から始まったプレビューはゲート付きでした。アクセスは審査のうえ限られた一部のアカウントに付与されたため、その2週間は「model not available」は通常、あなたがリストに載っていないことを意味し、唯一の実効的な対処はアクセスを申請して待つことでした。

2026年7月9日の一般提供でそれが一変しました。GPT-5.6はChatGPT、Codex、APIでグローバルに展開されたため、not-availableエラーが今、ゲート付きプレビューから締め出されていることを意味することはほぼありません。それは以下の6つの機械的な原因のいずれかを意味します。これは今日このエラーをデバッグするうえで最も重要な考え方の転換です。特別なアクセスが必要だという思い込みをやめ、モデル文字列、組織スコープ、地域を確認し始めてください。今実際に壊れているのはそれらだからです。

実用的なテストは今でもモデル一覧エンドポイントです。ゲート付きプレビュー中は、ほぼ全員に対してティアIDが欠けており、対処は自分の手の届かないところにありました。GA後は、大多数のキーでIDが存在するようになり、エラーは「これは持てない」から「あなたのリクエストの形が間違っている」へと移りました。この移行こそが、以下の対処法がアクセス申請ではなくほとんど1行の変更で済む理由です。

6つの原因、発生頻度の高い順

原因1: ティアにエイリアスを設定していないゲートウェイで素の gpt-5.6 IDを使った

これはOpenAIを直接呼び出していない人にとって最も多い原因であり、純粋に命名の問題です。

OpenAI自身のAPIは素の gpt-5.6 をSolティアにエイリアスしているため、直接エンドポイントでは gpt-5.6 が動作し、静かにSolへルーティングされます。そのエイリアスは移植できません。マルチプロバイダのゲートウェイ、プロキシ、ルーターは、どのティアを意図したかを推測しないため、一般に明示的なティアを要求します。たとえばofoxでは、openai/gpt-5.6 は404を返す一方、openai/gpt-5.6-sol、openai/gpt-5.6-terra、openai/gpt-5.6-luna はすべて解決します。

プロバイダ間の命名の違いは次のとおりです。

対処法と習慣: 常に明示的なティアを渡してください。素のエイリアスに依存すると、コードをゲートウェイの背後に移した瞬間に壊れますし、OpenAIがエイリアスの参照先を変えた場合にルーティングが非決定的になります。実際に使いたいティアを選んで、明示的に指定してください。

失敗する呼び出しと動作する呼び出しの例は次のとおりです。ゲートウェイに対する素のID:

# 404 on a gateway that does not alias the bare ID
curl https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-5.6", "messages": [{"role":"user","content":"hi"}]}'
# -> 404 {"error":{"message":"Model 'openai/gpt-5.6' not found","type":"model_not_found","code":404}}

同じ呼び出しを明示的なティアで行うと解決します。

curl https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-5.6-sol", "messages": [{"role":"user","content":"hi"}]}'
# -> 200, routed to Sol

SDKでは、変わるのはモデル文字列だけです。Python:

# breaks behind a gateway, works on OpenAI direct (aliases to Sol)
resp = client.chat.completions.create(model="gpt-5.6", messages=msgs)

# portable everywhere: name the tier
resp = client.chat.completions.create(model="gpt-5.6-sol", messages=msgs)

Nodeも同じ形です。

// portable: explicit tier
const resp = await client.chat.completions.create({
  model: "gpt-5.6-terra",
  messages: msgs,
});

共有設定やモデルレジストリを保守している場合は、ティアのサフィックスがないリテラル文字列 gpt-5.6 を検索し、すべて置き換えてください。この一括作業だけで、次回コードがプロキシやゲートウェイの背後で実行されたときにエラーが再発するのを防げます。

原因2: GAの展開がまだ自分の組織に到達していない

GPT-5.6は2026年7月9日に一般提供が開始されましたが、OpenAIは約24時間かけてグローバルに展開しました。その期間中は同じキーでも、ある地域ではティアIDが解決し、別の地域では404になることがありました。GAから1日以内にこれを読んでいて、かつ GET /v1/models がティアを掲載していない場合、これが有力な原因であり、自然に解消します。

対処はその待ち時間のコスト次第です。個人開発者や趣味のプロジェクトなら、2時間おきにモデル一覧を再確認するだけで、他に何もする必要はありません。付与は自然に届くからです。ローンチを止められない有料APIプランのチームなら、ティアをすでに掲載済みのゲートウェイ経由でルーティングし(代替手段のセクション参照)、組織が追いついたら直接キーに戻すべきです。複数の組織を持つエンタープライズアカウントは、どの組織に最初にアクセスが付与されたかを確認すべきです。付与は他の組織より数時間早く1つの組織に届くことが多く、アカウントに「アクセスがある」のに誤った組織のキーは404になるからです。

この原因の微妙なバリエーション: モデルが一覧に表示されるのに、呼び出しが数分間404になる場合です。これは、ルーティング層があなたの地域で完全に稼働する前に、カタログエントリがモデルエンドポイントに伝播したときに起こります。IDが掲載されているのに最初の呼び出しが失敗する場合は、本当のエラーとして扱う前に、5分待って一度再試行してください。

原因3: アクセスが別の組織、ワークスペース、またはアカウントで有効になっている

アクセスは組織ごと、Codexワークスペースごと、アカウントのメールアドレスごとにスコープされます。ChatGPTでGPT-5.6を使える人物が、呼び出しを行うAPIキーと自動的に同じ主体になるわけではありません。

次の3つが一致していることを確認してください。

1. API呼び出しがアクセスを付与された組織IDを使っている。複数の組織に所属している場合は、デフォルトに頼らず OpenAI-Organization ヘッダーを明示的に設定します。
2. キーのアカウントのメールアドレスが、付与を受けたものと一致している。
3. アクセスがCodex専用の場合、一般的なAPIキーではなく、承認済みのCodexワークスペースから呼び出していることを確認します。

組織を明示的に設定すると推測がなくなります。

from openai import OpenAI

client = OpenAI(
    organization="org-THE_ONE_WITH_ACCESS",  # not your default org
    project="proj_...",                       # the project scoped to the grant
)
resp = client.chat.completions.create(model="gpt-5.6-sol", messages=msgs)

どの組織が実際に付与を持っているかを調べるには、ダッシュボードで組織を一覧表示するか、組織ヘッダーごとに一度モデルエンドポイントを呼び出し、どれがティアIDを返すかを確認します。それらを掲載する組織が、本番キーで使うべき組織です。これが、同じ人物でもスコープの異なる主体であるために、ChatGPTでGPT-5.6が動くのにAPIが404になる理由です。

原因4: VPNやプロキシによってサポート対象外の地域に見える

OpenAIはサポート対象外の国や地域から発信されているように見える接続をブロックしますが、そのブロックは明確な地理的メッセージではなく、モデルが使えない、またはアクセスエラーとして表面化することが多いです。会社のプロキシとプライバシーVPNの両方がこれを引き起こします。

対処法: VPNやプロキシを切断して再試行します。コンプライアンス上の理由でプロキシ経由が必須なら、そのエグレスIPがサポート対象の地域にあることを確認するか、上流の地域が安定しているゲートウェイを使ってください。この原因は、エラー文言が地理について何も言わないため見落としやすいです。

これが地域の問題であって他の何かではないと確認するには、入力している端末のIPではなく、リクエストが実際に出ていくエグレスIPを確認してください。企業ネットワークはしばしば送信トラフィックをオフィスとは別の国のゲートウェイ経由でルーティングするため、サポート対象地域の開発者でも、会社のエグレスノードが別の場所にあるためにブロックに引っかかることがあります。OpenAI呼び出しを行うのと同じホストとネットワークから curl https://api.ipify.org を実行すると、OpenAIが見ているIPが分かります。そのIPがサポート対象外の地域に解決される場合、model-not-availableエラーは命名エラーの衣装をまとった地理の問題であり、モデル文字列をどう変えても直りません。

原因5: GPT-5.6が機能を公開する方法に対して誤ったエンドポイント

GPT-5.6はプログラム的なツール呼び出しをResponses API経由で提供します。統合がchat-completions向けに構築されているのにResponses専用の機能を呼んだり、誤ったパスにPOSTしたりすると、実際にはモデルは問題なくエンドポイントが間違っているのに、モデルが使えないように読めるエラーが出ることがあります。

対処法: 機能が必要とするエンドポイントに乗っているか確認します。プレーンテキストや標準的なチャット呼び出しはchat-completionsの形で動作します。新しいプログラム的なツール呼び出しのパスはResponses APIを使います。アクセスの問題だと決めつける前に、エンドポイントを機能に合わせてください。

標準的なチャット呼び出しはchat-completionsのままで問題なく動作します。

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "refactor this function ..."}],
)

プログラム的なツール呼び出しのパスはResponses APIへ移ります。

resp = client.responses.create(
    model="gpt-5.6-sol",
    input="refactor this function ...",
    tools=[{"type": "function", "name": "run_tests", "parameters": {}}],
)

GPT-5.6のローンチ資料からツール呼び出しのスニペットをchat-completions統合にコピーすると、そのミスマッチがモデルまたは機能のエラーとして読めることがあります。モデルは使えます。呼び出しが誤ったサーフェスにあるのです。ツール呼び出しの変更が提供状況の問題を装わないよう、コード内で2つのパスを分けておいてください。

原因6: アカウントでティアまたは認証が有効になっていない

一部のアカウントは、最前線のモデルがアンロックされる前に本人確認または組織の認証を必要とします。また一部の利用ティアは、支出のしきい値に達するまで最新モデルをゲートします。モデル一覧がGPT-5.6を除外しているのに古いモデルを含んでいて、かつGA展開期間を過ぎている場合は、ダッシュボードでアカウントの認証状況と利用ティアを確認してください。

対処法: 保留中の認証を完了するか、すぐには解除できないティアゲートでブロックされている場合は、自身の認証済みアカウントでモデルを前面に出すゲートウェイを使ってください(下記)。

ダッシュボードで確認すべき具体的な2点。1つ目、組織の認証: 一部のアカウントは、最新の最前線モデルがアンロックされる前に本人確認または組織の認証ステップを完了する必要があり、完了するまでこれらのモデルは単に一覧から欠け、古いモデルは通常どおり動作します。2つ目、利用ティア: OpenAIのティアは累積支出とともに段階的に上がり、最新モデルは高いティアに先に到達することがあります。アカウントが初期ティアにあり、GPT-5.5があるのにGPT-5.6の全ティアが欠けている場合、ティアゲートが有力な理由です。どちらもコードで直せるものではなく、まさにそれが、認証済みで高ティアのアカウントでモデルを前面に出すゲートウェイが、自分のアカウント状況を整理する間の現実的なブロック解除である理由です。

よく見られる失敗パターン

これらは実際の統合でこのエラーが取る形なので、自分の症状とパターンマッチできます。

今すぐブロックを解除する代替手段

自分の組織の展開を待てない、またはティアゲートを解除できない場合は、3つのティアをすべて掲載済みのゲートウェイ経由で呼び出してください。これが最も早いブロック解除であり、標準的なOpenAI SDK構成からモデル文字列を1行変えるだけです。

ofoxでは、3つのGPT-5.6ティアすべてがOpenAI互換エンドポイントで稼働しており、2026年7月10日時点で確認済みです。

OpenAI直接クライアントからの切り替えは次のとおりです。

from openai import OpenAI
import os

# was: client = OpenAI()  # api.openai.com, waiting on your org rollout
client = OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key=os.environ["OFOX_API_KEY"],
)

resp = client.chat.completions.create(
    model="openai/gpt-5.6-terra",   # explicit tier, no bare-alias 404
    messages=[{"role": "user", "content": "Summarize this stack trace: ..."}],
)
print(resp.choices[0].message.content)

Nodeも同じ考え方です。

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "openai/gpt-5.6-terra",
  messages: [{ role: "user", content: "Summarize this stack trace: ..." }],
});
console.log(resp.choices[0].message.content);

同じSDK、同じ呼び出しの形、変えるのはベースURLとモデル文字列1つずつだけです。どのみち移行する理由がコストなら、TerraはGPT-5.5の料金のちょうど半分で掲載されており、GPT-5.6 Terra vs GPT-5.5のコスト内訳にタスクごとの計算があります。3ティアすべてを下回る非OpenAIの選択肢については、GLM-5.2 vs GPT-5.5のコスト比較がオープンウェイト側をカバーし、$30 AIコーディングスタックガイドは、単一モデルの提供状況が二度とあなたをブロックしないよう、自動フォールバック付きで複数プロバイダにルーティングする方法を示しています。

GPT-5.6の提供状況を監視してアラートを受け取る方法

展開やアクセス付与を待っている場合、curlコマンドを手で更新し続けて座っていてはいけません。タイマーでモデルエンドポイントをポーリングし、ティアが出現した瞬間に知らせてもらいましょう。最小限のウォッチャーは次のとおりです。

import os, time
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
target = "gpt-5.6-sol"

while True:
    ids = {m.id for m in client.models.list().data}
    if target in ids:
        print(f"{target} is now available")
        break
    print(f"{target} not yet listed, rechecking in 5 min")
    time.sleep(300)

これを対象としたいサーフェスに向けて実行させておきます。提供開始の行が出力されたら、付与が届いたので、本番を直接キーに戻せます。ポーリング間隔は5分以上に保ってください。展開中にエンドポイントを叩き続けても何も得られません。

プラットフォーム側については、提供状況エラーとしても表面化しうるAPIインシデントについてOpenAIの公式ステータスページを監視し、遅い展開がユーザーにとって障害にならないようフォールバックルートを設定しておいてください。ゲートウェイでは、モデルカタログそのものが提供状況のシグナルです。ofoxモデルカタログがティアを掲載していて、かつキーが有効なら、モデルは今すぐ呼び出せます。待つべき展開はありません。それが、1つのプロバイダの展開スケジュールに依存することと、モデルがすでに稼働している層経由でルーティングすることの、実用上の違いです。

10秒でアクセスを確認する方法

何かを再試行する前に、APIに対して、あなたのキーに実際に何を提供するかを尋ねてください。

curl https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | grep -o '"id": *"gpt-5.6[^"]*"'

これがティアIDを出力すれば、モデルは自分にとって存在し、エラーはあなたのリクエストにあります。何も出力しなければ、キーにはまだアクセス権がなく、対処はコードではなくアクセス(展開、組織スコープ、認証)です。ゲートウェイでも同じ考え方が当てはまります。ofoxモデルカタログはあなたのキーが呼び出せるものを正確に掲載しているので、モデル文字列を推測する必要は一切ありません。

再発を防ぐ

エラーを一度直すのは簡単です。直したままに保つのは、採用にコストのかからない3つの習慣の問題です。

どこでもティアを明示し、コードベースに素の gpt-5.6 を置かないでください。モデルIDを呼び出し箇所全体に散らばらせるのではなく、1つの設定定数に置くことで、次のモデル更新は1行の変更になり、忘れたスクリプトに紛れ込んだ素のエイリアスがなくなります。モデル文字列の単一の情報源が、30秒のアップグレードと午後をまるごとgrepに費やすことの違いを生みます。

最初のリクエストではなく、起動時にモデルを検証してください。サービス起動時にモデル一覧エンドポイントを呼び出し、設定されたIDが欠けていたら大きな音で失敗するようにします。ユーザーのリクエストが本番で404になって初めて気づくのではなく。4行の起動時チェックが、静かで断続的なユーザー向けの障害を、すぐに見える明確なデプロイ時のエラーに変えます。

フォールバックルートを配線しておいてください。GPT-5.6への唯一の経路が1つの組織上の1つのプロバイダなら、あらゆる展開の遅延、ティアゲート、地域の不具合がダウンタイムになります。別のプロバイダや別のアカウントにフォールバックできる層経由でルーティングすれば、単一モデルの提供状況が単一障害点になることは決してありません。$30 AIコーディングスタックガイドがそのルーティングパターンを最初から最後まで解説しており、これこそが上記の6つの原因すべてをユーザーにとって無関係にする構造的な解決策です。

FAQ

上記のFAQスキーマは、このエラーについて人々が最も検索する8つの質問に答えています。確認すべき順の要約: まずモデル文字列、次にモデル一覧、続いて組織スコープ、地域、エンドポイント、認証です。6つの原因のうち5つは自分側の1行の変更で、6つ目は短い待ち時間、または3つのティアをすべて掲載済みのゲートウェイへの切り替えです。要約すると、まずモデル文字列、次にモデル一覧、そして組織と地域を3番目に、この順で確認してください。

References

• ofox model catalog: openai/gpt-5.6-sol, terra, luna
• OpenAI API model reference: gpt-5.6-sol
• OpenAI: GPT-5.6 general availability
• Simon Willison: the new GPT-5.6 family (Luna, Terra, Sol)
• GitHub Changelog: GPT-5.6 Sol, Terra, Luna in GitHub Copilot
• MarkTechPost: GPT-5.6 three-tier family with programmatic tool calling in the Responses API
• OpenAI 404 model-does-not-exist guide

GPT-5.6がキーで使えない場合は、6つの原因を上から下へたどってください。モデル文字列、展開、組織スコープ、地域、エンドポイント、認証です。6つのうち5つは1分以内に自分で直せるもので、6つ目は短い待ち時間、または3つのティアをすべて掲載済みのゲートウェイへの1行の切り替えです。