Codex 403エラーの原因と復旧手順・確認ポイント・再試行

Codex 403エラーは「拒否された場所」を読む

HTTPの403は、サーバーがリクエストを理解したうえで、その操作を許可しなかったことを示す。したがって、入力の形式が壊れている場合に出やすい400、資格情報が無効な場合に出やすい401、対象が存在しない場合に使われる404、短時間に送り過ぎた場合に出やすい429とは、最初に見るべき場所が異なる。ただし実際のサービスでは、手前の認証層や接続先のAPIが返した番号をアプリがそのまま表示することもあるため、番号だけで原因を一つに決めることはできない。

OpenAIの公式エラーガイドでは、APIの403の代表例を「対応していない国、地域、または領域」と説明している。同じページで401はAPIキーや組織の確認、429は利用上限や送信速度の確認に分けられている。この分類は、Codexの画面に出るすべての403を説明するものではないが、OpenAI側の拒否とGitHub側の拒否を分ける基準になる。まず発生元を特定し、その後に番号の意味を照合するのが安全だ。

403と401・404・429の違い

401なら、サインイン状態、APIキーの有効性、指定した組織が主な確認対象になる。429なら、利用量、短時間の送信回数、リセット時刻を確認し、連続して送り直すのを止める。404は対象のURLやリポジトリが違う場合だけでなく、非公開リポジトリを見せないためにGitHubが返すこともある。403はこのどれにも完全には置き換えられず、「アクセスは届いたが、許可条件を満たしていない」可能性を中心に調べる。

2026年8月に確認先が増えた理由

2026年8月18日から20日にかけて、OpenAI公式のリリースノートにはCodex Remote、GitLab対応、共有や固定スレッドに関する更新が掲載された。CodexをCLIだけでなくクラウド、モバイル、GitHubやGitLabにまたがって使う場面が増えるほど、同じ「403」という表示でも、OpenAI、接続先のサービス、組織の管理設定のどこが返したのかを見分ける必要がある。現在の更新状況はOpenAI公式リリースノートで確認できる。

最初の5分で行う切り分け

再インストールや設定の全消去から始めると、原因を示す情報まで失ってしまう。最初の5分は、403が一度だけ出たのか、同じ操作で毎回出るのか、別のプロジェクトや別の入口でも再現するのかを比べる時間にする。画面の文言、発生時刻、操作、利用していた入口を残せば、OpenAIやGitHubのサポートへ相談するときも説明が短くなる。

Step 1: 403が出た画面と操作を固定する

まず、Codex CLIのターミナル、IDE拡張、デスクトップアプリ、クラウド上のタスク、モバイルからのRemoteのどこで表示されたかを書き留める。次に「起動時」「サインイン直後」「リポジトリを読み込むとき」「モデルを選んだとき」「GitHubの内容を取得するとき」のどの段階かを確認する。同じ403でも、起動直後ならOpenAIへの接続、リポジトリ取得時ならGitHub側というように候補を絞れる。

Step 2: エラー本文と時刻を保存する

画面に表示された一行だけでなく、エラー本文、request ID、対象のURL、レスポンスヘッダーが見えるならその値も控える。API利用時はキーそのものを記録や共有の文章へ貼り付けず、末尾数文字など安全な識別方法にとどめる。時刻は日本時間で書き、再現した回数と、成功した直前の操作も添える。原因が地域・権限・上限のどれであっても、正確な文面があれば推測を減らせる。

Step 3: 全体障害か自分の環境かを比べる

OpenAIのステータスページでAPI、ChatGPT、Codexの状態を確認する。同ページが正常でも、個別の契約、組織、モデル、地域による拒否まで否定できるわけではない。逆に、複数の入口で同じ時間帯に失敗し、公式ステータスにも該当する障害があるなら、設定を何度も変更せず復旧を待つほうがよい。GitHub側の操作ならGitHubのステータスも別に見る。

Codex CLI・IDE側で403が出る場合

Codex CLIはローカルのプロジェクトを読み、変更し、コマンドを実行する入口だが、サインインやモデルの利用可否はアカウント側の条件に依存する。公式のCLIガイドも、プロジェクトディレクトリから起動してサインインし、作業を始める順番を示している。CLIで403が出たときは、まずツールを消すのではなく、どのアカウント、どの組織、どのモデルを選んでいるかを明らかにする。

Step 4: サインイン方法とアカウントを確認する

ブラウザでサインインできることと、Codex CLIが目的のアカウントで動いていることは同じではない。複数アカウントを使う場合は、現在の表示名や組織を確認し、別のアカウントで開いたブラウザのセッションに引っ張られていないかを調べる。APIキーで接続している場合は、ChatGPTの契約に含まれる利用とAPIの請求・権限が別経路であることも押さえる。認証をやり直す前に、発生時のアカウントを記録しておくと比較しやすい。

Step 5: モデル名と利用入口を一つずつ戻す

直前にモデルを変更した、alpha版を導入した、IDEからCLIへ切り替えた、といった変化があれば一度に全部を戻さない。まず公式に利用できると確認できるモデルと入口へ戻し、同じプロジェクトで再現するかを見る。別モデルで通ったとしても、それは元のモデルへの利用権がない、または表示条件が違うという手掛かりであって、原因の確定ではない。利用条件が不明なモデル名を連続して試すより、公式のモデル一覧とアカウントの表示を照合する。

Step 6: 再試行は一度にとどめて差分を比べる

ネットワークの瞬断や一時的な接続失敗なら、短い待ち時間のあと一度だけ同じ操作を試す意味がある。ただし、同じ403を短時間に繰り返しても権限は増えない。別のプロジェクト、別のアカウント、別のモデルを同時に変えると、何が直したのか分からなくなる。再試行の前後で、エラー本文、発生時刻、入口、モデルの四点だけを比較し、変化がなければ設定または利用条件の確認へ進む。

OpenAI API経由で403が出る場合

Codexの機能をAPI経由で呼び出しているときは、ChatGPTの画面で使えることだけを根拠にAPIでも使えると判断しない。OpenAI APIの公式エラーガイドは、401、403、429を別の原因として整理しているため、レスポンスのステータスと本文をそのまま確認する。利用地域、組織、プロジェクト、モデル、エンドポイントの組み合わせが変われば、同じ利用者でも結果が変わる。

APIキーと組織・プロジェクトの組み合わせを見る

401の説明に該当するなら、キーの入力ミスや期限切れを確認する。403の場合は、キーを作り直すだけでは解決しないことがある。APIキーが属する組織やプロジェクトと、モデルやエンドポイントが想定している対象を照合し、管理画面でアクセス条件が有効かを確かめる。キーの値はログや記事の問い合わせ欄に出さず、失敗したリクエストのID、時刻、モデル名だけを安全に伝える。

地域とモデルの利用条件を確認する

OpenAIの公式エラー一覧では、APIの403の代表例として未対応の国・地域・領域が挙げられている。VPNや社内プロキシを使っている環境では、利用者がいる場所とサービスから見える接続元が一致しない場合があるため、まず会社のネットワーク担当に経路を確認する。モデルについては、一覧に名前が表示されることと、自分の組織から実際に呼び出せることが同義とは限らない。モデルの利用条件、契約、地域の三つを分けて確認する。

request IDを残して問い合わせる

公式情報だけで判断できない場合は、エラー本文を要約せず、発生時刻、タイムゾーン、利用した入口、モデル、組織またはプロジェクトの識別情報、request IDをそろえる。個人情報やキーの全文、リポジトリの中身は送らず、必要な範囲だけを伏せて示す。OpenAIの公式ガイドが示す401・403・429の区別と実際のレスポンスが一致しないときは、その差分も書くと、単なる「動かない」という相談より調査対象が明確になる。

GitHub連携で403が出る場合

CodexがGitHubのリポジトリやプルリクエストを読み込む場面では、OpenAIのサインインが成功していても、GitHubへのアクセスが拒否されることがある。ここではOpenAI側のアカウントを何度も切り替える前に、GitHubのレスポンス本文とヘッダーを確認する。対象リポジトリの公開範囲、組織の方針、接続アプリに与えたリポジトリ範囲が違えば、同じアカウントでも結果は変わる。

レート制限の403かを見分ける

GitHub公式ドキュメントによると、プライマリまたはセカンダリのレート制限を超えた場合、403または429が返り、x-ratelimit-remaining が0になることがある。retry-after があればその秒数、残量が0なら x-ratelimit-reset の時刻まで待つ。ヘッダーが取れない画面でも、短時間に大量の取得をした直後なら、まず操作を止めて時間を置く。上限中に同じリクエストを増やすほど、復旧が遅れる可能性がある。

リポジトリ権限と組織承認を確認する

「Resource not accessible by integration」のような本文なら、対象エンドポイントに必要な権限が足りない可能性が高い。GitHubの公式資料では、レスポンスの X-Accepted-GitHub-Permissions ヘッダーから、たとえば内容の読み取りやプルリクエストの書き込みなど、必要な権限を確認できると説明している。接続アプリが対象リポジトリを選択できる状態か、組織のSSOや管理者承認が残っていないか、最近権限が追加されて再承認が必要になっていないかを確認する。

対象リポジトリを小さくして比較する

同じ組織にある公開リポジトリと非公開リポジトリ、個人所有と組織所有のリポジトリを一つずつ比べる。公開側だけ成功するなら、接続アプリのリポジトリ範囲や組織ポリシーが候補になる。すべてで403なら、レート制限、接続状態、アプリ側の認可を優先する。GitHub公式は、非公開リソースへの未認証アクセスを404で返す場合もあると説明しているため、403と404を同じ権限エラーとして扱わないことも重要だ。出典: GitHub REST APIの認証

画面別に見る復旧の順番

発生場所が分かったら、変更範囲を小さくして復旧する。CLIでローカルコードを読むだけならGitHub接続をいったん外した状態で再現を確認し、クラウドやRemoteでリポジトリを読む場合は対象の接続だけを確認する。アプリ全体の設定を削除すると、どの入口で拒否されたかを見失うため、最初は一つの層だけを戻す。

Step 7: CLIだけならローカル要因を先に外す

Codex CLIのサインインやモデル選択で403が出る場合は、同じプロジェクトで別の入口を試す前に、現在のCLI版、表示されているアカウント、プロジェクトの場所を控える。公式CLIガイドは、プロジェクトディレクトリから起動してサインインし、そこでタスクを始める流れを案内している。ローカルのファイル権限エラーと、OpenAIから返ったHTTP403を混同しないよう、ターミナルの前後の行も確認する。

Step 8: Remote・クラウドなら接続先を分ける

Remoteやクラウドで403が出た場合は、OpenAIへの接続、リポジトリへの接続、対象タスクの利用条件を別々に記録する。モバイルから操作したからといって、モバイル側のログインだけをやり直せばよいとは限らない。リポジトリの取得で止まったならGitHub側、モデルの開始で止まったならOpenAI側というように、最後に成功した段階を境に調べる。複数の接続を同時に解除するのは最後にする。

Step 9: サービス状態が戻ってから一度だけ検証する

公式ステータスで障害が解消したことを確認したら、最初に失敗した操作を小さく再現する。別モデルや別リポジトリを混ぜず、同じアカウント、同じ入口、同じ対象で結果を比べる。成功したら変更した設定を一つずつ戻し、どの条件が影響したかを残す。失敗が続くなら、そこで新しい試行を増やさず、エラー本文と時刻を添えて問い合わせる。

やってはいけない対処

403を見た直後に、アプリやCLIを何度も削除して入れ直すのは避けたい。再インストールでは地域、組織、モデル、GitHub権限の拒否は直らず、元の版や設定を記録していなければ比較材料もなくなる。また、同じリクエストを短時間に送り続けると、GitHubのレート制限のように状況を悪化させる場合がある。まずエラー本文と発生元を残し、必要なら待つという順序を守る。

設定を全消去する前に残すもの

消去やログアウトの前に、CLIの版番号、利用入口、表示アカウント、モデル名、プロジェクトの場所、発生時刻、エラー本文を控える。接続アプリの権限画面を変更する場合も、変更前の対象リポジトリと組織をメモしておく。認証情報の全文を保存する必要はない。調査に必要なのは、どの条件で拒否されたかを再現できる範囲の情報だ。

403を認証ミスだけで説明しない

OpenAIの公式エラーガイドが示す403の代表例は地域条件であり、GitHubの公式資料が示す403にはレート制限や権限不足も含まれる。この二つを合わせると、403には少なくとも「地域・組織・モデル」「接続先の権限」「送信上限」という別の軸があると分かる。どれか一つの対策を全サービスへ適用するのではなく、発生元に対応した確認先を選ぶべきだ。

まとめ：Codex 403エラーは発生元から直す

Codexの403エラーで最初にすることは、パスワードを替えることでも再インストールでもない。CLI、API、GitHub、Remote・クラウドのどこが拒否を返したのかを固定し、画面の本文、発生時刻、アカウント、モデル、対象リポジトリをそろえることだ。OpenAI側なら地域・組織・モデル・利用条件、GitHub側ならレート制限・リポジトリ範囲・組織承認を確認する。

2026年8月の公式更新でCodexの利用入口が増えた今は、「Codexが使えない」と一括りにするほど復旧が遠のく。OpenAIのエラーコード一覧、Codex CLIガイド、GitHubのREST APIトラブルシューティングを発生元に合わせて参照し、一つの条件だけを変えて再現を確認する。403の番号を原因ではなく、次に見る場所を示す手掛かりとして使えば、不要な設定変更を減らしながら復旧できる。