トップ > マイクラwiki > 【マイクラ】テンプレートプールとは？ジグソー構造物・生成候補の仕組み【Java版】
最終更新日

【マイクラ】テンプレートプールとは？ジグソー構造物・生成候補の仕組み【Java版】

マイクラwiki

この記事はJava版でデータパック・ジグソーブロックを触り始めた方向けです
テンプレートプールの意味、生成候補、重み、fallbackの仕組みを実録ベースで整理します
統合版(BE)とは仕様が異なるため、Java版前提で読んでください

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

マイクラでデータパックのカスタム構造物を調べていると、かなり高確率で出てくるのがテンプレートプールです。

ただ、この言葉、最初はかなり分かりにくいです。
「テンプレート？」「プール？」「ジグソーブロックと何が違うの？」となりやすいんですよね。

結論から言うと、テンプレートプールとは、ジグソー構造物が次に生成する構造物パーツの候補リストです。
村の道、家、広場、砦の部屋、通路、行き止まりパーツなどを、候補としてまとめておく場所だと思えば大丈夫です。

この記事では、マイクラJava版のテンプレートプールについて、次の内容を順番に解説します。

  • テンプレートプールとは何か
  • ジグソーブロック・ジグソー構造物との関係
  • weight、fallback、projectionの意味
  • Java版1.21以降で注意したいフォルダ名変更
  • 初心者がつまずきやすいミスと確認ポイント

難しい仕様をそのまま並べると読みにくいので、この記事では実際にデータパックを作る時に必要になる順番で整理していきますね。

※本記事はJava版のデータパック仕様を前提にしています。
※Java版1.21以降では一部のデータパックフォルダ名が変更されています。古い解説を見ながら作る場合は特に注意してください。

目次

1. テンプレートプールとは
2. ジグソー構造物とは何が違う？
3. ジグソーブロックとの関係
4. テンプレートプールJSONの基本構造
5. elementsとweightの仕組み
6. fallbackは“行き止まり処理”にも使える
7. projectionのrigidとterrain_matchingの違い
8. element_typeの種類と使い分け
9. データパック内の置き場所と1.21以降の注意点
10. 実際に作る時の流れ
11. よくある失敗とチェックポイント
12. まとめ
13. 引用・参考文献

この記事で分かること
・マイクラJava版のテンプレートプールの意味
・ジグソー構造物で部屋や通路がランダム生成される仕組み
・データパックでカスタム構造物を作る時の基本的な考え方

1. テンプレートプールとは

テンプレートプールとは、簡単に言うと、構造物パーツの候補リストです。

マイクラのジグソー構造物では、1つの大きな建物を最初から丸ごと固定で置くのではなく、複数の小さなパーツをつなげて生成します。

たとえば村なら、

  • 道
  • 家
  • 畑
  • 井戸
  • 広場
  • 装飾パーツ

こういう小さなパーツを組み合わせて、毎回少し違う村っぽい形を作ります。

この時に、ゲーム側が「次はどのパーツを置こうかな？」と選ぶための候補箱がテンプレートプールです。

かなり身近な例で言うと、くじ引き箱みたいなものですね。

  • 家Aを入れる
  • 家Bを入れる
  • 畑を入れる
  • 空白を入れる
  • 行き止まりパーツを入れる

こうして候補を入れておくと、ジグソー構造物の生成時にその中から選ばれます。

ここが大事です
テンプレートプールは、構造物そのものではありません。
あくまで、構造物パーツを選ぶための候補リストです。

ここを勘違いすると、データパックを作る時にかなり混乱します。
筆者も最初、「テンプレートプールを作れば構造物が湧く」と思っていましたが、実際は違います。

テンプレートプールは、ジグソー構造物の部品置き場。
ワールドに実際に生成させるには、別途 worldgen/structure や worldgen/structure_set 側の設定も必要になります。

2. ジグソー構造物とは何が違う？

テンプレートプールを理解するには、まずジグソー構造物との違いを押さえると楽です。

ジグソー構造物は、マイクラ内で複数の構造物テンプレートをつなげて生成する仕組みです。
村、古代都市、ピリジャーの前哨基地など、複数パーツで構成される建造物のイメージに近いです。

一方でテンプレートプールは、そのジグソー構造物が使う部品リストです。

用語 役割 イメージ
ジグソー構造物 全体の生成ルール 村やダンジョン全体の設計図
テンプレートプール 生成候補のリスト 家・道・部屋などの候補箱
構造物テンプレート 実際に置かれるNBTパーツ 1軒の家、1本の通路、1部屋
ジグソーブロック パーツ同士の接続点 部屋と通路をつなぐ差し込み口


つまり、ジグソー構造物を作る時は、

  1. まず構造物テンプレートを作る
  2. その中にジグソーブロックを仕込む
  3. テンプレートプールに候補として登録する
  4. worldgen/structure 側で開始プールを指定する
  5. structure_set 側でワールド生成条件を決める

という流れになります。

テンプレートプールだけを見ると地味ですが、ランダム生成の遊び幅を作っている重要な部分だと思ってください。

3. ジグソーブロックとの関係

テンプレートプールとセットで必ず出てくるのが、ジグソーブロックです。

ジグソーブロックは、構造物パーツの中に置いておく接続用ブロックです。
このブロックに「次はこのプールから候補を探してね」という情報を入れておくことで、別の構造物パーツがくっつきます。

ジグソーブロックで特に見るべき項目は、主にこのあたりです。

  • Target Pool：次に探しに行くテンプレートプール
  • Name：このジグソーブロック自身の名前
  • Target Name：接続したい相手側ジグソーブロックの名前
  • Turns into：生成後にジグソーブロックが置き換わるブロック
  • Joint Type：上下方向接続時の回転・整列の設定
  • Selection Priority：同じパーツ内の接続候補を処理する優先度
  • Placement Priority：接続後のパーツを広げていく時の処理優先度

少しややこしいですが、最初に大事なのはTarget PoolとTarget Nameです。

たとえば、ある通路パーツのジグソーブロックに、

Target Pool: yuzukaki:ruins/rooms
Target Name: yuzukaki:room_entrance

と入れておくとします。

この場合、ゲーム側は yuzukaki:ruins/rooms というテンプレートプールを見に行きます。
そして、その候補の中から yuzukaki:room_entrance という名前のジグソーブロックを持つパーツを探して接続します。

初心者さんが混乱しやすいところ
Target Poolは「どの候補箱を見るか」。
Target Nameは「候補の中で、どの接続口を探すか」。

ここを分けて考えるとかなり理解しやすいです。

テンプレートプールは候補箱。
ジグソーブロックは差し込み口。
Target Nameは差し込み口の合言葉。

こう考えると、だいぶ見通しが良くなります。

4. テンプレートプールJSONの基本構造

テンプレートプールは、データパック内ではJSONファイルとして管理します。
基本形はこんな感じです。

{
  "fallback": "minecraft:empty",
  "elements": [
    {
      "weight": 3,
      "element": {
        "element_type": "minecraft:single_pool_element",
        "location": "yuzukaki:ruins/room_a",
        "projection": "rigid",
        "processors": "minecraft:empty"
      }
    },
    {
      "weight": 1,
      "element": {
        "element_type": "minecraft:single_pool_element",
        "location": "yuzukaki:ruins/room_b",
        "projection": "rigid",
        "processors": "minecraft:empty"
      }
    }
  ]
}

このJSONの中で、まず見ればいいのは2つです。

  • fallback：通常候補が使えなかった時の補欠プール
  • elements：実際にランダム選択される候補リスト

elements の中に、生成候補となる構造物テンプレートを並べます。
各候補には weight があり、これが選ばれやすさになります。

ここで指定している location は、構造物テンプレートのIDです。
Java版1.21以降なら、たとえば下記のようなファイル配置を想定します。

data/yuzukaki/structure/ruins/room_a.nbt

この場合、JSON上では次のように書きます。

yuzukaki:ruins/room_a

.nbt は書きません。
ファイルパスとID表記が少し違うので、ここは最初に間違えやすいです。

5. elementsとweightの仕組み

elements は、テンプレートプールの中身です。
つまり、ランダム生成される候補の一覧ですね。

各候補には weight を付けられます。
これは、どれくらい選ばれやすいかを決める数値です。

たとえば、次のような候補があるとします。

候補 weight 選ばれやすさのイメージ
room_a 5 かなり出やすい
room_b 3 そこそこ出る
treasure_room 1 レア部屋


この場合、重みの合計は 5 + 3 + 1 = 9 です。
選ばれる確率の目安は、

  • room_a：5/9
  • room_b：3/9
  • treasure_room：1/9

となります。

weight は1以上150以下で指定します。
数値を大きくすればするほど選ばれやすくなりますが、序盤はあまり複雑にしなくて大丈夫です。

筆者の感覚では、最初は、

  • 普通の部屋：5
  • 少し変化のある部屋：2〜3
  • レア部屋：1

くらいで組むと分かりやすいです。

注意点
weight は「必ず何回に1回出る」という保証ではありません。
あくまでランダム選択時の比重です。

なので、検証時に10回生成してレア部屋が出なかったとしても、即バグとは限りません。
生成テストをする時は、ある程度回数を増やして確認しましょう。

6. fallbackは“行き止まり処理”にも使える

fallback は、通常の候補が使えなかった時に参照される補欠プールです。

テンプレートプールでは、候補に入っている構造物が必ず置けるとは限りません。
周囲のパーツと重なったり、接続条件に合わなかったり、ジグソー構造物側の深さ制限に到達したりすると、通常候補が使えないことがあります。

その時に使われるのが fallback です。

たとえば、ダンジョンの通路を作っている場合、何も考えずに部屋と通路だけを増やすと、接続口が残ったまま終わってしまうことがあります。
そこで、fallbackに行き止まり用のパーツを入れておくと、最後の見た目が自然になります。

{
  "fallback": "yuzukaki:ruins/terminators",
  "elements": [
    {
      "weight": 4,
      "element": {
        "element_type": "minecraft:single_pool_element",
        "location": "yuzukaki:ruins/corridor_straight",
        "projection": "rigid",
        "processors": "minecraft:empty"
      }
    }
  ]
}

この例では、通常は corridor_straight を生成しようとします。
でも、深さ制限や配置失敗などで続きが作れない場合、yuzukaki:ruins/terminators を見に行きます。

そして terminators 側に、

  • 壁で塞ぐパーツ
  • 崩れた通路パーツ
  • 小さな行き止まり部屋

などを入れておくと、自然に終端処理できます。

実用面ではここがかなり大事です
カスタム構造物は、終わり方を作っておかないと不自然になりやすいです。
fallbackは、ただの保険ではなく、見た目を整えるための仕組みとしても使えます。

最初の検証では minecraft:empty でも大丈夫です。
ただ、見た目をきれいにしたいなら、専用の行き止まりプールを用意するのがおすすめです。

7. projectionのrigidとterrain_matchingの違い

テンプレートプールの候補には、projection という項目があります。
ここには主に、

  • rigid
  • terrain_matching

のどちらかを指定します。

rigid は、構造物パーツの高さを固定して置く設定です。
家、部屋、塔、ダンジョン、地下通路など、形を崩したくないパーツは基本的に rigid で良いです。

一方で terrain_matching は、地形に合わせて高さを調整する設定です。
村の道のように、地面に沿わせたいパーツで使うイメージですね。

projection 特徴 向いているパーツ
rigid 高さを固定して生成 家・部屋・塔・地下構造物
terrain_matching 地形に合わせて高さが変わる 道・屋外の地形追従パーツ


初心者さんがカスタム構造物を作るなら、最初は rigid で統一した方が扱いやすいです。
特に地下ダンジョンや部屋接続タイプの構造物で terrain_matching を使うと、高さが意図せずズレて見えることがあります。

筆者のおすすめ
最初のカスタム構造物は、rigid だけで作る。
道や村風の屋外構造物に挑戦する段階で、terrain_matching を試す。

この順番が一番事故りにくいと思います。

8. element_typeの種類と使い分け

テンプレートプールの element_type は、その候補が何を生成するかを決める項目です。

主な種類は下記です。

element_type 内容 初心者向けの使い方
minecraft:single_pool_element 構造物テンプレートを生成 基本はこれでOK
minecraft:legacy_single_pool_element 古い挙動寄りの構造物テンプレート生成 明確な理由がなければ後回し
minecraft:empty_pool_element 何も生成しない候補 空白や生成確率調整に使える
minecraft:list_pool_element 複数要素をまとめて生成 慣れてからでOK
minecraft:feature_pool_element 配置済みフィーチャーを生成 装飾寄り。中級者向け


最初に覚えるべきなのは、minecraft:single_pool_element です。
普通に .nbt の構造物パーツを候補として入れるなら、ほぼこれを使います。

single_pool_element と legacy_single_pool_element の違いで重要なのは、空気ブロックの扱いです。
single_pool_element は空気による置き換えが発生するため、既存ブロックを残したい場所には structure_void を使って調整します。

ここも最初は混乱しやすいです。
「空気で消えちゃった」「残したい地形まで削れた」という場合は、構造物テンプレート側の空気や structure_void の扱いを見直してください。

empty_pool_element は、何も生成しない候補です。
たとえば、

  • たまに部屋を生成しない
  • 分岐を作りすぎない
  • 装飾をランダムで欠けさせる

こういう使い方ができます。

ただし、最初の1個目の構造物を作る段階では、無理に使わなくても大丈夫です。
まずは single_pool_element で、部屋や通路がちゃんと接続されるところまで確認しましょう。

9. データパック内の置き場所と1.21以降の注意点

テンプレートプールは、Java版のデータパック内では次の場所に置きます。

data/<namespace>/worldgen/template_pool/<name>.json

たとえば、名前空間を yuzukaki、プール名を ruins/rooms にするなら、配置はこうなります。

data/yuzukaki/worldgen/template_pool/ruins/rooms.json

構造物テンプレートの .nbt は、Java版1.21以降では次の場所です。

data/<namespace>/structure/<name>.nbt

たとえば、

data/yuzukaki/structure/ruins/room_a.nbt

なら、テンプレートプールJSON内の location は、

yuzukaki:ruins/room_a

になります。

ここで本当に注意したいのが、Java版1.21以降のフォルダ名変更です。

Java版1.21の開発版で、一部のデータパック内フォルダ名が複数形から単数形へ変更されました。
構造物テンプレートも、古い解説では structures と書かれていることがありますが、1.21以降では structure を使います。

用途 1.20.6以前で見かける書き方 1.21以降の書き方
構造物テンプレート structures structure
進捗 advancements advancement
レシピ recipes recipe
関数 functions function
ルートテーブル loot_tables loot_table


ここは本当にハマりやすいです
JSONの中身が合っていても、フォルダ名が古いだけで読み込まれないことがあります。

2026年時点のJava版では、バージョン表記も従来の 1.21.x 系から 26.1.x のような年ベースの表記へ移行しています。
ただし、テンプレートプールの基本的な考え方自体は、候補リスト・重み・fallbackという点で変わりません。

データパックを作る時は、遊んでいる本体バージョンに合わせて pack.mcmeta の形式とフォルダ名を確認してくださいね。

10. 実際に作る時の流れ

ここからは、テンプレートプールを使ってカスタム構造物を作る時の流れを、実録寄りに整理します。

最初から大きな村や巨大ダンジョンを作ろうとすると、だいたいどこかで詰まります。
なので、最初は部屋1個＋通路1個＋行き止まり1個くらいで十分です。

1. 構造物テンプレートを作る

まずは、ストラクチャーブロックを使って .nbt の構造物テンプレートを保存します。

最初に作るなら、

  • start_room
  • corridor
  • end_room

くらいで大丈夫です。

この時、接続したい場所にジグソーブロックを置いておきます。
通路の入り口、部屋の出口などですね。

2. ジグソーブロックに名前を付ける

ジグソーブロックには、接続用の名前を付けます。
たとえば、部屋の入り口なら、

yuzukaki:room_entrance

通路の出口なら、

yuzukaki:corridor_end

のように、自分で分かる名前を付けます。

名前は後から自分が見返して理解できるものにしてください。
ここを適当にすると、数日後の自分が困ります。

3. テンプレートプールに登録する

保存した .nbt を、テンプレートプールJSONに登録します。

{
  "fallback": "yuzukaki:ruins/terminators",
  "elements": [
    {
      "weight": 5,
      "element": {
        "element_type": "minecraft:single_pool_element",
        "location": "yuzukaki:ruins/corridor",
        "projection": "rigid",
        "processors": "minecraft:empty"
      }
    },
    {
      "weight": 2,
      "element": {
        "element_type": "minecraft:single_pool_element",
        "location": "yuzukaki:ruins/small_room",
        "projection": "rigid",
        "processors": "minecraft:empty"
      }
    }
  ]
}

4. start_poolを指定する

ジグソー構造物側では、最初に使うプールを start_pool として指定します。
ここで指定したプールから、最初のパーツが選ばれます。

worldgen/structure 側の size は、ジグソー構造物の生成深度です。
0〜7の範囲で指定され、数字が大きいほど接続が伸びやすくなります。
ジグソーブロック画面の Levels は0〜20まで指定できるので、ここは少し混同しやすいです。

最初のテストなら、いきなり7にせず、2〜3くらいで確認するのがおすすめです。
広げすぎると、失敗時に原因が追いにくくなります。

5. /place などで検証する

データパックを読み込んだら、まずはコマンドで配置確認しましょう。
ワールド生成に組み込む前に、パーツ同士がつながるかを見るのが大事です。

筆者のおすすめ検証順
まず単体の構造物テンプレートを確認。
次にテンプレートプールを確認。
最後にワールド生成へ組み込む。

いきなり自然生成までやると、失敗した時に、

  • 構造物テンプレートが悪いのか
  • ジグソーブロック設定が悪いのか
  • テンプレートプールが悪いのか
  • 構造物の生成条件が悪いのか

分からなくなります。

面倒でも、1つずつ確認する方が結局早いです。

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

テンプレートプール周りでよくある失敗をまとめます。
データパックが読み込まれない、ジグソー構造物が生成されない、候補が選ばれない時は、ここを見直してください。

  • [ ] data/<namespace>/worldgen/template_pool/ にJSONを置いているか？
  • [ ] Java版1.21以降なのに structures フォルダを使っていないか？
  • [ ] 構造物テンプレートは data/<namespace>/structure/ に入っているか？
  • [ ] location に .nbt を書いていないか？
  • [ ] weight は1以上150以下になっているか？
  • [ ] processors を書き忘れていないか？
  • [ ] ジグソーブロックの Target Pool が存在するテンプレートプールを指しているか？
  • [ ] Target Name と相手側ジグソーブロックの Name が一致しているか？
  • [ ] ジグソーブロックの向きが合っているか？
  • [ ] パーツ同士が重なって配置失敗していないか？
  • [ ] worldgen/structure 側の size を大きくしすぎて原因が追えなくなっていないか？
  • [ ] fallback が存在しないプールを指していないか？

特に多いのは、NameとTarget Nameの不一致です。
1文字でも違うと接続されません。

また、ジグソーブロックは向きも重要です。
水平接続は水平同士、上向き・下向きは対応する向き同士で接続されます。
名前が合っているのに接続されない時は、ブロックの向きも見てください。

もう1つ、Java版1.21以降で古い記事を参考にしている方は、フォルダ名の違いにも注意です。
structure と structures の違いだけで丸ごと動かないことがあります。

困った時の見直し方
まずはテンプレートプールを疑う前に、構造物テンプレート単体が置けるか確認。
次に、ジグソーブロックのName・Target Name・Target Poolを確認。
最後に、worldgen側の構造物設定を見る。

この順番が安定です。

12. まとめ

以上、マイクラJava版のテンプレートプールについて解説しました。

テンプレートプールは、名前だけ見ると難しそうですが、実態はかなりシンプルです。

要点を整理すると、

  • テンプレートプールは、ジグソー構造物が使う生成候補リスト
  • elements に候補を並べ、weight で選ばれやすさを決める
  • fallback は、候補が使えない時や終端処理に使える
  • projection は、固定生成なら rigid、地形追従なら terrain_matching
  • 最初は minecraft:single_pool_element だけ覚えればOK
  • Java版1.21以降では structure など、単数形フォルダ名に注意
  • worldgen/structure 側の size は0〜7、ジグソーブロック画面の Levels は0〜20まで指定できる

このあたりを押さえれば、ジグソー構造物の仕組みはかなり見えやすくなります。

最初は、部屋1個と通路1個がつながるだけでも十分です。
そこから候補を増やして、重みを調整して、行き止まりパーツを作っていくと、自然生成っぽい構造物に近づいていきます。

マイクラのデータパック構造物は、慣れるまでは少し大変です。
ですが、テンプレートプールを理解すると、ランダム生成の面白さが一気に分かるようになります。

ぜひ小さなカスタム遺跡やミニダンジョンから試してみてください。

では、本日はここまでで終わります。
最後までご覧いただき、ありがとうございました。
柚子クラでは他にもマイクラJava版の仕様解説や便利な仕組みを紹介しているので、是非ご覧くださいね(^^♪

13. 引用・参考文献

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