この記事はマイクラJava版の
/jfrコマンド解説です
統合版（Bedrock Edition）では使えないコマンドなので注意してください
サーバーやワールドが重い原因を調べたい方向けに、使い方から確認ポイントまでまとめます
こんにちは。ゆずかきです。
マイクラJava版で遊んでいると、たまにこんなことありませんか？
「ワールドが急にカクつく」
「サーバーのTPSが落ちている気がする」
「チャンク生成の時だけ重いけど、原因が分からない」
「MODを入れたら重くなった気がするけど、感覚だけでは判断できない」
こういう時に役立つのが、Java版に用意されている /jfr コマンドです。
/jfr は、マイクラの動作状況を Java Flight Recorder（JFR）形式のファイルとして記録するためのコマンドです。
普通のサバイバル攻略ではあまり使わない少し技術寄りのコマンドですが、サーバー運営・MOD環境・重いワールドの調査ではかなり便利です。
この記事では、マイクラJava版の /jfr コマンドについて、
/jfrコマンドで何ができるのか/jfr startと/jfr stopの使い方- 記録ファイルがどこに保存されるのか
- どんな時に使うと役立つのか
- 初心者さんが勘違いしやすい注意点
このあたりを、できるだけ自然に分かるように整理していきますね。
※本記事はマイクラJava版向けです。
※ゲーム内の仕様については、英語版Minecraft Wiki・Minecraft公式リリースノート・Java Flight Recorder関連ドキュメントを参考にしています。
※マイクラJava版1.18以降で追加されたコマンドで、1.21.11時点の情報も含めて整理しています。
目次
1. jfrコマンドとは
2. jfrコマンドで記録できる主な内容
3. jfrコマンドを使うための条件
4. jfrコマンドの構文と使い方
5. 実際の記録手順：重い場面を録画する感覚で使う
6. JFRファイルの保存場所と確認方法
7. 記録ファイルはどうやって見る？
8. どんな場面でjfrコマンドを使うべきか
9. jfrコマンドを使う時の注意点
10. 1.21.11以降で見るべき変更点
11. よくある失敗と対処法
12. まとめ
13. 引用・参考文献
この記事で分かること
・マイクラJava版の/jfrコマンドの使い方
・性能記録ファイルの作り方と確認方法
・ワールドやサーバーが重い時に見るべきポイント
1. jfrコマンドとは
/jfr コマンドは、マイクラJava版の動作状況を Java Flight Recorder という仕組みで記録するためのコマンドです。
名前だけ見るとかなり難しそうですが、マイクラ目線で言えば、
「ゲームが重くなった時に、内部で何が起きていたかを記録するコマンド」
くらいに考えると分かりやすいです。
例えば、サーバーで急にラグが出た時、普通はプレイヤー側から見ても、
- エンティティが多いのか
- チャンク生成が重いのか
- ネットワークが詰まっているのか
- メモリやGCが原因なのか
- MODやデータパックの処理が原因なのか
このあたりは、正直見ただけでは分かりません。
そこで /jfr start で記録を開始し、重い場面を再現してから /jfr stop で止めると、.jfr 形式の性能記録ファイルが作られます。
このファイルをあとから専用ツールで見ることで、どの処理に時間がかかっていたのかを調べる材料になります。
ただし、ここで大事なのは、/jfr は「重さを直すコマンド」ではないということです。
/kill や /tp のようにゲーム内へ直接変化を起こすコマンドではなく、原因調査用の記録コマンドです。
ワールドを軽くする魔法ではないので、そこは最初に押さえておきましょうね。
2. jfrコマンドで記録できる主な内容
/jfr コマンドで記録される内容には、通常のJavaアプリケーションとしての情報に加えて、マイクラ独自のイベントも含まれます。
公式リリースノートや1.21.11時点の実装で確認できる代表的なイベントは、次の通りです。
| イベント名 | 見られる内容 | 使いどころ |
|---|---|---|
| minecraft.ServerTickTime | サーバー側の平均ティック時間 | TPS低下・サーバーラグの確認 |
| minecraft.ChunkGeneration | チャンク生成の各段階にかかった時間 | 新規探索時の重さ確認 |
| minecraft.PacketReceived / minecraft.PacketSent | 通信パケットの受信・送信 | マルチサーバーの通信負荷確認 |
| minecraft.NetworkSummary | 接続ごとの通信量やパケット数の概要 | 通信量が増えている時の確認 |
| minecraft.LoadWorld | ワールド初期読み込み時間 | ワールド起動が遅い時の確認 |
| minecraft.ClientFps | クライアント側FPS関連の記録 | 1.21.11以降の描画負荷確認 |
ここで特に見る機会が多いのは、ServerTickTime と ChunkGeneration です。
サーバーが重い時は「今、何が重いのか」を切り分けるのが大事です。
例えば、村人交易所・モンスタートラップ・ホッパー大量設置・新規チャンク探索・MOD処理など、重くなる原因は色々あります。
/jfr で記録を取ると、少なくとも「感覚だけで判断する状態」からは一歩抜け出せます。
もちろん、JFRファイルを読むには多少の慣れが必要です。
ただ、サーバー運営をしている方や、重いワールドを本気で改善したい方なら、覚えておく価値は十分あります。
3. jfrコマンドを使うための条件
/jfr コマンドは、誰でもそのまま使えるコマンドではありません。
実行には 権限レベル4 が必要です。
マイクラ的に言うと、かなり強い管理者向けコマンドですね。
シングルプレイで使う場合
シングルプレイの場合は、チートが有効なワールドで使えます。
すでに作成済みのサバイバルワールドでチートをオフにしている場合は、LANに公開して一時的にチートを許可する方法もあります。
手順としては、
- Escキーでメニューを開く
- 「LANに公開」を選ぶ
- 「チートの許可」をオンにする
- LANワールドを開始する
- チャット欄で
/jfr startを実行する
という流れです。
ただし、LAN公開でチートを有効化する方法は、ワールドを開いている間だけの一時的なものです。
普段チートなしで遊んでいるワールドなら、記録が終わったら一度ワールドを閉じればOKです。
マルチサーバーで使う場合
マルチサーバーで使う場合は、OP権限が必要です。
特に /jfr は権限レベル4のコマンドなので、普通のプレイヤー権限では使えません。
サーバー管理者であれば、コンソールや権限設定から実行できる環境を整えておきましょう。
注意！
レンタルサーバーやホスティング環境によっては、ファイル保存場所へのアクセスが制限されている場合があります。
/jfr stopまで成功しても、あとから.jfrファイルを取り出せないと分析できないので、事前にファイルマネージャーやFTPでdebugフォルダへアクセスできるか確認しておくと安心です。
4. jfrコマンドの構文と使い方
/jfr コマンドの構文は、かなりシンプルです。
/jfr start
/jfr stop
基本はこの2つだけです。
/jfr start
/jfr start は、JFRプロファイリングを開始するコマンドです。
実行すると、マイクラの動作記録が始まります。
/jfr start
使い方としては、重さを調べたい作業をする直前に実行します。
例えば、
- 新しい地形をエリトラで高速探索する前
- 大量の村人がいる交易所へ近づく前
- モンスタートラップを動かす前
- サーバーでラグが出始めたタイミング
- MOD装置を動かす直前
こういうタイミングで開始すると、原因を追いやすいです。
/jfr stop
/jfr stop は、JFRプロファイリングを停止して、記録ファイルを書き出すコマンドです。
/jfr stop
記録を止めると、.jfr ファイルと、概要をまとめたJSONレポートが debug フォルダ側に作られます。
すでに記録中に /jfr start した場合
すでにJFR記録が始まっている状態で、もう一度 /jfr start を実行すると失敗します。
これは仕様です。
1回の記録は、
/jfr start
で始めて、
/jfr stop
で終わらせる、という1セットで考えましょう。
記録していない時に /jfr stop した場合
逆に、記録が始まっていない状態で /jfr stop を実行しても失敗します。
これも仕様です。
エラーが出てもワールドが壊れるわけではないので、慌てなくて大丈夫です。
5. 実際の記録手順：重い場面を録画する感覚で使う
/jfr は、使うタイミングがかなり大事です。
何も起きていない平和な拠点で10分間記録しても、「特に重くない時のデータ」しか取れません。
調べたいのは、あくまで 重くなった瞬間のデータです。
筆者としては、動画を録画するような感覚で使うのが分かりやすいと思います。
1. 重くなる状況を決める
まずは、何を調べたいのか決めます。
例として、
- エリトラで新規チャンクを読み込むとカクつく
- 村人交易所へ近づくと重い
- ゴーレムトラップ周辺でサーバーが止まりがち
- 大量のホッパーを置いた倉庫だけ重い
- MOD装置を動かすとTPSが落ちる
このように「重くなる場面」を先に決めておきましょう。
2. /jfr start で記録開始
次に、重くなる場面へ入る直前でコマンドを実行します。
/jfr start
例えば、新規チャンク探索が重いなら、探索を始める直前。
村人交易所が重いなら、交易所へ近づく前。
モンスタートラップが重いなら、トラップを稼働させる前です。
3. 重い動作を再現する
記録を開始したら、実際に重い動作を再現します。
- エリトラで飛ぶ
- トラップを稼働させる
- 交易所へ近づく
- 大量のエンティティがいる場所へ移動する
- サーバーでラグが出る作業をしてもらう
ここで大事なのは、関係ない作業をあまり混ぜないことです。
例えば、チャンク生成の重さを調べたいのに、同時に大量のTNTを爆破したり、村人交易所へ移動したりすると、あとから見た時に原因が混ざって分かりづらくなります。
4. /jfr stop で記録終了
重い場面を数十秒〜数分ほど記録したら、停止します。
/jfr stop
これで記録ファイルが出力されます。
記録時間の目安
初心者さんが最初に使うなら、記録時間は 30秒〜3分くらいで十分です。
長く記録しすぎると、ファイルサイズが大きくなり、あとから確認する時も大変です。
もちろん、サーバーで不定期に起きるラグを追う場合は長めに取ることもありますが、最初は短い記録で慣れるのがおすすめです。
体験ベースの考え方
/jfrは「常に長時間回しておけば良い」というより、重い場面を狙って記録する方が扱いやすいです。
特に個人ワールドや小規模サーバーなら、原因候補を1つずつ分けて記録した方が、後から見直しやすいです。
6. JFRファイルの保存場所と確認方法
/jfr stop で記録を終了すると、ゲームディレクトリ内の debug フォルダに記録ファイルが作成されます。
環境によってゲームディレクトリは変わりますが、通常のランチャー構成なら、おおよそ次の場所です。
| 環境 | 代表的な場所 | 補足 |
|---|---|---|
| Windows | %appdata%\.minecraft\debug | 通常ランチャーの場合 |
| macOS | ~/Library/Application Support/minecraft/debug | 通常ランチャーの場合 |
| Linux | ~/.minecraft/debug | 通常ランチャーの場合 |
| サーバー | サーバーフォルダ内の debug | 構成により異なります |
注意点として、Prism Launcher、MultiMC、CurseForge、Modrinth Appなどの別ランチャーを使っている場合は、ゲームディレクトリが通常の .minecraft ではないことがあります。
その場合は、ランチャー側の「フォルダを開く」「インスタンスフォルダを開く」などから、対象インスタンスの debug フォルダを確認してください。
出力されるファイル
出力される主なファイルは、次のようなものです。
.jfrファイル- 概要JSONレポート
- ログ側に出るサマリー情報
一番重要なのは .jfr ファイルです。
これは専用ツールで開くための記録本体です。
JSONレポートは概要確認に便利ですが、細かく見るなら .jfr ファイルを使います。
7. 記録ファイルはどうやって見る？
.jfr ファイルは、普通のテキストファイルのようにメモ帳で開いて読むものではありません。
専用ツールで開いて確認します。
代表的なのは、JDK Mission Control（JMC） です。
JMCは、JFRファイルを見やすく分析するためのツールです。
CPU、メモリ、GC、スレッド、イベントなど、Javaアプリケーションの内部情報を画面上で確認できます。
また、JDKに含まれる jfr コマンドを使えば、.jfr ファイルの概要確認やイベントの出力もできます。
ただし、初心者さんが画面で確認するなら、まずはJDK Mission Controlを使う方が分かりやすいです。
マイクラ用に見る場合は、最初から全部理解しようとしなくて大丈夫です。
まずは次のあたりを見れば十分です。
最初に見るポイント
- ServerTickTime：平均ティック時間が重くなっていないか
- ChunkGeneration：チャンク生成に時間がかかっていないか
- PacketReceived / PacketSent：通信量が極端に増えていないか
- NetworkSummary：接続ごとの通信量やパケット数が増えていないか
- GC関連：メモリ回収が頻繁に発生していないか
- CPU使用率：特定の処理がCPUを使いすぎていないか
特に、サーバーラグを調べるなら ServerTickTime はかなり重要です。
マイクラは基本的に20TPS、つまり1秒間に20回の処理を目標に動きます。
1ティックは50msが目安です。
この処理が50msを大きく超える状態が続くと、サーバー側の遅延として体感されやすくなります。
JFRは「答え」ではなく「証拠」
ここは大事なので、少し強めに書いておきます。
/jfr で記録を取ったからといって、必ず一発で原因が分かるわけではありません。
JFRファイルは、あくまで 原因を探すための証拠です。
例えば、ChunkGenerationが重いなら、
- 新規チャンクを大量に読み込んでいる
- ワールド生成系MODが重い
- サーバーのストレージが遅い
- 探索速度が速すぎる
などが考えられます。
ServerTickTimeが悪いなら、
- エンティティが多すぎる
- 村人やMobのAI処理が重い
- ホッパーやレッドストーン装置が多い
- MODやデータパック処理が重い
などを疑えます。
つまり、JFRは「このへんが怪しい」と見るための道具です。
その後は、実際のワールド構造やサーバー設定と照らし合わせて判断しましょう。
8. どんな場面でjfrコマンドを使うべきか
/jfr は、普通のサバイバル生活では必須ではありません。
ただ、次のような場面ではかなり役立ちます。
1. マルチサーバーが重い時
一番分かりやすい使いどころは、マルチサーバーのラグ調査です。
プレイヤーが増えると、
- チャンク読み込み
- Mob処理
- 村人処理
- アイテム処理
- ネットワーク通信
- データパックやプラグイン処理
などが増えていきます。
「なんとなく重い」だけだと対策も曖昧になりますが、JFRで記録しておくと、どの方向から調べれば良いか見えやすくなります。
2. MOD環境で急に重くなった時
MOD環境では、バニラよりも原因調査が難しくなります。
新しいMODを入れた直後に重くなったとしても、原因がそのMOD単体とは限りません。
他のMODとの組み合わせ、ワールド生成、エンティティ、ブロックエンティティ、描画負荷など、色々な要因が絡むことがあります。
こういう時にJFRを使うと、少なくともJava側・マイクラ側で何が起きているかを追いやすくなります。
3. チャンク生成が重い時
エリトラで新しい地形を飛んでいる時だけカクつく場合、チャンク生成が原因のことがあります。
minecraft.ChunkGeneration を見ることで、チャンク生成の処理がどのくらい重かったのかを確認できます。
特にワールド生成MODを入れている場合、新規探索時の重さ確認に向いています。
4. 村人・トラップ・倉庫周辺だけ重い時
サバイバルが進むと、拠点周りに便利装置が増えていきます。
- 村人交易所
- アイアンゴーレムトラップ
- 天空トラップタワー
- 自動仕分け倉庫
- ホッパー大量使用の装置
- クロック回路
こういう場所で重くなる場合、何が原因か分かりづらいです。
JFRだけで全てを断定するのは難しいですが、記録を取ることで「サーバーティックが詰まっているのか」「チャンク読み込みなのか」「別のJava側処理なのか」を見分ける助けになります。
5. レンタルサーバー会社やMOD作者へ相談する時
意外と大事なのがここです。
サーバーが重い時に、
「重いです」
「ラグいです」
「たまに止まります」
だけでは、相手も原因を判断しづらいです。
でも、JFRファイルやログ、再現手順があると、相談の質が一気に上がります。
相談する時にあると良い情報
・マイクラのバージョン
・バニラかMOD入りか
・サーバー人数
・重くなる場所や作業
・/jfrで取った記録ファイル
・再現手順
サーバー運営をしている方は、トラブル時の材料として覚えておくと便利です。
9. jfrコマンドを使う時の注意点
/jfr は便利ですが、いくつか注意点があります。
1. 長時間回しっぱなしにしない
JFRは低負荷で使える記録機能ですが、それでも記録を取っている以上、ファイルサイズは増えます。
特にサーバーで何時間も回しっぱなしにすると、あとから確認しづらくなります。
最初は短めに記録するのがおすすめです。
目安としては、
- 軽い確認：30秒〜1分
- 重い場面の再現：1〜3分
- 不定期ラグの調査：必要に応じて長め
くらいで考えると扱いやすいです。
2. 個人情報やサーバー情報の扱いに注意
JFRファイルには、Javaアプリケーションの内部情報が含まれます。
マイクラのワールドデータそのものが丸ごと入るわけではありませんが、サーバー環境や処理内容に関わる情報が含まれる可能性はあります。
第三者へ渡す場合は、相手をよく確認してください。
不特定多数が見られる場所へそのまま公開するのは避けた方が安全です。
3. JFRファイルだけで断定しない
JFRは強力な手がかりですが、万能ではありません。
例えば、FPS低下の原因がGPU側にある場合、JFRだけでは分かりづらいことがあります。
また、クライアント側の描画設定、影MOD、リソースパック、ドライバー、PCスペックなども関係します。
サーバーTPSの問題なのか、クライアントFPSの問題なのかは、最初に切り分けましょう。
4. チートやOP権限が必要
/jfr は管理者向けコマンドです。
一般プレイヤーが勝手に実行できるものではありません。
マルチサーバーで使う場合は、サーバー管理者に確認してから使いましょう。
5. 統合版では使えない
/jfr はJava版のコマンドです。
統合版では使えません。
スマホ、Switch、PS版、Xbox版、Windows版の統合版で「jfrコマンドが出ない」となっても、それは不具合ではなく仕様です。
10. 1.21.11以降で見るべき変更点
マイクラJava版1.21.11の公式リリースノートでは、技術的変更として ClientFps JFR event の追加が記載されています。
これは、JFRでクライアント側FPSに関する情報を扱いやすくする変更です。
今までの /jfr は、サーバーティックやチャンク生成など、サーバー側の調査で話題になりやすい印象がありました。
ただ、1.21.11以降では、クライアント側のFPS関連イベントも見やすくなっていく流れがあります。
1.21.11以降で意識したいこと
- サーバーTPSの問題なのか
- クライアントFPSの問題なのか
- チャンク生成の問題なのか
- 描画設定・リソースパック・MOD描画の問題なのか
この切り分けが、今まで以上に大事になります。
例えば、マルチサーバーで「重い」と言っても、実際には2パターンあります。
1つ目は、サーバーTPSが落ちて、ブロック破壊やMobの動きが遅れるパターン。
2つ目は、サーバーは正常だけど、プレイヤーのPC側でFPSが落ちてカクつくパターンです。
この2つは対策が全然違います。
TPSが悪いなら、サーバー側の負荷、エンティティ、チャンク、装置、MOD処理を疑います。
FPSが悪いなら、描画設定、描画距離、影MOD、リソースパック、GPU負荷、クライアント側MODを疑います。
/jfr を使う時は、ただ記録を取るだけでなく、何を調べたいのかを先に決めるのが大事です。
補足
1.21.11ではClientFps関連のJFRイベント追加が確認できますが、JFRファイルの見え方や分析しやすさは、使用するJDK・JMC・ランチャー環境によって変わる場合があります。
うまく見えない場合は、JDKやJMC側も新しめのものを使うと確認しやすいです。
11. よくある失敗と対処法
ここでは、/jfr コマンドでつまずきやすいポイントをまとめます。
/jfr start が使えない
考えられる原因は、権限不足です。
- シングルプレイでチートが無効
- マルチサーバーでOP権限がない
- 権限レベルが足りない
このあたりを確認してください。
シングルプレイなら、LANに公開してチートを許可すれば一時的に使えます。
マルチサーバーなら、管理者権限が必要です。
/jfr start が失敗する
すでにJFR記録が開始されている可能性があります。
一度、
/jfr stop
を実行して停止できるか確認してください。
/jfr stop が失敗する
記録が始まっていない状態で /jfr stop を実行している可能性があります。
この場合は、まず、
/jfr start
で開始してから、必要な場面を記録し、最後に /jfr stop しましょう。
ファイルが見つからない
まずはゲームディレクトリの debug フォルダを確認してください。
通常ランチャーなら .minecraft/debug 配下です。
別ランチャーやMODパック環境では、インスタンスごとにゲームディレクトリが分かれている場合があります。
CurseForgeやModrinth App、Prism Launcherなどを使っている方は、必ずそのインスタンスのフォルダを開いて確認しましょう。
JFRファイルを開けない
.jfr ファイルは普通のテキストファイルではありません。
JDK Mission Controlなど、JFR形式に対応したツールで開く必要があります。
パソコンにJDKやJMCが入っていない場合は、まず分析ツール側の準備が必要です。
記録したけど何を見れば良いか分からない
最初は全部見ようとしなくて大丈夫です。
まずは、
- ServerTickTime
- ChunkGeneration
- PacketReceived / PacketSent
- NetworkSummary
- GC関連
- CPU使用率
このあたりから確認しましょう。
特に「サーバーが重い」と感じるならServerTickTime、新規探索が重いならChunkGenerationから見るのがおすすめです。
記録中にさらに重くなった気がする
JFRは低負荷な記録機能ですが、ゼロ負荷ではありません。
もともとギリギリのスペックで動かしているサーバーや、かなり重いMOD環境では、記録中の負荷も気になる場合があります。
そういう時は、記録時間を短くする、再現する場面を絞る、人数が少ない時間に実行するなどで調整しましょう。
12. まとめ
今回は、マイクラJava版の /jfr コマンドについて解説しました。
要点を整理すると、
/jfrはJava版限定の性能記録コマンド- 構文は基本的に
/jfr startと/jfr stop - 実行には権限レベル4が必要
- 記録ファイルはゲームディレクトリ内の
debugフォルダに出力される .jfrファイルはJDK Mission Controlなどで分析できる- サーバーTPS低下、チャンク生成、通信負荷、ワールド読み込みなどの調査に使える
- 1.21.11ではClientFps関連のJFRイベント追加も確認されている
という感じです。
/jfr は、普段のサバイバルで必須のコマンドではありません。
でも、ワールドやサーバーが重くなった時に、原因を感覚だけで探すのはかなり大変です。
そんな時にJFRで記録を取っておくと、
「チャンク生成が怪しい」
「サーバーティックが詰まっている」
「通信ではなくワールド側が重そう」
「FPS低下とTPS低下を分けて考えるべき」
というように、次に見るべき場所がかなり整理しやすくなります。
マイクラを普通に遊ぶだけなら知らなくても困りませんが、MOD環境・マルチサーバー・重いワールド改善まで触るなら、覚えておいて損はありません。
まずは短い時間で、
/jfr start
からの、
/jfr stop
を試してみてください。
では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にもマイクラJava版の仕様解説や便利コマンドを紹介しているので、是非ご覧くださいね(^^♪
13. 引用・参考文献
この記事を書くにあたり、以下のページを参考にしています：
