
この記事はJava版のゲームルール解説です
Java版1.21.11以降では、旧名maxCommandChainLengthではなくminecraft:max_command_sequence_lengthを使います
初期値は65536です。基本的には変更しなくても大丈夫です
こんにちは。ゆずかきです。
マイクラでコマンドブロックやデータパックを触っていると、たまに出てくるのが、
max_command_sequence_lengthって結局なに?という疑問です。
名前だけ見ると、
- コマンドの文字数制限?
- コマンドブロックを置ける数の制限?
- チェーンコマンドブロックだけの制限?
- データパックのfunctionにも関係ある?
…と、かなり紛らわしいですよね。
結論から言うと、minecraft:max_command_sequence_lengthは、1ティック内にどこまでコマンド連鎖を実行していいかを決めるゲームルールです。
コマンドの文字数ではなく、実行されるコマンド処理の長さ・回数側の上限ですね。
普段のサバイバルではほぼ触りません。
ただし、コマンドブロック装置・配布マップ・データパック・ミニゲーム制作をする方にとっては、かなり重要な項目です。
この記事を読めば、次のことが分かるようになります。
max_command_sequence_lengthの意味が分かります👍- 初期値65536の理由と、基本的に変えなくて良い理由が分かります👌
- Java版1.21.11以降と、それ以前のコマンド名の違いで迷わなくなります
- コマンドブロック・function・executeで上限に引っかかる場面を判断できます
それでは、やっていきましょう!
※本記事はJava版のゲームルールを前提にしています。
※Java版1.21.11以降ではゲームルール名が変更されています。
※コマンド仕様はアップデートで変わる場合があるため、末尾の公式情報・英語版Minecraft Wikiもあわせて確認しています。
目次
1. max_command_sequence_lengthとは
2. 初期値と基本データ
3. 確認コマンドと変更コマンド
4. Java版1.21.11以降で名前が変わった点
5. 何が「コマンド連鎖」として数えられる?
6. 上限に引っかかりやすい具体例
7. 数値を上げる時・下げる時の注意点
8. コマンドブロック装置での考え方
9. function・executeを使う時の考え方
10. よくある勘違い
11. まとめ
12. 参考文献
この記事で分かること
・Java版のminecraft:max_command_sequence_lengthの意味
・初期値65536と変更コマンド
・旧名maxCommandChainLengthとの違い
・コマンドブロックやデータパックで注意するポイント

1. max_command_sequence_lengthとは
minecraft:max_command_sequence_lengthは、1ティック内に実行できるコマンド連鎖の長さを制限するゲームルールです。
マイクラは通常、1秒間に20ティック進みます。
つまり1ティックは約0.05秒です。
この短い1ティックの中で、コマンドブロックやfunctionが無限に次のコマンドを呼び続けると、ワールドやサーバーが重くなったり、最悪止まったりします。
そこで、1ティック内に実行してよいコマンド処理の上限として用意されているのが、このゲームルールです。
イメージとしては、こんな感じです。
コマンド装置が暴走しないようにする安全装置
長すぎるコマンド連鎖を1ティック内でどこまで許可するか決める設定
ですね。
たとえば、チェーンコマンドブロックを大量に並べたり、functionの中からさらにfunctionを呼び出したり、execute as @eのように大量の対象へコマンドを分岐させたりすると、この上限が関係してきます。
逆に、普通にサバイバルで遊ぶだけなら、ほぼ気にしなくて大丈夫です。

2. 初期値と基本データ
まずは、基本データを整理しますね。
| 項目 | 内容 |
|---|---|
| 正式名(Java版1.21.11以降) | minecraft:max_command_sequence_length |
| 旧名(Java版1.21.10以前) | maxCommandChainLength |
| 初期値 | 65536 |
| 値の種類 | 整数 |
| 最小値 | 0 |
| 主な対象 | コマンドブロックの連鎖、function、executeなど |
| 変更の必要性 | 通常プレイではほぼ不要 |
初期値の65536はかなり大きい数字です。
普通にコマンドブロックを数個〜数十個並べる程度なら、まず上限に届きません。
なので、初心者さん向けに言うなら、基本方針はこれです。
よく分からないうちは変更しない
エラーが出た時だけ確認する
配布マップやデータパックの説明で指定されている場合だけ変更する
これで大丈夫です。
筆者としても、このゲームルールは「便利にする設定」というより、重すぎるコマンド処理を止めるための安全ラインとして見ています。
むやみに上げれば良いものではないので、そこは注意してくださいね。

3. 確認コマンドと変更コマンド
ここでは、実際に使うコマンドを紹介します。
Java版1.21.11以降では、正式にはminecraft:付きの名前を使います。
現在の値を確認するコマンド
/gamerule minecraft:max_command_sequence_length
このコマンドを実行すると、今のワールドで設定されている値が表示されます。
初期状態なら、基本的には65536と表示されます。
値を変更するコマンド
たとえば、上限を100000に変更したい場合はこうです。
/gamerule minecraft:max_command_sequence_length 100000
初期値に戻したい場合は、次のようにします。
/gamerule minecraft:max_command_sequence_length 65536
Java版1.21.10以前の場合
Java版1.21.10以前では、ゲームルール名が旧形式なので、こちらを使います。
/gamerule maxCommandChainLength
変更する場合はこちらです。
/gamerule maxCommandChainLength 65536
注意!
Java版1.21.11以降で旧名を使うと、環境によっては候補に出なかったり、コマンドとして通らなかったりします。
逆に、古いバージョンで新名を入れても通らないので、まずは自分のワールドのバージョンを確認しましょう。
サーバーコンソールから実行する場合
ゲーム内チャットなら、先頭に/を付けます。
/gamerule minecraft:max_command_sequence_length 65536
一方、サーバーのコンソールから実行する場合は、環境によって先頭の/を付けずに入力します。
gamerule minecraft:max_command_sequence_length 65536
レンタルサーバーや管理パネルによって入力欄の仕様が違うので、ここはサーバー側の説明も見てくださいね。

4. Java版1.21.11以降で名前が変わった点
ここはかなり大事です。
Java版1.21.11で、ゲームルールはレジストリ化され、名前の形式が大きく変わりました。
その流れで、maxCommandChainLengthも次のように変更されています。
maxCommandChainLength ↓ minecraft:max_command_sequence_length
つまり、古い記事や動画で、
/gamerule maxCommandChainLength 65536
と紹介されていても、Java版1.21.11以降では、基本的に次の形で覚えておくのがおすすめです。
/gamerule minecraft:max_command_sequence_length 65536
表にすると、こんな感じです。
| バージョン | 使うゲームルール名 |
|---|---|
| Java版1.21.10以前 | maxCommandChainLength |
| Java版1.21.11以降 | minecraft:max_command_sequence_length |
| Java版26.1以降 | minecraft:max_command_sequence_length側で考える |
ここでややこしいのが、検索すると新旧どちらの名前も出てくることです。
特にmaxCommandChainLengthは昔から使われていた名前なので、古いコマンド解説記事ではまだ普通に出てきます。
ただ、これから新しく記事を読む方・ワールドを作る方は、Java版1.21.11以降の新名を基準に覚えた方が安全です。
覚え方
旧名:maxCommandChainLength
新名:minecraft:max_command_sequence_length
どちらも「コマンド連鎖の上限」を指すものです。

5. 何が「コマンド連鎖」として数えられる?
max_command_sequence_lengthで一番つまずきやすいのが、何を1つとして数えるのかです。
昔の感覚だと、チェーンコマンドブロックを何個つなげたか、だけを見れば良さそうに思えます。
でも現在のJava版では、それだけではありません。
この上限には、主に次のような処理が関係します。
- 1つの実行文脈でのコマンド実行
execute内の処理段階- functionの呼び出し
- function内で実行されるコマンド
つまり、見た目のコマンド行数が少なくても、実際の実行数が多ければ上限に近づくことがあります。
たとえば、次のようなコマンドを考えます。
execute as @e[type=minecraft:armor_stand] run function sample:tick
これ自体は1行です。
でも、対象の防具立てが100体いれば、sample:tickが100回分の文脈で走る可能性があります。
さらに、そのfunctionの中で複数のコマンドを実行していたら、処理数は一気に増えます。
ここが大事です。
コマンドが1行だから軽い、とは限りません。
対象が多いexecuteや、functionの入れ子は、見た目以上に処理が増えます。
なお、Java版1.20.3以降では、functionまわりの上限チェックが整理され、executeの段階、functionの呼び出し、1つの実行文脈でのコマンド実行などが意識されるようになっています。
また、execute as @e at @eのように実行文脈そのものを大量に作る処理には、別のゲームルールであるminecraft:max_command_forksも関係します。
コマンド勢の方ほど、このあたりで引っかかることがあると思います。
特にミニゲーム制作や配布ワールド制作で、毎tick大量に処理する仕組みを組んでいる場合は注意しましょう。

6. 上限に引っかかりやすい具体例
では、どういう時にmax_command_sequence_lengthが問題になりやすいのか。
よくある例を順番に見ていきますね。
1. チェーンコマンドブロックを大量に並べている
一番分かりやすいのはこれです。
インパルスコマンドブロックから始まり、チェーンコマンドブロックを大量につなげて、1回の起動で何百・何千ものコマンドを流す装置です。
通常の小規模装置なら問題になりません。
ただし、配布マップの演出、巨大なミニゲーム装置、ワールド制御装置などでは、かなり長いコマンド列になることがあります。
2. リピートコマンドブロックから毎tick実行している
リピートコマンドブロックは、条件を満たす限り毎tickコマンドを実行します。
1個だけなら軽くても、
- 複数のリピートコマンドブロック
- その先にチェーンコマンドブロック
- さらに
execute as @eで大量分岐
という構造になると、一気に重くなります。
体験的に注意したいところ
「動くから大丈夫」で増やしていくと、あとからどこが重いのか分かりにくくなります。
リピート処理は、最初から少し控えめに設計した方が安定します。
3. functionの中からfunctionを呼び出している
データパックでよくある構成です。
function sample:main
このmainの中で、さらに、
function sample:player_check function sample:mob_check function sample:score_update function sample:effect
のように複数のfunctionを呼び出すことがあります。
これ自体は悪いことではありません。
むしろ整理された良い書き方です。
ただし、呼び出しが深くなりすぎたり、毎tick実行されたり、対象が大量に分岐したりすると、上限に近づきやすくなります。
4. executeで対象を増やしすぎている
execute as @eは便利ですが、扱い方を間違えると重くなりやすいです。
たとえば、ワールド内の全エンティティを対象にして、さらに別の全エンティティを参照するような書き方をすると、対象数が掛け算で増えることがあります。
execute as @e at @e run say test
このような書き方は、検証用ならまだしも、実運用ではかなり危険です。
対象が増えれば増えるほど、処理数や実行文脈も増えていきます。
対策としては、
type=で対象を絞るtag=で対象を絞るlimit=を使うdistance=で範囲を絞る- 毎tickではなく数tickごとに分ける
などが有効です。

7. 数値を上げる時・下げる時の注意点
max_command_sequence_lengthは数値を変更できます。
ですが、上げれば上げるほど良いというものではありません。
数値を上げるメリット
数値を上げると、1ティック内に許可されるコマンド連鎖の上限が増えます。
そのため、
- 大規模なコマンドブロック装置を動かしたい
- 大きめの配布マップで指定されている
- データパックのfunctionが途中で止まる
- 検証ワールドで大量処理を試したい
という時には役立つ場合があります。
数値を上げるデメリット
一方で、上限を上げすぎると、暴走したコマンド処理を止めにくくなります。
マイクラ側から見ると、
「本来ならここで止めていた長すぎる処理を、もっと実行してよい」
という設定になるからです。
その結果、ワールドやサーバーが重くなったり、tick遅延が起きたりする可能性があります。
特にマルチサーバーでは、自分だけでなく他の参加者にも影響が出ます。
数値を下げるメリット
逆に数値を下げると、長すぎるコマンド連鎖を早めに止められます。
検証ワールドで、あえてコマンド暴走を早く見つけたい場合には使えます。
ただし、普通のワールドで下げすぎると、正常なコマンド装置まで途中で止まる可能性があります。
おすすめの考え方
個人的には、次の考え方がおすすめです。
通常は初期値65536のまま
配布マップやデータパックの説明で指定がある時だけ変更
上げる前に、まずコマンド側を軽くできないか見る
まずは設計を見直しましょう。
それでも足りない時に、必要な分だけ上げるのが安全です。

8. コマンドブロック装置での考え方
コマンドブロックでこのゲームルールを見る時は、チェーンの長さと毎tick実行の重さを分けて考えると分かりやすいです。
チェーンコマンドブロックの場合
チェーンコマンドブロックは、前のコマンドブロックから処理を受け取って、次々と実行されます。
たとえば、
インパルス → チェーン → チェーン → チェーン → チェーン
のように並べれば、1回の起動で連続して処理されます。
この連続処理が長くなりすぎると、max_command_sequence_lengthの制限が関係してきます。
ただ、普通に10個〜100個くらいの小規模装置を作る程度なら、初期値の65536に届くことはまずありません。
リピートコマンドブロックの場合
リピートコマンドブロックは毎tick実行されるため、上限そのものよりも、毎tickの負荷に注意した方が良いです。
たとえば、
execute as @e run effect give @s minecraft:glowing 1 0 true
のような処理を毎tick実行すると、対象エンティティが多いほど重くなります。
装置が小さいうちは問題なくても、拠点が育って村人・モブ・アイテムが増えると急に重くなることがあります。
対策としては、
- 毎tick実行しなくていい処理は間隔を空ける
- 対象を
tagで管理する distanceで範囲を絞る- 不要になったエンティティを消す
このあたりが大事です。
注意!
max_command_sequence_lengthを上げても、根本的な重さが消えるわけではありません。
重いコマンドを許可するだけなので、装置設計の見直しは別で必要です。

9. function・executeを使う時の考え方
データパック勢の方は、コマンドブロックよりもこちらの方が重要かもしれません。
Java版では、functionやexecuteの処理も、この上限に関係します。
特にJava版1.20.3以降は、function周りの制限の数え方が整理され、1つの実行文脈でのコマンド実行、executeの段階、function呼び出しも意識する必要があります。
また、executeで作られる実行文脈の数そのものには、minecraft:max_command_forksという別のゲームルールも関係します。
minecraft:max_command_sequence_lengthだけで全部を判断するのではなく、重いexecuteを書いている時は、実行文脈が増えすぎていないかも見た方が安全です。
functionは整理に便利だけど、呼び出しすぎに注意
functionは、コマンドをファイルにまとめられる便利な仕組みです。
たとえば、次のように分けると管理しやすいですよね。
sample:tick sample:player/main sample:player/effect sample:mob/check sample:system/timer
このように分けるのは良い書き方です。
ただし、毎tickの入口から大量のfunctionを呼び出すと、当然その分だけ実行処理は増えます。
execute as @a はまだ良いが、@eは注意
@aはプレイヤー全員が対象です。
マルチでも、人数がある程度見えやすいですよね。
一方、@eは全エンティティです。
村人、動物、モンスター、防具立て、アイテム、矢、ボート、トロッコなど、かなり多くのものが対象になり得ます。
そのため、
execute as @e run function sample:entity_tick
のような処理は、必ず対象を絞った方が安全です。
execute as @e[type=minecraft:armor_stand,tag=sample_target] run function sample:entity_tick
このように、typeとtagを使えば、かなり安全になります。
分岐は掛け算で増えることがある
特に注意したいのが、execute asとatを重ねる書き方です。
対象Aが10体、対象Bが10体いる状態で、AとBを組み合わせるような処理をすると、10回ではなく100回分に近い処理になることがあります。
これが、コマンドが重くなる典型例です。
コマンドが短い=軽い、ではありません。
対象数と分岐数で、処理量は大きく変わります。
ここを理解しておくと、max_command_sequence_lengthで詰まった時も原因を探しやすくなります。

10. よくある勘違い
ここでは、max_command_sequence_lengthまわりでよくある勘違いを整理します。
勘違い1:コマンドの文字数制限だと思っている
これはかなり多いです。
max_command_sequence_lengthは、コマンドの文字数上限ではありません。
1ティック内に実行されるコマンド連鎖の上限です。
コマンドブロックに入力できる文字数制限とは別物です。
長い/summonや長いJSONテキストが入らない場合は、こちらのゲームルールを変更しても解決しません。
ここ重要です
長いコマンドが入力できない問題
→ コマンド文字数・入力欄側の問題コマンド連鎖が途中で止まる問題
→max_command_sequence_lengthが関係する可能性あり
この2つは別で考えましょう。
勘違い2:上げればコマンド装置が軽くなると思っている
これも違います。
数値を上げると、より長いコマンド連鎖を許可できます。
ただし、処理が軽くなるわけではありません。
むしろ、重い処理をさらに実行できるようになるので、サーバー負荷が増える可能性があります。
重い装置を直したいなら、まずは、
- 対象を絞る
- 毎tick実行を減らす
- functionの呼び出しを整理する
- 不要なエンティティを対象外にする
こちらを見直しましょう。
勘違い3:Java版1.21.10以前と同じ名前で使えると思っている
Java版1.21.11以降では、ゲームルール名が変わっています。
古い記事のmaxCommandChainLengthをそのまま打っても、現在の環境では通らないことがあります。
今後のJava版では、次の名前で覚えるのがおすすめです。
/gamerule minecraft:max_command_sequence_length 65536
勘違い4:統合版と完全に同じだと思っている
統合版にも似たゲームルールがありますが、Java版とは仕様や挙動、コマンド名の扱いが違う場合があります。
この記事はJava版向けです。
統合版サーバーやRealmsで設定する場合は、必ず統合版側の仕様を確認してくださいね。

11. まとめ
以上、minecraft:max_command_sequence_lengthの意味・初期値・コマンド連鎖上限について解説しました。
要点を整理すると、
minecraft:max_command_sequence_lengthは、1ティック内に実行できるコマンド連鎖の長さを制限するゲームルール- 初期値は65536
- Java版1.21.10以前の旧名はmaxCommandChainLength
- Java版1.21.11以降ではminecraft:max_command_sequence_lengthを使う
- コマンドの文字数制限ではない
- コマンドブロック、function、executeの大量分岐で関係しやすい
executeで実行文脈を大量に作る場合は、minecraft:max_command_forksも関係する- 基本的には初期値のままでOK
- 上げる前に、まずコマンド装置やデータパック側を軽くする方が大事
という感じです。
通常プレイではほぼ触らないゲームルールですが、コマンドブロック装置やデータパックを作る方には重要な設定です。
特にJava版1.21.11以降は名前が変わっているので、古い記事を見ながら作業している方はここだけ注意してください。
最後にもう一度、基本コマンドを載せておきます。
/gamerule minecraft:max_command_sequence_length
/gamerule minecraft:max_command_sequence_length 65536
まずは初期値65536で運用。
どうしても必要な時だけ、原因を確認したうえで変更しましょう。
では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にもマイクラのゲームルールやコマンド解説をまとめているので、是非ご覧くださいね(^^♪

12. 参考文献
この記事を書くにあたり、以下の公式情報・英語版Minecraft Wiki・サーバー向け解説ページを参考にしています。
- Minecraft公式(Minecraft Java Edition 26.1)
- Minecraft公式(Minecraft Java Edition 26.1.1)
- Minecraft公式(Minecraft Java Edition 1.21.11)
- Minecraft Feedback(Java Edition 1.21.11 - Game Rules)
- Minecraft公式(Minecraft Java Edition 1.20.3)
- Minecraft Wiki(Game rule)
- Minecraft Wiki(Function / Java Edition)
- Minecraft Wiki(Command Block)
- BisectHosting(How to Set Game Rules on a Minecraft Server)