OpenAIの401エラーは認証の問題ですが、必ずしも同じ原因を意味するわけではありません。最も迅速な修正方法は、リクエストのホスト名を特定し、実行中のプロセスが実際に読み込んだシークレットを確認してから、エラーボディを使用して、誤ったキー、失効したキー、ゲートウェイ認証情報の不一致、IP許可リストによるブロックを区別することです。
リクエストが失敗したためにOpenAI APIキーの取得方法を検索している場合は、同じ設定に新しいシークレットをむやみに貼り付けないでください。まず、リクエスト先がapi.openai.comなのか、OpenAI互換ゲートウェイなのかを確認してください。これら2つのエンドポイントでは、異なる認証情報が必要になることがあります。
完全なAPIキーをチケット、チャット、スクリーンショット、ログ、またはこのチェックリストに貼り付けないでください。代わりに、安全に導出したフィンガープリントまたはプロバイダーに表示されるマスク済みの末尾を比較してください。
「invalid API key」とは何を意味しますか？
これは、リクエストを受信したサービスが、そのリクエストで提示された認証情報を認証できなかったことを意味します。OpenAIへの直接リクエストの場合、公式エラーとしてIncorrect API key providedと表示されることがあります。OpenAIが最初に確認する項目は、エラー内のマスク済みキーと意図したキーを比較すること、アプリケーションが2つのキーを切り替えていないことを確認すること、必要な場合に正しい組織設定を確認することです。OpenAIの誤ったキーに関するガイダンスは、この正確なメッセージに関する信頼できる情報源です。
HTTPステータスだけでは原因を診断するのに十分ではありません。たとえば、OpenAIは、IP許可リストによってブロックされたリクエストでは、有効なキーであってもip_not_authorizedエラータイプとともにHTTP 401が返されると説明しています。何かをローテーションする前に、エラーボディを読んでください。OpenAIのIP許可リストガイドで違いを確認できます。
5分間の診断チェックリスト
以下のチェックを順番に実施してください。証拠が原因を示した時点で停止してください。一度に複数の変更を行うと、修正が機能したことを証明しにくくなります。
| チェック項目 | 安全に確認する内容 | 考えられる結論 | 次の対応 |
|---|---|---|---|
| 1. リクエストホスト | リダイレクト後のホスト名（例：api.openai.comとゲートウェイドメインの比較） |
OpenAIの直接キーが別のプロバイダーに送信された、またはその逆 | エンドポイント運営者が発行した認証情報を使用する |
| 2. 正確なエラーボディ | エラーメッセージ、type、code。完全なシークレットは決して含めない |
誤ったキー／失効キー、IPブロック、またはプロバイダー固有の認証ルール | ボディに一致する以下の分岐に従う |
| 3. 実行時のシークレットソース | プロセス環境、デプロイ用シークレット参照、CIシークレット名、またはコンテナリビジョン | 古い、空の、切り詰められた、または引用符付きの値がまだ実行されている | アクティブなシークレットソースを更新し、意図的に再起動／再デプロイする |
| 4. キーのライフサイクル | キーが削除、失効、漏洩、または有効期限設定されているか | 元のキーはもはや認証できない | 代替キーを作成し、安全にローテーションする |
| 5. プロジェクトと権限 | プロジェクトメンバーシップ、意図したプロジェクト、キーの権限 | キーは存在するが、リクエストに必要なアクセス権がない | 意図したプロジェクトキーを使用するか、所有者にアクセス調整を依頼する |
| 6. ネットワーク制御 | 送信元IPとOpenAI IP許可リストの設定 | ip_not_authorizedまたはインフラストラクチャIPの変更 |
許可リストを更新し、再テスト前に反映時間を確保する |
1. キーに手を加える前にエンドポイントを確認する
SDKに設定可能なbase_urlがある場合、これは最も重要な確認項目です。
https://api.openai.com/...へのリクエストには、OpenAI API認証情報が必要です。- ゲートウェイまたはプロキシへのリクエストには、そのゲートウェイがドキュメントで指定する認証情報と認証形式が必要です。
- コード上では「OpenAI互換」に見えるリクエストでも、実際にはOpenAI以外のホストに送信されている場合があります。
OpenAI APIキーの取得方法が関係するのは、リクエストが実際にOpenAIに送信されていることを確認した後です。ホストがゲートウェイである場合、新しいOpenAIキーを作成しても、そのゲートウェイからの401は修正されません。設定済みホスト名、SDKのベースURL、デプロイ変数、プロキシ設定を比較してください。その際、Authorizationヘッダーをログに出力しないでください。
マルチモデルルーティング構成では、エンドポイントとキーの設定をまとめて管理してください。より包括的なOpenAI互換APIのトラブルシューティングガイドでは、この直接認証情報テストが成功した後に、ベースURL、モデル名、ストリーミング、ルーティング固有のチェックを扱っています。
2. アプリケーションが意図した1つのシークレットを読み込んでいることを確認する
「invalid API key」エラーの一般的な原因は、ありふれた設定ミスです。
- ローカルPCには存在していても、実行中のプロセスでは
OPENAI_API_KEYが未設定になっている。 - デプロイが古いシークレットバージョンをまだ参照している。
- 実際にリクエストを行う環境では
.envファイルが読み込まれていない。 - 値に意図しない引用符、空白、改行、またはコピーしたプレースホルダーが含まれている。
- あるコードパスではライブラリのデフォルトを使用し、別のコードパスではキーまたはベースURLを上書きしている。
非可逆のフィンガープリントを非公開のデバッグ環境で使用してください。これにより、シークレットそのものを出力せずに、異なるプロセスがどのシークレットを読み込んだかを比較できます。
import crypto from "node:crypto";
const key = process.env.OPENAI_API_KEY?.trim();
if (!key) {
throw new Error("OPENAI_API_KEY is not set in this process");
}
const fingerprint = crypto
.createHash("sha256")
.update(key)
.digest("hex")
.slice(0, 12);
console.info({ keyConfigured: true, keyLength: key.length, fingerprint });
ローカル開発、CI、ステージング、ワーカー、本番環境間でフィンガープリントを比較してください。完全なキーを比較または保存してはいけません。
3. 同じランタイム環境で直接リクエストをテストする
失敗しているのと同じマシン、コンテナ、またはジョブから最小限のリクエストを実行します。これにより、認証情報の読み込みとアプリケーションロジックを切り分けられます。次のコマンドでは標準のBearerヘッダーを使用しますが、意図的にキーは環境変数に残しています。
curl https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
結果は慎重に解釈してください。
- 同じランタイムで同じ401が発生する場合は、認証情報、エンドポイント、組織/プロジェクト設定、またはネットワークポリシーに原因があることを示します。
- 応答が成功する場合は、アプリケーション設定に原因があります。たとえば、異なるランタイム、ベースURLのオーバーライド、クライアントの重複作成、または異なる環境変数です。
ip_not_authorized応答はIP許可リストの問題であり、キーテキストが無効である証拠ではありません。
このテストをブラウザからのリクエストで置き換えないでください。OpenAIは、APIキーが露出して他者に使用される可能性があるため、ブラウザやモバイルアプリにAPIキーをデプロイしないよう勧めています。代わりに、自身のバックエンド経由でリクエストを送信してください。理由については、OpenAIのAPIキーの安全性に関するガイダンスを参照してください。
4. キーが取り消し、削除、漏洩、または期限切れになっていないか確認する
OpenAI APIシークレットは、作成時にのみ完全な値が表示されます。シークレットを保存していなかった場合、ダッシュボードから復元することはできません。新しいキーを作成し、アプリケーションを更新してください。削除したキーは使用できません。OpenAIのキー管理に関する記事では、これら両方の動作が確認されています。
インシデントからの復旧ではなく新しい統合をセットアップする場合は、より幅広いセットアップ、セキュリティ、運用チェックリストについて、付属のOpen AI APIキー本番環境ガイドを使用してください。
次の事象が発生した場合は、無期限に再試行するのではなく、ローテーションを行うべきです。
- キーが削除された、または意図的に取り消された。
- キーがリポジトリにコミットされた、メッセージで送信された、クライアントアプリに埋め込まれた、またはその他の方法で漏洩した可能性がある。OpenAIは、公開インターネット上で検出したキー、またはアプリストアのアプリ内で漏洩したキーを無効化すると述べています。
- プロジェクトキーが有効期限付きで作成され、その日付を過ぎている。
- 計画されたローテーション後も、デプロイが以前のキーを参照している。
置き換える場合は、対象のプロジェクトで新しいキーを作成し、正しいシークレットストアに書き込み、デプロイして、最小限のリクエストを1回確認してから、古いキーを取り消してください。OpenAIは有効期限の設定と定期的なローテーションプロセスを推奨しており、チームで認証情報を共有するのではなく、個別のキーを使用することも推奨しています。最新の安全性に関する推奨事項を確認する。
5. プロジェクトメンバーシップとキーの権限を確認する
キーを作成または確認できてもチームのワークロードが依然として失敗する場合は、シークレットの形式が不正だと想定する前に、プロジェクト境界を確認してください。OpenAIプロジェクトでは、APIキー、メンバー、サービスアカウント、モデルアクセス、利用上限を管理します。ユーザー所有キーには、フル、制限付き、または読み取り専用の権限を設定できます。利用可能な制御については、OpenAIのプロジェクトガイドを参照してください。
次の質問を確認してください。
- キーは、アプリケーションのリソースおよび想定される用途と同じプロジェクトのものですか？
- サービスアカウントまたはユーザーは、まだそのプロジェクトのメンバーですか？
- キーには、その呼び出しに必要なエンドポイント/リソース権限がありますか？
- エラーで組織が特定されている場合、クライアントは古い組織ではなく、意図した組織用に設定されていますか？
権限およびプロジェクトの問題では、Incorrect API key provided とは異なる、より具体的なメッセージまたはステータスコードが表示される場合があります。推測するのではなく、エラーのリクエストIDとサニタイズ済み本文を、プラットフォーム所有者またはOpenAI Supportのために保持してください。
6. 有効なキーをローテーションする前にIP許可リストを除外する
OpenAI組織では、APIトラフィックを承認済みIP範囲に制限できます。それ以外のアドレスからのリクエストは、認証情報自体が有効であっても、HTTP 401および ip_not_authorized で拒否されます。そのため、これは特に誤診しやすい401です。
エラータイプが ip_not_authorized の場合：
- 開発者のノートPCのパブリックIPではなく、ワークロードの実際の送信元IPを特定します。
- 設定済みの許可リストと比較し、クラウドNAT、サーバーレスの送信元アドレス、またはプロキシが変更されていないか確認します。
- 適切な組織コントロールを通じて、許可する範囲を更新します。
- 最小限のテストを再実行する前に、ドキュメントに記載された反映待ち時間を確保します。
この原因が否定されるまで、キーは変更しないでください。有効なキーをローテーションしても、インシデントに2つ目の変数が加わるだけです。
401の後にOpenAI APIキーを取得する方法
証拠から認証情報が欠落、削除、漏洩、または期限切れであることが示された場合は、次の短い復旧フローに従ってください。
- 対象の組織とプロジェクトでOpenAI APIキーページを開きます。
- ワークロードに適した最小限のアクセス権を持つ新しいシークレットキーを作成します。
- サーバー側のシークレットマネージャーまたはデプロイメントシークレットに直接保存します。ブラウザーコード、コミットされた
.envファイル、共有ドキュメントには保存しないでください。 - まず1つの環境を更新し、最小限の直接リクエストを実行します。
- 残りの環境にも変更を展開し、想定どおりにフィンガープリントが変更されたことを確認します。
- 置き換え後のキーを検証してから、以前のキーを無効化します。ただし、古いキーが漏洩している場合は、直ちに無効化し、使用状況を調査してください。
これは復旧のためにOpenAI APIキーを安全に取得する方法です。チームメイトや環境間で1つのキーを共有する理由にはなりません。プロジェクト／ユーザーごと、またはサービスアカウントごとに別々の認証情報を使用し、将来の401の影響範囲を小さくしてください。
ゲートウェイ固有の401では別の問いが必要
コードベースでカスタムbase_urlを使用するOpenAI互換SDKを利用している場合、まず次を確認してください。リクエストを受信したサービスはどれか？ ゲートウェイは、OpenAIに上流リクエストを送信する前に独自の401を返すことがあります。その場合は、ゲートウェイ自身のドキュメントで、ゲートウェイの認証情報、テナント／ワークスペース、APIベースURL、モデル識別子を検証してください。
リクエストが認証されたら、対象を絞った互換ルーターの設定についてはFlatkey APIクイックスタートを使用するか、モデル、ストリーミング、ベースURLの確認についてはOpenAI互換APIトラブルシューティングガイドに戻ってください。将来のインシデントで試行錯誤ではなく設定から明らかに判断できるよう、直接用のOpenAIキーとゲートウェイキーは別々の名前のシークレット変数に保存してください。
インシデントをクローズする前に
- [ ] ホスト名と
base_urlが認証情報の発行元と一致している。 - [ ] 本番プロセスが想定したシークレットのフィンガープリントを読み込んでいる。
- [ ] キーが削除、無効化、漏洩、期限切れになっていない。
- [ ] プロジェクトメンバーシップとキー権限がワークロードに対して正しい。
- [ ]
ip_not_authorizedが原因から除外されている、または許可リストが更新されている。 - [ ] 最小限のリクエストが障害の発生していたランタイムから成功する。
- [ ] 完全な認証情報がログ、ソース管理、チケット、チャットに表示されていない。
- [ ] 古いキーは漏洩していた場合を除き、置き換え後のキーを検証してから無効化された。
OpenAI APIキーの取得は有用なセットアップ作業ですが、ホスト、シークレットのソース、ライフサイクル、ネットワークポリシーを診断することこそが、401の修正を永続的な本番環境の修復に変えます。
よくある質問
OpenAIでinvalid API keyとはどういう意味ですか？
リクエストを処理するサービスが、提示された認証情報を認証できなかったことを意味します。正確にIncorrect API key providedというメッセージが表示される場合は、意図したキーとエラー内でマスクされた値を比較し、アプリが2つのキーを使用していないこと、および正しい組織設定を確認してください。ip_not_authorizedなど異なるエラータイプは、別の原因を示します。
古いOpenAI APIキーが使えなくなった場合、新しいキーを取得するにはどうすればよいですか？
対象のOpenAIプロジェクトで新しいシークレットキーを作成し、サーバー側のシークレットストアに保存して、アクティブなデプロイメントを更新し、古いキーを無効化する前に最小限のリクエストで検証してください。作成画面を閉じた後は、既存キーの完全な値を取得することはできません。
新しいキーをブラウザーのJavaScriptに入れれば、OpenAIの401を修正できますか？
いいえ。ブラウザーやモバイルアプリはプロバイダーのシークレットを置く場所として不適切です。リクエストはバックエンド経由でルーティングし、シークレットはサーバー側の設定またはシークレットマネージャーに保存してください。
有効なOpenAIキーが401 ip_not_authorizedを返すのはなぜですか？
OpenAIのIP許可リストにより、組織の許可リストに含まれていないアドレスからのリクエストが拒否されることがあります。サーバーまたはクラウドワークロードの実際の送信元IPを確認し、設定済みのIP範囲と比較してください。
新しいOpenAIキーでゲートウェイの401が修正されなかったのはなぜですか？
ゲートウェイエンドポイントには、独自のAPIキーと設定が必要な場合があります。リクエストのホスト名を確認し、そのエンドポイントの運営者が発行した認証情報を使用してください。直接用のOpenAIキーでは、すべてのOpenAI互換APIへのリクエストを認証できるわけではありません。
