# Webアプリケーションとは

利用者側の導入と更新の作業は少ない一方、サーバーの運用、ブラウザへの対応、権限確認が継続して必要になる、ブラウザで使う業務ソフトウェアです。

## Webアプリケーションとは

Webアプリケーションは、ブラウザ上で使い、業務の中心となる処理とデータの保存はサーバー側が担うソフトウェアです。Webアプリとも呼びます。サーバーは、利用者の端末とは別の場所で常時稼働するコンピューターで、プログラムとデータベース（データを整理して保存する仕組み）を配置します。目的は、端末ごとにソフトを導入しなくても、複数の人が同じ業務を同じ手順で使えるようにすることです。[ブラウザの要求に応じて、サーバーがデータベースの内容を反映した画面を生成する](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction)ため、利用者ごとに異なる画面を表示できます。前提は、ブラウザからサーバーへ通信できることです。通信先はインターネットのほか、社内LAN、VPN、閉域網などのプライベートネットワークでもよく、社内の利用者だけに限定して動かすこともあります。

銀行の窓口に近い仕組みです。客は用紙を出すだけで、台帳の管理は店の奥で行われます。具体像は二つに分かれます。オフィスで申請を承認する画面は、通信が安定しているためWebアプリケーションで十分です。電波の届かない倉庫で検品結果を入力する業務は、サーバーに通信できないと使えない作りが基本です。社内網があっても無線が届かない場所なら同じで、オフライン入力が必要ならPWAのオフライン対応かネイティブアプリを採用します。

会社紹介のように固定の内容を表示するWebサイトとは、入力に応じて処理し、結果を保存する点が異なります。端末へインストールして使うネイティブアプリとは、プログラムの置き場所が異なります。ブラウザから使うSaaSの多くは、Webアプリケーションとして作られています。

![ブラウザがサーバーへ要求を送り、サーバーのプログラムがデータベースを読み書き（双方向）して、結果をブラウザへ返す流れ。](https://media.marketing.kdotdev-tunnel.org/glossary-web-application-eab9987834ab4d1ebc702f3088c15a7aca93abee73ec0d0dc09d8ee9e67de210.png)

## なぜ必要か

端末ごとにソフトウェアを導入する方式では、利用者が増えるたびに導入作業が発生し、修正版が出るたびに全端末を更新します。更新が遅れた端末が残ると、同じ業務でも画面や計算結果が端末ごとに異なります。OSごとに別の版も必要です。

![端末アプリは端末ごとの導入と更新が必要で、Webアプリはブラウザで開き、更新がサーバー1か所で済むことの対比。](https://media.marketing.kdotdev-tunnel.org/glossary-web-application-1e8fa451e210528ec7f5e101ba634cc40c1aa60b4fd31f5f622ad3dd0985eabc.png)

## 効果とコストとリスク

効果は次のとおりです。

- [URLの共有だけで利用を開始でき、アプリストアへの登録も不要](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app)
- 修正を、利用者側の更新作業なしでほぼ同時に反映できる
- 複数のOSと端末に、1つの開発成果物で対応しやすい

導入後に続くコストとリスクは次のとおりです。

- サーバーとデータベースの運用。稼働の監視、バックアップ、障害対応、OSやライブラリの更新が継続して発生する。冗長構成を取らない小規模な業務システムを想定すると、サーバー費用は月数万円から数十万円が目安
- ブラウザの種類と版による表示や動作の差の確認。ブラウザは更新され続けるため、一度確認して終わりにならない
- 通信環境への依存。[Webサイトは通信への依存が強い](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app)ため、サーバーに通信できない場所では使えない作りが基本で、オフライン対応は追加の実装になる。インターネットか社内網かは問わず、利用する場所でサーバーへ常時通信できるかが問題になる
- 認証と権限の設計。誰に何を表示し、何の変更を許可するかをサーバー側で判定する必要がある
- 脆弱性への対応。インターネットに公開して稼働すると外部から到達できるため、脆弱性を突かれるおそれがあり、継続した確認が必要になる。社内網に限定すれば到達できる範囲は狭くなるが、確認が不要になるわけではない。ウェブサイトの[脆弱性は11種類に整理され、種類ごとの対策が示されています](https://www.ipa.go.jp/security/vuln/websecurity/about.html)

運用の担い手は、サーバー、画面、セキュリティを継続して確認できる人です。専任がいない場合も、稼働の監視と更新対応が中心の小規模な業務システムを想定すると、1〜2名分の工数を保守に充てる想定が目安で、発注と運用の責任を持つ部門の責任者が、開発前に工数の確保を決定します。

![Webアプリケーションで導入後も続く3つの作業。サーバーの稼働を保つ、ブラウザやライブラリの更新に合わせる、権限確認と脆弱性対応を行う。](https://media.marketing.kdotdev-tunnel.org/glossary-web-application-6353cb111bc9be95bc3b254f34d60fda3a541cdafbb1381100b2ffc3f6c11fc8.png)

## Webアプリかネイティブアプリかの判断

サーバーへ常時通信できない場所で入力する業務や、端末の機能を日常的に深く使う業務は、ネイティブアプリの対象です。[ネイティブアプリの利点は、オフラインやバックグラウンドの動作、OSとの連携、カメラやGPSなど端末機能の利用](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app)にあります。例えば、倉庫や工場、屋外の現場で通信が届かない中で入力する業務は、ここに当てはまります。通知の即時性が要件の業務は、Web Pushなどで足りる場合もあるため、通知とは別に、必要な端末機能の有無で判断します。

利用する場所でサーバーへ常時通信できる業務は、通信の途切れを気にしなくてよい業務です。判断の軸はインターネットか社内網かではなく、この常時通信の可否です。例えば、オフィスで使う申請、承認、一覧、集計がこれに当たります。[PWA（Progressive Web App）はWebの技術で作りつつ、端末へのインストールや端末機能の一部利用を可能にする方式](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app)です。Webアプリケーションで開始し、必要になった時点で追加する選択肢になります。

利用者が社外にいる場合は、端末とブラウザを指定できません。対応するブラウザは、利用環境を指定できない前提では主要ブラウザの直近2版程度に限定し、その範囲で動作を確認するのが目安です。社内だけの利用なら、端末を指定でき、確認の範囲を狭められます。

サーバー構成の規模は、利用者数が数十人から数千人規模でも、同時利用が集中しなければ処理負荷が一時的に跳ね上がらないため、社内の小規模構成と同じサーバー構成で開始できます。ただし利用者数だけで構成は決まらず、処理量とデータ量の確認が要ります。

![通信が途切れる入力や端末機能が業務の中心かどうかで分かれる判断。はいならネイティブアプリかPWAを採用し、いいえならWebアプリケーションで始める。](https://media.marketing.kdotdev-tunnel.org/glossary-web-application-a5412d8351f27dcbc88bd94e29ff1a508bf6caabb950d2e30c6053a4b4eb4bd4.png)

利用する場所で常時通信でき、端末機能を日常的に深く使わない業務システムは、まずWebアプリケーションで開始すれば十分な場合が多く、同時利用の規模や保守体制が条件を満たすかを確認します。作る前に決めるのは、画面の見た目より、サーバー側で誰に何を許可するかと、導入後に保守を担う人です。

## よくある誤解

### 画面に表示しない機能は、利用者に使われない

実際は、画面に出していない機能でも、サーバーが権限を確認していなければ、操作の要求をブラウザから直接送られると実行されてしまいます。例は、[URLの書き換えによる、本来見られない情報の表示](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/)です。[権限の確認は、利用者が書き換えられない信頼できるサーバー側で実装して初めて有効](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/)です。[何らかの権限制御の不備は、OWASP Top 10の2025年版が調査したアプリのすべてで見つかりました](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/)。

![画面に出さない操作でも、サーバーで権限を確認しなければ、直接送られた要求で実行される。権限の確認はサーバーで行う。色付きのセルが危険な組み合わせ。](https://media.marketing.kdotdev-tunnel.org/glossary-web-application-5d7281918181a4a96cb5d33d25df3bed55a7a0057cbb31c9d59a73e93e45b797.png)

### 診断で指摘がなければ脆弱性はない

実際は、ウェブ健康診断で[脆弱性が検出されなくても、安全宣言にはなりません](https://www.ipa.go.jp/security/vuln/websecurity/about.html)。診断は実施した時点の確認です。機能の追加やライブラリの更新で状況は変化するため、診断の結果は、権限の設計と更新の運用と合わせて扱います。

### Webサイトの延長でWebアプリケーションも低価格で開発できる

実際は、入力に応じた処理、データの保存、権限の設計、サーバーの運用が加わるため、固定内容のWebサイトとは費用の構成が異なります。画面の見た目が似ていても、導入後の運用と保守が継続して発生します。