/search、/ask、/count、/first、/last
ここまで、本文をどう切るか、どう探すか、どう引用付きで答えさせるかを見てきた。
けれど、どれだけ仕組みを整えても、使いにくければ道具としては続かない。
創作中に何かを確認したくなったとき、毎回ターミナルを開く。
サーバーに入る。
検索用のスクリプトを叩く。
結果を読んで、また執筆画面へ戻る。
それでも使えないわけではない。
けれど、日常的に使うには少し遠い。
創作中の確認は、もっと気軽に発生する。
「あれ、この名前どこで出したっけ」
「この人物、もう登場してたっけ」
「あの依頼、正式名称なんだったっけ」
「この単語、何回くらい出てる？」
「この設定、本文に書いてあった？」
こういう疑問は、作業の途中でふっと出てくる。
だから、検索botはDiscordに置いた。
道具は使う場所に置く
Discordは、会話の場である。
創作の相談をする。
メモを投げる。
作業報告をする。
思いついたことを流す。
誰かと話しながら設定を確認する。
そういう場所に検索botがいると、確認の手間が減る。
ブラウザを開いて、別の検索画面へ行く必要がない。
サーバーへ入ってコマンドを叩く必要もない。
普段の会話欄で、スラッシュコマンドを呼べばいい。
これは小さいようで、大きい。
道具は、使う場所にあるほど使われる。
使う場所から遠い道具は、よほど必要なときしか使われない。
検索botをDiscordに置くことは、創作検索を特別な作業ではなく、会話の一部にすることだった。
スラッシュコマンドという道具箱
Discord botでは、スラッシュコマンドを使う。
このbotに用意した主なコマンドは、次の通りである。
/setworld
/setwork
/search
/ask
/count
/first
/last並べてみると、小さな道具箱のように見える。
世界を選ぶ。
作品を絞る。
本文を探す。
本文を根拠に聞く。
数える。
初登場を探す。
最終登場を探す。
どれも派手な機能ではない。
しかし、長編創作の確認作業では、それぞれに出番がある。
/setworld は世界を選ぶ
最初に使うのは、たいてい /setworld である。
/setworld world:kimihanaこのコマンドで、検索対象のworldを指定する。
第2章でも書いたように、worldは世界観の名前空間である。
複数のシリーズや世界観を同じ検索対象に混ぜると、結果が混乱する。
別世界の人物や設定が引っかかってしまえば、創作確認としては危うい。
だから、まず世界を選ぶ。
/setworld は、検索対象の境界線を引くコマンドである。
「今からこの世界の本文を見る」
「別世界の記憶は混ぜない」
「この作品群の中で確認する」
その宣言を、最初に行う。
この指定はユーザーセッションに保存される。
毎回すべてのコマンドでworldを指定しなくても、選んだ世界を前提に検索できる。
これは使い勝手のためである。
創作確認のたびに長い引数を付けるのは面倒だ。
一度世界を選んだら、その流れで何度も検索したい。
/setworld は、検索の前準備であり、世界観を混ぜないための安全装置でもある。
/setwork は作品を絞る
/setworld で世界を選んだあと、必要に応じて /setwork を使う。
/setwork work:allあるいは、特定の作品IDを指定する。
world全体から探したいときもあれば、特定の作品だけを見たいときもある。
初登場を探すなら、同じworldの全作品を対象にした方がいいことが多い。
一方で、ある番外編の中だけでどう書いたかを確認したいなら、作品を絞った方がよい。
検索対象を広げれば、拾えるものは増える。
しかし、ノイズも増える。
検索対象を狭めれば、余計な結果は減る。
しかし、範囲外の情報は出てこなくなる。
この切り替えをするのが /setwork である。
worldが世界観の箱なら、workはその中の作品単位の箱である。
どの箱を開けるかを選ぶことで、検索結果の意味が変わる。
/search は本文への直行便
/search は、もっとも基本的な検索コマンドである。
/search q:ワイバーン覚えている語を入れる。
本文から探す。
該当する段落を返す。
返ってくるのは、本文抜粋、作品名、章、段落IDである。
第1章では、人食い蜂 と 人喰い蜂 が出てこなかったあと、ワイバーン で検索して結果が出た。
あれは、検索機能そのものが生きていることを確認するための使い方でもあった。
/search は、正確な語を持っているときに強い。
人物名。
地名。
魔物名。
技名。
台詞の一部。
設定用語。
そういうものを探すとき、/search は本文への直行便になる。
ただし、検索語が間違っていれば出てこない。
これは欠点ではなく、性質である。
/search は、本文にある文字列を探す。
本文にない文字列は返さない。
だからこそ、表記確認には向いている。
一方で、記憶が揺れているときには弱い。
そのときに使うのが、次の /ask である。
/ask は曖昧な記憶から本文へ戻る
/ask は、本文RAGで要約回答を返すコマンドである。
/ask q:ルークスの受けた依頼は？この質問は、本文にそのまま書かれた文字列ではない。
けれど、意味としては、依頼を受けた場面やその内容を探したいという意図がある。
/ask は、そういう曖昧な入口から本文へ戻るためにある。
まず、関連しそうな段落を探す。
必要なら前後の段落を足す。
その本文をLLMに渡す。
本文引用だけを根拠に答えさせる。
回答には出典IDを付ける。
第1章では、この /ask によって、依頼の正式名称が 人攫い蜂の退治 だと分かった。
これは、/search では届かなかった場所へ、状況から近づいた例である。
/search は、正しい語を持っているときに強い。
/ask は、正しい語を持っていないときに強い。
「あの場面」
「この人物が受けた依頼」
「この二人の関係」
「この魔物について分かること」
そういう問いには、/ask が向いている。
ただし、/ask の答えも丸呑みしない。
回答には出典IDが付く。
必要なら本文へ戻る。
前後を読む。
要約が妥当か確認する。
/ask は、最終判定者ではない。
本文へ戻る道案内である。
/count は数える
/count は、本文から回数を数えるコマンドである。
/count q:人攫い蜂画面に返ってくるのは、数字だけである。
見た目はとても単純だ。
しかし、内部では本文を探し、文脈をまとめ、その中で明示されたものだけを数える。
このコマンドは、少し慎重に扱う必要がある。
単語の出現回数に近い使い方なら分かりやすい。
たとえば、人攫い蜂 という語がどれくらい出てくるかを見る。
しかし、自然文で数えようとすると難しくなる。
「主人公が怒った回数」
「誰かが助けられた回数」
「依頼が発生した回数」
こういう問いでは、何を一回と数えるのかが曖昧になる。
言及なのか、出来事なのか。
回想なのか、現在の場面なのか。
同じ出来事が複数回語られているのか。
だから、/count は便利だが、絶対視しない方がいい。
数字が出たら、それを手がかりにする。
必要なら、検索し直す。
根拠となる本文を読む。
条件を変えて聞き直す。
/count もまた、本文へ戻るための道具である。
画面には数字しか出なくても、その背後には本文がある。
数字だけで完結させない方が安全である。
/first は初登場を探す
/first は、指定した名前の初登場段落を返す。
/first name:ルークス長編創作では、人物や用語の初出を確認したくなることがある。
この人物は、いつから出ていたのか。
この名前は、最初にどこで出したのか。
読者にとって初めて見る場面はどこなのか。
再登場のつもりで書いているが、実はまだ出ていなかったのではないか。
そういう確認に使う。
初登場は、意外と大事である。
作者の頭の中では、人物はずっと前から存在している。
設定も、関係性も、過去もある。
けれど、読者にとっては、本文に出た瞬間が初登場である。
このズレはよく起きる。
作者にとっては見慣れた人物でも、本文上ではまだ名前しか出ていないかもしれない。
あるいは、思っていたより早い段階で登場していたかもしれない。
/first は、そのズレを確認するためのコマンドである。
内部的には、名前や別名を展開して検索し、本文順に並んだ結果の先頭を返す。
つまり、特別に賢い推理をしているわけではない。
本文に順番を持たせているから、初登場を取れる。
ここでも、第3章の土台が効いている。
/last は最終登場を探す
/last は、指定した名前の最終登場段落を返す。
/last name:ルークス初登場と同じくらい、最終登場も役に立つ。
この人物は最後にどこで出てきたか。
最後に何をしていたか。
しばらく出ていないと思っていたが、実は最近も出ていたか。
次に登場させるとき、前回の状態からつながっているか。
長編やシリーズものでは、人物の再登場がよく起きる。
前回どこで別れたのか。
どんな状態だったのか。
何を知っていて、何を知らないのか。
誰と一緒にいたのか。
これを確認せずに続きの場面を書くと、微妙なズレが出ることがある。
/last は、その確認に使える。
こちらも、内部的には名前で検索し、本文順に並べた結果の末尾を返している。
本文の順序があるからこそできる機能である。
/first と /last は、派手ではない。
けれど、長編創作の整合性確認ではかなり便利である。
別名を吸収する
人物名や用語には、表記ゆれがある。
フルネーム。
姓だけ。
名だけ。
愛称。
肩書き。
呼び名。
空白の有無。
漢字とかな。
同じ人物を指していても、本文中ではいろいろな形で出てくる。
そのため、worldごとに別名辞書を用意している。
/first や /last では、この別名辞書を使って名前を展開する。
たとえば、あるキャラクターに複数の呼び名がある場合、それらをまとめて検索できる。
これは、創作検索ではかなり重要である。
人間は、同じ人物をいつも同じ呼び方で書くとは限らない。
地の文と会話文で呼び方が違うこともある。
視点人物によって呼び名が変わることもある。
別名辞書は、その揺れを吸収するためのものだ。
ただし、これも万能ではない。
別名を登録し忘れれば拾えない。
同じ呼び名が別人物にも使われるなら、誤爆する可能性がある。
肩書きや一般名詞に近い呼び名は、ノイズを増やすこともある。
だから、別名辞書も育てる必要がある。
小説が増えるたびに本文を取り込み、必要に応じて別名を足す。
検索結果を見て、足りない呼び名に気づく。
また辞書を直す。
検索botは、一度作って終わりではなく、本文と一緒に育つ。
創作会話の中にいる索引係
ここまで見てきたように、それぞれのコマンドは役割が違う。
/setworld は、世界を選ぶ。
/setwork は、作品を絞る。
/search は、正確な語で本文を探す。
/ask は、曖昧な記憶から本文へ戻る。
/count は、本文に明示されたものを数える。
/first は、初登場を探す。
/last は、最終登場を探す。
どれも、本文へ戻るための入口である。
Discordに置いたことで、これらの入口は創作会話の中に入ってくる。
誰かと相談しながら、すぐ検索できる。
作業中に気になったことを、その場で確認できる。
スマホからでも呼べる。
スクショを撮って共有できる。
検索結果そのものが、会話の材料になる。
これは、検索サイトとは少し違う。
検索サイトは、人間がそこへ行って使うものだ。
Discord botは、会話の場所にいる。
つまり、このbotは創作会話の中にいる索引係である。
呼べば本文を探す。
聞けば本文を根拠に答える。
数えてほしいと言えば数える。
初登場や最終登場を返す。
ただし、物語を勝手に作るわけではない。
作者の代わりに判断するわけでもない。
本文への道を示すだけである。
その距離感が、ちょうどいい。
使いやすさは思想でもある
機能そのものは、ターミナルからでも実行できる。
Web UIを作ってもいい。
ローカルアプリにしてもいい。
それでもDiscordに置くことには意味がある。
使いやすさは、単なる便利機能ではない。
どういう場面で使ってほしいか、という思想でもある。
このbotは、特別な解析作業のためだけにあるのではない。
創作中の小さな疑問に答えるためにある。
会話の流れの中で、本文へ戻るためにある。
だから、Discordにいる。
検索が必要になるたびに、大げさな手順を踏まなくていい。
スラッシュコマンドを打つだけでいい。
それだけで、本文へ戻るハードルは下がる。
長編創作では、このハードルの低さが効いてくる。
確認が面倒だと、人は確認を後回しにする。
後回しにした確認は、忘れられる。
忘れられた確認は、あとで整合性のズレになる。
ならば、確認を軽くする。
Discordに置いた検索botは、そのための道具である。
第7章では、この道具にさらに機能を足すときの話に進む。
便利そうな機能は、いくらでも思いつく。
キャラクターのプロフィール表示、人物DB、関係性、作者情報、紹介文。
けれど、機能を足すと、道具の性格も変わる。
創作検索と創作紹介の境界は、どこにあるのか。
次は、その話である。