AIと長編小説を書いていると、前に決めた設定がだんだんぼやけていきます。この問題を解くためにTypeTakの設定辞典「ワールド」をつくりながら、悩んだことや選んだことを1回ずつ書いています。

AIはなぜ小説の前の内容を忘れるのか

AIが長編小説の前の内容を忘れるのは、一度に読める分量に上限があるからです。原稿がその分量を超えると、AIは前半を直接読めなくなり、どこかに別に書き留めておいたものを探して読み直す必要があります。私の見たところ、探して読む方法は2つです。意味の近い段落を探して渡すRAGと、整理しておいたファイルを読む方法です。

私はTypeTakというAI執筆エディタを作っています。作家がエージェント（一緒に作業するAI）と小説を書くためのツールです。長編でもAIが前に決めた設定を忘れないように、設定を整理しておき、AIがそれを探して読めるようにする設定辞典ワールドを作りました。このシリーズは、ワールドを作った過程を順に書いた記録です。

第1回は、まだワールドがなかったころの話です。AIに小説の前の内容をどう覚えさせるか、2つの道のどちらを選ぶかで悩んだ過程を書きます。

一度に読める分量には限りがある

AIモデルが一度に読める範囲をコンテキストウィンドウと呼びます。ウィンドウの大きさはモデルによって違い、年々大きくなっていますが、連載が100話を超えると、原稿全体を毎回すべて渡すのは難しくなります。渡せたとしても、費用がかさみます。

ウィンドウに余裕があっても問題は残ります。2026年3月に発表された研究「Lost in Stories」は、AIが長い物語を書くとき、前に決めた事実と食い違う文をどれくらいの頻度で書くかを調べました。食い違いがもっとも多かったのは事実（誰が何を持っているか）と時間（いつ何が起きたか）で、物語の冒頭や結末よりも中盤に集中していました。（arXiv）

作家の側から見ると、こういうことです。3話で左腕をけがした主人公が10話で両腕を使って剣を振るい、敬語で話していた脇役がいつの間にかため口になっている。

ですから、長編を扱うAIツールはどれも同じ問いに答えなければなりません。ウィンドウの外に置いた前の内容を、必要なときにどうやって探し直して読ませるか。 私が見た答えは2つでした。

1つ目の方法、RAG：意味で探すと、積み重なったものが出てこない

RAGは、原稿を細かく分けて保存しておき、いま書いている場面と意味の近い断片を探してAIに一緒に渡す方法です。社内文書やカスタマーサポートのように、答えがひとつの段落にまるごと収まっている場合にはよく合います。

小説ではここで行き詰まる、と私は考えました。物語に必要なのは似た文ではなく、積み重なった結果だからです。

「いま主人公の左腕はどんな状態か」と尋ねると、RAGは「左腕」が出てくる段落をいくつも拾ってきます。けがをした場面、包帯を巻いた場面、すっかり治った場面が混ざって届きますが、そのどれが現在なのかは教えてくれません。「2人はなぜ仲たがいしたのか」のように何話にもわたって積み重なった理由は、どの段落にもまるごとは書かれていないので、意味で探しても断片しか出てきません。

意味で探す方法は「何に似ているか」には答えられても、「これまでに何が積み重なったか」には答えられません。そこで私は、RAGを記憶の中心に置かないことにしました。

2つ目の方法、ファイル：リンクはたどれるが、形式がない

もうひとつの道は、設定を別に整理したファイルを用意して、AIにそのファイルを読ませることです。作家がつくる設定資料と同じ発想です。人物ごと、場所ごとに文書を作ってリンクでつなぐ、Wikiの形がよく使われます。

私がファイルに惹かれた理由はリンクでした。Wikiなら「主人公」の文書から「主人公の師匠」の文書へ、さらに「師匠がけがをした事件」へと移れます。意味が似ているかどうかに関係なく、つながっているものをたどれるのです。積み重なった物語を探すには、こちらが合っていました。

ただし、ファイルにも弱点が2つありました。

形式がない。 AIに任せきりにすると、文書ごとに形がばらばらになります。AIはそれでも読めますが、人が目を通して直すには不便です。作家が確かめられない設定資料は、安心して使えません。
整理しないと散らかる。 設定は原稿を書くあいだも変わり続けます。変わるたびに整理しなければ、同じ人物の文書が2つできたり、食い違う内容がひとつの文書に残ったりします。食い違った設定資料は、ないよりも悪いものです。

だからファイルを選んだ

2つの道を並べてみると、答えはファイルでした。RAGの限界は方法そのものから来ていますが、ファイルの2つの弱点は解ける問題に見えたからです。

形式がないなら、形式を決めればいい。人にも読みやすく、AIが自分で埋められる形式に。
整理しないと散らかるなら、整理をひとつの仕事にすればいい。同じ対象が二度作られないように、変わった設定が収まるべき場所に収まるように。

言うのは簡単でした。2つの問題を解くには思ったより時間がかかり、そうしてできたファイルがいまのTypeTakのワールドです。

次回は1つ目の問題、形式の話です。私はその手がかりを、韓国のWikiサイト「ナムウィキ（Namuwiki）」で見つけました。別々の人が書いた数えきれないほどの作品の文書が、なぜ同じ形をしているのか。そこから何を取り入れたのかを書きます。

TypeTakは、小説の前の内容を意味で探すRAGではなく、整理しておいたファイルをリンクでたどって読む方法で覚えさせることにしました。その代わり、形式と整理という2つの宿題を抱えることになりました。

よくある質問

AI小説ツールは前の内容をどうやって覚えているのですか？

AIには一度に読める分量（コンテキストウィンドウ）の上限があるため、長い原稿の前半は、別に書き留めたものを探して読み直す必要があります。探し方は大きく2つです。原稿の断片から意味の近いものを探して渡すRAGと、設定を整理したファイル（Wiki）を読む方法です。

コンテキストウィンドウが大きいAIなら、小説の前の内容を忘れませんか？

忘れることはあります。コンテキストウィンドウはAIが一度に読める分量で、大きくなれば一度に渡せる原稿は増えますが、そのぶん費用がかかります。ウィンドウに入っていても、きちんと読まれないという問題も残ります。2026年の研究「Lost in Stories」では、長い物語での設定の食い違いは中盤に集中していました。

RAGはなぜ小説に向いていないのですか？

RAGは原稿を細かく分けて保存し、意味の近い断片を探してAIに渡す方法です。小説に必要なのは、何話にもわたって積み重なった結果といまの状態ですが、それはひとつの段落にまるごと書かれているわけではありません。そのため意味で探すと、さまざまな時点の断片が混ざって届き、どれが現在なのかがわかりません。

小説の設定をWikiで整理すると、どんな欠点がありますか？

Wikiはリンクをたどって関連する設定まで探せますが、弱点が2つあります。形式を決めないと文書ごとに形が違って人が確かめにくく、設定が変わるたびに整理しないと、同じ対象が二度作られたり、食い違う内容が積み重なったりします。