Webアプリの開発全体像を理解する

Section 1

Webアプリケーション開発の全体像と設計プロセスの理解

はじめに

この章の目的は、Webアプリ開発をいきなり個別技術の集まりとして見るのではなく、全体構造として理解することです。

HTML、CSS、JavaScript、API、サーバー、データベース、認証、運用。これらは別々の話に見えますが、実際には1つの流れの中で役割分担されています。

最初に全体像を持たないまま学び始めると、用語は増えても「何がどこにつながっているのか」が見えにくくなります。

Webの基礎として、HTTPはWeb上のデータ交換の土台であり、ブラウザーなどのクライアントがリクエストを送り、サーバーがレスポンスを返すクライアント・サーバープロトコルです。

また、1つのWeb文書はHTMLだけでなく、CSS、画像、動画、スクリプトなど複数のリソースから構成されます。つまり、Webアプリは最初から「複数要素の協調」で成り立つものです。

この章では、Webアプリとは何か、何で構成されるのか、どのように通信し、どのような工程で作られ、誰が何を担うのかを、課題と解決の対応関係を意識しながら整理します。

細かなフレームワークや実装技法に入る前に、まずは地図を描きます。その地図があることで、次章以降の学習が断片ではなく、体系としてつながります。

この章で学ぶこと

項目この章で理解する内容
Webアプリの定義WebサイトとWebアプリの違い、代表例、事業上の意味
基本構成フロントエンド、バックエンド、データベースの役割
通信の基礎ブラウザーとサーバーの関係、HTTP、リクエストとレスポンス
データの流れ入力から保存、取得、画面更新までの流れ
開発工程要件定義、設計、実装、公開、運用の全体像
役割分担フロントエンド、バックエンド、インフラ、PM などの担当範囲
アーキテクチャの入口CSR、SSR、SSG など描画方式の違いの概観
到達目標この章を終えた時点で説明できること、区別できること

1. Webアプリとは何か

Webアプリとは、ブラウザーを通じて利用され、ユーザーの操作に応じて処理やデータ更新を行うアプリケーションです。

単に情報を読むだけのページではなく、入力、送信、保存、検索、認証、更新などの動きを含みます。

MDNは、WebがHTML、CSS、JavaScript、そして多様なWeb APIを通じて、単なる文書表示を超えたアプリケーション体験を支える基盤であることを示しています。

ここで重要なのは、「Webアプリは特別なもの」ではなく、現代の多くのサービスの標準形だということです。

  • 予約
  • 購入
  • 投稿
  • 管理
  • 集計
  • 共有

こうした業務やサービスの多くは、Webアプリという形で提供されています。

1-1. WebサイトとWebアプリの違い

WebサイトとWebアプリは、見た目だけでは区別しづらいことがあります。ですが、役割の中心を見ると違いが見えます。

観点WebサイトWebアプリ
主目的情報の閲覧操作と結果の処理
代表例コーポレートサイト、ブログ、案内ページEC、予約、SNS、管理画面、SaaS
データ更新限定的頻繁で双方向的
ユーザー操作読む・移動する入力する・保存する・更新する

もちろん、現実のサービスでは両者が混ざります。たとえば企業サイトの中に問い合わせフォームがある場合、その部分はアプリ的です。

大切なのは、読むための構造なのか、操作と処理の構造なのかを見分けることです。

1-2. Webアプリの代表例

Webアプリの代表例は次のように整理できます。

種類例主な操作
EC商品一覧、カート、決済検索、購入、在庫確認
予約システム病院、美容院、ホテル空き確認、予約、変更、キャンセル
SNS投稿、コメント、通知作成、表示、更新、共有
管理画面売上管理、会員管理、在庫管理一覧、集計、編集、削除
SaaS業務支援、CRM、プロジェクト管理認証、保存、検索、分析

これらに共通するのは、ユーザー操作に応じてデータをやり取りし、結果を画面へ返すことです。単なるページ表示ではなく、状態の変化を伴います。

1-3. なぜWebアプリは現代の事業で重要なのか

Webアプリが重要なのは、利用者にとっても提供者にとっても扱いやすいからです。

利用者は専用インストールなしでブラウザーからアクセスしやすく、提供者は継続改善や更新を進めやすい構造を持てます。

また、端末をまたいで使いやすいことも大きな利点です。Webはブラウザーを中心に多くの端末から利用できる基盤であり、その上でアプリケーション体験を提供できます。

1-4. この節の課題と解決

課題何が起きるかWebアプリの解決
端末ごとに専用導入が必要だと利用障壁が高いユーザーが増えにくいブラウザー経由で利用しやすくする
情報表示だけでは業務やサービスが完結しない操作・入力・保存が必要になる動的な処理を持つアプリとして設計する
改善を繰り返しにくい事業成長が遅くなる継続更新できるサービス基盤にする

2. Webアプリは何で構成されているのか

Webアプリの全体像を理解するうえで、最も基本になるのが、フロントエンド・バックエンド・データベースという三つの役割分担です。

これは厳密な唯一の分け方ではありませんが、初学者が構造を理解するには非常に有効です。画面、処理、保存を分けて考えることで、何がどこで起きているかを整理しやすくなります。

2-1. フロントエンドとは何か

フロントエンドは、ユーザーが直接触れる側です。

ブラウザー上に表示される画面、入力欄、ボタン、一覧、画像、メッセージなどがここに含まれます。

HTML は文書構造、CSS は見た目、JavaScript は動きや通信に関わります。ブラウザーはまずHTMLを取得し、その後にCSSやスクリプト、画像などを追加で取得して画面を組み立てます。

2-2. バックエンドとは何か

バックエンドは、サーバー側の処理です。

ユーザーから届いたリクエストを受け取り、必要な業務ロジックを実行し、データベースにアクセスし、結果をレスポンスとして返します。

たとえばログイン判定、予約可否確認、注文処理、権限確認などはバックエンドの典型です。HTTP のクライアント・サーバー構造では、サーバーがリクエストを受けて応答を返します。

2-3. データベースとは何か

データベースは、データを保存し、取り出し、更新する場所です。

会員情報、商品情報、予約情報、投稿内容、在庫、売上など、継続的に保持したい情報を管理します。

画面に表示される内容の多くは、最終的にはデータベースに格納された情報に支えられています。

2-4. なぜ3つに分けて考える必要があるのか

画面、処理、保存が1か所に混ざると、修正や拡張が難しくなります。

たとえば、見た目の変更と認証の変更と保存仕様の変更が同じ場所で絡むと、問題の原因を追いづらくなります。

そのため、まずは三つに分けて考えることで、責務と変更点を整理しやすくします。

2-5. この節の課題と解決

課題何が起きるか解決
画面、処理、保存が1か所に混ざる修正や拡張が難しくなるフロントエンド・バックエンド・DBに分ける
データの責任範囲が曖昧バグや不整合が起きやすい保存責務をDBに明確化する
問題の原因が見えないデバッグが難しくなる各層の責務を分離する

3. ブラウザーとサーバーはどうやってつながるのか

Webアプリは、ブラウザー単体で完結しているわけではありません。

ブラウザーが要求し、サーバーが応答し、その結果として画面が構成されます。この関係を理解すると、API、ログイン、画面更新、エラーの意味が一気につながります。

HTTP は Web におけるデータ交換の基礎であり、クライアント・サーバープロトコルです。通常、ブラウザーがリクエストを開始し、サーバーがレスポンスを返します。

また、ブラウザーはHTMLを取得した後、CSS、スクリプト、画像、動画など追加のリソースも取得して最終的な画面を構築します。

3-1. クライアントとサーバーの基本関係

クライアントは、多くの場合ブラウザーです。サーバーは、要求を受け取り、必要なデータや文書を返す側です。

この関係を最も単純化すると、「要求する側」と「応答する側」です。

3-2. HTTPとは何か

HTTP は、リクエストとレスポンスで成り立つ通信の仕組みです。

HTTP overview では、HTTP は Web 上のリソース取得のためのプロトコルであり、クライアント・サーバー型であると説明されています。

また、HTTP は stateless であり、リクエスト同士の文脈を標準では持たないため、必要に応じて Cookie などで状態を扱います。

3-3. Webページはどのように組み立てられるのか

ブラウザーは最初に HTML 文書を取得します。

その後、その文書を解析し、必要な CSS、JavaScript、画像、動画などを追加で取得します。

さらに、スクリプトの実行によって後からデータを取得し、画面を更新することもあります。

つまり、1画面は「1回の取得」で完結するとは限らず、複数のリソースと通信の積み重ねで成り立っています。

3-4. なぜ通信の理解が必要なのか

通信を理解していないと、画面が遅い理由、APIが失敗する理由、ログイン状態が維持される理由などが見えません。

Webアプリは画面技術であると同時に、通信技術でもあります。

そのため、HTTP の基本は全体像理解の中心です。

3-5. この節の課題と解決

課題何が起きるか解決
画面がなぜ表示されるのかわからない表面的理解で止まるリクエストとレスポンスで整理する
API通信の意味が見えないフロントとバックの関係を誤解するHTTPを基礎に置く
1画面が複数資源から成ることを知らない表示不具合の原因を追えない文書とリソースの組み立てで理解する

4. Webアプリではデータがどう流れるのか

Webアプリでは、見た目の変化の裏側で、常にデータが動いています。

ユーザーが入力し、その情報がサーバーへ送られ、処理され、保存され、結果が返ってきて画面が更新される。この流れを言語化できるようになると、設計と実装のつながりが見えやすくなります。

4-1. ユーザー操作から画面更新までの流れ

もっとも基本的な流れは次のように表せます。

  1. ユーザーが入力する
  2. ブラウザーがリクエストを送る
  3. サーバーが処理する
  4. 必要ならデータベースへアクセスする
  5. サーバーがレスポンスを返す
  6. ブラウザーが画面を更新する

この一連の流れを理解すると、見た目の問題と通信の問題と保存の問題を切り分けやすくなります。

4-2. CRUDとは何か

Webアプリで扱うデータ操作は、多くの場合 CRUD で整理できます。

操作意味例
Create作成新規会員登録、投稿作成
Read読み取り一覧表示、詳細表示
Update更新プロフィール編集、予約変更
Delete削除投稿削除、退会処理

HTTP の代表的なリクエストメソッドとして、GET、POST、PUT、PATCH、DELETE などがあり、これらはしばしば CRUD の発想と対応づけて説明されます。

MDN の HTTP request methods も、それぞれの用途を整理しています。

4-3. なぜデータフロー理解が重要なのか

仕様をそのままコードへ落とすのは難しいです。

しかし、

  1. 入力
  2. 処理
  3. 保存
  4. 返却

という流れに分解すると、必要な画面、API、DB操作が見えてきます。つまり、データフローは設計と言語化の橋渡しと理解することができます。

4-4. この節の課題と解決

課題何が起きるか解決
「押したら動く」を感覚で理解するだけになる設計できない入力→処理→保存→返却で流れを分解する
データ更新の責任が曖昧不整合が起こるCRUDの観点で整理する
仕様をそのまま実装に落とせない開発が詰まりやすいデータフローを言語化する

5. 開発はどのような工程で進むのか

Webアプリ開発は、いきなりコードを書くことから始まるわけではありません。

誰の何を解決するかを決め、必要機能を整理し、画面やAPIやデータ構造を設計し、そのあとで実装し、公開し、改善を続けます。

この流れを知らずに学ぶと、「コードを書けるかどうか」だけで開発を見てしまい、全体像を取り違えやすくなります。

5-1. 要件定義

要件定義では、誰の何を解決するのか、どんな機能が必要なのかを整理します。

たとえば「予約できるようにしたい」という要望があっても、診療科ごとか、担当者ごとか、キャンセルは可能か、認証は必要か、通知はどうするかなど、分解が必要です。

5-2. 設計

設計では、要件を実装可能な形へ変換します。ここで考える主な対象は、次のようなものです。

設計対象内容
画面設計どの画面で何を表示・入力させるか
API設計どんな通信口を作るか
DB設計何をどう保存するか
権限設計誰が何を見て・操作できるか

5-3. 実装

設計した内容を、フロントエンド、バックエンド、DB、インフラなどに落としていく工程です。

ここで初めてコードが中心になります。ただし、実装は全体工程の一部であって、全体そのものではありません。

5-4. 公開と運用

Webアプリは、作って終わりではありません。

公開後も、監視、改善、保守、セキュリティ対応、性能改善などが続きます。むしろ事業として重要なのは、公開後の継続運用であることが少なくありません。

5-5. なぜ工程理解が必要なのか

工程を理解していないと、要件が曖昧なまま実装に入り、手戻りが増えます。

また、チーム開発では誰がどこを担うのかも見えにくくなります。Webアプリ開発は、コードだけでなく、課題設定から運用までを含む流れです。

5-6. この節の課題と解決

課題何が起きるか解決
すぐ実装から入る要件ぶれや手戻りが増える要件→設計→実装→運用で考える
役割が曖昧チーム連携が崩れる工程ごとの責務を整理する
リリース後を軽視する保守できない運用まで含めて開発と捉える

6. 誰が何を担当するのか

Webアプリ開発では、1人が全部やる場合もありますが、役割そのものは複数に分かれます。

役割分担を知らないまま学ぶと、「自分は何を学べばよいか」「他の人は何を見ているか」が分かりにくくなります。そのため、職種や責務の違いを大まかに理解しておくことが重要です。

6-1. フロントエンドエンジニアの役割

ユーザーが触れる画面を作るのが中心です。

表示、入力、バリデーション、UI体験、ブラウザー上の状態管理などを扱います。

6-2. バックエンドエンジニアの役割

サーバー側の処理、API、認証、業務ロジック、データの整合性などを主に担います。

フロントエンドから見れば「裏側」ですが、サービスの根幹に関わります。

6-3. インフラ / SRE / データベース担当の役割

サーバー運用、配備、監視、性能、障害対応、DB運用などを担います。システムを「動き続ける状態」に保つ役割です。

6-4. デザイナー・PM・QAの役割

役割主な責務
デザイナー情報設計、UI設計、見た目、体験設計
PM要件整理、優先順位、進行管理、意思決定支援
QA品質確認、テスト観点、問題検出

6-5. 小規模開発ではどう重なるのか

小規模開発や個人開発では、1人が複数役割を兼ねます。ただし、兼ねる場合でも「役割が消える」わけではありません。

頭の中では、画面、処理、保存、運用、品質確認を分けて考える必要があります。

6-6. この節の課題と解決

課題何が起きるか解決
役割分担を知らない学ぶ範囲が曖昧になる職種ごとの責務を把握する
1人開発で全部混ざる優先順位を失う役割を概念的に分けて考える
チーム開発像が見えない全体像を誤解する関係者の役割を並べる

7. どんなアーキテクチャの違いがあるのか

Webアプリは1種類ではありません。

見た目は同じように見えても、どこでHTMLを作るか、どこで画面を描くか、いつページを生成するかによって構成が変わります。

この章では詳細に踏み込みすぎず、「違いがある」ということを掴むことを目的にします。

web.dev は、CSR、SSR、prerendering を比較し、それぞれがどこでレンダリングされるか、どのような特徴を持つかを整理しています。

7-1. 静的サイトと動的Webアプリ

静的サイトは、あらかじめ用意された内容をそのまま配信する傾向が強いです。

一方、動的Webアプリは、ユーザーやデータ状態に応じて表示や処理が変わります。

ただし、実務では両者の中間も多く、完全に二分されるわけではありません。

7-2. CSR / SSR / SSG の入口

方式概要
CSRブラウザー側で主に描画する
SSRサーバー側でHTMLを生成して返す
SSG事前にHTMLを生成して配信する

web.dev は、CSR をクライアント側JavaScript中心、SSR をサーバーがHTMLを返す方式、prerendering を事前生成として説明しています。

7-3. なぜ描画方式の違いが重要なのか

描画方式の違いは、表示速度、SEO、体験、運用方式に影響します。

この章では深掘りしませんが、「どのWebアプリも同じ仕組みで動くわけではない」ことを知るだけでも大きな一歩です。

7-4. この章ではどこまで理解すればよいか

この段階では、違いの存在を区別できれば十分です。CSR、SSR、SSG の厳密な実装差は、後続章で深めればよいです。

最初から細部へ入りすぎると、全体像を見失いやすくなります。

7-5. この節の課題と解決

課題何が起きるか解決
Webアプリを1種類だと思い込む技術選定を誤る構成方式の違いを知る
レンダリング方式を知らないSEO・表示速度・体験の違いが見えないCSR / SSR / SSG を概観する
早い段階で細部に入りすぎる全体像を見失うこの章では違いの存在だけ押さえる

8. この章の到達目標

この章の到達目標は、「用語を見たことがある」ではなく、自分の言葉で構造を説明できることです。

理解しているかどうかは、説明できるかどうかでかなり見えてきます。

8-1. 説明できるようになること

この章を終えた時点で、次の内容を説明できる状態を目指します。

説明対象到達イメージ
Webアプリとは何か操作・処理・保存を伴うブラウザー利用型アプリと説明できる
フロントエンド・バックエンド・DB の違い画面、処理、保存の役割として整理できる
クライアントとサーバーの関係リクエストとレスポンスの流れで説明できる
開発工程の全体像要件定義から運用まで並べて説明できる

8-2. 区別できるようになること

この章では、次の区別ができるようになることも重要です。

区別したいもの区別の観点
WebサイトとWebアプリ閲覧中心か、操作と処理中心か
表示と処理と保存フロントエンド、バックエンド、DB の責務
実装と運用作ることと動かし続けることの違い
役割と責務誰が何を担うか

8-3. 次章以降への接続

この章は、次の章の入口として機能します。

この全体像があることで、次章以降の内容が「どこに位置する知識なのか」が見えやすくなります。

次章つながり
1-2 基本構造フロントエンド・バックエンド・DB をより詳しく学ぶ
1-3 クライアント・サーバーモデル通信モデルを深める
1-4 開発プロセス工程を詳しく見る
1-5 役割分担チームや責務を整理する
1-6 アーキテクチャ概念CSR / SSR / SSG へつなぐ

8-4. この節の課題と解決

課題何が起きるか解決
学びのゴールが曖昧何を理解すべきかわからない到達目標を明示する
次章との関係が見えない知識が断片化する次に学ぶ内容へ接続する
「知っている」と「説明できる」が混ざる理解が浅くなる説明可能性を基準にする

9. 考えてみよう

この章では、知識を受け取るだけでなく、なぜそのように分けて考えるのか を自分の言葉で捉えることが重要です。

考えることによって、単なる暗記ではなく、構造理解へ近づきます。

9-1. なぜWebアプリの全体像を最初に学ぶ必要があるのか

個別技術から入ると、知識が増える一方で位置づけが見えにくくなります。

全体像を先に持つことで、今学んでいる内容が画面の話なのか、通信の話なのか、保存の話なのかを整理しやすくなります。

9-2. なぜ画面・処理・保存を分けて考えるべきなのか

すべてを一塊で考えると、どこを直せばよいか分からなくなります。分けることで、責務と変更点を整理しやすくなります。

9-3. なぜ通信の理解がAPI理解につながるのか

API は通信の上に成り立っています。

HTTP のリクエストとレスポンスの考え方を知らずに API を学ぶと、ただの「呼び出し方の暗記」になりがちです。

9-4. なぜ要件定義から運用までを一連で捉える必要があるのか

実装だけを見ていると、なぜその機能が必要なのか、誰が使うのか、公開後にどう改善するのかが抜け落ちます。

開発は、書くことだけではなく、問題解決の流れ全体です。

9-5. なぜ技術の前に役割と責務を知ることが重要なのか

役割と責務を知らないと、自分が今どの層を学んでいるのか見失いやすくなります。

1人開発でも、頭の中では責務分離が必要です。

10. まとめ

  • Webアプリは、ブラウザーとサーバーが HTTP を通じてやり取りし、複数のリソースから画面を構成する仕組みの上に成り立っている。
  • Webアプリの基本構成は、フロントエンド、バックエンド、データベースの3層で捉えると整理しやすい。
  • 画面表示、通信、データ保存、役割分担、開発工程は、それぞれ別の責務として理解すると全体像がつかみやすい。
  • レンダリング方式には CSR、SSR、事前生成などの違いがあり、今後の章でその意味を深めていく。
  • この章の役割は、詳細技術に入る前に「何がどうつながっているのか」を俯瞰できるようにすることにある。

参考文献

次の節Webアプリケーションの基本構造（フロントエンド・バックエンド・データベース）
教材トップへ戻る