chinese-novelist skill を読む：10〜50章の中国語長編をエージェントに書かせる仕組みと、その境界
🎭 AI 写小说：从零生成 10-50 章完整中文小说，三层问答 · 创作记忆 · 悬念钩子 · 自动校验，长篇网文连载皆宜｜开源免费，适配主流 coding agent｜AI novel writing skill
ひと目でわかる
- これは何？
- Claude Code などの coding agent に長編中国語小説を書かせる Skill。三層の問答で設定を固め、章ごとに字数を検査し、失敗すれば書き直す。設計の中心は「書き続けさせること」に置かれている。
- 誰に向いている？
- 導入を検討すべきなのは、Claude Code などの agent 環境をすでに使い、中国語の長編を最後まで書き切らせる工程そのものに関心がある人だ。逆に、完成原稿の文学的な質をそのまま求めたい人、あるいは単発の短編を一回で出したい人には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 10 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
この Skill が埋めようとしている穴は、生成能力ではなく持続力
README の冒頭は「写小说最难的是坚持写完」と述べ、この Skill の目的を長編の完走に置いている。つまり対象は、モデルが1章ぶんの文章を書けるかどうかではなく、20章、30章と続けたときに設定が崩れず、途中で止まらず、最後まで到達するかという問題である。想定読者は、coding agent をすでに日常的に使っていて、その作業ディレクトリの上で長い生成物を扱いたい人だ。プロンプトを毎回手で組み立てる代わりに、手順と検査をファイルとして固定し、agent に踏ませる。小説の書き方指導というより、長い生成タスクの進行管理に近い。
Phase 0 から Phase 4 までの流れと、その間に置かれた確認点
README のフロー図は Phase 0 の初期化から始まる。ここで user-preferences.json を読み込み、未完了のプロジェクトがあれば続写の候補として検出する。次が Phase 1 の三層問答で、Layer 1 は題材、主人公、核心の対立という3問の必須項目、Layer 2 は世界観、視点、テーマ、読者層、章数の5問で、こちらは任意である。各問にはランダム生成の選択肢があり、「跳过」「都用默认」と答えてもよいと README は書いている。Phase 2 で7列の章立て、人物档案、写作计划 JSON を生成して利用者に確認を求める。Phase 2.5 で執筆モードを選び、Phase 3 は確認なしの全自動で、各章を「写前分析 → 撰写(3000-5000字) → 润色去AI味 → 字数检查 → 更新摘要」の順に処理する。最後の Phase 4 で字数と連続性を検査し、不合格の章は最大3回まで書き直す。確認を求めるのは Phase 2 の一度だけで、以降は人が止めない限り走り切る設計になっている。
偏好記憶、中断続写、写作计划 JSON という3つの状態管理
v2.0 で追加された要素のうち、実務的に効くのは状態をファイルに逃がした点だ。user-preferences.json はプロジェクトをまたいで共有され、題材の傾向、語りのスタイル、章数の好み、文字密度といった項目を次回の問答に反映する。中断続写は Phase 0 で未完了プロジェクトを検出し、断点から再開する。そして 02-写作计划.json は機械可読の執筆計画で、README はこれを並列執筆の調整に使うと説明している。出力ディレクトリは 20260412-143000-午夜列车 のようなタイムスタンプ付きの名前で切られ、その中に 01-大纲.md、00-人物档案.md、第01章-最后一班列车.md が並ぶ。章の本文だけでなく、計画と人物設定が独立したファイルとして残るため、途中で agent のコンテキストが切れても、ファイルを読み直せば再開できる。長編生成の失敗は多くの場合、記憶ではなくコンテキストの消失で起きる。この構成はそこに手当てをしている。
導入は npx skills add の一行、設定はファイルとディレクトリ配置
README が示す導入手順は `npx skills add PenglongHuang/chinese-novelist-skill` の一行で、そのあと `使用 chinese-novelist 帮我写一部小说` と入力する。手動で入れる場合は `~/.claude/skills/chinese-novelist/` にディレクトリを置く。設定ファイルとして名前が挙がっているのは user-preferences.json と 02-写作计划.json の2つで、どちらも Skill が生成する側であり、利用者が最初に書くものではない。字数の検証は `scripts/check_chapter_wordcount.py` が担い、各章に設定された 3000〜5000 字の範囲を満たすかを確認する。パラメータを外から渡す形式なのか、章ファイルを引数に取るのかは README からは読み取れない。実際に使う前に scripts ディレクトリの中身を開いて確認する必要がある。
自動校验は品質保証ではなく、形式の検査である
Phase 4 の検査項目は字数と連続性の2つで、不合格なら最大3回書き直す。ここで注意したいのは、字数はスクリプトで機械的に判定できるが、連続性の判定はモデル自身の判断に委ねられている点だ。つまり「自動校验」という語が保証するのは、おおむね長さが足りていることと、モデルが自分で矛盾を感じなかったことまでである。設定の破綻、伏線の回収漏れ、人物の口調の揺れといった、長編で実際に痛い問題はこの検査をすり抜ける。3回書き直しても通らない章はどう扱われるのかについても、README には記述がない。加えて、3000〜5000字という下限は中国語のWeb小説の連載単位を前提とした数字であり、短編や掌編を書かせたい場合にはこの検査が邪魔になる。中篇の文学志向の作品や、1話2000字程度の構成を意図する場合、この Skill は明らかに過剰で、適合しない。
3つの執筆モードは、速度と安定のトレードオフを利用者に選ばせる
Phase 2.5 の表は、串行（主 Agent が逐章書く、默认推荐）、子Agent並行（複数の子 Agent が分担して並行に書く、速度重視）、Agent Teams（Claude Code のマルチ Agent 協働、大型長編向け）の3つを挙げる。既定が串行であること自体が、この設計者の判断を示している。並列にすれば速くなるが、章をまたぐ伏線や人物の口調の一貫性は、書き手が複数に分かれるほど崩れやすい。README が並列を「追求速度」の欄に置き、Agent Teams を「大型长篇」に限定しているのは、その崩れを織り込んだ書き方だ。ただし、並列時に 02-写作计划.json をどう排他制御するのか、子 Agent 間で同じ人物档案をどう共有するのかは README からは分からない。速度が欲しい場合でも、まず串行で1作品を通し、どこで破綻するかを自分の目で見てから並列に移るのが順当だろう。
同種のツールとの違いは、手順を references/ に外出ししていること
比較対象として素のプロンプト運用を置くと、違いは明確である。長編を書かせる指示を毎回チャットに貼る運用では、章立て、人物設定、禁止事項、字数の目安がすべて会話の中にあり、セッションが切れれば消える。この Skill は同じ内容を SKILL.md から references/flows/ 配下の7ファイル（phase0-initialization.md から shared-infrastructure.md まで）と references/guides/ 配下の8ファイル（chapter-guide.md、hook-techniques.md、character-building.md、dialogue-writing.md、plot-structures.md、content-expansion.md、outline-template.md、character-template.md、chapter-template.md）に分割して保持する。v2.0 の変更点として README 自身が「将详细执行指令从 SKILL.md 拆分到 references/flows/ 独立维护」と書いており、これは指示の再利用と改訂を会話から切り離す判断だ。一方で、素のプロンプト運用の利点は即応性と自由度にある。1章だけ書き直したい、構成を根本から変えたいという場面では、手順がファイルに固定されているぶん、この Skill のほうが回りくどい。長編を何本も量産する使い方と、単発で試す使い方では、向き不向きがはっきり分かれる。
維持コストと MIT ライセンスが意味する範囲
リポジトリは MIT ライセンスで公開され、バージョンは 2.0、最終 push は 2026-09-06、リリースは取得できていない。主要言語は Python で、Python が関与するのは字数検査スクリプトの部分であり、本体は agent に読ませる Markdown の指示群である。この構造は維持コストの見積もりを難しくする。コードの依存関係は薄いが、モデルの挙動が変われば references/ の指示文を書き直す必要があり、それは通常のライブラリ更新とは性質が異なる。利用者側の追従コストも同じで、Skill を更新したときに preferences や既存プロジェクトの JSON との互換が保たれるかは README からは判断できない。MIT である以上、生成された小説の扱いについてライセンスが定めるのは Skill 自体の利用条件までで、生成物の権利や各モデル提供者の規約は別に確認が要る。ここは法的助言ではなく、確認先の整理として書いておく。
編集部の結論
導入を検討すべきなのは、Claude Code などの agent 環境をすでに使い、中国語の長編を最後まで書き切らせる工程そのものに関心がある人だ。逆に、完成原稿の文学的な質をそのまま求めたい人、あるいは単発の短編を一回で出したい人には向かない。試す前に確認すべきは、references/flows/phase3-writing.md に書かれた3つの執筆モードのうちどれが自分の環境で動くか、そして scripts/check_chapter_wordcount.py が実際に呼ばれるかどうかである。字数の検査が働かない状態では、この Skill の売りである「自動校验」は名目だけになる。
コミュニティノート