【マイクラ】testforblockコマンドの使い方・構文・ブロック検出を解説【統合版】

この記事はマイクラ統合版（Bedrock Edition）向けです
Java版では現在 /testforblock は使わず、基本的に /execute if block を使います
統合版でも新しい仕組みを組むなら /execute if block も候補になりますが、この記事では /testforblock を中心に解説します

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

マイクラ統合版でコマンドブロックを触っていると、

「この場所にダイヤブロックが置かれたら反応させたい」
「ボタンが押された時だけ別のコマンドを動かしたい」
「指定した座標のブロックを判定して、仕掛けを作りたい」

こういう場面が出てきますよね。

その時に使えるのが、指定した座標に特定のブロックがあるか調べる /testforblock コマンドです。

コマンド自体は短いです。
ただし、ブロック状態まで判定しようとすると、書き方を少し間違えただけで全然反応しなくなります。
特にボタン・レバー・ドア・トラップドアあたりは、初心者さんがかなり詰まりやすいです。

この記事では、統合版の /testforblock の基本構文、コマンドブロックでの使い方、ブロック状態の指定、失敗しやすいポイントを順番に整理していきます。

この記事を読めば、次のことが出来るようになります。

指定座標のブロックを検出できるようになります👍

コマンドブロックと組み合わせて、条件付きの仕掛けを作れます👌

ボタンやレバーの状態検出で詰まりにくくなります(^^♪

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

※この記事はマイクラ統合版のコマンド仕様を前提にしています。
※ゲーム内コマンドはバージョンによって挙動が変わる場合があります。
※Java版では /testforblock は古いコマンド扱いなので、統合版と混同しないようにしてくださいね。

1. testforblockコマンドとは
2. testforblockの基本構文
3. コマンドを使う前の準備
4. まずは指定座標のブロックを検出する
5. 相対座標で近くのブロックを検出する
6. コマンドブロックで仕掛けとして使う方法
7. ブロック状態を指定して検出する方法
8. ボタン・レバー検出で失敗しやすいポイント
9. testforblockとexecute if blockの違い
10. testforblocksとの違い
11. よくあるエラーと対処法
12. まとめ
13. 参考文献

この記事で分かること
・統合版の /testforblock の基本的な使い方
・コマンドブロックでブロック検出を仕掛けにする方法
・ボタンやレバーなど、ブロック状態を含む判定の注意点

1. testforblockコマンドとは

/testforblock は、指定した座標に、指定したブロックがあるかどうかを調べるコマンドです。

例えば、座標 0 64 0 にダイヤモンドブロックがあるか調べたい場合は、次のように書きます。

/testforblock 0 64 0 diamond_block

このコマンドを実行して、その場所に本当にダイヤモンドブロックがあれば成功。
違うブロックだったり、座標が読み込まれていなかったりすると失敗します。

分かりやすく言うと、/testforblock はブロック版のセンサーみたいなものですね。

特定の場所にブロックが置かれたら反応させる
足元が特定ブロックだったら処理を動かす
ボタンやレバーの状態を見て、別のコマンドへつなげる
ミニゲームや配布ワールドの判定装置に使う

こういう用途で使えます。

ただし、ひとつ注意です。
/testforblock はブロックを検出するだけのコマンドです。
「検出したら報酬を渡す」「検出したらドアを開ける」などの処理をしたい場合は、条件付きチェーンコマンドブロックや、/execute if block と組み合わせる必要があります。

ここ大事です
/testforblock 単体では、基本的に「見つかった／見つからない」を判定するだけです。
実際の仕掛けにするなら、次のコマンドへどうつなぐかが重要になります。

2. testforblockの基本構文

統合版の /testforblock の基本構文はこれです。

/testforblock <座標> <ブロックID> [ブロック状態]

もう少し公式っぽく書くと、下記の形になります。

/testforblock <position: x y z> <tileName: Block> [blockStates: block_state_array]

それぞれの意味は下記です。

項目	入力例	意味
座標	0 64 0	調べたいブロックの位置
ブロックID	diamond_block	検出したいブロック名
ブロック状態	["button_pressed_bit"=true]	ボタンが押されている等の細かい状態

まずは、ブロック状態なしで覚えれば大丈夫です。

/testforblock 0 64 0 diamond_block

👆これが一番基本です。

「座標」「ブロック名」の順番で書くだけなので、慣れるとかなりシンプルです。

昔のdataValue指定について

古い解説記事や動画では、次のような形を見かけることがあります。

/testforblock 0 64 0 wool 0

これは昔の dataValue を使った書き方です。
現在の統合版では、ブロックの細かい状態を指定する場合、基本的にブロック状態（blockStates）を使います。

なので、古い記事を見てそのまま真似すると、今の環境では通らないことがあります。
ここは結構大事なので、覚えておいてくださいね。

現在の考え方
・単純なブロック検出なら、ブロックIDだけでOK
・向き、押されているか、開いているか等まで見るなら、ブロック状態を指定する
・古い dataValue 前提の記事は、そのまま使えない場合があります

3. コマンドを使う前の準備

/testforblock を使う前に、最低限ここだけ確認しておきましょう。

チートが有効になっている
コマンドブロックを使うなら、ワールド設定でコマンドブロックが有効
座標を表示している
調べたい場所のチャンクが読み込まれている

統合版では、チャット欄から手打ちするだけなら、まずチートが有効である必要があります。
コマンドブロックで使う場合は、コマンドブロック自体を入手してから設置します。

/give @s command_block

コマンドブロックを使うなら、最初は次の設定がおすすめです。

ブロックの種類：リピート
条件：無条件
レッドストーン：常時実行

この設定にすると、指定したブロックがあるかどうかを毎ティック確認できます。
ただし、毎回チャットに実行結果が出るとかなりうるさいので、必要に応じて下記も使ってください。

/gamerule commandblockoutput false

これでコマンドブロックの実行ログが抑えられます。
検証中は出しておいて、完成したら false にするのもありです。

初心者さん向けメモ
コマンドが反応しない時、そもそも座標を1マス間違えていることが本当に多いです。
まずは座標表示をオンにして、検出したいブロックの座標をしっかり確認しましょう。

4. まずは指定座標のブロックを検出する

まずは、一番分かりやすい形からやってみましょう。

座標 0 64 0 にダイヤモンドブロックを置いて、次のコマンドを実行します。

/testforblock 0 64 0 diamond_block

成功すれば、その座標にダイヤモンドブロックがあるという判定になります。
逆に、そこが石や土や空気だった場合は失敗します。

空気を検出する場合

「その場所が空気かどうか」を見たい場合は、air を使います。

/testforblock 0 64 0 air

これで、座標 0 64 0 が空気なら成功します。

例えば、ブロックが壊されたかどうかを検出する仕掛けを作る時に使えます。

もともと置いてあるブロックを壊す
その場所が air になる
/testforblock が成功する
次のコマンドを動かす

という流れですね。

ブロックIDの確認方法

ブロックIDが分からない時は、コマンド入力中の候補を見ながら探すのが一番安全です。
統合版では、バージョンによってブロックIDや状態名の扱いが変わることがあります。

例えば、ダイヤモンドブロックは diamond_block。
石は stone。
土は dirt。

このあたりは分かりやすいですが、ボタンやトラップドア、銅系ブロック、桜系ブロックなどは名前を間違えやすいです。
候補に出るIDをそのまま使うのが安全ですね。

5. 相対座標で近くのブロックを検出する

/testforblock は、絶対座標だけでなく、相対座標も使えます。

よく使うのは ~ です。

/testforblock ~ ~-1 ~ grass_block

これは、コマンドを実行した場所の1マス下が草ブロックかどうかを調べるコマンドです。

チャットから実行した場合は、プレイヤー位置を基準にします。
コマンドブロックから実行した場合は、コマンドブロックの位置を基準にします。

ここ、地味ですがかなり大事です。

同じ ~ ~-1 ~ でも、

プレイヤーが実行する
コマンドブロックが実行する

この2つで基準位置が変わります。

コマンドブロックの下を調べる例

コマンドブロックの真下がレッドストーンブロックか調べたい場合は、こう書けます。

/testforblock ~ ~-1 ~ redstone_block

この場合、コマンドブロックの1マス下にレッドストーンブロックがあれば成功します。

目の前のブロックを調べたい場合

向き基準で調べたい場合は、ローカル座標の ^ を使う考え方もあります。
ただし、初心者さんが最初に使うなら、まずは ~ の相対座標に慣れた方が分かりやすいです。

コマンド装置では、検出位置を固定して使うことが多いので、最初は絶対座標か ~ で十分だと思います。

体験ベースの注意点
「コマンドは合っているのに動かない」と思った時、実際には基準位置を勘違いしているパターンが多いです。
コマンドブロックで動かすなら、~ の基準はそのコマンドブロックです。ここは必ず確認しましょう。

6. コマンドブロックで仕掛けとして使う方法

/testforblock を本格的に使うなら、コマンドブロックとの組み合わせが便利です。

一番基本の形は、

リピートコマンドブロックで /testforblock を実行
その先にチェーンコマンドブロックを置く
チェーン側を「条件付き」にする
/testforblock が成功した時だけ、次のコマンドが動く

という流れです。

例えば、座標 0 64 0 にダイヤモンドブロックが置かれたら、近くのプレイヤーにエメラルドを渡す仕掛けを作るならこうです。

1個目：リピートコマンドブロック

設定：リピート／無条件／常時実行

/testforblock 0 64 0 diamond_block

2個目：チェーンコマンドブロック

設定：チェーン／条件付き／常時実行

/give @p emerald 1

これで、指定座標にダイヤモンドブロックがある時だけ、チェーン側の /give が動きます。

ただし、このままだと条件を満たしている間、ずっとエメラルドを配り続けます。
なので、実用するならタグやブロック置き換えで、1回だけ発動する処理にしておくのがおすすめです。

1回だけ発動させる例

1個目：検出

/testforblock 0 64 0 diamond_block

2個目：報酬

/give @p emerald 1

3個目：検出対象を別ブロックに変える

/setblock 0 64 0 air

この形なら、ダイヤモンドブロックを検出して報酬を渡した後、そのブロックを空気に変えるので、連続発動しにくくなります。

ここは大事です
リピートコマンドブロックは、条件を満たす限り何度も動きます。
報酬配布やテレポートに使う場合は、暴発しないように「1回だけ発動する仕組み」も一緒に作りましょう。

7. ブロック状態を指定して検出する方法

ここから少しだけ難しくなります。

ブロックによっては、ただのブロックIDだけでは足りないことがあります。
例えばボタンなら、

押されているか
押されていないか
どの向きに付いているか

こういう細かい情報があります。
これがブロック状態です。

ブロック状態を指定する場合は、ブロックIDの後ろに半角スペースを入れて、次のように書きます。

/testforblock <座標> <ブロックID> ["状態名"=値]

例として、石のボタンが押されている状態を検出したい場合は、こういう形になります。

/testforblock 0 64 0 stone_button ["button_pressed_bit"=true,"facing_direction"=1]

button_pressed_bit は、ボタンが押されているかどうか。
facing_direction は、ボタンがどの向きに付いているかを表します。
この 1 は例なので、実際に置いたボタンの向きに合わせて変えてください。

ブロック状態を書く時の注意点

ブロック状態を書く時は、次の点に注意してください。

: ではなく = を使う
状態名はダブルクォーテーションで囲む
複数指定する時はカンマで区切る
ブロックIDと [ の間にスペースを入れる
状態を指定する時は、そのブロックに必要な状態をそろえて書く

特に、ボタンは button_pressed_bit だけを指定しても上手く判定できないことがあります。
向きの状態も一緒に指定するのが安全です。

/testforblock 0 64 0 stone_button ["button_pressed_bit"=true,"facing_direction"=1]

👆このように、押されているかどうか＋向き、のように必要な状態をまとめて指定します。

よく使うブロック状態の例

状態名	主な用途	値の例
button_pressed_bit	ボタンが押されているか	true / false
open_bit	ドア・トラップドア・フェンスゲート・レバー等の開閉やオンオフ状態	true / false
facing_direction	ブロックの向き	0〜5など
lever_direction	レバーの取り付け向き	north / south など
powered_bit	一部ブロックの信号状態	true / false
redstone_signal	感圧板などの信号強度	0〜15

※ブロック状態の名前や値は、ブロックごとに違います。
※バージョンによって扱いが変わる場合があるので、入力候補や公式のブロック状態一覧も確認してください。

8. ボタン・レバー検出で失敗しやすいポイント

/testforblock で一番つまずきやすいのが、ボタンやレバーの検出です。

理由は単純で、ボタンやレバーは「そのブロックがあるか」だけでなく、向きや押されている状態もセットで持っているからです。

ボタンが押されたことを検出する例

石のボタンを検出するなら、まずはボタンの座標を確認します。
仮に座標が 10 64 10 だとすると、基本形はこうです。

/testforblock 10 64 10 stone_button

これで、そこに石のボタンがあるかどうかは確認できます。

次に、押されている状態まで見たい場合は、ブロック状態を足します。

/testforblock 10 64 10 stone_button ["button_pressed_bit"=true,"facing_direction"=1]

ここで重要なのは、button_pressed_bit だけで済ませないことです。

/testforblock 10 64 10 stone_button ["button_pressed_bit"=true]

👆この書き方だと、環境やブロックの状態によって上手く判定できないことがあります。
ボタンは向きの状態も関係するので、ボタンの向きも一緒に指定するのが安定しやすいです。

facing_directionの値について

ボタンの facing_direction は、設置面の向きによって値が変わります。
一般的には、下記のような対応で説明されることが多いです。

値	向きの目安
0	下向き
1	上向き
2	北側
3	南側
4	西側
5	東側

ただし、facing_direction はブロックによって向きの意味がややこしくなることがあります。
一番安全なのは、まずブロックIDだけで検出できるか確認し、その後に状態を少しずつ足すやり方です。

レバーの場合

レバーは、オンオフの状態を open_bit で見ます。
ただし、レバーも lever_direction という向きの状態を持つので、ボタンと同じく「状態を一部だけ指定して上手くいかない」ことがあります。

まずは、レバーそのものを検出します。

/testforblock 10 64 10 lever

そのうえで、状態を確認しながら調整します。

/testforblock 10 64 10 lever ["lever_direction"="north","open_bit"=true]

この north は例です。
上手くいかない場合は、実際に置いたレバーの向きに合わせて、lever_direction の値を確認しましょう。

実際に詰まりやすいポイント
ボタンやレバーは、「押されているか」だけを見たくなります。
でも、実際のブロックは向きなどの状態も持っています。
なので、状態指定が中途半端だと、コマンドは合っているように見えても反応しないことがあります。

1.21.70〜1.21.90付近の注意点

統合版では、1.21.70で /testforblock がブロック状態を正しく見ない不具合が入り、1.21.90で修正された履歴があります。

つまり、もし古い統合版で、

ボタンを押していないのに成功扱いになる
button_pressed_bit を入れているのに状態を無視する
ブロックIDだけ見ているような挙動になる

こういう症状が出る場合は、コマンドの書き方だけでなく、ゲームのバージョン側の不具合も疑ってください。

安全に使うなら、1.21.90以降の環境で確認するのがおすすめです。

9. testforblockとexecute if blockの違い

ここまで /testforblock を中心に解説しましたが、現在の統合版では /execute if block もかなり重要です。

簡単に言うと、違いはこんな感じです。

コマンド	役割	向いている使い方
/testforblock	指定座標のブロックを検出する	コマンドブロックの条件判定
/execute if block	ブロック判定を条件にして、そのまま別コマンドを実行する	1行で条件付き処理を作る

例えば、座標 0 64 0 がダイヤモンドブロックなら、近くのプレイヤーにエメラルドを渡す場合。

/testforblock で組むなら、検出用と実行用でコマンドブロックを分けます。

/testforblock 0 64 0 diamond_block

条件付きチェーンで、

/give @p emerald 1

一方、/execute if block なら1行で書けます。

/execute if block 0 64 0 diamond_block run give @p emerald 1

これ、かなり便利です。

今から新しく仕掛けを作るなら、/execute if block の方がスッキリする場面も多いです。
ただ、コマンドブロックを並べて処理を見たい場合や、初心者さんが「成功したら次が動く」を理解するには、/testforblock もかなり分かりやすいです。

おすすめの使い分け
・コマンドの仕組みを覚える段階 → /testforblock
・1行で条件付き処理を書きたい → /execute if block
・否定条件を使いたい → /execute unless block

否定条件を使いたい場合

/testforblock は、「そのブロックがあるか」を調べるコマンドです。
「そのブロックが無い時に実行したい」なら、/execute unless block の方が自然です。

/execute unless block 0 64 0 diamond_block run say ダイヤブロックがありません

こういう条件は /execute 系の方がかなり書きやすいです。

10. testforblocksとの違い

名前が似ていてややこしいですが、/testforblock と /testforblocks は別物です。

/testforblock：1か所のブロックを調べる
/testforblocks：範囲内のブロック同士を比較する

1文字違いですが、用途はけっこう違います。

testforblock

指定した1マスを調べます。

/testforblock 0 64 0 diamond_block

これは、座標 0 64 0 にダイヤモンドブロックがあるかを見るだけです。

testforblocks

範囲同士を比較します。

/testforblocks 0 64 0 2 66 2 10 64 10 all

これは、0 64 0 から 2 66 2 までの範囲と、10 64 10 から始まる同じ大きさの範囲を比べるイメージです。

配布マップやパズルで、プレイヤーが正しい形にブロックを置いたか確認したい時などに使えます。
なお、最後の指定は all または masked で、何も書かない場合は all として扱われます。

ただし、初心者さんが最初に覚えるなら、まずは /testforblock で十分です。
1マス検出が分かるようになってから、範囲比較に進むと理解しやすいです。

覚え方
block は1ブロック。
blocks は複数ブロック。
まずはこの理解で大丈夫です。

11. よくあるエラーと対処法

最後に、/testforblock でよくある失敗をまとめます。
動かない時は、ここを上から確認してみてください。

1. 座標が間違っている

一番多いです。

特に統合版は、ブロックの座標とプレイヤーの立ち位置の座標を混同しやすいです。
対象ブロックにカーソルを合わせたり、座標表示を見たりしながら確認しましょう。

/testforblock 10 64 10 diamond_block

この場合、調べているのはプレイヤーの場所ではなく、座標 10 64 10 のブロックです。

2. ブロックIDが違う

diamond_block を diamonds_block と書いたら動きません。
当たり前ですが、こういうミスは普通に起きます。

入力候補を使って、正しいブロックIDを選びましょう。

3. ブロック状態の書き方が違う

ブロック状態の指定では、: ではなく = を使います。

間違い例：

/testforblock 10 64 10 stone_button ["button_pressed_bit":true]

正しい例：

/testforblock 10 64 10 stone_button ["button_pressed_bit"=true,"facing_direction"=1]

コロンで書いてしまうと、JSONっぽく見えますが、コマンドでは通らないことがあります。
ここはかなり間違えやすいです。

4. 状態指定が足りない

ボタンでよくある失敗です。

/testforblock 10 64 10 stone_button ["button_pressed_bit"=true]

これだけだと、上手く判定できないことがあります。
その場合は、向きの状態も一緒に指定してください。

/testforblock 10 64 10 stone_button ["button_pressed_bit"=true,"facing_direction"=1]

レバーの場合も、オンオフだけでなく向きの状態を合わせる必要があります。

/testforblock 10 64 10 lever ["lever_direction"="north","open_bit"=true]

5. 調べたい場所が読み込まれていない

指定した座標のチャンクが読み込まれていないと、コマンドが失敗します。
離れた場所を判定したい場合は、その場所が読み込まれているか確認しましょう。

配布ワールドや常時稼働装置では、ティッキングエリアを使う設計もありますが、初心者向けにはまず「プレイヤーの近くで検証する」ことをおすすめします。

6. コマンドブロックの向き・条件設定が違う

チェーンコマンドブロックを使う時は、前のコマンドブロックの矢印方向も大事です。

1個目：リピート／無条件／常時実行
2個目：チェーン／条件付き／常時実行
矢印の向きがつながっている

この3点を確認してください。

条件付きチェーンが前のコマンドブロックとつながっていないと、/testforblock が成功しても次のコマンドが動きません。

7. 古いバージョンの不具合に当たっている

統合版1.21.70付近では、/testforblock がブロック状態を正しく認識しない不具合がありました。
1.21.90で修正されています。

もし状態指定が明らかに無視される場合は、ワールドやコマンドだけでなく、ゲーム本体のバージョンも確認しましょう。

トラブル時のチェックリスト
- [ ] 座標は合っているか？
- [ ] ブロックIDは合っているか？
- [ ] ブロック状態の = を : にしていないか？
- [ ] ボタンの向きなど、必要な状態も指定しているか？
- [ ] 調べたい場所のチャンクは読み込まれているか？
- [ ] チェーンコマンドブロックは条件付きになっているか？
- [ ] 統合版のバージョンが古すぎないか？

12. まとめ

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

要点を整理すると、

/testforblock は、指定座標に特定のブロックがあるか調べるコマンド
基本構文は /testforblock <座標> <ブロックID> [ブロック状態]
コマンドブロックで使うなら、リピート＋条件付きチェーンが分かりやすい
ボタンやレバーは、押されている状態だけでなく向きの状態も関係する
新しく仕掛けを作るなら /execute if block もかなり便利

という感じです。

/testforblock は、コマンド自体は短いですが、コマンド装置の基本が詰まっています。

「特定の場所にブロックが置かれたら発動」
「ボタンを押したら別の処理へつなぐ」
「パズルの正解判定を作る」

こういう仕掛けを作れるようになると、統合版のコマンド遊びが一気に広がります。

ただし、ブロック状態を扱う時は本当にミスりやすいです。
まずはブロックIDだけで検出できるか確認して、その後に状態指定を少しずつ足していく。
この順番で作ると、失敗した時の原因も見つけやすくなります。

よかったら皆さんもぜひ、簡単なダイヤブロック検出から試してみてください。

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

13. 参考文献

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

ゆずかきのゲーム館