この村では何が起きている？
Foundry Virtual Tabletopは、D&D等の既存タイトルだけでなく、Game SystemとModuleを開発して挙動そのものを拡張できる。公式ドキュメントは、System開発にはJavaScript、HTML、CSSの基本知識が必要で、単純に見えるゲームでも想定以上に時間がかかると明記している。ModuleはActors、Items、Scenes、Journal、Roll Tablesなどのコンテンツ追加からUI変更、新機能まで扱う。コミュニティでは「自作ルールをFoundryへ移したいので誰か雇えるか」という相談が繰り返され、開発者Discordのcommission channelが案内されている。
なぜ、これだけで市場になるのか
Foundryの魅力である自由度が、そのまま導入障壁になるからだ。紙のルールをVTTへ持ち込むには、キャラクターデータモデル、アイテム、判定式、シートUI、チャットカード、コンペンディウム、権限、マイグレーションまで設計する必要がある。さらにModule同士の互換性やFoundry本体のバージョン更新もある。GMや同人TRPG作者はルールや世界観の専門家であって、継続保守するWebアプリ開発者とは限らない。そのため「自分のゲームを動くSystemにする」「既存ワールドを全部セットアップする」仕事に外注余地がある。
実際の仕事はこう進む
- 01
ルールと自動化範囲を決める
最初に、単にキャラクターシートがあればよいのか、判定・ダメージ・状態異常まで自動化するのか、Compendiumを持つのかを決める。完全自動化を目指すほど開発費と保守負担が急増する。
- 02
Actor・Itemのデータモデルを設計する
キャラクター、NPC、武器、技能などをFoundryのDocument構造へ落とし、保存形式と派生値を決める。ルール改訂を考えるとマイグレーション可能な形にしておく必要がある。
- 03
シートと判定ロジックを実装する
HTMLテンプレートやJavaScriptでActor Sheet、Item Sheet、ダイス判定、チャット表示などを作る。必要に応じてHooksやModule APIを使い、コアへ直接パッチしない構造にする。
- 04
実卓・更新環境で保守する
複数プレイヤー権限、サーバー環境、既存Moduleとの競合、Foundry本体の新バージョンで確認する。納品後もルール追加やFoundry更新に合わせた保守が発生しやすい。
どこに金が流れる？
この市場は定価商品よりコミッションとPatreon型が中心である。FoundryコミュニティではSystem/Module制作を依頼したい投稿に対し、League of Extraordinary FoundryVTT Developersのcommission channelが案内されている。2025年の環境構築依頼相談では、マップやトークン、Module設定まで含む完全なキャンペーン構築なら初期1,000〜2,000ドル、継続セッションごと200〜300ドル程度と見積もる回答もある。さらに有料ModuleをPatreonで提供する文化も存在し、単なる趣味コード以上の経済圏がある。
外から見ると見落とすこと
SystemとModuleを混同すると設計を誤る。ゲームのActor/Itemや根本ルールを提供するのがSystemで、その上へ機能を足すのがModuleである。既存Systemへ小機能を足したいだけならModuleにした方が保守しやすい。公式ドキュメントも『思ったより時間がかかる』と警告しており、Systemを丸ごと作る依頼は小さなWebアプリ開発に近い。またFoundryのバージョン更新が速いため、単発納品より保守契約の方が実務上重要になる。
AI・コードでどこまで削れる？
AIコーディングはSystem雛形、Document schema、Handlebarsテンプレート、チャットカード、マイグレーションの下書きを高速化できる。ただしルールブックの文章からデータモデルを決める部分は設計判断が必要で、コード生成だけでは解決しない。狙い目は「ルールPDFから必要なActor/Itemフィールドと判定式を抽出し、最小動作Systemを生成する」工程である。さらにFoundryのバージョンごとのAPI差分を静的解析し、更新で壊れそうな箇所を警告する保守ツールにも需要がある。
外からこの村に入るなら
- 自作TRPG作者向けに、ルールPDFと紙のキャラシから最小のFoundry Game Systemを作る固定スコープ商品。まず手入力＋ダイス判定だけに絞り、高度自動化は追加料金にする。
- 既存Systemの更新で壊れた自作Moduleを対象に、manifest、Hook、非推奨API、Documentアクセスを検査して新Foundry版へ移行するメンテナンスサービス。
- GM向けにSystem開発ではなく、導入済みModule、シーン、コンペンディウム、ランディングページを一式整える『Foundryワールド構築代行』へ寄せる。
この市場を雑に扱うと危ない点
- System開発はルール変更とFoundry本体更新の二重保守になる。納品時点で対応Foundryバージョンと保守期間を必ず固定する。
- 市販TRPGのルール本文、画像、コンペンディウムデータを無許諾で実装・配布すると権利問題になる。自作ルールか適切なライセンス範囲に限定する。
- 何でも自動化すると開発費が膨らむ。まず実卓に必要な最小機能を決め、Moduleで済む要求をSystemへ入れない。
この市場があると判断した根拠
最終確認: 2026-09-25
Game Systemをゼロから作る公式ガイドで、JavaScript・HTML・CSSが必要で開発が想定以上に長くなることを明示している。
元資料を見る ↗ 02 Foundry VTT公式: Introduction to Module DevelopmentModuleがコンテンツ、UI、機能、翻訳などを追加できる公式拡張単位であり、Systemとの役割分担を確認できる。
元資料を見る ↗ 03 Reddit r/FoundryVTT: New systems/devSystemやModuleを有償依頼できる場所として開発者コミュニティのcommission channelが案内されている需要側の証拠。
元資料を見る ↗