人食い蜂・人喰い蜂・人攫い蜂
最初に起きたのは、単純な検索失敗だった。
Discordで、創作検索botに向かってコマンドを打つ。
/setworld world:kimihana対象にする世界を設定する。
このbotでは、作品群を world という単位で分けている。シリーズごとに世界観が異なるため、検索対象を混ぜないためだ。別の世界の人物、別の世界の地名、別の世界の設定が混ざってしまうと、創作確認の道具としては使いにくくなる。
だから、まず世界を選ぶ。
kimihana は、そのうちのひとつである。
次に、目的の単語を検索する。
/search q:人食い蜂該当なし。
では、漢字が違うのかもしれない。
/search q:人喰い蜂これも、該当なし。
この時点で、少しだけbotを疑う。
検索できるはずのものが出てこない。
取り込みに失敗しているのかもしれない。
インデックスが壊れているのかもしれない。
検索機能そのものが、どこかでおかしくなっているのかもしれない。
検索で「該当なし」と出たとき、それは単に「本文に存在しない」という意味ではない。
少なくとも、三つの可能性がある。
ひとつは、本当に本文に存在しないこと。
ひとつは、本文には存在するが、検索語が間違っていること。
もうひとつは、取り込みや索引、検索機能に問題があること。
検索結果がゼロになると、人間はつい三つ目を疑いたくなる。
特に、自分で作ったbotならなおさらだ。どこか壊れているのではないか。何か取り込み忘れたのではないか。更新したときに失敗したのではないか。そう考えるのは自然なことだ。
けれど、長編創作で意外に多いのは、二つ目である。
本文にはある。
ただし、自分が覚えている名前とは違う形で。
そこで、別の単語を試す。
/search q:ワイバーン今度は出た。
作品名、章、本文抜粋、そして段落IDが並んで返ってくる。
つまり、検索機能は生きている。
ここで疑う対象が変わる。
壊れているのはbotではない。
おそらく、こちらの記憶のほうだ。
探していたのは、ルークスが受けた依頼の内容だった。
けれど、その依頼に出てくる蜂の名前が思い出せない。
人食い蜂だった気がする。
人喰い蜂だったかもしれない。
けれど、どちらでも検索に引っかからない。
こういうとき、キーワード検索は弱い。
キーワード検索は、覚えている言葉が正しければ強い。固有名詞、台詞、地名、魔物名、技名。正確な文字列を持っていれば、本文の該当箇所まで一気に飛べる。
しかし、人間の記憶はそこまで律儀ではない。
音だけ覚えている。
意味だけ覚えている。
場面だけ覚えている。
似た言葉と混ざっている。
漢字表記が揺れている。
あるいは、本文に書いた正式名称ではなく、自分の頭の中で勝手に近い言葉へ変換してしまっている。
そんなとき、検索欄に入れるべき正しい言葉が分からない。
そこで、今度は /ask を使う。
/ask q:ルークスの受けた依頼は？これは、単純なキーワード検索ではない。
本文から関連しそうな段落を探し、その引用だけを根拠に、LLMが短く答える機能である。本文以外の知識は使わない。推測で補わない。回答には出典IDを付ける。
返ってきた答えは、こうだった。
ルークスが受けた依頼は、人攫い蜂の退治。
人食い蜂ではなかった。
人喰い蜂でもなかった。
人攫い蜂だった。
ここでようやく、検索できなかった理由が分かる。
本文に存在しない語で探していたから、出てこなかったのだ。
この違いは小さい。
けれど、長編創作においては、この小さな違いがよく起きる。
作者は、自分の作品のことをすべて覚えているわけではない。
むしろ、書いた本人だからこそ、本文に実際に書いたことと、頭の中で考えていたことと、あとから思い出したことが混ざる。
「こう書いたはず」
「こういう意味だったはず」
「たしか、こんな名前だったはず」
その「はず」は、しばしば本文とズレる。
創作における確認作業で大切なのは、作者の記憶を責めることではない。
記憶が揺れたときに、本文へ戻れることだ。
だから、このbotは単に答えを返せばいいわけではない。
本文へ戻れる形で返す必要がある。
どの作品の、どの章の、どの段落に根拠があるのかを示す必要がある。
/ask の答えには、出典IDが付く。
それは、AIの回答を飾るための記号ではない。
その答えを信じるためではなく、確認するための足場である。
AIが「人攫い蜂です」と言ったから正しい、ではない。
AIが示した本文に「人攫い蜂」とあるから、確認できる。
信じる対象はAIではなく、本文である。
その後、確定した語で /count を使う。
/count q:人攫い蜂返ってきた数字は、10。
画面に出てくるのは、ほとんど数字だけである。
けれど、内部では本文から関連する段落を探し、文脈を組み立て、その中に明示されたものだけを数える。
もちろん、これは万能ではない。
数えるという行為は、検索よりも危うい。
何を一回と数えるのか。名前が出ただけで数えるのか。出来事として発生した回数を数えるのか。言及と実際の発生を分けるのか。
自然文で「数えて」と頼む以上、曖昧さは残る。
それでも、今回のように「確定した語が本文中にどれくらい出てくるか」を見る用途なら、十分に役に立つ。
この一連の流れは、検索botの価値をよく表している。
単に「本文を検索できる」だけではない。
単に「AIが質問に答える」だけでもない。
このbotは、作者や読者の記憶が揺れたときに、本文へ戻るための道具である。
検索して出てこない。
では、本文にないのか。
検索語が間違っているのか。
それとも、システムが壊れているのか。
この三つを切り分けるのは、意外と難しい。
今回の場合、ワイバーン で検索できたことで、検索機能そのものは動いていると分かった。
/ask で依頼内容を尋ねたことで、正しい表記が分かった。
/count でその語の出現数を確認したことで、本文中にどれくらい現れているかも分かった。
つまり、botは答えを一発で出したのではない。
人間が迷い、疑い、試し、確かめる流れの中で、本文への道筋を作った。
ここに、/search と /ask の違いがある。
/search は、覚えている言葉が正しいときに強い。
本文の中にある文字列へ、まっすぐ向かう道具である。
/ask は、覚えている言葉が曖昧なときに強い。
「誰が何を受けたんだっけ」「あの場面では何が起きたんだっけ」という、状況から本文へ戻るための道具である。
どちらか一方では足りない。
長編創作の現場では、「正確な語を覚えているとき」と「場面だけ覚えているとき」が混在する。
前者には検索が効く。
後者には、引用付きのRAG回答が効く。
そして、どちらの場合でも最後に必要なのは、本文へ戻れることだ。
創作に必要なのは、必ずしも派手な生成ではない。
むしろ、こういう地味な確認作業のほうが、長編を書く現場では効いてくる。
あの設定はどこにあったか。
あの名前はどの漢字だったか。
この人物はいつから登場していたか。
この出来事は何回起きたか。
本文上で明言されているのか、それとも自分の頭の中にしかないのか。
小説が長くなるほど、作者の頭の中と本文の間にはズレが生まれる。
検索botは、そのズレを責めるためのものではない。
ズレたときに、本文へ帰るためのものだ。