複数作品・複数world・50万字の本文
「人攫い蜂」の例は、たまたま起きた小さな検索失敗に見える。
けれど、長編創作をしていると、こういうことは珍しくない。
作者は、自分の作品について何でも覚えているように思われがちだ。少なくとも、外から見るとそう見える。登場人物の名前も、過去の出来事も、世界観の仕組みも、作者なのだから当然把握しているだろう、と。
しかし、実際にはそうでもない。
作者が覚えているのは、作品そのものというより、作品を書いたときの感触や、頭の中に残っている設定のまとまりである。本文のどの章に、どの言葉で、どこまで明示したかとなると、話は別になる。
頭の中では決まっている。
メモにも書いた気がする。
会話では何度も話した。
けれど、本文に書いたかどうかは分からない。
この差は大きい。
小説において、読者が読めるのは本文だけである。作者の頭の中にだけある設定は、本文に出てこない限り、作品内の事実にはならない。もちろん、作者が未公開の設定や背景を持っていること自体は悪くない。むしろ、作品を書くうえでは必要になる。
ただし、後から整合性を確認するときには、頭の中の設定だけを根拠にするわけにはいかない。
「この人物は、前にもこの場所へ来ていたはず」
「この魔物の名前は、前に出したはず」
「この国の制度は、どこかで説明したはず」
「この二人は、すでに面識があったはず」
そう思っても、実際に本文へ戻ってみると、書いていないことがある。
逆に、忘れていたことが本文にはっきり書いてあることもある。
長編創作では、作者の記憶と本文は少しずつズレていく。
それは作者の記憶力が悪いからではない。
作品が大きくなるとは、そういうことだ。
作品は増える。世界も増える。
短編なら、最初から最後まで読み返すのは難しくない。
一万字、二万字くらいなら、時間を取れば全体を確認できる。
登場人物も少なく、設定も限られているなら、作者の記憶だけでなんとかなることも多い。
けれど、作品が長くなると事情が変わる。
一作が十万字を超える。
シリーズとして複数巻に分かれる。
番外編が増える。
続編が生える。
世界観の違う作品が並行して存在する。
それぞれに人物、地名、魔物、組織、過去の事件、固有名詞がある。
この状態で、すべてを人間の記憶だけに任せるのは無理がある。
しかも、小説本文は単なる設定表ではない。
設定表なら、項目ごとに整理できる。
人物名、年齢、所属、能力、関係性。
国名、制度、歴史、地理。
魔物名、特徴、出現場所、弱点。
そういう形に整理された情報は、確かに扱いやすい。
けれど、小説本文にある情報は、もっと散らばっている。
人物の性格は会話の端に出る。
関係性は仕草に出る。
過去の事件は回想に混ざる。
世界観の仕組みは説明文ではなく、行動の制約として現れる。
固有名詞は一度だけ出て、その後しばらく出てこないこともある。
つまり、本文は情報の倉庫であると同時に、情報が自然文の中に埋まった森でもある。
探したいものがあるとき、どの木の下に埋まっているかを覚えていられるとは限らない。
worldで分ける
そこで、検索botではまず world という単位を置いた。
world は、検索対象となる世界観の名前空間である。
同じ作者の作品であっても、世界観が違えば、人物も設定も別物になる。ファンタジー世界の魔物と、別作品の魔物を同じ検索対象に入れてしまうと、検索結果が混ざる。似た名前の人物がいれば、別世界の人物が引っかかる。似た制度や地名があれば、関係のない本文が出てくる。
創作確認でこれは困る。
確認したいのは、「どこかの作品に似た記述があるか」ではない。
「この世界の本文ではどうなっているか」である。
だから、まず世界を分ける。
/setworld world:kimihanaこのコマンドは、単にbotの設定を変えているだけではない。
今から参照する本文の範囲を決めている。
どの世界の記憶を呼び出すのかを決めている。
別世界の設定を混ぜないための境界線を引いている。
世界観を分けることは、創作検索においてかなり重要である。
検索精度のためでもあるが、それ以上に、作品の整合性を守るためでもある。別作品の情報が混ざった答えは、たとえそれが本文に基づいていても、今見たい世界にとってはノイズになる。
AIに本文を読ませる場合、この境界線はさらに重要になる。
LLMは、与えられた文脈をもとにそれらしい答えを作る。もし別世界の本文が一緒に渡されていれば、その情報を混ぜてしまう可能性がある。本文に基づいているのに、世界観としては間違っている。そういう事故が起きる。
だから、RAG以前に、まず検索対象を分ける必要がある。
world は、そのための最初の箱である。
workで絞る
ただ、世界を分けるだけでも足りない。
同じ世界観の中に、複数の作品があることもある。
本編、続編、番外編、短編、過去編。
同じ人物が出ていても、時系列が違う。
同じ場所が出ていても、出来事の段階が違う。
そこで、work という単位も必要になる。
world が世界観の箱なら、work は作品単位の箱である。
あるときは、world全体から探したい。
その人物の初出を知りたいなら、同じ世界の全作品を対象にした方がいい。
ある設定がシリーズ全体で何度出ているかを見たい場合も、全作品検索が向いている。
一方で、特定の巻や特定の作品だけを確認したいこともある。
この短編の中ではどう書いたか。
この続編の範囲では、もうこの情報を出していたか。
本編では出ていたが、番外編ではどうだったか。
その場合、workで絞れると便利になる。
検索対象を広げれば、見つかる可能性は上がる。
けれど、余計なものも増える。
検索対象を絞れば、ノイズは減る。
けれど、見落とす可能性もある。
創作確認では、この切り替えがよく起きる。
だから、botは世界を選ぶだけでなく、必要に応じて作品も選べるようにする。
段落へ戻る
さらに、検索結果は作品単位や章単位で返ってくるだけでは足りない。
「この作品のどこかにあります」では、確認には遠い。
「第十七章にあります」でも、章が長ければまだ遠い。
本文へ戻るには、もっと小さな単位がほしい。
そこで、段落ごとにIDを付ける。
ch17:p005このようなIDがあれば、どの章の何番目の段落かが分かる。
検索結果に本文抜粋と段落IDが付いていれば、あとから本文ファイルへ戻れる。RAG回答に出典IDが付いていれば、AIの答えがどの段落に基づいているかを確認できる。初登場や最終登場も、本文上の位置として示せる。
これは、小説本文をデータベースにするうえで、とても大事な考え方である。
本文をただ大きな文字列として扱うのではなく、戻れる単位に切る。
その単位にIDを付ける。
検索結果や回答に、そのIDを必ず持たせる。
そうすると、botの答えは単なる返答ではなく、本文への入口になる。
「人攫い蜂です」と言うだけなら、AIは簡単にできる。
しかし、「どの本文に基づいてそう言ったのか」まで示さなければ、創作確認には使いにくい。
段落IDは、回答を本文につなぎ止めるための杭である。
記憶ではなく、索引
このbotは、作者の記憶を置き換えるものではない。
作者が覚えていなくていい、という話でもない。
むしろ、作者の記憶は創作の中心にある。
人物の声、物語の流れ、書いたときの温度、まだ本文に出していない背景。そういうものは、検索botには持てない。
けれど、作者の記憶だけでは支えきれない部分がある。
正確な表記。
初出の位置。
最後に登場した場面。
本文で明言した範囲。
同じ語が何度出ているか。
どの作品のどの章に書いたか。
こういうものは、記憶より索引の方が得意である。
検索botは、作者の代わりに物語を覚えるのではない。
本文へ戻るための索引を作る。
それは、紙の本における索引に近い。
巻末索引がある本では、人名や用語から該当ページへ戻れる。
しかし、小説には普通、細かい索引は付いていない。
作者用の索引も、読者用の索引もない。
ならば、自分で作ればいい。
小説本文を段落に分け、IDを付け、検索できるようにし、必要ならAIに本文だけを読ませて答えさせる。
そうすれば、長編小説は少し扱いやすくなる。
50万字を読むのではなく、戻れるようにする
本文が50万字を超える場合、毎回読み返すのは現実的ではない。
もちろん、必要なときには読む。
大事な場面なら、前後も含めて読み直す。
けれど、確認したいことが起きるたびに全体を読み返していては、創作の手が止まる。
探したいのは、全部ではない。
該当する一段落。
その前後の数段落。
その人物が初めて出てきた場面。
その語が最後に使われた場面。
その設定が明言された箇所。
つまり、必要なのは「全文を読む」ことではなく、「必要な本文へ戻れる」ことである。
検索botは、そのためにある。
長編小説は、人間の記憶に収まらないことがある。
でも、それは悪いことではない。
作品が育ったということでもある。
問題は、覚えていられないことではない。
忘れたときに、戻る道があるかどうかだ。
創作検索botは、その戻る道を作る。
worldで世界を分け、workで作品を絞り、chapterとparagraphで本文へ戻る。
そして、AIを使うときも、必ず本文に結びつける。
第1章で見た「人攫い蜂」の確認は、その小さな例だった。
検索できなかった。
記憶が揺れていた。
本文へ戻った。
正式な表記が分かった。
長編創作では、この小さな往復が何度も起きる。
だからこそ、本文へ戻る仕組みが必要になる。