こんにちは、えびかずきです！
今回は、Minecraft Realmsで使っていたワールドを、自宅のWindows PCへ移してみました。統合版のサーバーを立て、PCとNintendo Switchから同じワールドに入れる構成です。
ワールドのコピーだけでなく、Windows起動時の自動起動、別ドライブへのバックアップ、Switchからの接続も用意しました。その後、移行したワールドを残したまま、新しいワールドへの切り替えも行っています。
途中では「Switchは入れるのに、PCだけタイムアウトする」という問題にも遭遇しました。今回は、その対処も含めて紹介します。
この記事は、2026年9月27日〜10月10日に行った移行・接続試験の記録です。10月22日の資料作成時点ではサーバーの稼働とバックアップ先を確認できておらず、現在も連続稼働しているという報告ではありません。
Realmsから何を移すのか
今回移したのは、Realmsに保存していたワールドのデータです。
Realmsのサービスをそのまま自宅へ持ってくるわけではありません。取り出したワールドを、別途用意したサーバーで読み込ませます。サーバーの起動・停止やバックアップも、自宅側で管理する構成になります。
使ったのは、統合版向けのBedrock Dedicated Server、略してBDSです。Windows版の導入方法はMicrosoftのBDS公式ガイドに案内されています。
今回の環境
| 項目 | 作業時の構成 |
|---|---|
| ホストPC | Windows 11 Pro / Core i5-13400F / メモリー16GB |
| サーバー | Bedrock Dedicated Server 1.26.52.3 |
| 参加端末 | Minecraft for Windows、Nintendo Switch |
| ネットワーク | 自宅LAN、ホストPCは5GHz Wi-Fi |
| バックアップ先 | 外付けDドライブ |
これは今回使った環境で、必要最低スペックや同時プレイの性能測定結果ではありません。
ワールドは「元データ・サーバー用・バックアップ」の3つに分ける
まず、Realmsから取り出したワールドをMinecraft for Windowsの保存先で特定しました。移行対象は約248MiB、142ファイルでした。
Realmsからの取得は、所有者アカウントで対象ワールドをダウンロードする流れです。当日の画面操作を一つずつ記録していないため、ここではボタン位置までの説明は省きます。操作時には利用中の版の画面で確認してください。
保存フォルダーの名前は、ゲーム内のワールド名と同じとは限りません。対象を取り違えないように、levelname.txtに書かれた表示名などを確認します。
今回のコピー先は、次のように分けました。
| コピー | 目的 |
|---|---|
| Minecraft for Windows側の元ワールド | 移行元として残す |
BDSのworlds/realm_world |
サーバーから読み込む |
| Dドライブ上の初期バックアップ | 別ドライブへ保管する |
コピーは、ワールドを閉じ、サーバーも停止した状態で行いました。元ワールドを直接サーバーの運用先にはしていません。
さらに、ファイル数・合計サイズ・SHA-256を使った照合で、3つのコピーが一致することを確認しました。SHA-256は、ファイルの内容から計算する値で、コピー前後の内容を照合するために使っています。
ここで確認できるのは、データのコピーが一致していることです。建築物、所持品、エンダーチェスト、ネザーやエンドをゲーム内ですべて点検できたわけではないので、そこは別の確認として残っています。
BDSにワールドを読み込ませる
BDSを専用フォルダーへ配置し、コピーしたワールドをworldsの下に置きました。
Bedrock/
├─ bedrock_server.exe
├─ server.properties
└─ worlds/
└─ realm_world/
├─ level.dat
├─ levelname.txt
└─ db/
そして、server.propertiesの設定で読み込むワールドを指定します。
level-name=realm_world
この値は、worldsの下にあるフォルダー名と一致させます。既存ワールドのコピーとlevel-nameによる指定は、Microsoftの既存ワールド利用手順でも説明されています。
参加者は許可リストに登録し、オンライン認証を有効にしました。
起動後はログのワールド読込とServer started.を確認し、そのうえでクライアントから参加できるかを試しました。起動メッセージだけでは、ゲーム内に入れたかまでは分からないためです。
自動起動とバックアップまで含めた構成
全体の構成は次のようになりました。
BedrockConnectはSwitchから接続先を選ぶ入口です。ワールド本体は自宅PCにあり、別ドライブへバックアップします。
サーバーの実行ファイル、管理資料、バックアップは分けて保存しました。管理用には、次のPowerShellスクリプトを用意しています。
| スクリプト | 役割 |
|---|---|
Run-Server.ps1 |
BDSの実行、ログ保存、管理コマンドの受け渡し |
Start-Server.ps1 |
登録したタスクなどを使った起動 |
Stop-Server.ps1 |
stopを渡し、正常終了を待つ |
Backup-And-Restart.ps1 |
正常停止、バックアップ、世代整理、再起動 |
これらは今回の環境向けに作成したスクリプトで、BDSに標準で付属しているものではありません。
Windowsのタスクには、起動から30秒後のサーバー起動と、毎日午前4時のバックアップを登録しました。バックアップは、稼働中ならいったん正常停止してからワールドをZIPにし、再起動する方式です。そのため、バックアップ時にはプレイできない時間が発生します。
保存対象はserver.propertiesで選択されているワールドで、ワールド別に14世代を残す設計です。PCの電源が入っているだけでなく、スリープしないことと、保存先のドライブが利用できることも運用の条件になります。
また、バックアップに失敗しても、開始前に動いていたサーバーは再起動する設計にしています。サーバーが動いていることと、バックアップが成功していることは別なので、バックアップの結果も確認する必要があります。
SwitchからはBedrockConnectを入口にする
当時のSwitchの通常画面では、任意のサーバーIPを登録できなかったため、BedrockConnectのDNS方式を使いました。
これは、特集サーバーの項目から接続先を選ぶ画面へ入り、そこから自分のサーバーへ移動する仕組みです。Minecraft公式の機能ではなく、コミュニティのプロジェクトです。BedrockConnectのREADMEに仕組みと設定方法が載っています。
当時の手順は次のとおりです。
- SwitchをサーバーPCと同じ自宅ネットワークにつなぐ。
- Switchのインターネット接続設定でDNSを手動にする。
- 優先DNSに
104.238.130.180、代替DNSに8.8.8.8を指定する。 - Minecraftの特集サーバーからLifeboatへ接続する。
- BedrockConnectの「Connect to a Server」で、自宅PCのLANアドレスとポート
19132を指定する。 - 接続先を保存できる項目があれば保存する。
自宅PCのLANアドレスは、それぞれの環境で確認した値を使います。localhostは操作している端末自身を指すので、Switchから別のPCを指定するアドレスにはなりません。
2026年9月27日には、この方法で接続・スポーンを確認できました。私の環境ではThe Hiveを選ぶと通常のHiveへ入ってしまい、Lifeboatが入口になりました。
2026年10月22日に確認したREADMEのDNS手順にも上記のDNSが掲載されていますが、提供状況や対応サーバーは変わる可能性があります。DNS設定はそのインターネット接続全体へ適用されるため、不具合がある場合は自動設定へ戻します。
Switchは入れるのに、PCだけタイムアウトする
接続では、時期の異なる2つの問題がありました。
同じPC上のサーバーへ接続できなかった
9月の移行時には、サーバーとMinecraft for Windowsを同じPCで動かしていて、接続待ちが長く続く問題がありました。
当時はMinecraft for Windowsにループバック通信の除外設定を登録し、クライアントを完全終了して起動し直した後に、localhostで接続できたという記録があります。
これは同じPC内の通信に関する対処です。アプリの配布形式などで対象が変わるため、当時のコマンドをそのまま万能な解決策として扱わず、利用中の環境に合う設定を確認する必要があります。
新ワールドでは同時接続時にタイムアウトした
10月には別の問題が起きました。Switchが新ワールドへ接続している状態で、PCが「外部サーバーに接続中」の後にタイムアウトします。接続先を127.0.0.1からPCのLANアドレスへ変えても改善しませんでした。
調べると、サーバーの参加用HTTPエンドポイントは応答していて、ワールド名と接続人数も返っていました。しかし、ゲームへの参加は成功していません。
今回の構成で使っていたNetherNetは、最初の接続調整とゲーム通信を分けて扱います。MojangのNetherNet資料も参考にしました。HTTPの応答があるだけで、ゲーム通信まで正常とは判断できないわけですね。
当時のUDP割当は、次のように1ポートへ固定されていました。
server-udp-ports=19132:19132
そこで、ポート不足の可能性を考え、次の範囲へ広げました。
server-udp-ports=19132-19141:19132-19141
追加したUDP 19133〜19141は、BDSの実行ファイルに限定し、LANとlocalhostからの受信だけを許可しました。設定を保存し、正常停止・再起動した後、10月10日のログでSwitchとPCの両方の参加・スポーンを確認できました。
この結果から言えるのは、今回の環境では、UDP範囲の変更後に両端末の同時接続を確認できたということです。厳密な比較試験やパケット解析は行っていないため、すべてのタイムアウトの原因がポート不足だとは断定できません。
なお、ここまでの接続確認は自宅LAN内の話です。家庭外から接続する試験やルーターのポート転送完了は確認していません。
旧ワールドを残して、新しいワールドへ切り替える
移行後の10月9日には、新しいワールドを作りました。
採用したのは、1つのBDSが読み込むワールドを切り替える方法です。旧ワールドのフォルダーを消さず、並べて置いておきます。
同時に2つのワールドを動かす構成ではありません。正常停止してから、読み込むフォルダーを切り替えます。
実際には、次の順番で進めました。
- 新しいワールド名のフォルダーが、まだ存在しないことを確認する。
- 設定ファイルとバックアップスクリプトを保存する。
- サーバーを正常停止し、プロセスが終了したことを確認する。
- 旧ワールドをDドライブへコピーし、各ファイルのSHA-256を照合する。
level-nameを新しい名前へ変更する。- バックアップ対象を選択中のワールドに合わせ、サーバーを起動する。
起動ログで、新規ワールドの生成と対象フォルダーの読込を確認しました。
このとき、日次バックアップの対象が旧ワールド名に固定されていたため、level-nameを読む処理へ修正しました。ワールドを切り替えるだけでは、周辺の管理処理まで自動で追従するとは限らない、という点がポイントでした。
旧ワールドへ戻す場合は、サーバーを正常停止してlevel-name=realm_worldへ戻し、再度起動します。旧・新の両フォルダーが残っているので、この設定で切り替えられます。
移行できたことと、これから確認すること
今回の作業では、Realmsから取り出したワールドのコピー照合、BDSへの移行、停止してからのバックアップ試験、PCとSwitchの接続、新ワールドへの切り替えまで確認できました。
ワールドを自宅へ移す作業を通じて、データの置き場所だけでなく、起動・接続・保存をひとまとまりで考える必要があると分かりました。
特に役に立ったのは、元ワールドを残すこと、切り替え前にコピーを照合すること、そしてサーバーの応答と実際のゲーム参加を分けて確認することです。次は、残してあるバックアップから戻せるところまで確かめ、運用手順を整えていきたいと思います。
