web開発勉強会　イントロ

皆さんが普段見ているWebサイトは、
画面だけでなく、その背後にネットワークとサーバの膨大な仕組みが支えています。

今回の勉強会ではその中から、
「ブラウザでどう表示されるか（フロントエンド）」と
「サーバがどう応答するか（バックエンド）」を自分の手で動かして体験します。

インターネットという大きな道路の上で、
様々な情報が行き来しているとして、
その“入口と出口”を理解するのが、今回のゴールです。
なお、今回は初心者向け、理解優先として、詳細、正確さは意図的に省略しています。

そもそも「インターネット」とは？

Webは「インターネットを使う方法のひとつ」にすぎません。
まずは、“その土台”である インターネット とは何かを理解しましょう。

一言で言うと

インターネットとは「世界中のコンピュータ同士をつなぐ通信網」

どこの国のどんなOSでも、共通のルール（プロトコル）で情報を交換できる仕組み。

簡単な歴史（超ざっくり）

時期	出来事	意味
1960年代	ARPANET誕生（アメリカ国防総省のプロジェクト）	複数コンピュータを結ぶ軍事・研究ネットワーク
1970年代	TCP/IP プロトコル誕生	ネットワーク同士をつなぐ共通言語
1980年代	各国の大学・企業ネットが相互接続	「ネットワークのネットワーク」＝Inter-Network へ
1990年代	WWW・ブラウザ登場	一般市民も使える「情報の窓口」誕生
2000年代〜	スマホ・クラウド・IoT時代へ	あらゆる機器がインターネット接続する時代に

インターネットの基本構造（OSI参照モデルの簡略版）

層	代表的な技術	役割
アプリケーション層	HTTP, SMTP, FTP, DNS	アプリごとの通信ルール
トランスポート層	TCP, UDP	データの分割・再送制御、アプリ識別
ネットワーク層	IP	相手の住所を見て転送
データリンク層	Ethernet, Wi-Fi	機器間の接続（物理ケーブル/無線）
物理層	光ファイバ, 電波, LANケーブル	信号としてのやり取り

Web開発で扱うのは基本的に「アプリケーション層」ですが、
その下に多層の“通信インフラ”があるからこそ動いています。
幾ら自分のwebアプリが良い感じにできても、例えばDNS障害があると利用できなくなります。

「インターネットを使う方法」はWebだけじゃない

分野	プロトコル / サービス	主な用途	現代での立ち位置
WWW (Web)	HTTP / HTTPS	Webサイト、API、Webアプリ	主流（標準的UI）
メール	SMTP, POP3, IMAP	電子メール送受信	依然として主流
ファイル転送	FTP, SFTP	ファイル共有・公開	セキュリティ強化型（SFTP等）で継続
名前解決	DNS	ドメイン→IP変換	あらゆる通信の基礎
リモート接続	SSH, RDP, Telnet	サーバ操作・管理	運用者が利用
メッセージ通信	IRC, XMPP, MQTT	チャット、IoT、通知	現代はSlackやLINEが主流
音声・映像通信	RTP, SIP, WebRTC	通話、会議、配信	Zoom, Meet, Teams等で活用
ファイル共有P2P	BitTorrent	コンテンツ分散配布	CDNやP2P技術の基礎
クラウドAPI通信	gRPC, REST, GraphQL	サービス間通信	現代のバックエンド連携の主流

Web は「HTTPを使う仕組みの総称」。
つまり「インターネット通信の上に乗った一つのアプリケーション、使い方」にすぎません。

「Web」はインターネットの代表

Webはこの中のひとつ（HTTP＋URL＋HTML）。
ただし「ブラウザを通じて誰でも使える」ため、
結果的に“インターネットの代名詞”になっています。

現代のインターネットの特徴

観点	内容
共通性	TCP/IPとDNSで全世界が統一された通信規格
分散性	特定の中心サーバが存在しない（相互接続）
拡張性	新しいプロトコルやアプリが追加可能（HTTP/3、QUICなど）
安全性	暗号化通信（HTTPS, TLS 1.3）が標準化
多様性	Web, メール, API, IoTなど、用途ごとのプロトコル

つなげて理解すると

Webは「インターネットの上で動く多数の仕組みの一つ」
Web以外にも、メール・通話・SSHなど、様々な通信が同じ基盤で動いている
インターネットを理解すると、Web開発の "なぜそう動くのか" が腑に落ちる
そして、HTTP通信を理解することが、Web開発の入口になる

Webとは何か──フロントエンド・バックエンド・インフラの三層で見る

Web開発とは「見える世界」「考える世界」「支える世界」の3層構造。

それぞれが独立しながらも、通信とプロトコルで有機的につながっています。

まず「Web」はどこで動いているのか？

あなたの 端末（パソコン・スマホ） の中で「ブラウザ」が動いている
どこかの サーバ（クラウドやデータセンター） が応答している
そしてその間をつなぐのが ネットワーク / インターネット（通信網）

Web = “世界中のコンピュータがHTTPで話す仕組み”
つまり、Webは「アプリケーション」と「通信」と「インフラ」が重なって成り立っている。

Webを支える3つの層（＋通信の要素）

層	役割	主な技術要素	学びの位置づけ
🟦 フロントエンド層	L7。利用者の画面・UI・操作	HTML, CSS, JS, DOM, fetch, SPA	フロントエンド編で体験
🟨 バックエンド層	L7。ロジック・データ処理・API	HTTPサーバ, URLルーティング, JSON, DB, REST	バックエンド編で体験
🟥 インフラ層	L1～L4。通信・運用・配信を支える基盤	DNS, IP, TCP, TLS, CDN, Proxy, Firewall, LoadBalancer	仕組みとして理解（体験は一部ピックアップ）
⚫ 通信レイヤ（リンク）	L1～L4。各層を結ぶ道路・信号	IX等の物理と、HTTP, HTTPS, QUIC, WebSocket, gRPC等の論理	各編で共通して登場（特にfetchやサーバ起動）

改めて「インターネット」とは？

インターネット = 世界中のネットワークをつなぐ「ネットワークのネットワーク（Inter-Network）」

その構成を簡略に見ると…

要点

Webの通信はすべて IP（住所）とDNS（名前と郵便番号対応表） でつながる
HTTPやHTTPS（TLS） は、その通信のルール（約束事）
回線事業者 は、IP（住所）の外なので、「公道」
IX は、各国・各事業者のネットワークを接続する“交差点”

Web開発者はこれらをすべて作る必要はないが、
「通信の下にこれだけの層がある」と知ることで、仕組み全体が理解できる。

さらにインフラ層の役割を整理

分類	内容	初心者への説明
DNS / hosts	ドメイン名→IP変換	「example.com」を数字の住所（IP）に変える電話帳
HTTP / HTTPS / QUICなど	通信プロトコル	ブラウザとサーバの“会話の文法”
CDN（Content Delivery Network）	静的コンテンツを近いサーバから配信	画像やCSSを早く届ける“コンビニ網”
TLS / 証明書	通信暗号化・信頼性	「🔒鍵マーク」を出す仕組み
Firewall / Proxy	通信の制御	不正アクセスを防ぐ関所
ロードバランサ	負荷分散	リクエストを複数サーバに分ける
クラウド基盤	仮想マシン・ストレージ・ネットワーク	AWS, Azure, GCP, Render, Vercel など
監視・ロギング	稼働状況の可視化	サーバの「健康診断」

そして「Web開発者」が扱う範囲は？

補足解説

フロントエンド層：ユーザーの端末（ブラウザ）で動作する画面、スタイル、コード。
→ HTML/CSS/JS により「見える世界」を構築。
通信レイヤ（灰色）：HTTP(S)/TCP/IP の“道路”。
→ リクエストもレスポンスもこの層を通ってサーバとやり取り。
バックエンド層：サーバで動作する処理。
→ APIの応答、データベース操作などの業務ロジックを担当。

この図のポイント：

通信レイヤはフロント／バックの中間にある独立した層。
Web開発者は、このレイヤを越えてデータを正しく送受信することが必要なスキル。
HTTPを理解すれば、「ブラウザの動き」「サーバの応答」「APIの仕組み」すべての基礎が見えてくる。

ライブラリ、フレームワーク、ローコード、ノーコード、ミドル、その他便利なツールなどで隠蔽され、正直理解しないまま過ごしてしまうことも可能な場合もありますが、今回で可能な限りシンプルなwebの要素を確認しましょう。

インフラレイヤも追加した場合

Web開発者は主にフロントとバックの間（HTTP通信）を扱いますが、
その下には 通信レイヤ と インフラ層 がしっかり存在しています。

各層の役割整理

層	役割	主な技術	入門での扱い
🟦 フロントエンド層	ユーザーの画面と操作	HTML, CSS, JS, fetch	実行、改造を体験
⬜ 通信レイヤ	ブラウザとサーバをつなぐ道路	HTTP(S), TCP/IP	基本的仕組みを理解
🟨 バックエンド層	サーバの処理・データ管理	Webサーバ, API, DB	PowerShell＋http/JSONで体験
🟥 インフラ層	配信・セキュリティ・可用性を支える	DNS, TLS, CDN, Firewall, LB	概念を理解（構築は対象外）

図の読み方のポイント

リクエストもレスポンスも通信レイヤを経由してやり取りされる
→ HTTPが「Webアプリを動かす共通言語」
インフラ層は、通信を“速く・安全に・安定して”支える土台
→ 開発者が直接触らなくても、その存在を理解することが重要
Web開発者の主戦場は青〜黄の層
→ ただし、赤い層（インフラ）を理解していると、
「なぜ動かないのか」「どこが遅いのか」を見抜けるようになる

ここまでのまとめ

Webシステムは「アプリのロジック」だけで成り立っているわけではありません。
その下には、通信のルール（HTTP, TCP/IP）と、
さらに下にはインターネット全体を支える巨大なインフラが存在しています。

開発者はこれらのすべてを作る必要はありませんが、
それぞれがどう関係しているかを理解することが“真のWeb理解”の第一歩です。

理解のポイント

フロントエンド：ブラウザ内の動作（HTML/CSS/JS）
バックエンド：サーバの処理（API、DB連携）
インフラ：その間を支える通信・配信・運用

開発者は通常、フロントとバックの中継（HTTP通信） を理解できれば、
Webの全体像をつかめる

Webリクエスト1往復の流れ（Step-by-Step）

ブラウザでURLを開くとき、見えないところでこれだけの会話が行われています。
「フロント → 通信 → インフラ → バック → インフラ → 通信 → フロント」
の1往復が、1ページ表示の裏で行われています。

各ステップの概要

Step	段階	主な技術	開発者が意識すべきポイント
1	ユーザー操作	URL, ブラウザ	フロントエンドの入口
2	名前解決	DNS, IP	ドメイン設定・DNS伝搬
3	通信確立	TCP, TLS, HTTPS	セキュリティ（証明書・暗号化）
4	リクエスト送信	HTTPメソッド（GET/POST）	API設計・ヘッダ制御
5	サーバ処理	Webサーバ, アプリ, DB	バックエンドロジック
6	応答中継	CDN, LB, Proxy	配信最適化・キャッシュ制御
7	ブラウザ描画	DOM, CSS, JS	パフォーマンス・UI/UX
8	完了	—	フロント・バック連携完結

まとめ：1ページ表示の中で起きていること

DNS → TCP → TLS → HTTP → HTML解析 → リソース取得
これらすべてが、数百ミリ秒〜数秒の間に起きています。
開発者は“フロント↔通信↔バック”の接点を理解すると、
なぜ遅いのか、なぜ届かないのか、を自力で見抜けるようになります。
インフラ層（DNS, CDN, TLS） は、PGMには登場せず、直接コードに書かなくても、
その「存在と役割」を知るだけで、開発の質が大きく向上します。

この図の使い方

ブラウザをクリックする瞬間から、どんな旅をしているかを順に説明

それぞれのStepで「使われる技術」と「触れる機会がある言葉」を紹介

フロントエンド編ではStep 7（描画）を中心に、
　バックエンド編ではStep 5（応答処理）を中心に実演

補足：
このフローは「GETリクエストを1回送る」想定ですが、
Ajaxやfetchによる非同期通信では、Step 4〜6が何度も繰り返されます。
つまりブラウザは常にこの「小さな往復」を何百回も同時に行っています。

関連領域（インフラに属する内容だが、開発と関わる）

領域	役割	関連の深さ
ドメイン管理 / DNS	URLとサーバの紐付け	開発環境公開で重要
SSL証明書 / HTTPS	安全な通信	個人情報等を扱うAPI・フォームなどでは必須
SEO	検索最適化	HTML構造・metaタグ設計で関与
CDN	静的配信高速化	画像やJS配信時に関係
WAF / セキュリティ設定	攻撃対策	インフラ設定だが協力
ログ / モニタリング	運用監視	バックエンドと共通領域

開発者はこれらを直接構築しなくても、
「何が起こっているか」を理解できるだけでトラブル対応や設計の質が向上します。

総まとめ：「3層＋通信」の地図

レイヤ	主な要素	学ぶ内容	対応する講座
🟦 フロントエンド層	HTML, CSS, JS, fetch	見える部分を作る	フロントエンド編
🟨 バックエンド層	HTTPサーバ, API, JSON, DB	考える仕組み、応答する仕組み	バックエンド編
🟥 インフラ層	DNS, TLS, CDN, Firewall, クラウド	支える基盤	概念的理解（触れないが話題にする）
⚫ 通信リンク	HTTP(S), TCP/IP	層間をつなぐ会話	両編で登場

フロントエンドとバックエンドの連携（通信・インフラ層を省略）

通信レイヤ（HTTP/TCP）やインフラレイヤ（DNS/TLS/CDN等）は図から省略しています。
実際にはそれらが下支えしていますが、ここでは「アプリケーションレベルでの連携」に焦点を当てます。

1) コンポーネント構成（リクエストのみ記載。役割の対応）

2) 一連のリクエストフロー（順序付き）

3) 読み取りのポイント

区分	主な責務	具体例	勉強会の実装
🟦 フロントエンド	ユーザー操作と画面描画	HTML, CSS, JavaScript	`/www/index.html`
🟨 WEBサーバ	静的配信・ルーティング・プロキシ	`/index.html`, `/app/`, `/api/`	`web.ps1`
🟨 APサーバ	動的HTML生成	`/app/greet?name=...`	`ap.ps1`
🟨 APIサーバ	JSON APIの提供	`/api/todo` (GET/POST/DELETE)	`api.ps1`
🟨 DBサーバ	データの保存・検索	`/todo` (GET/POST/DELETE)	`db.ps1`

学習のポイント

フロントエンドの fetch() は /api/... のみを意識すればよい
→ バックエンドの構成（TomcatでもPowerShellでも）を意識せず利用可能。
バックエンドでは各サーバが「専門分野」を担当
→ 責務を分けることで、保守性・拡張性・置換性 が高まる。
実際のWeb開発では、この下に「通信レイヤ」「インフラレイヤ」があり、
→ DNS・TLS・ロードバランサ・CDNなどが、このやり取りを安全・高速に支えている。

Web開発勉強会：応用編（ライブラリとフレームワークの理解）

説明

1. 用語の導入（超ざっくり）

ライブラリ：特定の機能を“足す”道具箱。あなた（アプリ）は使う側。
例）日付処理、HTTP通信、グラフ描画など。
フレームワーク：ある用途のアプリの“骨組み”。あなたは“乗っかる”側。
例）画面遷移・ルーティング・テンプレート・ビルド・テストなど一式。

2. 何が嬉しい？なぜ使う？（メリット / デメリット）

✅ メリット

再発明の排除：よくある課題（バリデーション、ルータ、フォーム、日付、グラフ等）を即解決。
品質と速度：枯れたベストプラクティスが最初から入っていて、開発スピードUP。
コミュニティ：情報・サンプル・プラグインが豊富。

⚠️ デメリット

学習コスト：概念（状態管理、ライフサイクル、DIなど）を覚える必要。
ロックイン：依存が強くなると乗り換え難度UP。
バージョン追従：便利さの裏に“アップデート対応”の運用負債。
ビルド依存：一部はツール必須（オフライン開発は苦労する）。

3. フロントエンド編（CDNで始められる）

ライブラリ（機能ピンポイント）

種類	ライブラリ名	概要 / 用途	CDN例
HTTP通信	Axios	fetchを使いやすく	`<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>`
日付処理	Day.js / date-fns	軽量な日時整形	`<script src="https://cdn.jsdelivr.net/npm/dayjs"></script>`
グラフ描画	Chart.js	円/棒/折れ線グラフ描画	`<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>`
ユーティリティ	Lodash	配列やオブジェクト操作	`<script src="https://cdn.jsdelivr.net/npm/lodash"></script>`

軽量フレームワーク（ビルド不要）

フレームワーク	特徴	CDN例
Alpine.js	HTML属性でリアクティブ。軽量・学習コスト低。	`<script defer src="https://cdn.jsdelivr.net/npm/alpinejs"></script>`
htmx	`hx-get`等で部分更新。API学習に最適。	`<script src="https://unpkg.com/htmx.org@1.9.12"></script>`
Petite-Vue	Vueの超軽量版。ミニマムでリアクティブ。	`<script src="https://unpkg.com/petite-vue"></script>`

CSSフレームワーク（CDNだけで見た目UP）

名前	特徴	CDN例
Pico.css	クラスほぼ不要。HTMLがそのまま美しく。	`<link rel="stylesheet" href="https://unpkg.com/@picocss/pico@latest/css/pico.min.css">`
Sakura.css / Milligram	軽量でミニマルなスタイル。	公式CDNあり
Tailwind Play CDN	クラスベース。学習用途に最適。	`<script src="https://cdn.tailwindcss.com"></script>`

大規模SPA系（概念紹介のみ）

React（ビュー専用）＋Next.js（SSR/SSGなど全部入り）
Vue.js＋Nuxt
Svelte＋SvelteKit
Angular

基本的にエンタープライズ実運用はビルド環境が前提。勉強会では“概念の理解”に留める。

4. バックエンド編（概念理解＋位置づけ紹介）

代表的フレームワーク（用途別）

言語	フレームワーク	特徴
Java	Spring Boot	企業利用最多、全部入り
Ruby	Ruby on Rails	企業利用最多、全部入り
Node.js	Express / NestJS / Fastify	軽量〜設計重視まで幅広い
Python	Django / Flask / FastAPI	Web全般〜API特化まで選べる
Go	Gin / Fiber	軽量・高速
PHP	Laravel / Slim	MVC・学習資料豊富
.NET	ASP.NET Core	Windows親和・クラウド対応

バックエンドでよく登場する部品

ルーティング（URL振り分け。L3の話ではない）
テンプレートエンジン（画面生成）
ORM（DBアクセス）
認証・認可
バリデーション
ロギング
設定/DI
テスト

勉強会では PowerShell 実装と対応付けて理解：
例）URLルーティング＝勉強会はswitch → FWではアノテーションで自動割り当て。

5. 流行り・廃り（2025時点の動向）

フロントエンド

領域	トレンド
React + Next.js	業界標準として定着
Vue + Nuxt	アジア圏で安定採用
Svelte + SvelteKit	シンプルで高速、急伸中
Angular	大規模・企業系で再評価
Astro	静的サイト特化（SSG志向）

バックエンド

領域	トレンド
Java Spring Boot	企業利用安定
FastAPI (Python)	API特化、人気上昇
Node系 (NestJS, Fastify)	WebAPI用途で拡大
Go系 (Gin/Fiber)	軽量・高速化ニーズで注目
Rust系 (Axum/Actix)	高信頼領域で増加中

まとめ

ライブラリ＝“機能の部品”、フレームワーク＝“骨組み”。
勉強会では利用せずにシンプルな仕組みで理解を狙う。
本格運用を意識するなら、React/Vue/Svelte/Springなどへ発展。

Web開発勉強会：インフラレイヤーの基礎整理

レイヤー整理

1. まずは全体像（人間の世界と通信の世界）

レイヤー	主な登場人物	イメージ
クライアント層	パソコン、スマホ、タブレット、ブラウザ、アプリ	「見る・操作する側」
サーバ層	Webサーバ、APサーバ、DBサーバ、OS、サーバマシン（ラック／タワー）	「処理・記憶する側」
ネットワーク層	Wi-Fi、有線LAN、ルータ、スイッチ、モデム、光回線、ISP	「つなぐ道路」
インターネット基盤層	DNS、DHCP、LB（ロードバランサ）、FW（ファイアウォール）、クラウド	「道路標識と交通整理」
通信プロトコル層	IP、TCP、HTTP/HTTPS、TLS、DNS、DHCP	「会話のルール」
データ層	HTML/CSS/JS、API(JSON/XML)、SQL	「やり取りされる中身」

2. クライアント層（手元の世界）

カテゴリ	用語	説明
ハードウェア	パソコン / スマホ / タブレット / ワンボードマイコン	実際の端末。形や性能に差あり。
OS（基本ソフト）	Windows / macOS / iOS / Android / Linux	アプリを動かす土台。ハードとアプリの仲介
アプリ / ブラウザ	Chrome / Edge / Safari / Firefox / 専用アプリ	Webページを解釈し、描画・操作を提供。
ネットワーク接続	Wi-Fi / LTE / 5G / 有線LAN	電波やケーブルで外の世界へ。

3. サーバ層（向こう側の世界）

カテゴリ	用語	説明
ハードウェア形態	ラックマウント / タワー型 / ワンボードマイコン（Raspberry Pi等）	規模・用途により形が異なる。
OS	Linux系 / Windows Server / FreeBSD など	サーバ用の基本ソフト。
Webサーバ	Apache / Nginx / IIS / PowerShellスクリプト等で自作も可	HTTPリクエストを最初に受ける。
APサーバ	Tomcat / Node.js / Spring Boot / Flask / 自作可	ビジネスロジックを処理。
DBサーバ	PostgreSQL / MySQL / SQLite / Oracle / SQL Server	永続データを管理・検索。基本的にRDB。
構成の分離例	Web / AP / DB サーバ分離	負荷分散・セキュリティ向上・保守性UP。

4. ネットワーク層（つなぐ仕組み）

形態	用語	説明
有線機器	LANケーブル、スイッチ	データを有線で中継。
無線機器	Wi-Fiルータ、アクセスポイント	電波で接続。SSID・暗号化が関係。
クラウド	AWS / Azure / GCP / さくらVPSなど	実体は世界中のどこかのデータセンタ。

機器	説明
ルータ	家や会社の“出口”。LANとWANをつなぐ。または部署の境界。
モデム	電話線・光回線とルータの橋渡し。
ISP（プロバイダ）	インターネットの「入り口」。OCN / au / SoftBank など。
LB（ロードバランサ）	アクセスを複数サーバに分散する交通整理係。
FW（ファイアウォール）	不正通信を防ぐ防火壁。

5. インターネット基盤層（裏方の仕組み）

用語	説明
DNS（Domain Name System）	URL→IPアドレスに変換（例：www.google.com → 142.250.xxx.xxx）
DHCP（Dynamic Host Configuration Protocol）	端末に自動でIPアドレスを割り当てる仕組み
TLS/SSL	通信内容を暗号化（HTTPSの“S”部分）。 SSLは旧称
IPアドレス	住所。v4とv6あり（例：192.168.0.10 / 2001:db8::1）
ポート番号	玄関番号（例：80=HTTP, 443=HTTPS, 5432=PostgreSQL）

6. 通信フローを追ってみる（日常シーン別）

会社内チャットを使う場合（社内LAN通信）

あなたのPC（Windows + ブラウザ）
   ↓ Wi-Fi / 有線LAN
   ↓
スイッチ → 社内ルータ（DHCPでIP配布）
   ↓
社内DNSサーバで名前解決
   ↓
社内APサーバ（チャットアプリ）にHTTPアクセス
   ↓
DBサーバからメッセージ履歴取得
   ↓
結果をブラウザに返却（HTML/JSON）

ポイント：

インターネットを通らない「イントラネット通信」
セキュリティ・通信速度が高い・速い

自宅でGoogle検索する場合

スマホ（Chrome） or PC（Edge）
   ↓
Wi-Fiルータ（DHCPでIP割り当て）
   ↓
ONU（光回線終端装置）
   ↓
ISP（プロバイダ） インターネットへ
   ↓
DNSで www.google.com のIPを取得
   ↓
Googleデータセンタ（多分LB→Web→AP→DB）
   ↓
検索結果をHTMLで返却

ポイント：

DNS・ISPが裏で動いている
Googleは世界中に分散サーバを持ち、近いリージョンに接続される

電車内でネットショッピングする場合（モバイル回線）

スマホ（4G/5G）
   ↓
基地局（キャリアのアンテナ）
   ↓
キャリア網（docomo/au/SoftBank）
   ↓
インターネット
   ↓
ショッピングサイトのCDN（画像・静的ファイル）
   ↓
Webサーバ → APサーバ → DBサーバ
   ↓
購入情報を返却

ポイント：

電波状況で通信品質変動
CDN（Content Delivery Network）が“距離を短縮”

人気チケットを申し込み開始直後にアクセスしたのに繋がらない

多数のユーザー（全国から同時アクセス）
   ↓
ISP → インターネット → DNS
   ↓
チケット販売サイトのLB（ロードバランサ）
   ↓
Webサーバ群 → APサーバ群 → DB
   ↓
負荷過多によりレスポンス低下 or 制限

ポイント：

同時アクセス集中により スローダウン / 接続制限 / 503エラー
対策：CDN・キャッシュ・スケーリング・キュー制御・予約分散など

7. 通信の層モデル（OSIとTCP/IPのイメージ）

OSI参照モデル	TCP/IPモデル	主なプロトコル / 機器	例
7. アプリケーション層	アプリケーション層	HTTP, HTTPS, DNS	Webブラウザ, Webサーバ
6. プレゼンテーション層	↑	TLS/SSL	HTTPS暗号化
5. セッション層	↑	TCPハンドシェイク	接続の確立/維持
4. トランスポート層	トランスポート層	TCP, UDP	ポート番号の識別
3. ネットワーク層	ネットワーク層	IP	ルーティング, IPアドレス
2. データリンク層	データリンク層	Ethernet, Wi-Fi	MACアドレス, LAN通信
1. 物理層	物理層	ケーブル, 電波	実際の伝送媒体

8. まとめ（インフラレイヤーを理解する視点）

観点	質問例	見えてくる理解
どこを通って通信している？	Wi-Fi？4G？有線（メタル）？有線（光）？	経路と帯域の違い
誰が名前を変換している？	DNS？hosts？	ネット上または手元の住所帳
誰がIPを配っている？	DHCP？固定？	ネット接続の開始点。住所設定
誰がさばいている？	LB / FW？	混雑制御・セキュリティ
どこで処理される？	Web / AP / DB？	責務分離と構成管理

一言まとめ

Webの裏では「住所帳（DNS）」「地図、道案内（ルータ）」「交通整理（LB）」「警備員（FW）」が働いている。
画面1枚の表示の裏で、数十もの機器・仕組みが連携している。

発展学習の方向

ping / tracert / nslookup / dig などのコマンドで経路、処理を“見える化”
自宅LAN内でミニサーバを立てて“通信の旅”を体験
クラウド上でWeb・AP・DBを分けて構築する実習へ発展

Web開発用語樹形図・ツリー構造まとめ

各ツリーは厳密な技術区分よりも「理解しやすい関連性」を優先しています。

① Webシステム全体構造（レイヤー別）

Webシステム
├─ クライアント層（フロントエンド）
│  ├─ ブラウザ
│  │  ├─ HTML（構造）
│  │  ├─ CSS（見た目）
│  │  └─ JavaScript（動き・通信）
│  ├─ フレームワーク・ライブラリ
│  │  ├─ React / Vue / Angular
│  │  └─ jQuery / Bootstrap / Tailwind CSS
│  └─ 通信方式
│     ├─ HTTP / HTTPS
│     └─ Ajax / Fetch / WebSocket
│
├─ アプリケーション層（バックエンド）
│  ├─ Webサーバ
│  │  ├─ Apache / Nginx / IIS / PowerShell HttpListener
│  │  └─ 静的コンテンツ（HTML, CSS, JS）
│  ├─ APサーバ（動的処理）
│  │  ├─ Java (Spring Boot) / Node.js / Python / PHP / Ruby
│  │  └─ テンプレート生成・API応答
│  └─ DBサーバ
│     ├─ PostgreSQL / MySQL / SQLite
│     └─ データの永続化・検索・更新
│
└─ インフラ層（ネットワーク・物理）
   ├─ ノード（実体）
   │  ├─ PC / スマホ / タブレット（クライアント）
   │  └─ サーバ / VM / コンテナ（サーバ側）
   ├─ リンク（接続）
   │  ├─ LAN / WAN / 光回線 / モバイル通信
   │  └─ ルータ / スイッチ / モデム / LB
   └─ インターネット基盤
      ├─ DNS（名前解決）
      ├─ DHCP（IP割り当て）
      └─ FW / Proxy / CDN / Cloud

② ソフトウェア技術系ツリー（言語・FW・ライブラリ）

Web技術
├─ 言語
│  ├─ フロントエンド、クライアントサイド（ブラウザで動作）
│  │  ├─ マークアップ：HTML
│  │  ├─ スタイル：CSS
│  │  ├─ スクリプト：JavaScript / TypeScript
│  ├─ バックエンド、サーバサイド：Java / Python / PHP / Ruby / Node.js
│  │  └─ DB操作：SQL
│
├─ フレームワーク
│  ├─ フロントエンド：React / Vue / Angular
│  │  └─ CSS系：Bootstrap / Tailwind / Bulma
│  └─ バックエンド：Spring / Django / Express / Rails
│
└─ ライブラリ・ツール
   ├─ jQuery / Axios / Chart.js / p5.js
   ├─ ビルド：Webpack / Vite / Babel
   └─ 管理：npm / Maven / pip

③ アーキテクチャ構成（論理的な分離）

システム構成
├─ 単層構成（1台、ブラウザで完結）
│  └─ HTML + JS + ローカルストレージ
│
├─ 3層構成
│  ├─ Webサーバ（静的配信）
│  ├─ APサーバ（動的処理）
│  └─ DBサーバ（データ永続化）
│
└─ 拡張構成
   ├─ APIサーバ（JSON処理、返却）
   ├─ 認証サーバ（OAuth / OpenID Connect）
   ├─ キャッシュサーバ（Redis / Memcached）
   ├─ ファイルサーバ / CDN
   └─ ロードバランサ・監視サーバ

④ Web技術の時代変遷ツリー

Web進化の流れ
├─ 静的Web（1990年代）
│  └─ HTML + 画像（手書き更新）
│
├─ 動的Web（2000年代）
│  ├─ サーバサイド生成（PHP, ASP, JSP）
│  └─ DB連携サイト
│
├─ Ajax・SPA時代（2010年代）
│  ├─ JavaScript強化 / API通信
│  └─ React / Vue / Angular 登場
│
└─ クラウド・モバイル時代（2020年代）
   ├─ クラウド（AWS / GCP / Azure）
   ├─ DevOps・CI/CD・コンテナ
   └─ オフライン動作（PWA / ローカルストレージ / IndexedDB）

⑤ セキュリティ・運用・スケール観点

Webセキュリティ
├─ 通信保護
│  ├─ HTTPS / TLS証明書
│  └─ HTTPヘッダー（HSTS, CSP）
│
├─ アプリ対策
│  ├─ XSS / CSRF / SQL Injection
│  └─ 入力バリデーション / サニタイズ
│
└─ 運用・管理
   ├─ ログ監視 / アクセス制御 / 認証認可
   ├─ クラウド運用（スケール・負荷分散）
   └─ バックアップ・障害対応・監査

⑥ 配置・規模・運用範囲

運用形態
├─ ローカル環境
│  └─ 自分のPC上でvscodeやEclipse実行
│
├─ イントラネット（社内LAN）
│  ├─ 社内限定アクセス
│  └─ 管理者・開発部門向けツール
│
├─ インターネット公開
│  ├─ レンタルサーバ / VPS
│  └─ クラウド（AWS / GCP / Azure / Render）
│
└─ 規模
   ├─ 個人サイト・学習用
   ├─ 小規模業務システム
   ├─ 商用Webサービス
   └─ 分散マイクロサービス構成

自分が気になる方面の用語整理を続けてみてください。
↓例えば「認証」について。

Web開発における「認証」整理（ノード・レイヤー・方式・時代別）

認証整理

1. 認証とは何か

認証（Authentication）とは、
「相手が誰であるか」を確認する仕組み。

目的：
- 不正アクセスを防ぐ
- ユーザー固有の情報を扱うための識別
- 信頼できる通信・操作を保証するための前提

2. ノード別の認証

ノード	具体例	主な認証対象	備考
クライアント端末	PC、スマホ、IoT機器	ログイン情報、トークン、証明書	端末自身や利用者を識別
Webサーバ	Apache / Nginx / IIS	ブラウザやAPIクライアント	Basic認証、TLSクライアント証明書など
APサーバ	Java / Python / Node.jsなど	ユーザー、セッション、APIキー	ログイン処理やJWT認証を担当
DBサーバ	PostgreSQL / MySQLなど	APサーバ（接続元）	DB接続時のID・パスワードによる認証
ネットワーク機器	ルータ / FW / VPN	管理者・接続元IP	SSH認証、証明書認証など

3. レイヤー別の認証

レイヤー	認証の内容	具体的な技術例
ネットワーク層	通信元ノードの識別	IP制限、MAC認証、VPN認証
トランスポート層	通信経路の暗号化・証明	TLS（HTTPS）サーバ証明書／クライアント証明書
アプリケーション層	ユーザー認証・権限確認	Basic認証、Cookie＋Session、JWT、OAuth2.0、OpenID Connect

4. 認証のタイミングと流れ

① 通信前認証（接続時）
   └─ 例：VPN、TLS証明書、SSHキーなど

② 通信開始時（最初のHTTPリクエスト）
   └─ 例：Basic認証、APIキー認証

③ アプリ利用開始時（ログイン画面）
   └─ 例：ID＋パスワード入力、OTP（ワンタイムパス）

④ 通信中（セッション維持）
   └─ 例：Cookie＋Session ID、JWTトークン、Refresh Token

⑤ API連携時
   └─ 例：OAuth2.0、Bearerトークン

5. 認証の目的と分類

分類	概要	主な方式	使用例
知識認証	知っていること	ID＋パスワード、PIN	一般的なログイン
所持認証	持っているもの	スマホ、トークン、証明書	2段階認証、OTP
生体認証	体の特徴	指紋、顔認識、虹彩	スマホ・PCロック解除など
属性認証	所属・役職・権限など	SSO、SAML、LDAP	社内ログイン、イントラネット
多要素認証 (MFA)	上記の組み合わせ	パスワード＋OTPなど	高セキュリティ環境

6. 認証方式の進化（時代別）

1990年代：Basic認証
 - IDとパスワードをBase64で送信（簡易）
 - HTTP標準だが安全性低

2000年代：Cookie＋Session認証
 - ログイン成功時にサーバがセッションID発行
 - クライアントはCookieで維持
 - サーバ側で状態管理（ステートフル）

2010年代：トークン認証（JWT, APIキー）
 - サーバ側に状態を持たない（stateless）
 - JSON Web Tokenで署名付き情報を渡す
 - SPAやモバイルアプリと相性が良い

2015年代〜：OAuth2 / OpenID Connect
 - 外部サービス認証（Google, GitHubなど）
 - 「なりすまし防止」「権限委譲」に対応
 - クラウド・API時代の標準化

2020年代〜：パスワードレス / FIDO2
 - 生体認証・デバイス連携・公開鍵暗号
 - WebAuthn対応ブラウザで実現可能

7. 認証の目的と関連技術

目的	主な仕組み	関連技術
誰なのか知りたい	ID / パスワード	HTMLフォーム、POST送信
なりすまし防止	トークン署名	JWT、HMAC、RSA署名
権限を制御したい	ロール管理	RBAC、ACL
セッション維持	Cookie / Session ID	Spring Session、Express Session
外部連携したい	OAuth2 / OIDC	SNSログイン、SSO
人以外（機器・アプリ）認証	APIキー / クライアント証明書	IoT、サーバ間通信
一度の認証で複数利用	SSO（シングルサインオン）	SAML、OpenID Connect

8. 認証と認可の違い

用語	意味	例
認証（Authentication）	「誰か」を確認	ログイン、トークン検証
認可（Authorization）	「何ができるか」を制御	管理者のみ操作可、APIアクセス制御
監査（Audit）	「何をしたか」を記録	ログ保存、アクセス追跡

認証 → 認可 → 監査
はセキュリティの3本柱。

9. 認証の実装ポイント（Webアプリ開発）

フロントエンド：
  - ログインフォーム、Cookie操作、トークン保存(localStorage)
  - API呼び出し時にAuthorizationヘッダ付与

バックエンド：
  - 入力値のバリデーション
  - パスワードのハッシュ化（bcrypt, Argon2）
  - JWT検証・有効期限管理
  - セッションストア（Redisなど）

DB：
  - ユーザー情報（ID、パスワードハッシュ、権限）
  - トークン無効化リスト（ログアウト対応）

インフラ：
  - HTTPS通信必須
  - CookieのSecure / HttpOnly属性設定

10. まとめ（認証の多層的理解）

レイヤー：アプリケーション層（主）＋ 通信層（補助）
ノード　：クライアント／Webサーバ／APサーバ／DBサーバ間で行われる
目的　　：本人確認・不正防止・権限制御
方式　　：パスワード → セッション → トークン → OAuth → FIDO
時代　　：静的Web → 動的Web → API連携 → 分散クラウド

このように、Web開発における「認証」は、

誰を（User / App / Device）
どの層で（通信層 or アプリ層）
どの方式で（Session / Token / OAuthなど）
いつ行うか（通信前／通信中／継続中）
を明確に区別することが重要です。

フロントエンド編

バックエンド編