第7章 Webの通信を観察する | エンジニア入門研修

この章では、ブラウザとサーバーの往復であるWeb通信を、URL、request、response、Cookie、エラーの段階に分けて観察する。ここで登場する用語は研修の外でも日常的に使う一般的な技術用語なので、意味と読み方をしっかり身につけておく。

HTTP

読み：エイチティーティーピー（HyperText Transfer Protocol）
一言で言うと：Webでブラウザとサーバーが情報をやり取りするための約束ごと。
くわしく：HTTPは、ブラウザからサーバーへの「注文票」と、サーバーからブラウザへの「返事」の形式を決めた取り決め（protocol）である。基本的に一つのrequest（依頼）に一つのresponse（返事）が返る。サーバーは前のrequestを自動では覚えていないため、ログイン状態などを保つにはCookieやセッションのような仕組みが要る。この「往復で動く」という性質を知っておくと、問題が往路（依頼）にあるのか復路（返事）にあるのかを切り分けやすい。
具体例：支援ステータス機能で、メンターが一覧画面を開くと、ブラウザはHTTPでHTMLを取りに行き、続いて担当受講者一覧のデータをAPIにHTTPで依頼する。
つまずきやすい点：HTTPは一回の往復で完結すると思い込みやすいが、一画面の表示でもHTML、CSS、JavaScript、APIなど複数の往復が起きる。
関連語：HTTP request / HTTP response（第7章）、HTTPS（第7章）、API（第7章）
テキスト本文での登場箇所：第7章「Webは、ブラウザとサーバーの往復で動く」

HTTPS

読み：エイチティーティーピーエス（HyperText Transfer Protocol Secure）
一言で言うと：通信を暗号化したHTTP。
くわしく：HTTPSは、HTTPの通信を暗号化して、途中で内容を盗み見られたり書き換えられたりしにくくしたものである。URLのscheme（先頭部分）が https なら暗号化された通信、http なら暗号化されていない通信である。本番のWebサービスはほぼHTTPSを使う。一方、自分のPCで動かすローカル開発サーバーは http（localhost）のことが多い。schemeを見れば、どちらの通信かを区別できる。
具体例：支援ステータス機能を本番で公開するなら https://... になる。手元での確認は http://localhost:3000 で行う。
つまずきやすい点：ローカルが http なのは設定不足ではなく通常の状態で、本番が https であることと混同しやすい。
関連語：HTTP（第7章）、scheme（第7章）、HttpOnly / Secure / SameSite（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

URL

読み：ユーアールエル（Uniform Resource Locator）
一言で言うと：Web上の対象を指す入口（住所のようなもの）。
くわしく：URLは、どこへつなぎ、何を見に行き、どんな条件を付けるかを一つの文字列で表す。開発者はこれを住所として丸ごと読むのではなく、scheme、host、port、path、query、fragmentに分けて読む。分けて読めると、問題が起きたときに「接続先がおかしいのか」「対象がないのか」「条件が違うのか」を切り分けられる。
具体例：支援ステータス機能の一覧URL http://localhost:3000/mentors/progress?filter=unsubmitted#list は、scheme=http、host=localhost、port=3000、path=/mentors/progress、query=filter=unsubmitted、fragment=#list に分けられる。
つまずきやすい点：URLを一つの文字列として扱い、接続先・対象・条件に分けないと、確認すべき場所が絞れない。
関連語：scheme / host / port / path / query / fragment（第7章）、origin（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

scheme

読み：スキーム
一言で言うと：URLの先頭にあり、通信方法を示す部分。
くわしく：schemeはURLの最初の http や https の部分で、どの方法で通信するかを示す。http は暗号化なし、https は暗号化ありである。schemeを見れば、その通信が暗号化されているか、ローカル用かを判断できる。originを構成する三要素（scheme、host、port）の一つでもある。
具体例：支援ステータス機能のローカルURL http://localhost:3000/... のschemeは http。本番なら https。
つまずきやすい点：scheme（http/https）とhost（接続先名）を混同しやすいが、役割は別である。
関連語：URL（第7章）、HTTPS（第7章）、origin（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

host

読み：ホスト
一言で言うと：URLのうち、接続先の名前を示す部分。
くわしく：hostは、どのサーバー（接続先）へ行くかを示す名前である。example.com のようなドメイン名や、自分のPCを指す localhost などが入る。DNSという仕組みが、この名前から実際の接続先を探す。hostを見ると、「どこへつなごうとしているか」が分かる。
具体例：支援ステータス機能を手元で動かすときのhostは localhost（自分のPC）。
つまずきやすい点：host名の綴りミス（例: localhsot）でも名前解決の失敗になるので、エラー時はまず綴りを疑う。
関連語：DNS（第7章）、localhost（第7章）、origin（第7章）、port（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

localhost

読み：ローカルホスト
一言で言うと：自分のPC自身を指す特別なhost名。
くわしく：localhostは、いま自分が操作しているPCを指す名前である。http://localhost:3000 は、自分のPCの3000番ポートで動いている開発サーバーを見に行く、という意味になる。ローカル開発で頻繁に使う。アクセスできないときは、サーバーが起動しているか、URLのportが合っているかを分けて見る。
具体例：支援ステータス機能をローカルで起動し、http://localhost:3000/mentors/progress をブラウザで開いて確認する。
つまずきやすい点：「ローカルなのにつながらない」とき、原因がサーバー未起動かport違いかは別物なので分けて確認する。
関連語：host（第7章）、port（第7章）、HTTP（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

port

読み：ポート
一言で言うと：同じPCやサーバーの中で、どの入口へ行くかを示す番号。
くわしく：portは、一つの接続先（host）の中にある複数の入口を区別する番号である。同じPCでも、3000番と4000番では別のプログラムが応答していることがある。portが違えば別のoriginとして扱われる。アクセスできないときは、URLのportが起動中のサーバーのportと合っているかを確認する。
具体例：支援ステータス機能の開発サーバーが3000番で動いていれば http://localhost:3000。誤って :4000 を開くと別の入口を見に行く。
つまずきやすい点：portが違うだけで別origin扱いになり、CORSの原因になることを見落としやすい。
関連語：host（第7章）、origin（第7章）、CORS（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

path

読み：パス
一言で言うと：URLのうち、サーバー上のどの対象（画面やAPI）を指すかを示す部分。
くわしく：pathは、/mentors/progress や /api/mentor/learners のように、接続先サーバーの中のどの対象を見に行くかを示す。画面のpathもあればAPIのpathもある。404（見つからない）が出たときは、まずpathの綴りやAPIのルーティングを疑う。
具体例：支援ステータス機能で、担当受講者一覧のAPIは /api/mentor/learners、ステータス更新のAPIは /api/mentor/learners/:learnerId/support-status。
つまずきやすい点：pathが正しくてもmethodが違えば405になるので、pathの問題とmethodの問題を切り分ける。
関連語：URL（第7章）、query string（第7章）、method（第7章）、status code（404 / 405）（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

query string

読み：クエリ（クエリ文字列 / query string）
一言で言うと：URLの ? 以降に付く、絞り込みや検索などの追加条件。
くわしく：query（query string）は、URLの ? 以降に 名前=値 の形で付く追加条件である。filter=unsubmitted のように、表示条件や検索条件を表す。queryはサーバーへ送られるため、サーバーログに残る可能性がある。検索語やtokenのような秘密情報をqueryへ入れないよう注意する。
具体例：支援ステータス機能で未提出者だけを表示するとき GET /api/mentor/learners?filter=unsubmitted のように filter=unsubmitted をqueryで送る。
つまずきやすい点：queryはサーバーへ送られる（ログに残りうる）のに対し、fragmentは送られない、という違いを取り違えやすい。
関連語：URL（第7章）、path（第7章）、fragment（第7章）、HTTP request（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

fragment

読み：フラグメント
一言で言うと：URLの # 以降に付く、ページ内の位置やブラウザ側の状態を示す部分。
くわしく：fragmentは、#list のようにURLの # 以降に付く部分で、ページ内のどこへ移動するかなどを示す。通常、fragmentはHTTP requestとしてサーバーへ送られない。そのため #... を変えてもサーバーログに違いが出ないことがある。サーバー側の問題を探すときに、fragmentの違いを追っても原因にたどり着かない。
具体例：支援ステータス機能のURL末尾 #list を変えても、一覧APIへ送られる依頼の内容は変わらない。
つまずきやすい点：fragmentがサーバーへ送られると思い込み、#... の違いをサーバー側で探してしまう。
関連語：URL（第7章）、query string（第7章）、HTTP request（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

origin

読み：オリジン
一言で言うと：scheme、host、portの組み合わせで表す通信の出どころ。
くわしく：originは、scheme、host、portの三つを合わせたものである。この三つがすべて一致して初めて同じoriginになる。たとえば http://localhost:3000 と http://localhost:4000 は、hostが同じでもportが違うため別originである。ブラウザは別originへの通信を安全上制御することがあり、CORSの切り分けではこのoriginの違いを見る。
具体例：支援ステータス機能の画面が http://localhost:3000 で動き、APIが http://localhost:4000 にあると別originになり、ブラウザがCORSで通信を止めることがある。
つまずきやすい点：「同じlocalhostなら同origin」と思いやすいが、portが違うだけで別originになる。
関連語：scheme / host / port（第7章）、CORS（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」

DNS

読み：ディーエヌエス（Domain Name System）
一言で言うと：example.com のような名前から、実際の接続先を探す仕組み。
くわしく：DNSは、人が読めるhost名（ドメイン名）から、機械が通信に使う接続先を見つける仕組みである。通信はまず名前解決から始まるので、名前が見つからなければサーバーには届かない。失敗を切り分けるときは、「名前から接続先を見つけられない失敗（DNSやURLの綴り）」と「サーバーにつながった後の失敗」を分けて考える。
具体例：支援ステータス機能で Could not resolve host: localhsot と出たら、localhost の綴り間違いなど、名前解決の段階の問題を疑う。
つまずきやすい点：名前解決の失敗とサーバー内部の失敗（500など）を同じ「つながらない」とまとめてしまい、見る場所を間違える。
関連語：host（第7章）、URL（第7章）
テキスト本文での登場箇所：第7章「URLは、接続先、対象、条件に分けて読む」／「Web通信の失敗を段階で分類する」

HTTP request

読み：エイチティーティーピーリクエスト
一言で言うと：ブラウザやcurlからサーバーへ送る依頼。
くわしく：HTTP requestは、サーバーへの「注文票」にあたる依頼である。見るときはmethod（何をしたいか）、path（対象）、headers（追加情報）、body（本体）に分ける。requestを観察する目的は、HTTPの仕様を暗記することではなく、画面操作がどの依頼としてサーバーに届いているかを確認することである。
具体例：支援ステータス機能で更新ボタンを押すと PATCH /api/mentor/learners/:learnerId/support-status というrequestが送られ、bodyに更新内容が入る。
つまずきやすい点：操作とmethodの対応を見落とすと、保存したつもりがGETで終わっているなどのズレに気づけない。
関連語：method（第7章）、path（第7章）、headers（第7章）、body（第7章）、HTTP response（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

HTTP response

読み：エイチティーティーピーレスポンス
一言で言うと：requestに対するサーバーからの返事。
くわしく：HTTP responseは、依頼に対する「返事」である。見るときはstatus code（どう扱ったか）、headers（返事の付帯情報）、body（中身）に分ける。status codeだけで判断せず、bodyのエラーメッセージやサーバーログも合わせて読むと、原因に近づける。
具体例：支援ステータス機能で一覧APIが500を返したら、status codeだけで終えず、response bodyとサーバーログを見て原因を探す。
つまずきやすい点：status codeの番号だけで原因を決めつけ、bodyやログを見ないと、本当の失敗箇所を見誤る。
関連語：status code（第7章）、headers（第7章）、body（第7章）、HTTP request（第7章）
テキスト本文での登場箇所：第7章「responseは、status codeだけで判断しない」

method

読み：メソッド（HTTP method）
一言で言うと：サーバーに何をしたいかを示す、requestの種類。
くわしく：methodは、取得・作成・更新・削除など、サーバーへの依頼の種類を示す。代表的なものはGET（取得）、POST（作成や送信）、PATCH（一部の更新）、PUT（対象全体の置き換え）、DELETE（削除）である。ただし実際の意味はアプリの設計にも依存する。操作とmethodの関係を見れば、一覧表示なのにPOSTになっていないか、保存なのにGETで終わっていないかを確かめられる。
具体例：支援ステータス機能では、一覧取得が GET /api/mentor/learners、ステータス更新が PATCH /api/mentor/learners/:learnerId/support-status。
つまずきやすい点：データを変更する操作がGETで実装されていることもあるので、method名から用途を決めつけず設計を確認する。
関連語：GET / POST / PATCH / PUT / DELETE（第7章）、status code（405）（第7章）、HTTP request（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

GET

読み：ゲット
一言で言うと：データを取得するためのmethod。
くわしく：GETは、画面・一覧・詳細・検索結果などを取得するときに使うmethodである。HTTPの意味として、GETはデータを変えない安全な操作として扱われる。条件はbodyではなくquery（?...）で送ることが多い。取得のつもりなのにデータが変わっていないか、データ変更がGETで実装されていないかを確認する。
具体例：支援ステータス機能で GET /api/mentor/learners?filter=unsubmitted を送ると、未提出者一覧を取得する。
つまずきやすい点：GETは取得用なので、データを変更する処理にGETを使うのは設計として注意が必要。
関連語：method（第7章）、query string（第7章）、POST（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

POST

読み：ポスト
一言で言うと：作成・送信・ログインなどを行うmethod。
くわしく：POSTは、新しいデータの作成やフォーム送信、ログインなどに使うmethodである。送るデータはbodyに入れることが多く、その形式をContent-Type（content-type header）で示す。観察するときは、bodyやContent-Typeが期待どおりかを見る。
具体例：支援ステータス機能にコメント投稿のような作成操作があれば、POSTでbodyに内容を入れて送る。
つまずきやすい点：POSTでbodyを送っているのにContent-Typeが合っていないと、サーバーが正しく解釈できず400になることがある。
関連語：method（第7章）、body（第7章）、headers（content-type）（第7章）、status code（201 / 400）（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

PATCH

読み：パッチ
一言で言うと：対象の一部の項目を更新するmethod。
くわしく：PATCHは、対象の一部だけを更新するときに使うmethodである。対象全体を置き換えるPUTとは違い、変更したい項目だけを送る。観察するときは、どのfield（項目）を更新しているかをbodyで確認する。
具体例：支援ステータス機能で PATCH /api/mentor/learners/:learnerId/support-status を送り、bodyの status と note だけを更新する。
つまずきやすい点：PATCH（一部更新）とPUT（全体置き換え）の違いはAPI設計次第なので、思い込まず確認する。
関連語：method（第7章）、PUT（第7章）、body（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

PUT

読み：プット
一言で言うと：対象全体を置き換えるmethod。
くわしく：PUTは、対象のデータ全体を、送った内容で置き換えるときに使うmethodである。一部だけ更新するPATCHとは役割が異なる。両者のどちらを使うかはAPIの設計で決まるので、観察時はPATCHとの違いを設計で確認する。
具体例：支援ステータス機能で、受講者の支援情報をまるごと差し替える設計ならPUTを使うことがある（一部更新ならPATCH）。
つまずきやすい点：PUTで一部だけ送ると、送らなかった項目が消える設計のこともあるので注意する。
関連語：method（第7章）、PATCH（第7章）、body（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

DELETE

読み：デリート
一言で言うと：対象を削除するmethod。
くわしく：DELETEは、対象を削除するときに使うmethodである。取り返しがつかない操作になりやすいため、誤操作を避ける確認や、削除する権限があるかを見る。観察時も、意図しない削除requestが出ていないかに注意する。
具体例：支援ステータス機能で、誤って登録した受講者メモを消す操作があれば、DELETE requestで削除する。
つまずきやすい点：DELETEは元に戻しにくいので、curlなどで安易に試さず、ローカルの研修用アプリにだけ行う。
関連語：method（第7章）、status code（403）（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」

headers

読み：ヘッダー（HTTP headers）
一言で言うと：requestやresponseに付く追加情報のまとまり。
くわしく：headersは、本体（body）とは別に付く付帯情報である。データ形式（Content-Type）、認証情報（Authorization）、Cookie、ブラウザの情報などが入る。requestにもresponseにもheadersがある。Authorization headerやCookieには秘密情報が含まれることがあるため、提出物やAI入力へ値をそのまま貼らない。
具体例：支援ステータス機能のステータス更新requestには content-type や x-mentor-id（誰が更新しているか）のようなheadersが付く。
つまずきやすい点：headersは脇役に見えるが、Content-Typeや認証情報が違うと400や401の原因になる。
関連語：body（第7章）、Cookie（第7章）、status code（400 / 401）（第7章）、HTTP request / response（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」／「responseは、status codeだけで判断しない」

body

読み：ボディ（HTTP body）
一言で言うと：requestやresponseの本体（中身のデータ）。
くわしく：bodyは、依頼や返事の中身そのものである。POSTやPATCHのrequestでは、フォーム入力やJSONがbodyに入る。GETではbodyを使わず、条件はqueryで送ることが多い。responseのbodyには、一覧データやエラーメッセージが入る。status codeだけで判断せず、bodyの中身も確認する。
具体例：支援ステータス機能の更新requestのbodyは {"status":"needs_support","note":"..."}。一覧APIのresponse bodyには learners の配列が入る。
つまずきやすい点：GETにbodyを付けようとしがちだが、条件はqueryで送るのが普通である。
関連語：headers（第7章）、JSON（第7章）、query string（第7章）、status code（204）（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」／「responseは、status codeだけで判断しない」

JSON

読み：ジェイソン（JavaScript Object Notation）
一言で言うと：データを 名前:値 の形で表す、軽量なデータ記述形式。
くわしく：JSONは、{ } や [ ] を使ってデータを構造的に表す形式で、APIのrequest bodyやresponse bodyで広く使われる。JSONで返すことは、content-type: application/json のようなheaderで示される。中身を読むと、期待するデータが返っているかを確認できる。
具体例：支援ステータス機能の一覧APIは {"learners":[{"id":"l-101","submittedAt":"..."}]} のようなJSONを返す。
つまずきやすい点：JSONが返っているのにContent-Typeが合っていないと、受け取る側が正しく解釈できないことがある。
関連語：body（第7章）、headers（content-type）（第7章）、API（第7章）
テキスト本文での登場箇所：第7章「requestは、何をどう依頼したかを見る」／「curlは、ブラウザを通さずにサーバーへ聞く道具である」

status code

読み：ステータスコード（HTTP status code）
一言で言うと：サーバーがrequestをどう扱ったかを数字で示すコード。
くわしく：status codeは、responseに付く3桁の数字で、依頼の結果を表す。すべて暗記する必要はなく、まず大きな分類で読む。200番台は成功に近い、300番台は別の場所への案内、400番台はクライアント側に近い問題、500番台はサーバー側の処理失敗に近い問題である。代表例は、200 OK（成功）、201 Created（作成成功）、204 No Content（成功だがbodyなし）、301/302（移動）、304 Not Modified（キャッシュ利用可）、400 Bad Request（requestが不正）、401 Unauthorized（未認証）、403 Forbidden（権限不足）、404 Not Found（対象なし）、405 Method Not Allowed（methodが違う）、500 Internal Server Error（サーバー内部の失敗）である。数字だけで決めつけず、bodyやログも見る。
具体例：支援ステータス機能で GET /api/mentor/learners?filter=unsubmitted が500を返したら、画面全体ではなくこのAPIのサーバー側処理に近い問題だと絞り込める。
つまずきやすい点：400番台は「ブラウザが悪い」、500番台は「サーバーコードだけが悪い」と決めつけやすいが、入力・状態・権限など複数の原因がありうる。
関連語：HTTP response（第7章）、body（第7章）
テキスト本文での登場箇所：第7章「responseは、status codeだけで判断しない」

Networkタブ

読み：ネットワークタブ（Network tab）
一言で言うと：ブラウザの開発者ツールで、画面の裏で起きた通信を一覧で見る場所。
くわしく：Networkタブは、ブラウザの開発者ツールにあり、画面表示の裏で発生した各requestのURL、method、status、responseの概要、timing（速度）などを見られる。最初はrequest URL、method、status、responseの概要を見れば十分である。Fetch/XHR、Doc、JS、CSSのfilterでrequestを絞れる。観察結果は、相談やPR本文の事実としてそのまま使える。
具体例：支援ステータス機能の一覧画面を再読み込みし、Networkタブで「HTMLは200、一覧APIは500」のように、画面を通信の集まりとして分解して見る。
つまずきやすい点：Networkタブを開く前に読み込んだ通信は記録されないので、タブを開いてから再読み込みする。
関連語：HTTP request / response（第7章）、status code（第7章）、curl（第7章）
テキスト本文での登場箇所：第7章「Networkタブで、一画面の通信を分解する」

curl

読み：カール
一言で言うと：ターミナルからHTTP requestを送り、サーバーの返事を確認する道具。
くわしく：curlは、ブラウザを通さずにコマンドでHTTP requestを送れる道具である。-i を付けるとresponse headersも含めて表示でき、status code、headers、bodyの概要を確認できる。更新系のrequestは -X PATCH などでmethodを、-H でheadersを、-d でbodyを明示する。curlの目的はブラウザ操作の置き換えではなく、ブラウザ越しの問題かサーバー単体でも起きる問題かを分けることである。
具体例：支援ステータス機能で curl -i "http://localhost:3000/api/mentor/learners?filter=unsubmitted" を実行し、ブラウザの結果と突き合わせる。
つまずきやすい点：本番や共有環境に対して、意味を理解しないまま更新requestを送らない。更新系の確認はローカルの研修用アプリだけで行う。
関連語：HTTP request / response（第7章）、Networkタブ（第7章）、CORS（第7章）
テキスト本文での登場箇所：第7章「curlは、ブラウザを通さずにサーバーへ聞く道具である」

読み：クッキー
一言で言うと：サーバーから受け取りブラウザが保存し、条件に合うrequestへ自動で添える小さな情報。
くわしく：Cookieは、responseの Set-Cookie headerで保存され、次のrequestでは Cookie headerとして送られることが多い。ログイン状態やカートの状態を保つのに使われる。Cookieには秘密情報が含まれることがあるため、提出物・チャット・AI入力へ値をそのまま貼らず Cookie: [REDACTED] のように伏せる。値そのものより、いつセットされたか、次のrequestに付くか、HttpOnly・Secure・SameSiteといった属性を観察する。
具体例：支援ステータス機能にログインがあれば、ログイン後のrequestにCookieが付く。なければ「Cookieは観察されなかった」と記録する。
つまずきやすい点：ブラウザはCookieを自動で付けるが、curlは指定しない限り付けないため、curlだけ401/403になることがある。
関連語：session（第7章）、headers（Set-Cookie / Cookie）（第7章）、HttpOnly / Secure / SameSite（第7章）、status code（401 / 403）（第7章）
テキスト本文での登場箇所：第7章「Cookieとセッションは、ログイン状態の手がかりになる」

session

読み：セッション
一言で言うと：ログイン状態など、利用者に関する状態をサーバー側で扱う仕組み。
くわしく：sessionは、利用者ごとの状態（ログイン中かどうかなど）をサーバー側で保持する仕組みである。HTTPは前のrequestを自動では覚えないため、状態を保つのに使われる。セッション方式では、Cookieにユーザー情報そのものではなく、サーバー側の状態を探すためのID（session id）が入ることがある。そのID自体が秘密情報なので、値を貼ってはいけない。
具体例：支援ステータス機能にログインがあれば、ログイン状態はセッションで管理され、Cookieに入ったセッションIDで各requestと結び付けられる。
つまずきやすい点：「Cookie＝ユーザー情報そのもの」と思いやすいが、実際はサーバー側状態を指すIDだけのことが多い。
関連語：Cookie（第7章）、HTTP（ステートレス性）（第7章）、headers（第7章）
テキスト本文での登場箇所：第7章「Cookieとセッションは、ログイン状態の手がかりになる」

HttpOnly / Secure / SameSite

読み：エイチティーティーピーオンリー／セキュア／セイムサイト
一言で言うと：Cookieの送り方や読み取りを制御する属性。
くわしく：これらはCookieに付く属性で、Cookieの扱いを安全側に制御する。HttpOnlyはJavaScriptから値を読み取りにくくする（requestには送られる）。SecureはHTTPS通信で送ることを前提にする。SameSiteは、別siteからのrequestにCookieを送る条件に関係する。この章では細かい設定値を暗記する必要はなく、見つけたらメモし値を伏せる姿勢が大切である。
具体例：支援ステータス機能でログインCookieにHttpOnlyが付いていれば、画面のJavaScriptからその値を直接は読み取りにくい。
つまずきやすい点：HttpOnlyは「送られない」のではなく「JavaScriptから読みにくい」だけで、requestには付く点を取り違えやすい。
関連語：Cookie（第7章）、HTTPS（Secure）（第7章）、session（第7章）
テキスト本文での登場箇所：第7章「Cookieとセッションは、ログイン状態の手がかりになる」

API

読み：エーピーアイ（Application Programming Interface）
一言で言うと：画面やプログラムがサーバーの機能やデータを使うための入口。
くわしく：APIは、画面やプログラムがサーバーの機能やデータを呼び出すための窓口である。一画面の表示でも、HTMLとは別にAPIへデータを取りに行くことが多い。画面の枠組みは出ているのに一覧だけ出ないなら、HTMLは返っているがデータ取得のAPIが失敗している可能性がある、というように問題の位置を絞れる。
具体例：支援ステータス機能の担当受講者一覧は、画面とは別に GET /api/mentor/learners というAPIでデータを取得する。
つまずきやすい点：「画面が出ない」をひとくくりにせず、画面（HTML）の問題かAPIの問題かを分けて見る。
関連語：HTTP request / response（第7章）、JSON（第7章）、path（第7章）
テキスト本文での登場箇所：第7章「Webは、ブラウザとサーバーの往復で動く」

CORS

読み：コルス（Cross-Origin Resource Sharing）
一言で言うと：ブラウザが異なるoriginへの通信を安全上制御する仕組み。
くわしく：CORSは、ブラウザが、いま開いているページとは別のoriginへの通信を、安全のために制御する仕組みである。この章では詳細設定には踏み込まない。大切なのは、curlでは返るのにブラウザでは止められることがある、という観察である。違いが出たら、APIそのものの失敗ではなく、ブラウザが安全上止めている問題（ブラウザ制約）を疑う。
具体例：支援ステータス機能の画面が http://localhost:3000、APIが http://localhost:4000 にある場合、ブラウザからのfetchがCORSで止まることがある（curlでは200で返る）。
つまずきやすい点：CORSエラーをAPI自体の失敗と混同しやすいが、curlで成功するならブラウザ制約を疑う。
関連語：origin（第7章）、port（第7章）、curl（第7章）
テキスト本文での登場箇所：第7章「Web通信の失敗を段階で分類する」