カテゴリDへの入口
カテゴリAでは、Webアプリがどんな部品でできていて、人間とAIがどう分担するかを見てきました。カテゴリDでは一歩進んで、その部品どうしが実際にどうやり取りしているか、つまり通信の中身に入ります。その入口となるのが、今回の「誰が頼み、誰が応えるか」です。ここがわかると、この先のURLやHTTPの話が、すべて要求と応答の物語として一本につながって見えてきます。
このスライドのポイント
- カテゴリA: Webアプリの部品と、人間・AIの分担を学んだ
- カテゴリD: その部品どうしが実際にどうやり取りしているか＝通信の中身へ
- 最初の一歩: 「誰が頼み、誰が応えるか」
クライアントとサーバーの定義
まず定義します。クライアントとは、通信で要求を出す側の役割です。サーバーとは、その要求を受けて処理し、データを提供する側の役割です。ここで大切なのは、どちらも役割を指す言葉であって、特定の機械の種類を指すのではない、という点です。A-03で見た部品図と対応させると、ブラウザとフロントエンドがクライアント側、サーバーとデータベースがサーバー側にあたります。要求を出せばクライアント、要求に応えればサーバー、と覚えてください。
このスライドのポイント
- クライアント＝通信で要求を出す側の役割
- サーバー＝要求を受けて処理し、データを提供する側の役割
- どちらも「役割」であって、特定の機械の種類を指す言葉ではない
- A-03の部品との対応: ブラウザ＋フロントエンド＝クライアント側／サーバー＋データベース＝サーバー側
なぜこの区別が必要か
この区別を持たないと、この処理はどこで動いているのか、という問いを立てられません。すると、本来は秘密にすべき情報を利用者の画面側に置いてしまったり、重い処理を非力な画面側でやらせてしまったりといった誤りに気づけません。また、エラーが起きたときにも、どちら側の問題かを切り分けやすくなります。どちら側で動くかを問える力は、AIが作ったものの安全性と性能を確かめる土台になります。
このスライドのポイント
- 区別できないと「この処理はどこで動いているか」を問えない
- 起きる誤り: 秘密情報を画面（クライアント）側に置く／重い処理を画面側にやらせる
- どちら側で動くかを問える力＝AIの成果物の安全性・性能を確かめる土台
要求と応答の構造
構造はとても単純です。左にクライアント、右にサーバーを置き、その間を要求と応答が往復します。クライアントは要求の内容を決め、返ってきた結果を表示する役割を持ちます。サーバーは、その要求を処理する正しさと、扱うデータの管理に責任を持ちます。要求と表示はクライアント側、処理とデータはサーバー側、という責任の分かれ目を覚えておいてください。
このスライドのポイント
- 左にクライアント（要求を出す）、右にサーバー（処理して応える）
- 間を「要求→」「←応答」が往復する
- 責任範囲: 要求の内容と表示＝クライアント側／処理の正しさとデータの管理＝サーバー側
役割は場面で入れ替わる
具体例で見ましょう。天気アプリでは、画面が東京の天気をくださいと要求し、サーバーが調べて応答します。ここで面白いのは、そのサーバーが自分では天気を持っておらず、外部の気象サービスへ問い合わせる場合です。その瞬間、サーバーは今度は要求を出す側、つまりクライアントの役割になります。役割は固定ではなく、場面によって入れ替わるのです。
このスライドのポイント
- 天気アプリ: 画面が「東京の天気をください」と要求→サーバーが調べて応答
- そのサーバーが外部の気象サービスへ問い合わせる瞬間、サーバーはクライアントの役割になる
- 役割は固定ではなく、場面によって入れ替わる
技術サンプル: 最小の要求と応答
07は技術サンプルです。今回は、最小の要求と応答の対を見ます。上半分がクライアントからサーバーへの要求で、天気を取りに行く一行と、宛先を示すHostが並んでいます。下半分がサーバーからクライアントへの応答で、200という結果と、晴れというデータが返っています。この書式の細かい読み方はD-03とD-04で一行ずつ学びます。今日は、上が要求、下が応答という向きだけつかめれば十分です。
混同しやすい点: サーバーは機械か役割か
混同しやすいのは、サーバーとは特定の機械のことだ、という思い込みです。実際には、サーバーは役割の名前です。同じひとつのプログラムでも、外からの要求を受けているときはサーバー、自分から外部へ頼んでいるときはクライアントになります。機械で覚えるのではなく、そのとき要求を出しているか応えているか、で見分けてください。役割で捉えれば、複雑な構成になっても通信の向きを見失わずにすみます。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが作った機能について、この処理はクライアント側とサーバー側のどちらで動きますか、を毎回聞く習慣をつけましょう。もし秘密情報や重要な判定が画面側、つまりクライアント側にあるなら、それは危険信号です。安全性の詳しい扱いは後のカテゴリQで学びますが、今の段階では、どちら側かを問えることが第一歩になります。
このスライドのポイント
- AIが作った機能に毎回聞く: 「この処理はクライアント側とサーバー側のどちらで動きますか」
- 秘密情報や重要な判定がクライアント側にあれば危険信号
- 安全性の詳細はカテゴリQで扱う（今は「どちら側か」を問えることが第一歩）
一問一答とまとめ
最後に一問一答です。あなたのサーバーが外部APIを呼ぶとき、そのサーバーの役割は何でしょうか。……答えはクライアントです。要求を出す側だからです。30秒でまとめます。クライアントは要求を出す側、サーバーは応える側で、どちらも機械ではなく役割を指し、場面で入れ替わります。次回は、その要求の宛先を正確に書く道具、URLの構造へ進みます。関連資料は「Webアプリ構築 完全ワークフロー」「API連携 超入門」「Webアプリ構成図入門」です。
このスライドのポイント
- 一問一答: あなたのサーバーが外部APIを呼ぶとき、そのサーバーの役割は？ → クライアント（要求を出す側だから）
- 30秒まとめ: クライアント＝要求を出す側／サーバー＝応える側／どちらも機械でなく役割／場面で入れ替わる
- 次回: 要求の宛先を正確に書く道具＝URLの構造へ
- 関連資料: 「Webアプリ構築 完全ワークフロー」「API連携 超入門」「Webアプリ構成図入門」
