/profileを入れると何が変わるのか
検索botを使っていると、次に欲しくなる機能が出てくる。
たとえば、キャラクターのプロフィール表示である。
/profile name:ルークスこのようなコマンドを打つと、キャラクターの基本情報が返ってくる。
初登場、所属、能力、関係者、重要な出来事、現在の状態。
必要なら、本文中の根拠も一緒に出す。
一見、とても便利そうである。
実際、便利だと思う。
長編創作では、キャラクター情報も散らばる。
最初は一人称で出てきただけだった人物が、後から名前を持つ。
関係性が変わる。
肩書きが変わる。
秘密が明かされる。
呼び名が増える。
本人が知っていることと、読者が知っていることがズレる。
そういう情報を、毎回本文から探すのは大変である。
だから、/profile が欲しくなるのは自然だ。
けれど、ここにはひとつ境界がある。
/profile を入れた瞬間、botの性格は少し変わる。
それまでのbotは、本文を探す道具だった。
/search は本文の該当段落を返す。
/ask は本文を根拠に短く答える。
/first と /last は本文上の位置を返す。
どれも、本文へ戻るための入口である。
しかし、/profile は少し違う。
それは、本文から情報を抜き出し、整理し、ひとつの人物像として提示する機能である。
つまり、創作検索から、創作紹介へ一歩踏み出す。
検索は入口を返す
現行のbotは、基本的に入口を返す。
この段落にある。
この章に出てくる。
この語はここで使われている。
この人物の初登場はここ。
最終登場はここ。
答えは出すが、常に本文へ戻る道がある。
/ask も、自然文で答えるとはいえ、出典IDを付ける。
答えそのものより、答えの根拠へ戻れることを大事にしている。
これは、かなり慎重な設計である。
検索botは、本文を読みに行くための案内係である。
案内係は、道を示す。
最終的に読むのは人間である。
この距離感があるから、AIの要約や検索結果に対して、人間が確認できる。
出典IDをたどる。
前後を読む。
「ああ、ここからそう言っているのか」と判断する。
必要なら、別の検索をする。
検索botの答えは、固定された設定表ではない。
本文への入口であり、確認のきっかけである。
紹介は人物像をまとめる
一方、プロフィール表示は、少し性質が違う。
プロフィールは、散らばった情報をまとめる。
名前。
所属。
年齢。
能力。
関係者。
重要な出来事。
現在の状態。
性格。
過去。
秘密。
物語上の役割。
こうした情報を一画面に整理して返す。
これはとても便利である。
しかし、便利なぶん、情報が固定されやすい。
「この人物はこういう人です」
「この関係はこうです」
「現在の状態はこうです」
そのようにまとめられると、人間はそれを設定表のように扱いやすくなる。
もちろん、本文に根拠があればよい。
出典IDを付ければ、検証もできる。
本文から抽出したfactsを使えば、かなり安全に作れるかもしれない。
それでも、検索結果を返すだけの場合とは違う。
プロフィールは、本文の断片をひとつの説明にまとめる。
その過程で、選択が起きる。
どの情報を載せるか。
どの情報を省くか。
どの時点の情報を「現在」とするか。
ネタバレを含めるか。
視点人物が知らないことを含めるか。
未確定の情報をどう扱うか。
矛盾する描写がある場合、どちらを優先するか。
これは、単なる検索ではない。
編集であり、解釈であり、紹介である。
factsとrelations
将来的な機能として、人物DBを作ることも考えられる。
たとえば、factsとrelationsである。
factsは、その人物について本文から抽出された事実である。
ルークスは○○に所属している。
ルークスは第○章で依頼を受けた。
ルークスは○○と面識がある。relationsは、人物同士の関係である。
AはBの師匠である。
CはDを助けたことがある。
EとFは同じ組織に所属している。こうした情報が構造化されていれば、かなり便利である。
人物プロフィールを作れる。
関係図を作れる。
時系列を整理できる。
矛盾を検出できるかもしれない。
「この人物が知っているはずの情報」を確認する助けにもなる。
創作支援としては、とても魅力的だ。
ただし、ここでも注意が必要である。
factsやrelationsは、本文から抽出された瞬間に、本文そのものではなくなる。
もちろん、本文を根拠にしている。
出典IDも付けられる。
けれど、それは本文の再構成である。
本文中では曖昧だった関係を、DB上でははっきりした関係として登録してしまうかもしれない。
一時的な状態を、恒常的な設定として扱ってしまうかもしれない。
ある人物の主観を、作品世界の客観的事実として保存してしまうかもしれない。
小説には、曖昧さがある。
ある人物がそう思っているだけかもしれない。
語り手が意図的にぼかしているかもしれない。
読者にはまだ伏せている情報かもしれない。
後の章で意味が変わる描写かもしれない。
それをfactsとして切り出すとき、曖昧さが落ちる。
これは便利さと引き換えに起きる。
時点の問題
プロフィールや人物DBで特に難しいのは、時点である。
長編小説では、人物の状態は変わる。
所属が変わる。
能力が変わる。
関係が変わる。
知っている情報が増える。
立場が変わる。
呼び名が変わる。
読者に明かされる情報も変わる。
ある章では敵だった人物が、後の章では味方になるかもしれない。
ある人物が秘密を知らない時期と、知った後では、発言の意味が変わる。
序盤のプロフィールと終盤のプロフィールは、同じであってはいけない。
では、/profile はどの時点の情報を返すべきか。
作品全体を読んだあとの最新状態か。
指定した章時点の状態か。
読者にその時点で開示されている情報だけか。
作者用にネタバレ込みで全部出すのか。
ここを決めないと、プロフィールは危ない。
作者用なら、ネタバレ込みでもよいかもしれない。
しかし、読者向けの紹介なら、ネタバレは避けたい。
執筆中の確認なら、「この章時点でこの人物が何を知っているか」が大事になる。
つまり、プロフィールは単なる情報表示ではない。
時間軸と視点の問題を含む。
検索botの段階では、この問題は比較的避けやすい。
本文の場所を返すだけなら、人間が前後を読んで判断できる。
しかし、プロフィールとしてまとめるなら、botが判断する部分が増える。
そのぶん、設計が難しくなる。
紹介文は本文から離れやすい
もうひとつ、紹介文の危うさがある。
キャラクター紹介や作品紹介は、読みやすい文章にしたくなる。
「ルークスは、冷静な判断力を持つ若者である」
「彼は仲間思いで、危険な依頼にも立ち向かう」
「物語を通じて成長していく人物である」
こういう紹介文は、それらしく見える。
けれど、どこまで本文に基づいているのかを確認するのは難しい。
性格の説明は、本文上の行動や発言からの要約になる。
「仲間思い」という表現は、解釈である。
「成長する」という説明も、どの時点からどの時点への変化を指すのかを決める必要がある。
紹介文は、読みやすいほど、本文から少し離れることがある。
もちろん、それが悪いわけではない。
紹介文には紹介文の役割がある。
読者に作品を伝えるためには、要約や解釈が必要になる。
キャラクターを説明するには、本文の断片をそのまま並べるだけでは足りない。
ただし、それはもう検索ではない。
紹介である。
検索botに紹介機能を足すなら、そこを意識しておく必要がある。
機能追加は道具の性格を変える
便利そうな機能は、いくらでも思いつく。
キャラクターのプロフィールを出したい。
人物関係を一覧したい。
舞台設定をまとめたい。
用語集を作りたい。
ネタバレなし紹介文を作りたい。
読者向けのキャラクター紹介を生成したい。
作者向けに伏線一覧を出したい。
どれも面白い。
そして、どれも実装したくなる。
けれど、機能を足すたびに、道具の性格は変わる。
検索botは、本文へ戻るための道具である。
プロフィールbotは、本文をもとに人物像を整理する道具である。
紹介botは、作品を他人へ伝えるための道具である。
分析botは、作品の構造やテーマを読み解く道具である。
それぞれ近い。
けれど、同じではない。
同じ小説本文を情報源にしていても、目的が違えば設計も変わる。
検索なら、本文へ戻れることが最優先になる。
紹介なら、読みやすさや分かりやすさが重要になる。
分析なら、解釈の妥当性が問題になる。
作者用DBなら、時点管理やネタバレ管理が重要になる。
どこまでを同じbotに持たせるか。
どこからは別の道具に分けるか。
それは、機能の問題であると同時に、思想の問題でもある。
現行botは検索に留める
現時点のこのbotは、創作検索に寄せている。
本文を探す。
本文を引用する。
本文を根拠に短く答える。
初出や最終出を返す。
数える。
どれも、本文へ戻るための機能である。
これは、スコープを狭くしているとも言える。
プロフィール表示もない。
人物DBもまだない。
関係図もない。
作者情報の表示もない。
できることは限られている。
けれど、そのぶん、役割ははっきりしている。
本文へ戻る。
この一点に集中している。
機能が少ないことは、必ずしも弱さではない。
道具の性格がはっきりしているということでもある。
もちろん、将来的に /profile を足してもいい。
factsやrelationsを作ってもいい。
RAG要約を強化してもいい。
ただし、そのときは「検索」からどこへ踏み出すのかを意識したい。
創作検索なのか。
創作紹介なのか。
作者用設定DBなのか。
読者向け案内なのか。
そこを曖昧にしたまま機能を足すと、botの答えも曖昧になる。
本文へ戻る、を基準にする
では、機能追加を考えるとき、何を基準にすればいいのか。
この本の答えは、やはり同じである。
本文へ戻れるかどうか。
プロフィールを出すなら、項目ごとに出典へ戻れるか。
人物関係を出すなら、その関係がどの場面で示されたのか確認できるか。
用語集を作るなら、初出や代表的な用例へ戻れるか。
紹介文を作るなら、どこからどこまでが本文根拠で、どこからが要約や解釈なのか分けられるか。
本文へ戻れるなら、まだ検索botの延長に置ける。
本文へ戻れないなら、それは別の道具として扱った方がよい。
この基準は、完全ではない。
紹介や分析には、本文から少し離れる必要があることもある。
読者に伝えるためには、要約や解釈が必要になる。
作者本人の頭の中にしかない設定を扱いたいこともある。
それでも、創作検索botとしては、本文へ戻れることを基準にしたい。
それが、このbotの安全装置であり、性格である。
境界を意識しておく
創作検索と創作紹介の境界は、はっきり線を引けるものではない。
/ask も、すでに少し要約している。
/count も、本文を数に変換している。
/first や /last も、本文の中から特定の意味を持つ位置を取り出している。
完全に検索だけの道具ではない。
それでも、現行botは本文へ戻ることを中心にしている。
だから、まだ創作検索の側にいる。
/profile を入れるなら、その境界を一歩越えるかもしれない。
人物DBを作るなら、さらに踏み込むかもしれない。
紹介文を生成するなら、かなり創作紹介に近づく。
それは悪いことではない。
ただ、何を作っているのかを分かっていた方がいい。
便利な機能を足すたびに、道具の人格は変わる。
検索係なのか。
紹介係なのか。
分析係なのか。
設定管理係なのか。
その人格を決めるのは、機能の数ではなく、何を根拠に何を返すかである。
現行botは、本文を根拠に、本文への入口を返す。
だから、創作検索botである。
第8章では、この創作検索botがどこで動いているのか、どう運用されているのかを見ていく。
ラズパイ5の上で、MeiliSearchとQdrantを抱え、Discordから呼び出される。
使う人は多くない。
けれど、その少なさも含めて、この道具の性格を作っている。
次は、二人のための文学検索システムとしての話である。