1ページのあらすじを10章のAI原稿に変えるには？
2026-08-10
1ページの前提を読みやすい散文による10章へ膨らませる作業は、執筆の問題というより記憶の問題です。下書きそのものは簡単です。現代の言語モデルなら、きちんとしたシーン描写を3,000語、1分足らずで生成できます。破綻するのは、原稿が記憶しているべきあらゆる要素です。左頬の傷、エレナという姉妹、8章で落としたナイフ。本ガイドでは、10章の原稿で内部整合性を保つための拡張・検証ワークフローを分解し、各段階に適したツールを比較します。
あらすじから原稿へ進むAIワークフローの3層とは？
1ページのあらすじは、拡張、生成、検証という3つの異なる層を経て10章の原稿になります。そして整合性の破綻は、ほぼ例外なく第1層または第3層を省略したことに起因します。拡張層では、あらすじを構造化されたストーリーバイブルと章ごとのビートシートへ変換します。生成層では、そのビートに沿って各章を下書きします。検証層では、次の章へ進む前に、完成した各章をバイブルと照合して監査します。
「AIは6章までに筋を見失う」と不満を言う書き手の多くは、中間の層しか実行していません。あらすじを貼り付けて1章、次に2章を依頼し、モデルのコンテキストウィンドウに記憶を任せています。しかし、数章を超えた内容をモデルが安定して記憶し続けることはできません。
実用的なAI執筆スタックと、苛立たしいスタックを分ける要素は次のとおりです。
✅ チャットの外部に存在する、書面化されたストーリーバイブル — 登場人物、場所、時系列、物品を、散文から推測させるのではなく、検索・参照できる事実として記録する ✅ 散文の前に章レベルのビートを用意すること — 1文を生成する前に、各章の目標語数、POV、開始状態、終了状態を決める ✅ 最後だけでなく各章の後に行う整合性チェック — 誤りは累積し、3章で生じた矛盾は4章から10章までの内容を形作ってしまう ✅ 執筆と監査の分離 — 章を書いたモデルは、その章が1章と矛盾していないかを判断するのに適した審査役ではない ✅ コンテキストウィンドウの認識 — ツールの作業記憶は約6,000語から約150,000語まで幅があり、その範囲が、そもそも可能な整合性チェックの種類を決定します（Inkfluence AIツール比較）
各層のツールを賢く選ぶには、まず「整合性」が実際に何を含むかを理解する必要があります。なぜならこれは、ほとんどの執筆ツールがうたうよりはるかに広い概念だからです。
AI原稿では、実際にどのような整合性エラーが起きるのか？
整合性チェックは校正ではありません。9章の細部が、2章で確立した内容となお一致しているかを追跡する作業です。この領域には少なくとも7種類の異なるエラーがあり、それぞれAIの検出率も異なります。
整合性エラーの分類に関する文書化された内訳に基づくと、AIがどれだけ確実に発見できるかという観点で、失敗パターンは次のように並びます。
| エラーの種類 | 具体例 | AIによる検出信頼性 |
|---|---|---|
| 名前の不一致 | 物語内の理由なく「Katherine」が「Catherine」や「Kate」になる | 容易に検出可能 |
| 人物描写のずれ | 章ごとに目の色、身長、傷、タトゥーが変わる | 全文がコンテキスト内にあれば良好に対応 |
| 死亡・退場人物の再登場 | 8章で退場した人物が説明なく戻ってくる | 原稿全体がコンテキスト内にあれば検出可能 |
| 時系列の矛盾 | 確立済みの日付に対して「彼女が彼に会ったのは3週間前」などと記される | 明示的な矛盾は検出可能。曖昧なものは見落とす |
| 設定の誤り | 部屋の配置が変わる、建物の場所が移る、地理がぶれる | 検出率は中程度 |
| 物品追跡の失敗 | 8章で落とした品物を12章で使用する | 長い原稿全体では追跡が難しい |
| 関係性の連続性 | 疎遠な人物同士が親密な間柄のように振る舞う | 暗黙的な状態変化にAIは苦戦する |
パターンは明白です。AIは明示され、記述された事実には強く、暗黙的に推測される事実には弱いのです。 登場人物の目の色は書き留められます。一方、その人物が兄弟に対して感じる心理的距離は、3つの場面を通じて表現され、明言されないこともあります。前者は確認できますが、後者には読者が必要です。
また、AIが逆方向に確実に誤るカテゴリもあります。伏線、ミスリード、自己矛盾する信頼できない語り手など、意図的な不整合を、表現技法として認識せずエラーとして検出してしまうのです。受け取った整合性レポートは、対応する前に必ず人間がトリアージする必要があります。
1ページのあらすじを10章のビートへ拡張するには？
拡張層は、あらすじを構造化された階層、すなわち 前提 → ストーリーバイブル → アウトライン → 章のビート → 散文 へ変換します。中間段階を飛ばすことは、原稿がぶれていく最も一般的な原因です。
Sudowriteのドキュメントは、この依存関係を特に明確に示しています。Story BibleではBraindumpからSynopsisを生成し、SynopsisからCharactersとWorldbuildingを、Genre、Synopsis、Characters、WorldbuildingからOutlineを、さらにそれらすべてからScenesを生成します。そして最後に、Style、Genre、Characters、Worldbuilding、Scenesから章の散文を生成します（Sudowrite Story Bibleドキュメント）。各層は次の層へ情報を渡します。中間層が空なら、後続の生成は残された薄いコンテキストにひそかに依存することになります。
10章向けの実践的な拡張手順：
- 最初に全体の器を決める。 拡張の前に、章数、1章あたりの目標語数、POVの構成を決定します。1章3,500語の10章なら35,000語の原稿、つまり中編です。1章8,000語なら短めの長編になります。モデルにはこの数値が必要です。
- あらすじからバイブルを抽出する。 1ページ内の名前付きエンティティをすべて取り出し、それぞれを記録として展開します。外見、話し方、動機、関係性に加え、後で矛盾し得る事実、すなわち年齢、怪我、所持品、場所の履歴を必ず含めます。
- 10ビートの背骨を作る。 各章について、4行を書きます。POV人物、開始状況、転換点、終了状況です。第N章の終了状況は、第N+1章の開始状況と一致しなければなりません。これが主要な整合性ガードレールになります。
- 後で効く細部を意図的に仕込む。 どの章で各物品、傷、約束が導入され、どの章で回収されるかを記録します。これは物品追跡用のチェックリストになり、AIが最も苦手とするエラー種別に対処します。
- 散文は1章ずつ生成する。 バイブル、現在のビート、前章の終了状態を与えて生成します。
専用の小説アプリではなく汎用AIプラットフォームで行う場合、ストーリーバイブルは構造化データベースではなく会話内に置かれます。Jenovaでは、Creative Fiction Writerエージェントが、この拡張を永続的なプロジェクトとして扱えます。無制限のチャット履歴とセッションをまたぐメモリにより、セッション1で作ったバイブルをセッション9でも利用できます。また、ナレッジベースの添付機能により、執筆中にエージェントが参照する根拠文書としてバイブルをアップロードできます。実用的な最初のプロンプトは次のとおりです。
「これが私の1ページのあらすじです。何かを書き始める前に、ストーリーバイブルを作ってください。人物ごとの外見描写と話し方のメモ、場所、日付入りの時系列、物品・約束の台帳を含めてください。その後、1章3,500語の10章ビートシートを作成し、各章の終了状態が次章の開始状態と一致するようにしてください。あらすじの情報が不足している箇所は指摘してください。」
Novelcrafterで行う場合は、プラットフォームのドキュメントで「登場人物、場所、物品などに関する重要な情報を保存する」中核ハブと説明されているCodexへ、バイブルを先に入力します（Novelcrafter Codexドキュメント）。その後、シーンごとにStory Beatsを作成し、各ビートにCodexエントリーをリンクします。これにより、AIは生成のたびに汎用的なコンテキストではなく、精選されたコンテキストウィンドウを受け取ります。
章ごとの整合性チェックに最適なAIツールは？
ツールは、予防、つまり執筆中に整合性を維持する方法と、検出、つまり完成原稿を監査する方法という、2つの思想に分かれます。10章のプロジェクトにおける実用的な答えは、両方が必要だということです。
予防ツールは、各新規生成に先行章を与えることで、エラーを発見する前に回避します。検出ツールは、大量のテキストを一度に保持し、後から矛盾をスキャンします。両者を分けるのはコンテキストウィンドウの大きさであり、ある比較では、これが整合性能力における「最も重要な要素」だとされています（Inkfluence AI）。
| 項目 | Novelcrafter | Sudowrite | Jenova | Inkfluence AI | NovelAI |
|---|---|---|---|---|---|
| 整合性へのアプローチ | シーンビートにリンクする手動管理のCodex | 生成時に参照されるStory Bible | 永続メモリ＋添付ナレッジベース、複数モデルによる監査 | 生成時に直近2～3章のコンテキストを使用 | 手動管理のLorebook |
| チェック用の作業記憶 | Codexから精選したシーン別コンテキスト | Story Bibleのフィールドと依存関係チェーン | 無制限のチャット履歴。各チェック時のコンテキストはモデル依存 | 2～3章 | 約8,000トークン（約6,000語） |
| 構造化アウトライン | Story Beats、幕・シーン計画 | Braindump → Synopsis → Outline → Scenes → Draft | 会話形式のアウトライン。固定スキーマなし | 20種類以上のジャンル用ブループリントによる順次章生成 | 最小限 |
| モデルの選択 | 有料プランでは自分のキーを使用 | プラットフォームが選択したプロバイダーモデル | OpenAI、Anthropic、Google、xAI、DeepSeekを自由に切替 | プラットフォーム管理 | 独自モデル |
| 必要な手動メンテナンス | 高い — Codexを手動で維持 | 中程度 — Story Bibleは一部自動生成 | 中程度 — バイブルはチャットまたはアップロードしたファイル内に置く | 執筆中は低い | 高い — Lorebookを手動で維持 |
| 価格 | 月額$4 / $8 / $14 / $20。AI費用はBYOKにより別途（Novelcrafter価格） | クレジット制のサブスクリプションプラン | 無料プラン。Plusは無料利用枠の30倍で月額$20、Enterpriseまで対応 | 無料プランは5章・1日3回生成。Creatorは月額$9.99から | 月額$10～$25 |
| 最適な用途 | 大規模な世界構築を伴う長期シリーズを設計する書き手 | ガイド付きパイプラインで生成散文を求める探索型の書き手 | 1つのワークスペースで執筆と異なるモデルによる独立監査を行いたい書き手 | 整合性を組み込んだ連続的な初稿生成 | 散文の実験向け。長編規模の整合性には不向き |
表を率直に読むなら：
Novelcrafterは、ここで最も強力な構造システムです。CodexとStory Beatsのアーキテクチャは、あらすじから章へ進む問題のために作られています。また、月額$4という最も低い開始価格を提供します。ただし、文書化されたトレードオフもあります。無料プランはなく、代わりに21日間のトライアルが用意されています。Codexのメンテナンスは手動で、有料プランでは自分のAIキーを用意する必要があるため、表示価格が総費用ではありません（Novelcrafter料金ページ）。
Sudowriteは、あらすじから散文までの最も完全な生成パイプラインを持ち、フィールド間の依存関係も明示的に文書化されています。同社の比較資料も、思想上のトレードオフを認めています。偶発性や創造的補助のために設計されているため、出力は過剰に書き込まれがちで、自分らしい文体にするには編集工程が必要です（Sudowrite比較分析）。
Jenovaは汎用的な選択肢で、このワークフローにおける利点は、とりわけ執筆と監査を分離できることです。同じプロジェクト内でOpenAI、Anthropic、Google、xAI、DeepSeekのモデルを切り替えられるため、あるモデルで7章を書き、別のモデルで監査できます。これは本当に有用な対抗的な仕組みです。章を書いたモデルは、2章との矛盾に最も気づきにくいモデルでもあるからです。セッションをまたぐ永続メモリと無制限のチャット履歴により、ストーリーバイブルはセッション間で消えません。また、根拠として参照させる文書としてバイブルを添付できます。率直な制約は、原稿専用の構造が存在しないことです。Codexスキーマ、シーンビートボード、章ツリーはありません。バイブルは文書として、規律は習慣として自分で維持します。ソフトウェア側に構造を強制してほしい書き手は、専用の小説プラットフォームを好むでしょう。
Inkfluence AIは、予防優先の選択肢として最も明確です。各生成に直前の2～3章を与え、無料プランでは5章まで利用できます。ただし、10章の物語構造では同社が示す制約が現実的です。2章の細部は、9章を生成する際に自動的には表面化しない可能性があります。
NovelAIは、この用途では別カテゴリとして扱うべきです。約6,000語の作業記憶では一度にほぼ1章しか確認できず、Lorebookは同じ限られたコンテキスト予算を直近の本文と奪い合います。
各章の後に整合性チェックを実行するには？
監査は、新しいコンテキストで構造化された対抗的なチェックとして実施します。チェック役にはストーリーバイブル、新しい章、前章の終了状態を渡し、一般的な感想ではなく、分類済みのエラーレポートを求めます。
避けるべき失敗パターンは2つです。たった今その章を書いた会話に評価させること。そうするとAIは自身の選択を擁護しがちです。そして、「これは整合していますか？」のような自由回答型の質問をすることです。これでは決まって「はい、整合しているようです！」という回答が返ってきます。
繰り返し使える章ごとの監査プロンプト：
「あなたは整合性編集者です。これから、(1) ストーリーバイブル、(2) 第6章の終了状態、(3) 第7章の全文を渡します。第7章を両方と照合して監査してください。人物描写、時系列、設定、物品・所持品の追跡、関係性の状態という5カテゴリーで、検出結果を報告してください。各検出結果について、矛盾する本文、矛盾先の出典、その問題が重大なエラー、軽微なずれ、意図的である可能性のいずれかを示してください。散文の質にはコメントしないでください。あるカテゴリーで問題がなければ、そのことを明示してください。」
次に、7章で新たに確立した情報でバイブルを更新します。なぜなら、バイブルは固定入力ではなく、生きた文書だからです。 この段階を飛ばすワークフローが最も多く、それが、綿密に計画したプロジェクトでも整合性が劣化する理由です。AIは、4章の時点で正確ではなくなったバイブルと9章を照合しているのです。
追加で計画すべき2つのチェック：
- 5章時点での中間スイープ。 1章から5章を個別ではなくまとめて監査します。導入後に放置されたサブプロット、回収されない約束など、章をひとまとまりで読んだときにだけ見える章間エラーがあります。
- 10章時点での原稿全体監査。 35,000語の10章原稿なら大きなコンテキストウィンドウに十分収まります。つまり、80,000語の長編では難しい原稿全体のスキャンが、この規模なら完全に実用的です。これは10章形式が持つ真の構造的な利点です。
ツールによる違い。 Novelcrafterでは、監査の一部は構造的に行われます。シーンにCodexエントリーがリンクされているため、生成時点でAIは正しい事実をすでに受け取っており、事後チェックで見つかる問題は少なくなります。Sudowriteでは、整合性の品質はStory Bibleをどれだけ綿密に維持するかに左右されます。文書化されたテストでは、明示的な人物描写にはよく従う一方、散文中で確立されたもののバイブルに記録されなかった細部は見落とすことがわかっています（Inkfluence AI）。Jenovaでは、執筆に使ったモデルとは別のモデルに上記の監査プロンプトを実行し、その修正点を永続メモリに記録して、後続章に修正を引き継がせます。
章レベルの検証に追加時間をかける価値がある理由は？
整合性エラーは先の章へ連鎖するからです。また、プロの人間による整合性編集には、80,000語の長編で2～6週間を要し、$1,600から$4,000の費用がかかるためです（Inkfluence AI）。3章で矛盾を見つければ、必要なのは1回の修正です。同じ矛盾を10章で見つけると、その上に積み重ねられたすべての章が問題を引き継いでいます。
これは、現役の著者がすでにAIを利用している方法とも一致します。1,229人の著者を対象とした調査では、生成AIを使う著者の81%がリサーチに利用しており、次に多い用途はマーケティング資料とアウトラインまたはプロット作成でした（BookBub著者調査）。アウトラインとプロット、すなわち拡張層は、すでに一般的な実務です。検証は、まだ導入が遅れているもう半分です。
同じ調査に寄せられた著者コメントには、まさにこの用途が記されています。
「長期シリーズの細部を追跡する助けとして、私は事業のあらゆるレベルにAIを組み込んでいます。」
「シリーズバイブルや人物リストの作成など、大量の情報を要約・分析するためにAIを使っています。」
この調査は、より広い文脈も率直に記録しています。回答者の45%は現在生成AIを利用している一方、48%は利用しておらず、利用予定もありません。 非利用者の84%が倫理的懸念を挙げており、最も多い理由は、AIツールが創作者に補償することなく著作権保護された作品で学習されたというものでした（BookBub著者調査）。Australian Society of Authorsの調査では、回答者の98%が、AI企業は著者の作品を利用する前に許可を求めるべきだと考えていました（ASA 2025調査）。またInternational Thriller Writersは、76.1%が、AIは10年以内に著者の収入へ悪影響を与えると予想していると報告しています（ITW人工知能調査）。
こうした調査結果は、執筆ワークフローと切り離されたものではなく、そのワークフローに直接関係します。前提、構造、改稿の判断があなた自身のものであり、機械が拡張とファクトチェックを担うなら、あらすじから原稿へのパイプラインは、より擁護しやすいAI利用法になります。開示も現在進行形の課題です。生成AIを利用する著者の74%は、その利用を読者に開示していません（BookBub著者調査）。
フィクション編集者はAIによる整合性チェックをどう見ているのか？
原稿を職業として扱う人々の間での共通認識は、AIは優れた機械的チェック役であり、弱い編集者でもあるということです。そして、その違いによって導入方法を決めるべきです。
「書き手が犯しがちな誤りは、整合性を単一の作業として扱うことです。しかし、そうではありません。事実の整合性、つまり名前、日付、目の色、誰がナイフを持っているかという問題があります。そして心理的整合性、つまり9章での人物の行動が、2章時点でのその人物像を踏まえて信じられるかという問題があります。AIは前者には本当に優れていますが、後者には事実上まったく見えていません。KatherineがCatherineになったことは教えてくれます。しかし、Katherineが本人らしい話し方をしなくなったことは教えてくれません。」
「特に10章のプロジェクトでは、原稿全体のスキャンが最大の構造的利点なのに、多くの書き手はそれを無駄にしています。35,000語なら原稿全体を1つの大きなコンテキストウィンドウに収められます。80,000語ではそうはいきません。つまり、3年前には小説家ができなかった質問を1つ投げかけられるのです。『これを一度に全語読み、何が矛盾しているか教えてください』と。最後だけでなく、5章時点と10章時点の両方で行ってください。」
「もう1つ、率直に言う価値があることがあります。執筆モデルを監査モデルにしてはいけません。すでにそのモデルは自分の選択にコミットしています。バイブルと照合し、新しいコンテキストで、プラットフォームが許すなら異なるモデルを使って、先入観なく監査してください。同じ章に対する2つのモデルの見解の不一致は、どちらか一方のレポート単独よりも多くを教えてくれることがよくあります。」
— Jenovaプロダクトチーム、長文執筆・編集ワークフロー開発6年
AIで作成した10章原稿にはどのような限界があるのか？
率直な上限を言えば、AIは構造的に一貫し、事実関係の整った10章原稿を作れます。しかし、両端で相当な著者の作業を加えなければ、良い原稿を作ることはできません。
現在のツールではうまく扱えないこと：
- テーマの一貫性。 AIは事実を追跡できますが、人物の行動が確立された成長曲線に寄与しているかを安定して判断することはできません（Inkfluence AI）。
- ペース配分の連続性。 物語のリズムが10章を通して維持されているかは、AIの信頼できる範囲を超えた判断です。
- 意図的な不整合。 伏線、ミスリード、信頼できない語りはエラーとして検出されます。
- 声のぶれ。 モデルは文単位ではスタイルプロンプトに合わせられても、1章と同じ声に聞こえない10章を生み出すことがあります。スタイル一致機能は存在します。たとえばSudowriteのMatch My Styleは著者の作品を分析し、スタイルプロンプトを作成します（Sudowrite用語集）。しかし、制約できるのは表面的な質感であり、持続する文体の声ではありません。
ツール面の制約も明言する価値があります。 ここで比較したすべてのプラットフォームは、労力をなくすのではなく移し替えます。Novelcrafterは作業をCodexのメンテナンスへ移します。Sudowriteは、過剰に書かれた散文の編集改稿へ移します。Jenovaは、強制された構造がないため、自分でバイブルを維持し、監査の規律を実行する作業へ移します。Inkfluence AIは事前の労力を減らしますが、AIがどこまで過去を見られるかに制限があります。あらすじを貼り付けるだけで、きれいな原稿が得られる構成はありません。
このワークフローによる現実的な成果物は、検証済みで内部整合性のあるゼロドラフトです。事実が保たれ、時系列が機能し、物品が置いた場所にある原稿です。これは本当に価値があります。なぜなら、200ページ目で主人公の姉妹の名前が変わっていたと発見する代わりに、改稿の力を文体、テーマ、シーン作りへ注げるからです。ただし、これは執筆の代替ではなく、執筆の出発点です。