前回との接続——通しの流れから、遮断の話へ
前回のD-09では、URLを入れてから画面が表示されるまでの流れを通しで追いました。その中でブラウザは、HTMLだけでなくCSSやJavaScript、画像なども追加で取得していましたね。今回は、そのブラウザが動かすJavaScriptが別の出所へ通信しようとしたとき、なぜ止められるのかを見ていきます。CORSは、原因を知らないと何時間も無駄にしがちな、つまずきの定番です。
このスライドのポイント
- D-09: URLを入れてから画面が出るまでの7段階を通しで追った
- その中でブラウザは、HTML以外にCSS・JavaScript・画像なども追加で取得していた
- 今回: そのJavaScriptが別の出所へ通信しようとしたとき、なぜ止められるか
- CORSは原因を知らないと何時間も無駄にしがちな、つまずきの定番
オリジン・同一オリジンポリシー・CORSの定義
まず用語を定義します。オリジンとは、スキーム・ホスト・ポートの3つの組み合わせのことです。D-02で見たとおり、URLはいくつかの部分に分かれますが、そのうちパスは含みません。同一オリジンポリシーとは、ブラウザ上のJavaScriptから、異なるオリジンへのアクセスを原則として制限する、安全のための決まりです。悪意あるページが、別サービスにあるあなたのデータを勝手に読み取るのを防ぐために存在します。そしてCORSは、サーバー側が「このオリジンからの利用は許可します」と応答ヘッダーで表明し、ブラウザにその例外を認めさせる仕組みです。
このスライドのポイント
- オリジン＝スキーム＋ホスト＋ポートの組（D-02の3要素。パスは含まない）
- 同一オリジンポリシー＝ブラウザ上のJavaScriptから、異なるオリジンへのアクセスを原則制限する安全上の決まり
- 目的: 悪意あるページが、別サービスのあなたのデータを勝手に読むのを防ぐ
- CORS＝サーバー側が「このオリジンからの利用は許可する」と応答ヘッダーで表明し、ブラウザに例外を認めさせる仕組み
なぜ必要か——赤いエラーを自分のコードの誤りと思い込む
なぜこれを知る必要があるのでしょうか。開発中、手元の画面から自作のAPIを呼んだ瞬間に、赤いエラーが出ることがあります。多くの人はこれを自分のコードの間違いだと思い込み、AIに何時間も見当違いの修正をさせてしまいます。ですが、これはコードの誤りではなく、オリジンが違うことによる遮断であることが多いのです。正体を知っていれば、無駄な回り道を避けられます。
このスライドのポイント
- 開発中、手元の画面から自作APIを呼んだ瞬間に赤いエラーが出ることがある
- 多くの人はコードの間違いだと思い込み、AIに見当違いの修正を延々とさせる
- 実際はコードの誤りではなく、オリジンが違うことによる遮断であることが多い
- 正体を知っていれば、無駄な回り道を避けられる
構造・流れ——止めているのはブラウザ
CORSが起きる流れを整理します。まずブラウザが別のオリジンへ要求を送ります。次にサーバーは応答します。処理自体は動いていることもあります。ところがその応答に許可を示すヘッダーが無いと、ブラウザは受け取った結果をJavaScriptへ渡さず、エラーにします。ここが核心です。止めているのはサーバーではなく、ブラウザなのです。サーバーは応答を返しているのに、ブラウザが手前でせき止めている、と押さえてください。
このスライドのポイント
- ①ブラウザが別オリジンへ要求
- ②サーバーは応答する（処理自体は動いていることもある）
- ③応答に許可ヘッダー（Access-Control-Allow-Origin）が無い
- ④ブラウザが結果をJavaScriptへ渡さずエラーにする
- 核心: 止めているのはサーバーではなくブラウザ
具体例——許可を書く場所はサーバー側
具体例で見ましょう。手元の画面が http://localhost:3000、呼び出す先のAPIが https://api.example.com だとします。この2つはオリジンが異なるため、ブラウザが通信を遮断します。解決するには、サーバー側が応答ヘッダーで localhost:3000 からの利用を許可すればよいのです。ここで大事なのは、許可を書く場所はあくまでサーバー側だという責任範囲です。A-01で学んだ、どの部品がどこまで責任を持つかという4要素の、実践そのものと言えます。
このスライドのポイント
- 画面が http://localhost:3000、APIが https://api.example.com → オリジンが異なる
- オリジンが違うためブラウザが遮断する
- サーバー側が応答ヘッダーで localhost:3000 を許可すれば通る
- 許可を書く場所はサーバー側、という責任範囲（A-01の4要素の実践）
技術サンプル——CORS許可ヘッダー
サンプルを見ます。種別はhttpで、サーバーの応答ヘッダーに許可を書いた例です。Access-Control-Allow-Origin という行に、https://app.example.com という許可する相手のオリジンが書かれています。読み方のポイントは2つ。許可を書くのはサーバー側の応答であること、そして許可する相手のオリジンを明示していることです。注意点として、AIはときどき、この値を「*」にした全オリジン許可を提案してきます。ですがそれは、誰でも呼べるAPIになってしまいます。A-08の公開範囲の判断そのものなので、安易に採用しないでください。
このスライドのポイント
- 種別: http
- 目的: サーバーの応答ヘッダーに、許可するオリジンを書く例を読む
- サンプル本体:
混同しやすい概念——サーバーが拒否 vs ブラウザが遮断
混同しやすい概念を整理します。サーバーが拒否した場合と、ブラウザが遮断した場合は別物です。D-06で見た401や403は、サーバー自身が本人確認や権限の理由で断った結果です。一方CORSは、サーバーではなくブラウザの仕組みによる遮断です。ですからCORSは、画面を介さないサーバー同士の通信では起きません。エラーに出会ったら、これはサーバーが断ったのか、ブラウザがせき止めたのか、をまず切り分けましょう。
バイブコーディングでの確認点
バイブコーディングでの確認点です。CORSエラーが出たら、A-07で習ったとおり、ブラウザに表示された文言をそのままAIへ貼りましょう。そのうえで、もしAIが「*」での全許可を提案してきたら、公開範囲、つまりA-08の判断を自分で行ってから採用します。AIへの質問例としては、「このCORSエラーは、どのオリジンからどのオリジンへの呼び出しで、何のヘッダーが足りていませんか」が有効です。あわせて「本番では許可するオリジンを絞ってください」と指示しておきましょう。
このスライドのポイント
- CORSエラーはブラウザに出た文言をそのままAIへ貼る（A-07のエラー原文の実践）
- AIが
*での全許可を提案したら、公開範囲（A-08）を自分で判断してから採用する - 「本番では許可するオリジンを絞ってください」と指示する
- 質問例: 「このCORSエラーは、どのオリジンからどのオリジンへの呼び出しで、何のヘッダーが足りていませんか」
まとめ——カテゴリD修了
最後に一問一答です。CORSエラーで通信の結果を止めているのは、サーバーとブラウザのどちらでしょうか。……答えはブラウザです。同一オリジンポリシーによる遮断であり、サーバー側の許可ヘッダーで解決します。30秒でまとめます。オリジンはスキーム・ホスト・ポートの組。違うオリジンへの通信をブラウザが原則止め、サーバーが許可ヘッダーで例外を認める、これがCORSです。これでカテゴリDは修了です。要求と応答の書式から、守る仕組み、止める仕組みまでを通しで手に入れました。次回はカテゴリE、プログラミングの基本概念へ進みます。関連資料は、API連携 超入門、AIアプリのセキュリティ超入門、エラー解決プロンプト50です。
このスライドのポイント
- 一問一答:「CORSエラーで通信の結果を止めているのは、サーバーとブラウザのどちら？」→答: ブラウザ（同一オリジンポリシーによる遮断。サーバー側の許可ヘッダーで解決する）
- 30秒まとめ: オリジンはスキーム・ホスト・ポートの組。違うオリジンへの通信をブラウザが原則止め、サーバーが許可ヘッダーで例外を認めるのがCORS
- カテゴリD修了。要求と応答の書式、番号の読み方、守る仕組み、止める仕組みを通しで手に入れた
- 次回: カテゴリE、プログラミングの基本概念へ
- 関連資料: 「API連携 超入門」「AIアプリのセキュリティ超入門」「エラー解決プロンプト50」
