この村では何が起きている？
RPGツクールMZはノーコード寄りにゲームを作れる一方、標準イベントでは表現しづらい仕様にぶつかるとJavaScriptプラグインが必要になる。そこで生まれるのが「戦闘の敗北条件だけ変えたい」「特定UIだけ挙動を変えたい」といった一点物の開発依頼だ。依頼者はゲームを作る能力を持っていてもJavaScriptを読めないことがあり、数十行から数百行のコードがプロジェクト全体のボトルネックになる。この非対称性が、非常に狭いが明確な受託市場を作っている。
なぜ、これだけで市場になるのか
ツクールの強みは大部分をGUIで作れることだが、その強みが境界部分では弱点になる。作者はシナリオ、マップ、画像、イベントを自分で用意できるため、フルスクラッチ開発会社へ頼むほどではない。しかし標準機能にない一挙動のためにJavaScriptを学ぶと、数時間から数日の寄り道になる。既存プラグインも多いが、ゲーム固有の条件や他プラグインとの競合までは解決しない。この「ゲームはほぼ完成しているのに最後の5%だけコードが必要」という局面が、小口の専門依頼を生む。
実際の仕事はこう進む
- 01
欲しい挙動を言語化する
依頼者から現在の挙動、期待する挙動、発生条件、使用中プラグインを聞く。単に『できない』ではなく、どのSceneやGameオブジェクトの責務に触れる変更かを切り分ける。
- 02
既存実装と競合点を調べる
ツクール本体のクラス、イベント処理、プラグインコマンド、すでに導入されている他プラグインを確認する。小さな変更でもフック位置を間違えるとセーブデータや戦闘進行へ影響する。
- 03
最小のプラグインとして実装する
既存メソッドを必要最小限だけ拡張し、設定値が必要ならプラグインパラメータとして外へ出す。依頼者がコードを読めなくても設定できる形にすることが納品品質になる。
- 04
依頼者のプロジェクト条件で確認する
新規プロジェクトだけで動いても不十分で、実際に使っているプラグイン順序や戦闘システムで再現確認する。READMEや導入位置まで含めて初めて『使える納品物』になる。
どこに金が流れる？
有料市場は、固定商品として『MV/MZプラグイン制作を相談できます』と出品する形と、公開依頼に開発者が応募する形の両方がある。ココナラではプラグイン制作サービスに100件を超える販売実績がある例があり、別の一点物依頼では31人が応募している。つまり大規模な受託市場ではないが、作者が継続的に『最後の仕様』を外注するだけの厚みはある。
外から見ると見落とすこと
この市場で重要なのはJavaScriptが書けることより、ツクールの拡張作法を壊さないことだ。コアを書き換えれば一瞬で実現できても、アップデートや他プラグインとの競合で破綻する。依頼者はゲーム制作中なので、再現用の最小プロジェクトを作らず本番データだけ渡してくることもある。仕様の曖昧さを整理し、再利用できる設定項目とゲーム固有ロジックを分ける能力が職人性になる。
AI・コードでどこまで削れる？
AIコーディングとの相性は非常に良い。依頼文、対象バージョン、既存プラグイン一覧、期待する挙動を入力にして、対象クラス候補、フック箇所、プラグイン雛形、導入手順まで生成できる。人間側は再現確認と競合テストに集中する。単純な一点物なら従来1〜3時間かかっていた作業を大幅に短縮できる可能性がある。ただし、AIが本体APIを取り違えたりMVとMZを混同したりするため、実機確認を省くモデルは危険である。
外からこの村に入るなら
- 『欲しい挙動を日本語で書く→再現条件を質問→MZ用プラグインと導入説明を返す』ところまでを定型商品化し、小規模依頼だけを高速回転させる。
- 既存プラグイン同士の競合調査に特化し、エラー内容・導入順・プラグイン一覧から疑わしい上書き箇所を診断するサービスにする。
- よくある一点物依頼を匿名化して汎用プラグインへ昇格させ、受託で得た知見をBOOTH等のデータ商品へ変換する二段構えにする。
この市場を雑に扱うと危ない点
- MVとMZではAPIやプラグインコマンドの仕組みが異なる。対象バージョンを明記し、動作確認環境を固定する。
- 有料・無料を問わず既存プラグインのコードや仕様を無断で再配布しない。競合対応時もライセンス確認が必要。
- ゲーム本体のデータを預かる場合、未公開作品の素材やシナリオを含む可能性があるため、保管・削除方針を明確にする。
この市場があると判断した根拠
最終確認: 2026-09-25