30秒で要点
サーバーとは、ほかのコンピューターからの依頼を受けて、ページやデータなどを返す側の役割です。その役割を担うソフトウェアや、動かしている機械を指して「サーバー」と呼ぶこともあります。
- Webサイト、メール、データの検索、ファイル共有などで使われる。
- 専用の機械を自社で買う方法だけでなく、借りる方法や管理込みのサービスを利用する方法もある。
- 24時間の提供、安全な保存、費用の安さは、サーバーを使うだけで保証されない。構成と契約、運用の担当を確認する。
Webサイトや業務システムの見積もりに「サーバー費」が出てきたものの、何を契約するのか分からない方に向けた記事です。プログラミングの前提知識は不要です。役割、種類、用語、選び方を一つずつ整理します。
1. サーバーは「依頼を受けて提供する側」
レストランで考えると、客が料理を注文し、店側が用意して渡す関係に似ています。Webでは、ブラウザーなどが「このページを見せてください」と依頼し、サーバー側が必要な内容や処理結果を返します。
依頼する側をクライアント、提供する側をサーバーと呼びます。ここでのクライアントは顧客企業という意味ではなく、依頼を送るソフトウェアや端末のことです。
この比喩には限界もあります。依頼は必ず成功するわけではなく、存在しないページ、権限がない操作、処理の混雑などでは、エラーや待ち時間が生じます。サーバーが返した内容を、端末側でさらに組み立てて表示する場合もあります。
「機械」と「ソフトウェア」を分ける
MDNの入門資料は、Webサーバーという言葉をハードウェアとソフトウェアの両面から説明しています。Webのファイルを置く機械と、リクエストを受けて応答するソフトウェアを区別すると、見積書や説明を読みやすくなります。MDN:Webサーバーとは
表が収まらない場合は、横にスクロールできます
| 「サーバー」と呼ぶ対象 | 何を指しているか | 相談時の確認例 |
|---|---|---|
| 機械・計算資源 | ソフトウェアを動かす場所 | 自社の機械か、借りた仮想マシンか |
| ソフトウェア | 依頼を受けて処理・応答するプログラム | Web、メール、データベースのどの役割か |
| 提供サービス | 機能と運用をまとめた契約 | 更新や監視、バックアップはどこまで含むか |
普段のパソコンでも、サーバーのソフトウェアを動かせば提供する側になれます。「パソコンは1人、サーバーは必ず大勢」という機械そのものの絶対的な区別ではありません。ただし、業務で継続して公開するなら、電源、通信、更新、監視、故障時の対応を考える必要があります。
一台の機械が複数の役割を担う場合も、複数台で一つのサービスを支える場合もあります。見えるWebサイトの数と、物理的な機械の台数は一致しません。
2. Webページが届くまでを、四つに分ける
たとえば会社のサービス紹介ページを開くとき、次のようなやり取りが起こります。これは理解のために簡略化した流れで、通信の細部をすべて表したものではありません。
- ブラウザーが、指定したURLのページを要求する。
- Webサーバーのソフトウェアが、その要求を受け取る。
- 用意されたファイルを返すか、必要に応じてアプリがデータを読み、応答を作る。
- ブラウザーが応答を受け取り、ページを表示する。
内容をあらかじめファイルとして用意して配る方法を、静的な配信と呼びます。ログインした人に合わせた情報や、最新の在庫などを処理して返す方法では、アプリケーションやデータベースが関わることがあります。どちらを使うかは、公開・更新したい内容と必要な機能で決めます。
存在しないページを要求すれば、見つからないことを示す応答になる場合があります。画面が出ないときも、原因が必ず「サーバーの機械が故障した」わけではありません。URL、通信、設定、アプリ、権限など、どこで止まったかを分けて調べます。
3. 身近な四つの役割
「サーバーを用意する」と言われたら、まず何の依頼を受けるのかを尋ねてください。代表的な役割は次のとおりです。
表が収まらない場合は、横にスクロールできます
| 役割 | 受け持つこと | 身近な用途 | 自社が確認すること |
|---|---|---|---|
| Webサーバー | Webページなどを要求に応じて返す | 会社サイト、サービス紹介 | 公開範囲、更新方法、表示できないときの連絡先 |
| メールサーバー | メールの送受信などを支える | 会社の問い合わせメール | 利用者、容量、迷惑メール対策、引継ぎ |
| データベースサーバー | データを保存し、条件に応じて読み書きする | 注文、在庫、顧客情報 | 読み書きできる人、整合性、復元方法 |
| ファイルサーバー | ファイルの保存や共有を支える | 社内文書、共同作業 | 閲覧・編集権限、履歴、誤削除時の扱い |
ECサイトでは、Webで商品を表示し、アプリが注文を処理し、データベースに記録する、といった組み合わせになります。「Webサーバーを契約したから、注文管理や顧客管理も完成している」とは限りません。
メールやファイル共有を、完成したサービスとして利用する選択肢もあります。その場合、利用者がサーバーソフトウェアを直接管理しないことがありますが、利用者の追加・削除や共有範囲の判断まで不要になるわけではありません。
同時に使えることにも、条件がある
複数の人からの依頼を扱えるのはサーバーの重要な役割です。ただし、処理量には限界があります。同じアクセス数でも、紹介文を返すだけか、大きなファイルを処理するか、複雑な検索をするかで必要な資源は変わります。
「何人まで使えるか」を機械の名称だけで決めず、対象の処理、同時に利用する状況、許容する待ち時間を担当者へ伝えます。見積もり段階の想定と、実際に負荷をかけて確認した結果も区別します。
4. 自社で持つ・借りる・管理を任せる
設置や契約の方法は、企業の規模だけで選べません。持っている技術、止められる時間、保存するデータ、必要な変更の自由度で、適する構成が変わります。
表が収まらない場合は、横にスクロールできます
| 選択肢 | 主な考え方 | 自社で確認する責任 |
|---|---|---|
| オンプレミス | 自社側で機械や設置環境を用意する | 電源、通信、機器、更新、監視、故障と復旧を誰が担うか |
| レンタル・ホスティング | 事業者の資源やWeb公開機能を契約する | 契約に含まれる範囲と、サイトやデータの管理範囲 |
| クラウドの仮想マシン等 | 必要な資源をサービスとして利用する | 選んだサービスで残るOS・アプリ・設定の管理 |
| 管理されたアプリや基盤 | 完成した機能や、アプリを置く仕組みを利用する | データ、利用者権限、公開設定、復旧・取り出し条件 |
これらは完全に排他的な分類ではありません。ホスティング事業者の内部でクラウドが使われていることもあります。「クラウドかレンタルか」という言葉だけで比較せず、実際に何を借り、どの作業を任せる契約なのかを揃えます。
AWSの共有責任モデルでは、EC2のようなサービスで利用者がOSやアプリ、設定を管理する例と、事業者がより多くの基盤を管理するサービスの例を分けています。AzureやGoogle Cloudも、選ぶサービスで責任が変わることを説明しています。AWS、Azure、Google Cloud
「事業者が管理するから自社の作業はない」「自社設置だから必ず安全」とは言えません。誰が何を管理するかを、契約と実際の構成に合わせて確認することが先です。
5. 24時間の提供と、データを戻せることは別
継続して使えることと、データを失った後に戻せることは、別の問題です。機械を複数にして障害へ備えても、誤ったデータの削除まで複数箇所へ反映されれば、それだけで元に戻せるとは限りません。
表が収まらない場合は、横にスクロールできます
| 確認したいこと | 担当者に聞く具体的な問い |
|---|---|
| 止まりにくさ | 何が故障した場合に、どの機能が止まるか |
| 停止の把握 | 誰が異常を知り、利用者へ伝えるか |
| バックアップ | 何を、いつ、どこへ、どれだけの期間保存するか |
| 復旧 | 保存したデータを使って、必要な機能まで戻せるか |
| 復旧の確認 | 最新の確認では、どのデータまで、何時間で戻せたか |
AWSの復旧確認の指針は、バックアップが存在すると思い込むことや、復元しただけでデータを読めるか確認しないことを避けるよう説明しています。必要なデータが使えるか、許容するデータ損失と復旧時間に収まるかを試して確認します。バックアップからの定期的な復旧確認
たとえば、事業側の希望を「失ってもよい記録は最大1時間分、業務を戻すまで4時間以内」と仮に置くと、何を相談すべきかが具体的になります。この1時間・4時間は推奨値でも、この記事で検証した能力でもありません。記録を作り直せるか、停止中に代わりの方法があるかによって、必要な条件を決めます。
稼働割合の数字にも、分母がある
以下は計算の説明だけの架空例です。30日間を分単位で観測し、そのうち停止が30分だったとします。
表が収まらない場合は、横にスクロールできます
| 項目 | 架空の値 |
|---|---|
| 観測期間:30 × 24 × 60 | 43,200分 |
| 観測した停止 | 30分 |
| 稼働していた時間 | 43,170分 |
| 稼働割合:43,170 ÷ 43,200 × 100 | 約99.9306% |
この割合は、将来も同じだけ動く保証ではありません。監視した機能、計画停止を含むか、観測方法によっても意味が変わります。契約上のSLAがあれば、対象機能、除外条件、測定方法、補償条件を別途読みます。機械が稼働していても、利用者が必要な処理を完了できない障害もあります。
6. よく出る用語を、一つの例で整理する
例として「https://www.example.com/products」を考えます。実際の会社サイトや接続確認の結果ではなく、説明用のURLです。
表が収まらない場合は、横にスクロールできます
| 用語 | この例での意味 |
|---|---|
| URL | https://www.example.com/products という、取りに行く資源を示す全体 |
| ドメイン名・ホスト名 | www.example.com の部分。接続先を名前で表す |
| パス | /products の部分。サイト内で何を要求するかを示す |
| IPアドレス | ネットワーク上の宛先を表すための値。URL全体やドメイン名と同じではない |
| ホスティング | サイトやアプリを置いて利用できるようにするための提供形態 |
| ダウンタイム | 対象のサービスを利用できない時間 |
ドメインとURLを同じものとして扱うと、「名前の契約」「ページの場所」「サーバーの契約」が混ざります。MDNも、URLの中でスキーム、ドメイン、パスなどを分けて説明しています。MDN:URLとは
独自ドメインを持っていても、Webサイトの置き場所やメールの提供先が自動で用意されるわけではありません。複数の事業者を利用する場合、どの契約が何を受け持つのかを残しておくと、担当者の交代や移行時にも確認できます。
7. 見積もりは、月額だけで比べない
サーバー費には、計算資源や保存容量のほか、通信、バックアップ、監視、運用支援などが含まれる場合があります。別料金の場合もあるため、ここでは条件のない相場を置きません。
比較するなら、同じ用途と責任範囲を前提にします。
- 初期設定と移行:データや設定を誰が移し、確認するか。
- 継続利用:何の単位で請求され、使用量が増えると何が増額されるか。
- 運用:更新、監視、問い合わせ対応、緊急対応の範囲。
- 保存と復旧:バックアップの保持、復元作業、確認の費用。
- 終了:データを取り出す方法、期間、形式と費用。
低い月額でも、必要な管理作業が別途残れば総負担は変わります。高いプランでも、必要のない性能や運用支援なら適切とは限りません。自社で作業できる担当がいるか、任せたい作業は何かまで含めます。
8. 契約する前に、用途を一枚に書く
まず次の六つを書けば、サーバーの型番を選ぶ前に相談できます。
- 何を提供するか:会社紹介、予約、注文、メール、社内共有など。
- 誰がいつ使うか:社内だけか公開か、集中する時間はあるか。
- どのデータを置くか:機密性、失った場合の影響、増える量。
- 止まったらどうするか:代替手段と、許容する停止・損失。
- 誰が面倒を見るか:契約、更新、権限、監視、復旧の担当。
- どうやめるか:取り出し、移行、アクセス解除の担当と条件。
分からない欄は、分からないまま質問にします。「全部お任せ」の一言ではなく、「OSの更新は契約内だが、サイトの拡張機能は誰が更新するか」のように、作業単位で確認することが大切です。
サーバーを選ぶ出発点は、大きい機械や有名な事業者を選ぶことではありません。提供したい機能と、継続して管理する仕事を対応させることです。その対応が分かると、持つ・借りる・機能として使う選択肢を比べられます。