本記事には広告が含まれています
自宅のミニPCやNASにDockerでマイクラサーバーを建てて友達と入れるところまでは動いたのに、compose.ymlのどこを直せばいいのか、jarをどこに置けばサーバーが読むのかが分からず止まっています。
私も同じところで止まりましたが、やったことはcompose.ymlの数行を書き換えてmodsフォルダをPC側に出しただけで、建て直しは不要でした。
この記事では、ローダーを決める→Modrinthで対応表示を読む→その値でcompose.ymlを書き換える→jarを置いて起動ログで確かめる、の順に書きます。
前の章で決めた値を次の章がそのまま使うので、上から順にやれば1つ目のModが入ります。
バニラは動いた、でもModの入れ方が分からない
この記事の出発点：バニラが動いていること（まだの人は先にバニラ構築へ）
前提は、docker compose up -dでバニラのサーバーが起動し、友達がIPとポートで入れている状態です。
その状態から書き換える手順として書いているので、まだサーバーが動いていないなら先にバニラで一度起動させてください。
Mod化で詰まったときに、原因がModなのか元の設定なのかを切り分けられなくなるからです。
建て直しではなく、compose.ymlの数行の差分で済む
Mod化と聞いてサーバーの作り直しを想像していましたが、実際に触ったのは3か所でした。
TYPEをローダー名に変える、VERSIONをMod対応のMCバージョンに合わせる、mods配下をホストのフォルダに出すマウントを足す、の3つです。
ワールドのデータもそのまま引き継げますが、バニラのワールドにMod用のブロックが後から足されるので、書き換える前にワールドのフォルダをコピーしておきました。
ワールドフォルダのバックアップは、compose.ymlを書き換える前に取ってください。Mod入りで一度起動すると、そのワールドをバニラに戻したとき壊れることがあります。
書き換えの第一行を決める：FabricとForgeのどちらで始めるか
軽さと新バージョン対応ならFabric、古い大型Modが目当てならForge
TYPEに書く値はFABRICかFORGEのどちらかで、ここが決まらないと後の全部が決まりません。
Fabricは本体が軽くて新しいMCバージョンへの対応が早いので、最新の1.21系で遊んでいた私はFabricを選びました。
Forgeは歴史が長く大型Modや少し前のバージョン向けのModが揃っているので、目当てのModがForge専用なら迷わずForgeです。
つまり「どちらが優れているか」ではなく、入れたいModがどちらに対応しているかで決まります。
この後Modrinthで確認するので、ここでは仮決めで構いません。
ローダーは後からの変更が効きません。FabricのModはForgeのサーバーでは読まれず、その逆も同じです。入れたいModの対応を見てから確定させてください。
Modrinth（Mod配布サイト）で入れたいModを探す
Modページで必ず見る3つの表示：対応MCバージョン・対応ローダー・対応環境
Modrinthで入れたいModの名前を検索し、そのModのページを開きます。
見るのはダウンロードボタンではなく右側と上部の表示で、対応MCバージョン（1.21.1など）、対応ローダー（Fabric/Forge）、対応環境（Client/Server）の3つを控えます。
対応MCバージョンは複数並んでいることが多いので、その中から1つ選びます。
私は最新版ではなく、Modの対応が揃っている少し前のバージョンを選びました。
ここで控えた「ローダー名」と「MCバージョン」が、次の章でcompose.ymlに書く値そのものです。
Dependencies欄に書かれた前提Modも一緒にダウンロードする
Modページの下部にあるDependencies欄に書かれているのは、そのModが動くために必要な別のModです。
Fabricの場合は多くのModがFabric APIを要求するので、これを入れ忘れると後で起動ログにクラッシュが出ます。
Requiredと書かれたものは必ず入れ、Optionalは無くても動きます。
私はRequiredのぶんだけ、同じMCバージョン・同じローダーのファイルをダウンロードしました。
前提Modも、本体と同じMCバージョン・同じローダーのファイルを選んでください。バージョン違いのjarを混ぜると、そのModだけ読まれずに落ちます。
compose.ymlを書き換える：TYPE・VERSION・ローダー版
TYPEにローダー名、VERSIONにModページで読んだMCバージョンを書く
環境変数のTYPEをFABRIC（ForgeならFORGE）に、VERSIONをModページで控えたMCバージョンに書き換えます。
services:
mc:
image: itzg/minecraft-server
environment:
EULA: "TRUE"
TYPE: "FABRIC"
VERSION: "1.21.1"
MEMORY: "4G"
ports:
- "25565:25565"
ローダー本体のバージョンを書いていないのは、指定しなければそのMCバージョンに対応する最新のローダーが自動で入るためです。
mods配下をホストに出すマウント（コンテナの中の場所をPC側のフォルダと繋ぐ設定）を足す
ここが私の最初に分からなかった部分で、jarの置き場所はコンテナの中にあるので、そのままではPC側から触れません。
volumesに1行足して、コンテナ内の/data/modsをPC側のフォルダと繋ぎます。
volumes:
- ./data:/data
- ./mods:/data/mods
これで、PC側のmodsフォルダに置いたjarが、そのままサーバーのmods配下として見えます。
Mod入りはバニラよりメモリを食うので、MEMORYも同時に見直しました。
Fabricで軽量Modを数個なら4GBで足りますが、大型Modや人数が増えるなら6〜8GBは欲しい計算です。
ミニPCが8GB1枚のままだとOSとDockerの常駐分を引いて残りが心もとないので、私は32GB（16GB×2枚）に載せ替えました。
- メモリ
- 32GB（16GB×2枚）
- 規格
- DDR4 SDRAM
- 形状
- SO-DIMM 260pin
- 動作クロック
- PC4-19200（DDR4-2400）
- 電圧・CL
- 1.2V / CL17
店舗の商品説明から拾った標準構成です。構成は変わることがあるので、購入前に販売ページで確かめてください。
WINTEN ノートPC用 メモリ DDR4 2400
32,750円（2026-08-22 時点）
ミニPC自体をこれから用意するなら、最初からメモリ32GBの構成を選ぶ手もあります。
- メモリ
- 32GB DDR5-4800（SO-DIMM×2、最大64GB）
- SSD
- 1TB（M.2 2280×2で最大16TB）
- CPU
- AMD Ryzen 7 PRO 6850U（8コア16スレッド、最大4.7GHz）
- 有線LAN
- 2.5G LAN×2
- OS
- Windows 11 Pro（Linux/Ubuntu対応）
店舗の商品説明から拾った標準構成です。構成は変わることがあるので、購入前に販売ページで確かめてください。
GMKtec M7 ultra ミニPC
129,998円（2026-08-22 時点）
- メモリ
- 32GB DDR5-5600（16GB×2、最大128GB）
- SSD
- 1TB M.2 2280（最大16TB増設可能）
- CPU
- AMD Ryzen 7 8845HS（Zen4、8コア16スレッド）
- 有線LAN
- 2.5Gb LAN×2
- OS
- Windows 11 Pro
店舗の商品説明から拾った標準構成です。構成は変わることがあるので、購入前に販売ページで確かめてください。
GMKtec K8plusミニPC AMD Ryzen7
159,998円（2026-08-22 時点）
Modのjarをmodsに置いて起動ログで確かめる
出てきたmodsフォルダにjarを入れ、コンテナを作り直して反映させる
書き換えたらまず一度起動すると、ここでPC側にmodsフォルダが自動で作られます。
docker compose up -d
作られたmodsフォルダに、ダウンロードしたjarを本体と前提Modごと入れます。
zipのまま入れず、jarのまま置いてください。
置いたら作り直しますが、restartでは環境変数の変更が反映されないので、up -dで作り直すのが確実でした。
docker compose down
docker compose up -d
起動ログでModが読まれたか確認する：黙って起動してModだけ落ちることがある
一番はまりやすいのがここで、サーバーは正常に起動してログイン画面も出るのに、Modだけ読まれていないことがあります。
ログを流して確認します。
docker compose logs -f mc
見るのは2か所で、Loading N modsのような読み込み数の行と、ERRORやincompatibleを含む行です。
読み込み数が入れたjarの数（本体＋前提Mod）と合っていれば成功です。
合わない、あるいはバージョン不一致のエラーが出ていれば、Modrinthで選んだファイルのMCバージョンがVERSIONとずれています。
「サーバーが起動した」はModが読まれた証拠になりません。起動成功とMod読み込み成功は別なので、必ずログの読み込み数を見てください。
サーバー側だけでよいModと、友達のクライアントにも要るMod
対応環境の表示で見分ける：Server側だけか、Client必須か
Modrinthで控えた3つ目の表示である対応環境が、ここで効きます。
Server: required / Client: unsupportedならサーバーに入れるだけで完結するので、友達は何もしなくてもこれまで通り入れます。
Client: requiredなら友達も同じModを自分のマイクラに入れる必要があり、入れずに接続すると弾かれるか表示が壊れます。
私は最初にこの表示を見ずに入れて、「サーバーは動くのに友達が入れない」をやりました。
友達に配るときに揃えるもの：ローダー・MCバージョン・Modの版
クライアント必須のModなら、友達に3つを揃えてもらいます。
ローダー（Fabric/Forge）、MCバージョン、Modのファイルの版の3つを、サーバーと完全に一致させます。
友達側の手順は、まずランチャーにローダー入りのプロファイルを作り、そのプロファイルのmodsフォルダにサーバーと同じjarを入れる、という流れです。
私はダウンロードしたjarをそのままzipにまとめて共有しましたが、各自でModrinthから拾ってもらうと版がずれて接続できなくなるためです。
サーバーとクライアントで版がずれると、接続時に不一致を示すメッセージが出ます。文言にModの名前が出るので、どのjarを揃え直せばいいかはそこで分かります。
まとめ：バニラのcompose.ymlからMod入りサーバーへ
- 出発点は、
docker compose up -dでバニラが起動して友達が入れている状態にしておくこと - 書き換える前に、ワールドのフォルダをコピーしてバックアップを取っておくこと
TYPEに書くのはFABRICかFORGEで、入れたいModがどちらに対応しているかで決めること- Modrinthのページでは、対応MCバージョン・対応ローダー・対応環境の3つを控えること
Dependencies欄のRequiredな前提Modも、同じMCバージョン・同じローダーでダウンロードすることTYPEをローダー名に、VERSIONを控えたMCバージョンに書き換えること- ローダー本体のバージョンは指定せず、自動で入る最新に任せること
volumesに1行足して、コンテナ内の/data/modsをPC側のフォルダと繋ぐこと- Mod入りはメモリを食うので、
MEMORYを4GB、大型Modや人数増なら6〜8GBで見直すこと - jarを置いたら
restartではなくdownとup -dで作り直すこと - 起動ログの
Loading N modsの数が、入れたjarの数と合っているか確認すること Client: requiredのModなら、友達にもローダー・MCバージョン・Modの版を揃えてもらうこと
