0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@okakousuke1124

WEBアプリケーションとは何者か（クライアントとサーバーの立ち位置）

0
Last updated at Posted at 2026-06-21

WEBアプリケーションとは何者か（クライアントとサーバーの立ち位置）

前置き

※ この記事は、AI全盛期において、敢えて基本に立ち返った技術要素を知ることを目的にしています。

  • ソフトウェア初学者向けに全体像をつかむことを目的にした解説です。
  • 理解しやすさを優先するため、細かな例外や厳密な定義は一部省略しています。
  • 実際の運用や詳細については、公式ドキュメントや上位の資料で補完してください。

この記事でわかること（概要）

  • WEBアプリケーションを成り立たせる最小構成
  • クライアントとサーバーの役割分担
  • 最初に混同しやすいポイント

この記事の要点

  • WEBアプリケーションは、クライアントとサーバーの役割分担で動きます。
  • クライアントは入力と表示、サーバーは業務ルールとデータ処理を担当します。
  • どちらか一方だけでは完結せず、リクエストとレスポンスの往復で価値を提供します。

全体像

WEBアプリケーションは「1つの大きなプログラム」ではなく、複数の責務が連携する仕組みです。
まずは次の3点だけ押さえると、全体像をつかみやすくなります。

  • クライアントは、利用者との接点を担当します。
  • サーバーは、業務ロジックとデータ連携を担当します。
  • 通信では、HTTPを中心に要求と結果をやり取りします。

ここでのAPサーバーは、Spring Boot（Java/Kotlin）・ASP.NET Core（C#）・Laravel（PHP）・Django（Python）などの
ベンダーや OSS が提供する Webフレームワーク上で業務ロジックを実装する領域として扱います。
WEBサーバーは、Apache や Nginx などの出来あいのサーバーを想定しています。

この前提で見る担当範囲

この記事では、次の範囲を担当として見ていきます。

  • クライアント画面
  • APサーバー以降（APサーバー、DB、外部サービス連携）

この範囲を意識すると、どこで判断し、どこでデータを扱うかが整理しやすくなります。

ここだけ押さえる3ポイント

1. クライアントは「見せる・受け取る」側

ブラウザやアプリは、画面表示とユーザー操作の受付を担当します。
「どのボタンが押されたか」「どの値が入力されたか」をまとめて、サーバーに渡します。

2. サーバーは「判断する・整える」側

サーバーは、受け取った要求に対して業務ルールを適用します。
例として、入力値の妥当性確認、権限確認、必要データの取得、結果の整形があります。

3. 価値は往復で生まれる

クライアントが単体で賢くても、サーバーが単体で高性能でも、業務は完結しません。
「要求する」「判断する」「返す」「表示する」の往復が、WEBアプリケーションの本質です。

処理の流れの図

構成のイメージ図

勘違いしやすい解釈

  • クライアントを整えたら、サーバー側はあとで考えても大丈夫だと思いがちです。
  • サーバーの性能が高ければ、クライアント側の設計はあまり気にしなくてよいと思いがちです。
  • IDEで開発環境を整えたあと、「自分がいまどの領域のコードを書いているか」よくわからなくなりがちです。

どれも、最初に抱きやすいイメージです。
ただ、境界と役割分担が曖昧なままだと、変更しにくくなり、結果として属人化につながりやすくなります。

自分はいまどこを作っているのか

IDEで開発環境を整えてコードを書き始めたとき、自分がAPサーバーのアプリケーションを作っていることを意識していますか？

ブラウザ上の画面や、データベースの中身は、あくまで「つながっている先」です。
IDEで日々書いているコードの大半は、APサーバー上で動くアプリケーションです。

Spring Boot や ASP.NET Core、Laravel、Django などのWebフレームワークを使っている場合、それはまさにAPサーバーのアプリケーションを構築しています。
まずは「自分はAPサーバーの担当者である」という意識を持つと、設計の判断がぐっとしやすくなります。

実際の業務で押さえておきたいポイント

  • 画面仕様を見るときは、「表示だけか、業務判断まで含むか」を先に切り分けます。
  • APサーバーの処理は、入力チェック、権限確認、データ更新の順で確認します。
  • API仕様を見るときは、「何を要求して何が返るか」を1往復で説明できるようにします。

まとめ

  • WEBアプリケーションは、クライアントとサーバーが協調して動きます。
  • クライアントは体験を担い、サーバーは判断と整合性を担います。
  • フレームワークが変わっても、役割分担の原理は大きくは変わりません。

この理解のあとに進めていけること

  • 担当中の1画面を選び、処理を「クライアント側」「サーバー側」の2列に分けて書き出してみます。

関連リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?