CORSとは？初心者がつまずきやすい原因と考え方をわかりやすく解説

フロントエンドから API を呼んだら CORS エラーが出たけど、何が悪いのか分からない というのはかなりよくあるつまずきです。
しかも、初心者のうちは サーバーエラー と ブラウザの制約 が混ざって見えやすいので、さらに分かりにくくなります。

この記事では、2026年10月時点で MDN の CORS ガイド、Preflight request の説明、WHATWG Fetch Standard の CORS まわりを確認しながら、CORS とは何か、なぜエラーになるのか、どう考えると整理しやすいのかを初心者向けにまとめます。
フロントエンドと API を分ける構成の全体像から見たいなら、代表的なフレームワーク7選｜Laravel・Django・Rails・Spring Boot・Next.js・Nuxt・FastAPIの向いている用途を比較 もつながりやすいです。

CORSとは何か

CORS は Cross-Origin Resource Sharing の略で、ブラウザが別オリジンへのリクエストをどう許可するかを決める仕組みです。
MDN でも、追加の HTTP ヘッダーによって、あるオリジンで動く Web アプリが別オリジンのリソースへアクセスできるかをブラウザへ伝える仕組みと説明されています。

次の図では、同一オリジン・別オリジン（単純リクエスト）・別オリジン（プリフライト）の3パターンで、ブラウザとサーバーの間で何が起きているかをステップごとに確認できます。

そもそも「オリジン」とは何か

Origin は、ざっくり言うと スキーム + ホスト + ポート の組み合わせです。

たとえば、

• https://example.com
• https://api.example.com
• http://example.com
• https://example.com:8443

は、それぞれ別オリジンとして扱われることがあります。

このため、

• フロントは http://localhost:3000
• API は http://localhost:8000

のような開発構成でも、ブラウザから見ると別オリジンです。
ここで CORS が出やすくなります。

なぜそんな制限があるのか

背景にあるのは Same-Origin Policy です。
これは、あるサイト上で動くスクリプトが、別オリジンの応答を自由に読めないようにするブラウザの基本制約です。

どういうときに CORS エラーになるのか

初心者がハマりやすいのは、リクエスト自体は飛んでいるのに、ブラウザでだけ読めない パターンです。

たとえば次のような場面です。

• http://localhost:3000 の画面から http://localhost:8000/api を呼ぶ
• https://app.example.com から https://api.example.com を呼ぶ
• JavaScript の fetch() や Axios で別オリジンの API を叩く

まずよくある誤解

API が 200 を返していても CORS で失敗することがある

ここはかなり大事です。
ネットワークタブを見ると 200 に見えるのに、JavaScript 側ではエラーになることがあります。

「サーバー間通信」には CORS は関係ない

サーバーからサーバーへ API を呼ぶだけなら、普通は CORS は関係しません。
ブラウザで動く JavaScript が別オリジンへ取りに行くときに問題になりやすいです。

no-cors を付ければ解決するわけではない

fetch() の mode: 'no-cors' を見つけて、これで解決できると思う人も多いです。

Preflight request とは何か

ブラウザは、いきなり本番のリクエストを送る前に、このリクエスト送ってよい？ と確認することがあります。
これが Preflight request です。

典型的には、次のような場面で、先に OPTIONS リクエストが飛びます。

この preflight に対してサーバーが正しく返せないと、実際の本リクエストまで進みません。
初心者が POST なのに OPTIONS が見える と戸惑いやすいのはこのためです。

何を許可するのか

CORS では、主に次を整理します。

特によく見るのが Access-Control-Allow-Origin です。
これは、どのオリジンを許可するかをブラウザへ伝えるヘッダーです。

初心者向けの考え方

実務では、CORS を有効にする ではなく、どの画面からどの API を呼ばせたいのか を先に決めます。

たとえば、

• フロント: https://app.example.com
• API: https://api.example.com

なら、API 側で https://app.example.com を許可対象にします。

つまずきやすい原因

1. フロントと API のポートが違う

ローカル開発ではこれがかなり多いです。 localhost が同じでも、ポートが違えば別オリジンになることがあります。

2. preflight の OPTIONS を処理していない

本体の POST /api/... は作ったのに、OPTIONS への返しが足りず、ブラウザだけ止まるパターンです。

3. 許可オリジンを雑にしすぎる or 絞りすぎる

* にしてしまってあとで認証情報とぶつかる、逆に本番ドメインを入れ忘れる、というのはかなりよくあります。

4. CORS と認証エラーが混ざって見える

401 や 403 と CORS が同時に出ると、どちらが本当の原因か見えにくくなります。 まずはネットワークタブで、サーバー応答そのもの と ブラウザの CORS 判定 を分けて見るのが大事です。

どう確認するとよいか

CORS エラーが出たら、6ステップで原因を切り分けると迷いにくくなります。

この順に分けるだけで、かなり迷いにくくなります。

実務でどう考えるか

実務では、CORS は とりあえず動けばよい設定 にしない方が安全です。
フロントと API を分ける構成ではかなり普通に出てくるので、最初から 許可するオリジン を設計に入れておく方が後で崩れにくいです。

特に次のような場面で重要です。

CORS に関するよくある質問

サーバー側で Access-Control-Allow-Origin: * にすれば全部解決？

認証の要らない公開データなら * が適切なこともありますが、認証が絡む API では使えません。MDN のとおり、Cookie などの認証情報を含むリクエストに * で応えると、ブラウザは応答の読み取りを止めます。また * は、どのサイトのスクリプトにも応答を読ませるという意味です。なお CORS は「応答を読ませるか」の仕組みで、リクエストそのものを止めるものではありません。認証が絡むなら、許可するオリジンを明示的に列挙 するのが安全です。

CORS は JavaScript からのリクエストだけが対象？

主な対象は fetch() や XMLHttpRequest など、スクリプトから出すクロスオリジンリクエストです。ほかにも MDN は、CSS の @font-face で読む Web フォント、WebGL のテクスチャ、canvas に drawImage() で描く画像や動画を挙げています。crossorigin 属性の付いた要素や type="module" のスクリプトも CORS で取得されます。一方、属性なしの画像や従来の <script> の読み込み自体は CORS の判定を受けません（中身をスクリプトから読むことはできません）。サーバー間通信（curl、Node.js のサーバー側）には CORS は関係しません。

Preflight（OPTIONS）はなぜ飛ぶ？

単純リクエスト 以外（PUT/DELETE、カスタムヘッダー、application/json など）でブラウザが事前確認のために OPTIONS を投げます。サーバーが許可を返さないと本リクエストは送られません。preflight キャッシュ（Access-Control-Max-Age）を使えば、毎回 OPTIONS を飛ばさずに済みます。ただし上限はブラウザごとに決まっていて、MDN によると Chromium は 2 時間、Firefox は 24 時間です。

開発中だけ CORS を無効にする方法は？

ローカル開発なら、Vite（server.proxy）や webpack-dev-server のプロキシ機能で /api/* を API サーバーへ転送すると、ブラウザから見て同じオリジンになり CORS が要りません。もう1つは、開発環境でもサーバー側で http://localhost:5173 などを明示的に許可する方法です。ブラウザのセキュリティ機能そのものを無効にする起動方法は、他のサイトに対する保護まで外れるので勧めません。

サーバー側のフレームワーク別の設定方法は？

Express なら cors パッケージ、Laravel なら標準の HandleCors ミドルウェアと config/cors.php（Laravel 11 以降は php artisan config:publish cors で作成）、Django なら django-cors-headers、FastAPI なら CORSMiddleware、Spring Boot なら @CrossOrigin または WebMvcConfigurer。各フレームワークに公式 / 準公式のミドルウェアが用意されているので、ゼロから書く必要はほぼありません。

Next.js の Route Handlers（API Routes）に CORS は必要？

同じドメインで配信される画面から叩くなら不要。外部ドメインや別オリジンの SPA から叩くなら必要です。Next.js 16 では、Route Handler の中でヘッダーを返すか、proxy.ts（Next.js 15 までの middleware.ts。16 で改名）でまとめて設定します。公式ドキュメントに、許可するオリジンを照合する例があります。

まとめ

CORS は、ブラウザが別オリジンのリクエストをどう扱うかを決める仕組みです。 大事なのは、CORS エラーは API が壊れた のではなく、ブラウザが読ませていない ことが多いと分けて考えることです。

そのうえで、Origin、Same-Origin Policy、Preflight request を押さえると、かなり見通しがよくなります。
初心者のうちは、どの画面からどの API を呼ばせたいのか を先に整理して、サーバー側で必要な範囲だけ許可する考え方で進めるのがいちばん分かりやすいです。

参考情報

• MDN: Cross-Origin Resource Sharing (CORS)
• MDN: Preflight request
• MDN: Access-Control-Max-Age
• Next.js Docs: proxy.js（CORS の例）
• Laravel: Routing - CORS
• WHATWG Fetch Standard: CORS protocol