「APIキーがCookieに見つかりません」エラーを修正
「Cookie に API キーが見つかりません」とは、キーが無効なのではなく、ブラウザがキーを保持している Cookie を失ったという意味です。すぐに直す方法と、再発を防ぐ方法はこちらです。

TL;DR
API key not found in cookiesは、ほとんどの場合、キーが間違っているという意味ではありません。キーを cookie に保存したブラウザーアプリが、その cookie を読み戻せないという意味です。- よくある原因は、サードパーティ cookie がブロックされていることです。Safari、Brave、Firefox、そしてすべての Incognito ウィンドウはデフォルトでブロックします。そのため、キーを保持する cookie が黙って永続化されません。
- すぐできる修正: 正確なアプリドメインで cookie を許可し、サインアウトして再度サインインしてから、キーを貼り直します。別のブラウザーや Incognito ですか? それが「消えた」理由です。
- 恒久的な修正(開発者向け): cookie jar を信頼するのをやめます。安定したエンドポイントに
Authorization: Bearerヘッダーでキーを送信します。cookie がなければ、cookie の問題もありません。
ガイドでこれが「Cursor」や「Windsurf」のエラーだと言われてここに来たなら、それは違います。このメッセージは、API キーをクライアント側に保持するブラウザーアプリから出るもので、修正は IDE とは関係ありません。
"API key not found in cookies" は実際には何を意味しますか?
これは、アプリがブラウザー cookie 内に API キーがあることを期待して確認したところ、その cookie が存在しなかったという意味です。キー自体はおそらく問題ありません。壊れたのは、それを保持していたストレージです。
仕組みはこうです。一部の Web アプリ(AI チャットフロントエンド、リバースプロキシのダッシュボード、一部の SaaS コンソール)は、あなたのキーを自社サーバーに置きたがりません。そのため、あなたがキーを貼り付けると、それを自分のブラウザー内の [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies)(または cookie に裏付けられたセッション)に保存します。その後、各リクエストでその cookie からキーを読み戻します。cookie が欠落している、ブロックされている、期限切れになっている、または現在アクセスしているドメインとは異なるスコープになっている場合、読み取り結果は空になります。その結果、API key not found in cookies が表示されます。
つまり、これは クライアント側の認証状態エラー であり、「認証情報が無効」というエラーではありません。誰かがキーを拒否したわけではありません。アプリが送信するためのキーを見つけられなかっただけです。
どのアプリでこのエラーが出るのか — そしてなぜ API キーの問題ではないのか
API キーを cookie に保存するブラウザーアプリなら、どれでもこのエラーを出す可能性があります。それが正直な答えであり、明言する価値があります。というのも、この検索クエリで上位に出るガイドは、Cursor、Windsurf、Cline のような IDE ツールを原因にしていますが、そこに挙げられている特定のバージョン番号は、実際の cookie ベースのエラーには対応していないからです。これらのツールはキーをブラウザー cookie ではなく、ローカル設定ファイルに保存します。
実際に API key not found in cookies を目にする場所:
| コンテキスト | キーが cookie に置かれる理由 |
|---|---|
| AI チャット / ロールプレイ用フロントエンド(Chub AI/Venus 風、Janitor 風の構成) | 自分の OpenAI/Claude/OpenRouter キーまたはリバースプロキシキーを貼り付けると、それがブラウザー側に保存される |
| LLM API 向けリバースプロキシの Web UI | プロキシがサーバー上に保持しないよう、アクセスキーをセッション cookie に保存する |
| デモ / playground を制限する Web ダッシュボード | ログインの往復なしで更新後も動作するよう、キーが cookie に保持される |
共通点は、キーがサーバー側アカウントに到達していない ことです。キーはブラウザー内にあり、ブラウザーがそれを見失っています。この見方に切り替えると、以下のすべての修正の意味が変わります。キーを直しているのではなく、cookie ストレージを直しているのです。
なぜ API キーの cookie は消え続けるのですか?
現代のブラウザーはデフォルトでサードパーティ cookie をブロックし、キーを保持する cookie がしばしばその扱いを受けるからです。これが、ほとんどの「キャッシュをクリアしましょう」系ガイドが見落としている根本原因です。
デフォルト設定を見てください。いつの間にか変わっています:
| ブラウザー / モード | デフォルトのサードパーティ cookie |
|---|---|
| Safari | ブロック — Intelligent Tracking Prevention、Safari 13.1(March 2020)以降デフォルトで有効 |
| Firefox | 分離 / ブロック — Total Cookie Protection が June 2022 以降デフォルトで有効 |
| Brave | 初期状態でブロック |
| Chrome / Edge(Incognito または InPrivate) | デフォルトでブロック |
| Chrome / Edge(通常ウィンドウ) | 許可されているが、広告ブロッカーやプライバシー拡張機能がしばしば削除する |
そのため、「自分のノート PC では動く」同じキーが、プライベートウィンドウ、制限の厳しい会社のブラウザー、またはブラウザー更新でプライバシー設定のデフォルトが変わった後に失敗します。ハンドシェイクは完了したように見えますが、その後アプリは cookie を書き込むことも読み取ることもできません。
cookie が消える理由は他にもあります:
- cookie を削除した(または「閲覧データを削除」を使った)— キーの cookie も一緒に消えました。
- 別のブラウザーまたはデバイス — cookie はそれらの間で同期されないため、キーは存在しません。
- ドメインまたはサブドメインが違う —
app.example.comに設定された cookie はexample.comからは見えず、その逆も同じです。 - システム時計のずれ — cookie には有効期限のタイムスタンプがあります。時計が数分ずれていると、ブラウザーは新しい cookie をすでに期限切れと扱うことがあります。
- SSL 検査を行う企業プロキシまたは VPN — 一部は
Set-Cookieヘッダーを書き換えたり削除したりするため、cookie が保存されません。
"API key not found in cookies" を今すぐ直すには?
このリストを順に試してください。最初の 2 つで、ほとんどのケースは 1 分以内に直ります:
- アプリの正確なドメインで cookie を許可します。 Chrome/Edge: 設定 → プライバシーとセキュリティ → サードパーティ cookie → 「サードパーティ cookie の使用を許可するサイト」にアプリの URL を追加します。Safari: 設定 → プライバシー → 「サイト越えトラッキングを防ぐ」のチェックを外します(またはサイト例外を追加します)。Firefox: アドレスバーの盾アイコン → そのサイトで強化型トラッキング防止をオフにします。
- サインアウトし、再度サインインしてから、キーを貼り直します。 これにより、アプリは新しいセッションを発行し、きれいな cookie を書き込むよう強制されます。認証状態版の電源を入れ直すようなものです。
- Incognito/Private モードを終了します。 これらは設計上サードパーティ cookie をブロックし、ウィンドウを閉じると何も永続化されません。通常ウィンドウを使い、キーを再入力してください。
- そのサイトで広告ブロッカー / プライバシー拡張機能を無効にします。 uBlock Origin、AdGuard、プライバシー系アドオンは、cookie が通るサブドメインをブロックすることがあります。アプリをホワイトリストに追加し、再読み込みして、キーを再入力します。
- システム時計を確認します。 自動日時設定をオンにして、NTP で同期されるようにします。ずれた時計は正常な cookie を黙って期限切れにします。
- キーを保存した正確な URL にアクセスしていることを確認します。
app.tool.comでキーを保存した場合、cookie はtool.comには表示されません。サブドメインを一致させます。 - プロバイダーのダッシュボードでキーを再生成します。 チームメイトがローテーションまたは削除していた場合、その cookie は無効なキーを指しています。新しいものを作成し、貼り付ければ完了です。
企業ネットワーク上で、どれを試しても定着しない場合は、2 分だけスマホのホットスポットで試してください。そこで動くなら、SSL 検査プロキシが cookie を食べています。IT にアプリのドメインをバイパスするよう依頼してください。
このエラーを根本的になくすには?
キーを運ぶためにブラウザー cookie に依存するのをやめます。コードを管理しているなら、代わりにリクエストヘッダーでキーを送信してください。cookie は任意ですが、ヘッダーはそうではありません。
cookie に保存されたキーは、設計上壊れやすいものです。1 つのブラウザープロファイル内に存在し、そのブラウザーのプライバシールールを継承し、キャッシュ削除で消えます。ヘッダーベースの認証は、それらをすべて回避します。キーはリクエスト内を移動します:

curl https://api.velokey.ai/v1/chat/completions \
-H "Authorization: Bearer $YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6",
"messages": [{"role": "user", "content": "Hello"}]
}'cookie jar も、サードパーティ cookie ポリシーも、Incognito の予期せぬ挙動もありません。同じ呼び出しは、スクリプト、サーバー、CI ジョブ、またはフロントエンドが通信するバックエンドから実行できます。そしてそれらには、そもそも cookie の問題がありません。ブラウザーアプリを作っているなら、堅牢なパターンはキーを自分のバックエンドに保持し、ブラウザーには生のプロバイダーキーをクライアント側 cookie に貼り付けさせるのではなく、*あなたの* サーバーを呼ばせることです。
API ゲートウェイがこのエラーに遭遇しないのも同じ理由です。[Velokey](https://api.velokey.ai) のようなゲートウェイは、多くのモデル([GPT-5.6](/model/gpt-5.6)、[Claude Opus 4.8](/model/claude-opus-4-8)、[Claude Sonnet 5](/model/claude-sonnet-5))に到達できる 1 つのキーを、単一の OpenAI 互換エンドポイントを通じて提供し、そのキーは毎回 Authorization ヘッダーに乗ります。失う cookie はありません。モデルを試すためだけにチャットフロントエンドへプロバイダーキーを貼り付けていたなら、安定したエンドポイントを直接呼ぶ方がよりシンプルで壊れにくい方法です。その価格面については、Claude API 料金ガイド を参照してください。完全な手順については、キーを使って API を呼び出す方法 でセットアップを最初から最後まで説明しています。
クイック修正リファレンス
| 症状 | 根本原因 | 30 秒の修正 |
|---|---|---|
| プライベートウィンドウでのみ失敗する | Incognito がサードパーティ cookie をブロックしている | 通常ウィンドウを使い、キーを再入力する |
| 昨日は動いたが今日は動かない | ブラウザー更新で cookie のデフォルトが変わった | そのドメインで cookie を許可する |
| 自宅では動くが職場では失敗する | SSL 検査プロキシが cookie を削除している | ホットスポットで試す。IT にドメインのバイパスを依頼する |
| 「キャッシュ削除」の直後に壊れた | キーの cookie が削除された | キーを貼り直す |
| cookie は設定されているのに見つからない | サブドメインが違う | 保存した正確な URL に合わせる |
| ランダムに期限切れになる | システム時計のずれ | 自動日時設定をオンにする |
| 自分のアプリを構築している | キーがクライアント側の cookie に保存されている | バックエンドでヘッダー認証に移行する |
よくある質問
"API key not found in cookies" は特定の 1 つのアプリ固有ですか?
いいえ。これは、API キーを cookie に保存する任意のブラウザーアプリから出る一般的なメッセージです。AI チャットフロントエンド、リバースプロキシのダッシュボード、一部の Web playground はすべてこのパターンを使います。これを単一の IDE に結びつけるガイドは推測しています。修正はどの場合も同じで、キーを保持する cookie を修復するか置き換えることです。
cookie を削除すると API キーは永久に消えますか?
いいえ。キーは cookie ではなく、プロバイダーのダッシュボードに存在します。cookie を削除しても、アプリが読み取っていたローカルコピーが削除されるだけです。サインアウトされ、キーを再度貼り付けるよう求められますが、キー自体はそのままです。再入力できるよう、削除する前にプロバイダーからコピーしておいてください。
Incognito またはプライベートモードでこのエラーは起きますか?
はい、確実に起きます。Incognito、Private、InPrivate ウィンドウはデフォルトでサードパーティ cookie をブロックし、閉じるとすべて消去します。プライベートウィンドウでキーを保存したなら、それはすでに消えています。通常ウィンドウに切り替え、キーを再入力すれば、セッション間で永続化されます。
VPN や企業プロキシが引き起こすことはありますか?
あります。SSL 検査を行う企業プロキシや一部の VPN は Set-Cookie ヘッダーを書き換えたり削除したりするため、キーの cookie がブラウザーに保存されません。簡単なテスト: 1 分だけスマホのホットスポットに切り替えてください。エラーが消えるなら、ネットワークが原因です。IT に、アプリのドメインを検査バイパスリストに追加するよう依頼してください。
このエラーはサーバー側 API 呼び出しに影響しますか?
いいえ。サーバー間の呼び出しではキーを Authorization ヘッダーで送信し、ブラウザー cookie は関与しないため、このエラーはそこでは発生しません。これは、キーをクライアント側に保存することを選んだブラウザーアプリでのみ発生します。認証をリクエストヘッダーに移すことこそ、バックエンドやスクリプトでこのエラーが起きない理由です。
なぜ API ゲートウェイやアグリゲーターにはこの問題がないのですか?
cookie ではなくヘッダーで認証するからです。安定したエンドポイントへのすべてのリクエストで Authorization: Bearer <key> を送信するため、ブロック、期限切れ、削除されるブラウザー cookie がありません。これが、cookie ベースのフロントエンドが静かに失敗するブラウザー、プライベートウィンドウ、制限の厳しいネットワークでも、ゲートウェイ呼び出しが動き続ける構造的な理由です。

