Web とは何か | octomblog

この章で学ぶこと：Web と Internet の違い、クライアント・サーバーモデルの意味、ブラウザが担う 3 つの仕事（取得・解釈・表示）を説明できる状態になる。
なぜ学ぶのか：以降の章（URL・HTTP・認証・インフラ）はすべて Web の基本モデルの上に積み上がる概念であり、土台が曖昧なまま進むと章ごとに暗記学習になるため。
Web 開発のどの領域か：横断的な前提知識。特定のレイヤー（フロントエンド／バックエンド）に属さず、全章の共通言語となる。

前提: なし。本カリキュラムの最初の 1 章目として読むことを想定している。

所要時間: 30 分（読解 20 分＋確認クイズ 10 分）

到達目標: 「Web とは何か」を非エンジニアの同僚に 3 分で説明できる状態。

Web と Internet は別物

日常では「インターネットで検索した」「Web で調べた」がほぼ同じ意味で使われるが、技術的には別のレイヤーの概念である。

用語	定義	具体例
Internet	世界中のコンピューターをつなぐネットワークの集合体。1960 年代の ARPANET が起源	IP アドレスでつながるあらゆる通信（Web・メール・オンラインゲーム・IoT）
Web（World Wide Web）	Internet 上で HTTP プロトコルで HTML 文書をやり取りする仕組み。1989 年にティム・バーナーズ＝リー氏が提案	ブラウザで開けるサイト、REST API、画像・動画配信

つまり「Web は Internet 上で動くサービスの一つ」である。メール（SMTP）や SSH、DNS は Internet 上で動くが Web ではない。本カリキュラムが扱うのは Web に限定される。

Web を支える 3 つの基礎技術

Web は次の 3 つの技術仕様の組み合わせで成立している。いずれも W3C / IETF が標準化しており、今も更新されている。

URL（Uniform Resource Locator）：リソース（ページ・画像・API）の所在を一意に指し示す文字列。https://example.com/users/42 のような形式。
HTTP（Hypertext Transfer Protocol）：クライアントとサーバーがメッセージをやり取りする手紙の書き方の規約。現行は HTTP/1.1 と HTTP/2、最新は HTTP/3。
HTML（Hypertext Markup Language）：ブラウザが解釈して表示するための文書構造の記述言語。

この 3 つに CSS（見た目） と JavaScript（動的な振る舞い） が加わり、現代の Web アプリが構築される。

クライアント・サーバーモデル

Web の通信はすべてクライアントが要求し、サーバーが応答する一方向のモデルで成り立つ。

クライアント・サーバーモデルの図

クライアント：ユーザーが直接触れる側。ブラウザ・モバイルアプリ・curl コマンド・他のサーバーも該当する。
サーバー：要求に応じて処理をする側。常時起動しており、世界中からのリクエストを待ち受けている。

この「要求がなければ何も起きない」という非対称性が、後の章で出てくる REST・認証・キャッシュの設計すべての前提となる。サーバー側から能動的にクライアントへデータを送る仕組み（WebSocket・Server-Sent Events・Push 通知）はこのモデルを拡張したもので、基本は変わらない。

ブラウザの 3 つの仕事

Web ブラウザ（Chrome・Safari・Firefox・Edge）がしていることは、実は 3 つだけである。

取得する：入力された URL にリクエストを送り、HTML・CSS・JS・画像などのファイルを受け取る。
解釈する：HTML をパースして DOM ツリーを作り、CSS を適用してスタイルを決め、JavaScript を実行する。
表示する：計算結果を画面上のピクセルに変換して描画する。

この 3 段階を分解して理解すると、次章（b00-2-url-to-screen）の「URL を打ってから画面表示までに何が起きているか」を自然に追いかけられる。

動的ページと静的ページ

Web サイトは配信方式で 2 種類に大別される。

種別	意味	例
静的ページ（Static）	サーバーにあらかじめ置いてある HTML ファイルをそのまま返す	GitHub Pages で公開するブログ、本サイト（Astro ビルド済み）
動的ページ（Dynamic）	リクエストを受けてからサーバーが HTML や JSON を生成して返す	SNS のタイムライン、EC サイトの商品詳細、管理画面

本カリキュラムのゴール（SNS アプリ）は 動的ページである。ユーザーごと・時刻ごとに表示内容が変わるため、データベースから最新情報を取得して都度組み立てる必要がある。

【アーキテクチャ】コラム：なぜ Web アプリを選ぶのか

選択肢: ユーザーに届ける手段は Web アプリ／iOS・Android ネイティブアプリ／デスクトップアプリ／CLI の 4 系統がある。

判断基準:

配布のしやすさ：Web アプリは URL を共有するだけで動く。ストア審査やインストールが不要。

OS 横断：ブラウザが動けば Windows／macOS／Linux／iOS／Android すべてで動作する。

更新のしやすさ：サーバー側を更新すれば次のアクセスで全員に反映される。ネイティブアプリは審査とユーザーのアップデート待ちが必要。

性能：GPU や高速カメラ制御が必要なアプリは Web の制約を超える（例：高度な動画編集・3D CAD）。

本カリキュラムの選択: SNS は「配布・OS 横断・更新容易」の利点がどれも効く代表的なユースケースなので Web で構築する。後のステップで React Native 等に展開する余地も残せる。

【他言語対応】表：Dify／n8n と Web アプリの関係

ツール位置付け本カリキュラムとの関係
Dify LLM ワークフローをノーコードで構築構築済みワークフローを Web アプリのバックエンドから HTTP で呼び出す
n8n 各種サービスを連携する自動化ツール Webhook 経由で Web アプリの外部トリガーとして利用する
Web アプリ（本カリキュラム）ユーザーが触れる UI と API の集合体 Dify／n8n を部品として組み込む上位の器

Dify／n8n をすべてコードに置き換える必要はない。Web アプリはそれらを統合する土台として機能する。

ツール	位置付け	本カリキュラムとの関係
Dify	LLM ワークフローをノーコードで構築	構築済みワークフローを Web アプリのバックエンドから HTTP で呼び出す
n8n	各種サービスを連携する自動化ツール	Webhook 経由で Web アプリの外部トリガーとして利用する
Web アプリ（本カリキュラム）	ユーザーが触れる UI と API の集合体	Dify／n8n を部品として組み込む上位の器

よくある詰まりポイント

「Web」と「Internet」を混同したまま読み進めると、後の章で「Web 以外のプロトコル（SSH や DB 接続）」が出てきたときに整理がつかなくなる。本章の冒頭表を見返す。
「ブラウザ＝Chrome」と思い込んでいると、モバイル WebView（アプリ内ブラウザ）や curl での API 疎通確認が「ブラウザではない」と勘違いしがち。HTTP を話せるソフトウェアはすべてクライアントである。
「動的ページは遅い／重い」と単純化すると、CDN・キャッシュ・静的生成（SSG）の設計判断を誤る。配信方式は用途ごとに選ぶもの。

参考リソース

MDN Web Docs — ウェブのしくみ
W3C — Web Architecture
『Web を支える技術』山本陽平著（技術評論社）— 第 1 章〜第 3 章で Web と HTTP の成り立ちを体系的に学べる。
MDN — ブラウザーの仕組み

確認クイズ

Q1. 「Web」と「Internet」の関係として最も適切なものはどれか。　A. 同じ意味　B. Web は Internet の一部で、HTTP で HTML をやり取りする仕組み　C. Internet は Web の一部　D. Web は Internet の後継技術

正解: B. Web は Internet の一部で、HTTP で HTML をやり取りする仕組み

解説: Internet は世界中のコンピューターをつなぐネットワーク基盤で、Web はその上で HTTP プロトコルを使って HTML 文書をやり取りする仕組み。メール（SMTP）や SSH は Internet 上で動くが Web ではない。

Q2. Web を支える 3 つの基礎技術として正しい組み合わせはどれか。　A. HTTP・HTML・URL　B. TCP・IP・DNS　C. JavaScript・CSS・SQL　D. React・Node.js・PostgreSQL

正解: A. HTTP・HTML・URL

解説: Web は「リソースを一意に指す仕組み（URL）」「やり取りの規約（HTTP）」「文書の記述言語（HTML）」の 3 つで成り立つ。TCP・IP・DNS は Web より下のネットワーク層で、JavaScript・CSS は Web を豊かにする技術。

Q3. クライアント・サーバーモデルの基本的な特徴を述べよ。

正解: クライアントが要求し、サーバーが応答する一方向の関係。サーバーから能動的に送信する仕組みは例外的な拡張。

解説: この非対称性が Web の設計原則（REST・キャッシュ・スケーラビリティ）の前提となる。WebSocket や Server-Sent Events はこのモデルを拡張したもので、基本モデル自体は変わらない。

Q4. ブラウザの 3 つの仕事として正しいものはどれか。　A. 取得・解釈・表示　B. 認証・暗号化・キャッシュ　C. フェッチ・ビルド・デプロイ　D. ダウンロード・コンパイル・実行

正解: A. 取得・解釈・表示

解説: ブラウザは URL からファイルを取得し（Fetch）、HTML/CSS/JS を解釈し（Parse/Execute）、画面のピクセルに変換する（Render）。この 3 段階はどのブラウザでも共通の処理モデル。

Q5. 静的ページと動的ページの違いを説明せよ。

正解: 静的ページはサーバーに置かれた HTML ファイルをそのまま返す方式、動的ページはリクエストごとにサーバーが HTML や JSON を生成して返す方式。

解説: 本カリキュラムで構築する SNS はユーザーごと・時刻ごとに表示内容が変わるため動的ページ。一方で、更新が少ないブログやドキュメントサイトは静的ページの方が配信が高速で運用コストも低い。

Q6. Web アプリがネイティブアプリに対して持つ最大の利点はどれか。　A. 高速な GPU 処理　B. URL 共有だけで配布・OS 横断・サーバー側更新が可能　C. オフラインでの完全動作　D. カメラ・センサーへの無制限アクセス

正解: B. URL 共有だけで配布・OS 横断・サーバー側更新が可能

解説: Web アプリはブラウザが動く環境であればどの OS でも動作し、ストア審査もインストールも不要。サーバーを更新すれば次のアクセスで全員に反映される。これらの利点が SNS のような用途に強く効く。

Q7. Dify／n8n と本カリキュラムで構築する Web アプリの関係として最も適切なものはどれか。

正解: Dify／n8n で作った処理を部品として組み込む上位の器が Web アプリである。すべてをコードに置き換える必要はない。

解説: Web アプリは UI・認証・DB アクセスなどの土台を提供し、その中で LLM 処理は Dify を、外部サービス連携は n8n を呼び出す構成が実務では一般的。ノーコードとコードの使い分け基準は b00-learning-path で扱っている。

Q8. 「ブラウザ＝Chrome」と考えるのが誤りである理由は何か。

正解: HTTP を話せるソフトウェアはすべてクライアントであり、モバイル WebView や curl コマンドもクライアントとして機能するため。

解説: クライアント・サーバーモデルの「クライアント」は役割であってアプリ名ではない。curl https://example.com はブラウザではないが、立派な Web クライアント。この理解は b06（HTTP）で API 疎通確認をするときに重要になる。

生きているコード

本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。

対応 Week: W2
参照ブランチ:
W2: reference/week-2
対応 checklist 項目: （直接対応なし）

ブランチの作り方・見方は b00-curriculum-map を参照してください。