fetchのCORSエラーを解決する方法｜Failedの原因と対処法

JavaScriptの fetch() を使ってAPIからデータを取得しようとしたとき、ブラウザのコンソールに真っ赤な文字で fetch cors エラー が表示されて困っていませんか？「コードは合っているはずなのにデータが取得できない」「mode: 'no-cors' を試してみたけれど中身が読み取れない」と頭を抱えてしまう開発者の方は非常に多いです。

CORSエラーは、一見するとJavaScriptの書き方が間違っているように思えますが、実はWebブラウザが読者の安全を守るために通信をブロックしているセキュリティの仕組みです。そのため、エラーの仕組みや原因を正しく理解しないまま闇雲にコードを変更しても、根本的な解決にはつながりません。

この記事では、CORSエラーが発生する原因の切り分け方から、サーバー側での適切なヘッダー設定、Viteなどを利用したローカル開発環境での回避策まで、現場で役立つ具体的な解決法を分かりやすく解説します。

fetchのCORSエラーが発生する原因と確認方法

JavaScriptのfetch()を使って外部APIや別オリジンのサーバーからデータを取得しようとした際、突如として発生するのがCORSエラーです。CORSエラーの原因を迅速に特定するには、ブラウザの開発者ツール（DevTools）を活用し、エラーメッセージとネットワークの挙動を正しく切り分けることが重要です。まずはエラーが発生する仕組みと、具体的な確認手順を確認していきましょう。

CORSエラーが発生する仕組み

CORS（Cross-Origin Resource Sharing：オリジン間リソース共有）は、Webブラウザのセキュリティ機能である「同一オリジンポリシー（Same-Origin Policy）」の制限を安全に緩和するための仕組みです。

同一オリジンポリシーとは、あるオリジン（Webページを読み込んだコンテキスト）から取得したスクリプトが、異なるオリジンのリソースにアクセスすることをデフォルトで制限するルールです。ここでいう「オリジン」は、以下の3つの要素の組み合わせで決まります。

• スキーム（プロトコル）：http: や https:
• ホスト（ドメイン）：example.com や localhost
• ポート番号：3000 や 8080 など

例えば、フロントエンドアプリが https://app.example.com で動作している状態で、APIサーバー https://api.example.com へ fetch() でリクエストを送信した場合、ホストが異なるため「クロスオリジンリクエスト」となります。

ここで誤解されやすい点として、CORSエラーが発生した場合でも、ブラウザがリクエストをまったく送信していないとは限らないという点が挙げられます。実際には、ブラウザはサーバーへリクエストを送信しているものの、サーバーからのレスポンスに適切なCORSヘッダー（Access-Control-Allow-Origin など）が含まれていないため、ブラウザがセキュリティ上の理由からレスポンスの読み取りをブロックし、コンソールにエラーを表示しています。つまり、問題の本質は「リクエストの送信失敗」ではなく「レスポンスの読み取り拒否」にあるケースが多いのです。

オリジン間リソース共有 (CORS) - HTTP | MDN

オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、 HTTP ヘッダーベースの仕組みを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。ウェブアプリケー...

developer.mozilla.org

エラーメッセージから原因を特定する

ブラウザのConsoleに表示されるエラーメッセージを確認することで、CORSエラーの原因やサーバー側の設定不備をある程度絞り込むことができます。代表的なエラーメッセージとそれぞれの主な原因・確認ポイントは次のとおりです。

No 'Access-Control-Allow-Origin' header is present on the requested resource

原因: サーバーからのレスポンスに Access-Control-Allow-Origin ヘッダーが含まれていない、またはクライアントのオリジンが許可されていないためです。

確認点: サーバー側でCORSの設定が有効になっているか、許可するオリジンが正しく指定されているかを確認します。

Response to preflight request doesn't pass access control check

原因: 本番リクエストの前にブラウザが自動送信するプリフライトリクエスト（OPTIONSメソッド）に対し、サーバーが適切な許可ヘッダーを返していない、あるいはステータスコードを正しく返していないためです。

確認点: サーバー側が OPTIONS リクエストを受け入れ、適切な Access-Control-Allow-Methods や Access-Control-Allow-Headers を返却しているか確認します。

TypeError: Failed to fetch

原因: CORSエラーの代表的なメッセージですが、実際にはCORS制限以外に、ネットワーク接続の切断、DNSの名前解決失敗、HTTPS環境での混在コンテンツ（Mixed Content）、サーバーのダウン、またはCORS対応していないサーバーへのアクセスなど、多様な要因で発生します。

確認点: エラーメッセージだけでCORSと決めつけず、Networkタブで通信自体が成功しているか（ステータスコードの有無）を確認します。

Origin 'null'

原因: ローカルのHTMLファイルを file:// プロトコルで直接ブラウザに読み込ませた場合や、一部のサンドボックス化された環境からリクエストを送信した場合に発生します。

確認点: ローカルHTTPサーバーを立てて http://localhost:... 経由でアクセスしているかを確認します。

DevToolsでリクエストとレスポンスを確認する

CORSエラーの原因を正確に切り分けるためには、ブラウザの開発者ツール（DevTools）の「Network」タブを活用した詳細な調査が欠かせません。以下の手順でリクエストとレスポンスを検証します。

1. Consoleでエラーを確認する: まずConsoleタブを開き、発生しているエラーメッセージの正確な文面と、対象となっているAPIのエンドポイントURLを確認します。
2. Networkタブで該当リクエストを特定する: Networkタブを開いた状態で再度リクエストを発生させます。赤色で表示された該当のリクエスト行をクリックします。
3. プリフライト（OPTIONS）リクエストの有無を確認する: カスタムヘッダー（例: Authorization や Content-Type: application/json）を付与したリクエストやPOST/PUTリクエストの場合、本体のリクエストの前に OPTIONS メソッドのリクエストが送信されているかを確認します。プリフライトが発生している場合は、その OPTIONS リクエストのステータスコード（通常は 204 No Content や 200 OK）を確認します。
4. Request HeadersとResponse Headersを確認する:
   • Request Headers: クライアントから送信された Origin ヘッダーの値が意図した通りになっているか確認します。
   • Response Headers: サーバーからのレスポンスヘッダーに Access-Control-Allow-Origin や Access-Control-Allow-Methods が正しく含まれているか確認します。ヘッダー自体が存在しない場合は、サーバー側の設定漏えいやプロキシの設定ミスが疑われます。
5. HTTPステータスやネットワークエラーを確認する: レスポンスのステータスコードが 404 Not Found や 500 Internal Server Error などのエラーを示していないか確認します。サーバーがエラーを返している場合、CORSヘッダーが付与されないままレスポンスが返されるため、結果としてCORSエラーとして検知されるケースもあります。

fetchのCORSエラーを解決する方法

CORSエラーは、ブラウザがセキュリティ保護のために通信をブロックしている現象です。したがって、根本的な解決を図るには、APIサーバー側で適切にCORSレスポンスヘッダーを返却するように設定する必要があります。

クライアント側の fetch() の設定を変更するだけでは、サーバーが要求するCORS要件を満たすことはできません。以下に、サーバー側での具体的な設定手順とコード例を解説します。

Access-Control-Allow-Originをサーバー側で設定する

CORSエラーを解決するための最も基本的かつ必須の対応は、サーバーからのレスポンスに Access-Control-Allow-Origin ヘッダーを含めることです。このヘッダーによって、ブラウザに対して「どのオリジンからのリソース要求を許可するか」を指示します。

例えば、Node.jsのWebフレームワークであるExpressを使用している場合、cors ミドルウェアを利用するか、以下のように手動でレスポンスヘッダーを設定します。

Express（Node.js）での設定例

// server.js（Expressサーバーの例）
const express = require('express');
const app = express();

// 許可したいオリジンを明示する
const ALLOWED_ORIGIN = '<https://app.example.com>';

app.use((req, res, next) => {
  // レスポンスヘッダーに許可するオリジンを設定
  res.setHeader('Access-Control-Allow-Origin', ALLOWED_ORIGIN);
  next();
});

app.get('/api/data', (req, res) => {
  res.json({ message: 'Success' });
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

この設定により、サーバーが返すレスポンスヘッダーは次のようになります。

HTTP/1.1 200 OK
Content-Type:application/json
Access-Control-Allow-Origin:<https://app.example.com>

ブラウザは送信元の Origin と、レスポンスの Access-Control-Allow-Origin が一致していることを確認し、安全にレスポンス本文をJavaScript（fetch）へ渡します。

許可するオリジン・メソッド・ヘッダーを指定する

GETリクエストなどの単純な通信だけでなく、POSTやPUT、DELETEリクエスト、あるいはカスタムヘッダー（例: Authorization や Content-Type: application/json）を送信する場合、ブラウザは本番リクエストの前に「プリフライトリクエスト（OPTIONS）」を自動送信します。

これに対応するには、オリジンだけでなく、許可するHTTPメソッドやヘッダーもサーバー側で指定する必要があります。

Expressの公式ミドルウェアである cors パッケージを利用すると、これらを簡潔に安全に設定できます。

cors ミドルウェアを使用した設定例

// server.js（corsミドルウェアを使用した例）
const express = require('express');
const cors = require('cors');
const app = express();

const corsOptions = {
  // 許可するオリジンを指定
  origin: '<https://app.example.com>',
  // 許可するHTTPメソッドを指定
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  // クライアントからの送信を許可するヘッダーを指定
  allowedHeaders: ['Content-Type', 'Authorization'],
};

// CORSミドルウェアを適用（プリフライト OPTIONS リクエストにも自動対応）
app.use(cors(corsOptions));

app.post('/api/users', (req, res) => {
  res.json({ success: true });
});

app.listen(3000);

サーバーから返却されるレスポンスヘッダーの例：

Access-Control-Allow-Origin: <https://app.example.com>
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

このように必要最小限のメソッドとヘッダーだけを明示することで、セキュリティを保ちつつクロスオリジン通信を許可できます。

credentialsを使用する場合の注意点

CookieやHTTP認証情報（Authorization ヘッダーなど）をクロスオリジン通信に含める場合は、クライアント側とサーバー側の両方で明示的な設定が必要です。

1. クライアント側（fetch）の設定

fetch() のオプションで credentials: 'include' を指定します。

// client.js（クライアント側コード）
fetch('<https://api.example.com/api/user-profile>', {
  method: 'GET',
  credentials: 'include', // Cookieなどの認証情報を送信する設定
})
  .then(response => response.json())
  .then(data => console.log(data));

2. サーバー側の設定

サーバー側では、Access-Control-Allow-Credentials: true ヘッダーを返す必要があります。

// server.js（Expressでの認証情報許可設定）
const cors = require('cors');

const corsOptions = {
  origin: 'https://app.example.com', // 具体的なオリジン指定が必須
  credentials: true,                // 認証情報の送信を許可
};

app.use(cors(corsOptions));

⚠️ 認証情報使用時の重大な制約とセキュリティ注意点

credentials: 'include' を利用する場合、Access-Control-Allow-Origin にワイルドカード（*）を指定することは仕様上禁止されています。

/* ❌ 無効な設定パターン（エラーになります） */
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

もしワイルドカードと credentials: true を組み合わせた場合、ブラウザはCORSエラーを発生させ、通信を遮断します。認証情報を扱う通信では、必ず要求元のオリジン（https://app.example.com など）を具体的に検証し、個別に許可する実装にしてください。

fetchのmode・no-cors・プリフライトの違い

JavaScriptの fetch() を利用する際、リクエストの挙動を制御するオプションとして mode が用意されています。しかし、CORSエラーに直面した際に no-cors を安易に指定してしまい、期待通りのデータが取得できずに混乱するケースが多く見られます。各設定の役割と制約、そしてプリフライトリクエストの仕組みを正確に把握しておきましょう。

mode: ‘cors’とmode: ‘no-cors’の違い

fetch() の第2引数に指定する mode プロパティには、主に cors と no-cors が存在します。それぞれの動作や用途、制約の違いを以下の比較表に整理します。

fetch() のデフォルト値は cors であるため、何も指定しなくても mode: 'cors' として動作します。

no-corsでCORSエラーを解決できない理由

「CORSエラーが出るから mode: 'no-cors' に設定すれば解決する」というのはよくある誤解です。

mode: 'no-cors' を指定すると、ブラウザはCORSのチェックをスキップしてリクエストをサーバーへ送信します。そのため、コンソール上のCORSエラー表示が消えたように見えることがあります。しかし、サーバーから返ってきたレスポンスは「不透明なレスポンス（opaque response）」となり、JavaScript側からは以下のような状態になります。

• response.status が 0 になる
• response.ok が false になる
• response.json() や response.text() を実行しても中身を読み取れない

つまり、APIサーバーからJSONなどのデータを受け取って画面に表示したり処理したりする目的では、no-cors は何の解決策にもなりません。CORSエラーを回避する目的で mode: 'no-cors' を使用することは避けてください。データを取得する必要がある場合は、前述の通りAPIサーバー側でCORSヘッダーを正しく設定するか、後述する開発用プロキシ等の適切な手段を選択する必要があります。

プリフライトリクエスト（OPTIONS）が失敗するときの対処法

クロスオリジンリクエストを行う際、すべての通信で事前の確認が行われるわけではありません。プリフライトリクエスト（OPTIONSメソッド）は、サーバーに影響を与える可能性のあるリクエスト（例: Content-Type: application/json や Authorization ヘッダーを含むリクエスト、PUT/DELETEメソッドなど）の送信前に、ブラウザが安全性を確認するために自動送信する仕組みです。

プリフライトが失敗してCORSエラーになる主な原因と対処法は次のとおりです。

1. サーバーが OPTIONS メソッドに対応していない
   • 原因: サーバー側のルーティングやフレームワークが OPTIONS リクエストに対する応答ルートを用意していない場合、404 Not Found や 405 Method Not Allowed が返り、プリフライトチェックが失敗します。
   • 対処法: サーバー側で OPTIONS メソッドを正しく受け入れ、適切なステータスコード（通常は 204 No Content）とCORSヘッダーを返すように設定します（Expressの cors ミドルウェアなどを利用すれば自動処理されます）。
2. 認証ミドルウェアやリダイレクトが OPTIONS を妨げている
   • 原因: サーバーの手前に置かれた認証チェックやリダイレクト処理（例: 未認証の OPTIONS リクエストをログインページへリダイレクトさせる）により、プリフライトが正常終了しなくなるケースです。
   • 対処法: 認証ミドルウェアの適用除外設定を行界、OPTIONS リクエストに対しては常に認証をバイパスしてCORSヘッダー付きで応答するように修正します。
3. DevToolsでの確認方法
   • Networkタブで該当の通信を確認する際、本体のリクエスト（例: POST /api/data）の直前に、同じURLに対してメソッドが OPTIONS のリクエストが送信されているかを確認します。その OPTIONS リクエストを選択し、レスポンスのステータスコードや Access-Control-Allow-Methods / Access-Control-Allow-Headers が意図通りに返っているかを検証してください。

ローカル環境や外部APIでCORSエラーが出るときの対処法

APIサーバーのソースコードを直接修正できない場合や、ローカル開発環境特有の設定問題によってCORSエラーが発生することがあります。使用している環境やアーキテクチャに合わせた適切な回避策を実施しましょう。

Viteのプロキシ設定でローカル開発時のエラーを回避する

Viteなどのビルドツールを使用してローカル開発（例: http://localhost:5173）を行う際、バックエンドAPI（例: http://localhost:3000）へアクセスするとポート番号が異なるためCORSエラーが発生します。

この問題は、Viteの開発サーバー機能に含まれるプロキシ（Proxy）を利用することで解決できます。フロントエンドからのリクエストを一度Vite開発サーバーで受け取り、Viteが代わりにバックエンドAPIへリクエストを仲介（転送）することで、ブラウザからは「同一オリジンへの通信」に見えるようになります。

設定例：vite.config.js（または vite.config.ts）

// vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    proxy: {
      // '/api' から始まるリクエストを転送対象にする
      '/api': {
        target: '<http://localhost:3000>', // 転送先のバックエンドサーバーURL
        changeOrigin: true,             // Hostヘッダーの変更を許可
        rewrite: (path) => path.replace(/^\/api/, ''), // '/api' のプレフィックスを削除して転送する場合
      },
    },
  },
});

フロントエンド（fetch）側の実装

プロキシ設定後は、全域指定（http://localhost:3000）ではなく相対パスを指定して fetch() を実行します。

// src/main.js
// 例: Viteのプロキシ経由で <http://localhost:3000/users> にアクセスする
fetch('/api/users')
  .then(res => res.json())
  .then(data => console.log(data));

⚠️ プロキシ利用時の重要な注意点

Viteの server.proxy 機能は、ローカル開発サーバー（vite dev）動作時のみ有効な仕組みです。本番環境（vite build で静的ファイルを生成し、S3やNginx等に配備する場合）ではプロキシ機能は機能しません。本番環境では、Webサーバー（Nginxなど）側でのリバースプロキシ設定を行うか、APIサーバー側でCORSヘッダーを正しく設定する必要があります。

localhostやOrigin: nullが原因の場合

ローカル環境構築中に意図せずCORSエラーを引き起こす典型的な原因として、以下のような構成の不一致が挙げられます。

1. ポート番号・プロトコル・ホスト名の不一致

ブラウザは以下のようなケースをすべて「異なるオリジン」と判断します。

• ポート番号の違い: http://localhost:3000 と http://localhost:5173
• プロトコルの違い: http://localhost:3000 と https://localhost:3000
• ホスト名の違い: http://localhost:3000 と http://127.0.0.1:3000

APIサーバー側のCORS許可リストに http://localhost:5173 が指定されている場合、127.0.0.1:5173 からアクセスするとCORSエラーになります。アクセス時のURL表記を統一するか、サーバー側に両方のオリジンを許可する設定を追加してください。

2. Origin: null が送信されるケース

リクエストの Origin ヘッダーが null になる主な要因は、HTMLファイルを file:// プロトコルで直接ブラウザに読み込ませて実行している場合です（例: ファイルダブルクリックで開いたローカルの index.html）。

file:// プロトコルは安全なオリジンとして扱われないため、ブラウザは Origin: null を送信し、一般的なCORS許可ルールに合致せずブロックされます。

解決策: HTMLファイルを直接開くのではなく、VS Codeの「Live Server」拡張機能や、Node.jsの http-server などを用いてローカルHTTPサーバーを起動し、http://localhost:... 経由でアクセスしてください。

外部APIのCORS設定を変更できない場合の対処法

サードパーティ製APIや外部Webサービスなど、自身でCORS設定を変更できないAPIをフロントエンドから呼び出す際、CORSエラーが発生することがあります。

このような場合は、以下の手順で安全な回避策を検討してください。

1. 公式SDKやドキュメントの確認: 提供元のAPIがブラウザからの直接アクセス（Client-side fetch）を許可しているか確認します。APIによっては、サーバー間通信専用（Server-to-Server）として設計されているものもあります。
2. 自作バックエンド（サーバー側プロキシ）の経由: 自身でNode.js、Python、GoなどのバックエンドAPIを構築し、フロントエンドからは自作バックエンドへアクセスします。バックエンドから外部APIへの呼び出しにはブラウザのCORS制限が適用されないため、安全にデータを取得できます。

[ブラウザ(フロント)] --(CORS許可)--> [自社サーバー(Node.js等)] --(サーバー間通信)--> [外部API]

APIキーの防衛とセキュリティ注意: 外部APIのAPIキーをフロントエンドのJavaScriptコード内に直書きすることは避けてください。自作バックエンドを経由させることで、APIキーの漏洩を防ぎつつ、アクセス制限やキャッシュ制御を実施できます。

⚠️ 不明なサードパーティ製CORS回避プロキシサービスの危険性

インターネット上には「URLを挟むだけでCORSエラーを回避できる」と謳う無料の公開CORSプロキシサービスが存在します。しかし、悪意ある第三者が運営している場合、リクエストに含まれるトークンや個人情報、通信内容が盗聴・改ざんされるリスクがあります。本番環境はもちろん、開発環境であっても信頼できない公開プロキシの利用は厳禁です。

Reactやaxiosを使用している場合の注意点

1. React固有の問題とCORSの切り分け

Reactを使用している際、useEffect 内で fetch や axios を呼び出してCORSエラーになるケースがありますが、これはReactの仕組み自体が原因ではなく、ブラウザが適用する同一オリジンポリシーによるものです。

ただし、React Strict Mode（開発環境）ではコンポーネントの初期化時に useEffect が2回実行されるため、短時間に複数回のリクエストが発生し、サーバー側のレート制限やプリフライト処理の不備に接触してCORSエラーが出力されることがあります。エラー発生時は、ブラウザのNetworkタブで実際のリクエスト発生順序を確認してください。

2. axiosに変更してもCORSエラーは解決しない

「fetch() でCORSエラーが出るから axios にライブラリを変更する」という方法で解決を図る人がいますが、これは間違いです。

axios も内部ではブラウザ標準の XMLHttpRequest または fetch API を利用して通信を行っています。ブラウザが強制するCORS制限は通信ライブラリの種類に関係なく一律に適用されるため、axios に変更しただけではCORSエラーは解消しません。axios を使用する場合でも、これまで解説した通りサーバー側のCORS設定や開発用プロキシの設定が必要となります。

よくある質問（FAQ）

まとめ

本記事では、fetch() を利用した際のCORSエラーの原因特定から、具体的な解決策や環境別の対処法までを解説しました。最後に重要なポイントを振り返ります。

• 原因の特定と確認: まずはブラウザのConsoleでエラーメッセージを確認し、Networkタブでリクエストやレスポンス、プリフライト（OPTIONS）の挙動を検証する。
• サーバー側の設定が基本: CORS制限はブラウザによって強制されるため、根本的な解決にはAPIサーバー側での適切なCORSレスポンスヘッダー（Access-Control-Allow-Origin など）の設定が不可欠である。
• no-cors はデータの取得に不向き: mode: 'no-cors' はエラー表示こそ消えるものの、レスポンスボディを読み取れないため、JSONなどのデータ取得の解決策にはならない。
• ローカル開発ではViteプロキシを活用: ローカル環境（Vite等）でのポート違いによるCORSエラーには、開発用サーバーのプロキシ機能が有効である（本番環境ではサーバー側の設計が必要）。
• 外部APIでは提供元の仕様を確認: 変更できない外部APIに対しては、自社製のバックエンドプロキシを経由させるなどの安全な設計を検討し、公開プロキシの安易な利用は避ける。

CORSエラーに直面した際は、焦らずDevToolsで通信のどこがブロックされているかを切り分け、適切なレイヤー（サーバー設定、開発プロキシ、認証情報）で正しく対処しましょう。

あわせて読みたい

JavaScript fetchが動かない？POST/GETリクエスト・CORS・戻り値エラーの原因と対処法を完全ガイド

JavaScriptのfetchが使えない原因を徹底解説！GET/POSTの書き方から「Failed to fetch」やCORSエラーの対処法、非同期処理との連携、パースミスの回避まで、fetchが正常に動作しない時にチェックすべきポイントを紹介します。実践向けコード付きで、よくあるミスや疑問もまるごと解決！

watashi.xyz

2025.06.13