自作の Mod とプラグインの安全

対象は Java 版の Mod (Fabric、NeoForge) と、Paper のプラグインです。ツールの名前と内容は、2026 年 10 月 25 日時点の各プロジェクトのドキュメントによります。

テストしてから、本番に入れる

自作の Mod やプラグインは、本番のサーバーに直接入れません。企画の当日に不具合が見つかると、直す時間がなく、参加する方や視聴者の前でサーバーが止まります。

開発の環境: 自分の PC か、開発用のサーバーで作る
自動のテスト: 処理の単位で、決まった入力に決まった結果を返すかを確かめる
検証用のサーバー: 本番と同じバージョンのサーバー、プラグイン、Mod と、本番のワールドのコピーで動かす
負荷の確認: 企画と同じくらいの人数と操作で、ティックの時間 (MSPT) が延びないかを spark などで確かめる (ティックとスレッドの仕組み)
本番への反映: バックアップを取ってから入れ、問題があれば前のバージョンに戻せるようにしておく (バックアップの取り方)

自動のテストの仕組み

Paper のプラグイン: MockBukkit を使うと、サーバーを起動せずに、プラグインの処理を JUnit でテストできる
Fabric の Mod: JUnit でのテストと、Minecraft のゲームテストの仕組み (ワールドの中で、決まった構造物や動きを確かめる) の両方を使える
NeoForge の Mod: ゲームテストの仕組みで、ワールドの中の動きを確かめられる

クライアントから届くものを信頼しない

サーバーに届く情報は、すべてプレイヤーのクライアントから送られてきます。改造したクライアントは、普通の操作ではできない値も送れます。

権限はサーバーで確かめる: コマンドやボタンの操作のたびに、サーバー側で、その人に許可された操作かを確かめる。クライアントの画面でボタンを隠すだけでは防げない
独自の通信を検証する: Mod の独自のパケットや、プラグインのメッセージのチャンネルで受け取る値は、範囲、長さ、形式を確かめてから使う
回数を制限する: 重い処理を呼び出す操作は、1 人あたりの回数や間隔を制限する。連打されるとサーバーが止まる
ファイルの名前に使わない: プレイヤーが入力した文字を、そのままファイルの名前や場所に使わない。../ などで、ほかの場所のファイルを読み書きされる

Java で作るときの安全の決まり

信頼できないデータを、Java の仕組みで復元しない

Java の ObjectInputStream などで、外から受け取ったデータをオブジェクトに戻す処理 (デシリアライズ) は、データの作り方によって、任意のコードを実行されるおそれがあります。多くの Forge の Mod で外部からコードを実行される状態になった BleedingPipe も、通信で受け取ったデータを、この方法で読み込んでいたことが原因です (脆弱性の情報)。通信やファイルのデータは、JSON や Minecraft のデータの形式 (NBT) など、値だけを読む形式で受け取ります。

データベースは、プレースホルダーで扱う

プレイヤーの名前やチャットの文字を、SQL の文に直接つなげると、SQL インジェクションで、データベースを読み取られたり、消されたりします。PreparedStatement のプレースホルダーを使い、値と SQL の文を分けます (MySQL との連動)。

// 避ける: 入力をそのまま SQL の文につなげる
stmt.executeQuery("SELECT * FROM points WHERE name = '" + name + "'");

// 使う: プレースホルダーで、値を別に渡す
PreparedStatement ps = conn.prepareStatement("SELECT * FROM points WHERE name = ?");
ps.setString(1, name);

秘密の情報をコードに書かない

データベースのパスワード、Discord のボットのトークン、API のキーを、ソースコードや jar に書かない。jar は展開すれば中身を読めるため、配ると漏れる
設定ファイルに書き、Git の管理から外す (.gitignore)。サーバーの中のファイルの権限も、サーバーを動かすユーザーだけが読めるようにする
ログに、パスワードやトークン、参加する方の IP アドレスなどを出さない (ログの保管と分析)

依存するライブラリを管理する

使うライブラリは必要なものだけにし、バージョンを固定して、最新の修正に追従する。Log4Shell のように、ライブラリの脆弱性がそのまま Mod やプラグインの脆弱性になる
GitHub の Dependabot などで、依存するライブラリの脆弱性と更新を知らせてもらう
外部のコマンドの実行 (Runtime.exec など) や、プレイヤーの入力からのスクリプトの実行は使わない

メインのスレッドを止めない

ワールドの計算は、メインのスレッドで 1 秒に 20 回行われます。データベースへの問い合わせや外部との通信をメインのスレッドで行うと、その間、サーバー全体が止まります。重い処理は別のスレッドで行い、ワールドに触れる処理だけをメインのスレッドに戻します。Paper のドキュメントも、メインのスレッドの処理はサーバーの性能に影響すると説明しています (ティックとスレッドの仕組み)。

Minecraft の内部に頼りすぎない

Paper の API を使わず、Minecraft の内部のコードを直接呼び出すと、Minecraft のバージョンが上がるたびに動かなくなるおそれがあります。できるだけ公開された API を使い、内部を使う箇所は 1 か所にまとめておくと、更新のときに直す範囲が小さくなります (バックアップと更新)。

ソースコードの管理と見直し

ソースコードは Git で管理し、いつ、誰が、何を変えたかを残す。本番に入れたバージョンには、タグを付ける
本番に入れる前に、作った人以外がコードを見直す。生成 AI で作ったコードも、同じように見直す
ビルドは、決まった手順 (GitHub Actions など) で行い、個人の PC でビルドした jar を本番に入れない
GitHub や配布のアカウントに、2 段階認証を設定する。アカウントが乗っ取られると、マルウェアの入った更新を配られる

参加する方に配るとき

クライアントにも入れる自作の Mod は、参加する方の PC で動きます。配るときは、ほかの Mod と同じく、配布元を 1 つに決め、ファイルのハッシュを公開して、参加する方が確かめられるようにします (Mod とクライアントの安全)。

Mod パックに入れる場合も、検証用の環境で、ほかの Mod との組み合わせを確かめてから配る
参加する方の PC の情報 (ファイル、ほかのアカウントの情報) を読む処理を入れない。企画に必要な情報だけを扱う (参加者の個人情報の扱い)
不具合が見つかったときの告知方法と、修正したバージョンの配り方を決めておく

開発を委託するときに決めておくこと

ソースコードの受け渡し: 完成した jar だけでなく、ソースコードとビルドの手順も受け取る。ソースコードがないと、ほかの人が直せず、中身も確かめられない
権利とライセンス: ソースコードの権利の帰属と、使っているライブラリのライセンスを確かめる
更新の対応: Minecraft のバージョンが上がったときの対応と、脆弱性が見つかったときの修正を、誰がいつまでに行うか
テストの範囲: どの環境で、何を確かめてから納品するか

参考にした資料

自作の Mod とプラグインの開発は、KEY SELECT に

企画のための Mod とプラグインの開発、ソースコードの見直し、テストと検証用のサーバーの用意、本番への反映と更新の対応まで、KEY SELECT がお引き受けできます。

Mod とプラグインの開発のご相談 Minecraft サーバー運営

記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。