本記事では、Ubuntu上でコンテナ管理ツール「Podman」を使い、マインクラフト統合版（Bedrock Dedicated Server）のマルチプレイサーバーを構築する手順を解説します。
本記事で構築するサーバーは「マインクラフト統合版（Bedrock Edition）」専用です。端末ごとの接続可否にご注意ください。
- 標準でそのまま遊べる端末
- Windows PC（統合版）、スマートフォン・タブレット（iOS / Android / Fire OS）
- 標準ではサーバー追加が制限されている端末
- Nintendo Switch、PlayStation 4 / 5、Xbox などの家庭用ゲーム機
※家庭用ゲーム機は各プラットフォームの仕様上、標準画面に外部サーバーのIPアドレスを直接入力する欄が表示されません（公式提携サーバーのみ）。
そのため、構築後の接続テストにはPCやスマートフォンのMinecraftアプリをご用意ください。
（家庭用ゲーム機から参加させたい場合は、構築完了後にDNS設定変更や中継アプリ「BedrockTogether」等の外部ツールを併用する必要があります。）
Podmanとは？
簡単にいうと、Ubuntuの中に「使い捨ての小さな小部屋（独立した環境）」を作ってくれる便利ツールです。
この「小部屋」のことを、専門用語で「コンテナ」と呼びます。
コンテナツールとしては「Docker（ドッカー）」が有名ですが、Podmanは管理者権限（root）を使わず、普段使っている一般ユーザー権限のままで安全に動かせるため、セキュリティ面でも安心してサーバーを運用できるのが大きな特徴です。
なぜPodman（コンテナ）を使うといいの？
Ubuntuでマインクラフト統合版サーバーを動かす方法はいくつかありますが、「Podman（コンテナ）」を使う理由は、圧倒的な手軽さと安全性にあります。
面倒な準備は不要！コマンド1発ですぐに立ち上がる
通常、Ubuntuに直接マイクラサーバーを入れようとすると、公式サイトからzipファイルのダウンロード・解凍・フォルダへ配置・足りないライブラリの追加など、多くの手作業が必要です。
ですが、Podmanを使えば、コマンドを1行実行するだけで必要なプログラムが自動取得され、数分後には友達と遊べるマルチサーバーが完成します。
管理者権限（sudo）を使わないから、安全に運用できる
Podmanは普段使っている一般ユーザー権限のまま動かせる（Rootless）ため、万が一マイクラのプログラムに脆弱性があっても、Ubuntu本体が乗っ取られる危険を防げます。
Ubuntu本体を汚さず、やり直しも一瞬
マイクラサーバーは独立した「コンテナ（専用の小部屋）」の中で動くため、Ubuntu本来のシステム環境を一切汚しません。
もし設定を間違えたりサーバーが壊れたりしても、コンテナを丸ごと削除して作り直すだけで、一瞬で綺麗な初期状態へリセットできます。
マイクラ本体のアップデートも再起動するだけ
通常の手作業アップデートでは、「設定ファイル」や「ワールドデータ」の移行に気を配る必要がありますが、今回使用するコンテナ（itzg/minecraft-bedrock-server）なら、ワールドデータや設定を残したまま、コマンド1つで自動的に最新バージョンへアップデートされます。
ファイアウォール設定（UFWで19132ポート開放）
ここから、「Podman」を利用した統合版マインクラフトサーバー環境の構築を進めていきます。
まずは、外部のクライアント（スマートフォンやPCなど）からサーバーへ接続できるよう、Ubuntuの標準ファイアウォール機能である「UFW」を設定し、統合版に必要な通信ポートを開放します。
Java版で使用する「25565」番ポートとは異なり、統合版では以下のポートを使用します。
- IPv4接続用 : 19132 tcp/udp
- IPv6接続用 : 19133 tcp/udp
バージョン 1.26.51.1 より通信仕様が更新され、従来の「UDP」に加えて「TCP」プロトコルの開放も必要となっています。
ポートの通信許可
以下のコマンドを実行し、必要なポート番号（TCPおよびUDP）を許可します。
# IPv4用ポートの開放（必須） sudo ufw allow 19132/tcp sudo ufw allow 19132/udp # IPv6環境を利用する場合（任意） sudo ufw allow 19133/tcp sudo ufw allow 19133/udp
設定状態の確認
ポート開放ルールが正しく反映されているか、UFWのステータスを確認します。
sudo ufw status | grep -E '(19132|19133)'
出力結果に以下のように「ALLOW」が表示されていれば、OS側のファイアウォール設定は完了です。
19132/udp ALLOW Anywhere 19133/udp ALLOW Anywhere 19132/tcp ALLOW Anywhere 19133/tcp ALLOW Anywhere 19132/udp (v6) ALLOW Anywhere (v6) 19133/udp (v6) ALLOW Anywhere (v6) 19132/tcp (v6) ALLOW Anywhere (v6) 19133/tcp (v6) ALLOW Anywhere (v6)
VPSやクラウドを利用している場合の重要チェック点
ConoHa VPS、Xserver VPS、さくらのVPS、AWSなどのクラウド環境を利用している場合、Ubuntu内部のUFWだけでなく、各社コントロールパネル側のファイアウォール設定でも「19132番のTCP/UDP両方（IPv6利用時は19133番も）」を許可する必要があります。
「UFWを設定したのに外部からサーバーが見つからない・接続できない」というトラブルの大多数は、このクラウド側の二重ファイアウォールによる遮断が原因です。
Podmanのインストールと環境設定
Ubuntuのパッケージ管理システム（apt）を使い、コンテナエンジン「Podman」をインストールします。
Podmanのインストール
リポジトリのパッケージリストを最新化し、Podmanをインストールします。
sudo apt update sudo apt install -y podman
インストール完了後、Podmanのバージョンを表示して正常に導入されたか確認します。
podman -v podman version 4.9.3
データ永続化ディレクトリの作成と権限設定
コンテナの停止・削除やマインクラフトサーバーのバージョンアップ時にも、ワールドデータや設定ファイルを維持できるよう、Ubuntu（ホスト側）のディレクトリへデータを保存（ボリュームマウント）します。
ディレクトリの作成
ユーザのホームディレクトリ配下に、専用のデータ保存用ディレクトリを作成します。
mkdir -p ~/bedrock/data
【重要】データの書き込み権限を設定する（起動エラー防止）
今回動かすマイクラサーバーは、セキュリティを高めるため専用の一般ユーザー権限（UID 1000 / GID: 1000）で動作します。
そのため、先ほど作成したフォルダに対してあらかじめ「マイクラ側から自由にファイルを書き込める権限」を渡しておかないと、起動時に書き込み拒否エラー（Permission denied）でサーバーが異常終了します。
このトラブルを防ぐため、以下のコマンドを実行して、保存フォルダの所有者をマイクラコンテナ用に合わせて変更します。
podman unshare chown -R 1000:1000 ~/bedrock/data
「podman unshare」ってどんなコマンド？
「コンテナの作業部屋」に潜り込んで、管理者権限（sudo）を使わずに、コンテナ専用のファイルやフォルダを安全に操作できるようにするコマンドです。
統合版マインクラフトサーバーのテスト起動
「podman run」コマンドを実行して、統合版マインクラフトサーバーのコンテナを手動でテスト起動します。
podman run -dit \ --name mc-bedrock \ -p 19132:19132/udp \ -p 19132:19132/tcp \ -e EULA=TRUE \ -e VERSION=LATEST \ -v $HOME/bedrock/data:/data \ docker.io/itzg/minecraft-bedrock-server
コマンドオプションの重要ポイント
テスト起動コマンドで使用している各オプションの技術的な役割は以下の通りです。
-
-dit （動作モードの指定）
- d： （デタッチモード）コンテナをバックグラウンドで実行させます。ターミナルを閉じてもサーバーは動き続けます。
- i： （標準入力の維持）コンテナ側の標準入力を開いたまま維持し、キーボードからの入力をコンテナへ送信できるようにします。
- t： （疑似端末の割当）疑似TTYを割り当てます。後述する「podman attach」でサーバーコンソールに接続してコマンドを打つために必要になります。
- –name mc-bedrock コンテナの識別名を「mc-bedrock」に指定します。ログの確認や起動・停止などの操作はこの名前で行います。
- -p 19132:19132/udp ホスト側の19132番ポート（UDP）へのアクセスを、コンテナ内部の統合版サーバーへ転送します。
-
-p 19132:19132/tcp ホスト側の19132番ポート（TCP）へのアクセスを、コンテナ内部の統合版サーバーへ転送します。
バージョン 1.26.51.1 より接続仕様が更新され、従来のUDPに加えてTCPプロトコルも併用されるようになったため、同様に19132番ポート（TCP）を転送します。 - -e EULA=TRUE Mojang公式の「Minecraft使用許諾契約（EULA）」に同意し、サーバーの起動を許可するための設定です。
-
-e VERSION=LATEST
コンテナ起動時に、常に最新版の統合版マインクラフトサーバーを自動取得して起動します。 -
-v $HOME/bedrock/data:/data
ホスト側の「~/bedrock/data」をコンテナ内のデータ領域（/data）へボリュームマウントします。これにより、コンテナを破棄してもワールドデータや設定ファイルがホスト側に残ります。
VERSION=LATESTを設定すると何が自動更新されるのか？
「VERSION=LATEST」を設定しておくと、コンテナの起動・再起動時にスクリプトがMojang公式サイトを自動チェックし、マインクラフト統合版サーバーの本体プログラムを常に最新バージョンへ自動更新してくれます。
そのため、スマホやPC側のマイクラ本体がアップデートされた際も、コンテナの再起動を行うだけで即座に最新バージョンへ追従できます。
一方で、ベースとなるコンテナイメージ自体（OSのセキュリティパッチや起動スクリプトの土台）を最新化したい場合は、「podman pull」や後述する「podman-auto-update」を実行する必要があります。
サーバ起動ログの確認
起動コマンド実行後、正しくマインクラフトサーバーが起動しているかをログで確認します。
以下のコマンドを実行すると、最新のログを表示し続けることが出来ます。
podman logs -f mc-bedrock
ログ表示例
実際のログ表示例です。
$ podman logs -f mc-bedrock
DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=1000 from match path
DEBU[0000] Resolved GID=1000 from match path
Image info: buildtime=2026-09-22T12:05:10.230Z,version=latest,revision=adc2bbf5ffcaf4f1aca9ea8e376ec1fa0fcf91eb
Looking up latest version...
Downloading Bedrock server version 1.26.52.3 ...
Starting Bedrock server...
NO LOG FILE! - setting up server logging...
[2026-10-01 01:46:37:133 INFO] Starting Server
##### 中略 #####
#####################################################
# #
# CREATING VANILLA WORLD #
# #
#####################################################
[2026-10-01 01:46:37:861 INFO] Opening level 'worlds/Bedrock level/db'
[2026-10-01 01:46:37:863 INFO] Accepting clients on [::]:19132
[2026-10-01 01:46:37:918 INFO] Pack Stack - None
[2026-10-01 01:46:38:275 INFO] Signed in to signaling service successfully
[2026-10-01 01:46:39:785 INFO] Waiting for Minecraft services...
[2026-10-01 01:46:39:886 INFO] Server started. # マインクラフトサーバーが起動したログ
[2026-10-01 01:46:39:886 WARN] ================ ALLOW LIST WARNING ===================
[2026-10-01 01:46:39:886 WARN] Allow list is enabled but contains no entries.
[2026-10-01 01:46:39:886 WARN] Use allowlist add <playername> for you and your friends so that they can access the server, or modify allowlist.json manually.
[2026-10-01 01:46:39:886 WARN]
Alternatively, the allow list can be turned off by typing allowlist off or manually toggled in the server.properties file.
[2026-10-01 01:46:39:886 WARN] =======================================================
[2026-10-01 01:46:39:886 INFO] ================ TELEMETRY MESSAGE ===================
[2026-10-01 01:46:39:886 INFO] Server Telemetry is currently not enabled.
[2026-10-01 01:46:39:886 INFO] Enabling this telemetry helps us improve the game.
[2026-10-01 01:46:39:886 INFO]
[2026-10-01 01:46:39:886 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2026-10-01 01:46:39:886 INFO] to the server.properties file in the handheld/src-server directory
[2026-10-01 01:46:39:886 INFO] ======================================================
ログに「Server started.」と表示されていれば、サーバーの起動処理は無事成功です！
ログの表示を終了するには「Ctrl + C」を入力してください。
「ALLOW LIST WARNING」と「TELEMETRY MESSAGE」についての解説
- ALLOW LIST WARNING（参加許可リストの警告）
-
「ALLOW LIST機能が有効化されているが、許可されたプレイヤーがまだ1件も登録されていない」という警告です。
起動自体は成功していますが、このままでは誰もサーバーに入れないので、後述の手順でログインを許可したいユーザを登録するか、ALLOW LIST機能をOFFにする必要があります。 - TELEMETRY MESSAGE（品質データ送信の案内）
-
Mojang公式による品質向上のための匿名データ送信に関する案内です。初期状態では「無効」になっていますが、送信を許可しなくてもサーバーの動作やマルチプレイには一切支障ありませんので、そのまま無視して問題ありません。
自動的に作成されるデータ
初回起動が完了すると、ホスト側のデータ保存領域「~/bedrock/data」へ統合版マインクラフトサーバーの実行ファイルやワールドデータ、設定ファイル等が自動的に作成されます。
ls -F ~/bedrock/data Dedicated_Server.txt development_behavior_packs/ profanity_filter.wlist allowlist.json development_resource_packs/ release-notes.txt bedrock_server-1.26.52.3* development_skin_packs/ resource_packs/ bedrock_server_how_to.html minecraftpe/ server.properties behavior_packs/ packet-statistics.txt treatments/ config/ packetlimitconfig.json world_templates/ data/ permissions.json worlds/ definitions/ premium_cache/
主要なファイル・ディレクトリの役割
展開されたファイルのうち、日常のサーバー管理や設定変更で主に使用する重要項目は以下の通りです。
- server.properties（サーバー基本設定）： ゲームモード（サバイバル/クリエイティブ）、難易度、最大プレイヤー数、ワールドのシード値などを管理する設定ファイルです。
- allowlist.json（ホワイトリスト設定）： サーバーへの参加を許可するプレイヤーを登録・管理するファイルです。
- permissions.json（管理者・権限設定）： オペレーター（OP権限）やビジター権限など、プレイヤーごとの操作レベルを割り当てるファイルです。
- worlds/（ワールドデータ格納ディレクトリ）： ワールドデータが保存されるディレクトリです。
- behavior_packs/ resource_packs/（アドオン導入先）： ビヘイビアーパックやリソースパックを追加してサーバー全体に適用する際に使用します。
設定変更時の注意点
「server.properties」や「allowlist.json」などの設定ファイルをホスト側から直接手動編集する場合は、ファイルの破損や競合を防ぐため、必ずコンテナを停止してから編集・保存してください。
ALLOW LISTに（ホワイトリスト）へのプレイヤー追加
本環境ではセキュリティ保護のため、初期状態で「ALLOW LIST」（ホワイトリスト）機能が有効化されています。
そのため、登録されたプレイヤー以外はサーバー入ることができません。
まずは自分自身が接続テストを行えるようにするため、稼働中のコンテナにアタッチ（内部コンソールへ直接接続）してプレイヤー名を登録します。
マインクラフトサーバーのコンソールへアタッチ（接続）
「podman attach コンテナ名」で、統合版マインクラフトが動作しているコンテナにアタッチ（接続）します。
podman attach mc-bedrock
アタッチ直後はプロンプト（入力欄）が表示されず、画面が止まっているように見えますが、「Enter」 キーを押すと、コマンドエラーのメッセージが表示され入力受付状態であることが確認できます。
# 何も表示されていな状態でEnterキーを押下
[2026-10-05 01:51:04:705 ERROR] Unknown command: . Please check that the command exists and that you have permission to use it.
ALLOW LISTへプレイヤー追加
コンソールにアタッチしたら、「allowlist add “プレイヤー名”」 を実行して接続を許可するプレイヤーを登録します。
ユーザの追加が成功すると、以下のように追加完了メッセージが出力されます。
allowlist add "tamohiko" [2026-10-01 01:49:30:690 INFO] Added tamohiko to the allowlist
コンテナからデタッチ（切断）する方法
プレイヤーの登録が終わったら、サーバーを動かしたまま作業ターミナルへ戻るため「デタッチ」（切断）を行います。
「Ctrl + p」を入力した後に「Ctrl + q」を入力することで、現在接続しているコンソールからデタッチ（切断）することができます。
「Ctrl + c」を入力すると、接続しているコンテナが停止してしまうので注意してください。
クライアントからの接続テスト
サーバーの起動とALLOW LISTの登録が完了したら、手元の端末（スマホ、タブレット、PCなど）のマインクラフト統合版アプリから接続テストを行います。
サーバーの追加
- マインクラフトを起動し、タイトル画面で「プレイ」を選択します。
- 上部のタブから「サーバー」タブを選択します。
- サーバーを追加を選択します。
- 表示された入力欄に、追加するサーバーの情報を入力します。
- サーバー名： 任意の分かりやすい名前（例: My-Server）
- サーバーアドレス： 構築したサーバーのIPアドレス
- ポート： 19132（デフォルトのまま）
- 入力後に「サーバーを追加」または「追加してプレイ」を選択します。
無事にワールドへログインできたら、接続テストは成功です！
テスト用コンテナの停止と削除
接続テストが完了したら、サーバーを24時間安定稼働させるためsystemd（Quadlet）による自動起動・常駐化の作業へ移行します。
systemdの管理下へスムーズに移行するため、手動でテスト起動したコンテナは一度停止して削除します。
テスト用コンテナを残したまま進めると、後ほどsystemdから起動する際に「同名のコンテナがすでに存在する」というエラーが発生してサービスが起動できなくなるため、必ずここで削除しておきます。
# テスト用コンテナの停止 podman stop mc-bedrock # テスト用コンテナの削除 podman rm mc-bedrock
ワールドデータや設定ファイルについて
本環境では、ワールドデータや設定ファイルがすべてホスト側（Ubuntu）の「~/bedrock/data」ディレクトリに永続化（ボリュームマウント）し保存しています。
そのため、コンテナ本体を停止・削除してもワールドデータや設定ファイルが失われることはありません。
「ワールドを初期化して最初からやり直したい」「設定も含めて完全にリセットしたい」という場合は、ホスト側のファイルを直接削除する必要があります。
すべての設定・データを完全初期化する場合
ワールドデータや設定ファイルをリセットしたい場合は、手動で対象のデータを削除してください。
rm -rf ~/bedrock/data/*
ワールドデータのみをリセットする場合（設定は維持）
ALLOW LIST（allowlist.json）やサーバーの設定（server.properties）を残したまま、新しくワールドを新規生成し直したい場合は、ワールドデータが保存されているディレクトリのみを削除します。
rm -rf ~/bedrock/data/worlds/"Bedrock level"
削除後にコンテナを起動すると、新しいシード値でまっさらなワールドが自動生成されます。
systemd（Podman Quadlet）による自動起動・常駐化
テスト起動と接続確認が完了したら、Podmanの推奨方式である「Quadlet（クアドラット）」を使い、OS起動時に自動で統合版マインクラフトサーバのコンテナを起動し常駐するようにサービス化を行います。
Quadlet用ディレクトリの作成
Quadletの設定ファイルを配置するディレクトリを、ユーザーのホームディレクトリ配下に作成します。
mkdir -p ~/.config/containers/systemd/
Quadlet設定ファイル（.container）の作成
作成したディレクトリ内に、コンテナの構成を定義する設定ファイルを作成します。
「ユニット名.container」という命名規則なので、今回は「mc-bedrock.container」として新規作成します。
nano ~/.config/containers/systemd/mc-bedrock.container
設定内容は以下の通りです。
[Unit] Description=Minecraft Bedrock Server (Podman Quadlet) After=network-online.target Wants=network-online.target [Container] Image=docker.io/itzg/minecraft-bedrock-server:latest ContainerName=mc-bedrock PublishPort=19132:19132/udp PublishPort=19132:19132/tcp Volume=%h/bedrock/data:/data Environment=EULA=TRUE Environment=VERSION=LATEST AutoUpdate=registry PodmanArgs=-it [Service] Restart=on-failure RestartSec=10s TimeoutStopSec=60 [Install] WantedBy=default.target
記述後は、保存（Ctrl + O > Enter）して、終了 （Ctrl + X）します。
設定項目のポイント解説
作成した「mc-bedrock.container」内で定義している項目の説明は以下の通りです。
- Image=docker.io/itzg/minecraft-bedrock-server:latest
-
使用するコンテナイメージを完全修飾名（FQIN）で指定します。短縮名を避けることで、初回起動時のレジストリ問い合わせ停止を防ぎます。
- ContainerName=mc-bedrock
-
起動するコンテナ名を指定します。ログの確認やコンソールへのアタッチ時にもこの名前を使用します。
- PublishPort=19132:19132/udp
PublishPort=19132:19132/tcp -
統合版（Bedrock）の標準通信ポート（19132）をコンテナへ転送します。バージョン 1.26.51.1 以降の通信仕様更新に対応するため、UDPとTCPの両方を指定しています。
- Volume=%h/bedrock/data:/data
-
ホスト側のデータ保存先をコンテナ内の /data にマウントします。%h は systemd の指定子（Specifier）であり、実行ユーザーのホームディレクトリ（/home/ユーザー名）へ自動展開されます。
- Environment=EULA=TRUE
-
Mojang公式の「Minecraft エンドユーザー使用許諾契約（EULA）」に同意し、サーバーの自動起動を許可します。
- Environment=VERSION=LATEST
-
コンテナ起動・再起動時にMojang公式サイトを自動チェックし、最新の統合版サーバー公式バイナリを自動取得して立ち上げます。
- AutoUpdate=registry
- コンテナイメージ自体の自動更新設定です。podman auto-update 実行時（またはsystemdタイマー稼働時）にリモートレジストリをチェックし、新しいイメージが公開されていれば自動で再取得してコンテナを再生成します。
- PodmanArgs=-it
-
podman attach でコンソールへ接続してコマンド投入を行えるよう、標準入力の維持（-i）と疑似端末の割り当て（-t）を付与します。
- Restart=on-failure
-
コンソールからの「stop」コマンド等で正常終了（終了コード0）した場合は停止したまま維持し、サーバークラッシュ等の異常終了時のみ自動で再起動します（意図的なメンテナンス時の再起動ループを防止します）。
- RestartSec=10s
-
異常終了後、10秒間待機してから再起動します。連続クラッシュ発生時の高負荷な無限ループを防ぎます。
- TimeoutStopSec=60
-
サービス停止シグナル（SIGTERM）送信後、プロセスが安全に終了するまで最大60秒待機します。ワールドデータのディスク書き込み（チャンクセーブ）完了を待たずに強制終了（SIGKILL）されることによるデータ破損を防ぎます。
- WantedBy=default.target
-
ユーザーログイン時（Linger有効時はOS起動時）に自動的にサービスを開始するためのターゲット依存関係を指定します。
ログインなしで常時起動させるための必須設定（Lingerの有効化)
一般ユーザー権限でコンテナを動かす場合、「systemd」の標準仕様では「該当ユーザーがログインしていない状態では、そのユーザーのサービスは起動されない」という仕様になっています。
そのため、Quadletで自動起動設定を行っていても、Ubuntuにユーザがログインしなければ起動しません。
この条件をクリアするために、以下のコマンドで事前に「Linger（リンガー）」を有効化して置く必要があります。
loginctl enable-linger $USER
Linger 設定の反映確認
設定が正しく反映されたか確認するため、以下のコマンドを実行します。
loginctl show-user $USER --property=Linger Linger=yes
「Linger=yes」と表示されれば設定完了です。
これで、Ubuntuにログインしていない状態でも、電源が入った瞬間からバックグラウンドでマイクラサーバーが起動し、いつでもクライアントから接続できるようになります。
コンテナの開始と自動起動設定
作成した「mc-bedrock.container」ファイルを「systemd」に認識させ、サーバーコンテナの起動と自動起動の有効化を行います。
# Quadlet設定を再読み込み（mc-bedrock.service が自動生成されます） systemctl --user daemon-reload # 起動 systemctl --user start mc-bedrock.service
systemctl enable が不要な理由
「mc-bedrock.container」ファイル内の[Install]セクションに 「WantedBy=default.target」を記述しているため、「daemon-reload」の実行時に「Quadlet」ジェネレーターが自動起動用のリンクまで自動作成してくれます。
そのため、通常必要な「systemctl –user enable」コマンドを実行する必要はありません。
動作確認
「systemctl –user status mc-bedrock」で、サービスが正常に起動し稼働中「active (running)」になっているか確認します。
systemctl --user status mc-bedrock
● mc-bedrock.service - Minecraft Bedrock Server (Podman Quadlet)
Loaded: loaded (/home/tamohiko/.config/containers/systemd/mc-bedrock.container; generated)
Active: active (running) since Fri 2026-10-02 15:38:44 JST; 24h ago
Main PID: 3036 (conmon)
##### 省略 #####
「Active: active (running)」と表示されていれば、「systemd」配下での常駐化および自動起動の登録は完了です。
ホストを再起動しての動作確認
すべての設定と動作確認が完了したら、最後にホストOS（Ubuntu）自体を再起動し、「ログイン操作なしでコンテナが自動起動すること」および「クライアントから問題なく接続できること」を検証します。
# ホストサーバーの再起動 sudo reboot
ホストOS（Ubuntu）の再起動後、SSHやコンソールへのログインを行わない状態で、スマホやPCなどのマインクラフト統合版クライアントから接続を試みてください。
ゲーム画面からワールドへ正常に参加できれば、「Quadletによるサービス自動起動」と「Linger」が機能していることが確認できます。
もし接続できない場合は、SSHでログインした後に以下のコマンドを実行し、サービスの稼働状態や起動ログを確認してください。
# サービスの稼働ステータス確認 systemctl --user status mc-bedrock.service # 起動ログの確認 journalctl --user -u mc-bedrock.service -e
サーバーの更新・メンテナンス方法
マインクラフト統合版の運用において必要となる、サーバーコンソールでのコマンド操作、日常の保守（起動・停止・再起動）、および本体アップデートの手順を解説します。
マインクラフトサーバーのコンソールに接続
ホワイトリストの追加や権限付与など、ゲーム内サーバーコマンドを実行するには、稼働中のコンテナに「podman attach コンテナ名」でアタッチ（接続）してコンソール画面を呼び出します。
# コンテナのコンソールに接続 podman attach mc-bedrock
アタッチ直後は画面に何も表示されない場合があります。キーボードの「Enter」キーを1回押すと、入力受付状態であることが確認できます。
# 何も表示されていな状態でEnterキーを押下
[2026-10-05 01:51:04:705 ERROR] Unknown command: . Please check that the command exists and that you have permission to use it.
エラーメッセージが表示されて、コマンド入力が受付状態であることが確認できます。
よく使うサーバーコマンドの実行例
コンソール接続中は、スラッシュ「/」を付けずに直接コマンドを入力します。
# 参加許可リスト（ALLOW LIST）にプレイヤーを追加 allowlist add "プレイヤー名" # 指定プレイヤーに管理者権限（OP権限）を付与 op "プレイヤー名" # 現在ログイン中のプレイヤー一覧を表示 list # サーバーを安全にセーブしてシャットダウン stop
コンソールからのデタッチ（切断）
アタッチしているコンソールからデタッチ（切断）するには、「Ctrl + p」と「Ctrl + q」を続けて入力します。
「Ctrl + c」を入力してしまうと、コンテナ自体が終了してしまうので注意してください。
統合版マインクラフトサーバー本体のバージョンアップ（更新手順）
統合版マインクラフトの本体アップデートが配信された際は、サービス（コンテナ）を再起動するだけで更新作業が完了します。
Quadlet設定ファイルに指定した「Environment=VERSION=LATEST」により、起動時にコンテナ内部のスクリプトが公式サイトを自動チェックし、最新バージョンの公式バイナリを取得して立ち上げます。
# サーバーの再起動（最新バージョンが自動チェック・適用されます） systemctl --user restart mc-bedrock.service
バージョンアップ結果の確認
再起動後、正しくバージョンアップが完了してサーバーが起動したかをログで確認します。
# リアルタイムログの確認（終了は Ctrl + C） journalctl --user -u mc-bedrock.service -f
※「podman logs -f mc-bedrock」でもログをリアルタイムできます。
コンテナイメージ自体の更新（podman auto-update）
マインクラフトサーバー本体の更新とは別に、ベースとなるコンテナイメージを最新化する場合は、以下のコマンドを実行します。
# Quadletで AutoUpdate=registry を設定した全コンテナのイメージを一括更新 podman auto-update
新しいイメージがレジストリ（Docker Hub）に公開されていた場合、自動でダウンロードされ、コンテナが安全に再生成・再起動されます。
複数コンテナ運用時の注意点
「podman auto-update」は、同一ユーザーが管理し自動起動の設定（Quadlet）で「AutoUpdate=registry」（または同等のラベル）が設定されているすべてのコンテナを対象に一括更新を行います。
勝手に再起動させたくないコンテナが存在する場合は、あらかじめ設定から「AutoUpdate=registry」の記述を外してください。
日常運用で使う基本コマンド一覧
日常の管理で使用するコマンドをまとめました。
- サーバーの起動：systemctl –user start mc-bedrock.service
- サーバーの停止：systemctl –user stop mc-bedrock.service
- サーバーの再起動：systemctl –user restart mc-bedrock.service
- 稼働ステータス確認：systemctl –user status mc-bedrock.service
-
リアルタイムログ監視：podman logs -f mc-bedrock （終了は「Ctrl + c）
※ systemd 側の起動・停止プロセスを含めて追尾する場合はjournalctl –user -u mc-bedrock.service -f も利用可能
コンテナイメージ更新の完全自動化（podman-auto-update）
「.container」設定ファイルに「AutoUpdate=registry」を記述している場合、Podman標準の自動アップデート機能である「podman-auto-update」を活用して、深夜などにイメージの更新とコンテナ再起動を完全自動化できます。
これにより、管理者が手動でコマンドを実行しなくても、コンテナのベースOSへセキュリティパッチや起動スクリプトの修正を常に最新・安全な状態に保てます。
「podman auto-update」は、同一ユーザーが管理し自動起動の設定（Quadlet）で「AutoUpdate=registry」（または同等のラベル）が設定されているすべてのコンテナを対象に一括更新を行います。
勝手に再起動させたくないコンテナが存在する場合は、あらかじめ設定から「AutoUpdate=registry」の記述を外してください。
ユーザータイマー（podman-auto-update.timer）の有効化
一般ユーザー権限で動作させているため、「systemctl」に「–user」オプションを付与してタイマーの有効化を行い、「–now」でタイマーを起動させます。
systemctl --user enable --now podman-auto-update.timer
タイマーの動作状況・次回実行日時の確認
タイマーが正常にスケジュールされているか確認します。
systemctl --user list-timers podman-auto-update.timer
実行結果例
出力結果の「NEXT」列に次回実行予定時刻（デフォルトは毎日深夜〜早朝のランダムな時間帯）が表示されていれば、スケジュール登録は完了です。
$ systemctl --user list-timers podman-auto-update.timer NEXT LEFT LAST PASSED UNIT ACTIVATES Fri 2026-10-02 00:03:40 JST 2h 10min - - podman-auto-update.timer podman-auto-update.service 1 timers listed. Pass --all to see loaded but inactive timers, too.
実行時間を変更したい場合
「podman-auto-update.timer」の初期設定では、実行時刻が深夜〜早朝のランダムな時間帯（分散実行）に設定されています。
プレイヤーが確実にログアウトしている深夜の決まった時間（例: 午前4時00分）に固定したい場合は、「systemctl edit」コマンドを使用してタイマーのオーバーライド（設定の上書き）を行います。
タイマー設定の編集画面を開く
以下のコマンドを実行し、「systemd」の設定上書き用エディタ（ドロップインファイル）を開きます。
systemctl --user edit podman-auto-update.timer
スケジュールの上書き内容を記述
エディタが開いたら、コメント行「### Anything between here…」と「### Edits below this comment…」の空行部分に以下の設定を追記します。
[Timer] OnCalendar= OnCalendar=*-*-* 04:00:00 Persistent=true
【技術メモ：OnCalendar= を空行で指定する理由】
systemdの仕様上、OnCalendar=を一度空文字で宣言することで、パッケージ標準で組み込まれているデフォルトスケジュールを一旦リセット（消去）できます。その上で新しい時刻（04:00:00）を定義することで、二重実行を防ぎます。
エディタ内の記述位置イメージ
追記する場所は、以下のとおりです。
### Editing /home/tamohiko/.config/systemd/user/podman-auto-update.timer.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Timer]
OnCalendar=
OnCalendar=*-*-* 04:00:00
Persistent=true
### Edits below this comment will be discarded
### /usr/lib/systemd/user/podman-auto-update.timer
# [Unit]
# Description=Podman auto-update timer
#
##### 省略 #####
自動更新時の動作フローと注意点
運用上のトラブルを防ぐため、完全自動化（podman auto-update）における内部動作フローと、知っておくべきリスク・フェイルセーフ仕様を把握しておきましょう。
- イメージに変更がない場合は再起動しない
-
タイマー実行時、Podmanはリモートのコンテナレジストリ（Docker Hub）をチェックします。新しいイメージがプッシュされていない場合は何もせず終了するため、無駄なサーバー切断は発生しません。
- 深夜プレイ中の切断リスク
-
新しいイメージが検知された場合、コンテナの再作成と再起動が自動で走ります。マルチプレイのコアタイム（深夜帯など）にアップデートが重なると、ログイン中のプレイヤーが一時的にサーバーから切断される点に留意してください。
- ワールドデータの安全性
-
Quadlet 設定ファイル（mc-bedrock.container）で指定した「TimeoutStopSec=60」が機能するため、自動停止時も即座に強制終了されることはありません。ワールドデータをセーブするまで最大60秒間待機するため、データ破損のリスクを最小限に抑えられます。
- 自動ロールバック機能（安心設計）
-
更新後の新しいイメージに不具合がありコンテナの起動に失敗した場合、「Podman」は自動的にアップデートを中断し、直前の正常に動作していた旧イメージ・旧コンテナへ自動でロールバック（巻き戻し）してサービスを復旧させます。
手動更新したい場合（即時更新）
深夜の定期実行タイマーを待たずに、今すぐイメージ更新を行いたい場合の手順です。
マルチプレイ中にコンテナが意図せず再起動してプレイヤーが切断される事故を防ぐため、まずは影響のない「事前確認（ドライラン）」から実行することを強く推奨します。
更新があるかの事前チェック（ドライラン）
「–dry-run」オプションを付与してコマンドを実行すると、コンテナの停止や再起動を行わずに「リモートレジストリ（Docker Hub）に新しいイメージが来ているか」だけを安全に確認できます。（コンテナは停止・再起動しません）
podman auto-update --dry-run
ターミナルに以下のような一覧が表示されるので、一番右の「UPDATED」列を確認してください。
$ podman auto-update --dry-run UNIT CONTAINER IMAGE POLICY UPDATED mc-bedrock.service 87d5d276dfb6 (mc-bedrock) docker.io/itzgminecraft-bedrock-server:latest registry false
- false： 現在の手元のイメージが最新です（更新なし）。
- pending： 新しいイメージが配信されています（更新可能）。
手動で更新を実行する方法
ドライランで更新（pending）が検知されて、今すぐ強制的に更新処理を行いたい場合は、以下のコマンドを実行します。
podman auto-update
新しいイメージが存在する場合は、イメージのダウンロード（pull）後に古いコンテナが安全に停止され、最新イメージで自動的に再起動します。
$ podman auto-update Trying to pull docker.io/itzg/minecraft-bedrock-server:latest... Getting image source signatures Copying blob 97cae594208e skipped: already exists Copying blob 91877a838f71 skipped: already exists Copying blob c5dbc4329c2c skipped: already exists Copying blob 4f4fb700ef54 skipped: already exists Copying blob 47778eeb876f skipped: already exists Copying blob 4ff3f2b184ad done | Copying blob cdd32a6b8b95 done | Copying blob 2e5f2a392302 done | Copying blob 2c2c93581b8b done | Copying blob 6eefb2f5d3e9 skipped: already exists Copying blob 869fa0c7e79e done | Copying blob fabcaa7e1183 skipped: already exists Copying blob 6f7010cf316b done | Copying blob e4b73653d444 done | Copying config 6d8e01c51a done | Writing manifest to image destination UNIT CONTAINER IMAGE POLICY UPDATED mc-bedrock.service 9598a26a0472 (mc-bedrock) docker.io/itzg/minecraft-bedrock-server:latest registry true
更新が完了後には、以下のコマンドでコンテナが正常に再起動しているか確認してください。
「Active: active (running)」と表示され、稼働時間（起動経過秒数）がリセットされていれば正常に再生成されています。
systemctl --user status mc-bedrock.service
新しいイメージがない場合の挙動
ローカルのイメージがすでに最新である場合は、「UPDATED」列に「false」が表示されサーバープロセスの切断やコンテナ再起動を起こすことなく安全にコマンドを終了します。
$ podman auto-update UNIT CONTAINER IMAGE POLICY UPDATED mc-bedrock.service 87d5d276dfb6 (mc-bedrock) docker.io/itzg/minecraft-bedrock-server:latest registry false
コメント