この記事はマイクラJava版向けのdebugコマンド解説です
統合版（Bedrock Edition）では同じ/debugコマンドは使えません
コマンド実行にはチート許可、またはサーバーのOP権限が必要です
こんにちは。ゆずかきです。
マイクラJava版でコマンドを触っていると、たまに出てくるのが/debugコマンドです。
ただ、正直なところ、普通のサバイバルではほとんど使いません。
なので、はじめて見た時は、
「debugって何を調べるコマンドなの？」
「F3のデバッグ画面とは違うの？」
「debug startとdebug functionって何が違うの？」
こんな感じで、けっこう分かりにくいと思います。
筆者も最初は、F3画面のことを指しているのか、サーバーの重さを調べるものなのか、データパック用なのか、かなり混乱しました。
先に結論から言うと、/debugコマンドは主に、
- ワールドやサーバーの処理状況を簡易的に測る
- データパックのfunction実行内容を細かく追跡する
- コマンド・データパック制作時の不具合調査に使う
ためのJava版限定の技術向けコマンドです。
普段の建築・冒険では出番が少ないですが、データパックやコマンドブロック、重い装置の検証をする人にとっては、知っておくとかなり助かります。
この記事では、マイクラJava版のdebugコマンドの使い方・構文・出力ファイルの見方を、なるべく実際の使いどころに寄せて解説していきますね。
この記事を読めば、次のことが分かります。
/debug startと/debug stopの使い方/debug functionで何が出力されるのか- F3のデバッグ画面や
/perfとの違い- debugコマンドが使えない時のチェックポイント
それでは、やっていきましょう！
※本記事はマイクラJava版26.1.2時点の正式リリース仕様確認をベースに構成しています。
※ゲーム内の仕様についてはMinecraft Wiki、Minecraft公式リリースノートを参考にしています。
※スナップショット版・今後のアップデートでは仕様が変わる可能性があります。
目次
1. debugコマンドとは
2. debugコマンドを使う前の準備
3. debugコマンドの構文一覧
4. /debug start と /debug stop の使い方
5. /debug function の使い方
6. デバッグ出力ファイルの見方
7. /debug report は現在使える？古い情報に注意
8. F3デバッグ画面・F3+L・/perfとの違い
9. debugコマンドの実用例
10. うまく使えない時のチェックポイント
11. まとめ
12. 参考文献
この記事で分かること
・マイクラJava版の/debugコマンドの基本
・debug start、debug stop、debug functionの違い
・データパック制作時のデバッグ出力の読み方
1. debugコマンドとは
/debugコマンドは、マイクラJava版で使えるデバッグ用コマンドです。
普通のサバイバル攻略でよく使う/tp、/give、/time setのような便利コマンドとは違い、どちらかというと検証・開発・不具合調査向けのコマンドですね。
主な用途は下記です。
| 使い方 | 主な目的 | 使う人 |
|---|---|---|
| /debug start | デバッグ計測を開始する | 検証者・サーバー管理者 |
| /debug stop | 計測を停止し、平均TPSなどを確認する | 検証者・サーバー管理者 |
| /debug function | functionの実行内容を追跡する | データパック制作者 |
特に重要なのは、/debug functionはデータパック制作者向けという点です。
たとえば、自作データパックのfunctionが思った通りに動かない時に、
- どのコマンドが実行されたのか
- どのコマンドで失敗したのか
- functionの中から別のfunctionが呼ばれているか
といった流れを、テキストファイルで追跡できます。
一方で、/debug startと/debug stopは、一定時間の処理状況を見たい時に使います。
こちらはデータパック専用というより、サーバーやワールドの重さを見る簡易チェックに近いです。
体験談
筆者は最初、/debugを「F3画面を開くコマンド」だと思っていました。
でも実際は、F3画面とは別物です。
F3は画面表示、/debugはコマンドとして計測・出力をするもの、と分けて覚えると理解しやすいです。
2. debugコマンドを使う前の準備
/debugコマンドを使うには、まずコマンドを実行できる権限が必要です。
シングルプレイなら、ワールド作成時に「チートの許可」をオンにしておくか、LANに公開する時にチートを許可すれば使えます。
サーバーなら、基本的には権限レベル3以上のOP権限が必要です。
一般プレイヤーが自由に使えるコマンドではありません。
シングルプレイで使う場合
- Escキーでメニューを開く
- 「LANに公開」を選ぶ
- 「チートの許可」をオンにする
- 「LANワールドを開始」を押す
- チャット欄で
/debugを入力する
既存ワールドで一時的に確認したいだけなら、この方法が一番手軽です。
サーバーで使う場合
サーバーでは、サーバー管理者からOP権限を付与してもらう必要があります。
サーバーコンソールで行う場合は、次のように実行します。
op プレイヤー名
OP権限がある状態で、ゲーム内チャットから次のように入力します。
/debug start
実行できれば、デバッグ計測が開始されます。
※サーバー側のop-permission-level設定が3未満の場合は、OPでも/debugを実行できないことがあります。
※公開サーバーでむやみに使うのはおすすめしません。負荷検証やデータパック検証など、目的を決めてから使いましょう。
先に確認しておくこと
/debugを使う前に、下記を確認しておくと後で迷いにくいです。
- Java版でプレイしているか
- チート、または権限レベル3以上のOP権限があるか
- 検証したい内容が「重さ」なのか「functionの動き」なのか
- デバッグ出力ファイルを探す場所を把握しているか
特に、統合版には同じ/debugコマンドが無いので注意です。
「マイクラ debug コマンド」と検索して出てきた情報でも、Java版前提の記事かどうかは必ず確認しましょう。
3. debugコマンドの構文一覧
Java版で使う/debugコマンドの基本構文は、主に次の3つです。
/debug start /debug stop /debug function <name>
それぞれの意味を表にまとめます。
| 構文 | 内容 | 初心者向けの理解 |
|---|---|---|
| /debug start | デバッグ計測を開始 | ここから計測開始 |
| /debug stop | デバッグ計測を停止 | ここで計測終了 |
| /debug function <name> | functionを詳しく実行 | データパックの中身を追跡 |
<name>には、functionの名前空間付きIDを入れます。
たとえば、データパック内にyuzukaki:testというfunctionがあるなら、次のように入力します。
/debug function yuzukaki:test
functionタグを実行したい場合は、#を付けます。
/debug function #yuzukaki:debug_tests
ここで注意したいのは、/debug functionはfunctionファイルが存在していることが前提という点です。
データパックを作っていないワールドで急に実行しても、使いどころはほとんどありません。
また、/debug functionの中から、別の/debug functionを直接・間接的に呼び出すことはできません。
通常のfunction実行内容を追跡するためのもの、と考えておくと分かりやすいです。
ポイント
普通のプレイヤーが覚えるなら、まずは/debug startと/debug stopだけで大丈夫です。
データパックを作る方は、/debug functionまで覚えると不具合調査がかなり楽になります。
4. /debug start と /debug stop の使い方
まずは、/debug startと/debug stopの使い方です。
この2つはセットで使います。
1. 計測を開始する
チャット欄を開き、次のコマンドを入力します。
/debug start
これでデバッグ計測が開始されます。
この状態で、調べたい行動をします。
たとえば、
- 重いレッドストーン装置を動かす
- アイテム仕分け機を稼働させる
- Mobが多い場所に移動する
- 村人交易所の近くで待機する
- トラップを稼働させる
などですね。
「何もしない状態」と「装置を動かした状態」を分けて計測すると、差が分かりやすいです。
2. しばらく待つ
計測時間は、短すぎると参考にしにくいです。
目安としては、最低でも20〜30秒くらい。
装置の重さを見たいなら、1分程度は動かしてから止めると判断しやすいと思います。
3. 計測を停止する
次のコマンドを入力します。
/debug stop
これで計測が停止され、平均TPSなどの情報が返ってきます。
TPSは、簡単に言うとゲーム内処理が1秒間に何回進んでいるかの目安です。
通常のマイクラは20TPSを目標に動いています。
- 20TPS付近：かなり安定
- 18〜19TPS：少し重いかも
- 15TPS前後：体感でも遅れやすい
- 10TPS以下：かなり重い
という見方で良いです。
※ただし、TPSだけで全ての重さを判断できるわけではありません。クライアント側のFPS低下、描画距離、影MOD、リソースパック、PCスペックなども関係します。
すでに計測中だと失敗する
/debug startを実行したあと、停止せずにもう一度/debug startを実行すると失敗します。
その場合は、先に下記を実行してください。
/debug stop
逆に、何も開始していない状態で/debug stopを実行しても失敗します。
体験談
筆者は最初、/debug startを何回も連打して「あれ？動いてない？」と勘違いしました。
でも、開始したらまず止める。これだけです。
startとstopは必ずワンセットで使う、と覚えておくと事故りません。
5. /debug function の使い方
次に、/debug functionです。
これは、データパックで使う/functionコマンドを、より詳しく追跡するためのコマンドです。
普通の/functionは、指定したfunctionを実行するだけです。
/function yuzukaki:test
一方、/debug functionで実行すると、function内でどのコマンドが実行されたのかをデバッグ出力ファイルとして残せます。
/debug function yuzukaki:test
どんな時に使う？
/debug functionが役立つのは、こんな場面です。
- functionが途中で止まっている気がする
executeの条件分岐が思った通りに動かない- スコアボードの値が変化していない
- functionから別のfunctionを呼んでいるが、流れが追えない
- 大量のコマンドを入れたデータパックで、どこが失敗しているか探したい
特に、execute ifやexecute unlessを多用しているデータパックでは便利です。
チャット欄だけで追いかけるより、出力ファイルを見た方が圧倒的に確認しやすいです。
例：テスト用functionを実行する
たとえば、次のようなfunctionがあったとします。
say debug test start execute if entity @e[type=minecraft:zombie,limit=1] run say ゾンビを検出しました execute unless entity @e[type=minecraft:zombie,limit=1] run say ゾンビはいません say debug test end
これを普通に実行するなら、
/function yuzukaki:test
ですが、実行の流れを追いたいなら、
/debug function yuzukaki:test
と入力します。
実行後、.minecraft/debugフォルダにデバッグトレースファイルが作成されます。
そのファイルを見ることで、どのコマンドが実行され、どのメッセージが返ったのかを確認できます。
functionタグも使える
functionタグを指定する場合は、#を付けます。
/debug function #yuzukaki:debug_tests
複数のfunctionをまとめて検証したい時に便利です。
ただし、対象タグやfunctionが存在しない場合は失敗します。
※データパックの名前空間やフォルダ構造が間違っていると、ここで詰まりやすいです。
6. デバッグ出力ファイルの見方
/debug functionを実行すると、デバッグ用のテキストファイルが作成されます。
ファイル名は、おおむね次のような形式です。
debug-trace-yyyy-MM-dd_HH.mm.ss.txt
保存場所は、通常のシングルプレイなら.minecraft/debugフォルダです。
環境ごとの目安は下記です。
| 環境 | debugフォルダの場所 |
|---|---|
| Windows | %appdata%\.minecraft\debug |
| macOS | ~/Library/Application Support/minecraft/debug |
| Linux | ~/.minecraft/debug |
| サーバー | サーバーフォルダ内のdebugフォルダ |
出力ファイルに出てくる記号
デバッグトレースには、[C]や[M]などの記号が出てきます。
初心者さん向けに、見方を表にまとめますね。
| 記号 | 意味 | 見方 |
|---|---|---|
| [C] | コマンド実行 | この行のコマンドが実行された |
| [M] | メッセージ | 成功時などの返答メッセージ |
| [E] | 失敗メッセージ | ここで失敗している可能性が高い |
| [R = 数字] | 戻り値 | コマンド結果の数値 |
| [F] | function呼び出し | 別functionが呼ばれた |
一番見るべきなのは、まず[E]です。
[E]が出ている場合、その周辺のコマンドで失敗しています。
構文ミス、対象エンティティなし、スコアボード名の間違い、名前空間のミスなどを疑いましょう。
次に見るのは、[C]の流れです。
自分が想定していた順番でコマンドが実行されているかを追っていくと、
- 条件分岐に入っていない
- 呼ばれるはずのfunctionが呼ばれていない
execute asの対象がいないlimit=1で想定外の対象を拾っている
といった原因を見つけやすくなります。
体験談
データパックで一番怖いのは、「エラーは出ないけど思った通りに動いていない」パターンです。
こういう時、/debug functionで実行順を見られるとかなり助かります。
目で追える形にするだけで、原因が見つかることが多いです。
7. /debug report は現在使える？古い情報に注意
ここは大事です。
昔のマイクラ情報を見ると、/debug reportという構文が出てくることがあります。
ですが、現在のJava版26.1.2では、/debug reportは使えません。
古いバージョンでは、/debug reportでワールド情報やチャンク情報などを含むZIPファイルを出力できました。
ただし、この機能はJava版1.17で削除され、F3+Lや/perfに置き換わっています。
そのため、現在のJava版で覚えるべき/debugは、下記の3つで十分です。
/debug start /debug stop /debug function <name>
詳しいパフォーマンス情報を見たい場合
今のJava版で、より詳しいパフォーマンス情報を取りたい場合は、/debug reportではなく、状況に応じて次の方法を使います。
- クライアント側やシングルプレイで見るなら、F3画面やF3+L
- 専用サーバーで記録するなら、
/perfコマンド - データパックのfunction追跡なら、
/debug function
という使い分けです。
注意！
検索で出てくる古い記事や動画では、/debug reportが現役のように紹介されている場合があります。
でも、Java版1.17以降の現行環境では使えません。
この記事では、現在のJava版で実用しやすい構文に絞って解説しています。
8. F3デバッグ画面・F3+L・/perfとの違い
debugという言葉がややこしい理由は、マイクラJava版には似たようなデバッグ機能がいくつもあるからです。
特に混同しやすいのが、下記です。
- F3デバッグ画面
- F3+Lのパフォーマンス記録
/perfコマンド/debugコマンド
それぞれ役割が違います。
| 機能 | 使い方 | 主な用途 |
|---|---|---|
| F3デバッグ画面 | F3キー | 座標・向き・FPS・バイオームなどを見る |
| F3+L | F3を押しながらL | パフォーマンス記録を出力する |
| /perf | /perf start、/perf stop | 専用サーバーのパフォーマンス記録 |
| /debug | /debug start など | 簡易計測・function追跡 |
初心者さん向けに言うなら、
座標を見たいだけならF3
重さを詳しく調べたいならF3+Lや/perf
functionの中身を追いたいなら/debug function
という覚え方でOKです。
26.1以降のデバッグ画面変更について
Java版26.1では、F3デバッグ画面側にいくつか変更が入りました。
たとえば、見ているブロックや液体のタグ表示が別項目に分かれたり、F3 + 4でライトマップのデバッグ表示を使えるようになったりしています。
また、Java版1.21.9では、F3 + F6で開けるデバッグオプション画面も追加されています。
ここから、表示するデバッグ情報をある程度カスタマイズできます。
ただし、これらは主にF3デバッグ画面側の変更です。
この記事で扱っている/debug start、/debug stop、/debug functionの基本的な使い方とは分けて考えて大丈夫です。
※今後のアップデートで/debugコマンド側に変更が入った場合は、公式リリースノートやMinecraft Wikiで確認するのが安全です。
9. debugコマンドの実用例
ここからは、実際にどんな場面で/debugを使うかを紹介します。
例1：重い装置を動かす前後でTPSを確認する
レッドストーン装置やMobトラップを作った時、
「これ、サーバー重くなってないかな？」
と気になることがあります。
その場合は、まず装置を止めた状態で計測します。
/debug start
30秒〜1分ほど待ってから、
/debug stop
次に、装置を動かした状態で同じように計測します。
/debug start
装置を動かしてしばらく待ち、
/debug stop
この2回を比べると、装置の影響を見やすいです。
もちろん、これだけで完璧な負荷調査ができるわけではありません。
でも、初心者が「明らかに重いかどうか」を確認するには十分役立ちます。
例2：データパックのfunctionが動かない原因を探す
自作データパックで、/functionを実行しても思った通りに動かない時は、/debug functionで追跡します。
/debug function yuzukaki:test
出力されたdebug-traceファイルを開き、[E]や実行順を確認します。
よくある原因は、
- 名前空間が間違っている
- function名が違う
- スコアボード名が違う
- 対象セレクターに該当するエンティティがいない
execute ifの条件が成立していない
このあたりです。
特に、execute系はチャット欄だけだと原因を見つけづらいので、トレースファイルを見る価値があります。
例3：functionタグの呼び出し順を確認する
複数のfunctionをまとめて呼び出している場合、functionタグを使っていることがあります。
/debug function #yuzukaki:debug_tests
このように実行すると、タグ経由で呼ばれたfunctionの流れを確認できます。
「Aの次にBが呼ばれるはずなのに、Bが動いていない」
「タグに入れたつもりのfunctionが呼ばれていない」
こういう時に便利です。
例4：配布前のデータパック確認に使う
自作データパックを配布する前には、/debug functionで一度確認しておくと安心です。
特に、次のようなデータパックは確認推奨です。
- tickで毎ティック実行される処理がある
- loadで初期化処理をしている
- スコアボードを大量に使っている
- アイテム・Mob・座標条件を多く使う
- function同士の呼び出しが多い
配布後に「動きません」と言われるより、先に自分の環境で追跡しておく方が楽です。
筆者メモ
データパックは、1行だけのミスでも全体が変に見えることがあります。
目視で見つからない時は、無理に勘で直すより、/debug functionで実行順を追った方が早いです。
10. うまく使えない時のチェックポイント
/debugコマンドが使えない、または思った出力が出ない時は、下記を確認してみてください。
- [ ] Java版で実行しているか？
- [ ] チートの許可、または権限レベル3以上のOP権限があるか？
- [ ]
/debug startを開始済みなのに、もう一度startしていないか？ - [ ]
/debug stopを開始前に実行していないか？ - [ ]
/debug functionで指定したfunctionは存在しているか？ - [ ] 名前空間のスペルは合っているか？
- [ ] functionタグを指定する時に
#を付けているか？ - [ ] データパックは有効化されているか？
- [ ]
/reload後にもう一度試したか？ - [ ] 出力ファイルを探すフォルダを間違えていないか？
「Unknown or incomplete command」と出る場合
この場合は、構文が間違っている可能性が高いです。
よくあるミスは、
/debug report
のように、古い情報にある構文を使っているケースです。
現在のJava版では、まず下記の構文を確認してください。
/debug start /debug stop /debug function <name>
「権限がありません」と出る場合
チートが無効、またはOP権限レベルが足りない可能性があります。
シングルプレイならLAN公開でチートを許可。
サーバーなら管理者にOP権限とop-permission-levelを確認してもらいましょう。
debug-traceファイルが見つからない場合
/debug functionを実行したのにファイルが見つからない場合は、保存場所を間違えている可能性があります。
シングルプレイでは.minecraft/debugを確認。
サーバーでは、サーバーの実行フォルダ内に作られるdebugフォルダを確認してください。
また、/debug startと/debug stopでは、/debug functionのようなトレースファイルとは目的が違います。
functionの実行追跡を見たい場合は、必ず/debug functionを使いましょう。
データパックが認識されていない場合
functionを指定しても失敗する場合は、データパック自体が読み込まれていないかもしれません。
次のコマンドで、読み込まれているデータパックを確認できます。
/datapack list
データパックを入れ直した場合は、
/reload
も忘れずに実行しましょう。
11. まとめ
以上、マイクラJava版のdebugコマンドの使い方・構文・デバッグ出力について解説しました。
要点を整理すると、
/debugはJava版限定のデバッグ用コマンド- 普段のサバイバルでは出番少なめ
/debug startと/debug stopは簡易的な計測に使う/debug functionはデータパックのfunction追跡に使う- 出力ファイルでは
[C]、[M]、[E]、[R]、[F]を見る - 古い
/debug report情報には注意 - F3デバッグ画面、F3+L、
/perfとは役割が違う
という感じです。
正直、/debugコマンドは初心者が必ず覚えるべきコマンドではありません。
でも、データパック制作やサーバー検証をするなら、知っておく価値はかなりあります。
特に/debug functionは、functionの中身を追えるので、自作データパックが動かない時の原因探しに便利です。
「どこが悪いか分からない」という時に、勘で直すより安全ですね。
もし初めて使うなら、まずはテストワールドで、
/debug start /debug stop
を試してみてください。
データパックを触っている方は、次に、
/debug function 自分の名前空間:テストfunction
でトレースファイルを見てみると理解しやすいです。
では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にもマイクラJava版のコマンド・装置・検証系の記事をまとめているので、ぜひご覧くださいね(^^♪
12. 参考文献
この記事を書くにあたり、以下の公式情報・コミュニティWikiを参考にしています。
