マイクラ「無効なプレイヤーデータです」の対処｜Java版・Modサーバー

マイクラJava版で「無効なプレイヤーデータです」「無効なプレーヤーデータ」やInvalid player dataが出る場合は、先に発生時刻のログと、Minecraft・Modの構成を確認してください。表示文だけを根拠にplayerdataを消すと、持ち物や位置を失う可能性があります。ワールドを保管したうえで、更新による不整合と対象プレイヤーの保存データを順に切り分けます。

最初に確認すること：誰が、どのワールドで入れないか

発生する条件	次に比べるもの
自分だけが既存サーバーに入れない	同じ配布版のクライアント、対象UUID、参加時刻のサーバーログ
複数人が同じ更新後に入れない	サーバー側の変更、Mod依存関係、対応バージョン
古いワールドだけ開けず新規ワールドは開ける	ワールド保存データと更新前バックアップ。コピーで調査
新規ワールドでも失敗する	構成・Java・Modの起動エラー。元ワールドのファイル削除を先にしない

これは調査順を決めるための比較で、各条件だけで原因を断定するものではありません。他人が運営するサーバーでは利用者がサーバーのplayerdataを直せないため、管理者へ発生日時、プレイヤー名、バージョン、直前の変更を伝えます。

1. エラーの前後をログで確認する

Forge公式FAQでは、公式ランチャーの「起動構成（Installations）」でForge構成のフォルダーを開き、logs内のdebug.logを確認する手順を案内しています。crash-reportsがない場合でもdebug.logが調査に使えます。専用サーバーを使う場合は、管理者が参加時刻に対応するサーバー側ログも確認してください。

1. 参加を試した日時と、画面に出たエラー全文を記録する。
2. 該当時刻のログで、切断文の前に出た例外・原因行、関係するMod名を読む。最後の切断文だけを切り取らない。
3. Minecraft、Forgeなどのローダー、Modパックの版、変更したModや設定を一覧にする。
4. 相談時は原因行と前後の文脈を添える。公開するログには接続情報や個人情報が含まれていないか確認する。

「無効なプレイヤーデータ」と出ても、ファイル破損が確定したわけではありません。Mojangの25w42a修正一覧には、効果が付いたワールドの読み込み時にInvalid player dataが出る不具合MC-302672の修正例があります。これはそのテスト版の記録で、すべての版の解決策ではありません。手元の版とログに合う不具合かを確認し、修正例だけを理由に本番ワールドをスナップショットへ移さないでください。

2. Minecraft・Forge・Modを配布構成に合わせる

Modパックでは、サーバー配布元が指定したMinecraft、ローダー、Modパックの版を使います。個々のModを一斉に最新版へ変えるのではなく、対応する組み合わせへ戻すか、配布元が確認した更新へ揃えます。ForgeのMod定義にはMinecraftやForgeなどの依存関係と対応バージョン範囲があり、「新しいほど互換性が高い」とは限りません。

クライアントと専用サーバーへ、すべて同じModを無条件にコピーする方法も避けます。Forgeのクライアント/サーバー解説では、クライアント専用クラスを専用サーバーの共通処理で読み込むとクラッシュすることを説明しています。ログにクライアント専用クラスやDEDICATED_SERVERの不一致がある場合は、そのModの提供元で導入対象と対応版を確認します。それを見ずに、エラー文とMod名だけで削除対象を決めないでください。

Javaも、使用しているMinecraftとローダーが必要とするメジャー版を選びます。たとえばMojangの1.20.5リリース情報はJava21への変更を明記しています。これはすべての旧版・新しい版にJava21を指定する意味ではありません。配布パックの要件と、実際の起動設定で使うJavaを比べます。

3. 変更前にワールド全体をバックアップする

復旧の調査では、まずゲームまたはサーバーを正常終了し、保存が終わってから別の場所へコピーを保管します。専用サーバーならワールドだけでなく、ローダー/Mod、設定、必要なプラグインやデータも戻せる構成で残します。Paperの更新手順もワールド、サーバー設定、プラグイン設定/JARの保管と、稼働中のJAR差し替えを避けることを案内しています。Forgeなどでは、その構成に対応したファイルも保管してください。

1. 現在の状態を日時付きで保存し、更新前に正常だったバックアップも残す。現在のコピーで上書きしない。
2. 調査用コピーを別フォルダーへ用意し、同じ版と構成で再現を確認する。
3. シングルプレイは対象ワールドだけでなく、使っている構成・Mod・設定の場所も記録する。
4. Modを外す実験やNBT編集はコピーで行い、既存ワールドを本番のまま読み込んで保存しない。

4. playerdataの復元は、対象と失うデータを確認してから

サーバーの保存形式の例として、Paper API 1.20.6のsaveData/loadDataは、ワールドのplayerdata内にUUID.datとして位置、体力、インベントリ、移動などを保存/読み込みすると説明しています。そのため「参加できれば成功」としてファイルを削除するだけでは、元のプレイヤー状態を保持できたことになりません。Mod独自の保存データが別にある場合も、提供元の説明を確認します。

対象のデータが原因とログで絞れた場合は、管理者が正しいUUIDとワールドを確認し、停止中の調査用コピーで、正常だったバックアップからの復元を検討します。元ファイルを別の場所へ退避し、戻した時点以降の持ち物・位置などが巻き戻ることを本人と確認します。全員のplayerdataを消す操作や、ユーザー名だけから推測したファイルの上書きは避けます。

バックアップがなく、初期状態からの再参加を試す必要がある場合でも、最初に元データを保管し、失われる状態を理解したうえでコピー側で確認します。入れた後に元のインベントリ、装備、位置やModの状態を比べてください。シングルプレイや独自サーバーでは保存の扱いが異なるため、Paperのパス例をすべての環境へ当てはめたり、level.datを丸ごと削除したりしないでください。

再インストールとModの全削除を先に行わない

ゲームが起動して特定ワールドへの参加時だけ失敗するなら、ランチャーの修復や再インストールだけでサーバー側の保存データが直るとは限りません。新規の別構成で起動できるか比べ、元のsavesやModパックを残したまま調査します。「ランチャーのゲームキャッシュを消せば解決」といった共通の操作を前提にせず、実際に使うランチャーの公式手順を確認してください。

復旧後の確認と相談時に添える情報

再参加できたことと、元の持ち物・位置・Modの状態を保持できたことは別々に確認してください。一度正常終了して入り直し、対象プレイヤーのログに同じ例外が残らないかも確認します。コピーで直った変更だけを、本番のバックアップを保管してから反映します。

原因が絞れない場合は、Minecraft/ローダー/Modパックの版、実行するJava、失敗した日時、対象ワールドだけか、直前の変更、該当ログとバックアップの有無をまとめて配布元や管理者へ伝えます。変更前へ戻す場合は、ワールドと構成を対応する時点の組み合わせで扱い、調査で退避した元データも残してください。