なぜAccess-Control-Request-Methodが重要なのか
Web開発において、フロントエンドから別ドメインのAPIを叩く際、CORS（Cross-Origin Resource Sharing）の設定に頭を悩ませた経験はありませんか？特に、DELETEやPUTなどのメソッドを使用したり、カスタムヘッダーを付与したりすると、ブラウザは自動的に「プリフライトリクエスト」を発行します。この時、サーバーに対して「これからこのメソッドを使うよ」と事前に伝える役割を果たすのがAccess-Control-Request-Methodヘッダーです。この仕組みを理解していないと、CORSエラーの原因を特定するのに時間を浪費してしまいます。
基礎知識：プリフライトリクエストとは
ブラウザは、安全性を確保するために、複雑なリクエスト（GET以外や特定のContent-Typeなど）を送る直前に、OPTIONSメソッドを用いた確認用リクエストをサーバーへ送ります。これをプリフライトリクエストと呼びます。
ここでブラウザはAccess-Control-Request-Methodヘッダーを付与し、「実際に送るリクエストではこのメソッドを使います」と宣言します。サーバー側は、そのメソッドが許可されているかを判断し、許可する場合のみレスポンスに「Access-Control-Allow-Methods」を含めて返します。
実装と解決策
実務では、サーバー側の設定でこのリクエストを適切に処理する必要があります。フロントエンド側で特別な実装は不要ですが、サーバー側（Node.js/ExpressやNginxなど）では、OPTIONSメソッドに対して適切なレスポンスを返す設定が不可欠です。
サンプルプログラム：Node.js (Express) での処理例
以下は、Expressを使用してCORSのプリフライトリクエストを適切に処理するためのミドルウェア実装例です。
const express = require(‘express’);
const app = express();
// プリフライトリクエスト（OPTIONS）に対する処理
app.options(”, (req, res) => {
// Access-Control-Request-Methodで送られてきたメソッドを確認し許可する
res.header(‘Access-Control-Allow-Origin’, ‘https://your-frontend-domain.com’);
res.header(‘Access-Control-Allow-Methods’, ‘GET, POST, PUT, DELETE, OPTIONS’);
res.header(‘Access-Control-Allow-Headers’, ‘Content-Type, Authorization’);
// 204 No Contentを返すのが一般的です
res.sendStatus(204);
});
// 通常のリクエスト処理
app.delete(‘/api/data’, (req, res) => {
res.send(‘データが削除されました’);
});
app.listen(3000);
応用・注意点
現場でよくある失敗は、Access-Control-Allow-Methodsの設定漏れです。プリフライトリクエストで送られたメソッドが、サーバー側のAllow-Methodsリストに含まれていない場合、ブラウザは即座にエラーを吐き、実際のリクエストは実行されません。
また、開発環境ではProxy（webpack-dev-serverやViteのproxy設定）を使ってCORSを回避することも多いですが、本番環境では必ずサーバーサイドでの適切なヘッダー制御を行ってください。特に「Access-Control-Allow-Origin」をアスタリスク（）にする際は、セキュリティの観点から本当に許可すべきドメインのみを指定するようにしましょう。
コメント