ビジュアルノベルの謎の人物が姿を見せる前、名前欄には何を表示するべきか

正体がまだわからないキャラクターの名前欄には、その時点の物語で根拠のある呼称を表示します。姿が見えたからといって、読者が名前まで知ったことにはなりません。制作資料に本名が入力されていても、それを自動的にセリフの上へ表示するべきではありません。内部的な識別情報は固定し、表示する呼称は明確な紹介や人物の特定を受けて更新する。バックログには、それぞれのセリフが表示された時点の呼称を残す。これが採用できるルールの一つです。

ルールを書く前に、名前欄がどの範囲の知識を反映するのかを決めます。この例では「現在のルートで読者が得た情報」を基準とし、作者だけが知っている秘密は含めません。主人公の認識に合わせる作品なら、主人公が紹介を聞いていたかどうかも確認する必要があります。どちらの基準も成立しますが、同じシーンの中で説明なく切り替えてはいけません。

以下の人物、セリフ、進行は、解説のために作成したオリジナルの架空例です。実際のユーザー事例、実測結果、筆者自身のテスト記録、DramaFork の製品機能ではなく、特定のエンジンにも依存しません。

舞台は夜の時計店です。制作資料では、ドアの外にいる人物を「キャラクターA、沈硯、時計修理職人」と記しています。読者はまずドア越しに声を聞き、次に彼が明かりの中へ入る姿を見て、最後に本人の名乗りを聞きます。ここで作るのは、この一人の名前欄の開示表です。なぜ身元を隠しているのかを設計することではありません。

内部的な識別情報は、セリフや立ち絵、シナリオの状態を同じキャラクターに対応づけるために使います。一方、現在の表示呼称は「誰がこのセリフを話しているか」を読者に伝えるものです。両者は関連しますが、同じである必要はありません。内部名をそのまま初期表示にすると、制作上の都合が、予定していなかった正体の開示につながってしまいます。

まず読者に示された根拠を確認し、その後で呼称を記入します。先に第二段階を「時計修理職人」と決め、工具箱を持っているというだけで、読者も職業を確認できたはずだと考えてはいけません。

ここで「最後まで提示」とは、名前の情報を読者にすべて伝え終えた状態を指します。セリフの終了を具体的にどこで判定するかは、制作時に定める必要があります。自己紹介のセリフ自体は、引き続き「時計修理職人」の名前欄で表示します。名前がセリフより先に出るのを防ぐためです。表に「紹介時に更新」とだけ書くと、紹介の冒頭で切り替える人と、次のセリフまで待つ人に分かれてしまいます。

この表を再利用する際は、各変更に対応するシーンとセリフの位置を追記します。呼称の根拠となる具体的な一文や明確な出来事が見つからなければ、前の段階を維持します。後で明かされる事実を、その時点の根拠にしてはいけません。

最初のセリフは「訪問者：すみません、時計店はまだ開いていますか？」です。ドアはまだ開いておらず、呼称は話者を最低限区別する役割だけを担います。主人公が答えた後、外の人物が「少し待てます」と言っても、表示は「訪問者」のままです。謎めいた雰囲気を出すためだけに「見知らぬ声」へ変える必要はありません。

途中で別の人物が発言した場合、再び聞こえた声が先ほどと同じ話者だとわかる根拠が必要です。たとえば地の文に「ドアの外の人物が、先ほどの言葉を継いだ」と書けば、名前欄は引き続き「訪問者」にできます。これは話者の連続性を示すもので、名前を明かすものではありません。声が偽装されており、読者に同一人物だと気づかせない語り方を意図しているなら、同じ呼称を使って密かに同一人物だと確定させてはいけません。

次に、彼がドアを押して明かりの中へ入ります。顔は見えるようになりますが、名前欄はまだ「訪問者」です。店主が「こちらが、私の呼んだ時計修理職人です」と言い、本人が「まずは、どこで動きが止まっているか見せてください」と答えます。この返答から「時計修理職人」を表示します。姿を現すことと職業の紹介は連続して起こる別々の出来事であり、今回の呼称変更を裏づけるのは後者だけです。

第三段階で、彼は「自己紹介がまだでしたね。沈硯と申します」と言います。このセリフの名前欄も「時計修理職人」のままです。主人公が「沈さん、こちらへどうぞ」と答え、その後の彼の「ありがとうございます」から「沈硯」を表示します。主人公が敬称を使って呼びかけたからといって、名前欄もすぐに「沈さん」へ変える必要はありません。セリフ内の呼び方は関係性を表せますが、名前欄には表で決めた一定の表記を使います。

分岐によって自己紹介を通らなかった場合は、その後も「時計修理職人」を使います。別のルートで店主が先に「沈硯」と口にし、それが誰を指すか明確に示したなら、その発言を独立した変更のきっかけにできます。機械的に本人の自己紹介を待ち続けるべきではありません。確認するのは名前と人物が結びついたかどうかであって、決まったセリフが再生されたかどうかではないのです。

この例では、過去のセリフを書き換えない方針を採ります。名前が明かされた後でバックログを開いても、最初のセリフは「訪問者」、止まっている箇所を確認する場面は「時計修理職人」のままで、それ以降に「沈硯」が現れます。読者が当時知っていた情報を再現でき、どの段階で身元が明かされたのかも確認しやすくなります。

その代わり、バックログの中で同じ人物に三つの呼称が存在することになります。長編で検索しやすくしたい場合は、名前が明かされた後にだけ読める、呼称の対応関係を示す説明を別途設計できます。たとえば「訪問者、時計修理職人は、いずれも沈硯を指します」という説明です。これは追加の読書補助であり、過去の項目の元の呼称を上書きしてはいけません。未開示のルートで先に表示してもいけません。このような表示への対応は、別途実装する必要があります。

別の選択肢として、名前が明かされた後に過去のバックログの呼称を統一する設計もあります。ただし、以前のシーンを読み返したときの印象が変わることを受け入れ、いつ、どの記録に適用するのかを明確にする必要があります。この例では謎が解けていく過程を振り返ることを重視し、元の呼称を残します。当時の知識に忠実な記録を求めながら、説明もなく後からわかった名前で書き換えることはできません。

名前が明かされる前のセーブデータやシナリオ位置に戻ったときは、現在の名前欄も対応する段階に戻すべきです。読者自身は本名を覚えていても、現在のルートではまだ紹介されていない。この二つは矛盾しません。巻き戻した際にバックログをどう復元するかは、作品がどの範囲を記録するかと併せて決めておきます。

反例の一つ目は、ドア越しの最初のセリフにいきなり「沈硯」と表示することです。セリフで名乗っていなくても、名前欄によって声と名前はすでに結びついています。読者がそれ以前に沈硯の噂を聞いていれば、その噂とのつながりも早く成立します。作者が名前欄による先行開示を明確に意図していない限り、「訪問者」に戻すのが修正方法です。

二つ目は、本人が名乗った後も「？？？」を表示し続けることです。読者は、自己紹介が受け入れられていない、名前が疑わしい、あるいは依然として誰なのか特定できない、と受け取るかもしれません。物語にそうした意味がないなら、表に従って更新します。ただし、自称した名前を表示することは、それが本名だと保証することではありません。偽名を扱う場合は、訂正のきっかけを別に定める必要があります。本人の申告を身元確認と同一視してはいけません。

原稿を渡す前に、通常どおり紹介されるルート、紹介を飛ばすルート、紹介前に戻るルートの三つで、一行ずつ確認します。現在の呼称の根拠はどこにあるか、どのセリフから変更されるか、過去の記録は取り決めどおりか。その後、内部的な識別情報の列を隠し、シーンの文章だけを読みます。制作資料がなければ説明できない呼称は、前の段階へ戻すか、物語の中に根拠を加える必要があります。