なぜAIは第10章でプロットを忘れるのか？長編執筆のコンテキスト管理ガイド

最初の5章を書いている間は、理想の共同執筆者を見つけたような気分になります。AIは主人公のジョナスが短文で話し左利きであること、港町に3日間雨が降り続いていること、そして情報屋のイライが第4章のラストで桟橋で命を落としたことを正確に覚えています。

ところが第10章に入り、やり取りが80往復を超えたころ、アパートのキッチンで緊迫した対峙シーンを書かせてみると、数秒後に出てきた原稿にはこう書かれています。ジョナスが右手を伸ばしてパン切り包丁を取り、マラが「積み荷目録を確かめるためにイライに電話しよう」と持ちかけるのです。

思わず手が止まり、チャット欄に「ジョナスは左利きだし、イライは第4章で死んだはず」と打ち込みます。AIはすぐに謝って書き直してくれます。しかし2章進むと、今度はマラの妹がいとこにすり替わっています。重くなったスレッドに嫌気がさして「新しいチャット」を開いたものの、真っ白な入力欄を前にして途方に暮れます。第10章の最初の1行を書くために、1万5千字におよぶキャラクター設定シート、世界観メモ、第9章までのあらすじをフォルダから探し出し、手作業で貼り直さなければならないからです。

ChatGPTやClaudeで長編小説やノンフィクションを書いたことがある人なら、ほぼ例外なく第8章から第12章のあたりでこの壁にぶつかります。

透明性に関する注記： 私たちは、エディタの内部にAIチャットを統合した執筆ワークスペース「Muses」を開発しています。本記事は開発チームが執筆しており、製品に関する記述はすべて現在利用できる実際の機能に基づいています。

まず結論から

• 「コンテキストウィンドウが大きい」ことと「最後まで設定を忘れない」ことは別問題です。 ウィンドウのサイズは一度に入力できる容量の上限であって、注意力の保証ではありません。スレッドが伸びるほど、中盤に挟まれた初期の設定は重みが薄れます。
• 1冊の本を1つのチャットスレッドで書き続けると、ボツ原稿が確定稿を汚染します。 没にした展開や3回書き直した第7章の別案が最終稿と同じタイムラインに並ぶため、どの設定が採用されたのかモデルには見分けがつきません。
• 長編が破綻しない鍵は、「資料室」と「作業台」を分けることです。 確定した章、キャラクター設定資料、プロットは会話の外に置き、チャットスレッドは目の前の1シーンだけを扱う場所にする必要があります。
• 長編のコンテキストは更新頻度に応じて4層に分けると安定します。 常時読み込む作品概要、構造を示すプロット図、必要なときだけ引き出す設定・過去章のアーカイブ、そして現在の段落を磨く清潔な作業台の4つです。
• AIがプロジェクトの内部に常駐していれば、人間がコピペで記憶を運ぶ必要はなくなります。 AI自身が過去の章を検索し、素材やマインドマップを読み、階層化されたメモリを維持するため、書き手は物語を前に進めることに集中できます。

チャットが長くなるほど、AIが「設定を忘れる」4つの理由

AIが設定を忘れるのは「文字数上限を超えたからだ」と思われがちです。しかし実際には、20万トークンや100万トークンのコンテキストウィンドウを謳うモデルであっても、1つの果てしないチャットにすべてを詰め込み続ければ、第10章前後で必ずと言っていいほど設定の食い違いが起きます。その背景には4つの仕組み上の理由があります。

1つ目は、長文の中盤で注意力が落ちる現象です。 言語モデルはコンテキストの「冒頭」と「直近の数往復」に最も強く注意を向けます。40往復前に一度だけ触れた「古傷のせいで右手首が動かず、普段は左手を使う」という一文は、プロンプト中盤の注意力が届きにくい谷間に埋もれてしまいます。現在のターンでその設定を改めて引き出さない限り、モデルは一般的な文章の統計的な慣性に引っ張られ、「右手を伸ばした」と書いてしまいます。

2つ目は、チャット履歴に「却下された並行世界」が混ざり続けることです。 長編の執筆には試行錯誤がつきものです。第4章で「イライに死を偽装させるか」を5往復ほど相談した末にやはり退場させることにしたり、第7章の結末を3パターン試したりすることがあります。しかし単一のチャットスレッドでは、ボツにした分岐もすべて履歴に残ります。モデルが読んでいるのは清書された原稿ではなく、矛盾するメモが散乱した会議室そのものです。

3つ目は、スライディングウィンドウや内部要約の過程で伏線が削られることです。 会話が長くなると、多くのチャットツールは応答速度とトークン消費を抑えるために古い発言を切り捨てるか、前半のやり取りを内部で要約します。要約は大筋（「第4章：桟橋での衝突、ジョナスが帳簿を回収」）を残すのは得意ですが、物理的なディテールや伏線（「帳簿の17ページ目が破り取られている」「懐中時計は3時15分で止まっている」）を簡単に落としてしまいます。要約から消えた伏線は、後の章で回収できません。

4つ目は、新しいチャットを開いた瞬間にすべてがゼロに戻ることです。 混濁した古いスレッドに見切りをつけて新規チャットを開くと、ノイズは消えますが、作品の世界観まで一緒に消えてしまいます。結局、何十個ものファイルや過去ログを掘り返して「これまでのあらすじ」を手作業で組み立て直すことになり、執筆そのものよりコンテキストの運搬に時間を奪われてしまいます。

1つの巨大チャットに頼らない：長編コンテキストの4層構造

第30章になっても第3章と同じ解像度を保つために必要なのは、100万字を詰め込めるチャット欄ではありません。情報がどれくらいの頻度で変わるか、そして今のシーンで本当に必要かによってコンテキストを4つの層に分けることです。

長編の破綻を防ぐコンテキスト構造は、次の4層で成り立ちます。

この4層構造によって、長編AI執筆の根本的なジレンマが解消されます。全編共通のルールは毎回確実に伝わり（第1層）、第3章の具体的な事実は必要なときだけ正確に参照でき（第3層）、第10章の1段落を推敲するときには無関係な50ページ分の雑談に邪魔されない静かな作業台（第4層）が保たれるのです。

Musesの中で4層のコンテキストはどう動くか

一般的な「テキストエディタ＋外部チャット画面」の組み合わせでは、この4層をフォルダ分けとコピー＆ペーストで人間が維持しなければなりません。Musesでは、この4層そのものがワークスペースの標準構造になっています。左側にプロジェクトと素材、中央に原稿またはマインドマップ、右側にAIチャットが並びます。

第1層：階層化された永続メモリ（ユーザーメモリ＋プロジェクト概要＋プロジェクト詳細）

Musesの永続メモリは、過去のチャット履歴をそのままプロンプトに流し込むのではなく、役割の異なる3つの層に分けて管理します。

• ユーザーメモリ（User Memory）：プロジェクトをまたいで引き継がれる書き手の好みです。文体のリズム、使用言語、表記ルール、避けたい常套句などを保持します。
• プロジェクト概要（Project Overview）：現在の作品における常駐ベースです。基本設定、叙述の視点、主要キャスト、作品固有のルール、現在の執筆段階をまとめます。
• プロジェクト詳細（Project Details）：プロジェクト内の特定のテーマ（サブプロットの時系列や組織の掟など）ごとにタイトルを付けて保存する独立したノートです。プロジェクト内の特定の記事や素材に紐づけることができ、物語の進行に合わせて作成・更新・アーカイブできます。

プロジェクト内で新しいチャットを始めると、最初のターンでユーザーメモリとプロジェクト概要が自動的に注入されるため、毎回前置きを貼り付ける必要がありません。会話の途中で特定の背景が必要になれば、AIが検索ツール（grep）やメモリツール（memory）を使って関連するプロジェクト詳細を読み込み、更新します。エディタ内の自動補完や音声入力でも、ユーザーメモリ、プロジェクト概要、そして現在のドキュメントに紐づいた有効なプロジェクト詳細が参照されます。

AIが何を記憶しているか確かめたいときは、エディタでメモリ表示を開けば、ユーザーメモリ、プロジェクト概要、有効なプロジェクト詳細を一覧で確認できます。途中で設定を変更した場合は、チャットでAIに伝えるか、**「記憶を更新」**ワークモードに切り替えてプロジェクトの内容に沿うよう整理させることができます。

第2層・第3層：同じプロジェクト境界にある記事・素材・マインドマップを必要なときだけ呼び出す

執筆中の各章（記事）、設定資料（素材ライブラリの記事、txt / md / docxファイル、PDF、Webリンク、画像）、そしてプロット構成（マインドマップ）は、すべて同じプロジェクトの内部に収まっています。

1. @で今回のシーンに必要な資料だけを指名する。 第10章のキッチンの口論を書くときは、フォルダを開いてコピペする代わりに、チャット入力欄で@（半角@・全角＠の両方に対応）を入力し、『ジョナス設定シート』と『第4章：桟橋』を選択します。1回のメッセージにつき最大5件までプロジェクト内の記事や素材を添付できます。
2. 書く前にAI自身に過去章を検索させる。 第3章で鍵をどこに隠したか、あるいは脇役の名前をどう表記したか曖昧なときは、そのままAIに調べさせます。AIのgrepツールはプロジェクト内の保存済み記事、素材（素材記事、テキストファイル、URL、PDF要約、マインドマップのノードトピックを含む）、メモリを横断検索し、readツールで該当するブロックや行だけを正確に読み取ります。
3. マインドマップの構成と本文をつなぐ。 AIはプロジェクト内のマインドマップをノードアンカー付きの構造化アウトラインとして読み取れます。既存のマインドマップに対してAIが構成変更を提案すると、キャンバス上でノードごとに変更箇所がハイライトされ、書き手が1つずつ承認・却下を確認してから反映されます。

第4層：マルチセッションタブ＋選択範囲の推敲＋行内Diffレビュー

1つのチャットが80往復の泥沼になるのを防ぐため、MusesはWeb版とデスクトップ版の両方でマルチセッション対応のチャットワークスペースを備えています。

• 作業ごとにタブを分け、文脈の混線を防ぐ。 チャットパネルで2つ目の会話を開くと、上部にセッションタブ、新規チャットボタン、履歴メニューが表示されます。片方のタブで第2幕のプロット構成を検証しながら、もう片方の清潔なタブで第10章のセリフを磨くといった並行作業ができるため、ボツになったブレスト案が本文の推敲に紛れ込みません。
• ページ上で選択し、その場で行内Diffをレビューする。 引き締めたい3段落を本文中で選択すると、その選択範囲が自動的にメッセージに添えられます。AIが既存の記事を編集するとき、元の原稿がいきなり上書きされることはありません。元の文の上に取り消し線と追加箇所が並ぶ行内Diffとして表示されます。もしAIが「左手」を「右手」に変えようとしても、赤い取り消し線ですぐに気づき、その項目だけ**「却下」して残りの良い修正だけを「承認」**できます。承認した直後なら、本文の編集を続ける前であればワンクリックで承認を取り消すことも可能です。デスクトップ版でローカルプロジェクトを扱う場合も、サインインしてオンラインであれば、同じ横並びチャット、プロジェクト検索、行内レビューがそのまま使えます。

通常のチャット画面で今日から実践できる4つの習慣

現在ChatGPTやClaudeの標準画面で長編を書いている場合でも、「1つのチャットで最後まで書き切る」やり方を改めるだけで、第10章での設定崩壊は今日から大幅に減らせます。

1. チャット履歴を「設定の原本」にしない

チャット画面はあくまで計算用紙であり、正式なカノン（正史）は手元の原稿と設定ファイルだけです。チャットの中で新しい展開やキャラクターの細部が決まったら、その場ですぐにプロット表や設定シートへ書き写し、古い記述を更新してください。30往復前に出した3つの案のうちどれを心の中で採用したかを、モデルが勝手に察してくれると期待してはいけません。

2. 1章書き終えるごとに、150字の「章引き継ぎカード」を作る

第10章を書くときに第1〜9章の本文を丸ごと貼り付けるのは非効率ですし、かといって「第9章：ジョナスとマラが口論する」といった一行要約では情報が足りません。章が確定したら、2分だけ時間を取って物理的・物語的な状態の変化だけを記録した引き継ぎカードを作ります。

【第9章 引き継ぎカード】
- 時間と場所：木曜深夜23:40、旧港地区にあるジョナスのアパートのキッチン（窓の外の雨は上がったばかり）
- 場にいる人物の状態：ジョナス（右手首に古傷があり常に左手を使う。桟橋から戻ったばかりでコートが濡れている）／マラ（帳簿の欠落ページに気づいており、窓辺で彼に背を向けている）
- 覆らない確定事実：情報屋のイライは第4章の桟橋で死亡済み。破り取られた帳簿の17ページ目はマラのポケットにある（ジョナスはまだ知らない）
- 直後のフック：階下の通りを無灯灯の灰色の車が通過し、マラはジョナスが先に口を開くまでの秒数を数えている

わずか百数十文字のこのカードが、次の章で最も破綻しやすい「立ち位置」「身体的特徴」「生死」「情報格差」の4点をしっかり固定してくれます。

3. 章ごとに新しいスレッドを開き、「その部屋に入る人・物」だけを持ち込む

新しい章（あるいは大きなシーン）に入るたびに、思い切って新しいチャットを開きます。最初のメッセージに入れるのは次の3点だけです。

1. 作品全体の常駐ベース（文体ルール＋核心となる前提、500字以内）
2. そのシーンに登場する人物だけの設定抜粋（第10章にジョナスとマラしか出ないなら、悪役や脇役のシートは入れない）
3. 前章の引き継ぎカード（150字）＋この章で達成すべき3つのプロットビート

プロンプトがスリムで当面のシーンに集中しているほど、モデルの注意力は鋭くなり、人物らしい動作やセリフが出てきます。

4. 設定ミスが出たら、チャットで言い争わずに元のプロンプトを直して再生成する

AIが「ジョナスは右手を伸ばした」と書いたり、死んだはずの人物を登場させたりしたとき、つい「違う！彼は左利きだ、やり直して！」と返信したくなります。

1回だけならまだしも、これを2回、3回と繰り返すと、スレッド全体が「間違い」「謝罪」「失敗した原稿」で埋め尽くされ、かえって誤った単語が直近のコンテキストに強く残ってしまいます。返信で叱るのではなく、直前のプロンプト自体に抜けていた制約を書き足して再生成し、誤った世界線を最初から会話履歴に残さないようにするのが最も確実です。

まとめ

第10章あたりでAIが物語を「忘れ始める」のは、モデルの性能が急に落ちたからではありません。そもそも一本の直線的なチャットタイムラインは、本を1冊丸ごと保管するようには作られていないからです。 世界観設定、ボツにしたシーン、プロット、10章分の本文を1つのスクロール画面に積み上げれば、どんなモデルでもやがてノイズに溺れます。

コンテキストを「常駐ベース」「構造マップ」「オンデマンド資料室」「現在の作業台」の4層に分けることで、長編執筆に背骨が通ります。常に守るべきルールは概要とメモリに置き、確認が必要な細部は素材と過去章からその都度引き出し、いま書いている段落はノイズのないセッションと行内レビューで磨き上げるという分担です。

Musesはまさにこのワークフローのために設計されています。ユーザーメモリ・プロジェクト概要・プロジェクト詳細の3層管理、記事・素材・マインドマップを統合したプロジェクト境界、@メンションと全文検索による過去章の参照、プロット検討と本文推敲を分けるマルチセッションタブ、そして既存本文への変更を1文ずつ確認できる行内Diffレビューを備えています。執筆中の長編で試してみたい方は、新しいプロジェクトを作成するか、小説執筆ワークスペースおよびAI小説執筆ツールが長編制作をどう支えるかご覧ください。また、ウィンドウ間の往復や書式崩れに疲れを感じている方には、コピペ税：ChatGPTとClaudeでの執筆に隠れた本当のコストやAIで本を書く方法：自分の文体を守る8つのステップもあわせておすすめします。

利用開始は無料です。無料プランには標準のClioモデルと毎月50,000 StarPowerが含まれており、有料プランはサブスクリプション形式で決済ページにて現在の料金をご確認いただけます。無料で始める。