NovelForge：JSON Schema でカードを縛る長編小説エンジン

長編で壊れるのは文章力ではなく設定の整合性である

NovelForge が解こうとしているのは、生成そのものではなく、数十万字を書いたあとに設定が食い違う問題である。README は長編創作の課題を「一貫性、可控性、持続的なインスピレーション」の 3 つに整理し、その対策としてカード、動的出力モデル、コンテキスト注入、知識グラフという 4 つの仕組みを挙げている。対象読者は、世界観ノートと登場人物表を別ファイルで管理し、章を進めるたびに過去の記述を検索しているような書き手だ。

汎用チャットで長編を書くと、直前の数章しか文脈に入らない。NovelForge は設定をカードという単位に分解し、必要なカードだけを明示的に参照させる。この発想自体は目新しくないが、参照の指定を @DSL という記法に寄せ、生成結果を JSON Schema で検証する点が、単なるプロンプト集との差になる。

カード、Schema、@DSL の三点でコンテキストを組み立てる

中心にあるのはカードだ。登場人物、関係、場景、組織、物品、概念といった種類ごとにカードがあり、それぞれに Schema を定義できる。README によれば、AI 生成はこの構造に沿って検証されるため、「見た目は使えるが配置が乱れる」出力が減る。生成は一括ではなく、入力要求、フィールド単位のストリーミング填充、確認またはフィードバックという順で進む。この流れは現在のカード 1 枚に閉じており、生成ダイアログを閉じるとセッションは終了する。

二つ目が @DSL によるコンテキスト注入である。プロジェクト内のデータを @ 記法で正確に参照し、関係グラフと動的情報を組み合わせる。v0.9.1 で関係グラフの保存先に SQLite が加わり、Neo4j も引き続き使える。つまりグラフは外部サービスなしでも動く。

三つ目が記憶層だ。v0.9.4 で角色の動的情報、関係の抽出、場景・組織・物品の状態、概念の掌握が、いずれも「現在の章本文から抽出 → プレビュー → 手動調整 → 確認して書き戻し」という同じ手順に統一された。抽出結果をそのまま信じて書き込むのではなく、人間が差分を見てから確定する設計になっている。

コード式ワークフローへの移行と、その代償

v0.9.0 でワークフローは旧 DAG エディタから、Python 風の文と専用マーカー DSL によるコード式へ移った。README は移行理由として、順序・待機（Logic.Wait）・非同期（async=true）の意味が実行過程に沿って読めること、実行器が文単位で計画を立てられること、同じ機能を DAG の数百行のノードと線ではなく数十行で書けることを挙げている。

同時に欠点も明記されている。DAG ほど直感的ではなく、文字列とコードの形式に敏感で、パラメータのシリアライズ、辞書フィールドの型、変数参照といった細部が検証エラーや実行エラーを招きやすい。ここは README が自ら認めている弱点であり、実際にワークフローを書くならこの感度を前提にすべきだ。

ワークフロー Agent は自然言語の記述からワークフローコードを生成・修正し、検証してから適用する。変更前にプレビューできる点は安全側の設計だが、README は「まだいくつかバグがあるかもしれない」と述べている。v0.9.5 では拆書ワークフローが既定の指令流モードに変わり、成功率が上がったと記録されている。コード式の扱いにくさを、テンプレート側で吸収しようとしている構図だ。

起動と設定：実際に触るファイルとキー

v0.9.2 で前後端の一括起動が追加された。README の運行指南セクションにはコマンド列は載っていないため、正確な起動手順はリポジトリの該当箇所を確認する必要がある。ここは当記事の材料からは断定できない。

確認できる設定項目は限られている。バックエンドのポートは backend/.env の APP_PORT で変更でき、既定値は 54321、1 から 65535 の範囲検証が入る（v0.9.7）。v0.8.2 では助手のツール呼び出しの最大リトライ回数を .env で設定できるとある。

LLM 側は v0.9.6 で設定ページから能力検出を実行できるようになった。基礎対話、ストリーミング、構造化出力、ツール呼び出しの互換状況を確認するためのもので、Schema 検証が効くかどうかはここで判断する。v0.8.5 は DeepSeek や Qwen のようなモデルは OpenAI 互換プロバイダとして登録し、OpenAI 側には GPT 5 などの公式モデルだけを置くよう勧めている。ツール呼び出しが弱いモデル向けには、テキスト形式のツール呼び出しを実装した ReAct モードが設定の霊感助手項目にある（既定は無効）。ただし README 自身が実装は粗くバグがあるかもしれないと書き、ネイティブのツール呼び出しが得意なモデルを優先するよう勧めている。

章本文の字数制御は二択であり、コストで選ぶ

v0.9.3 で章本文の続き書きの字数制御は二つのモードに収束した。提示詞約束はプロンプト側で字数を縛るだけで、文章は自然だが厳密ではない。制御モードは目標字数を複数ラウンドに分割して予算を配分し、安定する代わりにトークンを多く消費する。README は制御モードについて、現在は固定の複数ラウンド予算戦略を採ると説明している。

ここは好みの問題ではなく費用の問題として読むべきだ。長い章を何度も書き直すなら、自然な文章が得られる提示詞約束のほうが結果的に安くつくことがある。逆に、投稿規定で字数が厳密に決まっている場合は制御モードを選ぶしかない。どちらが優れているという話ではなく、どちらを犠牲にするかの選択である。

審核も v0.9.3 で再構成された。流れは「審核草稿を生成 → 確認して審核結果カードを作成または更新」で、結果は根レベルの審核結果フォルダに自動で归档される。カード種別ごとに審核プロンプトを切り替えられるが、結果カードの構造は共通なので参照しやすい。

v0.9.0 のデータベース非互換は他人事ではない

最大の落とし穴は更新履歴に明記されている。v0.9.0 は変更が大きいため旧版のデータベースがそのまま使えない可能性があり、配布された移行スクリプトを試すよう案内されている。ただし README は成功を保証しておらず、事前に db ファイルをバックアップするよう強く求めている。

これは「動くかもしれない」移行であり、保証された移行経路ではない。長編の設定カードと関係グラフが一つのデータベースに蓄積されているなら、移行の失敗は作業そのものの消失を意味する。導入を検討する段階で、まず自分の現行バージョンとデータ量で移行スクリプトを試せるかどうかを確かめるべきだ。

もう一つの制約はライセンスである。AGPL-3.0 はネットワーク越しに改変版を提供する場合にもソース開示を求める。個人が自分の小説を書く用途では通常問題にならないが、NovelForge を組み込んだサービスを社内や顧客向けに公開する場合は話が変わる。ここは法的助言ではないので、条件の解釈は各自で確認してほしい。

汎用チャットと Obsidian 系プラグインとの違い

比較対象として素直なのは、長文用のプロンプトを組んだ汎用チャットと、Obsidian などのノート環境に LLM を足す構成だ。前者は導入が最も軽いが、設定の実体がプロンプト文字列になり、章が進むほど参照が破綻しやすい。後者はノートという構造を持つが、生成結果をスキーマで検証する仕組みは持たない。

NovelForge の違いは、設定を Schema 付きのカードとして保存し、生成時にその構造で検証し、@DSL で参照範囲を明示するところにある。裏を返せば、Schema を書かずに使うと汎用チャットと大差なく、カードとワークフローの管理コストだけが残る。構造を自分で設計する意思があるかどうかが、この道具が化けるかどうかの分岐点になる。

維持コストの面では、v0.9.0 から v0.9.7 まで約 1 か月半で 8 回のリリースがあり、うち複数がデータモデルやワークフロー基盤に触れている。追従には相応の手間を見込むべきだ。

編集部の結論

長編の設定資料が散らかって困っている個人作家、とくに自分でプロンプトとスキーマを書き換えることを厭わない層には向いている。逆に、GUI だけで完結させたい人や、AGPL-3.0 のソース開示条件を飲めない商用プロダクトには向かない。導入前に確認すべきは 3 点で、第一に v0.9.0 のデータベース非互換を自分の環境で再現できるか、第二に LLM 設定ページの能力検出で使用モデルの構造化出力とツール呼び出しが通るか、第三に backend/.env の APP_PORT を 54321 以外に変えた状態でフロントが追従するかである。このうち構造化出力の検出が落ちた場合、Schema 検証という NovelForge の中心機能が成立しないため、他の 2 点を確認する意味はない。

公式情報源

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. RhythmicWave/NovelForge on GitHub