同時アクセス数とは、同じ時間帯にWebサイトへアクセスしている利用者や、サーバーが同時に処理しているリクエストの多さを表す考え方です。 月間PVが同じでも、アクセスが1日中ばらけるサイトと、数分間に集中するサイトではサーバー負荷が大きく異なります。
特にWordPressでは、未キャッシュページを同時に多く処理するとPHPやデータベースへの負荷が増えやすいため、「月間PV」だけでなく「短時間にどれだけアクセスが重なるか」を見ることが重要です。
30秒でわかる結論
30秒でわかる結論
- 同時アクセス数は、同じ時間帯にアクセスや処理が重なっている量を見るための考え方
- 月間PVが多くても均等なら負荷は低く、短時間集中なら負荷は高くなりやすい
- WordPressではPHP・データベース・CPU・メモリが同時処理の影響を受けやすい
- 「100人同時アクセス＝100処理」と単純にはならない
- キャッシュ済みページと未キャッシュページでは、同じアクセス数でも負荷が大きく違う
- 共用レンタルサーバーでは、同時アクセス上限を公開していない場合も多い
- 初心者は人数の上限値だけを探すより、アクセス集中時に遅延・503・制限が出ないかを見る
同時アクセス数とは？
同時アクセス数とは、一定の短い時間内にWebサイトへアクセスが重なっている状態を表す言葉です。 ただし、実務では「同時に見ている人の人数」「同時接続数」「同時リクエスト数」「PHPが同時処理している数」など、似た言葉が混在します。
初心者向けに言い換えると
「その瞬間に、サーバーへどれだけ仕事が重なっているか」を考えるための目安です。
たとえば、1時間に1,000PVあったとしても、1時間へ均等に分散している場合と、SNS投稿直後の1分間に大部分が集中する場合では、必要な処理能力が違います。
PVと同時アクセス数は違う
| 項目 | 意味 | 分かること |
|---|---|---|
| PV | ページが表示された回数 | 一定期間の閲覧量 |
| ユーザー数 | 訪問した利用者の数 | 利用者規模 |
| 同時アクセス | 短時間に重なったアクセス | 瞬間的な負荷 |
| 同時リクエスト | 同時に処理中のHTTP要求 | サーバー処理の混雑度 |
月30万PVでも負荷は同じではない
300,000PV ÷ 30日 ÷ 24時間 ≒ 417PV/時
単純平均では1時間あたり約417PVですが、実際には昼休み、キャンペーン開始、テレビ紹介、SNS拡散などで短時間に集中することがあります。
このため、「月30万PVに耐えられるサーバー」という表現だけでは、アクセス集中への強さまでは判断できません。
「100人同時アクセス」は100リクエストとは限らない
同時に100人がサイトを見ていても、100人全員が同じ瞬間にサーバーへPHP処理を要求しているとは限りません。
Webページを開くと、HTMLだけでなく画像・CSS・JavaScript・フォントなど複数のファイルを読み込むことがあります。 一方で、ブラウザやCDN、サーバーキャッシュから返されるファイルは、WordPressのPHPを毎回動かさない場合があります。
人数と処理数を同一視しない
「同時アクセス100人まで」のような数字があっても、実際の負荷はページ構成、キャッシュ、HTTP通信、PHP処理時間、データベース処理などで変わります。 人数だけではサーバー負荷を正確に決められません。
同時アクセスが増えると何が重くなる？
| 要素 | 同時アクセス増加時の影響 |
|---|---|
| CPU | PHP・計算処理が同時に増える |
| メモリ | 複数処理が同時にメモリを使用する |
| PHP | 同時実行できるプロセス数に影響 |
| データベース | 同時クエリが増え待ち時間が発生しやすい |
| ストレージ | DB・ファイルI/Oが集中することがある |
| 回線 | 画像などの転送量が一気に増える |
特にWordPressの未キャッシュページでは、アクセスのたびにPHPを実行し、データベースから情報を取得してHTMLを生成するため、同時処理が増えるほどCPU・メモリ・DBへ負荷がかかりやすくなります。
アクセス → PHP実行 → DB取得 → HTML生成 → 応答
PHPの同時処理数がボトルネックになることがある
PHP-FPMを使う環境では、同時に処理できるPHPリクエスト数に上限があります。
PHP公式マニュアルでは、pm.max_childrenが同時に処理できるリクエスト数の上限を決める設定として説明されています。
イメージ
同時に処理できるPHPリクエストが20件で、21件目以降が来た場合、すぐ処理できず待ち行列へ入ることがあります。
ただし、共用レンタルサーバーでは利用者がこの設定値を確認・変更できない場合が多くあります。 そのため初心者は、具体的な内部値を調整するより、アクセス集中時に応答速度が落ちないか、503エラーやリソース制限が出ていないかを確認する方が実用的です。
CPUとの関係
同時アクセスが増えると、PHP処理、テンプレート生成、画像処理、検索、EC処理などが同時に走り、CPU使用率が高くなりやすくなります。
負荷が高くなりやすいページ
- 商品検索
- 絞り込み検索
- 会員ページ
- ECカート
- 予約ページ
- 大量プラグインを使うページ
- キャッシュできない管理画面
一方、完成済みHTMLをキャッシュから返せるページでは、PHPやデータベースを動かさず応答できるため、同じアクセス数でもCPU負荷を大幅に減らせる場合があります。
メモリとの関係
複数のPHPプロセスやデータベース処理が同時に動くと、それぞれがメモリを使用します。
同時処理が増える → 使用メモリが積み重なる → 空きメモリが減る
たとえば、1つのPHP処理が平均100MB使う環境で20処理が同時に走れば、単純計算ではPHPだけで約2GB使う可能性があります。 実際の使用量は処理内容ごとに変わるため、この計算はあくまでイメージです。
PHPメモリ上限とは別
PHPのmemory_limitは基本的に1つのPHP処理が使えるメモリ上限です。
「同時アクセス数」と「1処理あたりのメモリ上限」は同じ意味ではありません。
複数処理が同時に動けば、サーバー全体では合計メモリ使用量が増えます。
データベースとの関係
WordPressでは記事、設定、ユーザー情報、コメント、商品情報などをMySQLやMariaDBから取得します。 アクセスが集中すると、同じ時間帯にデータベースへの問い合わせも増えることがあります。
複雑な検索、重いプラグイン、最適化されていないクエリ、大きなデータベースなどがあると、同時アクセス増加時にDB処理がボトルネックになる場合があります。
CPUだけ増やせば解決するとは限らない
CPUに余裕があっても、データベース待ちが長ければページ表示は遅くなります。 サーバー性能はCPU・メモリ・PHP・DB・キャッシュをまとめて見ます。
キャッシュが同時アクセスに強くする理由
アクセス集中対策で特に重要なのがキャッシュです。
| 状態 | サーバー処理 |
|---|---|
| 未キャッシュ | PHP・DBを動かしてHTMLを生成 |
| ページキャッシュあり | 生成済みHTMLを返せる |
| CDN利用 | 静的ファイルを外部拠点から返せる |
同じ100アクセスでも負荷は違う
100件すべてがWordPressのPHP処理を必要とする場合と、90件をキャッシュやCDNから返せる場合では、元サーバーが実際に処理する仕事量が大きく変わります。
静的サイトとWordPressでは同時アクセスへの強さが違う
| サイト | アクセス時の処理 | 同時アクセス時の負荷 |
|---|---|---|
| 静的HTML | 既存ファイルを返す | 比較的低い |
| WordPressキャッシュ済み | 生成済みページを返す | 低くしやすい |
| WordPress未キャッシュ | PHP・DBで毎回生成 | 高くなりやすい |
| EC・会員サイト | 個別の動的処理が多い | 高くなりやすい |
そのため「このサーバーは同時アクセス500人まで」と単純な人数で比較するより、どの種類のページを何件同時に処理するかを見る方が実態に近くなります。
同時接続数と同時アクセス数は同じ？
厳密には同じではありません。
Webサーバーには、同時に保持できるネットワーク接続数があります。
たとえばNginxではworker_connectionsという設定が、1つのworker processが同時に開ける接続数に関係します。
ただし、これは利用者人数そのものではなく、クライアントだけでなくプロキシ先などの接続も含む場合があります。
またHTTP/1.1では接続を再利用する仕組みがあり、HTTP/2では1つの接続上で複数のリクエストを多重化できます。 そのため「接続数＝アクセス人数」とは数えられません。
初心者はネットワーク接続数そのものを追うより、「同時に処理中のPHP」「DB負荷」「CPU使用率」「応答時間」を見る方が、WordPressの実際の混雑を判断しやすくなります。
同時アクセスが多すぎると何が起きる？
- ページ表示が遅くなる
- TTFBが長くなる
- PHP処理待ちが増える
- データベース応答が遅くなる
- CPU使用率が高止まりする
- メモリ不足が起きる
- 503 Service Unavailableなどのエラーが出る場合がある
- 共用サーバーのリソース制限にかかる場合がある
エラーが出たから即サーバー変更とは限らない
原因がキャッシュ未設定、重いプラグイン、外部API待ち、DBの肥大化などサイト側にある場合、上位サーバーへ変更しても根本原因が残ることがあります。
同時アクセス数はどこで確認する？
一般のレンタルサーバー利用者が「今ちょうど47人を処理中」と正確に把握するのは簡単ではありません。 利用環境によって確認方法が異なります。
確認に使える情報
- アクセスログ
- サーバー会社のリソース使用量画面
- CPU使用率
- メモリ使用量
- PHPプロセスや実行数
- 応答時間
- 503などのエラーログ
- アクセス解析のリアルタイム表示
GA4などのリアルタイム利用者数はアクセス集中の傾向を見る参考になりますが、サーバー内部の「同時処理数」そのものではありません。 サーバー負荷を見るなら、アクセスログやリソース使用状況と合わせて確認します。
何人まで耐えられるか計算できる？
単純な人数だけでは計算できません。
同時アクセスへの耐性は、1リクエストにかかる処理時間、CPU、PHP同時実行数、メモリ、DB処理、キャッシュ率、ページ容量などで変わります。
耐えられる同時アクセス ＝ サーバー性能だけでなく、1アクセスあたりの処理量で変わる
イメージ
1件の処理が0.1秒で終わるサイトと、1件に2秒かかるサイトでは、同じサーバーでも待ち行列の発生しやすさが大きく異なります。
このため、正確に確認したい場合は本番環境へ無断で大量アクセスを送るのではなく、ステージング環境やサーバー会社のルールに従って負荷試験を行います。
レンタルサーバー選びで何を確認する？
共用レンタルサーバーでは、「同時アクセス○人」という上限を公開していないサービスも多くあります。
その場合は次の項目を確認します。
比較ポイント
- CPU・メモリなどの割当情報
- 高負荷時の制限条件
- リソース使用量を確認できるか
- サーバー側キャッシュ機能
- CDN対応
- 上位プランへの変更しやすさ
- アクセス集中時の公式FAQ
- 503などが出たときのサポート情報
「同時アクセス無制限」という言葉だけで判断せず、高負荷時にどのような制限があるかを見る方が重要です。
アクセス集中に強くする方法
ページキャッシュを使う
WordPressで毎回PHP・DBを動かす必要がないページは、ページキャッシュを利用すると負荷を下げやすくなります。
CDNを使う
画像、CSS、JavaScriptなどをCDNから配信できれば、元サーバーの回線や静的ファイル配信負荷を減らせます。
重いプラグインや処理を見直す
検索、アクセス集計、バックアップ、外部API通信などが重いと、アクセス集中時に処理待ちが増えやすくなります。
PHP・データベースを最新の安定構成に保つ
WordPress本体・テーマ・プラグインとの互換性を確認しながら、サポートされているPHPバージョンや適切なDB環境を使います。
上位プランやVPSを検討する
キャッシュやサイト改善をしてもリソース不足が続く場合は、CPU・メモリの割当が大きいプランやVPSなどを検討します。
どんなサイトで同時アクセスを意識すべき？
個人ブログ
重要度：通常は低め
検索流入が分散している一般的なブログなら、通常は同時アクセス数を細かく管理する必要はありません。SNS拡散が多い場合は注意します。
会社サイト
重要度：中
プレスリリース、テレビ出演、採用発表などで瞬間的にアクセスが増える可能性がある会社は確認します。
EC・予約サイト
重要度：高
カート・在庫・予約など動的処理が多く、ページキャッシュしにくいため、同時処理能力が重要です。
キャンペーン・イベントサイト
重要度：非常に高
開始時刻が決まっている企画はアクセスが一気に集中しやすいため、事前の負荷確認やCDN活用を検討します。
初心者が勘違いしやすいポイント
| 誤解 | 正しい考え方 |
|---|---|
| 月100万PVなら必ず高性能サーバーが必要 | アクセス集中の度合いも見る |
| 100人見ていれば100PHP処理 | キャッシュや通信方式で変わる |
| CPUが高性能なら全部解決 | DB・メモリ・PHP・キャッシュも影響 |
| 同時接続数＝ユーザー数 | 接続・リクエスト・人数は別概念 |
| 人数の上限さえ分かればよい | 1アクセスあたりの処理量も重要 |
教科書判定
初心者は「何人まで」より「短時間に重なったとき、どの処理が詰まるか」を見る
通常の個人ブログや小規模会社サイトでは、同時アクセス数を細かく計算しすぎる必要はありません。 まずページキャッシュを有効にし、CPU・メモリ・応答時間・エラーの有無を確認できれば十分です。
一方、EC、予約、会員サイト、キャンペーンサイトのように動的処理が多い、またはアクセス集中が予想されるサイトでは、PHPの同時処理、データベース負荷、CDN、上位プランまで含めて事前に確認してください。
「同時アクセス100人に耐えるか」ではなく、「100人が何をするのか」を考えることが重要です。
FAQ
Q．同時アクセス数とPVは同じですか？
違います。PVは一定期間にページが表示された回数で、同時アクセス数は短時間にどれだけアクセスが重なったかを見る考え方です。同じ月間PVでも集中度によってサーバー負荷は変わります。
Q．100人同時アクセスなら100PHPプロセス必要ですか？
必ずしも必要ではありません。キャッシュでPHPを動かさず返せるアクセスもあり、利用者が常に同時にリクエストを送るわけでもありません。ページの処理内容とキャッシュ構成で変わります。
Q．WordPressは同時アクセスに弱いですか？
WordPressだから必ず弱いわけではありません。ただし未キャッシュの動的ページではPHPとDB処理が必要なため、静的HTMLより負荷が高くなりやすい傾向があります。キャッシュやCDNで改善できます。
Q．共用レンタルサーバーで同時アクセス上限を確認できますか？
サービスによって異なります。具体的な人数を公開していない場合も多いため、CPU・メモリ割当、高負荷時の制限、リソース使用量画面、プラン変更のしやすさなどを確認してください。
Q．アクセス集中対策で最初に何をすればよいですか？
一般的なWordPressサイトなら、まずページキャッシュ、画像最適化、重いプラグインの見直し、CDN利用可否を確認します。そのうえでリソース不足が続くなら上位プランを検討します。
まとめ
この記事の結論
- 同時アクセス数は短時間にアクセスが重なった度合いを見る考え方
- 月間PVが同じでも集中度によって負荷は変わる
- 人数・接続数・リクエスト数・PHP処理数は同じではない
- WordPressではCPU・メモリ・PHP・DBが同時処理の影響を受けやすい
- キャッシュ済みページは同じアクセス数でも負荷を下げやすい
- 共用サーバーでは具体的な同時アクセス上限が非公開の場合もある
- EC・予約・キャンペーンサイトは同時処理能力を特に確認する
- 初心者は「何人まで」より、アクセス集中時の応答時間・リソース・エラーを見る
同時アクセス対策で重要なのは、利用者数だけを見ることではありません。 同じ100人でも、キャッシュされた記事を読むのか、検索・カート・予約処理を同時に行うのかでサーバー負荷は大きく変わります。 サイトの処理内容とアクセスの集中度をセットで判断してください。
「CPU使用率とは？高くなる原因と確認ポイント」「メモリ使用率とは？不足するとどうなる？」「TTFBとは？サーバー応答速度の見方と改善方法」もあわせて確認してください。