1コア1GBのKVMサーバーで何ができる？性能を極限まで引き出す究極ガイド

毎年ブラックフライデーになると、フォーラムには「1コア1GB・年額がコーヒー1杯以下」のKVMチキンサーバーが一斉に登場します。買って放置する人もいれば、ブログ、リバースプロキシ、WireGuard、RSS、定期タスクまで回している人もいます——同じスペックでも差が出るのは、ハードウェアではなくチキンサーバー運用の勘所、つまりデフォルトのフルスタックを軽量コンポーネントに置き換え、カーネルパラメータで1MBのメモリと1回のコンテキストスイッチまで計算する力にあります。

この記事では「もっと大きいマシンを買え」という話はしません。ひとつの問いだけに答えます：1コア1GBでサイト構築やサービス運用をする場合、限界はどこにあり、どうやってそのラインに近づくか？

現実を受け入れる：1コア1GBで何ができるか

KVMで1コアとは、多くの場合物理コアの専有がないことを意味し、バースト時の計算力は限られます。1GBのメモリは、OS、キャッシュ、アプリ、接続の間で分け合う必要があります。「何も動かせない」わけではなく、ひとつのことをしっかり動かすのが前提で、それ以外は統合するか外部に出すしかありません。

メモリ台帳：1MBごとに役割を決める

Debian 12の最小インストールでSSHだけ有効にした場合、システムの常駐メモリはおよそ150〜200MBです。アプリに回せる「実質予算」は400MB前後——ページキャッシュや突発的な接続はまだ含みません。

• システム + systemd + sshd：約150〜180MB。不要なunitを無効化すればさらに30〜50MB節約可能。
• Webリバプロ（Caddy / nginx）：約15〜40MB。静的サイトモードならnginxの方がさらに軽い。
• アプリランタイム：Goバイナリは通常10〜30MB。Node.jsは空プロセスでも50MB以上——チキンサーバーでは慎重に。
• データベース：SQLiteは常駐ほぼゼロ。MySQL 8のデフォルト設定は簡単に400MBを消費。
• Swap / zram：512MB〜1GBの仮想メモリをバッファとして確保するのは推奨。ただし「本物のメモリ」の代わりにはしないこと。

⚠️ 経験則：free -hではfree列だけでなくavailable列を見てください。Linuxは空きメモリをキャッシュに使うため、実際にアプリが確保できる量はavailableです。

1コア1GBでのサイト構築：軽量コンポーネントの代替案

従来のLAMP/LNMPスタックはチキンサーバーではメモリ殺しです。以下の組み合わせは、実戦で日数千PVの個人サイトを安定稼働させてきました：

動的コンテンツが必要なら、まずGo単一バイナリ（PocketBase、miniBlog系ツールなど）かPython FastAPI + SQLiteを検討し、worker数は1に固定してください。

そのまま使えるCaddy静的サイト設定

example.com {
    root * /var/www/site
    file_server
    encode gzip zstd
    header Cache-Control "public, max-age=3600"
}

サイト全体のメモリ使用量は通常< 30 MB。HTTPSの自動更新もあり、certbotは不要です。ビルドはローカルまたはCIで完了させ、チキンサーバーは「ファイルを配る」だけ——これが1コア1GBでのサイト構築で最も安定したルートです。

KVM性能最適化：カーネルとシステム層の調整

KVM仮想マシンのネットワークとI/O性能はホスト側に大きく依存しますが、ゲスト側にも十分な調整余地があります。以下のパラメータは多くのDebian / Ubuntuチキンサーバーで有効です：

1. BBR輻輳制御の有効化

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3

海外回線のチキンサーバーでは、BBRはデフォルトのcubicより帯域を「埋めやすく」、体感レイテンシーも改善しやすいです。

2. 従来のSwapパーティションの代わりにzramを使う

ディスクSwapはVPSではI/O遅延が高く、マシン全体を固めやすい。zramはメモリ圧縮でSwapを模擬し、小さなスパイクに強い：

apt install zram-tools
# /etc/default/zramswap で設定：
# ALGO=lz4
# PERCENT=50

3. swappinessを下げてホットデータを守る

vm.swappiness = 10
vm.vfs_cache_pressure = 50

4. 接続数とファイルディスクリプタ

net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048
fs.file-max = 65535

5. systemdサービスの削減

不要なサービスを確認して無効化。よく切れる項目：bluetooth、avahi-daemon、ModemManager、パネル付属の監視エージェント（外部監視がある場合）。

チキンサーバー活用リスト：7つの実用的な用途

1コア1GBを専用エッジノードとして扱い、ミニデータセンターにしない——そう考えれば、以下を安定稼働させられます：

1. 個人ブログ / 技術ドキュメント：Hugo + Caddy、ローカルビルド後にrsyncデプロイ。
2. リバースプロキシ入口：手前にCloudflare、裏で内網やオブジェクトストレージのオリジンへ転送。
3. WireGuardジャンプホスト：3〜5台のデバイスを接続、CPU負荷は極小。
4. Webhook / Bot常駐：Telegram、Slack、LINE Botなど、GoまたはPythonの単一プロセス。
5. DNSまたはAdGuard Home：クエリログのサイズ制限と定期ローテーションを忘れずに。
6. 軽量監視プローブ：Uptime Kumaやカスタムcurlスクリプトで外部ダッシュボードへ報告。
7. プライベートGitミラー：git daemonやGiteaのミニマルモード、リポジトリはGB単位以内に。

AI推論、大規模プロジェクトのコンパイル、セキュリティスキャンパイプラインにはチキンサーバーは不向き——こうした作業は専用開発マシン向きです。コードセキュリティレビューのツールチェーンを検討しているなら、GitHub Copilot App /security-review 使い方ガイドを参照し、重い処理はローカルやクラウドMacで行いましょう。

赤線：チキンサーバーで絶対にやってはいけないこと

• Elasticsearch / ClickHouse：公式の最低メモリ推奨が1Gを大きく超え、起動直後にOOM。
• デフォルト設定のMySQL 8：innodb_buffer_pool_sizeを64Mまで下げ、極端に遅いクエリを受け入れる場合を除き非推奨。
• aaPanel / LNMP一括インストール：パネル + Nginx + MySQL + PHPで常駐800MB超えも珍しくない。
• Kubernetes（k3s単一ノード）：コントロールプレーン自体がチキンサーバー向きではない。
• Dockerフルスタックの同時稼働：dockerd + compose複数サービスでメモリ断片化が深刻に。
• チキンサーバーをNAS代わりにBTダウンロード24時間稼働：ディスクI/Oとメモリの二重負荷、商業回線の帯域制限も。

監視とトラブルシュート：OOMの5分前

チキンサーバーに余裕はない。監視は軽く、正確に、通知できることが重要：

• node_exporter：指標は充実するがやや重い（~20 MB）、少し余裕があるマシン向け。
• glances：ターミナル向き、glances -wで簡易Webパネルも可能。
• カスタムスクリプト：cronで5分ごとにMemAvailableを確認、80MB未満ならTelegramへcurl通知。
• ログローテーション：logrotateは必須。access.logがディスクを埋めるのはOOMよりよくある。

負荷テストで見る3つの指標：load average（1コアなら1.5超えを長期維持しない）、MemAvailable（100MB以上を維持推奨）、iowait（Swapスラッシング時に急上昇）。

いつ「卒業」して大きなマシンに移るべきか？

以下のいずれかに当てはまれば、チキンサーバーの寿命です：

• 週1回以上OOMが発生し、本文の最適化をすべて実施済み。
• Web + データベース + バックグラウンドタスクを同時稼働が必要で、どれも外部化できない。
• 日次UVが安定して1万超え、CDNキャッシュ後もオリジンのCPUが常時フル。
• タスクが「ページホスティング」から「コンパイル、テスト、AI推論」へ——クラウドMacや上位VPSを検討する段階。

モデル選定やプロキシアーキテクチャなど計算リソースに敏感な作業は、Gemini 4は待つべき？2026年の選び方を参考に、推論と評価はリソースに余裕のある環境で行いましょう。