メインコンテンツへスキップ
PromptQuorum人のために設計。 AI向けに構造化。
ホーム/ローカルLLM活用
Creative & Roleplay

ローカルLLMで小説・脚本を執筆する：10万語以上のワークフロー完全ガイド

·15分で読めるHans Kuepper 著 · PromptQuorum創設者 · オープンウェイト／オープンソースAIの発見エンジン

長編フィクションでローカルLLMを使う際の主な課題はコンテキスト管理です：1回の生成は約32Kトークンで計画し、原稿全体ではなく圧縮した「セッションドキュメント」（キャラクターシート、章サマリー、現在のシーン設定）を渡して、1シーンずつ生成します。

重要なポイント

  • コンテキストウィンドウの計画目安：掲げられているのは128K〜262,144トークン、計画は約32K。 モデルは長い入力の中間を使う信頼性が下がる（「Lost in the Middle」）ため、1回の生成は約32Kトークン（〜24,000語）で計画し、原稿全体ではなくセッションドキュメント技術を使ってください。
  • セッションドキュメント技術がコアスキル。 圧縮テキストファイルを維持します：アクティブなキャラクターシート（各キャラクター150語）、章サマリー（完成した章ごとに100〜200語）、現在のシーンのセットアップ。各生成セッションの開始時に注入します。
  • 1セッションに1シーン生成。 増大するドキュメントの継続を求めるのではなく、1セッションにつき1シーン（200〜600語）を生成します。1セッション1シーンはコンテキストドリフトを減らし、一貫した声を保つ助けになります。
  • 脚本はビートシートファースト。 スクリプトページを生成する前に、シーンレベルのビートシートを生成します。ビートシートを各ページ生成の足場として使います。
  • 実行できるモデルを選び、自分のシーンで試してください。 27B〜31Bクラスの密モデル（Qwen3.6 27B、Gemma 4 31B）とLlama 3.3 70Bが一般的な出発点です。PromptQuorumはどれも小説向けに評価しておらず、公開されている創作ライティングのリーダーボードもモデルの順位付けが一致しません。
  • Ollama＋プレーンテキストライティングツールは信頼できる統合です。 Scrivener、Obsidian、VS Codeは原稿を保持でき、OllamaはAPIを通じてモデルを提供し、コンパニオンアプリやスクリプトから呼び出せます。
  • 拒否の少ないモデル（Hermes 4 70B）はセットアップ変更なしに組み込めます。 成熟したフィクション向けには、Ollamaのモデルを切り替えるだけ；セッションドキュメントと生成技術は同一です。用途に合うか、モデルごとのライセンスを確認してください。
言語を選択:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

ローカルLLMを小説・脚本のワークフローに統合することで、シーン草稿・ビートシート・ダイアログパス・リビジョンをインターネット接続なし、クラウドロギングなし、利用制限なしで実行できます。本ガイドでは完全なワークフローを解説します：タスク別のおすすめモデル、長編作業のためのコンテキストウィンドウ管理、章の足場構築、シーン生成、そしてローカルLLMをライティングソフトウェアと連携させるツール。

ローカルLLMで小説・脚本を執筆する：10万語以上のワークフロー完全ガイド

クイックファクト

  • モデルの出発点（モデルカードより）： Qwen3.6 27B（密、Apache-2.0、コンテキスト262,144トークン）、Gemma 4 31B（密、Apache-2.0、コンテキスト256K）、Llama 3.3 70B（密、コンテキスト128K、Llama 3.3 Community License）。
  • コンテキストウィンドウの計画上限： 1回の生成あたり〜32Kトークン（〜24,000語）；モデルは128K〜262,144トークンを掲げますが、これは上限であり品質の保証ではありません。
  • セッションドキュメントのサイズ： 4,000トークン未満を目標（キャラクターシート＋章サマリー＋現在のシーンセットアップ）。
  • シーン生成の目標： 1生成呼び出しあたり200〜600語；複数の連続プロンプトで長いシーンを生成。
  • 脚本フォーマット： Fountain形式の出力命令とOllamaを組み合わせてスクリプトフォーマットのテキストを生成。
  • Ollamaと連携するライティングツール： Scrivener（出力を貼り付け；文書化されたプラグインAPIなし）、Obsidian（プラグインまたはスクリプト経由）、VS Code（Continue.dev経由）、ターミナル。
  • 拒否の少ないオプション： 成熟したフィクション向けHermes 4 70B（Llama-3.1-70Bベース）；同じワークフロー、同じセッションドキュメント技術。

長編執筆のコンテキストウィンドウ問題

モデルがはるかに大きなウィンドウを掲げていても、1回の生成あたり約32Kトークンで計画してください。 これはPromptQuorumの慎重な計画ルールであり、測定された上限ではありません：長いコンテキストの研究（Liu et al.「Lost in the Middle」）では、モデルは長い入力の先頭と末尾の情報を中間の情報より確実に使い、入力が長くなるほど品質が下がり得ることが報告されています。新しいモデルはさらに大きなウィンドウを掲げており——Qwen3.6 27Bはネイティブで262,144トークン、Gemma 4 31Bは256K——ご自身のモデルで試す必要があります。小説では、ここまでの原稿をそのまま貼り付けて次の章を求める方法が依然として最も信頼できず、長いコンテキストはKVキャッシュが増えるためメモリも多く消費します。

Moonshot AIのKimi-K2.6は256Kトークン（262,144）のコンテキストウィンドウを掲げており、上記のモデルと同じクラスですが、総パラメータ約1兆（アクティブ320億）のMixture-of-Expertsモデルで、ネイティブint4の重みで提供されています。4ビットでも重みだけで約500GBになり（PromptQuorumの推定：1兆パラメータ×0.5バイト）、ノートPC向けではなくサーバークラスのモデルです。セッションドキュメント技術とシーンごとの生成は、コンテキストサイズを問わずローカルで実行可能なモデルに適用できます。

📍 一文で説明

ローカルLLMにおけるコンテキスト遵守の慎重な計画上限は、1回の生成あたり約32,000トークン（〜24,000語）です——これを超えると、長いコンテキストの研究では以前の内容の利用が不安定になると報告されており、長い原稿にわたって声のドリフトやプロットの不一致として現れることがあります。

💬 簡潔に説明

原稿全体がコンテキストウィンドウに収まるからといって、第20章を書きながら第3章で何が起きたかをモデルが確実に覚えているとは期待できません。代わりに：モデルが知る必要があることを——キャラクターシート、章サマリー、現在のシーンセットアップを——4,000トークン未満の「セッションドキュメント」に圧縮し、各ライティングセッションの開始時にそれを注入します。モデルは、今生成しているシーンに関係することだけを知っていれば十分です。

  • トークン対語数変換： 英語で1トークン≈0.75語（目安）。32Kトークン≈24,000語。128Kトークン≈96,000語（小説1冊分ほど）；262,144トークン≈196,000語。
  • 注意の劣化： モデルは長いコンテキストウィンドウの早い部分のコンテンツへの信頼できる参照を失うことがあります——キャラクター名の誤り、忘れられたプロットポイント、声のドリフト。
  • 非対称性： Lost in the Middleの研究では、モデルは入力の先頭と末尾を最もよく使い、中間の内容を最も不確実にしか使いませんでした。この研究は2023年に利用できたモデルを対象にしているため、同じ傾向を前提とせず現行モデルで試してください。
  • 解決策としてのセッションドキュメント： モデルが必要とするすべてのものを短い構造化ドキュメントに圧縮します。開始時に注入。シーンを生成。セッションを終了。リセット。更新されたドキュメントで新鮮に始めます。
コンテキスト計画：作業上限は32Kトークン（約24,000語）。オープンモデルは128K〜262,144トークンを掲げる。
コンテキスト計画：作業上限は32Kトークン（約24,000語）。オープンモデルは128K〜262,144トークンを掲げる。

⚠️注意: 原稿全体をコンテキストに貼り付けないでください。10,000語を超える原稿を貼り付けると、コンテキストドリフトのリスクがあります——モデルは初期のキャラクター詳細を忘れ、確立されたプロットポイントと矛盾し、一般的なレジスターに戻ることがあります。代わりにセッションドキュメント技術を使ってください。

セッションドキュメント技術

セッションドキュメント技術は、上で説明したコンテキストの制約に基づくPromptQuorumのワークフロー推奨です。PromptQuorumは管理された試験を行っておらず、以下のサイズ（4,000トークン、キャラクターシート1件あたり150語、章サマリー1件あたり100〜150語）は計画上の目安であり、測定された閾値ではありません。

セッションドキュメントは原稿の隣に保管するプレーンテキストファイルです——モデルが一貫したコンテンツを生成するために知る必要がある、小説の圧縮された状態。 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文を追加し、変更されたキャラクターシートのエントリを更新します。

💡ヒント: セッションドキュメントを原稿の隣のプレーンテキストファイルに保管します。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シーン以上のリビジョンを求めないこと。
小説執筆の4フェーズ：アウトライン、ビートシート、シーン生成、リビジョン。
小説執筆の4フェーズ：アウトライン、ビートシート、シーン生成、リビジョン。

💡ヒント: アウトラインとビートシートは原稿とは別のファイルに保管します。別々のファイルは、もう一方を上書きせずに任意の部分を再生成でき、現在のシーンセットアップに関連するビートシートエントリのみを貼り付けられます。

脚本ワークフロー

ローカル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は脚本用のプレーンテキストマークアップフォーマットで、Highland、Fade In、およびFountainアプリ一覧の他のアプリが読み込めます。「Fountain-compatible plain text」の生成を求めると、それらのツールで開ける、または他のツール向けに変換できる出力が得られます（FAQのFinal Draftの質問を参照）。
  • スラグラインを先に： シーンコンテンツを生成する前に、スラグライン（INT./EXT. 場所——昼/夜）を別の1行プロンプトとして生成します。
  • ダイアログパス： アクションラインを生成した後、別のダイアログパスを実行：「アクションラインは設定されました。このシーンで[キャラクターA]と[キャラクターB]のダイアログを書いてください。ダイアログタグなし。5〜8回の交換。」
  • ページ数管理： 1ページあたりの語数に決まった数値はなく、「1ページ＝1分」はあくまで目安です。ご自身の脚本の1ページあたり平均語数を数え、そこから語数上限を設定してください。

💡ヒント: ビートシートファーストの規律は小説執筆よりも脚本でより重要です。脚本のシーンは特定の構造的機能（セットアップ、対立、決定、逆転）と特定のページ目標を持ちます。ビートシートなしでページを生成すると、長さと構造的目的が逸脱したシーンになります。

長編作業のシーン生成テンプレート

長編シーン生成には、プレフィックスとしてのセッションドキュメントとアクションとしての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.”

💡ヒント: 連続性チェックプロンプトは各シーンではなく、章の移行時に使います。章の移行（場所、時間、またはPOVキャラクターが変わる場所）が連続性の破綻が最も頻繁に起き、チェックが効果を発揮する場所です。

ライター向けツール統合

OllamaはローカルホストでOpenAI互換APIを公開しており、成長しているライター向けツールのエコシステムが接続しています。 以下の統合は最も確立されたオプションを示します。

Obsidian

リンク:
obsidian.md
連携方法:
CopilotプラグインまたはSmart ConnectionsプラグインでOllama APIに接続。詳細はObsidian＋ローカルLLMプラグインを参照。
用途:
ノート＋原稿にObsidianをすでに使っているライター；同じアプリでシームレスに生成

Scrivener

リンク:
literatureandlatte.com/scrivener
連携方法:
Ollama API経由の外部スクリプト→ドキュメントに貼り付け
用途:
Scrivenerで小説を構成するライター；AI草稿を既存のプロジェクト構造に貼り付け

VS Code

リンク:
code.visualstudio.com
連携方法:
Continue.dev拡張機能→Ollamaバックエンド
用途:
コードエディタに慣れているテクニカルライターとゲームナラティブデザイナー

SillyTavern

リンク:
github.com/SillyTavern/SillyTavern
連携方法:
OpenAI互換API→Ollama
用途:
ロールプレイ形式のフィクションとキャラクターカード駆動の執筆；永続的なキャラクター記憶
SillyTavernに関する記事（10件）

さらに7件（非表示）

プレーンターミナル

リンク:
—
連携方法:
`ollama run [model]`またはOllama APIへのcurl
用途:
スクリプタブルなワークフロー；最小限のUIオーバーヘッドで最大限のコントロール

LM Studio

リンク:
lmstudio.ai
連携方法:
組み込みチャットUI＋ローカルサーバーAPI
用途:
Ollamaを別にインストールせずGUIモデルマネージャーを望むライター
LM Studioに関する記事（10件）

さらに162件（非表示）

NovelCrafter

リンク:
novelcrafter.com
連携方法:
組み込みAI統合；ヘルプページにLM Studio、Ollama、OpenAI API互換の接続が記載されている
用途:
小説専用アプリで章レベルのAI支援を望むライター

Plottr

リンク:
plottr.com
連携方法:
手動ワークフロー：Plottrで物語を構造化し、シーン/ビートを外部でOllamaに貼り付け（PlottrはAI機能を追加しない方針と表明）
用途:
構造的プロッティングがワークフローの中心であるプロット重視のジャンルフィクション

💡ヒント: ほとんどのライターに機能する最もシンプルな統合：ObsidianにOllamaを向けたCopilotプラグイン。セッションドキュメントはObsidianノートに、原稿の章は同じVaultに、コンテキストを切り替えることなく同じアプリで直接生成できます。詳細はObsidian＋ローカルLLMプラグインを参照。

長編作業のモデル推薦

長編執筆には短編フィクションとは異なるモデル要件があります。 コンテキスト遵守性、長いセッションにわたる命令追随の一貫性、複数の生成呼び出しにわたって声を維持する能力が意思決定に関連する要素です。以下の行は各モデルカードに基づく出発点であり、PromptQuorumはこれらのモデルを小説向けに評価していません。公開されている創作ライティングのリーダーボードもモデルの順位付けが一致しないため、自分のシーンで2つの候補を試してください。Command A+（総パラメータ2,180億、アクティブ250億、Apache 2.0）やMistral Large 3（総パラメータ6,750億、コンテキスト256K、Apache 2.0）のようなサーバークラスのオープンモデルは、一般消費者向けハードウェアの範囲外です。すべてのユースケースにわたるモデル景観については、ローカルLLMベスト2026を参照。

小説執筆（主要）

おすすめモデル:
Qwen3.6 27BまたはGemma 4 31B
理由:
256K以上のコンテキストを掲げるApacheライセンスの27B〜31B密モデル；4ビットで24GB GPUまたは32GB以上のユニファイドメモリに収まるサイズクラス（推定）

脚本作業

おすすめモデル:
Qwen3.6 27BまたはLlama 3.3 70B
理由:
フォーマット遵守は主にシステムプロンプト次第；Fountainの1シーンを2つのモデルで試す。Llama 3.3 70Bは密モデルでコンテキスト128K、4ビットで約40GB必要（推定）

ビートシート/アウトライン生成

おすすめモデル:
Qwen3.6 35B-A3B
理由:
トークンあたり350億パラメータ中30億がアクティブなMixture-of-Experts（Apache-2.0）のため、トークンあたりの生成が速い；アウトライン品質はPromptQuorumが未評価

ダイアログパス

おすすめモデル:
サンプルが合うモデル
理由:
キャラクターのレジスターに合うキャリブレーション行を出したモデルで、ダイアログを別パスとして実行；ダイアログ向けモデルの検証済みランキングはない

リビジョン（構造的）

おすすめモデル:
初稿に使ったモデル
理由:
1回の呼び出しにつき構造的制約を1つ指定するリビジョンプロンプトは、命令追随するどのモデルでも機能；1回の呼び出しにつき1シーン

成熟した/暗いフィクション

おすすめモデル:
Hermes 4 70B
理由:
Llama-3.1-70Bベース；Nous Researchはおおむね中立的なアラインメントと低い拒否率と説明；Llama 3ライセンス；ハイブリッド推論モード

よくある間違い

  • 原稿全体をコンテキストに貼り付ける。 モデルが128K〜262Kのウィンドウを掲げていても、長い入力は使われる信頼性が下がるため、約32Kトークンで計画します。セッションドキュメント技術——圧縮したキャラクターシートと章サマリー——を使ってください。
  • モデルにオープンエンドのドキュメントを「継続」させる。 「小説を続けて」はドリフトを生みます。「次のシーンを書いて：[特定のセットアップ、POV、語数上限]」は一貫した境界付き出力を生みます。
  • 脚本にビートシートがない。 シーンビートなしでスクリプトページを生成すると、長さと構造的機能が逸脱したページになります。ビートシートを常に最初に生成してください。
  • セッションドキュメントの更新を無視する。 セッションドキュメントを更新しないと、数セッション以内に不整合が生じます。
  • 1セッションで複数のシーンを生成する。 複数シーン生成は最初のシーンは良く、その後は各シーンの一貫性が低下します。1セッション1シーン；リセットして再注入します。

ソース

よくある質問

小説執筆でまず試すローカルLLMモデルは？

用途によって最適なモデルは異なり、PromptQuorumはこれらのモデルを小説向けに評価していません。出発点としては、27B〜31Bクラスの密モデル（Qwen3.6 27BまたはGemma 4 31B。どちらもモデルカードで256K以上のコンテキストとApacheライセンスが確認できます）か、実績のある70BクラスのLlama 3.3 70Bが現実的です。ビートシートやアウトラインにはアクティブパラメータが少なく生成が速いQwen3.6 35B-A3Bも選択肢です。ダイアログパスやFountain形式の出力は、ご自身のシーンで2つのモデルを比べて、キャラクターのレジスターやフォーマットに合う方を選んでください。成熟した/暗いフィクションには、拒否の少ないHermes 4 70B（Llama-3.1-70Bベース、Llama 3ライセンス）が同じワークフローで使えます。迷ったら1つの密モデルから始め、特定のタスクで物足りなさを感じたら別のモデルを試すのが実用的です。

ローカルLLMは完全な小説を書けますか？

ローカルLLMは完全な小説の散文を生成できますが、構成と編集の知性は書き手から来る必要があります。モデルは具体的なセットアップを与えられるとシーンを生成しますが、自分で計画したり、評価したり、テーマ上の判断をしたりはしません。すでに書き方が分かっているシーンのための高速な初稿ジェネレーターと考えるのが適切です：白紙の状態からの時間を節約してくれますが、重要な判断はすべて書き手が行います。投稿前に出版社やプラットフォームのAI方針を確認してください（下の出版社の質問を参照）。

信頼できる最大のコンテキストウィンドウはどれくらいですか？

モデルは128Kから262,144トークンを掲げていますが、PromptQuorumは1回の生成あたり約32,000トークン（〜24,000語）で計画することを勧めます。長いコンテキストの研究では、モデルは長い入力の中間を使う信頼性が下がると報告されているためです。これは慎重な計画ルールであり、すべてのモデルについて測定された上限ではないため、ご自身のモデルで試してください。セッションドキュメント技術は作業コンテキストを4,000〜6,000トークン未満に保つので、どの生成呼び出しもその範囲内に十分収まります。

小説の途中でモデルがキャラクターの声を変えるのを防ぐには？

声のドリフトには2つの原因があります：古くなったセッションドキュメントとコンテキストの希薄化。修正：キャラクターシートをシステムメッセージに置き、重要なアークの瞬間の後にシートを更新し、各セッションコンテキストのトップセクションに収まるように簡潔に保ちます。

ScrivenerをローカルLLMで使えますか？

ネイティブには使えません——Scrivener 3にはドキュメント化されたプラグインシステムがなく、3.5.2（2025年12月）までの公式リリースノートにもAI統合の記載はありません：3.4.0のノートには「Scrivener itself contains no AI」とあり、macOSのシステム機能であるAppleのWriting Toolsへの対応が追加されています。一般的なワークフロー：Ollamaで生成（ターミナルまたはコンパニオンスクリプト経由）、出力をコピー、関連するScrivenerドキュメントに貼り付けます。ObsidianをAI執筆レイヤーとして使い、完成した章を最終構成のためにScrivenerにインポートするライターもいます。OllamaのAPIを呼び出して出力をクリップボードにコピーするスクリプトが、ネイティブ統合に最も近い方法です。

脚本にはOllamaとクラウドAIどちらが良いですか？

成熟したコンテンツ（暴力、暗い心理、道徳的に複雑なキャラクター）を生成する必要がある脚本家にとって、ローカルモデルはモデルとその拒否の挙動を自分で制御できる点が利点です——ホスト型モデルの中にはドラマチックな脚本に現れる内容を拒否したり和らげたりするものがあり、ホスト型の方針は時間とともに変わります。Hermes 4 70Bのような拒否の少ないローカルモデルは組み込みの拒否が少ないものの、生成・公開する内容の責任は自分にあります。フォーマットの一貫性は主にシステムプロンプトの指示で決まり、どちらでも機能します。選択は主にコンテンツの制御、プライバシー、コストの問題です。PromptQuorumは脚本向けにホスト型とローカルモデルの出力品質を比較していません。

特定のキャラクターのように聞こえるダイアログを生成するには？

3ステップのアプローチ：(1) キャラクターの話し言葉レジスターをセッションドキュメントに追加します。(2) セッション開始時にキャリブレーションステップとして中立的なコンテキストでそのキャラクターのサンプルダイアログ3〜5行を生成します。(3) ダイアログプロンプトでこれらのサンプル行を例として使います：「これらの例と同じレジスターでダイアログを書いて：[貼り付け]。」

小説執筆のためにローカルLLMにGPUが必要ですか？

GPUは生成速度を大幅に高めますが必須ではありません。Apple Siliconでは、ユニファイドメモリのおかげで16GBのMacBook Proでも小さめのモデル（4ビットでおおむね8Bクラス、推定。macOSが約8GBを使用するため）を実行できます——24GB GPUの機材より遅いものの、生成の合間に出力を読んで評価する執筆ワークフローなら許容範囲です。24GBのNVIDIA GPU（RTX 4090、RTX 3090）は4ビットで27B〜32Bクラスのモデルを収められます（推定）。70Bクラスは4ビットで約40GB以上が必要なため、GPU2枚、48GBカード、64GBのユニファイドメモリ、または速度の落ちるCPUオフロードが必要です。

Final Draftや他のプロの脚本ソフトウェアでローカルLLMを使えますか？

直接は使えません。Final Draftのヘルプセンターによれば、Final Draftは.fountainファイルをインポートできません。推奨されているのは、テキストをプレーンな.txtとして保存し、そのファイルをスクリプトとしてインポートするか、FDXを書き出せるアプリ経由でFDXとして取り込む方法です。HighlandはFountain、FDX、PDFの間で変換でき、Fade InはFountainのインポートとエクスポートに対応しています（Fountainアプリ一覧による）。ワークフロー：OllamaでFountain形式のテキストを生成し、HighlandまたはFade Inで開き、Final Draft用にFDXを書き出します。

小説執筆にKimi-K2.6をローカルで使えますか？

Kimi-K2.6は256Kトークンのコンテキストウィンドウを掲げており、Qwen3.6 27BやGemma 4 31Bと同じクラスですが、総パラメータ約1兆（アクティブ320億）のMixture-of-Expertsモデルで、ネイティブint4の重みを持ちます。重みだけで約500GBになり（PromptQuorumの推定）、マルチGPUサーバーか非常に大きなユニファイドメモリの機材が必要で、一般消費者向けハードウェアでは非現実的です。完全にローカルなワークフローでは、27B〜70Bの密モデルとセッションドキュメント技術で、1兆パラメータのモデルなしでも小説の長さの作業を処理できます。

出版社はAI支援の原稿についてどう感じていますか？

方針は出版社やプラットフォームによって異なり、2026年時点でも変化し続けているため、投稿前に該当するものを確認してください。Amazon KDPは、テキスト・画像・翻訳がAI生成の場合に申告を求め、AIツールで作成したコンテンツは大幅に編集してもAI生成として扱います。自分で書いた文章をAIが編集や推敲を手伝っただけなら「AI支援」で、申告は不要です（2023年9月にPublishers Weeklyが報じたAmazonの規則による）。一部の雑誌はAIが関与した作品を一切受け付けません——Clarkesworldは「AI」執筆ツール（ChatGPTなど）の使用に関する声明で、これらのツールで翻訳・執筆・開発・支援された投稿は一切検討しないと記しています。ローカルLLMが生成したシーンのテキストはKDPの「AI生成」の定義のような基準に該当するため、求められる場面では申告してください。これは一般的な情報であり、法的助言ではありません。

100万トークン級のコンテキストにはどんなハードウェアが必要ですか？

Qwen3.6 27BとQwen3.6 35B-A3Bはネイティブで262,144トークンのコンテキストを掲げており、モデルカードによればYaRNスケーリングで約1,010,000トークンまで拡張できます。長いコンテキストでは重みに加えてKVキャッシュ用のメモリが必要なため、100万トークンでの実行には一般的な消費者向け環境よりはるかに多くのメモリが必要です。PromptQuorumは必要量を測定していません。この記事のセッションドキュメント技術は、まさにこのギャップのために設計されています——100万トークンのウィンドウに頼らずに一貫した長編出力を得るためです。

ローカルLLMを使って小説や脚本を執筆する際に個人情報保護法は関係しますか？

完全にローカルなモデル（自分のハードウェア上のOllama、クラウドAPIなし）では、個人データは外部サーバーに送信されません。実在する人物の個人情報（氏名、経歴情報）をプロンプトに含める場合は個人情報保護法の原則（目的外利用禁止、安全管理措置）が適用される可能性があります。実在する個人に関係のないフィクションコンテンツの場合、完全ローカルLLMワークフローは一般的に問題を引き起こしません。

日本でローカルAIモデルを使って性的または暴力的なコンテンツを書く際の法的制限は？

合意のある成人キャラクターによる成人向けフィクションには、AIに特化した規制はありません。改正児童買春・ポルノ禁止法は未成年者の性的描写を禁止しています——これは人間かAIモデルがテキストを生成したかに関係なく適用されます。刑法175条はわいせつ物頒布を規制しています。法的責任はユーザーにあります。

← ローカルLLM活用 に戻る

MCP