本記事はアフィリエイト広告（PR）を含みます。社名のリンクには広告リンクを含む場合があります。成約の有無で本記事の数値と結論は変えません。
本記事は 2026-10-31〜11-02（JST）に当社が契約しているアカウントから測った値だけで書いています。
結論
- 共用サーバーの中から見える「メモリ」「CPU」「ディスク」「負荷」は、物理機（とストレージ全体）の値で、自分が使える量ではありません。
- 自分が使える量は、プランごとの制限値（ディスク容量、PHP の実行時間とメモリ、同時プロセス数など）で決まります。比べるならそちらを見てください。
- 資源の保証が要るなら、VPS か、資源を保証するプランを選びます。
測ったもの
当社が契約している共用サーバーのアカウント6つで、2026-10-31（JST）に測りました。XREA が3つ、CORESERVER が3つです。以降は XREA-A／B／C、CORESERVER-A／B／C と呼びます。
自分の契約領域に、読み取り専用のファイルを一度だけ置いて値を読み、すぐ削除しました。書き込み・攻撃・他の利用者の領域への操作はしていません。読んだのは /proc/cpuinfo・/proc/meminfo・/sys/class/dmi/id/・/run/systemd/container・自プロセスの cgroup・/proc/self/mounts と、PHP の実行ユーザー・ini 値です。
実測表: 中から見える値
| 区分 | 物理機（DMI） | CPU | 見えるメモリ | 見えるディスク | カーネル | PHP |
|---|---|---|---|---|---|---|
| XREA-A | Dell PowerEdge R6525 | AMD EPYC 7713P 64コア/128スレッド | 995GB | 13.4TB | 6.8.0-147 | 8.5.12 |
| XREA-B | Dell PowerEdge R6615 | AMD EPYC 9534 64コア/128スレッド | 1,133GB | 27.9TB | 6.8.0-147 | 8.5.12 |
| XREA-C | Dell PowerEdge R6525 | AMD EPYC 7713P 64コア/128スレッド | 995GB | 10.2TB | 6.8.0-147 | 8.5.12 |
| CORESERVER-A | Dell PowerEdge R6525 | AMD EPYC 7763 64コア/128スレッド | 995GB | 9.9TB | 5.15.0-198 | 8.5.12 |
| CORESERVER-B | Dell PowerEdge R6525 | AMD EPYC 7763 64コア/128スレッド | 995GB | 7.4TB | 5.15.0-198 | 8.5.12 |
| CORESERVER-C | Dell PowerEdge R6525 | AMD EPYC 7763 64コア/128スレッド | 995GB | 9.6TB | 5.15.0-198 | 8.5.12 |
測定日: 2026-10-31〜11-02（JST）。当社契約のアカウントから見えた値です。メモリは /proc/meminfo の MemTotal（1GB＝1,024MB で換算）で、11-02 まで15分ごとの記録で値は変わっていません。ディスクは PHP の disk_total_space で 11-02 に取った値（1TB＝10¹²バイト）です。ZFS では、同じ領域を使う他の利用者の使用量によって総量の表示も変わり、10-31 には XREA-A が 13.6TB でした。
なぜ物理機の値が見えるのか
6つとも、仮想マシンではなくコンテナ（LXD）の中でした。根拠は4つです。
- CPU フラグに
hypervisorがない（仮想マシンの中なら立つ） - DMI に物理機の型番（PowerEdge）がそのまま出る
/run/systemd/containerの中身がlxc- ルートファイルシステムが ZFS の
lxd/containers/<サーバー名>
コンテナは、1つのカーネルを複数の利用環境で共有する仕組みです。/proc を物理機の値から作り替える仕組み（lxcfs など）を入れていなければ、中からは物理機の値が見えます。
コンテナ型: 物理機 → カーネル（1つ） → コンテナ A / B / C …（/proc は物理機の値）
VM 型: 物理機 → ハイパーバイザー → VM A（カーネル A） / VM B（カーネル B） …（割り当てた値だけ見える）
同じ方法で測った VPS（WebArena Indigo、当社契約）は、systemd-detect-virt が kvm、CPU に hypervisor フラグがあり、見えたのは割り当てた1 vCPU・961MB・19GB だけでした（2026-10-31）。さくらのレンタルサーバ（当社契約の1台）も仮想マシン（KVM）で、6 vCPU・約24GB が見えました（2026-11-01）。
上限は「無制限」ではなく、見えない場所にある
6つとも、cgroup の memory.max は max、cpu.max と io.max は設定なしでした。コンテナの中には、CPU・メモリ・IO の上限が見当たりません。PHP の設定では次の値でした。
| 項目 | 6つの値 |
|---|---|
memory_limit |
1024M |
max_execution_time |
300秒 |
open_basedir |
空（PHP 側の読み取り制限なし） |
利用者ごとの制限は、コンテナの外の仕組み（プロセスの監視など）で管理されていると考えられます。これは推定で、実測で確かめたものではありません。大事なのは次の点です。見える数字が大きくても、使える量が大きいとは限らない。
負荷平均（load average）の読み方
負荷平均も物理機全体の値です。128スレッドの機体なので、128前後が「ほぼ全スレッドが埋まっている」目安になります。2026-11-01 03:47 から 2026-11-02 19:15（JST）まで、15分ごとに各159回、1分平均の負荷を取った結果が次の表です。
| 区分 | 平均 | 最小 | 最大 |
|---|---|---|---|
| XREA-A | 28.5 | 10.4 | 100.1 |
| XREA-B | 23.1 | 15.0 | 41.1 |
| XREA-C | 50.8 | 23.0 | 119.8 |
| CORESERVER-A | 50.8 | 21.9 | 291.7 |
| CORESERVER-B | 36.0 | 14.4 | 708.9 |
| CORESERVER-C | 37.4 | 15.0 | 104.3 |
| さくらのレンタルサーバ（当社契約） | 0.3 | 0.0 | 1.4 |
観測期間は約1.6日（39時間半）です。最大値は1回の値で、その負荷が続いたかどうかはこの表からは分かりません。負荷と応答時間の関係は、期間が長くなってから別の記事（隣人の影響の実測）で扱います。さくらは1台あたり6 vCPU の仮想マシンなので、物理機と同じ尺度では比べられません。
公式スペック表で見るべき項目
メモリ・CPU の大きな数字ではなく、次の項目を見てください。
- ディスク容量（割り当て）と inode 数
- 転送量の上限
- 同時接続数・同時プロセス数
- PHP の実行時間とメモリの上限
- データベースの数と容量
まとめ
- 共用サーバーの中から見える数字は、物理機のものです。自分の割り当てではありません。
- 比べるなら、公式の制限値と実測の応答時間を見てください。
- 資源の保証が要るなら VPS を選びます。仕組みの違いは VPS と共用サーバーの隔離の違い で説明します。
本記事の数値は当社が契約しているアカウントでの実測で、測定日時を各表に記しました。当社は計測用サーバーを契約しており、リンク先との契約でアフィリエイト収入を得る場合があります。