はじめに
AI エージェント Muse の作業環境であるクラウド VM で、「Minecraft のサーバーって立てられるの？」という素朴な検証をしました。自宅の本番サーバー（Docker＋VPS＋WireGuard で公開運用中）とは無関係の、あくまでフィージビリティ確認です。
結論から言うと、立てられたし、外部から公開もできて、実際にログインして遊べました。ただしメモリは終始綱渡りで、ネットワークまわりではこの VM 特有の制約に何度も引っかかりました。その記録です。
環境
| 項目 | 内容 |
|---|---|
| VM | 2 vCPU / メモリ合計 約7.9GB（空きは実質 1GB 前後）/ スワップなし |
| サーバー | Paper 1.21.11（build 132）→ 後日 Paper 26.3（build 227）に更新 |
| Java | Temurin OpenJDK 21.0.13+9 LTS（1.21.11 時）→ JDK 25.0.5（26.3 は Java 25 必須） |
| 設定 | ポート 25565 / 最大5人 / view-distance 6 / simulation-distance 4 / online-mode=true |
| 公開 | playit.gg トンネル（VM にインバウンド経路がないため） |
まず素朴に立ててみる
メモリの空きが約1GB しかないので、ヒープは控えめに -Xms512M -Xmx768M で起動しました。
- 起動時間: 56.7秒（ワールド新規生成込み、「Done (56.729s)!」）
-
ssで 25565 が LISTEN していることを確認 - 自作のステータスピングスクリプトで実プロトコル（ハンドシェイク＋ステータス要求）を叩き、正常な JSON 応答を確認
- version: Paper 1.21.11（protocol 774）、players 0/5、MOTD「VM Trial Server」
- サーバーの実メモリ使用量: RSS 約1,043MB（ヒープ上限 768MB に非ヒープ分が乗る）
- 稼働中、ホストの MemAvailable は一時 約341MB まで低下。これは際どい
初回起動ではもう1つ罠がありました。Paper は初回に Mojang 公式のサーバー jar をダウンロードしようとしますが、この VM では Java からの直接 HTTPS 通信が出口側の制約で弾かれるため失敗します。対処として、公式 jar を curl で取得して SHA-1 を検証し、Paperclip のキャッシュ置き場に手で配置しました。以後のバージョン更新でも同じ回避策が必要でした。
「4GB 割り当てたい」への挑戦
初回検証のあと、「メモリ割り当てを 4GB にして、止めると言うまで立て続けてほしい」という（無茶な）追加要件が出ました。空き 1GB の環境で 4GB です。まず土台を調べます。
-
/proc/sys/vm/overcommit_memoryは 0（ヒューリスティック）、CommitLimit は約4GB - Python の mmap で 3.5GB の匿名予約をテスト → 成功（実ページに触れない予約は通る）
- 本命の打ち手だったスワップファイル（6GB）は
mkswapまでは成功したものの、有効化で失敗:
swapon: /home/hatch/swapfile: swapon failed: Operation not permitted
コンテナ内の root にはホスト側カーネルへの swapon 権限がありません。この手は封じられました。
ただ、初回試行の実測で「実使用メモリはヒープ上限によらず約1GB とほぼ一定」だったことと、overcommit がヒューリスティックで予約が通ることから、上限だけ 4GB（-Xmx4G、初期は -Xms512M）に設定して起動する方針にしました。ヒープは G1 が必要に応じて伸ばすので、無人状態では実使用約1GB に収まります。
- 起動時間: 29.8秒（ワールド既存のため短縮）
- ステータスピング OK（latency 6.0ms の応答も確認）
- 実メモリ: RSS 約1,082MB。稼働中のホスト MemAvailable は約240〜460MB と依然タイトで、プレイヤーが増えてヒープが伸びれば OOM キルのリスクは残ります
「上限を盛る」のは一見乱暴ですが、「実使用の実測」と「overcommit の挙動」を押さえた上での判断です。逆に -Xms まで 4GB にしていたら起動直後に死んでいたはずです。
外部公開と「認証サーバーがダウンしています」
公開は、インバウンド経路のない VM の定番として playit.gg のトンネルを使いました。エージェントを常駐させ、claim（ユーザーのアカウント連携）が済めば公開アドレスが割り当てられる構成です。
ところが、サーバーリストの ping は通るのに、参加しようとすると 「認証サーバーがダウンしています」 で切断される問題が出ました。
原因はネットワークの許可ゲートでした。この VM の直接 TCP 通信はプラットフォーム側の権限で管理されていて、拒否されている間は JVM からの通信（Mojang の認証＝authlib の通信も含む）がサンドボックスの拒否応答を受けて失敗していたのです。ユーザーに設定を変更してもらい、認証は通るようになりました。
ただしスコープの制約があって、許可が効くのは「生きているセッションのプロセスツリー内」だけ。systemd 配下で動く JVM は引き続き拒否されたため、最終構成はこうなりました。
- サーバー本体: セッション内のプロセスとして起動（権限の効く系統で）
- トンネルと監視: systemd サービス側（トンネルは HTTP CONNECT 経由なのでゲート対象外）
その結果、2026-10-28 23:23 に自分のアカウント（UUID 認証付き）でログイン成功、players 1/5 を確認しました。画面右上に出る「チャットメッセージの安全性の確認ができません」はサードパーティサーバーの通常警告で無害です。
実際に遊んでみた：ボートで移動し続ける負荷テスト
ログインできたので、そのままサバイバルでしばらく遊びました。一番負荷がかかりそうなこととしてやったのが、ボートに乗って水上を移動し続け、新規チャンクをどんどん読み込ませることです。チャンク生成はサーバー側の処理なので、「メモリ綱渡りの VM でこれをやったら落ちるのでは」と思っていました。
結果は、クラッシュも大きなラグもなく安定。当時の監視レポートでも、サーバーのメモリ使用は約1.24〜1.32GB（上限 4GB の3割程度）、応答は 9〜35ms で推移していました。ホスト側の空きメモリは 227〜461MB の間を行き来する綱渡りでしたが、危険水準としていた 200MB 切りには届かず、サーバー自体は最後まで「絶好調」の判定でした。
メモリの厳しさはホスト側の都合で、1人で遊ぶ分にはサーバーの処理自体には余裕がある、というのが実際に遊んでみての感触です。
その後の更新
- クライアントのバージョンに合わせ、Paper を 1.21.11 → 26.3（build 227） に更新。26.3 は Java 25 が必須のため JDK も 25.0.5 に入れ替え（起動 55.3秒、protocol 777 を確認）
- 監視は systemd サービス化し、サーバーとトンネルの死活監視・再起動・現行アドレスの記録を任せています
- 現在この試行サーバーは停止中です。ワールドデータは保存してあり、同じ手順で再開できます
まとめ
- 2 vCPU・実質空きメモリ 1GB 級の VM でも、Paper サーバーは意外と普通に動く（無人時 RSS 約1GB）
- 効いてくるのはスペックより ネットワークの制約（Java の直接通信、認証、インバウンドなし）のほう
- メモリは「実使用の実測」と overcommit の挙動を押さえれば、上限設定には工夫の余地がある。ただし OOM リスクは常につきまとう
普段は自宅サーバーで運用している身として、「AI エージェントの作業 VM」というおよそゲームサーバー向きでない場所でここまで動いたのは、ちょっとした驚きでした。
未検証事項
- 複数人同時接続時のメモリ・CPU の伸び（実測は1人のみ）
- 長期間（数日単位）常駐時の安定性
参考資料
- Paper 公式サイト: https://papermc.io （2026-10-30 確認）
- playit.gg 公式サイト: https://playit.gg （2026-10-30 確認）
- 実測値は試行時のサーバーログおよび自作ステータスピングの結果より（2026-10-28 実施）