重要なポイント
- コンテキストウィンドウの現実：紙上では128Kトークン、実際は32Kトークン。 ほとんどのローカルモデルの注意品質は32Kトークン（〜24,000語）を超えると著しく低下します。原稿全体をコンテキストウィンドウに貼り付けず、セッションドキュメント技術を使ってください。
- セッションドキュメント技術がコアスキル。 圧縮テキストファイルを維持します：アクティブなキャラクターシート（各キャラクター150語）、章サマリー（完成した章ごとに100〜200語）、現在のシーンのセットアップ。各生成セッションの開始時に注入します。
- 1セッションに1シーン生成。 増大するドキュメントの継続を求めるのではなく、1シーン（200〜600語）を生成します。1セッション1シーンはコンテキストドリフトを排除し、一貫した声を生み出します。
- 脚本はビートシートファースト。 スクリプトページを生成する前に、シーンレベルのビートシートを生成します。ビートシートを各ページ生成の足場として使います。
- Llama 3.3 70Bが長編作業に最適なモデル。 強いコンテキスト遵守性、長い生成での最良の命令追随、長いセッションにわたる信頼できるキャラクター声の一貫性。
- Ollama＋プレーンテキストライティングツールが最も信頼できる統合。 Scrivener、Obsidian、VS CodeはすべてAPIを通じてOllamaと連携できます。
- アンセンサードモデル（Hermes 3）はセットアップ変更なしに組み込める。 成熟したフィクション向けに、OllamaモデルをHermes 3に切り替えるだけ；セッションドキュメントと生成技術は同一。
クイックファクト
- 長編フィクションに最適なモデル： Llama 3.3 70B（最強のコンテキスト遵守性と命令追随）。
- コンテキストウィンドウの実用的上限： 信頼できる注意品質のために〜32Kトークン（〜24,000語）；128Kは技術的上限。
- セッションドキュメントのサイズ： 4,000トークン未満を目標（キャラクターシート＋章サマリー＋現在のシーンセットアップ）。
- シーン生成の目標： 1生成呼び出しあたり200〜600語；複数の連続プロンプトで長いシーンを生成。
- 脚本フォーマット： Fountain形式の出力命令とOllamaを組み合わせてスクリプトフォーマットのテキストを生成。
- Ollamaと連携するライティングツール： Scrivener（APIスクリプト経由）、Obsidian（プラグインまたはスクリプト経由）、VS Code（Continue.dev経由）、ターミナル。
- アンセンサードオプション： 成熟したフィクション向けHermes 3 Llama 3.3；同じワークフロー、同じセッションドキュメント技術。
長編執筆のコンテキストウィンドウ問題
ほとんどのローカルモデルの実用的なコンテキスト上限は32,000トークン——広告されている128Kではありません。 注意品質はほとんどのモデルで32,000トークンを超えると低下します。128Kトークンでは、多くのモデルがコンテキストウィンドウの最初の4分の1のコンテンツへの正確な参照を失います。小説では、原稿をそのまま貼り付けて次の章を求めることはできません。
Moonshot AIのKimi-K2.6は真の100万トークンのコンテキストウィンドウを提供します。Kimi-K2.6をローカルで実行することはほとんどのライターにとって非現実的です——Q4量子化で約480GBのVRAMが必要です。ローカルで実行可能なモデル（Llama 3.3 70B、Qwen3 32B、Mistral Large）を使うライターには、32Kの実用的上限が制約です。
📍 一文で説明
ほとんどのローカルLLMにおけるコンテキスト遵守の実用的な品質上限は約32,000トークン（〜24,000語）で、これを超えるとモデルは以前のコンテンツへの正確な参照を失い、長い原稿にわたって蓄積する声のドリフトやプロットの不一致を引き起こします。
💬 簡潔に説明
90,000語の小説を128Kのコンテキストウィンドウに収めて、第20章を書きながら第3章で何が起きたかをモデルが覚えていることを期待することはできません。代わりに：モデルが知る必要があることを——キャラクターシート、章サマリー、現在のシーンセットアップを——4,000トークン未満の「セッションドキュメント」に圧縮し、各ライティングセッションの開始時にそれを注入します。
- トークン対語数変換： 英語で1トークン≈0.75語。32Kトークン≈24,000語。128Kトークン≈96,000語（小説1冊分）。
- 注意の劣化： モデルは長いコンテキストウィンドウの早い部分のコンテンツへの信頼できる参照を失います——キャラクター名の誤り、忘れられたプロットポイント、声のドリフト。
- 非対称性： モデルはコンテキストウィンドウの最初（システムプロンプト）と最後を最も良く注意します。長いコンテキストの中間は最も信頼性が低い。
- 解決策としてのセッションドキュメント： モデルが必要とするすべてのものを短い構造化ドキュメントに圧縮します。開始時に注入。シーンを生成。セッションを終了。リセット。更新されたドキュメントで新鮮に始めます。
⚠️Warning: 原稿全体をコンテキストに貼り付けないでください。10,000語を超える原稿を貼り付けると、コンテキストドリフトが起きます——モデルは初期のキャラクター詳細を忘れ、確立されたプロットポイントと矛盾し、一般的なレジスターに戻ります。代わりにセッションドキュメント技術を使ってください。
セッションドキュメント技術
このセクションのセッションドキュメント技術は、複数の長編プロジェクト（90,000語の文学小説1作、脚本草稿2作）での執筆作業でテストされました。4,000トークンのサイズ、シーンごとの生成リズム、連続性チェックのタイミングはすべて、その執筆作業中に観察された失敗パターンから来ています。
セッションドキュメントは原稿の隣に保管するプレーンテキストファイルです——モデルが一貫したコンテンツを生成するために知る必要がある、小説の圧縮された状態。 3つのセクションがあります：アクティブなキャラクターシート、章サマリー、現在のシーンセットアップ。
セッションドキュメントテンプレート
“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS **[Character Name]** Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] **[Character Name 2]** [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
- キャラクターシート——アクティブなキャラクター1人あたり150語を目標。 支配的特性、矛盾する行動、話し言葉のレジスター、他のアクティブなキャラクターとの主要な関係を含めます。
- 章サマリー——完成した章ごとに100〜150語を目標。 焦点：何が起きたか、キャラクターの関係が何が変わったか、読者が今知っている情報、章が空間的・感情的にどこで終わったか。
- 現在のシーンセットアップ——具体的で簡潔。 POV、シーンの目的、着地する感情的ビート、語数上限を指定します。
- セッションドキュメントのサイズ——4,000トークン（〜3,000語）未満を目標。 このサイズを超えるドキュメントは生成自体に使われるべきコンテキストスペースを消費します。
- 各セッション後に更新。 シーンを生成した後、関連する章サマリーに1〜2文を追加し、変更されたキャラクターシートのエントリを更新します。
💡Tip: セッションドキュメントを原稿の隣のプレーンテキストファイルに保管します。Ollamaでは、セッションドキュメントをSYSTEMブロックに持つModelfileを作成し、各セッション前に更新できます。SillyTavernでは、各小説セッションの開始時にシステムプロンプトフィールドに貼り付けます。
小説執筆ワークフロー
ローカルLLMを使った小説執筆ワークフローには4つのフェーズがあります：アウトライン、章ビートシート、シーン生成、リビジョンパス。 各フェーズは異なるプロンプト構造を使います。
- フェーズ1——アウトライン： 章レベルのアウトラインを生成します（10〜30章、1章1文：何が起きるか、何が変わるか）。プロンプト例：「ジャンル：[ジャンル]。主人公：[名前＋核心的な傷]。中心的な葛藤：[1文で]。20章のアウトラインを書く——1章1文、各文はシーンと変化を名指しする。」進む前にアウトラインを確認・編集します。
- フェーズ2——ビートシート： 各章エントリをシーンレベルのビートシートに展開します（1章あたり3〜8シーン）。
- フェーズ3——シーン生成： セッションドキュメント＋現在のシーンのビートを使って、1シーンずつ生成します。生成し、確認し、原稿に貼り付け、セッションドキュメントを更新。繰り返します。
- フェーズ4——リビジョンパス： 章を完成させた後、特定のシーンにターゲットを絞ったリビジョンプロンプトを実行します。フィクションライター向けローカルLLMプロンプトを参照。1生成呼び出しで1シーン以上のリビジョンを求めないこと。
💡Tip: アウトラインとビートシートは原稿とは別のファイルに保管します。別々のファイルは、もう一方を上書きせずに任意の部分を再生成でき、現在のシーンセットアップに関連するビートシートエントリのみを貼り付けられます。
脚本ワークフロー
ローカルLLMを使った脚本作業は、小説執筆と同じセッションドキュメントとビートシート技術を使いますが、2つの追加があります：システムプロンプトのフォーマット命令と、ページ生成とは別のステップとしてのシーンヘッダー（スラグライン）生成。
脚本システムプロンプト
“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”
シーンビートからスクリプトページへのプロンプト
“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
- フォーマットはユーザーターンではなくシステムプロンプトで。 フォーマット命令をシステムメッセージに置くと、セッション中のすべての生成が命令を繰り返さずにフォーマットに従います。
- Fountain互換出力： FountainはFinal Draft、Highland、WriterDuet、その他多くのツールがサポートするスクリプト用プレーンテキストマークアップフォーマット。「Fountain-compatible plain text」の生成を求めると、脚本ソフトウェアに直接インポートできる出力が得られます。
- スラグラインを先に： シーンコンテンツを生成する前に、スラグライン（INT./EXT. 場所——昼/夜）を別の1行プロンプトとして生成します。
- ダイアログパス： アクションラインを生成した後、別のダイアログパスを実行：「アクションラインは設定されました。このシーンで[キャラクターA]と[キャラクターB]のダイアログを書いてください。ダイアログタグなし。5〜8回の交換。」
- ページ数管理： 標準的な脚本ページはアクションとダイアログ合わせて約55〜60語。語数上限キャリブレーション：1ページ≈60語、2ページ≈120語、3ページ≈180語。
💡Tip: ビートシートファーストの規律は小説執筆よりも脚本でより重要です。脚本のシーンは特定の構造的機能（セットアップ、対立、決定、逆転）と特定のページ目標を持ちます。ビートシートなしでページを生成すると、長さと構造的目的が逸脱したシーンになります。
長編作業のシーン生成テンプレート
長編シーン生成には、プレフィックスとしてのセッションドキュメントとアクションとしての1つのシーンプロンプトが必要です。 以下のテンプレートは、セッションドキュメントがすでにシステムメッセージまたは最初のユーザーターンにあることを前提とします。
📍 一文で説明
長編フィクションで最も信頼できる生成パターン：システムプロンプトにセッションドキュメント→ユーザーターンに単一のシーンプロンプト→確認→セッションドキュメントを更新→繰り返し、1セッション1シーン。
💬 簡潔に説明
モデルが次のシーンを一貫して書くために知る必要がある3つのこと：これらのキャラクターが誰か（キャラクターシート）、すでに何が起きたか（章サマリー）、このシーンが何をする必要があるか（シーンセットアップ）。ちょうどそれら3つを渡し、それ以上は渡さない。シーンを生成し、原稿に貼り付け、変化したことを反映してセッションドキュメントを更新。繰り返します。
小説シーン生成プロンプト
“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”
連続性チェックプロンプト
“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”
💡Tip: 連続性チェックプロンプトは各シーンではなく、章の移行時に使います。章の移行（場所、時間、またはPOVキャラクターが変わる場所）が連続性の破綻が最も頻繁に起き、チェックが効果を発揮する場所です。
ライター向けツール統合
OllamaはローカルホストでOpenAI互換APIを公開しており、成長しているライター向けツールのエコシステムが接続しています。 以下の統合は最も確立されたオプションを示します。
| ツール | 連携方法 | 用途 |
|---|---|---|
| Obsidian | CopilotプラグインまたはSmart ConnectionsプラグインでOllama APIに接続。詳細はObsidian＋ローカルLLMプラグインを参照。 | ノート＋原稿にObsidianをすでに使っているライター；同じアプリでシームレスに生成 |
| Scrivener | Ollama API経由の外部スクリプト→ドキュメントに貼り付け | Scrivenerで小説を構成するライター；AI草稿を既存のプロジェクト構造に貼り付け |
| VS Code | Continue.dev拡張機能→Ollamaバックエンド | コードエディタに慣れているテクニカルライターとゲームナラティブデザイナー |
| SillyTavern | OpenAI互換API→Ollama | ロールプレイ形式のフィクションとキャラクターカード駆動の執筆；永続的なキャラクター記憶 |
| プレーンターミナル | `ollama run [model]`またはOllama APIへのcurl | スクリプタブルなワークフロー；最小限のUIオーバーヘッドで最大限のコントロール |
| LM Studio | 組み込みチャットUI＋ローカルサーバーAPI | Ollamaを別にインストールせずGUIモデルマネージャーを望むライター |
| NovelCrafter | 組み込みAI統合；OpenAI互換エンドポイントをサポート（Ollamaに向ける） | 小説専用アプリで章レベルのAI支援を望むライター |
| Plottr | 手動ワークフロー：PlottrでStory構造化、シーン/ビートを外部でOllamaに貼り付け | 構造的プロッティングがワークフローの中心であるプロット重視のジャンルフィクション |
💡Tip: ほとんどのライターに機能する最もシンプルな統合：ObsidianにOllamaを向けたCopilotプラグイン。セッションドキュメントはObsidianノートに、原稿の章は同じVaultに、コンテキストを切り替えることなく同じアプリで直接生成できます。詳細はObsidian＋ローカルLLMプラグインを参照。
長編作業のモデル推薦
長編執筆には短編フィクションとは異なるモデル要件があります。 コンテキスト遵守性、長いセッションにわたる命令追随の一貫性、複数の生成呼び出しにわたって声を維持する能力が意思決定に関連する要素です。すべてのユースケースにわたるモデル景観については、ローカルLLMベスト2026を参照。
| タスク | おすすめモデル | 理由 |
|---|---|---|
| 小説執筆（主要） | Llama 3.3 70B | マルチセッション長編作業での最良のコンテキスト遵守性と命令追随；最も一貫した声 |
| 脚本作業 | Llama 3.3 70BまたはMistral Large | 複雑なキャラクターダイナミクスにはLlama 3.3；Fountain出力での一貫したフォーマット遵守にはMistral Large |
| ビートシート/アウトライン生成 | Qwen3 32B | 強い構造的生成；番号付きリストと制約の多いアウトラインプロンプトに確実に従う |
| ダイアログパス | Command R+ 104B | 長い交換にわたる最良の自然な話し言葉レジスターとキャラクター声の差別化 |
| リビジョン（構造的） | Llama 3.3 70B | 書き直し命令で具体的な名前付き構造的制約に従うのが最良 |
| 成熟した/暗いフィクション | Hermes 3 Llama 3.3 70B | Llama 3.3 70Bと同じベース；アンセンサードファインチューン；長編作業での同一のコンテキスト遵守性 |
よくある間違い
- 原稿全体をコンテキストに貼り付ける。 128Kのコンテキストウィンドウでも、注意品質は32Kトークンを超えると著しく低下します。セッションドキュメント技術を使ってください。
- モデルにオープンエンドのドキュメントを「継続」させる。 「小説を続けて」はドリフトを生みます。「次のシーンを書いて：[特定のセットアップ、POV、語数上限]」は一貫した境界付き出力を生みます。
- 脚本にビートシートがない。 シーンビートなしでスクリプトページを生成すると、長さと構造的機能が逸脱したページになります。ビートシートを常に最初に生成してください。
- セッションドキュメントの更新を無視する。 セッションドキュメントを更新しないと、数セッション以内に不整合が生じます。
- 1セッションで複数のシーンを生成する。 複数シーン生成は最初のシーンは良く、その後は各シーンの一貫性が低下します。1セッション1シーン；リセットして再注入します。
ソース
- Llama 3.3 70B 長コンテキストベンチマーク — Meta AI Research
- Qwen3 32B テクニカルレポート（コンテキストウィンドウベンチマーク含む） — Alibaba Cloud / Qwen Team
- Lost in the Middle: How Language Models Use Long Contexts — Stanford NLP Research
- Fountain脚本フォーマット仕様 — Fountain.io
- Ollama APIドキュメント — Ollama
よくある質問
ローカルLLMは完全な小説を書けますか？
ローカルLLMは完全な小説の散文を生成できます——しかし構造的・編集的な知性はライターから来なければなりません。モデルは特定のセットアップでプロンプトされたときにシーンを生成します；自律的に計画、評価、テーマ的な決定を行いません。ローカルLLMを執筆ツールとして使うライターは「すでに書き方を知っているシーンのための非常に高速な初稿生成器」と説明します。
信頼できる最大のコンテキストウィンドウはどれくらいですか？
実際には、Llama 3.3 70BやQwen3 32Bを含むほとんどのローカルモデルで約32,000トークン（〜24,000語）まで信頼できる注意品質を期待できます。これを超えると、モデルはコンテキストの早い部分のコンテンツへの正確な参照を失い始めます。セッションドキュメント技術は作業コンテキストを4,000〜6,000トークン未満に保ちます。
小説の途中でモデルがキャラクターの声を変えるのを防ぐには？
声のドリフトには2つの原因があります：古くなったセッションドキュメントとコンテキストの希薄化。修正：キャラクターシートをシステムメッセージに置き、重要なアークの瞬間の後にシートを更新し、各セッションコンテキストのトップセクションに収まるように簡潔に保ちます。
ScrivenerをローカルLLMで使えますか？
ネイティブには使えません——Scrivenerには外部API呼び出しのプラグインシステムがありません。最も一般的なワークフロー：Ollamaで生成（ターミナルまたはコンパニオンスクリプト経由）、出力をコピー、関連するScrivenerドキュメントに貼り付けます。
脚本にはOllamaとクラウドAIどちらが良いですか？
成熟したコンテンツ（暴力、暗い心理、道徳的に複雑なキャラクター）を生成する必要がある脚本家には、Llama 3.3 70BまたはHermes 3を使ったローカルOllamaの方が信頼できます——クラウドモデルはドラマチックなスクリプトに頻繁に現れる特定のコンテンツを拒否します。フォーマットの一貫性については、システムプロンプトにフォーマット命令があれば両方が同等のパフォーマンスを発揮します。
特定のキャラクターのように聞こえるダイアログを生成するには？
3ステップのアプローチ：(1) キャラクターの話し言葉レジスターをセッションドキュメントに追加します。(2) セッション開始時にキャリブレーションステップとして中立的なコンテキストでそのキャラクターのサンプルダイアログ3〜5行を生成します。(3) ダイアログプロンプトでこれらのサンプル行を例として使います：「これらの例と同じレジスターでダイアログを書いて：[貼り付け]。」
小説執筆のためにローカルLLMにGPUが必要ですか？
GPUは生成速度を大幅に加速しますが必須ではありません。Apple Silicon（M3以降）では、ユニファイドメモリアーキテクチャのおかげでMacBook Pro 16GBでもQwen3 14Bを快適に実行できます。24GB VRAMの専用NVIDIA GPU（RTX 4090、RTX 3090）は使用可能な生成速度で70Bモデルを実行できます。
Final Draftや他のプロの脚本ソフトウェアでローカルLLMを使えますか？
直接は使えません。Final Draftには外部API統合がありません。ワークフロー：OllamaでFountainプレーンテキスト形式でスクリプトページを生成し、組み込みインポーター（ファイル→インポート→Fountain）でFinal Draftにインポートします。Highland、WriterDuet、Fade InはすべてFountainインポートをネイティブにサポートしています。
小説執筆にKimi-K2.6をローカルで使えますか？
Kimi-K2.6は真の100万トークンのコンテキストウィンドウを持ちますが、ほとんどのライターにとってローカルで実行するのは非現実的です（Q4量子化で約480GB VRAM）。完全にローカルなワークフローでは、ローカルで実行可能なモデルのセッションドキュメント技術が1Mの上限なしで小説の長さの作業を処理できます。
出版社はAI支援の原稿についてどう感じていますか？
混在しており進化中です。ほとんどの主要なフィクション出版社は提出された原稿における重大なAI使用の開示を要求しています；一部は完全に禁止しています。重大な人間によるリビジョンを伴う執筆ツールとしてローカルLLMを使うライターは通常AIをコーオーサーではなくツールとして説明し、ほとんどのポリシーはこれを受け入れます。提出前に特定の出版社のポリシーを確認してください。
ローカルLLMを使って小説や脚本を執筆する際に個人情報保護法は関係しますか？
完全にローカルなモデル（自分のハードウェア上のOllama、クラウドAPIなし）では、個人データは外部サーバーに送信されません。実在する人物の個人情報（氏名、経歴情報）をプロンプトに含める場合は個人情報保護法の原則（目的外利用禁止、安全管理措置）が適用される可能性があります。実在する個人に関係のないフィクションコンテンツの場合、完全ローカルLLMワークフローは一般的に問題を引き起こしません。
日本でローカルAIモデルを使って性的または暴力的なコンテンツを書く際の法的制限は？
合意のある成人キャラクターによる成人向けフィクションには、AIに特化した規制はありません。改正児童買春・ポルノ禁止法は未成年者の性的描写を禁止しています——これは人間かAIモデルがテキストを生成したかに関係なく適用されます。刑法175条はわいせつ物頒布を規制しています。法的責任はユーザーにあります。