Webアプリケーションにおけるクライアント・サーバモデルの基礎 HTTP・Fetch API・WebSocket・MCPサーバー
はじめに
この章では、Webアプリの通信の土台であるクライアント・サーバモデルを学びます。
画面が表示される理由、API が動く理由、ログイン状態が続く理由を理解するには、このモデルの理解が欠かせません。
HTTP は Web のデータ交換の基礎であり、クライアント・サーバプロトコルとして、通常はブラウザーなどのクライアントがリクエストを開始し、サーバーがレスポンスを返します。
さらに、1つのWebページは HTML だけでなく、CSS、画像、動画、スクリプトなど複数のリソースから構成されます。
前章では、フロントエンド、バックエンド、データベースという三つの役割を見ました。
この章では、その三つがどのように通信で結ばれるかを、HTTP、ステータスコード、状態管理、Fetch API、WebSocket、MCP まで含めて整理します。
MCP は、AI アプリケーションを外部データやツールへ接続するためのオープン標準として説明されています。
この章で学ぶこと
- クライアントとサーバーの役割
- HTTP の基本構造
- リクエストとレスポンス
- HTTP メソッドとステータスコード
- ステートレスと状態管理
- Fetch API と WebSocket の違い
- MCPサーバーと AI Agent の位置づけ
1. なぜクライアント・サーバモデルが必要なのか
Webアプリは、一台の中だけでは完結しません。利用者は画面で入力し、その内容をサーバーへ送り、サーバーが処理して結果を返します。
サーバー側では必要に応じてデータベースや他のシステムとも連携します。MDN でも、クライアントとサーバーが HTTP で通信し、サーバーが要求を処理して応答を返す構造が説明されています。
クライアント・サーバモデルとは、要求する側と応答する側に分けて仕組みを理解する考え方です。Web では、通常ブラウザーがクライアントで、Web サーバーがサーバーです。この区別があると、「どこで何をしているか」を説明しやすくなります。
flowchart LR
U[ユーザー] --> C[クライアント<br>ブラウザー]
C -->|HTTP Request| S[サーバー]
S -->|必要に応じてアクセス| D[(データベース)]
D --> S
S -->|HTTP Response| C
C --> U
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 画面だけで Web を理解する | API や保存の意味が見えない | 要求側と応答側に分ける |
| 何がどこで動くか曖昧 | デバッグしにくい | クライアントとサーバーを分ける |
| サービスを1台で考える | 複数人利用を説明しにくい | 共通処理をサーバーに置く |
2. クライアントとは何か
クライアントは、利用者の操作を受ける側です。代表例はブラウザーです。リンクをクリックし、フォームを送り、検索を実行し、サーバーへ要求を出します。
そして返ってきた結果を画面へ表示します。つまりクライアントは、利用者の窓口であり、要求の出発点です。
MDN では user-agent がクライアント側の役割を担い、通常はブラウザーがそれに当たると説明されています。
クライアントにはできることと、向いていないことがあります。画面表示や操作受付は得意です。
一方で、重要な権限判定や共通ルールの最終決定をクライアントだけに任せるのは危険です。そのため、サーバーと役割分担します。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| ユーザー操作の入口がない | サービスとして使えない | クライアントが受け持つ |
| 結果を見せられない | 利用価値が下がる | レスポンスを画面に反映する |
| 重要処理を全部クライアントへ置く | 改ざんや不整合が起こる | サーバーと分担する |
3. サーバーとは何か
サーバーは、クライアントから届いた要求を受け取り、必要な処理を行い、結果を返す側です。
ログイン判定、商品一覧取得、予約登録、投稿保存、権限チェックなどは、典型的なサーバー処理です。
MDN でも、サーバーがリクエストを待ち受け、処理し、HTTP レスポンスを返すと説明されています。
サーバーが必要なのは、複数ユーザーへ共通のルールを適用し、データを安全に扱うためです。
クライアントごとに別々の判断をすると、結果が揺れやすくなります。そこで、共通処理をサーバーへ寄せます。
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 各端末で別々にルールを判断する | 結果が不安定になる | サーバーで一元処理する |
| データを直接触らせる | 安全性が下がる | サーバーを仲介にする |
| 画面と処理を混同する | 設計が複雑になる | サーバーの責務を分ける |
4. HTTPとは何か
HTTP は、Web で使われる通信の基本です。クライアントがリクエストを送り、サーバーがレスポンスを返します。
さらに、HTML 文書だけでなく、CSS、JavaScript、画像なども、それぞれ別の HTTP リクエストで取得されます。そのため、一つの画面は複数通信の積み重ねでできています。
HTTP を理解すると、「なぜ画面が表示されるか」だけでなく、「なぜ API が失敗するか」も読みやすくなります。通信はブラックボックスではなく、要求と応答の往復として捉えると整理しやすいです。
HTTP の基本イメージ
- クライアントが URL とメソッドを送る
- サーバーが内容を解釈する
- 必要な処理を実行する
- ステータスコードと本文を返す
5. HTTPメソッドとステータスコード
HTTP メソッドは、「何をしたいか」を表します。MDN は GET、POST、PUT、PATCH、DELETE などを代表的なメソッドとして整理しています。
たとえば GET は取得、POST は新規作成、PUT や PATCH は更新、DELETE は削除です。ステータスコードは、「その結果どうなったか」を表します。MDN はレスポンスコードを 1xx から 5xx の五分類で整理しています。
代表例として、200 OK、201 Created、400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、500 Internal Server Error などがあります。
| 種類 | 代表例 | 意味 |
|---|---|---|
| 2xx | 200 OK / 201 Created | 成功 |
| 3xx | 302 Found | 転送・移動 |
| 4xx | 400 / 401 / 403 / 404 | クライアント側の問題 |
| 5xx | 500 Internal Server Error | サーバー側の問題 |
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| 通信結果を雰囲気で見る | 原因を見誤る | メソッドとコードで整理する |
| 成功失敗の意味が曖昧 | ログを読めない | 代表コードを押さえる |
| API の意図が見えない | 設計がぶれる | メソッドごとの役割を理解する |
6. ステートレスと状態管理
HTTP はステートレスです。これは、前の通信内容を標準では覚えていないという意味です。
つまり、各リクエストは独立しています。この性質があるため、ログイン状態や買い物かごの内容を、別の仕組みで保持する必要があります。
MDN でも、HTTP は stateless だが cookies によって stateful sessions を実現できると説明しています。
状態管理の代表例は Cookie です。サーバーは Set-Cookie ヘッダーで情報を送り、後続リクエストでクライアントが返送できます。加えて、Session やトークンを使う考え方もあります。
この節の課題と解決
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| HTTP を単純な往復だけで考える | ログイン維持を説明できない | ステートレス性を知る |
| 状態保持の必要性が見えない | 認証の理解が浅くなる | Cookie や Session を学ぶ |
| 状態管理を曖昧にする | セキュリティ理解が弱くなる | 何をどこで持つか整理する |
7. Fetch APIによる基本通信
Fetch API は、ブラウザーからリソース取得や API 呼び出しを行うためのインターフェースです。
MDN でも、Fetch API は network 上の resources を取得するための仕組みとして説明されています。
Fetch API は、商品一覧の取得、フォーム送信、設定更新などの一回ごとの通信に向いています。送って、返ってきて、終わる。この形が基本です。Webアプリの多くは、まずこの形から始まります。
sequenceDiagram
participant C as Client
participant S as Server
C->>S: Fetch APIでHTTP Request
S-->>C: HTTP Response(JSON/HTML)
C->>C: 画面更新
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| クライアント通信の入口が見えない | API 理解が浅くなる | Fetch API を基本形として学ぶ |
| 何でも同じ通信と思う | 用途差が見えない | 一回ごとの通信と整理する |
| 画面更新との関係が見えない | 実装像がつかめない | 取得→反映で理解する |
8. WebSocketによる双方向通信
WebSocket は、クライアントとサーバーの間で接続を維持したまま双方向通信を行う仕組みです。
MDN は、ブラウザーとサーバーの間で双方向の対話的通信セッションを開けると説明しています。ポーリングなしでサーバーからも情報を送れる点が特徴です。
Fetch API が一回ごとの往復通信なら、WebSocket はつながり続ける通信です。そのため、チャット、リアルタイム通知、共同編集、ライブ更新などに向いています。即時性が大事な要件で価値を発揮します。
| 項目 | Fetch API | WebSocket |
|---|---|---|
| 通信の形 | 一回ごとの要求と応答 | 接続維持型の双方向通信 |
| 向く用途 | 一覧取得、送信、更新 | チャット、通知、共同編集 |
| 特徴 | シンプルで基本形 | 即時性に強い |
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| Fetch API だけで全通信を考える | リアルタイム要件を説明できない | WebSocket を別枠で理解する |
| サーバーから押し戻す通信が見えない | 通知構造がわからない | 双方向通信として整理する |
| 用途差が曖昧 | 技術選択を誤る | 役割で比較する |
9. MCPサーバーとAI Agentの位置づけ
MCP は Model Context Protocol の略です。公式ドキュメントでは、AI アプリケーションを外部システムへ接続するためのオープン標準と説明されています。接続先には、ローカルデータソース、リモートサービス、ツールなどが含まれます。
ここで重要なのは、MCPサーバーもクライアント・サーバモデルの延長として理解できることです。違うのは、クライアントが必ずしもブラウザーではない点です。LLM アプリケーションや AI Agent がクライアント側になることがあります。
AI Agent は、人の代わりに要求を送り、ツールやデータへアクセスし、必要な結果をまとめる主体です。MCP の説明でも、AI applications が MCP servers に接続して context や tools を取得する構造が示されています。
MCP と通常の API サーバーの比較
| 観点 | 通常の Web API サーバー | MCP サーバー |
|---|---|---|
| 主な相手 | ブラウザーやアプリ | LLM アプリや AI Agent |
| 役割 | データや処理を返す | ツール・データ・文脈をつなぐ |
| 共通点 | 要求を受けて応答する | 要求を受けて応答する |
まとめ
| 課題 | 何が起きるか | 解決 |
|---|---|---|
| MCP を別世界の概念と見る | 基本通信モデルと切れる | クライアント・サーバの拡張として捉える |
| AI Agent を特別扱いしすぎる | 仕組み理解が浅くなる | 「要求する側」として整理する |
| Fetch / WebSocket / MCP の違いが曖昧 | 用途判断を誤る | 役割と利用場面で比較する |
10. 具体例で比べる
Fetch API で十分な例
- 商品一覧取得
- フォーム送信
- 設定更新
WebSocket が向く例
- チャット
- リアルタイム通知
- 共同編集
MCPサーバーと AI Agent が向く例
- LLM が社内ツールを呼び出す
- AI が外部データを参照する
- Agent が複数ツールを連携する この比較を通じて、通信方式は一種類ではないこと、そして目的ごとに向き不向きがあることが見えてきます。基礎を押さえたうえで違いを知ることが大切です。
11. この章の到達目標
この章を終えた時点で、次の内容を説明できるようになることを目指します。
-
クライアントとは何か
-
サーバーとは何か
-
HTTP の基本構造
-
リクエストとレスポンス
-
ステートレスと状態管理
-
Fetch API と WebSocket の違い
-
MCPサーバーと AI Agent の位置づけ また、次の区別ができることも重要です。
-
クライアントの責務とサーバーの責務
-
一回ごとの通信と双方向通信
-
通常の API サーバーと MCP サーバー
-
画面表示と通信の役割
12. 考えてみよう
- なぜブラウザーだけで Webアプリは完結しないのでしょうか。
- なぜ HTTP の理解が API 理解につながるのでしょうか。
- なぜ Fetch API だけでは足りない場面があるのでしょうか。
- なぜ WebSocket はリアルタイム処理で使われるのでしょうか。
- なぜ MCPサーバーと AI Agent も、クライアント・サーバモデルの延長で理解できるのでしょうか。
13. まとめ
- クライアント・サーバモデルは、要求する側と応答する側に分けて Web を理解する基本枠組みです。
- HTTP は Web のデータ交換の基礎であり、リクエストとレスポンスの往復で成り立ちます。
- Fetch API は基本的な HTTP 通信の入口です。
- WebSocket は、接続維持型の双方向通信として、リアルタイム要件に向いています。
- MCPサーバー と AI Agent は、クライアント・サーバモデルの現代的な拡張として理解できます。