【マイクラ】構造物テンプレートとは?保存形式・配置・データ仕様を解説【Java版】

この記事はマイクラJava版向けの技術解説です
ストラクチャーブロック・データパック・/place template を使いたい方向けです
統合版(BE)とは保存形式やコマンド仕様が違うのでご注意ください

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

マイクラで配布ワールドやデータパックを触っていると、たまに「構造物テンプレート」という言葉が出てきます。

最初に聞くと、

「構造物って村とかピラミッドのこと?」
「テンプレートって設計図みたいなもの?」
「ストラクチャーブロックで保存した建築物と何が違うの?」

…と、けっこう混乱しやすいところだと思います。

結論から言うと、Java版における構造物テンプレートは、建物や部屋などのブロック配置を保存したNBT形式の構造物ファイルのことです。
ストラクチャーブロックで保存した建築物も、内部的にはこの構造物テンプレートとして扱われます。

特にJava版1.21系列では、データパック内のフォルダ名まわりで古い情報と新しい情報が混ざりやすく、ここで詰まる人が多いです。
なので本記事では、構造物テンプレートについて、保存形式・配置方法・データ仕様・1.21以降で注意する変更点まで、なるべく自然に読める形でまとめていきますね。

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

  • 構造物テンプレートが何なのか分かります👍
  • ストラクチャーブロックで保存したファイルの場所が分かります👌
  • Java版1.21以降の structure フォルダ問題で迷いにくくなります
  • /place template で構造物を配置する基本が分かります
  • NBTファイル内部に何が入っているか大まかに理解できます

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

※本記事はJava版1.21系列を主な前提にしています。
※ゲーム内仕様は、Minecraft WikiおよびMinecraft公式リリース情報を参考に整理しています。
※統合版(BE)の .mcstructure 形式とは別物として読んでください。


目次

1. 構造物テンプレートとは?
2. ストラクチャーブロックとの関係
3. 保存形式はNBTファイルです
4. 保存先とフォルダ構成を確認する
5. Java版1.21以降で注意したい変更点
6. 構造物テンプレートのデータ仕様
7. ストラクチャーブロックで保存・読み込みする手順
8. /place templateで配置する方法
9. ストラクチャーヴォイドと空気ブロックの違い
10. サイズ制限と大きい建築物の扱い方
11. データパック化するときの考え方
12. よくある失敗とチェックポイント
13. まとめ
14. 引用・参考文献

この記事で分かること
・マイクラJava版の構造物テンプレートの基本
・NBTファイルとしての保存形式
・ストラクチャーブロックと /place template の使い分け
・Java版1.21以降でつまずきやすいフォルダ名の変更点


1. 構造物テンプレートとは?

構造物テンプレートとは、簡単に言うと、マイクラ内の建築物や部屋、装飾パーツなどを保存した構造物データです。

たとえば、

  • 小さな家
  • ダンジョンの1部屋
  • 遺跡の一部
  • 村の建物
  • 試練の間や要塞のような構造物のパーツ
  • 自作データパックで配置したい建築物

こういったものを、ゲーム側が「この形で置いてね」と扱えるように保存したものが構造物テンプレートです。

普段のサバイバルだけを遊んでいると、あまり意識することはありません。
ただ、配布マップを作ったり、データパックで自作構造物を生成したり、ストラクチャーブロックで建築物をコピーしたりする場合は、急に重要になります。

筆者が最初に混乱したのは、“構造物”という言葉が2種類の意味で使われがちなところでした。

1つ目は、村・砂漠のピラミッド・エンドシティのような、ワールド生成で出てくる建造物としての「構造物」。
2つ目は、ストラクチャーブロックやデータパックで読み込む、ファイルとしての「構造物テンプレート」。

ここを分けて考えると、かなり理解しやすくなります。

構造物テンプレートは「置ける建築データ」

構造物テンプレートは、建築物そのものではなく、建築物を再現するための保存データです。

ワールド内に置かれている建物をそのままコピーしているというより、

  • どの大きさか
  • どの座標にどのブロックがあるか
  • そのブロックの状態は何か
  • チェストや看板などのブロックエンティティ情報を含むか
  • エンティティも含めるか

こういった情報をまとめて保存しています。

つまり、構造物テンプレートはマイクラ版の建築設計図ファイルみたいなものですね。

ただし、普通の画像やテキストではなく、Java版では主に .nbt という形式で保存されます。
このNBT形式については、後の章で説明します。


2. ストラクチャーブロックとの関係

構造物テンプレートを扱ううえで、まず理解しておきたいのがストラクチャーブロックです。

ストラクチャーブロックは、建築物を保存したり、保存した構造物を読み込んだりするための特殊ブロックです。
Java版ではクリエイティブモードやコマンドを使って入手・操作するタイプのブロックで、通常のサバイバル攻略で自然に作れるものではありません。

代表的な入手コマンドはこちらです。

/give @p minecraft:structure_block

ストラクチャーブロックを置いて開くと、主に次のモードを使えます。

モード 役割 よく使う場面
Save 範囲内の構造物を保存する 自作建築をNBTファイル化したい時
Load 保存した構造物を読み込む 保存済みテンプレートをワールドに置く時
Corner 保存範囲の角を指定する 大きさを自動検出したい時
Data 構造物生成用のメタ情報を持たせる 一部のバニラ構造物生成で特殊処理の目印として使われる時


初心者さんがまず覚えるべきなのは、SaveとLoadです。

  • Save:建築物を保存する
  • Load:保存した建築物を読み込む

この2つだけでも、建築物のコピーや配布ワールド作りではかなり役立ちます。

ストラクチャーブロックで保存したものが構造物テンプレートになる

ストラクチャーブロックのSaveモードで建築物を保存すると、Java版では構造物データがファイルとして保存されます。
この保存された .nbt ファイルが、今回のテーマである構造物テンプレートです。

つまり、

ストラクチャーブロック = 保存・読み込みをするための道具
構造物テンプレート = 保存された建築データ本体

という関係です。

ここを押さえておくと、「ストラクチャーブロック」「構造物ファイル」「構造物テンプレート」という言葉が出てきても迷いにくくなります。

操作には権限が必要です

Java版では、ストラクチャーブロックのGUIを開くには、基本的にクリエイティブモードかつ権限レベル2以上が必要です。

シングルプレイならチートを有効にしたワールドで扱うことが多いです。
マルチサーバーの場合は、OP権限がないと操作できない可能性があります。

配布マップ制作や検証ワールドでは問題になりにくいですが、サバイバルサーバーで勝手に使えるものではないので注意してくださいね。


3. 保存形式はNBTファイルです

Java版の構造物テンプレートは、基本的にNBTファイルとして保存されます。
ファイル拡張子は .nbt です。

NBTは「Named Binary Tag」の略で、マイクラのセーブデータやエンティティ情報、ブロックエンティティ情報などでも使われるデータ形式です。
少し技術寄りの話になりますが、構造物テンプレートを理解するうえでは、次のイメージだけでも大丈夫です。

NBT = マイクラが内部データを保存するための専用形式

普通のテキストファイルのように、そのままメモ帳で開いて読み書きするものではありません。
中身を確認したい場合は、NBT編集ツールや、SNBTへ変換できるツールを使うことになります。

構造物テンプレートの拡張子

構造物テンプレートのファイル名は、たとえば次のようになります。

small_house.nbt
ruin_room_01.nbt
trial_room_part.nbt
my_base_template.nbt

ファイル名は、基本的に小文字・数字・アンダーバー・ハイフンを使うのがおすすめです。

大文字や特殊記号を入れると、読み込み時に面倒なことが起きやすいです。
特にデータパック化する予定があるなら、最初から小文字で統一しましょう。

OK例:small_house.nbt
OK例:desert_ruin_01.nbt
避けたい例:SmallHouse.nbt
避けたい例:家テンプレート.nbt

日本語ファイル名でも環境によっては扱える場合がありますが、配布やデータパックを考えるなら避けた方が無難です。

NBTとJSONは別物です

データパックを触っていると、レシピや進捗は .json ファイルで書くことが多いです。
その流れで、構造物テンプレートもJSONだと思ってしまうことがあります。

ですが、構造物テンプレート本体はJSONではなくNBTです。

構造物テンプレート本体:.nbt
ワールド生成設定:.json
データパックの説明:pack.mcmeta

ここが分かれていないと、ファイルを置く場所や編集方法で迷います。

特に、自作構造物をワールド生成に組み込みたい場合は、

  • 建物の形そのもの:.nbt
  • どこに生成するか:.json
  • どのプールから選ぶか:.json

というように、複数のファイルが関係してきます。

本記事では、まず建物の形そのものを保存する構造物テンプレートに絞って解説しますね。


4. 保存先とフォルダ構成を確認する

ストラクチャーブロックで保存した構造物テンプレートは、ワールドフォルダ内の generated フォルダ配下に保存されます。

ここが最初のつまずきポイントです。
ゲーム内で保存ボタンを押しても、インベントリにアイテムとして出てくるわけではありません。
PC上のワールドデータ内に .nbt ファイルとして保存されます。

Java版で、ストラクチャーブロックから保存したファイルを確認する場合、まず見る場所は次のような場所です。

.minecraft/saves/ワールド名/generated/名前空間/structures/構造物名.nbt

たとえば、構造物名を minecraft:small_house として保存した場合、次のような形になります。

.minecraft/saves/MyWorld/generated/minecraft/structures/small_house.nbt

minecraft: を付けずに保存した場合、基本的には minecraft 名前空間として扱われます。
そのため、初心者さんが最初に試すと、generated/minecraft/ の中に保存されていることが多いです。

名前空間を付けると整理しやすいです

自作データパックや配布ワールド用に作るなら、minecraft 名前空間のままではなく、自分用の名前空間を付けるのがおすすめです。

たとえば、次のように保存します。

yuzukaki:small_house

すると、保存先は次のようなイメージになります。

.minecraft/saves/ワールド名/generated/yuzukaki/structures/small_house.nbt

名前空間を分けると、後からデータパック化する時にも整理しやすいです。

体験談寄りの注意点
最初は minecraft: のまま保存しても動きます。
ただ、数が増えてくると「どれが自作で、どれが検証用か」が分からなくなります。
早めに自分用の名前空間を決めておくと、後でかなり楽です。

データパック内の structure フォルダと混同しやすいです

ここは本当にややこしいところです。
Java版1.21以降では、データパック内の構造物テンプレート用フォルダは次のようにstructure(単数形)になっています。

data/名前空間/structure/構造物名.nbt

一方、ストラクチャーブロックでワールド内に保存したファイルは、次のようにgenerated/名前空間/structures/(複数形)側に保存されます。

generated/名前空間/structures/構造物名.nbt

つまり、1.21以降で特に注意したいのは、次の違いです。

ストラクチャーブロックで保存されたワールド側:generated/名前空間/structures/
データパックに入れる配置先:data/名前空間/structure/

「データパックでは structure と聞いたのに、ワールドフォルダを見たら structures になっている」という形で混乱しやすいです。
保存できていないと決めつける前に、ワールド側とデータパック側を分けて確認しましょう。


5. Java版1.21以降で注意したい変更点

構造物テンプレートの記事を書くうえで、Java版1.21以降では避けて通れない注意点があります。
それが、データパック内のフォルダ名変更です。

Java版1.21の開発版で、データパック内の一部ディレクトリ名が、複数形から単数形へ整理されました。
構造物テンプレートもこの影響を受けています。

特に重要なのは、次の変更です。

旧:data/名前空間/structures/
新:data/名前空間/structure/

自作構造物をデータパックに入れる場合、1.21以降では基本的に structure フォルダを使います。

1.20.6以前の解説をそのまま使うと失敗しやすいです

古いデータパック解説では、次のような構成がよく出てきます。

my_datapack/data/yuzukaki/structures/small_house.nbt

ですが、1.21以降では次の形を優先して考えます。

my_datapack/data/yuzukaki/structure/small_house.nbt

この違いだけで、/place template の候補に出てこなかったり、読み込めなかったりします。

ここ重要です
「ファイル名も合っている」
「名前空間も合っている」
「でも読み込めない」
こういう時は、まずデータパック内が structure になっているかを疑ってください。

ただし、これはデータパック内の話です。
ストラクチャーブロックで保存したワールド側のファイルは、generated/名前空間/structures/ に保存されます。
同じ構造物テンプレートでも、置き場所によってフォルダ名が違うので注意してください。

1.13より前の古い構造物にも注意

Java版1.13では、いわゆる「Flattening」によってブロックIDまわりが大きく変わりました。
そのため、1.13より前のバージョンで保存した構造物テンプレートは、現在のJava版でそのまま読み込むとブロックが正しく出ない可能性があります。

たとえば、昔の数値IDや古いブロック名を前提にした構造物は、現行バージョンの名前空間IDと合わない場合があります。

普通に1.20以降で保存した構造物を1.21系列で扱う程度なら、大きく心配しすぎる必要はありません。
ただし、かなり古い配布ワールドや古い構造物ファイルを使う場合は、読み込み後に必ず中身を確認しましょう。

1.16以降は保存サイズ上限が48になっています

Java版のストラクチャーブロックで扱える最大サイズは、現在は最大48×48×48です。
以前はもっと小さい上限だった時期がありました。

そのため、古い記事で「32マスまで」と書かれている場合は、現在のJava版とは少し違います。

ただし、48×48×48でも、大型建築を丸ごと保存するには足りないことがあります。
大きい建築物を扱う場合は、後述するように複数パーツに分けて保存するのがおすすめです。


6. 構造物テンプレートのデータ仕様

ここから少しだけ中身の話をします。
難しく見えますが、実際に覚えるべきポイントはそれほど多くありません。

構造物テンプレートの .nbt ファイルには、主に次のような情報が入っています。

項目 意味 初心者向けの理解
DataVersion 保存時のデータバージョン どの仕様で保存されたかの目印
size 構造物のX・Y・Zサイズ 横・高さ・奥行き
palette 使われているブロック状態の一覧 ブロックの種類リスト
blocks 各ブロックの位置と状態 どこに何のブロックを置くか
entities 保存されたエンティティ情報 額縁・防具立て・Mobなど


これだけ見ると難しそうですが、実際は次のように考えればOKです。

size で範囲を決めて、
palette で使うブロックの種類をまとめて、
blocks で座標ごとにブロックを配置し、
必要なら entities も保存する。

これが構造物テンプレートの基本です。

paletteはブロックの辞書のようなもの

palette は、構造物の中で使われているブロック状態の一覧です。

たとえば、石・オークの板材・ガラス・松明を使っている建築物なら、それらのブロック状態がまとめて登録されます。

blocks 側では、毎回「これはオークの板材です」と全部書くのではなく、palette の何番目を使うかで指定します。

この仕組みによって、同じブロックが何百個あっても、ファイル内で効率よく管理できます。

blocksは座標情報です

blocks には、構造物内の各ブロックについて、

  • どの位置にあるか
  • paletteのどのブロック状態を使うか
  • 必要ならブロックエンティティ情報を持つか

が保存されます。

チェスト、看板、かまど、樽、コマンドブロックなどは、ただのブロックIDだけでは情報が足りません。
中身やテキストなどの追加情報があるため、必要に応じてNBT情報も一緒に保存されます。

entitiesは保存設定と読み込み設定次第です

ストラクチャーブロックには、エンティティを含めるかどうかの設定があります。
保存時にここをオンにすると、構造物内のエンティティも保存対象になります。

たとえば、

  • 防具立て
  • 額縁
  • 絵画
  • ボート
  • Mob

などですね。

ただし、保存しただけで必ず読み込み時に出るわけではありません。
Java版のLoadモードにも、保存されたエンティティを含めて読み込むかどうかの設定があります。
エンティティ込みで再現したい場合は、保存時と読み込み時の両方を確認しましょう。

エンティティを含めると、読み込み時に意図しないものまで再配置されることがあります。
建築物の形だけ保存したい場合は、エンティティを含めない方が管理しやすいです。

筆者のおすすめ
建築テンプレートとして使うだけなら、最初はエンティティなしで保存。
額縁や防具立て込みの装飾を再現したい時だけ、エンティティ保存をオンにすると扱いやすいです。


7. ストラクチャーブロックで保存・読み込みする手順

ここでは、実際にストラクチャーブロックで構造物テンプレートを保存して読み込む基本手順を整理します。

複雑に見えますが、流れはシンプルです。

1. ストラクチャーブロックを入手する

まずはコマンドでストラクチャーブロックを入手します。

/give @p minecraft:structure_block

クリエイティブモードで、チートが有効なワールドで実行してください。

2. Saveモードにする

ストラクチャーブロックを設置して開き、モードをSaveにします。

保存したい構造物名を入力します。

yuzukaki:small_house

このように名前空間を付けておくと、後から探しやすいです。

3. 保存範囲を指定する

次に、保存したい範囲を指定します。

設定する主な項目は、

  • 相対位置
  • 構造物のサイズ
  • エンティティを含めるか
  • 不可視ブロックを表示するか

などです。

最初は、小さな建物で試すのがおすすめです。
いきなり大型建築を保存しようとすると、範囲指定や向きで混乱しやすいです。

4. 保存ボタンを押す

範囲が決まったら、Saveボタンを押します。
成功すると、ワールドフォルダ内に .nbt ファイルが保存されます。

保存後、ファイルが見つからない場合は、次の場所を確認してください。

.minecraft/saves/ワールド名/generated/名前空間/structures/

データパックにコピーする時は、ここから .nbt ファイルを取り出して、データパック側の data/名前空間/structure/ に入れる流れになります。

5. Loadモードで読み込む

保存した構造物を置きたい場所にストラクチャーブロックを置き、モードをLoadにします。

構造物名には、保存時と同じ名前を入力します。

yuzukaki:small_house

Java版では、読み込みボタンを押すと、まず配置範囲のプレビューが出ます。
位置や向きを確認して問題なければ、もう一度読み込みを実行して配置します。

ここで焦らなくて大丈夫です
いきなり建築物が置かれるのではなく、プレビューを見てから確定できます。
大型の構造物を置く時は、必ずプレビューを見て周囲を確認しましょう。

6. 回転・反転もできます

Loadモードでは、構造物の回転や反転も指定できます。

  • 回転なし
  • 90度回転
  • 180度回転
  • 反時計回り90度回転
  • 左右反転
  • 前後反転

建築物を複数向きで使い回したい場合、回転と反転はとても便利です。
ただし、階段・看板・ドア・レッドストーン装置などは、向きや接続が意図通りになるか確認してください。


8. /place templateで配置する方法

構造物テンプレートは、ストラクチャーブロックだけでなく、コマンドでも配置できます。
Java版では、/place template を使います。

基本構文はこちらです。

/place template <template> [<pos>] [<rotation>] [<mirror>] [<integrity>] [<seed>]

たとえば、自作テンプレート yuzukaki:small_house を現在位置に配置したい場合は、次のように実行します。

/place template yuzukaki:small_house ~ ~ ~

座標を指定する場合はこちらです。

/place template yuzukaki:small_house 100 64 100

回転を指定する

回転を指定したい場合は、次のように書きます。

/place template yuzukaki:small_house ~ ~ ~ clockwise_90

使える回転指定は主に次の通りです。

none
clockwise_90
counterclockwise_90
180

反転を指定する

反転を指定する場合は、回転の後ろに指定します。

/place template yuzukaki:small_house ~ ~ ~ none front_back

使える反転指定は主に次の通りです。

none
front_back
left_right

integrityで一部だけ欠けた配置もできます

integrity は、構造物をどのくらい完全に配置するかを決める値です。
範囲は 0.0 から 1.0 です。

1.0 = 完全に配置
0.5 = おおよそ半分程度のブロックが配置候補
0.0 = ブロックが配置されない

たとえば、古びた遺跡っぽく一部を欠けさせたい場合は、次のようにできます。

/place template yuzukaki:ruin_room ~ ~ ~ none none 0.75 12345

seed を指定すると、欠け方のランダム性を固定できます。
同じseedなら同じような欠け方になります。

使いどころ
普通の家を配置するなら integrity1.0 でOKです。
遺跡・廃墟・壊れた施設を作りたい時に、integrity を下げると雰囲気を作りやすいです。

/place structureとは別物です

ここも混乱しやすいです。

/place structure minecraft:village_plains

のような /place structure は、ワールド生成の構造物を配置するコマンドです。
一方、今回扱っている構造物テンプレートを配置する場合は、

/place template yuzukaki:small_house

のように、template を使います。

名前が似ていますが、役割が違うので注意してくださいね。


9. ストラクチャーヴォイドと空気ブロックの違い

構造物テンプレートを扱う時、地味に大事なのがストラクチャーヴォイドです。

ストラクチャーヴォイドは、見た目にはほぼ見えない特殊ブロックで、構造物を読み込む時に「ここは既存ブロックをそのまま残してね」という用途で使えます。

空気を保存すると既存ブロックを消します

構造物テンプレート内に空気ブロックが保存されている場合、その場所に読み込み先のブロックがあれば、空気で置き換えられます。

つまり、既存の地形や建築を削ることがあります。

これは、建物の内側を空洞にしたい時には便利です。
家の中に土や石が残ると困るので、空気で置換してくれる方が助かります。

ただし、装飾パーツだけを既存建築に貼り付けたい時は、空気で周囲を削ってしまう可能性があります。

ストラクチャーヴォイドは既存ブロックを残します

一方、ストラクチャーヴォイドを使うと、その場所は読み込み時に既存ブロックを残すように扱えます。

たとえば、壁飾りだけを保存して、貼り付け先の壁は壊したくない場合に便利です。

空気:読み込み先を空気に置き換える
ストラクチャーヴォイド:読み込み先を残す

この違いはかなり大事です。

建築パーツ保存ではストラクチャーヴォイドが便利

たとえば、次のようなものを保存する場合は、ストラクチャーヴォイドが役立ちます。

  • 壁飾り
  • 天井装飾
  • 道路の一部
  • 遺跡の欠けたパーツ
  • 既存地形に自然になじませたい小物

逆に、家や部屋のように「内部空間をしっかり作りたい」構造物では、空気を残しておいた方が都合が良い場面もあります。

ここは目的次第ですね。

筆者の考え方
建物を丸ごと保存するなら空気込み。
装飾パーツを後付けするならストラクチャーヴォイド。
この使い分けをすると、読み込み後の修正がかなり減ります。


10. サイズ制限と大きい建築物の扱い方

Java版のストラクチャーブロックで一度に扱える構造物サイズは、現在は最大48×48×48です。

この範囲内に収まる小屋、部屋、塔の一部、装飾パーツなら問題ありません。
ただし、大型拠点や城、巨大建築を丸ごと保存しようとすると、すぐ上限に引っかかります。

大型建築は分割保存がおすすめです

48×48×48を超える建築物は、無理に1ファイルで扱おうとせず、パーツごとに分けるのがおすすめです。

たとえば城なら、

  • 正門
  • 左の塔
  • 右の塔
  • 中央ホール
  • 城壁A
  • 城壁B
  • 内装部屋

というように、複数のテンプレートに分けます。

castle_gate.nbt
castle_tower_left.nbt
castle_tower_right.nbt
castle_wall_01.nbt
castle_hall.nbt

この方が、配置ミスした時の修正も楽です。

巨大建築を1回で読み込もうとすると、位置合わせが難しいですし、ミスした時の戻し作業も大変です。
パーツ分割は少し面倒ですが、結果的に安全です。

基準ブロックを決めると配置しやすいです

分割保存する時は、各パーツの基準位置を決めておくと便利です。

おすすめは、各パーツの角に分かりやすい仮ブロックを置いておく方法です。

たとえば、保存前だけ金ブロックを置いておき、読み込み後に撤去するなどですね。
もちろん配布用の最終データでは消しておきます。

基準位置がないと、後から複数パーツをつなげる時に1マスずれて困ることがあります。

レッドストーン装置は読み込み後に必ず確認

レッドストーン装置を構造物テンプレート化する場合は、読み込み後に動作確認してください。

理由は、

  • 向きによって接続が変わる
  • 回転で階段・観察者・ピストンの向きが変わる
  • 読み込み順や更新で一部が動作する
  • 水や溶岩が流れ出すことがある

などがあるからです。

特にピストンや観察者を含む装置は、構造物テンプレート化しても、置いた瞬間に完全再現されるとは限りません。
装置系は、配置後に1回テストするくらいの気持ちで扱いましょう。


11. データパック化するときの考え方

保存した構造物テンプレートは、データパックに入れて使うこともできます。
ここでは、基本的なフォルダ構成を整理します。

Java版1.21以降を前提にする場合、構造物テンプレートは次の場所に入れます。

データパック名/
├─ pack.mcmeta
└─ data/
   └─ yuzukaki/
      └─ structure/
         └─ small_house.nbt

この場合、ゲーム内での名前は次のようになります。

yuzukaki:small_house

structure フォルダ内にサブフォルダを作ることもできます。

data/yuzukaki/structure/house/small_house.nbt

この場合は、次のように指定します。

/place template yuzukaki:house/small_house ~ ~ ~

pack.mcmetaも必要です

データパックとして読み込むには、ルートに pack.mcmeta が必要です。

例として、Java版1.21.0向けなら次のような形です。

{
  "pack": {
    "pack_format": 48,
    "description": "Yuzukaki custom structures"
  }
}

ただし、pack_format の値はマイクラのバージョンによって変わります。
1.21系列でも細かい更新で値が変わるため、実際に配布する時は、使っているJava版のバージョンに合った値を確認してください。

保存したファイルをデータパックへ移す流れ

実際の流れはこんな感じです。

  1. 検証用ワールドでストラクチャーブロックを使って保存する
  2. generated/名前空間/structures/ から .nbt ファイルを探す
  3. データパック内の data/名前空間/structure/ にコピーする
  4. ワールドにデータパックを入れる
  5. /reload する
  6. /place template 名前空間:構造物名 で配置確認する

ここまでできれば、構造物テンプレートをデータパック側で管理できます。

データパックに入れると読み込み優先度も関係します

同じ名前の構造物テンプレートが複数ある場合、読み込みの優先順位にも注意が必要です。

たとえば、同じ yuzukaki:small_house が、

  • メモリ上
  • ワールドのgeneratedフォルダ
  • データパック内

に存在する場合、どれが使われるかで結果が変わることがあります。

検証中に「データパックを差し替えたのに見た目が変わらない」という時は、ワールド内に同名の保存済み構造物が残っていないか確認してください。

ここも地味にハマります
同じ名前で何度も保存していると、古いデータを読み込んでいるのか、新しいデータを読み込んでいるのか分からなくなります。
検証用の名前と配布用の名前は分けておくと安心です。


12. よくある失敗とチェックポイント

構造物テンプレートを扱っていると、最初はけっこう失敗します。
ここでは、よくある原因をまとめておきますね。

読み込めない場合

  • [ ] データパック内が data/名前空間/structure/ になっているか?
  • [ ] ワールド側の保存ファイルを探す時に generated/名前空間/structures/ を見ているか?
  • [ ] 名前空間を付け忘れていないか?
  • [ ] ファイル名に大文字や特殊文字を使っていないか?
  • [ ] .nbt ファイルが正しい場所にあるか?
  • [ ] データパックを入れた後に /reload したか?
  • [ ] pack.mcmeta の形式が壊れていないか?
  • [ ] 構造物名の入力が保存時と完全に一致しているか?

特に多いのは、やはりフォルダ名です。
1.21以降なら、データパック側はまず data/名前空間/structure/ を確認してください。
ワールドに保存されたファイルを探す場合は、generated/名前空間/structures/ 側を見るのがポイントです。

位置がずれる場合

  • [ ] 保存時の相対位置を間違えていないか?
  • [ ] ストラクチャーブロックの位置を基準に考えているか?
  • [ ] 回転時の基準位置を確認したか?
  • [ ] 分割パーツに基準ブロックを用意したか?

構造物テンプレートは、保存した範囲の原点やストラクチャーブロックとの相対位置が大事です。
1マスずれるだけで、ドアが埋まったり、床が浮いたりします。

最初は小さな3×3くらいの構造物で練習すると、感覚をつかみやすいです。

ブロックが消える・地形が削れる場合

  • [ ] 空気ブロック込みで保存していないか?
  • [ ] ストラクチャーヴォイドを使うべき場所ではないか?
  • [ ] integrityを下げすぎていないか?
  • [ ] 回転・反転後に欠け方が想定と違っていないか?

地形を残したいなら、空気とストラクチャーヴォイドの使い分けが重要です。
特に装飾パーツを貼る用途では、空気で保存すると周囲を削ってしまう場合があります。

エンティティが出ない場合

  • [ ] 保存時にエンティティを含める設定にしたか?
  • [ ] 読み込み時にもエンティティを含める設定にしたか?
  • [ ] 読み込み先の難易度やゲームルールで消えていないか?
  • [ ] Mobの場合、読み込み後にデスポーンしていないか?
  • [ ] 額縁や防具立ての位置が範囲外になっていないか?

建築物だけならエンティティなしで構いません。
ただし、装飾として額縁や防具立てまで保存したい場合は、保存時と読み込み時のエンティティ設定を忘れないようにしましょう。

1.21以降の移行で見つからない場合

  • [ ] データパック内で古い structures フォルダのままになっていないか?
  • [ ] データパック側は data/名前空間/structure/ に移したか?
  • [ ] ワールド内の generated/名前空間/structures/ 側とデータパック側を混同していないか?
  • [ ] 同名テンプレートが複数箇所に存在していないか?

バージョンをまたいで作業している人ほど、ここで迷いやすいです。
ファイルが見つからない時は、検索で .nbt を探すのも手です。

ワールドフォルダ内で「*.nbt」を検索する

これで保存場所が分かることがあります。


13. まとめ

以上、マイクラJava版の構造物テンプレートについて、保存形式・配置・データ仕様をまとめました。

最後に要点を整理します。

  • 構造物テンプレートは、建築物や構造物パーツを保存したNBT形式のデータ
  • ストラクチャーブロックのSaveで保存し、Loadで読み込める
  • Java版では .nbt ファイルとして保存される
  • ストラクチャーブロックで保存したワールド側のファイルは generated/名前空間/structures/ に保存される
  • Java版1.21以降では、データパック内のフォルダは基本的に structure(単数形)
  • ワールド側の structures と、データパック側の structure を混同しないように注意
  • /place template を使えばコマンドから構造物テンプレートを配置できる
  • NBT内には DataVersionsizepaletteblocksentities などの情報が入る
  • 大型建築は48×48×48の制限があるため、分割保存がおすすめ
  • 空気とストラクチャーヴォイドの違いを理解すると、読み込み事故が減る

構造物テンプレートは、普通のサバイバルではあまり使いません。
でも、配布ワールド制作、データパック制作、検証ワールド作りではかなり便利です。

最初は専門用語が多くて難しそうに見えますが、まずは小さな建物を1つ保存して、読み込んでみるだけで一気に理解しやすくなります。

個人的には、いきなりジグソー構造物やワールド生成に進むより、

  1. ストラクチャーブロックで小屋を保存する
  2. Loadで読み込む
  3. /place template で置いてみる
  4. データパックへ移して読み込む

この順番で触るのがおすすめです。

構造物テンプレートを扱えるようになると、建築物の再利用や配布ワールド制作がかなり楽になります。
皆さんもぜひ、小さな建築から試してみてくださいね。

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


14. 引用・参考文献

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