【マイクラ】コマンド権限レベル一覧|実行条件・OP・チート設定まとめ【Java/統合版】

Java版と統合版では、同じ「OP」でも中身がけっこう違います
サーバーでOPを渡す前に、レベル2・3・4の違いだけは必ず確認してください
コマンドブロックやfunctionで動かないコマンドがある理由も、ここで整理します

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

マイクラでサーバーを立てたり、友達とワールドを遊んでいると、

/tp は使えるのに /op は使えない」
「OPにしたはずなのに、一部のコマンドだけ通らない」
「コマンドブロックで実行できるコマンドと、できないコマンドがある」

こういう場面に出会うことがあります。

これ、原因はだいたい コマンド権限レベル です。

マイクラのコマンドは、ただチートをオンにすれば全部使える…という単純な仕組みではありません。
特にJava版サーバーでは、OP権限にもレベルがあり、誰にどこまで許可するかをかなり細かく分けられます。

逆にここを知らずに全員へ強いOPを渡すと、

  • /give でアイテムを自由に出せる
  • /gamemode でゲームモードを変えられる
  • /ban/kick で他プレイヤーを操作できる
  • /stop でサーバーを停止できる

…という状態になります。

身内サーバーでも、これはけっこう危ないです。
悪意が無くても、コマンド練習中にワールドを壊したり、サーバーを止めたりする事故は普通に起きます。

この記事では、Java版・統合版のコマンド権限レベルを、実際にサーバー運営で使う目線で整理していきますね。

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

  • Java版の権限レベル0〜4の違い
  • op-permission-level の設定方法
  • コマンドブロックやfunctionの実行権限
  • 統合版の「訪問者・メンバー・オペレーター」と内部権限の違い
  • OPを渡す時にどのレベルが安全か

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

※本記事はJava版1.21.11〜26.1.2、および統合版1.26.20系の公開情報を確認して整理しています。
※コマンド仕様はバージョン更新で変わる場合があります。特に新規追加コマンドは、最新のコマンド一覧も併せて確認してください。
※本記事では初心者さんでも判断しやすいように、細かい内部仕様よりも「実際に何ができるか」を優先して解説します。


目次

1. コマンド権限レベルとは
2. Java版のコマンド権限レベル一覧
3. Java版で実行者ごとに何レベルになる?
4. op-permission-levelとは?OP権限の強さを決める設定
5. function-permission-levelとは?データパックを使う人は要注意
6. コマンドブロックで実行できないコマンドがある理由
7. 統合版の権限レベル一覧|Java版とは考え方が違います
8. チート設定とコマンド権限の違い
9. サーバー運営でおすすめの権限設定
10. よくあるトラブルと対処法
11. まとめ
12. 参考文献

この記事で分かること
・Java版のOP権限レベル0〜4の違い
・統合版の権限レベルと「訪問者・メンバー・オペレーター」の違い
・コマンドブロック、function、server.properties周りの実用的な注意点


1. コマンド権限レベルとは

コマンド権限レベルとは、簡単に言うと、そのプレイヤーや実行者がどこまで強いコマンドを使えるかを決める仕組みです。

マイクラのコマンドには、誰でも使えるものもあれば、OPやサーバー管理者でないと使えないものもあります。

例えば、

  • /help
  • /list
  • /msg

このあたりは、基本的に強い管理権限がなくても使えるコマンドです。

一方で、

  • /give
  • /gamemode
  • /tp
  • /setblock
  • /ban
  • /op
  • /stop

このあたりは、ワールドやサーバーに大きな影響を与えます。
そのため、一定以上の権限がないと実行できません。

ここで大事なのが、OP=全部同じ強さではないという点です。

Java版の専用サーバーでは、OPにもレベルがあり、server.propertiesop-permission-levelops.json によって強さが変わります。

体験談
筆者も最初は「OPにしたら全部同じ」と思っていました。
でも実際は、OPレベル2だと /give/tp は使えても、/ban/op は使えない…ということが普通にあります。
サーバー管理をするなら、ここは最初に理解しておくのがおすすめです。

また、コマンドを実行するのはプレイヤーだけではありません。

  • プレイヤーのチャット入力
  • コマンドブロック
  • コマンドブロック付きトロッコ
  • データパックのfunction
  • サーバーコンソール
  • 統合版のビヘイビアーパックやスクリプト

こうした実行者にも、それぞれ権限レベルがあります。

つまり、同じコマンドでも、誰が実行するかによって成功したり失敗したりするということですね。


2. Java版のコマンド権限レベル一覧

まずはJava版から見ていきましょう。

Java版のコマンド権限レベルは、基本的に 0〜4 の5段階です。
数字が大きいほど強い権限で、上位レベルは下位レベルの権限も含みます。

権限レベル 呼び方 主な意味 代表例
0 全員 通常プレイヤーでも使える範囲 /help/list/msg など
1 モデレーター相当 スポーン保護を回避できる コマンド目的ではかなり限定的
2 ゲームマスター相当 多くの通常コマンドを使える /give/tp/gamemode/setblock など
3 管理者相当 マルチプレイ管理系コマンドを使える /ban/kick/op/deop など
4 所有者相当 サーバー管理系を含む全体権限 /stop/save-all/save-off など


かなり大事なのは、レベル2とレベル3の境目です。

レベル2になると、サバイバル生活で使うような便利コマンドはかなり使えます。
たとえば、/tp/give/gamemode/gamerule/summon/setblock などですね。

ただし、レベル2では基本的にサーバー管理系までは触れません。
/ban/kick/op のような、他プレイヤーやOP権限そのものに関わるコマンドは、より高い権限が必要になります。

個人的には、身内サーバーで「建築補助や検証用にコマンドを使わせたい」くらいなら、まずはレベル2で十分だと思います。

逆に、レベル3以上はかなり強いです。
他プレイヤーをBANしたり、別の人へOPを付与したりできるので、管理を任せられる人だけに渡しましょう。

レベル4は、サーバー停止や保存周りまで触れる最上位です。
これは基本的に、サーバー主だけでOKです。


3. Java版で実行者ごとに何レベルになる?

次に、Java版で「誰がコマンドを実行するか」による権限レベルを整理します。

コマンド権限は、プレイヤーだけでなく、コマンドブロックやfunctionにも関係します。
ここを理解しておくと、コマンド装置づくりでかなり迷いにくくなります。

実行者 Java版での権限レベル 補足
通常プレイヤー 0 チート無し・OP無しなら基本はここ
専用サーバーのOPプレイヤー 設定次第 ops.jsonop-permission-level の値に従う
シングルプレイでチート有効のプレイヤー 4 ソロ検証ではほぼ全権限として扱える
LAN公開でチート許可されたプレイヤー 4 一時的に強い権限でコマンド使用可能
コマンドブロック 2 多くの装置用コマンドは動くが、管理系は基本不可
コマンドブロック付きトロッコ 2 通常のコマンドブロックと同じ扱い
function 初期値2 function-permission-level で変更可能
サーバーコンソール 4 サーバー側の最上位実行者


ここで初心者さんがハマりやすいのは、Java版のコマンドブロックはレベル2相当というところです。

なので、

  • /tp
  • /give
  • /summon
  • /setblock
  • /fill
  • /scoreboard

このあたりは装置でよく使えます。

一方で、

  • /op
  • /deop
  • /ban
  • /kick
  • /stop
  • /save-off

こういう管理者向けのコマンドは、コマンドブロックからは基本的に実行できません。

重要
コマンドブロックで「構文は合っているのに動かない」場合、コマンドの書き方ではなく、権限レベル不足が原因のことがあります。
エラー文だけ見て悩むより、まず「そのコマンドはレベル2で実行できるのか?」を疑うと早いです。


4. op-permission-levelとは?OP権限の強さを決める設定

Java版の専用サーバーでOPの強さを決める代表的な設定が、server.propertiesop-permission-level です。

初期値は基本的に、

op-permission-level=4

です。

つまり、何も考えずに /op プレイヤー名 でOPを付与すると、かなり強い権限を渡すことになります。

個人サーバーで自分だけがOPなら問題ないですが、友達にもOPを渡す場合は注意です。

op-permission-levelの設定例

op-permission-level=2

このようにすると、新しくOPにしたプレイヤーの標準権限をレベル2にできます。

レベル2なら、/tp/give などの便利コマンドは使えますが、/op/ban のような管理系は基本的に使えません。

身内サーバーでよくある用途なら、

  • 建築補助で /fill を使いたい
  • 座標移動で /tp を使いたい
  • 検証用に /give を使いたい
  • コマンドブロックを触りたい

このくらいなら、レベル2が現実的です。

既にOPになっている人はops.jsonも確認

ここは少しややこしいです。

op-permission-level は、主に新しくOPを付与する時の標準値として考えると分かりやすいです。
既にOPになっているプレイヤーは、サーバーフォルダ内の ops.json に権限レベルが保存されている場合があります。

そのため、

op-permission-level=2 にしたのに、既存OPがレベル4のまま」

という状況も起こりえます。

この場合は、サーバーを停止したうえで ops.json を確認し、対象プレイヤーの level を調整する必要があります。

例としては、こういうイメージです。

[
  {
    "uuid": "プレイヤーのUUID",
    "name": "PlayerName",
    "level": 2,
    "bypassesPlayerLimit": false
  }
]

level がOP権限レベルです。

注意!
ops.json を編集する時は、必ずサーバーを停止してから作業しましょう。
起動中に編集すると反映されなかったり、ファイルが上書きされたりする場合があります。

おすすめ設定

筆者の感覚では、サーバーの用途ごとにこうです。

サーバーの使い方 おすすめOPレベル 理由
完全ソロ・自分だけ 4 自分しか触らないなら管理効率優先でOK
身内サバイバル 2 便利コマンドは使えて、管理事故を減らせる
共同管理者あり 3 BAN・KICKなどを任せるなら必要
公開サーバー 人によって分ける 管理担当だけ高権限、一般スタッフは低めが安全


サーバー主以外へいきなりレベル4を渡すのは、あまりおすすめしません。
レベル4はサーバー停止まで触れるので、実質的に所有者権限です。


5. function-permission-levelとは?データパックを使う人は要注意

データパックを使う方は、function-permission-level も確認しておきましょう。

これは、Java版サーバーの server.properties にある設定で、functionがどの権限レベルで実行されるかを決めます。

初期値は基本的に、

function-permission-level=2

です。

つまり、通常のfunctionはレベル2相当として実行されます。

functionの初期レベル2でできること

レベル2なら、たとえば次のようなコマンドは扱いやすいです。

  • /execute
  • /summon
  • /setblock
  • /fill
  • /scoreboard
  • /tag
  • /effect
  • /playsound
  • /title

配布マップやミニゲーム、便利データパックの多くは、この範囲で動きます。

functionで動かないことがあるコマンド

一方で、レベル3以上が必要なコマンドは、初期設定のfunctionでは動かないことがあります。

代表的に注意したいのは、管理者寄りのコマンドです。

  • /ban
  • /kick
  • /op
  • /deop
  • /tick

特に /tick は、検証ワールドやデータパック制作で使いたくなる場面があります。
ただし、コマンドブロックや初期設定のfunctionからは権限不足になりやすいので注意してください。

サーバーでfunctionから高権限コマンドを実行したい場合は、server.properties を変更します。

function-permission-level=3

このように設定すれば、functionの実行権限をレベル3にできます。

ただし、これは便利な反面、データパックへ強い権限を渡すことになります。
配布データパックを入れるサーバーでは、内容をよく確認してから設定してください。

筆者の考え
自作データパックだけを使うなら、必要に応じてレベル3にするのはありです。
でも、配布データパックを複数入れるサーバーで安易に上げるのは怖いです。
functionが強すぎると、意図しない管理コマンドまで実行できてしまう可能性があります。

シングルプレイでは変更しにくい

function-permission-level は、基本的にサーバー用の server.properties の設定です。
シングルプレイの通常ワールドでは、同じ感覚で簡単に変更できるものではありません。

そのため、データパック検証で高いfunction権限が必要な場合は、ローカルでJava版サーバーを立てて、そこへ接続して試す方が安定します。


6. コマンドブロックで実行できないコマンドがある理由

コマンドブロックは、マイクラの装置づくりでとても便利です。
でも、何でも実行できるわけではありません。

Java版では、コマンドブロックの権限レベルは 2 です。

そのため、レベル2までのコマンドなら動かせますが、レベル3以上が必要なコマンドは基本的に動かせません。

コマンドブロックで使いやすいコマンド例

  • /execute
  • /tp
  • /summon
  • /setblock
  • /fill
  • /clone
  • /scoreboard
  • /tag
  • /title
  • /playsound

このあたりは、配布マップやアドベンチャーマップ、ミニゲーム装置でよく使います。

コマンドブロックで基本的に向かないコマンド例

  • /op
  • /deop
  • /ban
  • /kick
  • /stop
  • /save-all
  • /save-off
  • /tick

これらは、サーバー管理やワールド全体の制御に近いコマンドです。
コマンドブロックから自由に実行できてしまうと危険なので、制限されていると考えると分かりやすいですね。

よくある勘違い
「自分がOPレベル4だから、置いたコマンドブロックもレベル4で動く」と思いがちですが、そうではありません。
コマンドブロックは、プレイヤー本人の権限ではなく、コマンドブロック自身の権限で実行されます。

まず確認すること

コマンドブロックが動かない時は、次の順で見直しましょう。

  • [ ] enable-command-block=true になっているか?
  • [ ] コマンドの構文が正しいか?
  • [ ] 実行対象のセレクターが正しいか?
  • [ ] レッドストーン信号や常時実行の設定が正しいか?
  • [ ] そのコマンドがレベル2で実行可能か?

特にサーバーでは、server.properties のこの設定も見てください。

enable-command-block=true

これが false のままだと、そもそもコマンドブロックが使えません。


7. 統合版の権限レベル一覧|Java版とは考え方が違います

次に、統合版です。

統合版にも内部的なコマンド権限レベルはありますが、Java版と同じ感覚で見ると少し混乱します。

統合版では、一般プレイヤー目線だと、ワールドのプレイヤー権限として、

  • 訪問者
  • メンバー
  • オペレーター
  • カスタム

のような区分を見かけます。

ただし、これはJava版の 0〜4 のOPレベルと完全に同じものではありません。
内部的なコマンド権限レベルとしては、次のように整理されます。

内部レベル 公式ドキュメント上の呼び方 主な意味 補足
0 Any 誰でも実行できる範囲 通常プレイヤー相当
1 GameDirectors オペレーターとコマンドブロックが使える範囲 統合版のコマンドブロックはこの扱い
2 Admin オペレーターは使えるが、コマンドブロックでは使えない範囲 自動実行環境では制限されるコマンドが出る
3 Host サーバーホストが使える範囲 ホスト権限が必要なコマンド向け
4 Owner 専用サーバー側の最上位権限 専用サーバー側でのみ実行できる範囲


統合版で重要なのは、コマンドブロックの権限がJava版より低めに扱われるところです。

Java版のコマンドブロックはレベル2ですが、統合版ではコマンドブロックやfunction、アドオンのスクリプトはレベル1相当です。
そのため、統合版では「オペレーターなら実行できるけど、コマンドブロックでは無理」というコマンドが出てきます。

例として、/setmaxplayers のようなコマンドは、統合版ではコマンドブロックから実行できない代表例として知られています。

統合版サーバーの初期プレイヤー権限

統合版の専用サーバーでは、server.properties に次の設定があります。

default-player-permission-level=member

これは、新しく参加したプレイヤーを、最初にどの権限で扱うかを決める設定です。

使える値は、主に次の3つです。

設定値 意味 使いどころ
visitor 訪問者 見学用。ブロック破壊や設置を制限したい時
member メンバー 通常参加者。基本はこれでOK
operator オペレーター 管理者向け。全員に設定するのは非推奨


普通のサバイバルサーバーなら、初期値は member で十分です。
operator を初期値にすると、新規参加者が強い権限を持ってしまうので、公開サーバーでは避けましょう。


8. チート設定とコマンド権限の違い

ここも混乱しやすいので、丁寧に整理します。

マイクラでは、チート設定権限レベルは似ていますが、同じではありません。

Java版シングルプレイ

Java版のシングルプレイでは、ワールド作成時に「チートを許可」をオンにすると、プレイヤーは強い権限でコマンドを使えます。

もしワールド作成時にオフにした場合でも、ゲームメニューから、

Esc → LANに公開 → チートを許可:オン → LANワールドを開始

という手順で、一時的にコマンドを使えるようにできます。

この方法は検証に便利です。
ただし、ワールドを閉じると元に戻るので、毎回必要に応じて設定する形になります。

Java版マルチプレイ

Java版の専用サーバーでは、基本的にプレイヤーがコマンドを使うにはOP権限が必要です。

ここで見るのが、

  • /op プレイヤー名
  • op-permission-level
  • ops.json

この3つです。

サーバーでは、単に「チートをオンにする」というより、誰をOPにするか、OPレベルをいくつにするかが重要になります。

統合版

統合版は、Java版より「チート」設定の影響が大きいです。

統合版では、チートをオンにすると実績が解除できなくなります。
しかも、一度チートをオンにしたワールドでは、後からオフにしても実績解除の扱いは元に戻らない点に注意してください。

また、統合版では高い権限を持っていても、チートが無効だとプレイヤーから実行できないコマンドがあります。
ここはJava版との大きな違いです。

項目 Java版 統合版
シングルでのチート一時許可 LAN公開で一時的に可能 設定から切り替え可能
チートと実績 進捗とは別扱い チート有効化で実績解除不可
サーバーでの考え方 OPレベル管理が中心 プレイヤー権限とチート設定の両方を見る
コマンドブロック レベル2相当 レベル1相当


統合版でコマンドを使う場合は、権限だけでなく、チート設定も確認しましょう。
Java版の感覚で「OPなのに使えない」と悩むと、ここで詰まりやすいです。


9. サーバー運営でおすすめの権限設定

ここからは、実際にサーバーを立てる人向けです。

筆者のおすすめは、最初から全員に強いOPを渡さないことです。

身内だけのサーバーでも、コマンド権限が強すぎると事故ります。

  • 間違えて /kill @e に近いコマンドを打つ
  • /fill の範囲指定をミスして建築が消える
  • /gamerule を戻し忘れる
  • /time set/weather を頻繁に使い、サバイバル感が崩れる
  • /stop でサーバーを止めてしまう

悪意ではなくても、こういうことは普通にあります。

Java版のおすすめ構成

個人的には、Java版サーバーなら最初はこの構成が扱いやすいです。

役割 OPレベル できること
サーバー主 4 全体管理、停止、保存、緊急対応
共同管理者 3 BAN、KICK、OP付与などの管理補助
建築・検証担当 2 TP、give、fill、gamemodeなど
通常参加者 0 通常プレイ


設定例としては、まず server.properties をこうしておくと安全寄りです。

op-permission-level=2
enable-command-block=false

コマンドブロックを使う配布マップや装置を運用する時だけ、必要に応じて、

enable-command-block=true

に変更するのが良いと思います。

共同管理者だけレベル3以上にしたい場合

全体の op-permission-level は2にしておき、共同管理者だけ ops.json でレベル3や4へ変更する方法が扱いやすいです。

これなら、間違えて普通の参加者をOPにしても、いきなりレベル4にはなりません。

体験談
筆者は、少人数サーバーでもOPレベル2運用が一番扱いやすいと感じています。
/tp/give は使えるので検証はできますし、サーバー停止やBAN周りを触れないので事故が減ります。

統合版のおすすめ構成

統合版サーバーでは、初期参加者の権限は基本 member でOKです。

default-player-permission-level=member

管理者だけ、ワールド内のプレイヤー権限画面やサーバー側の権限設定でオペレーターにしましょう。

公開サーバーや参加者が多いワールドで、初期値を operator にするのはおすすめしません。


10. よくあるトラブルと対処法

最後に、コマンド権限レベル周りでよくあるトラブルをまとめます。

OPにしたのにコマンドが使えない

まず、Java版サーバーなら op-permission-levelops.json を確認してください。

  • [ ] 本当にOPになっているか?
  • [ ] ops.jsonlevel が低すぎないか?
  • [ ] サーバー再起動後に反映されているか?
  • [ ] そのコマンドが必要とする権限レベルを満たしているか?

/tp は使えるのに /op は使えない場合、OPレベル2の可能性があります。
これは不具合ではなく、権限レベルの仕様です。

コマンドブロックが動かない

Java版サーバーでは、まず server.properties を確認しましょう。

enable-command-block=true

これが false のままだと、コマンドブロックは使えません。

それでも動かない場合は、次を見ます。

  • [ ] コマンドブロックに信号が入っているか?
  • [ ] 常時実行・レッドストーン必要の設定が合っているか?
  • [ ] コマンド構文が合っているか?
  • [ ] 実行対象が存在しているか?
  • [ ] レベル2で実行できるコマンドか?

/ban/stop のような管理系コマンドを入れている場合、コマンドブロックの権限不足で通らないと考えましょう。

functionで一部コマンドだけ動かない

functionは初期設定だとレベル2です。

そのため、レベル3以上が必要なコマンドは動かないことがあります。

サーバーで必要な場合は、

function-permission-level=3

のように変更します。

ただし、配布データパックを入れているサーバーでは慎重に。
権限を上げるほど、functionが実行できる範囲も広がります。

統合版でOPなのにコマンドが使えない

統合版では、権限だけでなくチート設定も見てください。

  • [ ] チートが有効になっているか?
  • [ ] プレイヤー権限がオペレーターになっているか?
  • [ ] そのコマンドがコマンドブロックから実行可能な種類か?
  • [ ] 専用サーバー側の権限設定が合っているか?

統合版は、Java版よりも「チート設定」と「プレイヤー権限」の両方が絡みやすいです。

/tick がコマンドブロックやfunctionで動かない

Java版の /tick は、ワールド全体の進行速度や停止に関わるかなり強いコマンドです。

そのため、コマンドブロックや初期設定のfunctionからは権限不足になりやすいです。

サーバーのfunctionでどうしても使う場合は、function-permission-level を上げる方法があります。
ただし、ワールド全体の時間制御に関わるため、配布ワールドやマルチサーバーでは慎重に使いましょう。


11. まとめ

以上、マイクラのコマンド権限レベルについて、Java版・統合版の違いも含めて整理しました。

要点をまとめると、

  • Java版の権限レベルは 0〜4
  • Java版のコマンドブロックは レベル2相当
  • Java版のfunctionは初期値 レベル2 で、function-permission-level で変更可能
  • Java版サーバーのOP標準レベルは op-permission-level で決まる
  • レベル2は便利コマンド向け、レベル3は管理者向け、レベル4は所有者向け
  • 統合版は「訪問者・メンバー・オペレーター」と内部権限レベルが完全一致ではない
  • 統合版のコマンドブロック、function、アドオンのスクリプトはレベル1相当
  • 統合版はチート設定の影響が大きく、実績解除にも関係する

このあたりを押さえておけば、サーバー運営やコマンド装置づくりでかなり迷いにくくなります。

特に大事なのは、OPを渡す時に何も考えずレベル4を配らないことです。

身内サーバーなら、まずはレベル2。
共同管理者だけレベル3。
サーバー主だけレベル4。

このくらいの分け方が、事故も少なくて扱いやすいと思います。

コマンドは便利ですが、強すぎる権限はワールドを壊す原因にもなります。
安全に使い分けながら、建築や検証、サーバー管理に活用していきましょう。

では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。


12. 参考文献

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