Webの仕組み（HTTP・HTTPS）｜情報Ⅰ 最強120講義 第74講

こんにちは、数強塾代表の藤原進之介です。『最強120講義』第74講は、共通テスト重要度Aの「Webの仕組み（HTTP・HTTPS）」です。

この講で扱うのは、第68講で見たTCP/IPの4階層のうち、いちばん上のアプリケーション層にあるHTTPという1つのプロトコルだけです。階層の話はもう終わっているので、ここでは「Webページが表示される瞬間に、何という文字列が行き来しているのか」に絞ります。そして本講の山場は「なぜHTTPは忘れっぽいのか」という一点です。

1. HTTPは「1回で完結する」ように作られている

HTTPの仕様は RFC 9110「HTTP Semantics」（IETF、Standards Track、STD 97、2022年6月）にまとまっています。その冒頭の一文が、この講のすべてです。

ステートレス（stateless）＝状態を持たない。 同じ文書の第3.3節は、その意味をこう定義しています。「HTTPはステートレスなプロトコルとして定義される。つまり、それぞれの要求メッセージの意味は、単独で理解できる」。

1通の要求は、前の要求を見なくても、後ろの要求を見なくても、それだけで意味が分かる。これがステートレスの定義です。

▲ HTTPの1往復。②が終わった時点でサーバの記憶は消える。③で名乗り直しているのがCookie。

2. なぜ忘れる設計にしたのか ── その見返り

「覚えていない」のは欠陥ではありません。わざとそうしました。 RFC 9110 は、その見返りをはっきり書いています。

ここが本講の核心です。要求が単独で意味を持つなら、その要求はどのサーバに渡しても処理できます。 1通目をAサーバ、2通目をBサーバが処理してかまわない。だから何百台にも要求をばらまける。

もし「この人の前回を覚えている特定のサーバでないと処理できない」設計だったら、利用者を毎回同じ1台に戻さなければなりません。そんな仕組みでは、世界中からアクセスされるサイトは物理的に成立しません。

ステートレスは、Webが地球規模になれた理由そのものです。 「忘れっぽさ」と「膨大な相手を捌ける能力」は、同じ設計の表と裏です。

RFC 9110 はさらに、実装者にこう命じます。「サーバは、同じ接続で届いた2つの要求が同じ利用者からのものだと仮定してはならない（MUST NOT）」。つまりサーバは、原理的に相手を覚えていないのです。

3. 代償 ── だからCookieが必要になった

しかしそれでは、ログインが成立しません。ログイン画面でIDとパスワードを送っても、次のページを要求した瞬間、サーバにとっては初対面だからです。

この穴を埋めるために作られたのがCookieで、規格は RFC 6265「HTTP State Management Mechanism」（IETF、2011年4月）。その要旨が、成り立ちを正直に書いています。

つまりCookieは、HTTPの一部として最初からあったのではありません。ステートレスにした代償を払うために、後から乗せた仕組みです。手順は3つだけです。

• サーバが応答に Set-Cookie: を付け、「この番号（セッションID）を持っておけ」と渡す
• ブラウザはそれを保存し、次からの要求に Cookie: を付けて自分から名乗る
• サーバは受け取った番号を手元の台帳（セッション）と突き合わせ、「ああ、さっきの人だ」と分かる

サーバが覚えているのではありません。利用者が毎回、自分の名札を持参しているのです。 これがWebのログインの正体です。

だからこの設計には副作用があります。名札を盗まれれば、盗んだ人が本人になりすませる。RFC 6265 自身が「cookieはセキュリティとプライバシーを損なう歴史的な不備を多く抱えている」と認めています。

4. URLの構造と、クエリに書いてはいけないもの

要求のあて先を表すのがURLです。一般形は RFC 3986（STD 66、2005年1月）が定めていて、5つの部品に分かれます。

▲ URLの5部品。省略時のポートは http が80番、https が443番。

総務省の「国民のためのサイバーセキュリティサイト」も、この分解を自分のURLで説明しています。https://www.soumu.go.jp/joho_tsusin/joho_tsusin.html を例に、「https」は「Webサイトの閲覧に使用されるHTTPSというプロトコル」、「www.soumu.go.jp」は「Webサーバを指定」、その後ろは「Webサーバの中のホームページの情報が保存されている場所」と書いています。

個人情報をクエリ文字列に入れてはいけない理由

ここは受験でも実生活でも効きます。RFC 3986 は第7.5節「Sensitive Information」で、理由を3つ挙げて禁じています。

HTTPSで暗号化しても、この3つは防げません。 暗号化されるのは「通信路」であって、送信元のブラウザの中と受信先のサーバの中では平文だからです。クエリに書いた個人情報は、サーバのアクセスログに何年も残り続けます。個人情報はクエリではなく、本体（POST）に入れる。 これが原則です。

同じRFCの第7.6節は、@ を使ってホスト名の前に別の文字列を置き、信頼できる組織のURLに見せかける手口も挙げています。URLは左から順に読むのではなく、「// の直後から最初の / まで」だけを見る。 そこがホスト名です。上の図で緑の部分だけを見る、と覚えてください。

5. HTTPSが守る3つ、守らない1つ

HTTPSは「HTTPをTLSの上で流したもの」です。では何が保証されるのか。「なんとなく安全になる」で済ませている人が多いのですが、RFC 9110 の第4.2.2節は “secured” の意味を厳密に定義しています。

この3つに「このサイトの運営者は誠実である」は入っていません。 サーバ証明書が証明しているのは「このサーバは確かに example.com というホスト名の持ち主だ」ということだけで、example.com が詐欺サイトかどうかは一言も証明していません。

だから詐欺サイトも、正当にHTTPSを取れます。 「そのホスト名の持ち主である」ことは、詐欺師にとっても真実だからです。鍵マークは「この通信は覗かれていない」の印であって、「この相手は信用できる」の印ではありません。 鍵マークが保証するのは、あなたが打ち込んだカード番号が、途中で誰にも読まれずに確実に詐欺師のもとへ届くことです。

守るべきは通信路ではなく、そもそもホスト名が本物かという判断で、これは人間の側の仕事として残ります。ここが第4節の「ホストだけを見る」につながります。

なお、暗号そのものの原理（共通鍵暗号・公開鍵暗号・デジタル署名）は本連載の第16講・第17講で扱います。本講は「HTTPSが何を守っているか」に絞りました。『最強120講義』の全体像はこちらから追えます。

もう1つ。RFC 9110 は「httpスキームで提供される資源と httpsスキームで提供される資源は同一性を共有しない。両者は別個のオリジンである」とも定めています。http://example.com/ と https://example.com/ は、規格上まったく別物です。「同じサイトの安全版」ではありません。

6. 手で確かめる ── curl -I でHTTPを読む

ここからは手を動かします。curl -I（大文字のアイ）は、本体を受け取らずヘッダだけを取りに行くコマンドです。以下はすべて私が実際に実行して出力を確認したものです。

まず、要求はただの文字列である

自分のパソコンの中に小さなサーバを立て、ブラウザ（ここでは curl）が実際に送っている文字列を覗きました。

GET /joho1-http/?q=test HTTP/1.1
Host: 127.0.0.1:8933
User-Agent: curl/8.7.1
Accept: */*
Accept-Language: ja

1行目が要求行（メソッド／パス＋クエリ／バージョン）、2行目以降が要求ヘッダ。これだけです。HTTPは、人が読める文字列のやり取りにすぎません。

200 ── 成功

$ curl -s -I https://sukyojuku.com/joho1-protocol-tcpip/
HTTP/2 200
date: Sun, 02 Aug 2026 19:29:12 GMT
content-type: text/html; charset=UTF-8
server: Apache
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin

1行目がステータス行。RFC 9110 は 200 を「要求は成功した」と定義します。

301 と 302 ── 引っ越し（恒久 と 一時）

$ curl -s -I https://sukyojuku.com/joho1-protocol-tcpip
HTTP/2 301
location: https://sukyojuku.com/joho1-protocol-tcpip/

末尾の / を落としただけで 301 が返り、location: に正しいURLが入りました。301 は「このリソースには新しい恒久的なURIが割り当てられた」という意味です。ブラウザはこれを読んで自動的に行き先を変えます。私たちが普段「勝手に転送された」と感じているものの正体が、この2行です。

公的機関の例も見てみましょう。

$ curl -s -I http://www.mext.go.jp/
HTTP/1.0 302 Moved Temporarily
Location: https://www.mext.go.jp/
$ curl -s -I http://www.soumu.go.jp/
HTTP/1.1 301 Moved Permanently
Location: https://www.soumu.go.jp/

同じ「httpからhttpsへの転送」でも、文部科学省は 302（一時的）、総務省は 301（恒久的） を返しています。301 は「ブックマークを書き換えてよい」、302 は「今回だけこっちへ行け、URLは変えるな」。 番号を暗記するのではなく、この違いを覚えてください。

404 ── 見つからない

$ curl -s -I https://sukyojuku.com/kono-page-wa-arimasen/
HTTP/2 404
content-type: text/html; charset=UTF-8

RFC 9110 の定義が面白いところです。404 は「現在の表現が見つからなかった、または存在することを明かしたくない」。「無い」と「有るが教えない」の両方を含みます。会員専用ページが404を返すのは、故障ではなく仕様なのです。

500 ── サーバ側が転んだ

500 は他人のサイトで意図的に起こすものではないので、自分のパソコンの中に「必ず500を返すサーバ」を立てて確認しました。

$ curl -s -I http://127.0.0.1:8931/kowareta
HTTP/1.0 500 Internal Server Error
Server: BaseHTTP/0.6 Python/3.9.6
Content-Type: text/plain; charset=utf-8

500 は「サーバが予期しない状況に遭遇し、要求を果たせなかった」。ここで一気に整理できます。

RFC 9110 は「クライアントは登録済みのコードを全部理解する必要はないが、先頭の1桁が示すクラスは必ず理解しなければならない（MUST）」と定め、知らない番号は同じクラスの x00 として扱えとしています（471 を受け取ったら 400 とみなす）。有効な範囲は100〜599。つまり規格自身が「3桁を丸暗記するな、先頭1桁を読め」と言っているのです。

ステートレスとCookieを、目で見る

最後に、本講の主張を実験で確かめます。「Cookieを持っていない相手には Set-Cookie を渡し、持っている相手には名前で呼びかける」サーバを自分のパソコンに立て、3回叩きました。

$ curl -s -D - -o /dev/null -c jar.txt http://127.0.0.1:8932/   # 1回目・ヘッダだけ見る
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.9.6
Date: Sun, 02 Aug 2026 19:39:11 GMT
Content-Type: text/plain; charset=utf-8
Set-Cookie: sid=abc123; Path=/

初対面なので、サーバが Set-Cookie: で名札を渡してきました。-c jar.txt は「もらったCookieをこのファイルに保存せよ」の意味です。中身はこうなっています。

$ cat jar.txt
127.0.0.1	FALSE	/	FALSE	0	sid	abc123

では、この名札を持って（-b jar.txt）もう一度、そして持たずにもう一度、同じURLを叩きます。

$ curl -s -b jar.txt http://127.0.0.1:8932/          # 2回目・名札あり
おかえりなさい。あなたは sid=abc123 の人ですね。
$ curl -s http://127.0.0.1:8932/                    # 3回目・名札なし
はじめまして。あなたに sid=abc123 を渡します。

同じサーバ、同じURL、同じ1台のパソコンから。違うのは、要求に Cookie: が付いているかどうかだけです。

3回目で「はじめまして」に戻ったことが、ステートレスの証明です。サーバは相手を覚えていない。覚えているように見えるのは、こちらが名札を持参しているからにすぎない。 ログアウトボタンが機能すること、ブラウザを閉じたら再ログインになること、シークレットウィンドウでは未ログインになること ── すべてこの1点から説明がつきます。

7. 共通テストではこう出る（重要度 A）

情報Ⅰの「(4) 情報通信ネットワークとデータの活用」は毎年出題されます。HTTP・HTTPS・URLは、知識単独よりも「読み取り」と「判断」の形で問われます。

大学入試センターが公表した「令和7年度大学入学共通テスト 試作問題『情報』の概要」では、第1問 問1 の概要が「情報社会の中で日常的に利用されるSNSやメール、Webサイトなどの利用時の注意点や情報の信ぴょう性の判断について理解しているかを問う」と説明されています。「Webサイトを安全に使えるか」は、はっきり出題の対象です。

出題の型

• URLの読み取り。 与えられたURLからスキーム・サーバ名・パラメータを読み分ける。とくに似せたホスト名を見抜けるか
• ステータスコードの意味。 番号そのものより「4xxか5xxか」＝どちら側の問題かの判断
• HTTPSの理解。 「HTTPSなら安全なサイトである」型の誤りを選ばせる
• クライアントとサーバの役割分担。 どちらが要求し、どちらが応答し、処理はどちらで行われるか

役割分担の整理

引っかけの急所

「鍵マークが出ているから安全なサイト」は誤り。 通信路が暗号化されているだけで、詐欺サイトもHTTPSを取れる。
「HTTPSはHTTPと別の層のプロトコル」は誤り。 どちらもアプリケーション層。間にTLSが挟まるだけ。
404はサーバの故障ではない。 サーバは正常に動いていて「無い」と正しく答えている。故障は5xx。
301と302の混同。 恒久的か、一時的か。
「HTTPSだからURLに個人情報を入れても安全」は誤り。 履歴・ブックマーク・プロキシのログに残る。
セッションIDはサーバが「覚えている」のではない。 利用者が毎回持参している。

私が作った類題

8. 情報Ⅱではこうなる

情報ⅠではHTTPとHTTPSは「使う側として理解する」対象でした。情報Ⅱでは、これが「自分が作る側として設計し、実装し、テストする」対象に変わります。文部科学省「情報Ⅱ」教員研修用教材 第4章「情報システムとプログラミング」で追いかけましょう。

(1) Webサーバが「3層のうちの1層」になる（学習19）

学習19「情報システム全体の情報の流れ」は、2層／3層クライアントサーバシステムを扱います。同教材は、当初クライアントのアプリがサーバのデータベースへ直接アクセスして通信負荷が問題になり、そこでクライアントには画面表示などの機能を残し、データ加工をサーバ側に置く3層構成が主流になった、と説明します。サーバの種類の表には、ファイルサーバ・Webサーバ・データベースサーバなどが並びます。

情報Ⅰでは「Webサーバ＝Webページを返す機械」でした。情報Ⅱでは「3層のうち1層を担う部品」になり、どの処理をどの層に置くかが自分の設計判断になります。

(2) クエリ文字列を、自分で組み立てる（学習23）

学習23「分割したシステムの制作とテスト」は、単体プログラムの入出力として「関数への引数や戻り値として渡す」と並べて「ネットワーク通信のメッセージとして渡す」を挙げ、図書検索のWeb APIをPythonから呼ぶ実習を置いています。そのコードが、本講と正面からつながります。

p = urllib.parse.urlencode(params)
url = url + "?" + p
with urllib.request.urlopen(url) as res:
    return json.loads(res.read().decode("utf-8"))

params をURLエンコードして ? で連結し、urlopen に渡す ── これは第4節で見たURLのクエリ文字列を、手で組み立ててGET要求を出すコードそのものです。教材が指定するAPIのURLも https:// で始まり、応答はJSON形式で返ってきます。

情報Ⅰでは「? の後ろはパラメータです」と眺めていた場所に、情報Ⅱでは自分で値を書き込みます。 そのとき、第4節の「秘密をクエリに入れるな」は、他人への注意ではなく自分が守るべき設計ルールに変わります。

(3) SSL/TLSが「暗号方式の表の1行」として出てくる（学習20）

学習20「情報システムの情報セキュリティ」の図表3「データの暗号化の仕組みの例」には、共通鍵暗号方式・公開鍵暗号方式・デジタル署名と並んで、SSL/TLSの行があります。

同じ表で、共通鍵暗号方式と公開鍵暗号方式には「盗聴対策に効果的」、デジタル署名には「改ざん対策に効果的」と、効果が書き分けられています。HTTPSが盗聴・改ざん・なりすましの3つに同時に効くのは、性格の違う道具を組み合わせているからという構造が、ここでようやく見えるようになります。第5節の表の3行が、3種類の技術に対応していたわけです。

(4) HTTPSが「自分のシステムのテスト項目」になる（学習24）

決定的なのは学習24「分割したシステムの結合とテスト」の「セキュリティテスト」です。ここでは、自分が作ったシステムに対して行うテストとして、ブルートフォース攻撃・リバースブルートフォース攻撃・リスト型攻撃、そしてXSS（クロスサイトスクリプティング）とCSRFが並びます。XSSの説明で、本講のCookieが再登場します。

情報Ⅰの「HTTPSのサイトを使いましょう」が、情報Ⅱでは「自分のシステムをHTTPSにし、Cookieが盗まれないかをテストしなさい」に変わります。 守られる側から、守る側へ。第3節で見た「名札を盗まれると本人になりすませる」という副作用が、ここで具体的な攻撃名と対策工程になります。

同じ学習24の「非機能テスト」では、多数のユーザーからアクセスされて負荷が高まっても正常に動くかを見る性能テスト、停電に備える無停電電源装置、ネットワークの二重化が扱われます。これは、第6節で見た 500 Internal Server Error を出さないための工程です。 情報Ⅰでは「サーバ側の失敗を表す番号」だったものが、情報Ⅱでは事前に潰すべき対象になります。

(5) おまけ ── 教える側の教材にも、Webの展開は無い

最後に、教材そのものの話を1つ。文部科学省「情報Ⅰ」教員研修用教材 第4章の学習18には、【学習活動の目的】として「電子メールやWebの仕組みについて、そのプロトコルとともに理解する」が掲げられています。ところが、続く展開1〜3で実際に用意されているのは「プロトコルの必要性」「公衆無線LANの危険性」「安全な接続は不便な接続か」で、Web／HTTPそのものを掘り下げる展開は用意されていません。 本文にHTTPが登場するのも、4階層モデルの説明中の列挙の1語としてだけです。

目的には書かれているのに、教材の側に展開が用意されていない。 だからここは、授業で深く扱われないまま通過しやすい。私がこの講を1本まるごと使って書いたのは、そういう理由です。今日持ち帰るのは番号ではなく、「忘れる設計にしたから名札が要る」「鍵マークは通信路の話であってサイトの話ではない」という2つの因果にしてください。