【マイクラ】permissionコマンドの使い方・構文・権限設定の再読み込み【統合版】

この記事はマイクラ統合版のBedrock Dedicated Server向けです
通常のソロワールド・フレンド参加ワールド・Realms向けの記事ではありません
Java版のops.jsonや権限レベルとは仕様が異なるので注意してください

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

今回は、マイクラ統合版のサーバー運用で使うことがある、/permissionコマンドについて解説します。

正直、普段のサバイバルで遊んでいるだけなら、ほぼ触らないコマンドです。
ただ、Bedrock Dedicated Server、いわゆる統合版の自前サーバーを立てている方だと、

OP権限を付けたはずなのに反映されない
permissions.jsonを編集したけどサーバーに反映されない
サーバーを再起動せずに権限設定を読み直したい
operator、member、visitorの違いが分かりづらい

こういう場面に遭遇することがあります。

その時に使うのが、今回のテーマであるpermissionコマンドです。

この記事では、/permission listと/permission reloadの使い方、permissions.jsonとの関係、OP設定で詰まりやすいポイントまで、実際のサーバー運用目線で整理していきますね。

この記事で分かること
・マイクラ統合版のpermissionコマンドの使い方
・/permission listと/permission reloadの違い
・permissions.jsonを編集した後に反映する手順
・operator、member、visitorの使い分け
・OP権限が反映されない時のチェックポイント

※本記事はBedrock Dedicated Serverの現行Stable系ドキュメントを基準に構成しています。
※ゲーム内の仕様・コマンド仕様については、公式ドキュメントとコミュニティ情報を参考にしています。
※マイクラ統合版はアップデートでコマンド仕様が変わることがあるため、サーバー更新後は必ず実機側でも確認してください。

1. permissionコマンドとは
2. permissionコマンドが使える環境
3. permissionコマンドの構文一覧
4. /permission listの使い方
5. /permission reloadの使い方
6. permissions.jsonとは
7. operator・member・visitorの違い
8. OP付与・剥奪コマンドとの違い
9. 実録：権限設定を安全に変更する手順
10. よくある失敗と対処法
11. バージョン差・古い情報の注意点
12. まとめ
13. 参考文献

1. permissionコマンドとは

/permissionコマンドは、マイクラ統合版のBedrock Dedicated Serverでプレイヤー権限を確認・再読み込みするためのコマンドです。

主な役割は、次の2つです。

現在読み込まれている権限設定を確認する
permissions.jsonを編集した後、サーバーに再読み込みさせる

普通のサバイバル攻略で使うコマンドというより、サーバー管理者向けのメンテナンスコマンドですね。

たとえば、サーバーフォルダ内のpermissions.jsonを編集して、特定のプレイヤーをoperatorにしたとします。
でも、ファイルを書き換えただけでは、サーバー側がすぐに新しい設定を認識しない場合があります。

そこで使うのが、

/permission reload

です。

このコマンドを実行すると、サーバーが権限設定ファイルを読み直してくれます。

また、現在の権限設定を確認したい時は、

/permission list

を使います。

要するに、permissionコマンドは、権限を直接いじるコマンドというより、権限ファイルの状態確認と再読み込みをするコマンドです。
ここを間違えると、「/permissionでOPを追加できるのでは？」と勘違いしやすいので注意してくださいね。

2. permissionコマンドが使える環境

まず一番大事なところです。

/permissionコマンドはBedrock Dedicated Server専用です。

つまり、次のような環境で使うコマンドです。

Windowsで立てた統合版専用サーバー
Ubuntu/Linuxで立てた統合版専用サーバー
VPSやレンタルサーバー上のBedrock Dedicated Server
Dockerなどで動かしている統合版サーバー

逆に、次のような環境では基本的に使う場面がありません。

普通のシングルプレイワールド
フレンドを招待しているだけのワールド
Realms
Java版サーバー

ここ、本当に間違えやすいです。

マイクラ統合版には、ワールド設定画面からプレイヤー権限を変更できる場面がありますよね。
でも、この記事で扱う/permissionは、あの画面操作の代わりに使う日常コマンドではありません。

サーバーフォルダ内のpermissions.jsonを読み込むための管理コマンドと考えてください。

また、公式ドキュメント上では/permissionはOwner権限のコマンドとして扱われています。
さらに、コマンド仕様上はRequires Cheats Yesです。
そのため、ゲーム内チャットから普通にOP権限で実行するというより、サーバーコンソール側で使う管理コマンドとして覚えておくと安全です。

注意！
「OPなのに/permission reloadが実行できない」という場合、ゲーム内チャットではなくサーバーコンソールから実行してみてください。
ゲーム内から試す場合は、サーバー側のallow-cheats設定も確認しておくと安心です。
permissionコマンドは、一般プレイヤー向けのコマンドではなく、サーバー所有者・ホスト環境向けのコマンドです。

3. permissionコマンドの構文一覧

現行の統合版Stable系ドキュメントで案内されているpermissionコマンドの主な構文は、次の2つです。

/permission list

/permission reload

また、/permissionにはエイリアスとして、

/ops

も用意されています。

つまり、環境によっては次のように書いても同じ目的で使えます。

/ops list

/ops reload

ただし、この記事では分かりやすさ重視で、基本的に/permission表記で進めますね。

👇下の表に、permissionコマンドの役割を整理しました。

コマンド	役割	主な使いどころ
`/permission list`	現在の権限設定を表示	誰がどの権限で読み込まれているか確認する
`/permission reload`	権限ファイルを再読み込み	`permissions.json`編集後に反映する
`/ops list`	`/permission list`の別名	短いコマンドで確認したい時
`/ops reload`	`/permission reload`の別名	短いコマンドで再読み込みしたい時

初心者さん向けに言うと、まず覚えるのはこの2つだけでOKです。

確認したい時：/permission list
反映したい時：/permission reload

これだけで、permissionコマンドの基本運用はできます。

4. /permission listの使い方

/permission listは、現在サーバーに読み込まれている権限設定を表示するコマンドです。

構文はこちらです。

/permission list

サーバーコンソールで実行すると、サーバーが現在認識しているプレイヤー権限を確認できます。

たとえば、permissions.jsonにプレイヤーを追加した後、

/permission list

を実行すると、設定が読み込まれているか確認できます。

このコマンドの使いどころは、主に次のような場面です。

permissions.jsonの編集内容が反映されているか確認したい
どのプレイヤーがoperator扱いになっているか確認したい
サーバー再起動後に権限設定が残っているか確認したい
OP付与したつもりのプレイヤーが本当にOP扱いか確認したい

特に、サーバーを手動で管理している方は、編集後に必ずlistで確認するクセを付けるのがおすすめです。

筆者としては、権限まわりは「たぶん反映されたはず」で進めない方が良いと思っています。
OP権限は、ワールドの設定変更やコマンド実行に直結するので、うっかり別の人に付けると普通に危ないです。

運用メモ
permissions.jsonを書き換えたら、
1. /permission reload
2. /permission list
の順番で確認すると、ミスに気づきやすいです。

5. /permission reloadの使い方

/permission reloadは、サーバー上の権限設定ファイルを再読み込みするコマンドです。

構文はこちらです。

/permission reload

このコマンドを使う場面は、ほぼ決まっています。

permissions.jsonを編集した後です。

たとえば、サーバーフォルダ内のpermissions.jsonを開いて、次のように編集したとします。

[
  {
    "permission": "operator",
    "xuid": "1234567890123456"
  }
]

この状態でファイルを保存しても、サーバーが即座に変更を反映してくれるとは限りません。
そこで、サーバーコンソールから、

/permission reload

を実行します。

これで、サーバーがpermissions.jsonを再読み込みします。

その後、

/permission list

で確認すれば、設定が反映されたかチェックできます。

個人的には、reload単体で終わらせず、必ずlistまでセットで使うのが安全です。

reloadでできること

/permission reloadでできることは、次の通りです。

permissions.jsonの変更をサーバーに読み込ませる
サーバー再起動なしで権限設定を反映する
OP設定やメンバー設定の読み込み状態を更新する

reloadでできないこと

逆に、次のようなことはreloadではできません。

プレイヤー名だけでOPを追加する
XUIDを自動取得する
JSONの書き間違いを自動修正する
Java版のops.jsonを読み込む
Realmsの権限設定を変更する

reloadはあくまで、正しく書かれた権限ファイルを読み直すコマンドです。
ファイル自体が間違っている場合は、reloadしても解決しません。

6. permissions.jsonとは

permissions.jsonは、マイクラ統合版のBedrock Dedicated Serverで、プレイヤーごとの権限を管理するJSONファイルです。

Java版のサーバーではops.jsonを使いますが、統合版BDSでは基本的にpermissions.jsonを使うと覚えてください。

ファイルの例は、次のような形です。

[
  {
    "permission": "operator",
    "xuid": "1234567890123456"
  },
  {
    "permission": "member",
    "xuid": "2345678901234567"
  },
  {
    "permission": "visitor",
    "xuid": "3456789012345678"
  }
]

見ていただくと分かる通り、permissions.jsonでは、基本的にゲーマータグではなくXUIDでプレイヤーを指定します。

ここが少し面倒なんですよね。

ゲーマータグなら見れば分かりますが、XUIDは数字のIDなので、初見だと「どこで見るの？」となりがちです。
一般的には、次の方法で確認します。

プレイヤーがサーバーに参加した時のコンソールログを確認する
allowlist.json側に記録されたXUIDを確認する
レンタルサーバーの管理画面でプレイヤー情報を確認する
既にOP付与済みなら、サーバー側の権限ファイルを確認する

※外部サイトでXUIDを調べる方法もありますが、入力先の信頼性が分からない場合は慎重に扱ってください。

触るpermissions.jsonを間違えないように注意

ここも大事です。

Bedrock Dedicated Server周りには、別の用途のpermissions.jsonが出てくることがあります。
特に、Script APIやアドオン開発まわりでは、config/default/permissions.jsonのようなファイル名が出てくる場合があります。

ただし、この記事で扱っているのは、プレイヤー権限を管理するサーバーフォルダ側のpermissions.jsonです。

注意！
config/default/permissions.jsonのようなファイルは、スクリプト機能の権限設定用として扱われる場合があります。
プレイヤーをOPにしたい時に触るファイルとは目的が違うので、混同しないようにしましょう。

JSONの書き間違いに注意

permissions.jsonはJSONファイルなので、カンマやダブルクォーテーションを間違えると読み込みに失敗します。

よくあるミスはこのあたりです。

"permission"のスペルミス
operatorをopと書いてしまう
最後の行に余計なカンマを付ける
ダブルクォーテーションが片方だけ消えている
全角の記号を混ぜてしまう
XUIDではなくゲーマータグを書いてしまう

たとえば、これはダメな例です。

[
  {
    "permission": "op",
    "xuid": "1234567890123456",
  }
]

permissionの値はopではなく、operatorです。
また、最後のxuid行の末尾に余計なカンマが付いています。

正しくはこうです。

[
  {
    "permission": "operator",
    "xuid": "1234567890123456"
  }
]

このあたりは地味ですが、サーバー運用ではかなり大事です。
コマンド以前にファイルが正しく読めないと、/permission reloadしても反映されません。

7. operator・member・visitorの違い

permissions.jsonで使う権限は、主に次の3種類です。

operator
member
visitor

統合版サーバーを管理するなら、この3つの違いは必ず理解しておきましょう。

👇権限の使い分けを表にしました。

権限	日本語の感覚	おすすめ用途
`operator`	管理者・OP	サーバー管理者、信頼できる共同管理者
`member`	通常メンバー	普通にサバイバルで遊ぶ参加者
`visitor`	見学者	初参加者、確認待ちのプレイヤー、荒らし対策

operator

operatorは、いわゆるOP権限です。

通常プレイヤーより強い管理操作ができる権限なので、付与する相手はかなり慎重に選んでください。
ただし、/permissionのようにOwner権限が必要なコマンドは、operatorだけで何でも実行できるとは限りません。

たとえば、環境や設定によって、次のような管理操作に関わる場面があります。

コマンドによるワールド操作
ゲームルール変更
他プレイヤーへの管理操作
サーバー運営に関わる各種設定確認

便利ですが、強すぎる権限です。
友達サーバーでも、全員にoperatorを付けるのはおすすめしません。

体験談的な注意
少人数の身内サーバーでも、OPを全員に配ると、誰がどの設定を変えたか分からなくなりがちです。
管理者以外はmember、必要な時だけ一時的にoperatorにする方が事故は少ないです。

member

memberは、普通に遊ぶプレイヤー向けの権限です。

サバイバル参加者、建築メンバー、普段から遊ぶ友達などは、基本的にmemberで大丈夫です。

server.propertiesのdefault-player-permission-levelの初期値も、現行ドキュメントではmemberです。
つまり、特別に制限しない限り、新しく参加するプレイヤーは通常メンバー扱いになります。

visitor

visitorは、見学者向けの権限です。

初参加者をいきなり自由に建築できる状態にしたくない場合や、荒らし対策をしたい場合に使います。

たとえば、公開寄りのサーバーなら、

default-player-permission-level=visitor

にしておき、確認できた人だけmemberに上げる運用もあります。

もちろん、完全な荒らし対策としてはallow-listやバックアップも必要です。
ただ、初期権限をvisitorにしておくと、知らない人が入ってきた時の被害を減らしやすいです。

8. OP付与・剥奪コマンドとの違い

権限まわりで混同しやすいのが、/op、/deop、/permissionの違いです。

名前が似ているので、最初はかなり分かりづらいです。
でも、役割はそれぞれ違います。

👇OP関連コマンドの違いを整理しました。

コマンド	役割	使う場面
`/op <player>`	プレイヤーにOP権限を付与	プレイヤーを管理者にしたい時
`/deop <player>`	OP権限を剥奪	管理者権限を外したい時
`/permission list`	現在の権限設定を確認	読み込み状態を確認したい時
`/permission reload`	権限ファイルを再読み込み	`permissions.json`編集後に反映したい時

すぐOPにしたいなら/op

プレイヤー名で指定してOPにしたい場合は、基本的に/opを使います。

/op PlayerName

指定したプレイヤーにOP権限を付与するコマンドです。

逆に、OPを外したい時は、

/deop PlayerName

を使います。

Bedrock Dedicated Serverでは、認証済みのプレイヤーに対してopやdeopを実行した場合、環境によってはpermissions.json側にも反映されます。
ただし、ファイルを直接編集した場合とは確認手順が変わるので、最後は/permission listで見ておくと安心です。

ファイル編集後に反映したいなら/permission reload

一方、permissions.jsonを直接編集した場合は、/opではなく/permission reloadの出番です。

/permission reload

このように、目的によって使うコマンドが違います。

ゲーム内・コンソールからプレイヤーをOPにする：/op
OPを外す：/deop
permissions.jsonを読み直す：/permission reload
権限設定を確認する：/permission list

ここを整理しておくと、かなり迷いにくくなります。

9. 実録：権限設定を安全に変更する手順

ここからは、実際にサーバーで権限を変更する時の流れを、手順形式でまとめます。

今回は、permissions.jsonを編集して、特定プレイヤーをoperatorにする想定で進めますね。

1. サーバーのバックアップを取る

まずはバックアップです。

権限ファイルだけならワールドデータに直接影響しないことも多いですが、サーバー運用では、設定ファイルを触る前にバックアップを取るクセを付けた方が安心です。

最低限、次のファイルはコピーしておきましょう。

permissions.json
server.properties
allowlist.jsonを使っている場合はallowlist.json

ファイル名の後ろに日付を付けて、

permissions_2026-05-24_backup.json

のようにしておくと、後から戻しやすいです。

2. 対象プレイヤーのXUIDを確認する

次に、対象プレイヤーのXUIDを確認します。

permissions.jsonでは、基本的にプレイヤー名ではなくXUIDを使います。
そのため、ゲーマータグだけ書いても期待通りに動きません。

XUIDは、プレイヤーが一度サーバーに入った時のログや、allowlist.jsonなどから確認できることがあります。

3. permissions.jsonを編集する

permissions.jsonを開いて、次のように追記します。

[
  {
    "permission": "operator",
    "xuid": "1234567890123456"
  }
]

すでに別のプレイヤーが登録されている場合は、カンマの位置に注意してください。

[
  {
    "permission": "operator",
    "xuid": "1234567890123456"
  },
  {
    "permission": "member",
    "xuid": "2345678901234567"
  }
]

このように、各プレイヤーの設定を{ }で囲み、複数ある場合はカンマで区切ります。

4. ファイルを保存する

編集が終わったら、必ず保存します。

ここでありがちなのが、エディター上では変更したつもりでも、実際には保存していないパターンです。
/permission reloadしても反映されない時は、まず保存できているか確認してください。

5. /permission reloadを実行する

保存したら、サーバーコンソールで次のコマンドを実行します。

/permission reload

これで、サーバーが権限設定を再読み込みします。

環境によっては、スラッシュなしで、

permission reload

のように入力するコンソールもあります。
サーバーコンソール側の仕様に合わせてください。

6. /permission listで確認する

最後に、

/permission list

を実行して、設定が読み込まれているか確認します。

ここまで確認できたら、権限設定の変更は完了です。

おすすめの流れ
バックアップ
→ XUID確認
→ permissions.json編集
→ 保存
→ /permission reload
→ /permission listで確認

この順番でやれば、かなり事故を減らせます。

10. よくある失敗と対処法

ここでは、permissionコマンドやpermissions.jsonで詰まりやすいポイントをまとめます。

権限まわりは、エラー原因が地味で分かりにくいです。
「コマンドが悪い」と思っていたら、実はJSONのカンマ1個が原因だった、ということも普通にあります。

permissions.jsonを編集したのに反映されない

まず確認することはこちらです。

ファイルを保存したか？
/permission reloadを実行したか？
/permission listで確認したか？
JSONの書式が壊れていないか？
対象プレイヤーのXUIDが正しいか？
別のpermissions.jsonを編集していないか？

特に多いのは、編集するファイルを間違えているパターンです。
サーバーを複数置いている方や、Docker・レンタルサーバーを使っている方は、実際にサーバーが読んでいるフォルダを確認してください。

/permission reloadが使えない

/permission reloadが実行できない場合、次を確認しましょう。

Bedrock Dedicated Serverで実行しているか？
ゲーム内チャットではなくサーバーコンソールから実行しているか？
ゲーム内から実行する場合、allow-cheatsが有効になっているか？
コマンドのスペルを間違えていないか？
サーバー側でコマンド入力を受け付ける状態か？

permissionコマンドはOwner権限の管理コマンドです。
OPプレイヤーなら何でも実行できる、という扱いで考えない方が安全です。

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

この場合は、次の確認がおすすめです。

本当にoperatorと書いているか？
opやadminなど、別名で書いていないか？
XUIDが別プレイヤーのものになっていないか？
/permission reload後にサーバーへ入り直したか？
ゲーム内コマンドの場合、allow-cheatsや各コマンドの必要権限を確認したか？

operatorは必ずこの表記です。

"permission": "operator"

"permission": "op"ではありません。
ここは地味に間違えやすいので注意しましょう。

visitorになってブロックを触れない

参加者が「ブロックを置けない」「壊せない」と言っている場合、visitor扱いになっている可能性があります。

この場合は、対象プレイヤーをmemberにするか、server.propertiesの初期権限を確認してください。

default-player-permission-level=member

通常のサバイバル参加者なら、基本はmemberで大丈夫です。

全員をoperatorにしても大丈夫？

おすすめしません。

身内サーバーでも、operatorは管理者だけに絞る方が良いです。
OP権限があると、意図せずゲームルールを変えたり、コマンドでワールドに影響を与えたりできます。

普通に遊ぶ人はmember。
管理する人だけoperator。
初参加者や確認待ちはvisitor。

このくらいの運用が分かりやすいです。

11. バージョン差・古い情報の注意点

permissionコマンドについて調べる時に、少し注意したい点があります。

それは、古いドキュメントや一部の情報で、setという記述が残っている場合があることです。

現行のStable系コマンド例では、/permissionの構文として主に案内されているのは、

/permission list

/permission reload

の2つです。

一方で、古いリファレンス系ページや派生情報では、説明文の中にsetという語が残っていることがあります。
ただ、現行の実用記事としては、permissionコマンドで権限を直接setする前提では書かない方が安全です。

実際の運用では、次のように覚えてください。

権限を付ける：/op、またはpermissions.json編集
権限を外す：/deop、またはpermissions.json編集
ファイルを読み直す：/permission reload
読み込み状態を見る：/permission list

また、統合版のサーバー仕様は、Java版と違います。

Java版で見かける、

ops.json

を統合版BDSで探しても、同じ感覚では扱えません。
統合版BDSでは、プレイヤー権限の管理にpermissions.jsonが使われます。

2026年5月時点の注意
本記事では、現行Stable系の公式コマンド例に合わせて、/permission listと/permission reloadを中心に解説しています。
今後の統合版アップデートで構文が変更された場合は、サーバーのhelpコマンドや公式ドキュメントも確認してください。

マイクラ統合版1.21系列で見るべきポイント

1.21系列以降でサーバーを触る場合、permissionコマンドそのものより、次の点で詰まりやすいです。

サーバー本体とクライアントのバージョン不一致
サーバー更新後に設定ファイルの場所を勘違いする
Dockerやレンタルサーバーで編集先フォルダを間違える
旧情報を見てJava版のops.jsonを探してしまう
config/default/permissions.jsonとプレイヤー権限用permissions.jsonを混同する

特に、サーバー更新直後は、どのフォルダを読んでいるのかを確認してから編集してください。
ここを間違えると、どれだけreloadしても反映されません。

12. まとめ

以上、マイクラ統合版のpermissionコマンドについて解説しました。

最後に要点をまとめます。

/permissionはBedrock Dedicated Server専用の管理コマンド
基本構文は/permission listと/permission reload
/permission listは現在の権限設定確認に使う
/permission reloadはpermissions.json編集後の再読み込みに使う
プレイヤー権限はoperator、member、visitorの3種類
普通に遊ぶ人はmember、管理者だけoperatorがおすすめ
permissions.jsonではゲーマータグではなくXUIDを使う
Java版のops.jsonとは別物なので混同しない

permissionコマンドは、普段のマイクラ攻略では出番が少ないです。
でも、統合版の自前サーバーを運用するなら、知っておくとかなり助かります。

特に、

/permission reload

これは本当に大事です。

permissions.jsonを編集したのに反映されない時は、まずこのコマンドを思い出してください。
その後、

/permission list

で確認するところまでセットにすれば、権限まわりの事故はだいぶ減らせます。

では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にも統合版サーバー運用やコマンド解説をまとめていくので、是非ご覧くださいね(^^♪

13. 参考文献

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

ゆずかきのゲーム館