cultivation-world-simulator を採用前に読む: 全NPCをLLMエージェントで動かす修仙世界の設計と制約
基于 AI Agent 工作流的修仙世界模拟器，旨在还原智能、开放的仙侠世界。| An open-source Cultivation World Simulator using Agentic Workflow to create a dynamic, emerging Xianxia world.
ひと目でわかる
- これは何？
- 修仙世界を「天道」視点で眺めるシミュレータ。全NPCを個別のLLMエージェントとして動かし、規則体系でその発散を抑える設計になっている。Epic Games Store版、Docker、ソースコードの3経路があり、外部Agent接続用のHTTP APIも用意されている。
- 誰に向いている？
- 自分でモデルを差し替えたり、プロンプトや世界規則を書き換えたりしたい開発者には向いている。逆に、モデルAPIの費用やレイテンシを気にせず「完成したゲーム」を遊びたいだけなら、ソースからの導入ではなくEpic Games Store版を選ぶべきだ。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 31 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
「天道」として眺めるシミュレータが解こうとしている問題
一般的な修仙もののゲームでは、プレイヤーは一人の修士として修行し、敵と戦い、宗門に所属する。cultivation-world-simulator の立ち位置はそこからずれている。README の冒頭には「你将作为“天道”，观察一个由规则系统与 AI 共同驱动的修仙世界模拟器自行演化」と書かれている。操作対象は修士ではなく、世界そのものだ。
想定されている利用者は二種類いる。ひとつは、NPC 同士が勝手に因縁を作り、宗門が興亡していく過程を観察したい遊び手。もうひとつは、LLM エージェントの群像シミュレーションを題材にしたい開発者だ。README は「全员 LLM 驱动、群像涌现叙事」という表現でこの二つを同時に狙っている。
問題設定として興味深いのは、LLM に自由を与えるほど世界が破綻するという点への対処である。README は「为了避免AI的幻觉与过度发散，编入了复杂灵活的修仙世界观与运行规则」と説明しており、霊根、境界、功法、性格、宗門、丹薬、兵器、武道会、 auction、寿元といった要素を規則体系として用意することで、AI の出力を修仙ものとして筋の通る範囲に留めようとしている。自由度の設計ではなく、自由度の上限設計が主題になっている。
NPCごとに独立したエージェントを置くという構成
README によれば、シミュレータ内の修士はそれぞれが独立した Agent であり、環境を観測して自律的に意思決定する。加えて「都有独立的性格、记忆、人际关系和行为逻辑」とあり、性格、記憶、人間関係、行動ロジックが NPC 単位で保持される。
ここで確認できるのはデータモデルの粒度であって、推論の実行単位ではない。たとえば100人の修士が存在するとき、各ターンで100回の LLM 呼び出しが発生するのか、重要度に応じて間引かれるのかは、README からは読み取れない。この点は採用判断に直結する。呼び出し回数がNPC数に比例するなら、モデルの従量課金とレイテンシがそのままシミュレーション速度の上限になる。ドキュメントが薄い部分であり、ソースを読むか小規模な世界で試すまで確定できない。
一方で、規則体系と AI の役割分担は比較的はっきりしている。規則側が霊根や境界といった世界の骨格を決め、AI 側がその枠内で判断を下す。README の「AI 的想象力被限制在合理又足够丰富的修仙逻辑框架内」という記述はこの分担を指している。逆に言えば、規則に穴があれば AI はそこから逸脱する。プロンプトだけでは足りず、世界規則の側を直す必要が出てくる種類の設計だ。
ソースから動かす場合の手順と設定の保存先
README が開発者向けとして推奨しているのはソースデプロイで、Python 3.10+、Node.js 18+、そして利用可能なモデルサービスが必要になる。手順は3ステップで示されている。
pip install -r requirements.txt でバックエンド依存を入れ、cd web && npm install && cd .. でフロントエンド依存を入れ、python src/server/main.py --dev で起動する。この起動コマンドは前後端をまとめて立ち上げる。開発モードではフロントエンドの開発サーバーが自動で開き、開かない場合は起動ログに表示されたアドレス（通常は http://localhost:5173）にアクセスする。
モデルはフロントエンドの設定ページでプリセットを選ぶ。README が名前を挙げているのは DeepSeek、MiniMax、Ollama の3つで、設定はユーザーデータディレクトリに自動保存されるとある。API キーを設定ファイルに手書きするのではなく、画面から入れる導線になっている点は、配布物としての扱いやすさに関わる。
Docker 経路も用意されている。git clone のあと docker-compose up -d --build を実行し、http://localhost:8123 にアクセスする。バックエンドコンテナは CWS_DATA_DIR=/data でユーザーデータを永続化し、設定、キー、セーブ、ログをまとめて保持する。ホスト側の ./docker-data にマップされ、docker compose down のあとに up し直してもデータは残る。ただし README はこの経路の見出しに「未テスト」と明記している。著者自身が動作確認していないと書いている以上、業務利用の前提でこれを第一候補にするのは避けたほうがよい。
外部Agentから観測と介入を行うためのAPI名前空間
README には、外部の agent や自動化スクリプトから「観測 -> 決定 -> 介入 -> 再観測」のループを回すための API が記載されている。方針として、安定した名前空間に直接ぶつかる形が推奨されている。読み取り専用が /api/v1/query/*、制御された書き込みが /api/v1/command/* だ。
起点として挙げられているのは次のものである。GET /api/v1/query/runtime/status、GET /api/v1/query/world/state、GET /api/v1/query/events、GET /api/v1/query/detail?type=avatar|region|sect&id=<target_id>、POST /api/v1/command/game/start、POST /api/v1/command/avatar/*、POST /api/v1/command/world/*。
最小の接入フローも README に書かれている。まず runtime/status で現在の実行状態を判定し、まだ開始していなければ game/start で初期化し、そのうえで world/state や events を読む、という順序だ。query と command がパスレベルで分離されているため、監視用のツールに読み取り権限だけを与え、介入は別のプロセスに任せる、という切り分けがしやすい。
注意すべきは、これがゲーム内部の HTTP インターフェースであって、汎用のエージェントフレームワークではないことだ。README が示しているのはあくまで接入の入口であり、たとえばイベントの購読方式やレート制限、認証の要否については記述がない。自動化を前提にするなら、このあたりは自分で確認する必要がある。
向いていないケースと、確認できないまま残る部分
最初に挙げるべき制約はライセンスだ。リポジトリのライセンスは NOASSERTION と表示されており、GitHub が標準的なOSSライセンスとして認識していない状態にある。README にもライセンス条項の説明は見当たらない。二次創作や再配布、商用利用を視野に入れるなら、コードを読む前にリポジトリ内のライセンスファイルを確認すべきで、これは法務判断ではなく事実確認の話である。
次に、モデル依存の重さがある。全NPCがLLM駆動である以上、外部のモデルサービスが止まれば世界も止まる。Ollama を使えばローカルで完結するが、その場合はマシンの推論能力がそのまま世界の規模を決める。DeepSeek や MiniMax を使う場合は、API の利用量がそのまま運用コストになる。README には費用や速度の目安は一切書かれていない。
もう一点、README は Docker 経路を「未テスト」と明記しており、モバイルUIについても「暂未完全适配，仅供尝鲜」と書いている。つまり配布チャネルとして整備されているのは Epic Games Store のデスクトップ版で、ソースと Docker はあくまで開発者向けの経路という位置づけになる。
「完成したゲームを遊びたい」という用途には、このリポジトリは遠回りだ。モデル設定、依存関係、場合によってはプロンプトの調整まで自分で面倒を見る前提がある。逆に、シミュレーションの内部に手を入れるつもりがないなら、ソースを選ぶ理由は薄い。
代替となるアプローチとの違い
比較対象として分かりやすいのは、LLM を使わずルールベースのスクリプトでNPCの行動を記述する古典的なシミュレータだ。こちらの場合、NPCの行動は事前に書いた条件分岐の範囲に収まる。同じ状況で同じ判断が返るため、再現性があり、実行コストも一定で、テストも書ける。
cultivation-world-simulator はこの逆を行く。README が「开发者也不知道下一秒会发生什么。没有预设剧本」と書いているとおり、行動は事前定義ではなくその場の推論で決まる。得られるのは予測不能な物語だが、失うのは再現性と実行コストの見通しだ。同じ初期条件から同じ展開が再現するかどうかは、README からは判断できない。
もうひとつの比較軸は、汎用のエージェントフレームワークとの違いである。汎用フレームワークはエージェントの連携やツール呼び出しの仕組みを提供するが、世界の規則は自分で用意する必要がある。このプロジェクトは逆に、修仙ものの規則体系を最初から同梱し、その上でエージェントを動かす。だから世界観を差し替えるのは容易ではないが、逆に修仙という題材に限れば、規則とエージェントの接続を自分で設計し直さずに済む。
どちらが優れているという話ではない。世界の規則を自分で設計したいのか、規則済みの世界にエージェントを流し込みたいのか、その違いが選択を分ける。
導入前に確認しておくべきこと
最初に決めるのはモデルだ。README が名前を挙げている DeepSeek、MiniMax、Ollama のうち、どれを設定ページで選ぶかによって、コスト構造と世界の規模が変わる。ローカル推論で完結させたいなら Ollama、速度と品質を外部に委ねるなら DeepSeek か MiniMax、という区分けになる。
次に確認するのはライセンスファイルそのものだ。NOASSERTION という表示は、ライセンスが存在しないという意味でも、自由に使えるという意味でもない。単に GitHub が既知のテンプレートとして判定できなかったというだけである。二次創作や再配布を予定しているなら、ここを飛ばして作業を始めるのは避けたい。
三つ目は、自分の用途が観察なのか介入なのかをはっきりさせることだ。眺めるだけなら Epic Games Store 版で足りる。API 経由で自動化したいならソースデプロイが必要になる。README の Docker 経路には「未テスト」と書かれているので、Docker を前提にする場合は、まず自分の環境で docker-compose up -d --build を実行し、http://localhost:8123 に到達できるかを確認してから、./docker-data にデータが残る挙動を確かめる順序になる。
なお、README には tools/wiki でローカルの補助 wiki を生成できるという記述がある。世界情報、アクション、宗門などの資料を手元で引きながらコードを読むほうが、ソースの見通しは良くなるはずだ。
編集部の結論
自分でモデルを差し替えたり、プロンプトや世界規則を書き換えたりしたい開発者には向いている。逆に、モデルAPIの費用やレイテンシを気にせず「完成したゲーム」を遊びたいだけなら、ソースからの導入ではなくEpic Games Store版を選ぶべきだ。導入前に確認すべき点は3つある。リポジトリのライセンスがNOASSERTION表記であり、GitHub上では標準的なOSSライセンスとして認識されていないこと。README自身がDocker経路を「未テスト」と明記していること。そして設定ページで指定するモデルプリセット（DeepSeek / MiniMax / Ollama）のどれを自分の環境で使うか、費用と速度の両面から先に決めておくこと。
コミュニティノート