トップ > マイクラwiki > 【マイクラ】コマンドの実行回数制限・負荷対策｜maxCommandChainLength・tick負荷の考え方【Java/統合版】
最終更新日

【マイクラ】コマンドの実行回数制限・負荷対策｜maxCommandChainLength・tick負荷の考え方【Java/統合版】

マイクラwiki

コマンドブロックやfunctionで装置を作り始めた方向けの記事です
Java版・統合版の両方に触れますが、表記や使える機能に違いがあります
Java版1.21.11以降では maxCommandChainLength の名前が変更されています

こんにちは。ゆずかきです。

マイクラでコマンドブロックを触っていると、途中から急に、

「チェーンコマンドブロックが続かない」
「functionを実行したら一部だけ動かない」
「常時実行コマンドを置いたらワールドが重くなった」

こういうことが起こることがあります。

この時に関係してくる代表的な設定が、コマンドの実行回数制限です。
旧来の名前で言うと、maxCommandChainLengthですね。

ただし、ここで最初に注意です。
Java版1.21.11以降では、ゲームルール名が minecraft:max_command_sequence_length に変更されています。
一方で、統合版では今も maxcommandchainlength という表記で扱う場面があります。

つまり、検索すると古い名前・新しい名前・Java版・統合版の情報が混ざって出てきます。
ここで混乱しやすいです。

この記事では、maxCommandChainLengthとは何か？という基本から、tick負荷を増やさないコマンド設計まで、実際に装置を作る時に役立つ形で整理していきますね。

この記事を読めば、次のことが分かります。

  • maxCommandChainLength / minecraft:max_command_sequence_length の意味が分かります👍
  • Java版と統合版で、どの名前を使えばいいか分かります👌
  • コマンド装置が重くなる原因と、負荷対策の考え方が分かります
  • 「上限を上げれば解決」ではない理由が分かります

それでは、やっていきましょう！

※本記事ではJava版1.21.11以降の名称変更も含めて解説しています。
※統合版はBedrock Editionの公式ドキュメントを元に整理しています。
※コマンド仕様はバージョン差が出やすいので、実際に使う前にゲーム内補完でも確認してください。

目次

1. maxCommandChainLengthとは
2. Java版と統合版で名前が違うので注意
3. 現在値の確認方法と変更コマンド
4. 上限を上げれば解決、ではありません
5. tick負荷とは何か？
6. 重くなりやすいコマンドの例
7. コマンド装置の負荷対策
8. Java版と統合版で使い分けたい実装方法
9. 動かない・重い時のチェックポイント
10. まとめ
11. 参考文献

この記事で分かること
・マイクラのコマンド実行回数制限の基本
・maxCommandChainLength と minecraft:max_command_sequence_length の違い
・tick負荷を減らすための実践的な考え方

1. maxCommandChainLengthとは

maxCommandChainLength は、簡単に言うと、1ティック内に連続して実行できるコマンド数の上限です。

マイクラは通常、1秒間に20ティック進みます。
つまり、1ティックは約0.05秒です。

この短い時間の中で、コマンドブロックやfunctionが大量に動くと、ワールドやサーバーに大きな負荷がかかります。
そこで、1ティックの中でコマンドが延々と連鎖し続けないようにする安全装置として用意されているのが、この実行回数制限です。

イメージとしては、こんな感じです。

コマンドが暴走しないように、1ティック内で実行してよい連鎖数に上限を付ける設定

ですね。

代表的に関係するのは、次のようなものです。

  • チェーンコマンドブロックを大量に並べた装置
  • リピートコマンドブロックからチェーンをつないだ装置
  • Java版データパックのfunction
  • functionの中からさらにfunctionを呼び出す構造
  • execute as @e などで大量の対象に分岐するコマンド

初期値は、Java版では基本的に 65536 です。
統合版でも同じ系統の上限として扱われますが、環境やサーバーの種類によって初期表示が異なることがあるため、最終的にはゲーム内で現在値を確認するのが安全です。
普通にコマンドブロックを数個〜数十個使うくらいなら、まず上限には届きません。

なので、初心者さん向けに最初に結論を言うと、こうです。

よく分からないうちは変更しなくてOKです。
問題が出た時だけ確認しましょう。

この設定は、便利設定というより、暴走防止用の安全装置に近いです。
数値を上げれば装置が強くなる、というものではありません。

2. Java版と統合版で名前が違うので注意

ここが一番混乱しやすいところです。

昔からマイクラを触っている方は、maxCommandChainLength という名前で覚えていると思います。
ただ、Java版1.21.11以降ではゲームルール名が変更されています。

👇整理すると、こうです。

環境 使う名前 備考
Java版1.21.11以降 minecraft:max_command_sequence_length 新しい正式名
Java版1.21.10以前 maxCommandChainLength 旧名
統合版 maxcommandchainlength ゲーム内コマンドでは小文字表記で扱われることが多い
統合版Script API maxCommandChainLength API上の識別名


Java版1.21.11以降で記事や配布ワールドの説明を読む時は、特に注意してください。
古い解説では、今でも maxCommandChainLength と書かれていることがあります。

ですが、Java版1.21.11以降でコマンドを打つなら、基本は次の名前です。

/gamerule minecraft:max_command_sequence_length

一方、統合版では次のように扱います。

/gamerule maxcommandchainlength

統合版は入力時の大文字・小文字にゆるい場面もありますが、記事内ではゲーム内補完で出やすい小文字表記に寄せておきます。

注意！
Java版と統合版は、似た名前でも仕様や周辺コマンドが違います。
「Java版で動いたから統合版でも同じ」と考えると、かなりの確率で詰まります。

特に、データパック・ビヘイビアーパック・function・schedule周りは差が出やすいので、ここは分けて考えるのがおすすめです。

3. 現在値の確認方法と変更コマンド

ここでは、実際に使うコマンドを整理します。

Java版1.21.11以降の場合

現在値を確認するコマンドはこちらです。

/gamerule minecraft:max_command_sequence_length

値を変更する場合は、後ろに数値を付けます。

/gamerule minecraft:max_command_sequence_length 65536

初期値に戻したい場合も、基本は 65536 に戻せばOKです。

/gamerule minecraft:max_command_sequence_length 65536

Java版1.21.10以前の場合

古いJava版では、こちらの名前を使います。

/gamerule maxCommandChainLength

変更する場合はこうです。

/gamerule maxCommandChainLength 65536

統合版の場合

統合版では、次の形で確認します。

/gamerule maxcommandchainlength

変更する場合は、後ろに数値を付けます。

/gamerule maxcommandchainlength 65535

統合版では、環境によって初期値や入力できる上限の表示が異なることがあります。
初期値に戻したい場合は、変更前に表示された現在値をメモしておき、その値に戻すのが安全です。

統合版は、ゲーム内のバージョンや入力環境によって補完表示が少し違うことがあります。
迷ったら、チャット欄に /gamerule まで入力して、候補に出る名前を確認してください。

0にするのは基本おすすめしません

このゲームルールは、最小値が0として扱われる環境があります。
ただし、0や極端に低い値にするとチェーン系のコマンドがほぼ動かない原因になります。

特に、コマンドブロックが突然動かなくなった時に、

/gamerule maxcommandchainlength 0

のような設定になっていると、そこで止まる可能性があります。

体験ベースの注意点
配布ワールドやサーバー設定をいじっていると、ゲームルールが自分の想定と違う値になっていることがあります。
コマンド装置が全体的に動かない時は、まず現在値を確認しましょう。

4. 上限を上げれば解決、ではありません

ここ、かなり大事です。

maxCommandChainLength という名前だけ見ると、

「コマンドが途中で止まるなら、上限を上げれば解決では？」

と思うかもしれません。

確かに、上限に引っかかっているだけなら、数値を上げることで最後まで実行される場合はあります。
ですが、これは根本解決ではないことが多いです。

なぜなら、1ティック内で実行するコマンド数を増やすということは、単純にその瞬間の負荷も増えやすいからです。

たとえば、次のような構造を想像してください。

  • 毎tick、全プレイヤーを対象にコマンドを実行する
  • さらに全エンティティを対象に execute as @e で分岐する
  • その中で複数の execute if block や data get を呼ぶ
  • 最後にfunctionを何個も呼び出す

こういう構造は、上限を上げれば動くかもしれません。
でも、ワールドは重くなります。

つまり、考え方としてはこうです。

上限に届いたら、まず設計を見直す。
どうしても必要な時だけ、慎重に上限を変更する。

これが安全です。

上げてもよい場面

上限変更を検討してもよいのは、たとえば次のような場面です。

  • 配布マップやデータパックの説明で、明確に指定されている
  • 大規模な演出を一瞬だけ実行する必要がある
  • 検証用ワールドで、一時的に上限を外したい
  • 自分で処理量を把握できている

上げない方がよい場面

逆に、次のような場合は、上限を上げる前に構造を直した方がいいです。

  • 原因は分からないけど、とりあえず重い
  • 常時実行コマンドが多すぎる
  • @e を毎tick広範囲に使っている
  • function同士が何重にも呼び合っている
  • サーバーで複数人が遊ぶ予定がある

初心者さんほど、上限の数値を触るよりも、コマンドの実行頻度を落とす方が安全です。

5. tick負荷とは何か？

コマンドの負荷を考える時に避けて通れないのが、tick負荷です。

マイクラは通常、1秒間に20ティック進みます。
1ティックは約0.05秒ですね。

この1ティックの間に、マイクラはかなり多くの処理をしています。

  • Mobの移動やAI
  • ブロック更新
  • レッドストーン処理
  • 作物の成長などのランダムティック
  • エンティティの当たり判定
  • コマンドブロックやfunctionの実行

ここに重いコマンドを大量に乗せると、1ティック内で処理しきれなくなります。
すると、体感としては次のような症状が出ます。

  • Mobの動きがカクつく
  • アイテムが拾われるまで遅い
  • コマンドブロックの反応が遅い
  • サーバーでブロックを壊しても戻る
  • TPSが下がる

TPSは、簡単に言えば「1秒間にどれだけ正常にtickを進められているか」の目安です。
理想は20TPSです。
重くなると、この数字が下がります。

Java版には /tick コマンドもありますが、これは主にデバッグや検証用途で、負荷対策そのものではありません。
/tick sprint などを使うと挙動確認には便利ですが、普段のサバイバル装置を軽くする魔法のコマンドではないです。

大事な考え方
コマンド負荷対策は、tickを操作することではなく、1ティックに詰め込む処理を減らすことです。

ここを間違えなければ、かなり安定したコマンド装置を作れるようになります。

6. 重くなりやすいコマンドの例

ここでは、負荷が増えやすいコマンドの書き方を紹介します。

1. 毎tickの @e 全検索

一番ありがちなのがこれです。

execute as @e run say test

@e は、エンティティ全体を対象にします。
ワールド内にアイテム、Mob、防具立て、矢、村人、額縁などが多いと、対象数がかなり増えます。

これをリピートコマンドブロックで毎tick実行すると、負荷が増えやすいです。

改善するなら、対象を絞ります。

execute as @e[type=minecraft:zombie,distance=..20] run say test

このように、type や distance を付けるだけでもかなり違います。

2. 広範囲のブロック検知

ブロック検知も、範囲が広いと負荷が増えます。

特に、毎tickで広範囲チェックをする構造は注意です。

execute if blocks ~-20 ~-5 ~-20 ~20 ~5 ~20 ~ ~ ~ all run say found

こういう広い比較を常時回すと、ワールドによってはかなり重くなります。

改善するなら、

  • 範囲を狭くする
  • 毎tickではなく数秒に1回にする
  • チェック地点を固定する
  • 必要な時だけ起動する

という形が安全です。

3. functionの呼び出しすぎ

Java版データパックでは、functionがとても便利です。
ただし、functionの中からfunctionを呼び、その中からさらにfunctionを呼ぶと、1ティック内の実行数が一気に増えます。

たとえば、

function sample:a
function sample:b
function sample:c

くらいなら大丈夫でも、それぞれのfunction内でさらに大量処理をしていると、見た目より重いです。

特に minecraft:tick タグで毎tick実行するfunctionは注意しましょう。
minecraft:tick に登録されたfunctionは、毎tick実行されます。
つまり、1秒間に20回です。

体験談寄りの注意点
「1行だけだから軽い」と思っていても、その1行が別functionを呼び、その先で大量処理をしていることがあります。
重い時は、表の入口だけでなく、呼び出し先まで確認しましょう。

4. 常時ログ出力

say や tellraw、コマンドブロックの出力表示も、検証中は便利です。
ただし、常時実行に入れっぱなしにすると、チャットやログが流れ続けます。

軽量化以前に、原因調査がしづらくなります。

検証が終わったら、ログ系は止めておきましょう。

Java版1.21.11以降なら、コマンドブロックの出力を抑えるゲームルール名も新しい表記になります。

/gamerule minecraft:command_block_output false

Java版1.21.10以前なら、こちらです。

/gamerule commandBlockOutput false

統合版なら、ゲーム内コマンドでは小文字表記で扱います。

/gamerule commandblockoutput false

コマンドブロックの出力を抑えたい場合は、これを使うと見やすくなります。
ただし、エラー確認をしたい時は一時的に戻してくださいね。

7. コマンド装置の負荷対策

ここからは、実際にコマンド装置を作る時の負荷対策です。
難しい最適化というより、まずこれを守れば事故りにくいという内容に絞ります。

1. 毎tickで動かす必要があるか考える

一番効果が大きいのはこれです。

リピートコマンドブロックは、条件次第で毎tick動きます。
でも、その処理は本当に毎tick必要でしょうか？

たとえば、

  • 近くにプレイヤーがいるか確認する
  • 特定の場所にブロックがあるか確認する
  • スコアを見てイベント開始する

こういう処理は、毎tickでなくても成立することが多いです。

1秒に1回で良いなら、20tickに1回で十分です。
5秒に1回で良いなら、100tickに1回で十分です。

毎tick実行をやめるだけで、かなり軽くなることがあります。

2. 対象セレクターを絞る

@e をそのまま使わない。
これだけでも大事です。

悪い例です。

execute as @e run function sample:check

改善例です。

execute as @e[type=minecraft:zombie,distance=..32,tag=target_zombie] run function sample:check

対象を絞る時は、次の条件が使いやすいです。

  • type= で種類を絞る
  • distance= で距離を絞る
  • tag= で対象を絞る
  • limit= で数を制限する
  • sort=nearest などで必要な対象だけ選ぶ

特に limit=1 は便利です。
「近くに1体いればいい」だけなら、全部に処理を走らせる必要はありません。

3. スコアボードで状態管理する

毎回ブロックやエンティティを探しに行くより、スコアボードで状態を持たせた方が分かりやすいことがあります。

たとえば、

  • イベント中かどうか
  • カウントダウン残り時間
  • プレイヤーがエリア内にいるか
  • 処理を何tickに1回動かすか

こういうものは、スコアボードで管理しやすいです。

処理の流れを、

  1. 毎tickカウントを進める
  2. 20になったら本処理を実行
  3. カウントを0に戻す

のようにすれば、毎tick重い処理を走らせずに済みます。

4. Java版なら /schedule で分散する

Java版のデータパックでは、/schedule を使ってfunctionの実行を遅らせることができます。

たとえば、重い処理を毎tick呼ぶのではなく、5秒後に次のfunctionを呼ぶようにすれば、処理を分散できます。

schedule function sample:main 5s replace

処理の最後にまた自分自身を予約すれば、一定間隔で動くループも作れます。

# sample:main の最後に書く例
schedule function sample:main 5s replace

これなら、minecraft:tick に全部詰め込むより管理しやすいです。

注意！
/schedule はJava版と統合版で構文や使い方が違います。
Java版の schedule function sample:main 5s replace という書き方を、そのまま統合版に持ち込まないようにしてください。

5. 統合版ならコマンドブロックのDelay in Ticksを使う

統合版のコマンドブロックには、Delay in Ticks の項目があります。
これを使うと、コマンドブロック側で実行間隔を調整できます。

たとえば、毎tickではなく20tickごとに実行したいなら、遅延を入れることで負荷を減らせます。

統合版でコマンドブロック装置を作る時は、Java版よりもこの項目を使いやすいです。
常時実行にしたい時ほど、Delay in Ticksを確認しましょう。

6. 常時稼働装置と演出装置を分ける

コマンド装置には、大きく分けて2種類あります。

  • 常時稼働する管理系コマンド
  • イベント時だけ動く演出系コマンド

この2つを同じ場所に混ぜると、重くなった時に原因が分かりにくいです。

おすすめは、

  • 常時稼働は最小限にする
  • 演出は必要な瞬間だけ起動する
  • 終わったらタグやスコアを消す
  • デバッグ用コマンドは別に分ける

という作り方です。

装置が大きくなるほど、整理しておいた方が後から助かります。

8. Java版と統合版で使い分けたい実装方法

ここでは、Java版と統合版で「どう作ると扱いやすいか」を整理します。

Java版：データパックならtickタグを使いすぎない

Java版データパックでは、minecraft:tick タグにfunctionを登録すると毎tick実行できます。
これは便利です。

ただし、何でもかんでも minecraft:tick に入れると重くなります。

おすすめの考え方は、

  • minecraft:tick には軽い管理処理だけ入れる
  • 重い処理は条件が揃った時だけ呼ぶ
  • 定期処理は /schedule で間隔を空ける
  • 対象セレクターは必ず絞る

です。

Java版はfunctionが強い分、処理を詰め込みすぎる危険もあります。
特に、function の入れ子が増えてきたら、一度整理しましょう。

Java版：コマンドブロックは向きに注意

チェーンコマンドブロックは、前のコマンドブロックから処理が流れてきます。
向きが違うと、見た目はつながっていても動きません。

特に、

  • インパルス → チェーン → チェーン
  • リピート → チェーン → チェーン

の形で作る時は、矢印の向きを確認してください。

また、チェーン側を「常時実行」にするか、「動力が必要」にするかでも動作が変わります。
動かない時は、コマンドの中身だけでなく、ブロック設定も見直しましょう。

統合版：Delay in Ticksを積極的に使う

統合版のコマンドブロックでは、Delay in Ticksがかなり便利です。

たとえば、

  • 20tickごとにチェック
  • 100tickごとにイベント判定
  • 5tick間隔で演出を進める

のような調整が、コマンドブロックの設定だけでできます。

Java版の感覚で「常時実行を並べる」より、統合版ではDelay in Ticksを使った方が扱いやすい場面があります。

統合版：functionCommandLimitも意識する

統合版では、maxcommandchainlength とは別に、functionCommandLimit というゲームルールもあります。
これは、/function で同時に実行できるコマンド数に関係する設定です。

統合版でビヘイビアーパックのfunctionを使う場合は、maxcommandchainlength だけ見ていると原因を見落とすことがあります。

動かない時は、次の両方を確認しましょう。

/gamerule maxcommandchainlength
/gamerule functioncommandlimit

コマンドブロック主体なら maxcommandchainlength、function主体なら functioncommandlimit も見る。
このくらいの感覚で覚えておくと分かりやすいです。

9. 動かない・重い時のチェックポイント

ここまで読んでも、実際のワールドではいろいろな原因で動かないことがあります。
そんな時は、下のチェックリストを使ってください。

コマンドが途中で止まる場合

  • [ ] Java版1.21.11以降なのに、旧名 maxCommandChainLength で入力していないか？
  • [ ] Java版1.21.10以前なのに、新名 minecraft:max_command_sequence_length で説明を読んで混乱していないか？
  • [ ] 統合版で maxcommandchainlength が0や極端に低い値になっていないか？
  • [ ] チェーンコマンドブロックの向きは正しいか？
  • [ ] チェーンコマンドブロックが「常時実行」になっているか？
  • [ ] 条件付きにしている場合、前のコマンドが成功しているか？
  • [ ] functionの中でさらに大量のfunctionを呼んでいないか？

ワールドが重い場合

  • [ ] 毎tickで @e 全検索をしていないか？
  • [ ] type= や distance= で対象を絞っているか？
  • [ ] 広範囲のブロック検知を毎tickで回していないか？
  • [ ] 常時実行コマンドが多すぎないか？
  • [ ] Java版なら /schedule で処理を分散できないか？
  • [ ] 統合版なら Delay in Ticks を入れられないか？
  • [ ] デバッグ用の say や tellraw が残っていないか？

サーバーで問題が出る場合

  • [ ] シングルでは軽いが、マルチで重くなっていないか？
  • [ ] 複数人分の処理が毎tick走っていないか？
  • [ ] 常時読み込みチャンクで重い処理をしていないか？
  • [ ] 権限レベルの関係で、実行できないコマンドを使っていないか？
  • [ ] Java版サーバーでは、コマンドブロックの有効化設定とワールド側のゲームルールを確認したか？

特にサーバーでは、自分1人のワールドより影響が大きいです。
装置を入れる前に、テストワールドで確認してから本番へ持ち込むのがおすすめです。

筆者の考え
コマンド装置は、完成した瞬間よりも、あとから直す時の方が大変です。
最初から「軽くする」「分ける」「止められる」構造にしておくと、かなり安心です。

10. まとめ

以上、マイクラのコマンド実行回数制限と、tick負荷対策について解説しました。

最後に要点を整理します。

  • maxCommandChainLength は、1ティック内のコマンド連鎖数を制限する安全装置
  • Java版1.21.11以降では minecraft:max_command_sequence_length に名称変更
  • Java版1.21.10以前では maxCommandChainLength
  • 統合版のゲーム内コマンドでは maxcommandchainlength 表記を使う場面が多い
  • Java版の初期値は基本的に 65536
  • 統合版は環境によって初期表示が異なることがあるため、変更前に現在値を確認しておくと安全
  • 上限を上げる前に、まずコマンド設計を見直す
  • tick負荷対策は、1ティック内に詰め込む処理を減らすことが重要
  • @e 全検索、広範囲検知、functionの入れ子は重くなりやすい
  • Java版は /schedule、統合版は Delay in Ticks を使うと処理を分散しやすい

コマンド装置は、動いた瞬間は嬉しいですが、常時稼働させると負荷の問題が出ることがあります。
特に、拠点やサーバーで長く使う装置なら、毎tickで本当に必要か？を一度考えるだけでかなり変わります。

初心者さん向けに言うなら、基本方針はこれです。

上限を上げるより、処理回数を減らす。
対象を絞る。
毎tick実行を避ける。

この3つを守るだけでも、コマンド装置はかなり安定します。

よかったら皆さんも、今作っているコマンドブロック装置やデータパックを一度見直してみてくださいね。

では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にもマイクラの仕様解説や便利装置を紹介しているので、是非ご覧くださいね(^^♪

11. 参考文献

この記事を書くにあたり、以下の公式ドキュメント・コミュニティWikiを参考にしています。