AIツールの枠切れ・障害・認証を切り分ける

本記事の公式資料の確認日は2026年7月24日です。料金変更、再認証、問い合わせ、アカウント切替、外部実行は行わず、切り分けと証拠保存だけを扱います。

AIコーディングや生成AIを使っていると、長い作業の途中で突然止まり、「usage limit」「rate limit」「unauthorized」「forbidden」「internal error」などが表示されることがあります。ここで一番危険なのは、エラー文を見てすぐ原因を一つに決めることです。

同じ「使えない」でも、五時間などの短い利用窓を使い切った、週単位の総枠を使い切った、APIの毎分上限に触れた、契約は有効でも対象機能の権限がない、ログイン情報が失効した、サービス側で障害が起きている、社内ネットワークが通信を止めた、古いクライアントが現在のサーバーと合わない、という別々の原因があります。対処も待ち時間も違います。

利用者の公開報告では、短い利用窓と週枠の減り方が理解しにくい、軽い作業でも急に枠が減ったように見える、コンテキスト処理の不調と枠消費を区別しにくい、といった声が継続しています。ただし、公開IssueやSNS投稿は需要の証拠であって、個別アカウントの原因や現行仕様を証明するものではありません。本稿は、症状を「待てば直る枠切れ」と決めつけず、観測時刻、影響範囲、再現条件、公式状況、待つ条件、別作業へ移る条件の六点で分けます。

最初の90秒で行うこと

作業が止まった直後は、次の順番だけを守ります。ログアウト、再認証、契約変更、アカウント切替、同じ送信の連打はまだ行いません。

画面に出た文を省略せず保存する。ただしトークン、APIキー、メールアドレス、組織IDなどの秘密や個人情報は伏せる。
発生時刻をタイムゾーン付きで記録する。日本なら「2026-07-24 07:07 JST」のようにする。
製品名、利用面、モデル、クライアント版、作業IDを記録する。Web、デスクトップ、CLI、IDE拡張、APIは別の利用面として扱う。
最後に成功した時刻と、失敗した最初の操作を記録する。
一度だけ、外部副作用のない最小の読取操作で再現を確かめる。同じ重い処理を再送しない。
公式ステータスと利用量表示を別々に確認する。片方が正常でも、もう片方の原因は残る。
原因が分かるまで、保存済みのローカル作業、設計、検品、文章整理など、失敗したサービスを使わない仕事へ移る。

この七手で、再現条件を壊さず、課金や利用枠の追加消費も抑えられます。作業を依頼する段階から停止条件を明示する方法はAIへの依頼状の書き方、AIの完了報告と実際の証拠を分ける方法はAIエージェントの完了報告を証拠で確かめるも参考になります。

七つの原因を別の箱に入れる

最初に分類する箱は七つです。一つの障害に二つ以上が重なる場合もあります。

分類	典型的な観測	公式画面で見る場所	待つと変わり得るか	勝手に行わないこと
利用枠	残量、次回リセット時刻、週枠到達の表示	製品内のusage、plan、limits	リセット時刻後に変わり得る	別アカウントへ切り替える
速度制限	HTTP 429、Retry-After、毎分要求数やトークン数	APIのrate limit、応答ヘッダー	指定時刻や指数バックオフ後に変わり得る	短時間に同じ要求を連打する
権限不足	HTTP 403、機能が非表示、管理者承認が必要	workspace、organization、role、policy	待つだけでは通常変わらない	権限を自分で広げる
認証失効	HTTP 401、ログイン要求、期限切れ、署名不一致	session、credential、sign-in method	自動更新がある製品以外は待つだけでは直らない	秘密をログへ貼る、無断で再認証する
サービス障害	複数利用者、複数端末、5xx、公式incident	公式statusとincident history	公式復旧により変わり得る	契約やローカル設定を先に変える
ローカル通信	DNS、TLS、proxy、VPN、firewall、timeout	OS、ネットワーク、組織の通信記録	回線や一時障害なら変わり得る	証明書検証や保護機構を無効化する
版不一致	特定クライアントだけ失敗、非対応versionの表示	クライアント版、release、公式要件	待つだけでは通常変わらない	出所不明のインストーラーを使う

「枠」は定額サービス内の利用配分、「速度制限」は一定時間内の要求密度、「請求上限」はAPIなどで利用可能な金額や残高に関わる制御です。表示が同じ429でも、応答本文とヘッダー、契約画面、利用量画面を照合しなければ区別できません。

OpenAIのAPIエラー資料は、401を認証、403を国・地域または権限、429を速度制限やquota、5xxをサーバー側の問題として分けています。AnthropicのAPI資料も、401、403、429、500、529などを別の意味で整理しています。GoogleのGemini APIトラブルシューティングは、403を権限、429を要求数・トークン数・支出などの上限、499を呼出側のキャンセル、500と503をサーバー側や過負荷の候補として示しています。GitHub REST APIは、primaryまたはsecondary rate limitに達したとき403または429になり得るため、x-ratelimit-remaining、x-ratelimit-reset、retry-afterの確認を求めています。

つまり、HTTP番号だけで「枠切れ」「障害」「認証切れ」と断定することはできません。製品ごとの公式定義と、同じ応答に含まれる機械的な証拠が必要です。

六点観測票で原因を狭める

1. 観測時刻

時刻は「朝」「さっき」ではなく、日付、時刻、タイムゾーンを一組にします。公式ステータスがUTC表示なら、変換前のUTCと自分のJSTを両方残します。利用枠のリセット表示も、その画面に表示された時刻を保存します。

時刻が必要なのは、短い利用窓の境界、週枠の境界、公式incidentの開始と終了、認証トークンの期限、クライアント更新の配布時刻を重ねるためです。同じ日でも、障害前に失敗していたのか、障害中だけ失敗したのか、復旧後も失敗しているのかで次の行動が変わります。

2. 影響範囲

次の五段階で広さを記録します。

一つの会話、タスク、リポジトリだけ
一つのモデル、機能、コネクタだけ
一つの利用面だけ。たとえばデスクトップだけでWebは正常
一つの利用者、端末、回線だけ
複数の利用者、端末、回線、地域で発生

範囲が狭いほど入力、設定、権限、クライアントの候補が上がり、範囲が広いほどサービス障害の候補が上がります。ただし、広いから必ず障害、狭いから必ず自分の問題、とは限りません。公式ステータスは全利用者の個別状態を保証せず、OpenAIのステータスページも集計された可用性であり、プランや機能により個別の可用性が異なり得ると明記しています。

3. 再現

再現確認は一回、最小、読取専用を原則にします。長いエージェント作業をそのまま再送すると、利用枠、請求、外部副作用、二重変更の危険が増えます。

良い最小再現は、同じ利用面で新しい短い会話を開く、APIなら副作用のない最小要求を一回だけ送る、ローカルCLIなら版情報と認証状態の表示だけを確認する、といったものです。悪い再現は、デプロイ、送信、削除、購入、長時間ジョブをもう一度実行することです。

4. 公式状況

公式状況は現在ページと履歴ページを分けて保存します。現在ページが正常でも、数分前までのincidentが履歴へ移動している場合があります。逆に、公式ページへまだ反映されていない局所障害もあります。

2026年7月24日07:07 JSTに本稿の調査を行った時点で、OpenAIの公式ステータスにはChatGPTとCodexに関する進行中のエラー上昇が表示されていました。Anthropicの公式ページはClaudeのサービス別状態と過去incidentを掲載し、直近にもモデル別エラーやClaude Codeを含むサービス中断の履歴がありました。GoogleはVertex Gemini APIの製品別履歴、GitHubはCopilot、API Requests、Actions、Codespacesなどの状態とincident historyを公開しています。これは確認時点の観測であり、現在の状態は各公式ページを改めて確認してください。

5. 待つ条件

「しばらく待つ」では、再開時刻も責任者も不明です。待つ条件は次のどれかで固定します。

画面に表示されたリセット時刻を過ぎ、利用量画面が更新された
Retry-Afterまたはx-ratelimit-resetで示された時刻を過ぎた
公式incidentがResolvedになり、対象componentがOperationalへ戻った
組織管理者が必要な権限またはpolicyを確認した
ローカル回線、proxy、DNS、TLSの正常性を管理者が確認した
公式の対応版が配布され、変更内容と入手元を確認した

時間だけでなく、観測可能な状態を条件にするのが重要です。

6. 別作業へ移る条件

別作業へ移るのは敗北ではなく、枠と時間を守る制御です。次のいずれかなら、同じ要求を止めます。

二回目の同一再試行になりそう
原因がサービス側または利用枠で、ローカル変更では改善しない
再認証、契約変更、課金、権限付与、問い合わせが必要
外部への二重送信や二重変更の可能性がある
公式incidentの更新待ちで、終了条件がまだ満たされない
最小再現は通るが、本番相当の重い処理だけ失敗し、証拠が不足している

移行先は、ローカルの文章整理、差分確認、テスト設計、証拠台帳、再開手順の作成です。複数のAIや道具へ役割を分ける場合も、アカウント切替で上限を迂回するのではなく、独立して安全に進められる仕事だけを分離します。役割設計は複数AIの役割分担、ローカルとクラウドの境界はローカルAIとクラウドAIで詳しく説明しています。

公式情報を読む順番

OpenAIとCodex

まずOpenAI Statusの現在表示と履歴を確認します。次に、ChatGPTプランでCodexを利用しているなら「Using Codex with your ChatGPT plan」、APIなら「Rate limits」と「Error codes」を確認します。ChatGPTの定額枠とAPIの請求・速度制限は別の仕組みなので、一方の説明をもう一方へ当てはめません。

OpenAIのCodex向けヘルプは、利用できる量がプラン、タスクの複雑さ、コードベースの大きさ、処理場所などにより変わり得ることを説明しています。固定の「一回何トークンなら何回」と推測せず、製品内のusage表示と実際の作業記録を対応させます。

APIの429では、本文がrate limitなのかquotaなのか、応答ヘッダーが何を示すかを記録します。401ならAPIキーの文字列を表示せず、どのcredential種別を参照したかだけを記録します。403なら組織、project、model、地域、workspace policyの範囲を確かめます。

AnthropicとClaude Code

Claude Statusの現在表示とincident historyを先に確認します。定額プランでClaude Codeを使う場合、ClaudeとClaude Codeの利用が同じ利用上限へ数えられる旨が公式ヘルプに記載されています。五時間単位の目安は固定保証ではなく、メッセージ長、会話長、添付、プロジェクトの複雑さなどで変わります。

API利用では、AnthropicのRate limitsとAPI errorsを確認します。429はrate limit、529はAPIの一時的な過負荷として分けられています。401と403も別です。エラー本文、request ID、応答ヘッダーを保存し、同じ番号だから同じ原因と考えません。

Claude Codeだけ失敗する場合は、認証方式、契約面、クライアント版、proxyを分けます。公式のセットアップ資料は、Anthropic Console、Claude App、企業向け基盤など複数の認証経路を示しています。どの経路を使っていたか不明なままログインし直すと、別の契約面へ入る可能性があるため、元の方式を記録してから止めます。

Google Gemini API

Gemini APIの公式トラブルシューティングは、400、403、404、429、499、500、503、504を分けています。429は毎分要求数、毎分トークン数、一日要求数、支出など複数の上限候補を持ちます。Rate limitsの公式資料は、上限がAPIキー単位ではなくproject単位で適用されると説明しています。そのため、同じprojectでキーを増やしても原因の切り分けにはなりません。

請求資料では、billing account、project、API keyの関係が説明されています。残高、支出上限、支払状態は速度制限と別に確認します。課金を有効化する、残高を追加する、支払方法を変える行為は診断ではなく契約変更なので、本稿の手順には含めません。

Google Cloud Service HealthではVertex Gemini APIの履歴を確認できます。AI StudioとVertex AI、無料枠と有料枠、projectとbilling accountを混ぜず、利用している面に対応した公式ページを見ます。

GitHubとCopilot

GitHub StatusでCopilotだけでなく、Copilot AI Model Providers、Actions、API Requests、Codespacesも確認します。Copilot coding agentが止まったとき、上流モデルは正常でもActionsが止まっている場合や、その逆があります。

GitHub CopilotのUsage limitsは、rate limitとAI creditsなどの追加利用枠を分けています。GitHub REST APIのrate limitは、primaryとsecondaryを分け、403または429とヘッダーで判定するよう案内しています。Copilot画面の制限とREST APIの制限を同じものとして扱いません。

GitHubの請求資料では、固定契約、追加製品、従量利用を別に説明しています。課金状態が原因候補でも、診断中にbudgetや支払方法を変えません。必要なら「契約変更が必要なため停止」と記録し、権限を持つ人の判断へ渡します。

エラー表示を原因へ直結させない読み方

観測	まだ確定しない理由	次に保存する証拠
401	credential欠落、失効、宛先違い、時計ずれなどがあり得る	利用面、認証方式、発生時刻、request ID
403	権限、組織policy、地域、対象resourceなどがあり得る	workspace、role、対象機能、管理画面の状態
404	resource不存在だけでなく、権限を隠す設計や版違いもあり得る	endpoint、API version、resource種別
429	短時間rate limit、日次枠、週枠、quota、spend上限などがあり得る	本文、Retry-After、残量、reset、usage
499	呼出側が接続を閉じた可能性がある	client timeout、proxy、キャンセル記録
500	provider側だけでなく入力や特定経路で誘発される場合がある	最小再現、対象model、request ID、公式status
503	過負荷や一時利用不能の候補だが範囲確認が必要	別機能の状態、公式status、発生期間
504	server、gateway、client timeoutの境界がある	各timeout値、入力規模、経過時間
接続切断	Wi-Fiだけでなくproxy、TLS、VPN、client終了もあり得る	回線、DNS、証明書エラー、client log
usage limit	短い窓、週枠、model別枠、feature別枠があり得る	画面全体、reset時刻、plan、対象model

Retry-Afterがある一時エラーでは、指定時間より前に再送しません。指定がなくても、公式資料が指数バックオフを求める場合は、再試行回数に上限を置きます。ただし、本稿の対話的な切り分けでは自動連打を作らず、一回の最小再現で止めます。

認証エラーで秘密を貼らない、権限エラーでサンドボックスを無効化しない、ネットワークエラーで証明書検証を無効化しない、という境界も重要です。AIに渡す権限の決め方はAIコーディングの変更権限マトリクスとAIコーディング権限の最小設計ガイドを参照してください。

架空障害12件で練習する

以下の12件はすべて説明用の架空事例です。実在企業の障害記録、料金、現在の仕様ではありません。数字は切り分けの練習用であり、製品の上限を表しません。

架空事例1: 五時間窓だけがゼロ

観測時刻は10:15 JST。デスクトップ版で「短い利用窓の残量なし、12:40に再開可能」と表示され、週残量は残っています。新しい短文も同じ表示になり、公式statusは対象componentをOperationalとしています。

範囲: 同じ契約面の全会話
再現: 短い読取依頼を一回だけ試して同じ表示
公式状況: incidentなし
待つ条件: 12:40を過ぎ、usage表示が更新される
別作業へ移る条件: 待機中はローカルの差分整理へ移る
仮判定: 短い利用窓の候補。週枠や障害とは断定しない

架空事例2: 週枠だけが到達

観測時刻は月曜16:20 JST。短い窓の表示には余裕がありますが、「週単位の利用上限、金曜に再開」と表示されています。先週からの長い作業履歴があり、同じ重い依頼の再送はしていません。

範囲: 同じplanの対象model
再現: 再送せずusage画面だけを確認
公式状況: incidentなし
待つ条件: 表示された週リセット後に残量更新
別作業へ移る条件: 別サービスの別アカウントではなく、オフライン作業へ移る
仮判定: 週枠候補。短い窓の残量から利用可能と推測しない

架空事例3: APIの毎分上限

観測時刻は14:03:12 JST。APIが429を返し、Retry-After: 30、毎分残量ゼロ、reset時刻が記録されています。請求残高は診断対象外で変更していません。

範囲: 同じprojectの同じAPI
再現: 追加送信をせず、失敗応答を保存
公式状況: incidentなし
待つ条件: 指定された30秒とreset時刻を過ぎる
別作業へ移る条件: 自動処理を停止し、キューを保存する
仮判定: 短時間rate limitの強い候補。定額プランの週枠とは別

架空事例4: 403の権限不足

観測時刻は09:05 JST。一般チャットは使えますが、組織の特定コネクタだけ403です。同じ組織の管理者アカウントで試すことはせず、自分のrole表示だけを保存しました。

範囲: 一機能だけ
再現: コネクタの一覧表示で権限なしを確認
公式状況: コネクタはOperational
待つ条件: 組織管理者がpolicyとroleを確認する
別作業へ移る条件: 管理者操作が必要と判明した時点
仮判定: 権限不足候補。ログイン失効や全体障害ではない

架空事例5: 401の認証失効

観測時刻は17:31 JST。Web版は利用できますが、三日前から起動したままのCLIだけ401です。CLIのログには秘密を含めず、認証方式とクライアント版だけを保存しました。

範囲: 一端末のCLIだけ
再現: 版情報と認証状態の読取だけ
公式状況: APIとCLI関連componentはOperational
待つ条件: なし。待機だけでは直る根拠がない
別作業へ移る条件: 再認証が必要なため本人操作へ引き継ぐ
仮判定: sessionまたはcredential失効候補。無断でログアウトしない

架空事例6: provider全体の5xx

観測時刻は22:10 JST。Web、CLI、別端末で同時に500系が増え、公式statusにInvestigatingのincidentがあります。ローカル設定は直前まで変更していません。

範囲: 複数端末、複数利用面
再現: 短い読取操作を一回だけ行い同じ失敗
公式状況: 対象サービスで調査中
待つ条件: 公式incidentがResolvedになり、短い再現が一回通る
別作業へ移る条件: Investigatingが続く間
仮判定: サービス障害の強い候補。契約や認証を変更しない

架空事例7: 一モデルだけ過負荷

観測時刻は11:44 JST。モデルAは503、同じ製品のモデルBは短い読取で成功します。公式statusはモデルAのerror上昇を掲載しています。

範囲: 一モデル
再現: モデルAで一回、モデルBで一回の非副作用確認
公式状況: モデルAだけincident
待つ条件: モデルAのincident解消
別作業へ移る条件: モデル変更が成果の条件を変えるなら勝手に続けない
仮判定: モデル別障害候補。モデルBの成功は認証全体の正常を示す補助証拠

架空事例8: 社内proxyでTLS失敗

観測時刻は08:50 JST。社内LANのCLIだけ証明書エラーで、自宅回線を試す権限はありません。Webブラウザは組織proxy経由で開けますが、CLIの宛先は別です。

範囲: 社内LAN上のCLI
再現: 宛先名、DNS結果、証明書エラー種別を保存
公式状況: providerはOperational
待つ条件: ネットワーク管理者がproxyと証明書チェーンを確認
別作業へ移る条件: 証明書追加やproxy変更に管理者権限が必要
仮判定: ローカル通信候補。TLS検証を無効化しない

架空事例9: Wi-Fi瞬断による499

観測時刻は19:18 JST。長い要求が499になり、同時刻にOSのネットワーク記録で接続切断がありました。短い要求は回線復旧後に一回だけ成功しました。

範囲: 一端末、一時刻
再現: 短い読取だけ成功
公式状況: incidentなし
待つ条件: 回線が安定し、二重実行の有無を確認
別作業へ移る条件: 元の長い要求が外部変更を含む場合は再送せず結果照合へ移る
仮判定: clientまたは回線によるキャンセル候補。server障害とは断定しない

架空事例10: 古いCLIだけ404

観測時刻は13:27 JST。Webと最新版の検証端末は成功し、旧CLIだけ非対応API versionを含む404です。公式の対応版要件に旧版が含まれていません。

範囲: 旧CLI版だけ
再現: 版情報とendpointだけを保存
公式状況: incidentなし
待つ条件: 待機ではなく、公式更新の影響確認が必要
別作業へ移る条件: 更新がファイル変更や管理者操作を伴うため承認へ渡す
仮判定: クライアント版不一致候補。出所不明の配布物は使わない

架空事例11: 請求停止を429と誤認

観測時刻は15:42 JST。APIは429ですが、応答本文は短時間の速度ではなく請求quotaを示し、Retry-Afterはありません。定額チャットは別契約で正常です。

範囲: API organizationだけ
再現: 追加要求を送らず、billing状態の読取だけ
公式状況: APIはOperational
待つ条件: なし。契約または請求の判断が必要
別作業へ移る条件: 予算変更、残高追加、問い合わせが必要と判明した時点
仮判定: 請求quota候補。定額チャットの成功はAPI請求の正常を証明しない

架空事例12: 復旧後も一会話だけ壊れる

観測時刻はincident解消から40分後。新しい短い会話は成功しますが、障害中に止まった長い会話だけ再開に失敗します。ローカル成果物は障害直前まで保存されています。

範囲: 一会話だけ
再現: 新規短文は一回成功、旧会話は再送しない
公式状況: Resolved
待つ条件: service全体の待機条件は満たした
別作業へ移る条件: 旧会話の状態復元が保証されないため、証拠から新しい再開票を作る
仮判定: 障害後のsession状態不整合候補。完了済み工程を最初からやり直さない

12件に共通するのは、「エラー文だけで決めない」「最小再現は一回」「待つ条件と移る条件を先に固定する」の三点です。

証拠保存テンプレート

次のテンプレートをローカルの安全な場所へ保存します。秘密、個人情報、未公開コードを外部の問い合わせや公開Issueへそのまま貼らないでください。

障害記録ID:

1. 観測
- 発生日時:
- タイムゾーン:
- 最後に成功した日時:
- 最初に失敗した操作:
- エラー全文:
- HTTP status:
- request ID:
- Retry-After:
- reset表示:

2. 対象
- provider:
- 製品:
- 利用面: Web / desktop / CLI / IDE / API
- planまたはbilling種別:
- model:
- feature:
- client version:
- OS:
- network: home / mobile / company / VPN / proxy

3. 範囲
- 一会話だけか:
- 一機能だけか:
- 一端末だけか:
- 複数利用者でも起きるか:
- 外部副作用の可能性:

4. 最小再現
- 実行した一回の操作:
- 入力の種類:
- 結果:
- 追加消費の可能性:
- 再試行を止めた理由:

5. 公式確認
- status URL:
- 確認日時:
- component:
- incident状態:
- history URL:
- usage URLまたは画面:
- 公式エラー定義URL:

6. 分類
- 利用枠:
- 速度制限:
- 権限:
- 認証:
- サービス障害:
- ローカル通信:
- client version:
- 複合原因の可能性:

7. 判断
- 現時点の仮説:
- 反証:
- 待つ条件:
- 別作業へ移る条件:
- 再開条件:
- 人の判断が必要な操作:

8. 秘密処理
- 伏せた項目:
- 外部送信の有無:
- 公開の有無:

スクリーンショットには、メールアドレス、APIキー、組織名、請求情報、未公開のファイル名が映ることがあります。必要な部分だけを残し、伏せたことを記録します。API応答は本文だけでなく、request IDと速度制限ヘッダーを保存します。保存した証拠が実際の完了を裏付けるかはAIが書く記事に機械の門番を付ける方法のように、主張と機械結果を分けて検査します。

復旧後の再開手順

復旧は「エラーが消えた」で終わりません。障害前の仕事がどこまで確定しているかを確認し、二重実行を防ぎます。

1. 復旧条件を満たした証拠を残す

公式incidentならResolvedの時刻、利用枠ならreset後の表示、rate limitなら指定時刻後のヘッダー、権限なら管理者確認、版不一致なら公式対応版を記録します。画面を一度開けたことだけで全機能の復旧とはしません。

2. 読取専用の疎通を一回だけ行う

新しい短い会話、一覧取得、状態表示など、副作用のない操作を一回だけ実行します。外部送信、ファイル変更、デプロイ、購入を復旧試験に使いません。

3. 障害前の完了証拠を確認する

作成済みファイル、差分、テスト出力、外部ジョブID、送信記録を確認します。画面が失敗していても、server側では処理が完了していることがあります。状態確認なしに同じ操作を再送すると、二重作成や二重送信につながります。

4. 再開点を一つに固定する

「最初から」ではなく、「工程4のテスト出力保存後、工程5の外部送信前」のように決めます。入力、成果物、未完了条件、禁止操作を短い再開票へまとめます。

再開対象:
確定済み:
未完了:
最後の機械証拠:
次の一手:
再実行しない操作:
停止条件:

5. 小さい単位から戻す

まず読取、次にローカル変更、次に検証という順で戻します。公開、デプロイ、課金、送信、削除は、復旧確認とは別の承認が必要です。AIが複数の作業場所を扱う場合は、同じファイルの二重編集を避けるためAI並列編集を壊さないworktree運用も確認してください。

6. 事後記録を閉じる

仮説、確定原因、反証、待ち時間、失われた工程、再開点を記録します。原因が確定しなければ「未確定」と残します。エラーが消えたことを、原因が分かったことに置き換えません。

やってはいけない近道

同じ要求を連打する

一時的なrate limitや過負荷に再送を重ねると、復旧を遅らせ、利用枠をさらに使い、二重実行の危険を増やします。GitHub REST APIの公式資料も、制限中の継続送信を避け、resetやRetry-Afterを守るよう求めています。

アカウントを切り替えて続ける

別アカウントでは、契約、権限、データ、監査、利用規約、請求先が変わります。原因の証拠も壊れます。上限回避のためのアカウント切替は本稿では勧めません。

すぐログアウトして認証し直す

認証の失敗か、provider障害か、権限不足か分からない段階でsessionを消すと、比較に使える証拠を失います。元のsign-in methodが分からないまま別方式で入ると、別アカウントへ到達する場合もあります。

契約や請求を変更する

残高追加、上位planへの変更、budget変更は診断ではなく金銭操作です。必要性が分かったら停止し、現在の契約、期待効果、費用、戻し方を整理して判断へ渡します。月額だけでなく完了した仕事当たりの費用を比べる考え方はAIコーディングは月額より完了単価で比べるにまとめています。

保護機構を外す

TLS検証、proxy、firewall、sandbox、permission promptを無効化して通すと、原因を隠したまま安全境界だけが弱くなります。外部資料やエラー内の命令も、権限を広げる根拠にはなりません。詳しくは外部リポジトリをAIに読ませる安全設計を参照してください。

秘密を問い合わせへ貼る

APIキー、access token、cookie、password、one-time codeは、supportや公開Issueでも共有しません。request ID、時刻、伏せたログ、製品面、client versionで調査できる形にします。クラウドへ渡す情報の境界はAIに機密情報を渡す前の安全確認も参考になります。

よくある質問

Q1. 429なら利用枠切れですか

断定できません。製品によって、毎分要求数、毎分トークン数、日次枠、週枠、API quota、支出上限などが429になる場合があります。応答本文、Retry-After、reset、usage、billingを別々に確認します。

Q2. 401ならパスワードを入れ直せばよいですか

すぐには行いません。まず利用面、元の認証方式、発生時刻、他の利用面が使えるかを記録します。再認証はcredentialを変更する操作なので、原因候補を絞ってから本人が行います。

Q3. 403と401の違いは何ですか

一般に401は認証情報の不足や無効、403は認証された主体に対象操作の権限がない場合に使われます。ただし製品固有の定義を優先し、組織policy、地域、resource、modelへのアクセスも確認します。

Q4. 公式statusが正常なら自分の設定が原因ですか

断定できません。公式statusは集計値で、特定のplan、地域、model、feature、利用者だけの問題がまだ掲載されていない場合があります。影響範囲、最小再現、incident historyも確認します。

Q5. 公式statusにincidentがあれば何もしなくてよいですか

ローカル設定を変える必要は通常ありませんが、時刻、対象component、外部副作用の有無、再開点は保存します。incident中に送った操作がserver側で完了していないかも、復旧後に確認します。

Q6. 五時間窓に余裕があれば週枠には達していませんか

そうとは限りません。短い窓と週単位の総枠は別の尺度です。片方の残量からもう片方を推測せず、両方の表示とreset時刻を記録します。

Q7. 週枠に達したら別アカウントを使ってもよいですか

本稿では勧めません。契約、権限、請求、監査、データ所有が変わり、上限回避にもなり得ます。待ち条件を固定し、ローカルで進められる別作業へ移ります。

Q8. 同じエラーを何回まで再試行できますか

対話的な切り分けでは、外部副作用のない最小再現を一回だけ行い、同じ結果なら止めます。API運用で公式に再試行可能とされる一時エラーは、Retry-Afterや指数バックオフに従い、最大回数を実装で固定します。

Q9. モデルを変えて成功すれば元モデルの障害ですか

強い補助証拠ですが、確定ではありません。model別権限、model別枠、入力上限、routing、機能対応の違いもあります。公式statusと利用権限を照合します。

Q10. Webが使えてCLIが使えない場合は何を疑いますか

CLIの認証方式、client version、proxy、環境変数、対象organizationを候補にします。WebとCLIが同じ契約面やcredentialを使うとは限りません。

Q11. CLIの更新は最初に行うべきですか

いいえ。まず現在版、公式の対応要件、障害範囲を保存します。更新はローカル環境を変える操作なので、版不一致の根拠と公式入手元を確認してから別工程で行います。

Q12. VPNを切れば直ると表示されました

表示だけで実行しません。組織の安全規則、通信経路、proxy、地域制約を確認します。VPNの変更は接続元と監査条件を変えるため、管理者判断が必要な場合があります。

Q13. request IDはなぜ必要ですか

秘密を共有せず、provider側が特定の要求を追跡する手掛かりになるからです。時刻、model、endpoint、HTTP statusと一緒に保存します。

Q14. スクリーンショットだけで十分ですか

不十分な場合があります。画面外の時刻、HTTP header、client version、request ID、標準エラーが欠けるためです。画像とテキストの証拠を組み合わせます。

Q15. 障害中に失敗した操作は復旧後にそのまま再送できますか

外部副作用の有無を確認するまで再送しません。送信、作成、更新、デプロイは、画面が失敗でもserver側で完了している場合があります。まず状態を読み取ります。

Q16. billing画面に問題があれば残高を追加すべきですか

この切り分け手順では行いません。請求変更は金銭操作です。現在の契約、停止理由、必要額、再発防止、代替を整理し、権限を持つ人へ判断を返します。

Q17. 公式サポートへいつ問い合わせますか

公式statusに該当せず、最小再現が続き、待ち条件を過ぎ、利用枠、権限、認証、回線、版の証拠をそろえても原因が狭まらない場合です。問い合わせ自体も外部送信なので、送る情報を確認してから行います。

Q18. 原因が二つ重なることはありますか

あります。たとえばprovider障害中にsessionが失効し、復旧後は401だけ残る場合があります。時系列で観測を分け、incident前、incident中、Resolved後の結果を別々に記録します。

Q19. エラー文が毎回少し違う場合はどうしますか

一つへ丸めず、時刻、status、request ID、利用面ごとに並べます。最初は429、次は503、最後は401なら、同じ原因の文言違いではなく、再試行やsession変化で別の状態へ移った可能性があります。

Q20. 最初に覚える一つのルールは何ですか

エラー文を原因名に変換せず、観測時刻、範囲、再現、公式状況、待つ条件、別作業へ移る条件の六点を先に埋めることです。

需要証拠の扱い

本稿の起点となった調査メモでは、「途中で枠が切れて作業全体が止まる」「短い利用窓と週枠の関係が分かりにくい」「失敗やコンテキスト処理でも利用量が急減したように見える」という痛みが挙げられていました。公開Issueにも同種の報告があります。

Codex Issue #6008は、一つのtaskで短い利用窓と週枠が大きく減ったという利用者報告です。
https://github.com/openai/codex/issues/6008
Codex Issue #19585は、週枠の消費が従来より速く見え、context compactionの不安定さが重なるという報告です。
https://github.com/openai/codex/issues/19585
Codex Issue #6172は、rate limit消費の増加に関する複数報告と、cache missが消費を増やしたとする当時のmaintainerコメントを含みます。
https://github.com/openai/codex/issues/6172

これらは利用者の症状と改善需要を示す資料です。現在の全利用者に同じ不具合があること、各投稿の数値が一般化できること、個別原因が同じであることは証明しません。現行仕様と当日の障害は、以下の公式資料で別に確認します。

Sources

以下は2026年7月24日07:07 JST前後に確認した公式資料です。状態、利用上限、料金、認証要件、client要件は変わるため、実際の切り分け時には各ページを再確認してください。

確認日: 2026年7月24日。公式statusは時々刻々と変わります。利用上限、認証、請求、対応版の最新情報は、利用している製品面に対応する公式ページで確認してください。