【マイクラ】scripteventコマンドの使い方・構文・スクリプトイベント送信【統合版】

この記事はマイクラ統合版（Bedrock Edition）向けです
Java版では /scriptevent コマンドは使えません
ビヘイビアーパックのScript APIと一緒に使うコマンドです

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

今回は、マイクラ統合版の少し特殊なコマンド、/scriptevent コマンドについて解説します。

普通のコマンドだと、/give でアイテムを渡したり、/tp で移動させたり、/setblock でブロックを置いたりしますよね。
でも /scriptevent は、それらとは少し立ち位置が違います。

簡単に言うと、コマンド側からビヘイビアーパック内のJavaScriptへ合図を送るためのコマンドです。

なので、チャット欄で /scriptevent を入力しただけでは、何も起きないことがあります。
これは失敗ではなく、受け取る側のスクリプトが無いと処理されないからです。

この記事では、初心者さんでも流れを追えるように、

/scriptevent コマンドの基本構文

messageId と message の意味

Script API側で受け取る方法

コマンドブロック・NPC・functionとの使い分け

何も起きない時のチェックポイント

を順番に整理していきます。

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

※本記事は、統合版の安定版ドキュメントを元に、初心者向けに噛み砕いて構成しています。
※Script APIは更新が多い分野なので、配布アドオンとして公開する場合は、使用中の統合版バージョンと @minecraft/server のバージョン確認をおすすめします。

1. scripteventコマンドとは
2. scripteventを使う前に必要な前提
3. scripteventコマンドの構文
4. まずは最小構成で受信してみる
5. messageIdとmessageの考え方
6. どこからscripteventを送信できる？
7. 実用例：コマンドからスクリプト処理を呼び出す
8. NPCボタンやコマンドブロックで使う時の注意点
9. 何も起きない時のチェックポイント
10. バージョン差・古い情報で混乱しやすい点
11. まとめ
12. 参考文献

この記事で分かること
・マイクラ統合版の /scriptevent コマンドの使い方
・コマンドからScript APIへイベントを送る基本
・初心者がつまずきやすい「入力しても何も起きない」原因

1. scripteventコマンドとは

/scriptevent は、統合版のScript APIへイベントを送るためのコマンドです。

もう少しマイクラらしく言うと、

コマンドブロックを押した
NPCのボタンを押した
functionファイルからコマンドを実行した
チャット欄から管理者がコマンドを打った

こういったタイミングで、ビヘイビアーパック内のJavaScriptに「この処理をしてね」と合図を送るために使います。

たとえば、こんなイメージです。

/scriptevent yuzukaki:hello こんにちは

このコマンドだけを見ると、「こんにちは」と送っているだけに見えますよね。
でも、ビヘイビアーパック側で yuzukaki:hello を受け取る処理を書いておけば、

ワールド全体にメッセージを出す
プレイヤーにアイテムを渡す
スコアボードを更新する
NPCショップを開く
ミニゲームの開始処理を走らせる

といった処理に繋げられます。

つまり /scriptevent は、コマンドとスクリプトをつなぐ橋みたいなものですね。

`/event` コマンドとは別物です

統合版には /event というコマンドもあります。
名前が似ているので混乱しやすいですが、役割は違います。

コマンド	主な用途	初心者向けの覚え方
/event	エンティティのイベントを発火	モブ側の状態変更に使う
/scriptevent	Script APIへイベントを送信	JavaScript側の処理を呼び出す

/event はモブやエンティティの定義と関係が深いコマンドです。
一方で /scriptevent は、Script APIを使うビヘイビアーパック向けです。

ここを混同すると、調べても情報が噛み合わなくなるので注意してくださいね。

2. scripteventを使う前に必要な前提

/scriptevent は、普通のサバイバルでいきなり便利効果が出るコマンドではありません。
使う前に、最低限この前提を押さえておきましょう。

必要な前提

統合版限定です
チートの有効化が必要です
Game Directors相当の権限が必要です
ビヘイビアーパック内にScript APIの受信処理が必要です
送るIDと、受け取るIDを一致させる必要があります

特に重要なのは、4つ目です。

/scriptevent は、コマンドを入力しただけで単体動作するというより、スクリプトに合図を送るための部品です。
なので、受信側のコードが無いワールドで打っても、見た目上は何も起きないことがあります。

使いどころのイメージ

筆者としては、次のような用途と相性が良いと思います。

NPCのボタンから、ショップ処理を呼び出す
コマンドブロックから、ミニゲーム開始処理を呼び出す
functionファイルから、Script API側の処理を分岐させる
スコアボードだけでは書きづらい処理をJavaScript側に逃がす
配布ワールドの管理用コマンドを作る

逆に、単純にアイテムを渡すだけなら /give、場所移動だけなら /tp で十分です。
/scriptevent は、普通のコマンドだけでは処理が複雑になりすぎる時に使うものと考えると分かりやすいです。

3. scripteventコマンドの構文

/scriptevent の基本構文は次の通りです。

/scriptevent <messageId> <message>

公式ドキュメント上では、次のような形で定義されています。

/scriptevent <messageId: id> <message: message_root>

初心者向けに言い換えると、こうです。

/scriptevent イベントID 送信するメッセージ

たとえば、次のように入力します。

/scriptevent yuzukaki:test hello

この場合、

yuzukaki:test が messageId
hello が message

になります。

引数の意味

引数	意味	例
messageId	どのイベントを送るかを示すID	yuzukaki:test
message	スクリプト側へ渡す文字列データ	hello

messageId は、スクリプト側で判定するための名前です。
message は、そのイベントに付けて渡す追加データです。

たとえば、以下のように複数のイベントを分けることができます。

/scriptevent yuzukaki:shop_open weapon
/scriptevent yuzukaki:quest_clear tutorial
/scriptevent yuzukaki:heal 10

この場合、Script API側では、

yuzukaki:shop_open が来たらショップ処理
yuzukaki:quest_clear が来たらクエスト完了処理
yuzukaki:heal が来たら回復処理

というように分岐できます。

messageは2048文字まで

message に渡せる文字数には上限があります。
現在の安定版ドキュメントでは、messageは2048文字を超えられないとされています。

普通の用途ならあまり困りませんが、長いJSON文字列や大量データを渡そうとすると引っかかる可能性があります。

なので、最初はこんなふうに短く渡すのがおすすめです。

/scriptevent yuzukaki:mode easy
/scriptevent yuzukaki:mode hard
/scriptevent yuzukaki:give_ticket 1

長いデータを無理にコマンドへ詰め込むより、messageは合図や短い値だけにして、細かい処理はスクリプト側で持つほうが管理しやすいです。

4. まずは最小構成で受信してみる

ここからは、実際に /scriptevent を受け取る最小コードを見ていきます。

ビヘイビアーパックの中に scripts/main.js を用意し、次のようなコードを書きます。

import { system, world } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:test") return;

  world.sendMessage(`scripteventを受信しました：${event.message}`);
});

この状態で、ワールド内から次のコマンドを実行します。

/scriptevent yuzukaki:test hello

うまく動いていれば、ワールドのチャット欄に、

scripteventを受信しました：hello

というメッセージが表示されます。

これが、/scriptevent の基本形です。

何が起きているの？

上のコードでは、次の流れになっています。

/scriptevent yuzukaki:test hello を実行する
system.afterEvents.scriptEventReceive がイベントを受け取る
event.id が yuzukaki:test か確認する
一致した場合だけ、event.message をチャットへ表示する

つまり、コマンド側の messageId と、スクリプト側の event.id が一致して初めて処理が走ります。

ここがかなり大事です。

if (event.id !== "yuzukaki:test") return;

この1行があることで、関係ない /scriptevent を受け取っても無視できます。

最小限のmanifest.json例

Script APIを動かすには、ビヘイビアーパック側の manifest.json に script module と依存関係が必要です。
環境によって指定できる @minecraft/server のバージョンは変わるため、公開用では手元の統合版に合わせて調整してください。

一例として、構造はこんなイメージです。

{
  "format_version": 2,
  "header": {
    "name": "Scriptevent Sample",
    "description": "scriptevent test pack",
    "uuid": "00000000-0000-0000-0000-000000000001",
    "version": [1, 0, 0],
    "min_engine_version": [1, 21, 0]
  },
  "modules": [
    {
      "type": "script",
      "language": "javascript",
      "uuid": "00000000-0000-0000-0000-000000000002",
      "version": [1, 0, 0],
      "entry": "scripts/main.js"
    }
  ],
  "dependencies": [
    {
      "module_name": "@minecraft/server",
      "version": "1.11.0"
    }
  ]
}

※UUIDは必ず自分で生成したものに差し替えてください。
※上の例では min_engine_version に合わせて @minecraft/server を 1.11.0 にしています。新しい統合版向けに作る場合は、公式ドキュメントで対応する安定版に差し替えてください。

5. messageIdとmessageの考え方

/scriptevent で一番つまずきやすいのが、messageIdとmessageの役割分担です。

筆者は、次のように考えると分かりやすいと思います。

messageId：どの処理を呼び出すか
message：その処理に渡す追加情報

たとえば、回復処理を呼び出すなら、

/scriptevent yuzukaki:heal 10

という感じですね。

この場合、

yuzukaki:heal → 回復処理を呼び出す合図
10 → 回復量

として扱えます。

messageIdは分かりやすい名前にする

messageId は、あとから見ても意味が分かる名前にしておくと管理が楽です。

おすすめは、次のような名前です。

yuzukaki:shop_open
yuzukaki:quest_clear
yuzukaki:heal
yuzukaki:minigame_start
yuzukaki:give_reward

反対に、次のような名前は後から困りやすいです。

test:a
test:b
test:aaa
abc:1

最初のテストならこれでも良いのですが、イベント数が増えると一気に分かりにくくなります。

messageId は、後から見返す自分へのメモでもあります。
できるだけ処理内容が分かる名前にしておきましょう。

名前空間は自分用に分ける

yuzukaki:heal の yuzukaki の部分は、名前空間のように使えます。

自作パックなら、

yuzukaki:hello
yuzukaki:shop_open
yuzukaki:quest_clear

のように、先頭を自分のパック名・作者名・企画名などで揃えると分かりやすいです。

他のアドオンと混ぜるワールドでは、イベントIDが衝突するとややこしいので、自分のパック専用の名前空間を使うのがおすすめです。

messageには短い値を渡す

message は文字列として受け取れます。
なので、次のような渡し方ができます。

/scriptevent yuzukaki:mode easy
/scriptevent yuzukaki:mode normal
/scriptevent yuzukaki:mode hard

スクリプト側では、こんな感じで分岐できます。

import { system, world } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:mode") return;

  if (event.message === "easy") {
    world.sendMessage("難易度設定：かんたん");
  }

  if (event.message === "normal") {
    world.sendMessage("難易度設定：ふつう");
  }

  if (event.message === "hard") {
    world.sendMessage("難易度設定：むずかしい");
  }
});

初心者さんは、まずこのくらいシンプルな値から始めると失敗しにくいです。

6. どこからscripteventを送信できる？

/scriptevent は、コマンドが使える場所から送信できます。

代表的なのは次の4つです。

送信元	使いどころ	注意点
チャット欄	手動テスト・管理用	権限とチートが必要
コマンドブロック	ボタン・感圧板・レッドストーン連動	誰が押したかは自動では分かりにくい
NPCのボタン	会話・ショップ・クエスト	押したプレイヤーはinitiator側で扱う
functionファイル	複数コマンドの流れに組み込む	イベントIDの管理が大事

チャット欄から送る

まずテストするなら、チャット欄からが一番簡単です。

/scriptevent yuzukaki:test hello

受信コードが正しく動いていれば、すぐに確認できます。

コマンドブロックから送る

ボタンやレッドストーン装置と連動したい場合は、コマンドブロックに書き込みます。

scriptevent yuzukaki:gate_open redstone

コマンドブロック内では、先頭の / はあってもなくても構いません。

コマンドブロックは、配布ワールドやミニゲーム作りではかなり便利です。
ただし、誰が押したかを正確に取りたい場合は工夫が必要です。

NPCのボタンから送る

NPCの会話ボタンにコマンドを設定して、/scriptevent を送ることもできます。

/scriptevent yuzukaki:npc_shop_open weapon

NPCショップやクエスト受付のような仕組みとは相性が良いです。

ただし、NPCから送られたイベントでは、NPC自身と、ボタンを押したプレイヤーの扱いを混同しないことが大事です。
詳しくは後の章で解説します。

functionファイルから送る

functions フォルダ内の .mcfunction ファイルから送ることもできます。

say ミニゲームを開始します
scriptevent yuzukaki:minigame_start lobby

普通のコマンドで準備をして、最後にScript API側の処理を呼び出す、という使い方ができます。

7. 実用例：コマンドからスクリプト処理を呼び出す

ここでは、実際に使いやすいサンプルをいくつか紹介します。

サンプルなのでシンプルにしていますが、考え方はそのまま応用できます。

例1：ワールド全体にメッセージを出す

まずは一番分かりやすい例です。
/scriptevent の message を、そのままワールドへ表示します。

import { system, world } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:announce") return;

  world.sendMessage(`お知らせ：${event.message}`);
});

実行コマンドはこちらです。

/scriptevent yuzukaki:announce イベント開始です

チャット欄に、

お知らせ：イベント開始です

と表示されます。

配布ワールドの開始案内や、イベント進行用の管理コマンドとして使いやすいです。

例2：messageで処理を分岐する

次は、message の内容によって処理を変える例です。

import { system, world } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:weather") return;

  if (event.message === "clear") {
    world.getDimension("overworld").runCommand("weather clear");
    world.sendMessage("天候を晴れにしました");
  }

  if (event.message === "rain") {
    world.getDimension("overworld").runCommand("weather rain");
    world.sendMessage("天候を雨にしました");
  }
});

実行コマンドはこちらです。

/scriptevent yuzukaki:weather clear

または、

/scriptevent yuzukaki:weather rain

messageId は同じ yuzukaki:weather ですが、message を変えることで処理を分けています。

この考え方はかなり便利です。

shop の中で武器屋・防具屋を分ける
quest の中でクエストIDを分ける
mode の中でミニゲームの難易度を分ける

というように、イベント数を増やしすぎずに管理できます。

例3：スクリプト側からscripteventを送る

実は、コマンドだけでなく、Script API側からもスクリプトイベントを送れます。

import { system } from "@minecraft/server";

system.run(() => {
  system.sendScriptEvent("yuzukaki:loop_test", "from_script");
});

これにより、スクリプト内から別の scriptEventReceive 処理へイベントを渡すこともできます。

ただし、初心者さんは最初からこれを多用しなくて大丈夫です。
まずは、コマンド → Script API の流れを理解するほうが先です。

例4：イベントを名前空間で絞る

イベントが増えてくると、1つの受信処理で全部を受け取るのが面倒になります。
その場合は、受信する名前空間を絞る方法があります。

import { system, world } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe(
  (event) => {
    world.sendMessage(`受信：${event.id} / ${event.message}`);
  },
  { namespaces: ["yuzukaki"] }
);

このように書くと、yuzukaki: から始まるイベントだけを受け取る形にできます。

イベントが少ないうちは必須ではありませんが、アドオンの規模が大きくなるほど管理が楽になります。

8. NPCボタンやコマンドブロックで使う時の注意点

/scriptevent は、送信元によって「誰が送ったのか」の扱いが変わります。
ここを知らないと、NPCショップやコマンドブロック連動でつまずきやすいです。

Script API側では、受信したイベントから主に次の情報を見られます。

プロパティ	意味	よく使う場面
event.id	受信したmessageId	処理の分岐
event.message	受信したmessage	追加データの受け取り
event.sourceBlock	コマンドブロックなど、ブロック由来の場合のブロック情報	コマンドブロック連動
event.sourceEntity	エンティティ由来の場合のエンティティ情報	NPCなど
event.initiator	NPC会話などで実際に操作したプレイヤー	NPCボタン処理
event.sourceType	どの種類の送信元か	送信元ごとの分岐

NPCボタンではinitiatorを見る

NPCのボタンから /scriptevent を実行した場合、処理対象のプレイヤーを取りたいなら、基本的には event.initiator を見ます。

import { system } from "@minecraft/server";

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:npc_hello") return;

  const player = event.initiator;
  if (!player || player.typeId !== "minecraft:player") return;

  player.sendMessage("NPCボタンから呼び出されました");
});

NPC絡みでは、sourceEntity がNPC側を指すことがあります。
そのため、ボタンを押したプレイヤーを扱いたい時はinitiatorを見ると覚えておくと事故が減ります。

コマンドブロックでは押した人が分かりにくい

コマンドブロックから /scriptevent を送る場合、押したプレイヤーが自動で取れるとは限りません。

たとえば、ボタンを押したプレイヤーにだけ報酬を渡したい場合、コマンドブロック単体だと少し工夫が必要です。

初心者向けには、まず次のどちらかがおすすめです。

報酬対象を周辺プレイヤーにする
message に対象名や対象情報を渡す

たとえば、コマンドブロックから近くのプレイヤーを対象にしたいなら、Script API側で周辺プレイヤーを探す設計にします。

ただし、複数人が近くにいるワールドでは誤判定が起きやすいので、配布ワールドでは設計段階で注意しましょう。

セキュリティ面も少しだけ注意

/scriptevent は、スクリプト側で自由な処理につなげられる分、適当に作ると危険です。

たとえば、

/scriptevent yuzukaki:give_diamond 64

のようなイベントを作った場合、権限を持つ人が自由に呼び出せてしまいます。

管理者用なら問題ないですが、配布ワールドでプレイヤーに使わせる場合は、

どこから呼べるか
誰に効果を出すか
messageに想定外の値が入った時どうするか

を決めておきましょう。

特に message は外から渡される文字列なので、想定外の値を受け取ったら何もしない設計が安全です。

const allowedModes = ["easy", "normal", "hard"];

if (!allowedModes.includes(event.message)) {
  return;
}

こうしておくと、変な値が来ても処理を止められます。

9. 何も起きない時のチェックポイント

/scriptevent は、初心者さんほど「コマンドを打ったのに何も起きない」となりやすいです。
そういう時は、下のチェックポイントを順番に見てください。

[ ] 統合版のワールドで実行しているか？
[ ] チートは有効になっているか？
[ ] 実行者に必要な権限があるか？
[ ] ビヘイビアーパックはワールドに適用されているか？
[ ] manifest.json の script module は正しく設定されているか？
[ ] scripts/main.js のパスは合っているか？
[ ] @minecraft/server のバージョンは、今の統合版に対応しているか？
[ ] messageId の文字が、コマンド側とスクリプト側で一致しているか？
[ ] 大文字・小文字・アンダーバーの違いが無いか？
[ ] message が2048文字を超えていないか？
[ ] スクリプト側で return して処理が止まっていないか？

よくあるミス1：IDの書き間違い

これが一番多いです。

コマンド側：

/scriptevent yuzukaki:test hello

スクリプト側：

if (event.id !== "yuzukaki:tests") return;

この場合、test と tests が違うので動きません。
見た目では気づきにくいので、まずはコピペで一致させるのがおすすめです。

よくあるミス2：スクリプトが読み込まれていない

コード自体は合っていても、ビヘイビアーパックが読み込まれていなければ何も起きません。

特に、

UUIDの重複
entry のパス違い
scripts/main.js の置き場所違い
manifestのJSON記法ミス

このあたりはよくあります。

スクリプトが動いているか不安な時は、起動直後にメッセージを出すコードを一度入れると確認しやすいです。

import { system, world } from "@minecraft/server";

system.run(() => {
  world.sendMessage("スクリプトが読み込まれました");
});

読み込み直後の処理は実行タイミングの影響を受けやすいので、必要に応じて system.run などで少し遅らせると確認しやすいです。

よくあるミス3：古いScript API記事を見ている

Script APIは、昔の情報と今の情報で書き方が違うことがあります。

特に古い記事では、

GameTest時代の書き方
Beta APIs前提の書き方
@minecraft/server の古いバージョン前提
すでに変更されたイベント名

が混ざっていることがあります。

/scriptevent そのものは現在の安定版ドキュメントにも載っていますが、周辺のScript APIコードは更新されることがあるので、古い記事を丸ごとコピーする時は注意してください。

10. バージョン差・古い情報で混乱しやすい点

/scriptevent は、もともとBeta APIs実験に関係する時期がありました。
そのため、検索すると古い説明が出てくることがあります。

現在の安定版ドキュメントでは、/scriptevent は統合版のコマンドとして掲載されており、構文は次の形です。

/scriptevent <messageId: id> <message: message_root>

ただし、Script API全体は今も更新が多い分野です。
なので、最新版付近で作業する時は、次の2つを分けて考えてください。

1. `/scriptevent` コマンド本体

コマンド本体の役割は、IDとメッセージをスクリプトへ送ることです。

チート必須
統合版専用
messageId と message を送る
message は2048文字まで

この基本は押さえておけば大丈夫です。

2. Script API側の書き方

一方で、Script API側のバージョン指定や、使えるメソッド・イベントは更新されることがあります。

特に manifest.json の、

{
  "module_name": "@minecraft/server",
  "version": "1.11.0"
}

この version 部分は、統合版のバージョンと対応関係があります。
新しい環境では 2.x.x 系の安定版が使われることもあるため、ワールドを配布する場合や、マーケットプレイス向けに作る場合は、手元のMinecraft本体・公式ドキュメント・使用するAPIバージョンを合わせて確認してください。

Java版1.21.11などの情報とは別物です

検索していると「1.21.11」などの表記を見かけることがありますが、Java版と統合版ではバージョン表記や機能差があります。

/scriptevent は統合版向けのコマンドです。
Java版のバージョン情報を見ても、このコマンドの仕様確認には使えません。

ここはかなり混乱しやすいので、調べる時は必ず、

Bedrock
統合版
Script API
/scriptevent

のような言葉を入れて検索すると良いです。

11. まとめ

今回は、マイクラ統合版の /scriptevent コマンドについて解説しました。

要点を整理すると、

/scriptevent は統合版専用のコマンド
コマンドからScript APIへイベントを送るために使う
構文は /scriptevent <messageId> <message>
messageId は処理名、message は追加データと考えると分かりやすい
受信側では system.afterEvents.scriptEventReceive.subscribe を使う
message は2048文字まで
受信するスクリプトが無いと、見た目上は何も起きない
NPCボタンでは initiator、コマンドブロックでは送信元の扱いに注意する

という感じです。

/scriptevent は、普通のサバイバル攻略で使うコマンドというより、配布ワールド・アドオン制作・ミニゲーム制作向けの橋渡しコマンドです。

最初は難しく見えますが、基本はかなりシンプルです。

/scriptevent yuzukaki:test hello

このコマンドで、

system.afterEvents.scriptEventReceive.subscribe((event) => {
  if (event.id !== "yuzukaki:test") return;
  world.sendMessage(event.message);
});

この処理が動く。
まずはここだけ理解できればOKです。

そこから、NPCショップ・クエスト・ミニゲーム開始処理などへ広げていくと、コマンドだけでは作りづらかった仕組みもかなり作りやすくなります。

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

12. 参考文献

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

目次