フロントエンドとバックエンドをつなぐ - 1リクエストの全体像
1リクエストを追う理由
フロントエンド編とバックエンド編で、ブラウザ側とサーバー側の役割を分けて整理してきました。最後に、ブラウザから機器を操作・監視する例で、1つの操作がどこを通るのかを追います。
細かな例外や厳密な定義は一部省略しています。実際の設計では、採用する通信方式やフレームワークの公式ドキュメントも確認してください。
先に結論
- 1つの操作は、フロントエンド・通信・バックエンド・データ（や機器）を順にたどって完結します。
- これまで別々に学んだ技術は、1本のリクエストの中で、それぞれの持ち場を担当しています。
- 「どこで何を判断し、どこにデータがあるか」を追えると、システム全体が見通せるようになります。
1本のリクエストで役割をつなぐ
ここまで、フロントエンド編で「ブラウザの中で動くもの」を、バックエンド編で「サーバーの中で動くもの」を見てきました。
この最終回では、その2つを1本の線でつなぎます。
題材は、シリーズを通してときどき触れてきた「ブラウザから機器を操作・監視するWEBアプリ」です。たとえば、ロボットや調光装置のような“出力を持つ機器”を、ブラウザの画面から「今いくつか」を見て（監視）、「上げる・下げる」で動かす（操作）、というイメージです。
まず、登場人物（部品）の持ち場をおさらいします。
| 部品 | 持ち場 | どの回で扱ったか |
|---|---|---|
| ブラウザ（フロントエンド） | 画面の組み立て・操作の受付・結果の表示 | フロントエンド編 |
| ネットワーク | フロントエンドとバックエンドの間の通信路（HTTPS） | 各回 |
| バックエンド（API） | 受付・認証/認可・判断・機器やDBへの橋渡し | バックエンド編 |
| データベース／機器 | データの保存、または制御の対象 | バックエンド編 |
シナリオ①：値を「見る」（監視のリクエストを1本追う）
画面に現在値を表示する、いちばん基本的な流れです。
- ブラウザ（フロントエンド）が「現在値をください」と要求します（例：
GET /api/status）。 - 要求はHTTPSの通信路を通ってバックエンドに届きます。
- バックエンドは、トークンを確認して「誰からの要求か」を判断します（認証）。
- 問題なければ、機器やデータベースから現在値を取得します。
- バックエンドは、データ（JSON）と
200 OKを返します。 - フロントエンドが受け取ったデータで、画面の数値だけを書き換えます。
これを短い間隔でくり返すと、画面が“動き続ける”リアルタイムに近い監視になります。この「一部だけ書き換える」動きは、フロントエンド編のSPAの話そのものです。
シナリオ②：値を「変える」（操作のリクエストを1本追う）
次は、ボタンで機器を動かす流れです。見るだけの①より、チェックが増えます。
- 利用者が「上げる」ボタンを押します。
- フロントエンドは、新しい値をトークンを添えて送ります（例：
POST /api/output）。 - バックエンドは、まず認証（誰か）と認可（その操作をしてよいか）を確認します。
- 次に入力の最終チェックをします（範囲外の値でないか、など）。フロントエンドでも軽く確認しますが、本当の判断はここです。
- 問題なければ機器へ値を適用し、必要なら操作の記録をデータベースに残します。
- 結果と
200 OKを返し、フロントエンドが画面へ反映します。 - もし途中で弾かれたら、
401（未認証）・403（権限なし）・400（値が不正）・500（サーバー側の失敗）などが返り、フロントエンドはエラー表示をします。
「見る」と「変える」で必要な確認の重さが違う、という感覚が持てると、設計の勘所が見えてきます。
1リクエストの全体像（図）
全体の構成図
既存のシーケンス図に登場する要素を、利用者側とサーバー側の配置として並べ直します。
どこで何を担当しているか（総整理）
1本のリクエストを、工程ごとに「誰が・何を・どの回で扱ったか」で並べると、シリーズ全体が1枚につながります。
| 工程 | 担当 | 何をするか | 関連する回 |
|---|---|---|---|
| 画面の組み立て・操作受付 | フロントエンド | 見た目を作り、操作を受け取る | フロントエンド①〜③ |
| 通信 | ネットワーク | HTTPSで安全に運ぶ | 各回 |
| 受付・認証・認可 | バックエンド | 誰か・してよいかを判断 | バックエンド③ |
| 業務判断・入力の最終確認 | バックエンド | 正しさを担保する | バックエンド①③ |
| 保存・取り出し／機器制御 | データ・機器 | データや対象を扱う | バックエンド①② |
| 応答・画面反映 | バックエンド→フロントエンド | 結果を返し、表示する | 全編 |
勘違いしやすい解釈
-
「全部フロントエンドでできる」「全部バックエンドでできる」ではありません。
それぞれに向き不向きがあります。見た目と操作性はフロントエンド、正しさと安全はバックエンド、という役割分担が土台です。 -
「リアルタイムな操作・監視は特別な技術」ではありません。
これまで見てきた部品（API、JSON、SPAの部分更新、短い間隔の通信）の組み合わせでできています。魔法ではありません。 -
「1つの操作＝1つの通信」とは限りません。
1画面の表示に複数のAPIリクエストが飛ぶことはよくあります。まずは「1つの操作を1本追う」ことから始めると、複雑な画面も分解して読めるようになります。
設計や不具合調査で意識すること
- 新しい機能を設計するときは、1つの操作をこの流れで紙に書き出すと、「どこで判断し、どこにデータを置くか」の責任分担が自然に見えてきます。
- 不具合調査では、「どの工程で止まったか」を、開発者ツールのNetworkタブ（フロントエンド〜通信）とサーバーログ（バックエンド）で切り分けます。ステータスコードが最初の道しるべです。
- 全体の流れが頭に入っていると、AIにコードを書かせるときも「いま自分は、どの工程のどの部品を作らせているのか」を見失わずに済みます。基礎の地図は、AIを使いこなす側に回るための土台になります。
まとめ
- 1つの操作は、フロントエンド → 通信 → バックエンド → データ／機器 をたどって完結します。
- これまで学んだ技術は、この1本の線の中で、それぞれの持ち場を担当していました。
- 「見る」と「変える」では、必要な確認の重さが変わります。
- 全体の地図を持てば、個々の技術も、AIが書いたコードも、位置づけて理解できるようになります。
これで「AI時代に基礎技術を学ぶ」フロントエンド・バックエンド編は一区切りです。ここまでの地図を手に、実際に何かを作り始めてみてください。
この理解のあとに進めていけること
- 自分が使っている（または作ってみたい）WEBアプリで操作を1つ選び、「フロントエンド → 通信 → バックエンド → データ」の流れを、この記事の図をまねて書き出してみます。うまく書けない工程が見つかれば、そこが次に深掘りするポイントです。