リクエストとは？場面別の意味とHTTPリクエストの中身を実測

この記事で実際に動かしたもの：127.0.0.1 だけで待ち受ける自作のサーバー3つ（受け取ったバイト列をそのまま記録する Python のサーバー、GET・POST・JSON・エラーを返す Node.js のサーバー、HTTP/2 のサーバー）と Python 標準の http.server に、curl・Playwright から操作した Chromium・Python の requests・Node.js の fetch からリクエストを送り、届いた全文・バイト数・ステータス・エラーの原文を記録しました。

「リクエスト」は、ラジオの曲のリクエストのような日常の言葉でもあり、Web 開発の基本用語でもあります。同じ言葉が場面で違うものを指すため、最初に全体を図にします。Web の HTTP リクエストは、ブラウザが「このページをください」と頼み、サーバーが「どうぞ」とレスポンス（応答）を返す、1往復のやり取りの前半です。

sequenceDiagram
    participant B as ブラウザ
    participant S as サーバー
    B->>S: リクエスト GET /
    S-->>B: レスポンス 200 HTML
    B->>S: リクエスト GET /a.css
    S-->>B: レスポンス 200 CSS

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB の共用マシン）で、curl 8.5.0、Node.js 22.23.4、Python 3.13.18（requests 2.34.2）、Playwright 1.63.0 から動かした Chromium 153.0.8010.12（ヘッドレス）を使いました。サーバーはすべて 127.0.0.1 で待ち受けさせた自作のものと Python 標準の http.server で、外部のサーバーにはリクエストを送っていません。ブラウザの送信内容は Chrome DevTools Protocol の Network イベントと、受け取った側で記録したバイト列の両方で確かめています。開発者ツールの画面の操作（ネットワークパネルの開き方・Headers や Payload のタブ・Copy as cURL）は、ヘッドレスでは画面を操作できないため Chrome for Developers の公式ドキュメントで確かめた範囲を書きました。メソッドの定義と性質は MDN と RFC 9110、プルリクエストの定義は GitHub Docs、マージリクエストは GitLab Docs で確かめています。図は mermaid-cli で描画を確かめました（確認日 2026年10月29日）。

リクエストとは（ふだんの意味とITでの意味）

この節では、「リクエスト」という言葉のふだんの意味と、IT・プログラミングで使うときの意味の違いが分かります。

リクエスト（request）は、英語で「頼む・求める」、名詞では「要望・依頼」を表す言葉です。国語辞典では、要求・要望のほかに、ラジオやテレビの番組で聴く人が曲を指定して放送を頼むこと、という意味も載っています。「曲をリクエストする」「リクエストにお応えして」の使い方です。

IT では、この「頼む」がコンピューターどうしのやり取りになります。頼む側（クライアント）が「この処理をしてほしい」「このデータがほしい」という内容を決まった形で送り、頼まれた側（サーバー）が結果を返します。人どうしの依頼と違い、形式が少しでも違うと相手は読めないため、どこに何を書くかが細かく決まっています。

ふだんの意味と IT の意味は、「相手に何かを求めて送る」という芯は同じです。違いは、IT では送る内容の形が決まっていて、返事（レスポンス）が必ず1つ返ってくる点です。返事が来ないときは「時間切れ（タイムアウト）」というエラーとして扱われます。

場面別のリクエストの意味（HTTP・API・プルリクエストほか）

この節では、IT の文書や会話で「リクエスト」と出てきたときに、どの意味かを見分ける方法が分かります。

IT の「リクエスト」は、前後に付く言葉で意味が決まります。単に「リクエスト」とだけ書かれていれば、Web 開発の文脈では HTTP リクエストを指すことがほとんどです。代表的なものを並べました。

このほかにも、IT サービス管理（ITSM）で「パスワードを再発行してほしい」「PC を用意してほしい」などの定型の依頼をサービスリクエストと呼び、製品への機能の要望をフィーチャーリクエストと呼びます。英語の略語では、提案依頼書を RFP（Request for Proposal）、インターネットの技術仕様の文書を RFC（Request for Comments）と呼びます。HTTP の仕様も RFC 9110 などの RFC として公開されています。

プルリクエストについて、GitHub Docs は「プル要求は、コードの変更をプロジェクトにマージするための提案です。」と定義しています。名前に「リクエスト」が付きますが、HTTP リクエストとは仕組みも目的も別のものです。説明文の書き方やテンプレートは、関連記事「プルリクエストの書き方｜レビューされやすい説明文とテンプレート」で扱っています。

割り込み要求は、Linux なら /proc/interrupts で、装置ごとに CPU が受け取った回数を見られます。手元のマシンでは次のように表示されました（先頭の4行）。

$ head -4 /proc/interrupts
           CPU0       CPU1
 24:          1          0  IO-APIC   5-edge      ACPI:Ged
 25:          0          1  IO-APIC   6-edge      ACPI:Ged
 26:          4          0  IO-APIC   4-edge      ttyS0

以降は、検索で最も多く調べられている HTTP リクエストを中心に、中身を実物で見ていきます。

HTTPリクエストとは（リクエストとレスポンスの流れ）

この節では、HTTP リクエストがどんな流れで送られ、レスポンスとどう対になっているかが分かります。

HTTP リクエストは、HTTP という通信の約束ごとに従って、クライアントがサーバーへ送る要求です。HTTP では、クライアントが先にリクエストを送り、サーバーはそれに対してレスポンスを1つ返します。サーバーから先に話しかけることはありません。MDN の「HTTP メッセージ」では、HTTP のメッセージにはリクエストとレスポンスの2種類があると説明されています。

ブラウザでページを1枚開くときの流れを、手元の実験で順番に並べると次のとおりです。

1. 1URL からサーバーの場所を調べるドメイン名を DNS で IP アドレスに変える（今回は 127.0.0.1 を直接指定）
2. 2サーバーと接続するTCP の接続を作る。curl -v の「Connected to」の行がこれ。HTTPS ならここで暗号化の準備も
3. 3HTML のリクエストを送るGET / HTTP/1.1 とヘッダーを送る
4. 4レスポンスを受け取る200 OK と HTML の本文が返る
5. 5HTML に書かれた部品を、1つずつリクエストするCSS・JavaScript・画像ごとに別のリクエストが出る（実験では合計4件）

HTTP は「ステートレス」で、リクエストは1件ずつ独立しています。前のリクエストでログインしたことを、サーバーは HTTP の仕組みだけでは覚えていません。そのため、ブラウザは Cookie というヘッダーに目印を入れて毎回送り、サーバーはそれを見て同じ人だと判断します。

ステータスコード（200・404・500 などの3桁の結果番号）は、レスポンスの側に入る情報です。番号ごとの意味と対処は、関連記事「HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき」にまとめています。この記事ではリクエストの側に絞ります。

HTTPリクエストの中身（リクエスト行・ヘッダー・空行・本文）

この節では、HTTP リクエストが実際にはどんな文字の並びで送られているかを、届いたバイト列そのもので確かめられます。

HTTP/1.1 のリクエストは、人が読める文字の並びです。受け取ったバイト列を加工せずに記録する小さなサーバーを作り、curl で JSON を POST したときに届いた全文が次です（行末の改行は CR LF の2バイト）。

POST /api/users HTTP/1.1
Host: 127.0.0.1:18233
User-Agent: curl/8.5.0
Accept: */*
Content-Type: application/json
Content-Length: 24

{"name":"taro","age":20}

このリクエストは4つの部分でできています。MDN の説明と、届いた実物を対応させました。

記録したサーバーの集計では、このリクエストは164バイト（ヘッダーまで140バイト、本文24バイト）でした。Content-Length: 24 は本文の長さで、サーバーはこの数字を見て「どこまでが本文か」を判断します。

よく見るリクエストヘッダー

ヘッダーの名前は大文字と小文字を区別しません（実験でも Node.js の fetch は host: と小文字で送っていました）。よく出てくるものを、意味と実験での値で並べます。

Host を外して HTTP/1.1 のリクエストを手で送ると、Node.js のサーバーは HTTP/1.1 400 Bad Request を返しました。「HTTP/1.1 では必須」という決まりが、実際に守られていることが分かります。API の文書では、本文のことを「ペイロード」と呼ぶこともあります。

curl -v でHTTPリクエストを見る（自分で確かめる1）

この節では、ターミナルの1行で、自分が送るリクエストと返ってくるレスポンスを見る方法が分かります。

curl に -v（verbose＝詳しく表示）を付けると、送ったリクエストと受け取ったレスポンスの頭の部分が表示されます。行頭の記号で区別でき、> が送ったもの、< が受け取ったもの、* が curl 自身の説明です。手元のサーバーに送った結果が次です（Date の行は省略）。

$ curl -v http://127.0.0.1:18234/search?q=request
*   Trying 127.0.0.1:18234...
* Connected to 127.0.0.1 (127.0.0.1) port 18234
> GET /search?q=request HTTP/1.1
> Host: 127.0.0.1:18234
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
<
* Connection #0 to host 127.0.0.1 left intact
検索: request

この出力から、リクエストはリクエスト行と3行のヘッダー、空行だけで、本文が無いことが分かります。受け取った側の記録では 94バイトでした。> の最後の空の行が、前の節の「空行」にあたります。

POST のリクエストも同じように見られます。-d を付けると curl は自動で POST になり、Content-Type を application/x-www-form-urlencoded（フォームと同じ形式）にします。JSON を送るときは -H 'Content-Type: application/json' を自分で付けます。付け忘れたときにどうなるかは、後の症状表で実物を示します。

curl のオプション全体（-X・-H・-d・-i など）は、関連記事「curlコマンドの使い方とオプション一覧｜エラー対処・Windows・wget比較」で扱っています。

ブラウザが送るHTTPリクエスト（自分で確かめる2）

この節では、ブラウザでページを1枚開いたときに、いくつのリクエストがどんな中身で送られているかと、開発者ツールでそれを見る手順が分かります。

ページを1枚開くだけで、リクエストは1件では済みません。CSS 1つ・JavaScript 1つ・画像1枚を読み込む小さなページを用意し、Chromium で開いたときに送られたリクエストを記録しました。

GET     Document   http://127.0.0.1:18234/
GET     Stylesheet http://127.0.0.1:18234/style.css
GET     Script     http://127.0.0.1:18234/app.js
GET     Image      http://127.0.0.1:18234/logo.png

HTML を受け取ったあと、ブラウザは HTML の中の link・script・img を見つけて、部品ごとに別々のリクエストを送りました。実際のサイトでは、広告・解析・フォント・アイコンなどで1ページに数十件から100件を超えるリクエストが出ることも珍しくありません。

最初の HTML のリクエストで Chromium が送ったヘッダーは次のとおりです。届いた側の記録では 661バイトあり、curl の GET（94バイト）の約7倍でした。

GET /hello HTTP/1.1
Host: 127.0.0.1:18233
Connection: keep-alive
sec-ch-ua: "HeadlessChrome";v="153", "Not_A Brand";v="8", "Chromium";v="153"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/153.0.8010.12 Safari/537.36
Accept-Language: ja-JP
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd

Sec-Fetch- で始まるヘッダーは、「アドレスバーから開いたページか（navigate）」「どのサイトからのリクエストか（none＝直接入力）」をサーバーに伝えるものです。sec-ch-ua はブラウザの名前と版をまとめて伝えるヘッダーで、ヘッドレスで動かしたため HeadlessChrome と出ています。ふだんの Chrome では Google Chrome などになります。

開発者ツールでリクエストを見る手順

Chrome と Edge の開発者ツールでは、同じ情報を画面で見られます。Chrome for Developers の公式ドキュメントにある操作を、順番に並べました。

Copy as cURL で写したコマンドには、Cookie や Authorization の値がそのまま入ります。チャットやチケットに貼る前に、その部分を消しておくのが安全です。開発者ツールのほかの機能は、関連記事「Chrome DevToolsの使い方｜デバッグ手順と便利機能一覧」で扱っています。

コンソールの1行でリクエストの数を数える

ネットワークパネルを開く前に読み込みが終わってしまったページでも、コンソール（Console タブ）に次の1行を入れると、そのページが読み込んだ部品の数と中身を確かめられます。

performance.getEntriesByType('resource').length

実験のページでは 3 が返りました。最初の HTML 自体はこの一覧に入らないため、ネットワークパネルの4件より1つ少なくなります。URL・種類・かかった時間（ミリ秒）・転送量（バイト）まで見るときは、次のようにします。

performance.getEntriesByType('resource').map(r =>
  [r.name.replace(location.origin, ''), r.initiatorType, Math.round(r.duration * 10) / 10, r.transferSize])
// 実験での結果
// [["/style.css","link",13.8,314],["/app.js","script",17,325],["/logo.png","img",16.5,366]]

送る道具でリクエストはどう変わるか（curl・Chromium・Python・Node.js）

この節では、同じ「HTTP リクエスト」でも、送るソフトによってヘッダーと大きさがどれだけ違うかが分かります。

メソッドと URL が同じでも、ヘッダーは送るソフトが自分で決めて足します。同じ記録用のサーバーに、4つの道具からリクエストを送りました。

Python の requests と Node.js 22 の fetch で、同じ JSON を POST したときに届いた全文です。

POST /api/users HTTP/1.1
Host: 127.0.0.1:18233
User-Agent: python-requests/2.34.2
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 16
Content-Type: application/json

{"name": "taro"}

POST /api/users HTTP/1.1
host: 127.0.0.1:18233
connection: keep-alive
Content-Type: application/json
accept: */*
accept-language: *
sec-fetch-mode: cors
user-agent: node
accept-encoding: gzip, deflate
content-length: 15

{"name":"taro"}

同じ {"name":"taro"} でも、Python の requests は {"name": "taro"} と空白を入れて16バイト、Node.js は15バイトで送りました。サーバー側でバイト単位の比較（署名の検証など）をするときは、この差で結果が変わることがあります。また、User-Agent でアクセスを振り分けているサーバーでは、ブラウザでは開けるのに curl やプログラムからだと結果が違うということが起きます。そのときは、ブラウザで Copy as cURL したコマンドと、自分のコマンドのヘッダーを並べて比べると原因に近づけます。

GETとPOSTの違い（実測：URL・履歴・ログへの残り方）

この節では、HTTP リクエストのメソッドで最もよく使う GET と POST の違いと、使い分けの目安が分かります。

GET は「取得」、POST は「送信」のためのメソッドです。MDN は、GET は「指定したリソースの表現をリクエストします」「データの取得のみを行うべき」、POST は「サーバー上の状態を変更したり、副作用が発生したりすることがよくあります」と説明しています。値の載せ方の違いを、同じページに置いた2つのフォームで確かめました。

サーバーのアクセスログにも違いが出ます。Python 標準の http.server に、同じ値を GET と POST で送ったときのログです（日時は省略）。

127.0.0.1 - - [日時] "GET /?user=taro&pass=secret123 HTTP/1.1" 200 -
127.0.0.1 - - [日時] "POST /login HTTP/1.1" 501 -

GET で送った値は、アクセスログに URL ごと残りました。POST の本文はログに出ていません（http.server は POST を受け付けないため 501 を返していますが、記録される行は同じ形です）。パスワードや個人情報を GET で送ると、ブラウザの履歴・サーバーのログ・中継するプロキシのログなど、思わぬ場所に残ります。

ブラウザで POST のフォームを送ったあとのページを再読み込みすると、「フォームを再送信しますか」という確認が出るのは、POST をもう一度送ると結果が変わるかもしれないためです。

HTTPリクエストのメソッド一覧（安全・冪等の違い）

この節では、GET・POST 以外のメソッドの意味と、「安全」「冪等（べきとう）」という性質の違いが分かります。

メソッドは、リクエスト行の先頭に書く「何をしたいか」を表す単語です。HTTP の仕様（RFC 9110）で定義され、MDN の一覧では次の9つが説明されています。性質の欄は MDN の表のとおりです。

• 安全：サーバーのデータを変えないこと。GET を何回送っても、データは増えも減りもしない前提です。
• 冪等：同じリクエストを1回送っても複数回送っても、サーバーの最終的な状態が同じになること。DELETE で同じものを2回消しても「消えている」状態は同じなので冪等です。POST で注文を2回送ると注文が2件になるので冪等ではありません。

この性質は、通信が途中で切れたときに自動でやり直してよいかの判断に使われます。冪等なリクエストはやり直しても害が無く、POST は二重登録を防ぐ工夫（一意の番号を付けて、同じ番号の2回目を無視するなど）が要ります。

HEAD は curl の -I で送れます。届いた全文は HEAD / HTTP/1.1 とヘッダー3つの79バイトで、レスポンスもヘッダーだけが返りました。ファイルの大きさや更新日時だけを知りたいときに使えます。REST API でメソッドをどう割り当てるかや、1画面を作るのに何回リクエストが要るかの比較は、関連記事「GraphQLとRESTの違い｜同じ画面を両方で作ってリクエスト数を実測」で扱っています。

HTTP/2・HTTP/3でのリクエストの形（疑似ヘッダー）

この節では、HTTP/2 以降でリクエストの見た目がどう変わるのかと、変わらない部分が分かります。

HTTP/2 と HTTP/3 では、リクエストは人が読める文字ではなく、バイナリのフレームとして送られます。1行目のリクエスト行は無くなり、代わりにコロンで始まる「疑似ヘッダー」（:method・:scheme・:authority・:path）で同じ情報を運びます。Node.js で HTTP/2 のサーバーを立て、curl から HTTP/2 で送った結果が次です。

$ curl -v --http2-prior-knowledge http://127.0.0.1:18237/search?q=request
* [HTTP/2] [1] OPENED stream for http://127.0.0.1:18237/search?q=request
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: http]
* [HTTP/2] [1] [:authority: 127.0.0.1:18237]
* [HTTP/2] [1] [:path: /search?q=request]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET /search?q=request HTTP/2
> Host: 127.0.0.1:18237
...
< HTTP/2 200
< content-type: text/plain

サーバー側で受け取ったヘッダーを出力すると {":method":"GET",":scheme":"http",":authority":"127.0.0.1:18237",":path":"/search?q=request","user-agent":"curl/8.5.0","accept":"*/*"} でした。HTTP/1.1 の GET /search?q=request HTTP/1.1 と Host: が、4つの疑似ヘッダーに分かれただけで、メソッド・URL・ヘッダー・本文という中身の考え方は同じです。MDN も、HTTP/2 と HTTP/3 でもメソッド・ステータスコード・ヘッダーの意味は変わらないと説明しています。

curl -v が > GET ... HTTP/2 と1行目を表示しているのは、人が読みやすいように HTTP/1.1 風に書き直しているためです。開発者ツールの Headers でも同じように表示されます。HTTP/2 ではヘッダーが圧縮され、1本の接続で複数のリクエストを並行して送れるため、前の節で見た「1ページに何十件ものリクエスト」を速く処理できます。

リクエストが失敗するときの症状表（エラー原文つき）

この節では、リクエストが失敗したときに出る文言から、原因がどこにあるかを見分ける方法が分かります。

失敗は「届かなかった」か「届いたが断られた」かで、最初に大きく分かれます。届かなかったときはステータスコードが返らず、curl の終了コードやブラウザの net:: で始まる文言になります。届いて断られたときは、400番台・500番台のステータスコードが返ります。手元で起こした失敗を並べました。

JavaScript の fetch では、接続できなかったときも、CORS で止められたときも、どちらも TypeError: Failed to fetch でした。プログラムからは区別できず、違いが分かるのはコンソールに出た次の文言だけです。

Access to fetch at 'http://127.0.0.1:18236/' from origin 'http://127.0.0.1:18235' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Failed to load resource: net::ERR_FAILED
Failed to load resource: net::ERR_CONNECTION_REFUSED

CORS の文言ごとの直し方は、関連記事「CORSエラーの原因と解決方法｜エラーメッセージ別に解説」で扱っています。なお、別オリジンへ JSON を POST したとき、Chromium は本物の POST の前に OPTIONS のリクエスト（プリフライト）を自動で1件送りました。ネットワークパネルで「自分が書いていない OPTIONS のリクエスト」が見えても、異常ではありません。

OPTIONS Other      http://127.0.0.1:18234/api/items
POST    Fetch      http://127.0.0.1:18234/api/items
   body: {"name":"note"}

URL とヘッダーの長さの上限を測る

「GET の URL はどこまで長くできるか」は、ブラウザではなくサーバーの設定で決まることが多い値です。手元の2つのサーバーで、クエリ文字列の長さを変えて測りました。

Node.js の上限は URL とヘッダーを合わせた大きさ（require('http').maxHeaderSize が 16384）で決まるため、URL が長いときも Cookie が大きいときも同じ 431 になりました。つまり、同じ URL でも Cookie がたまっている人だけ 431 になることがあります。見る側で「このサイトだけ開けない」ときに Cookie を消すと直ることがあるのは、このためです。

1. 1ステータスコードが返っているか返っていなければ「届いていない」。サーバー・ポート・回線・プロキシを見る
2. 2ブラウザだけで起きるかcurl で同じ URL が通るなら、CORS・拡張機能・キャッシュなどブラウザ側
3. 3400番台なら、リクエストの中身を見るメソッド・URL・Content-Type・本文の形・大きさを、開発者ツールの Headers と Payload で確かめる
4. 4500番台なら、サーバーのログを見るリクエストは届いて読めている。原因はサーバーの中にある

リクエストを確かめる道具の判断表と、よくある誤解

この節では、自分の状況でどの道具を使ってリクエストを確かめればよいかと、初めて学ぶときに誤解しやすい点が分かります。

よくある誤解

• 1「ページを開く＝リクエスト1回」ではない実験の小さなページでも4件。部品ごとにリクエストが出る
• 2POST にすれば中身が隠れるわけではないURL に出ないだけで、開発者ツールの Payload には見える。通信の暗号化は HTTPS の役目
• 3Failed to fetch は「サーバーが落ちている」とは限らないCORS で止められたときも同じ文言だった。コンソールの次の行で見分ける
• 4プルリクエストは HTTP リクエストの一種ではないGit の変更を取り込んでもらう提案。名前が似ているだけの別の仕組み
• 5見慣れない OPTIONS は不具合ではない別オリジンへ JSON を送るとき、ブラウザが自動で送るプリフライト

API の利用料金が「リクエスト数」で決まるサービスでは、1画面を開くたびに何件のリクエストが出ているかがそのまま費用になります。ネットワークパネルの件数を一度数えておくと、見積もりのずれを防げます。

よくある質問

この節では、リクエストについて検索でよく調べられる疑問に、短く答えます。

Q. リクエストを簡単に言うと何ですか。
A. 相手に「これをしてほしい」と求めて送る要求です。Web では、ブラウザやアプリがサーバーへ「このページやデータをください」「このデータを受け取ってください」と送る HTTP リクエストを指すことがほとんどです。

Q. リクエストとレスポンスの違いは何ですか。
A. 頼むのがリクエスト、答えるのがレスポンスです。HTTP では必ずクライアントがリクエストを先に送り、サーバーがそれに対してレスポンスを1つ返します。ステータスコード（200・404 など）はレスポンスの側に入ります。

Q. HTTP リクエストには何が入っていますか。
A. リクエスト行（メソッド・URL・HTTP の版）、ヘッダー（Host・User-Agent・Content-Type など）、空行、本文の4つです。実験の curl の GET は本文が無く94バイト、JSON の POST は本文24バイトを含めて164バイトでした。

Q. GET と POST はどう使い分けますか。
A. データを見るだけなら GET、データを登録・変更・送信するなら POST です。パスワードや個人情報は、URL・履歴・ログに残らないよう POST で、HTTPS のページから送ります。

Q. リクエストの中身を自分で見るにはどうすればよいですか。
A. ブラウザなら F12 で開発者ツールを開き、Network タブでページを再読み込みしてリクエストを選びます。ターミナルなら curl -v URL の > で始まる行が、送ったリクエストです。

Q. プルリクエストとは何ですか。HTTP リクエストと関係ありますか。
A. Git で作った変更を、元のプロジェクトに取り込んで（マージして）もらうための提案です。GitLab ではマージリクエストと呼びます。名前は似ていますが、HTTP リクエストとは別の仕組みです。

Q. 「リクエストが多すぎます」と出るのはなぜですか。
A. 短い時間に送るリクエストの数が、サービスの決めた上限を超えたときに出る表示で、HTTP では 429 Too Many Requests というステータスコードで返されます。少し時間をおいてから送り直します。

Q. 「Failed to fetch」はどういう意味ですか。
A. JavaScript の fetch がレスポンスを受け取れなかったという意味です。実験では、サーバーにつながらないときも、CORS で止められたときも同じ文言でした。コンソールに出る次の行（ERR_CONNECTION_REFUSED や blocked by CORS policy）で原因を見分けます。

Q. HTTPS のリクエストは HTTP と中身が違いますか。
A. 中身（メソッド・URL・ヘッダー・本文）の形は同じで、それを暗号化して運ぶのが HTTPS です。通信の途中では読めませんが、送ったブラウザ自身の開発者ツールや、受け取ったサーバーでは元の形で見られます。

Q. API リクエストと HTTP リクエストは違うものですか。
A. 多くの Web API は HTTP で呼び出すため、API リクエストの中身はたいてい HTTP リクエストです。プログラムが API を呼ぶ場面を強調するときに「API リクエスト」と呼ぶ、と考えると分かりやすいです。

まとめ

• リクエストは「相手に何かを求めて送る要求」。IT では前後の言葉で意味が決まり、Web では HTTP リクエスト、Git ではプルリクエスト（GitLab ではマージリクエスト）を指す。
• HTTP リクエストはリクエスト行・ヘッダー・空行・本文の4つでできた文字の並び。実測では curl の GET が94バイト、Chromium でページを開くと661バイトで、送るソフトによってヘッダーが大きく違う。
• ページを1枚開くと、HTML・CSS・JavaScript・画像ごとにリクエストが出る（実験の小さなページでも4件）。別オリジンへ JSON を送ると、ブラウザは OPTIONS のプリフライトを自動で足す。
• GET は値を URL に載せ、履歴やアクセスログに残る。POST は本文に載せる。パスワードは POST で、HTTPS のページから送る。
• 失敗はまず「ステータスコードが返ったか」で分ける。Failed to fetch は接続失敗と CORS で同じ文言なので、コンソールとネットワークパネル、curl -v で中身を確かめる。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN Web Docs「HTTP メッセージ」：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Messages
• MDN Web Docs「HTTP リクエストメソッド」：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Methods
• IETF「RFC 9110: HTTP Semantics」：https://www.rfc-editor.org/rfc/rfc9110.html
• Chrome for Developers「Network features reference」：https://developer.chrome.com/docs/devtools/network/reference
• Chrome for Developers「Open Chrome DevTools」：https://developer.chrome.com/docs/devtools/open
• GitHub Docs「Pull Request」：https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
• GitLab Docs「Merge requests」：https://docs.gitlab.com/user/project/merge_requests/
• Node.js Documentation「HTTP」（http.maxHeaderSize）：https://nodejs.org/api/http.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。