Novelcrafter は、AI 支援による小説執筆において最大の課題となる「長編叙述の一貫性維持」と「コンテキスト保持」を解決するために設計された、高度にモジュール化された創作アーキテクチャを作家に提供する。従来のテキスト生成ツールは、物語執筆を単発のプロンプトによる問い合わせとして扱う傾向が強く、その結果、登場人物の設定忘れ、世界観のブレ、不自然なテンポの崩れが生じがちであった。これに対し Novelcrafter は、作家の世界観・設定知識ベースと、実際のシーン執筆プロセスを明確に分離・切り離す構造を採用している。このシステムの核心をなすのが、登場人物の特徴、別名、動的な関係性の変化を追跡するインタラクティブなストーリーバイブル「Codex」と、作品全体のアウトラインを個別のシーンビートへと細分化する「Plan」ビューである。Codex の設定項目と粒度の高い叙述ビートを連動させることで、作家は複数章にわたる長大な原稿を通じて深層の一貫性を維持し、モデルのハルシネーションを排除し、確立された世界観設定に厳密に従った文章を生成するよう AI を制御できる。
アーキテクチャの分離：Codex の設定資料と構造的アウトライン
10万語規模の長編小説を執筆する際には、全く性質の異なる2種類の創作情報を管理する必要がある。1つは静的または変化の緩やかな参照データ（登場人物の外見、心理的欠陥、魔法体系の法則、舞台設定の描写）であり、もう1つは動的な時間軸の進行（プロットを前進させる一連のアクション、事実の判明、感情の起伏、対話）である。汎用の文章生成ツールでは、執筆者は膨大なプロンプト入力欄に人物描写やプロットの備忘録を何度も貼り付け直さざるを得ず、コンテキストウィンドウの上限を急速に浪費するだけでなく、無関係な詳細情報によってモデルを混乱させてしまう。
Novelcrafter は、以下の疎結合された3層構造によってこの課題を解決している：
- Codex（ストーリーバイブル）： 登場人物、勢力・派閥、ロケーション、アイテム、世界観の基本概念など、永続的な設定情報を一元管理するリレーショナルなリポジトリ。プロンプトを生成するたびに全設定をそのまま流し込むのではなく、スマートタグ検出とシーン単位の選択的紐付けにより、そのシーンに真に必要な設定項目のみを抽出する。
- Plan ビュー（マクロ構造の階層化）： 原稿をマクロな構造単位（幕、章、シーン）へと整理するアウトラインキャンバス。各シーンには専用の要約とメタデータフィールド（視点人物 POV、舞台設定、タイムライン上の位置など）が用意されており、モデルに対して必要不可欠なコンテキストの足場を提供する。
- Write ビューとシーンビート（ミクロ実行）： シーンを時系列に沿った指示（シーンビート）へと細分化して文章を起草する執筆ワークスペース。AI に章全体を一度に書かせるのではなく、時系列の指示をステップバイステップで与えることで、テンポ、登場人物の反応、文章表現のトーンを精密にコントロールできる。
「登場人物がどのような存在か」（Codex）、「そのシーンが作品全体のどこに位置するか」（Plan）、「その瞬間何が起きるか」（Scene Beats）の境界を明確に定めることで、小説家は最先端の大規模言語モデルによる高速な文章生成を活用しつつ、厳密な創作の主導権を維持できる。
Codex における登場人物設定と世界観構築
Codex は、AI が作品の世界観を理解するための基盤となる主要なインテリジェンス層として機能する。これを適切に構造化することで、章の途中で登場人物の目の色が変わったり、性格に合わない俗語を口にしたり、10章前に確立された重要な人間関係を失念するといった、生成 AI にありがちなミスを防ぐことができる。
1. 高密度な登場人物エントリーの構造化
Codex の各登場人物エントリーは、長文の散文的な略歴ではなく、実用的で情報密度の高い参照シートとして機能させる必要がある。大規模言語モデルは、冗長な背景エピソードの段落よりも、構造化され要約された記述をはるかに効率的に処理する。
充実した登場人物エントリーは、通常以下の主要フィールドで構成される：
- 名前と識別子（Name and Identifiers）： 見出しや索引付けに使用される正式名称。
- 別名・愛称（Aliases and Nicknames）： 原稿内でその人物を指す別名、称号、愛称のカンマ区切りリスト（例：「Eleanor Vance, Nora, Lady Vance, The Red Fox」）。
- 役割と類型（Role and Archetype）： 主人公、敵役、味方、あるいは端役の背景人物かを指定する分類タグ。
- 外見描写（Physical Description）： 身長、髪質、顔の傷跡、特徴的な衣服、姿勢、声の調子など、具体的で識別しやすい視覚的特徴。
- 心理的コアと動機（Psychological Core and Motivation）： 根源的な欲望、主要な恐怖、精神的トラウマ、内面的葛藤など、危機的状況下で人物がどのように反応するかを決定づける要素。
- 口調と癖・振る舞い（Voice and Mannerisms）： 特有の語彙パターン、お決まりの口癖、話し方の癖、特異な行動パターンなど、AI がその人物固有のリアルな語り口を模倣するための手がかり。
2. 別名（Aliases）の効力とスマート検出
Novelcrafter の最も重要な技術的特徴の1つが「スマート検出（Smart Detection）」である。長編小説において、作者が毎ページ登場人物をフルネームで呼ぶことは稀である。「Captain Marcus Sterling」という人物は、語り手やシーンの心理的距離に応じて、「Marcus」「the captain」「Sterling」などと呼び分けられる。
Codex エントリーの Aliases フィールドにこれらの呼称を登録しておくことで、Novelcrafter のバックグラウンドトークナイザーがシーンビートや本文内の多様な呼び名を自動検出する。作家がビート内に別名を入力するか、@ トリガーで選択すると、プラットフォームはその言及をマスターの Codex レコードと自動的にリンクさせ、AI モデルに送信されるプロンプトコンテキストに該当エントリーを挿入する。これにより、手動で照合する手間が省け、モデルが誰について語られているのかを常に正確に把握できるようになる。
3. 進展記録とステータス追跡による動的アークの管理
物語の中で登場人物が終始変化しないことはほとんどない。主人公が第5章で後遺症の残る怪我を負ったり、第12章で衝撃的な裏切りを知ったり、第20章で所属陣営を変えたりすることがある。Codex エントリーが初期状態のまま固定されていると、その後の AI 生成において、これらの展開と矛盾する文章が生成されるリスクが生じる。
Novelcrafter は、動的ノート、エントリーの進展記録（progressions）、ステータス追跡によって登場人物の進化に対応する：
- 段階的な更新（Progressive Updates）： 新たに習得した魔法能力、四肢の欠損、変更された爵位など、恒久的な変化を記録するために、タイムライン固有の追記を行うことができる。
- 関係性モディファイア（Relationship Modifiers）： かつてのライバル同士が危うい同盟を結ぶなど、人間関係が変化した際、双方のエントリー内にある関係性メモを更新することで、生成される対話にその緊張感の変化を反映させることができる。
- アーカイブと無効化（Archiving and Deprecation）： 死亡した人物や物語から完全に退場した人物については、タグやステータスを変更し、自動検出スキャンで誤って呼び出されないように設定できる。
4. コンテキストの最適化：グローバル設定 vs シーン固有の紐付け
コンテキストウィンドウの容量には限りがあり、プロンプトに参照データを過剰に詰め込むと「アテンションの希釈（attention dilution）」が起き、AI が細かな指示を無視したり、矛盾した描写を捏造したりする原因となる。Novelcrafter はコンテキスト密度を制御するための2つの補完的メカニズムを備えている：
- 言及に基づく自動挿入（Automatic Mention-Based Injection）： 実行中のシーンビート内で人物、勢力、アイテムなどが明記されると、Novelcrafter は対応する Codex エントリーを自動的に取得し、生成ペイロードに組み込む。
- 手動シーンコンテキスト（Manual Scene Context、
+ Codex）： 本文中で名前が直接言及されていなくても、ある世界観設定がシーン全体を強く支配している状況は多い。例えば、緊迫した尋問シーンの背後に地政学的な条約や語られない家族の秘密が存在する場合などである。シーン要約の下にある+ Codexボタンをクリックすることで、作家はそれらの設定エントリーをシーン全体に明示的に紐付けることができ、ビートの指示を煩雑にすることなく、AI に十分な文脈意識を持たせることができる。
原稿の構造化：Plan ビューにおけるアウトライン作成
個々の段落を書き始める前に、作家は Plan ビューで物語のマクロ構造を組み立てる。このアウトラインインターフェースは、高次なテーマ構想とシーンごとの実践をつなぐ、視覚的で整然とした階層構造を提供する。
1. 階層的な物語構成
Plan ビューは、執筆内容を入れ子構造の3つの階層に整理する：
- 幕（Acts）： ドラマチックな緊張感の主要な展開段階を定義する大枠の叙述単位（例：古典的な三幕構成、五幕悲劇、あるいは Save the Cat などのビートシート）。
- 章（Chapters）： 1つまたは複数の関連シーンを含む個別の読書単位であり、自然なリズムの区切りとテーマごとのまとまりを提供する。
- シーン（Scenes）： Novelcrafter における最小の実務単位。各シーンは、特定の場所、特定の視点、明確な作中時間において発生する一連の連続した行動を表す。
各シーンカード内で、作家は以下の重要な構造メタデータを割り当てる：
- 視点（Point of View、POV）： どの登場人物のフィルターを通して感覚描写や内面思考を描くかを指定する。
- 主たる舞台（Primary Location）： シーンを Codex 内の特定の場所エントリーに紐付け、環境描写や感覚的背景を自動的に付与する。
- 目標文字数（Target Word Count）： 章ごとのペース配分を整えるための構造的目標を設定する。
2. シーン要約の戦略的機能
Novelcrafter において、シーン要約（Scene Summary）は作家用の備忘録にとどまらず、AI 生成エンジンが読み込む実行用プログラム入力としても機能する。
Write ビューで文章を生成する際、AI モデルは現在の場面が過去の出来事とどうつながっているかを理解する必要がある。何万語もの生の原稿テキストをプロンプトに流し込むのは、コストが高く、処理が遅くなり、コンテキスト劣化を招きやすい。これに対し Novelcrafter は、直前のシーン要約を生成プロンプトに挿入する方式をとる。
AI の連続性を最大化するため、作家は以下の原則に従ってシーン要約を作成することが推奨される：
- 状態変化に焦点を当てる： 人間関係、物理的状態、登場人物の認知がシーン内でどのように変化したかを明記する（例：「エレナはロバート卿の書斎で偽造された台帳を発見した。中庭を抜けて逃走する際、ロバートに見つかり捕らえられた」）。
- 未解決の葛藤を記録する： 後続のシーンへと持ち越される残された対立や緊急の疑問点を明示する。
- 厳密な時系列を維持する： 出来事が起きた順序通りに要約し、モデルの時系列理解を妨げるような装飾的な表現や主観的批評は避ける。
アウトラインの実行：シーンビートによる執筆
Plan ビューが物語全体の青写真を描く場であるなら、Write ビューはシーンビートを用いてその構想を具現化する場である。シーンビートは、人間の創作意図と機械の文章生成をつなぐ直接のインターフェースとなる。
1. シーンビートとは何か？
シーンビート（scene beat）とは、シーン内の特定の行動、対話、描写を執筆するよう AI に命じる、粒度の高い時系列指示のことである。「第3章を書け」といった大雑把な指示を出すのではなく、作家は第3章を5〜10個の個別ビートに分解する。
Novelcrafter のエディタでは、ビートは /beat コマンドまたはスラッシュショートカットで呼び出される。作家が指示を入力すると、AI はその直下に該当する文章を生成する。作家は生成結果を確認し、採用、修正、再生成、破棄のいずれかを選択してから、次のビートへと進むことができる。
2. シンプルビートと誘導型ビート
創作スタイルに応じて、作家は通常2つの起草手法を使い分ける：
- シンプルビート（発見型執筆）： 一定の制約の中で AI に展開の可能性を探らせたい場合に使用する。大まかな行動と意図のみを指定する。例：
/beat Marcus enters the tavern, soaking wet from the storm, looking for his informant. - 誘導型ビート（監督的コントロール）： 特定の立ち回り、対話のニュアンス、感情の機微、感覚的描写を厳密に制御したい場合に使用する。行動に加えて具体的なサブテキストや語り口の指示を盛り込む。例：
/beat Marcus enters the tavern, shivering from the torrential rain. He spots Dennis sitting in the dark corner booth nursing a stale ale. Dennis avoids eye contact, terrified of being seen together. Marcus approaches, speaking in a low, threatening whisper, demanding the cipher key.
シーンビートの具体性を調整することで、小説家は重要なプロット展開における演出の主導権を完全に保持しつつ、日常的な場面転換を迅速に執筆できる。
3. ペース配分と「原因と結果（Cause and Effect）」フレームワーク
生成 AI による小説執筆で頻繁に見られる問題が「時間的圧縮（temporal compression）」である。これは、AI が複雑な劇的状況をわずか1段落の中で性急に解決してしまう現象を指す。シーンビートは、「原因と結果」（または「そして次に」）フレームワークを適用することで、これを効果的に防止する：
- ビート 1（発端のアクション / 感覚的定着）： 物理的環境と、登場人物が直面する直接の刺激を提示する。
- ビート 2（内面的反応 / 感情の処理）： 視点人物の心理的応答、葛藤、感覚的判断を描写するよう指示する。
- ビート 3（応戦アクション / 対話）： その判断に基づき、発言や身体的動作を通じて人物に行動を起こさせる。
- ビート 4（事態の複雑化 / 環境の変化）： 人物の当初の目標を阻む新たな障害、中断、予想外の事実を導入する。
これらの最小ステップを時系列順に積み重ねることで、生成される文章に自然なリズム、説得力ある緊張感、そして確かな物語の深みが生まれる。
4. プロンプト生成エンジンの構造
Novelcrafter でビート生成を実行すると、プラットフォームはバックグラウンドで多層構造のプロンプトを動的に構築する。各層の連携の仕組みを理解することで、生成結果に問題が生じた際にも的確な原因特定が可能になる：
- システムプロンプト（System Prompt）： 全体的な文体、叙述視点（一人称 vs 三人称限定視点）、時制（過去形 vs 現在形）、およびネガティブ制約（メロドラマ的な陳腐な表現や現代の俗語の回避など）を設定する。
- シーン要約とメタデータ（Scene Summary and Metadata）： シーンのマクロな背景を提供し、視点人物、現在のロケーション、叙述上の目的を明示する。
- 直前の本文（ルックバックコンテキスト、Lookback Context）： ビートの直前に書かれた最新の段落を読み込み、文体の自然なつながり、トーンの一貫性、文章のリズムを維持する。
- 紐付けおよび言及された Codex エントリー（Attached and Mentioned Codex Entries）： 自動検出または手動タグ付けによって抽出された、関連人物の特徴、口調ガイドライン、世界観設定を注入する。
- 実行中のシーンビート（Active Scene Beat）： その回の生成でモデルが書くべき内容を具体的に指定する中核の指示。
すべてのコンポーネントが個別に管理されているため、作家は何百ものプロンプトテンプレートを書き直すことなく、Codex で人物の口調を微調整したり、Plan ビューで要約を修正したりすることができる。
ワークフローの比較：Codex、Plan、Scene Beats
下表は、Novelcrafter の主要構造コンポーネントの役割、運用範囲、コンテキスト供給方式、および長編執筆におけるベストプラクティスをまとめたものである：
| コンポーネント | 主要なアーキテクチャ上の役割 | 運用範囲 | コンテキスト供給方式 | 小説家にとってのベストプラクティス |
|---|---|---|---|---|
| The Codex | 人物、設定、世界観情報を蓄積する静的および進展対応のストーリーバイブル | 小説全体または複数巻のシリーズ | 別名のスマート検出、@ によるメンション、手動の + Codex シーン紐付け | エントリーは簡潔かつ特徴重視（150〜300語程度）に保つ。すべての別名を登録し、重大な展開後は進展ノートを更新する |
| The Plan View | マクロな構造設計とシーン階層管理（幕、章、シーン） | 原稿全体のアウトライン | 直前のシーン要約を時系列順にアクティブプロンプトへ供給 | シーンごとに POV とロケーションのメタデータを設定。プロットへの影響に着目した状態変化要約を作成する |
| Scene Summaries | 連続するシーン間をつなぐ物語の架け橋 | シーン単位（Plan および Write ビュー内） | 生成プロンプトへ注入し、複数章にわたる一貫性を維持 | 因果関係の結果を要約する。装飾過剰な表現は避け、登場人物の新たな認識状態を記録する |
| Scene Beats | 本文起草を実行するためのミクロな演出指示 | アクティブなシーン内の瞬間的な推移 | スラッシュコマンド（/beat）を通じて即時生成プロンプトとして処理 | 因果関係に基づき順序立ててビートを構成。アクション、内面描写、対話指示をバランスよく織り交ぜる |
| Lookback Buffer | 文体とリズムの連続性を保つ短期記憶 | 直前の段落（トークン長はカスタマイズ可能） | アクティブなビート指示の直前に自動付加 | 次のビートを実行する前に直前の文章を推敲し、文体の乱れが連鎖して拡大するのを防ぐ |
複数章にわたるプロジェクトで一貫性を維持するためのベストプラクティス
Novelcrafter を用いて破綻のない長編小説を書き上げるには、規律ある運用の習慣を確立することが欠かせない。経験豊富な作家は、長大な執筆過程で人物設定やテンポが崩れないよう、以下の手法を実践している：
1. Codex の肥大化を防止する
初心者が陥りがちな過ちは、何ページにも及ぶ長大な世界観設定の文章をそのまま Codex エントリーに登録してしまうことである。過大なエントリーが複数シーンに紐付けられると、モデルのアテンションが分散し、生成の鈍化、指示の無視、API コストの増大につながる。
Codex エントリーは、設定のダンプ場ではなく、実用的なリファレンスカードとして扱うべきである。文章生成に直接影響を与える機能的特徴（際立った感覚描写、口調のリズム、感情の地雷、直接的な人間関係など）に焦点を絞る。登場人物の行動に直結しない背景設定は外部の研究ノートに保存するか、要点を突いた一文に集約するのが賢明である。
2. アウトラインの定期的な監査を実施する
Plan ビューで綿密なアウトラインを作成していても、実際の執筆過程でひらめきが生じ、人物の動機や結末が変わることはよくある。味方だった人物が予期せず裏切るシーンを書いたにもかかわらず、Plan ビューの後続シーン要約を更新し忘れると、AI はその人物が依然として忠誠を誓っているという古い前提に基づいて執筆を続けてしまう。
シーンが当初のアウトラインから逸脱した場合は：
- 書き終えたシーンの要約を直ちに更新し、実際の展開を正確に反映させる。
- Plan ビュー内の以降の章およびシーン要約を修正し、プロットの整合性を再調整する。
- Codex 内の該当人物レコードを更新し、新たな忠誠関係、負傷、心理的変化を反映させる。
3. BYOK アーキテクチャによるモデルの使い分け
Novelcrafter は Bring Your Own Key（BYOK）方式を採用しているため、特定の単一 AI モデルに縛られることがない。執筆ワークフローの各段階に応じて、異なるモデルの特性を活かすことができる：
- アウトライン構想と世界観構築： 応答が速くコスト効率の高いモデルは、シーンビートのブレインストーミング、アウトラインの派生案作成、初期の Codex テンプレート生成に最適である。
- 本文起草： 文体の適応力に優れた高性能な最先端モデルは、複雑な誘導型ビートの解釈、繊細な対話のニュアンス表現、変化に富んだ構文の維持に適している。
- 推敲とブラッシュアップ： 文章分析に特化したモデルは、カスタムプロンプトプリセットを通じて、章の完成前にテンポの停滞、形容詞の多用、キャラクター崩壊した台詞などを精査する校正役として活躍する。
Codex による一元的な参照能力、Plan ビューによる構造的ガイダンス、そして Scene Beats によるミクロな演出コントロールを統合することで、小説作家は AI を気まぐれなツールから、規律正しく忠実な共同執筆パートナーへと変貌させることができる。長編の一貫性はもはや偶然に頼るものではなく、原稿の骨格そのものに体系的に組み込まれるのである。