CORSとは
CORSはCross-Origin Resource Sharingの略で、あるオリジン（ドメイン・プロトコル・ポートの組み合わせ）から別のオリジンのリソースへアクセスする際の許可ルールを定めた仕組みです。
ブラウザは安全のため、原則として別オリジンへのスクリプトからの通信を制限します。CORSは、その制限をサーバー側が明示的に緩める手段だと理解するとわかりやすくなります。
同一オリジンポリシーとの関係
CORSを理解する前提として、同一オリジンポリシーがあります。これは、ページが読み込まれたオリジンと異なるオリジンのリソースへ、スクリプトが勝手にアクセスできないようにする基本ルールです。
この制限がないと、悪意のあるサイトが利用者の情報を別サイトから引き出せてしまう恐れがあります。CORSは、この安全網を保ちつつ、必要な通信だけを許可するための仕組みです。
実務ではどこで関係する？
CORSは言葉の意味だけ覚えても、HTML共有の判断にはつながりません。実務では「表示に関係する話か」「検索に関係する話か」「アクセス制限に関係する話か」を分けて考えると整理しやすくなります。
CORSについて迷ったら、相手が安全に開けるか、検索に出してよいか、ブラウザや環境差で壊れないかを順番に確認します。用語理解は、その判断を早くするための道具として使います。手順が決まったら、HTML/ZIPをアップロードして共有URLを発行し、相手に確認してほしい観点と期限を添えて送ります。
- 表示の話: HTML/CSS/JS、パス、ブラウザ互換性を確認する
- 検索の話: noindex、canonical、sitemap、robots.txtの役割を分ける
- 制限の話: URL共有、パスワード、メール認証、会社ドメイン認証を混同しない
- 運用の話: 期限、差し替え、削除、共有メッセージまで決める
通信が許可される流れ
別オリジンへのリクエストが許可されるかどうかは、サーバーが返すヘッダーによって決まります。おおまかな流れは次の通りです。
- ブラウザが別オリジンへリクエストを送る際、自分のオリジン情報を付与する
- 場合によっては事前確認（プリフライト）のリクエストを先に送る
- サーバーが許可するオリジンやメソッドをレスポンスヘッダーで返す
- ブラウザがその許可内容を確認し、問題なければ本来のレスポンスを使えるようにする
プリフライトリクエスト
特定のメソッドやヘッダーを使う通信では、本番のリクエストの前に、許可されているかを確認するためのリクエストが自動で送られます。これをプリフライトと呼びます。
プリフライトでサーバーが適切な許可を返さないと、本番の通信は実行されません。CORSエラーの調査では、このやり取りを確認すると原因が見えやすくなります。
CORSエラーへの向き合い方
CORSエラーはフロントエンド側のコードだけでは解決できないことが多く、許可を返すのは通信先のサーバー側です。そのため、アクセスを許可してもらえるかをサーバー側の設定で対応する必要があります。
また、CORSはあくまでブラウザ上の制御であり、認証や認可とは別物です。アクセス制御はサーバー側でも別途しっかり行う必要がある点に注意しましょう。
再現するページを共有して相談するには
CORSエラーは環境によって挙動が変わることがあり、実際に開いて確かめてもらうと相談がスムーズです。問題を再現する最小限のページを関係者に見てもらうと、原因の切り分けが進みます。
再現用のHTMLを一時的に共有したいときは、ギガサイト便のようにドロップで認証付きの一時URLを発行できるサービスを使うと、関係者だけに見せながら相談できます。
よくある質問
オリジンとは何を指しますか？
プロトコル（httpsなど）、ドメイン、ポート番号の組み合わせを指します。このいずれかが異なると別オリジンとみなされます。
CORSエラーはフロントエンドだけで直せますか？
多くの場合、許可を返すのは通信先のサーバーです。サーバー側で適切な許可ヘッダーを返す設定が必要になることが一般的です。
プリフライトリクエストはなぜ送られますか？
特定の条件を満たす通信について、本番のリクエスト前に許可状況を確認するために、ブラウザが自動で送ります。
CORSはセキュリティ対策になりますか？
CORSはブラウザ上での通信制御であり、それ自体が認証や認可の代わりにはなりません。アクセス制御はサーバー側で別途行う必要があります。
実務ではどこで関係する？はHTML共有で必ず理解しておく必要がありますか？
細かな仕様を暗記する必要はありません。ただし、検索に出るか、閲覧者を制限できるか、表示が崩れないかに関わる用語は、共有前の判断材料として押さえておくと安全です。