人物の改名と依存関係

改名するのは文字列ではなく、すでに関係を持つ人物

登場人物の名前は、採用した瞬間から作品のあちこちに関係を作ります。会話の呼び名、家族の名簿、小道具の刻印、手紙の署名、推理の手掛かり。新しい姓を思い付いても、それらが一緒に成立するとは限りません。このツールでは、人物IDに結び付けた使用箇所を単位として変更案を作り、旧表記と新表記、その変更が壊すかもしれない条件を分けて確認します。

新しい名前を生成する作業とは入口が異なります。ここでは、変える前の表記、変更したい表記、確認した使用箇所を持ってきます。原稿内の全参照を自動発見することも、似た文字列から同一人物を推定することもしません。美しい候補が見つかった後に、それを今ある物語へ導入できるかを考える編集用のページです。

同じ名前の二人が登場するなら、人物IDを分けてください。初期例には、どちらもAven Reedと書く別人がいます。対象をaにすると、bの箇所は変わりません。文字列が等しいことと、物語内で同一人物であることは別です。ここでの対象判定は作者が確認した人物IDに従います。

六つの欄で変更の境界を決める

使用箇所の表には、使用箇所ID、人物ID、表記キー、現在の文字列、変更の許可、素材または場面を入力します。使用箇所IDは、一つの編集判断が行われる場所を示します。人物IDは、誰を指すかを示します。表記キーはfull、short、signatureなど、姓名、短い呼び方、署名といった役割を作者が区別するためのものです。

現在の文字列には、変更対象になる欄全体を入れます。長い段落に名前が何回含まれるかを、このツールは解析しません。許可はreplaceまたはlockです。lockの行は対応表があってもそのまま残ります。場面や素材の欄は「第2章の台詞」「旅行鞄の刻印」「昔の手紙の引用」など、後で追える名前にします。

素材の欄も復元条件に含まれます。後の編集で、その使用箇所が別の絵や場面へ転用されたなら、古いパッチで機械的に戻さないためです。一つの表は200行までに分け、入力全体にも上限を設けています。巨大な作品を小分けにする場合は、どの巻、どの素材、どの版まで点検したかを別に残してください。入力がないことは、依存関係が存在しない証明ではありません。

姓を変えても愛称や署名は推測しない

表記の対応は、キー、完全一致する旧表記、新表記の三列です。fullのAven ReedをAven Valeへ変えても、別のキーにある愛称、署名、家族の姓までは推測しません。同じ改稿に含めるなら、それぞれ別の対応を入力します。一つのキーを二度使うと、競合する指示になるため処理を止めます。

対象の人物ID、表記キー、旧表記がそろい、replaceが指定された行だけが変更案に入ります。現在の文字列が旧表記と違えば、その行は未解決として残します。部分一致で無理に置き換えたり、似ている文字を補正したりしません。対応がないキーも未解決です。入力のずれを直すか、意図した例外として固定するかを作者が選べます。

表示する名前そのものは正規化して上書きしません。後で説明する依存条件の比較には限定した処理がありますが、その処理を理由に元の表記を消すことはありません。異体の表記や別言語版を同一視する必要があるなら、その判断を対応表と使用箇所のIDで明示します。見た目が似ているだけでは人物を統合できません。

初期例では何が変わるか

対象aの初期例を実行すると、通常の台詞と旅行鞄に関わる参照がAven Valeへ変わります。人物bが持つ同じAven Reedは変わりません。昔の文書の引用もlockなので維持します。この画面で表示するのは編集案です。端末上の原稿、画像、文書を開いて変更する処理はありません。

旅行鞄の使用箇所には、ARという頭文字の条件が結び付いています。現在の比較方法ではAven ReedはAR、Aven ValeはAVになります。この差が再点検の対象です。「刻印を描き直す」という修正メモを入力しても、絵が完成して確認された扱いにはしません。予定した作業と、完了した判断を分けるためです。

「復元可能な使用箇所パッチ」は、実際の変更箇所だけを旧表記、新表記、人物、表記キー、素材とともに書き出します。「提案する使用箇所の表」は、変更しない行も含む全体と、フォームへ戻せるworksheet文字列を含みます。前者は差分の記録、後者は確認範囲の状態です。どちらも原稿が自動更新済みだと証明するものではありません。

創作例：犯人を早く絞ってしまった鞄

作画担当は二つの冷めたカップの間に、旅行鞄の絵を置いた。真鍮の角金には細かな傷があり、駅の照明を受けた蓋にARの文字が光っていた。

改稿後、その持ち主はAven Valeになっていた。主要人物にReedがもう一人いたため、会話で区別しやすい姓を選んだのだ。作業中の章では、吹き出しの姓名はすべて新しい表記になっていた。

ところが最後のページで、探偵はまだ鞄を指して言う。「あなたの頭文字ですね」

「前の稿では」と作者が答えた。

この鞄は背景の飾りではなかった。持ち主の顔が見える前に、読者は鞄をホームへ運ぶ手だけを見ている。ARは二人に当てはまり、最初の追及では一人に絞れない設計だった。一人をAVへ変えたことで、もう一人だけが残った。推理の台詞を一行も変えずに、答えらしきものが四ページ早く現れたのである。

文字を塗り替える案が出た。AVにすれば新しい持ち主とつながる。しかし、それだけでは二人に当てはまる曖昧さが戻らない。AVという別の人物を増やすなら、編集の事故を直すためだけに登場人物を作ることになる。探偵の台詞を消すなら、先に鞄を見せた構図の目的も考え直さなければならない。

編集者は検索窓ではなく台帳を開いた。鞄の行に手掛かりの依存条件を付け、通常の呼びかけと分けた。昔の荷札の引用には、意図した誤記があるためlockを付けた。別の新聞記事に現れる同姓同名の人物には別IDがあり、今回の変更には入らなかった。

最後にチームは新しい姓を維持し、鞄の持ち手にある修理跡を手掛かりとして組み直した。前の場面には修理店を利用した人物がすでに描かれている。頭文字は断定に使えない情報として残り、探偵の問いも修理店への出入りを尋ねるものへ変わった。作画担当は必要なコマを直したが、過去のARという文字をすべて消したわけではない。

作者は結末を見ないつもりで駅の場面を読み直した。必要な時点ではまだ二つの説明が残っていた。新しい名前は会話を改善したが、物語を直したのは、その結果を点検して作り直した判断だった。これはオリジナルの架空の制作例です。実在の利用者の体験談や、画像編集ソフトとの連携実績ではありません。

別の名前なら何が残ったか

Aven ReedからAven Roweへの変更なら、このツールの頭文字はARのままです。その依存条件は「文字条件は維持・場面は未承認」として表示されます。だからといって、場面全体が安全とは限りません。姓の並べ替え、親族との共通性、文字数、誰がどの署名を知っているかなど、別の機能が変わる可能性があります。

改名の検討では、各参照が何をするのかを言葉にしてください。姓だけで呼ぶ台詞は距離感を示すかもしれません。正式な署名は所属を明かすかもしれません。刻印は部屋に入れた人物を絞るかもしれません。表記の変更と、その表記が担う役割の変更は、別に確認する必要があります。

機械的な比較に収まらない条件にはmanualを使えます。「この引用を読んだ人物だけが正体を知る」など、守るべき条件を書きます。該当箇所が変わったmanual条件は常に再点検へ送ります。作者の意図を理解したふりをして、合格にすることはありません。

依存条件の比較方法を限定する

initialsは空白とハイフンで表記を分け、各部分の最初のUnicodeコードポイントを取り、実装で指定した方法で大文字にします。これは再現のための編集上の規則です。すべての言語で正しい頭文字やモノグラムを求める規則ではありません。区切りのない名前や結合文字が関わる表記は、手動の条件を別に設けてください。姓と名の順も推測しません。

anagramはNFCで正規化し、小文字化した後、Unicodeの文字と数字を残してコードポイント順に並べます。この比較に限って空白と句読点を除きます。別の文字体系、翻字、アクセントのない形を同じものとは扱いません。同じ結果なら、その文字の集合がこの方法では変わらなかったという意味にとどまります。謎が公平で解けるという保証ではありません。

textは入力された表記を比較します。manualはプログラムに判定させない創作上の義務を記録します。どの場合も、影響した行には変更前後、記録した条件、修正メモを表示します。条件は文脈を残すためのもので、正解を自動判定する基準としては扱いません。メモだけで修正を完了にしない点も共通です。

後から加えた編集を守って復元する

復元を試すときは、操作を条件付きの復元案へ変え、現在の使用箇所と保存したパッチJSONを入力します。対応する形式、種類、対象人物が一致し、編集IDが重複していないことを確認します。その後で、人物ID、表記キー、素材、現在の文字列、lockの状態を各行で照合します。

現在の文字列がパッチの変更後と一致する行だけ、旧表記へ戻す案を作れます。別の編集者がさらに変更した行、素材名が変わった行、固定した行は保持し、理由を表示します。ほかの行だけ復元できる場合は、一部のみの結果として明示します。原稿を管理しているツールではないため、原稿全体を一括で元に戻したとは言いません。

復元案から書き出すパッチも、今回提案した差分だけを記録します。前の変更後と一致しなくなった行に、同じ復元を繰り返して新しい編集を消すことはできません。ただしこれは暗号による認証ではなく、入力した文字列と人物の照合です。読み込むファイルを確認し、プロジェクトの別のバックアップも維持してください。

採用の前に読者のいる場面へ戻る

変更を採用する前に、未解決の表記、固定した例外、影響する依存条件を一つずつ見ます。残した古い姓に説明が必要なのか、修理する手掛かりは前のコマまで直す必要があるのかを確認します。差分の書き出しは、そうした創作上の作業を終えた印ではありません。

採用した使用箇所の表とパッチ、直した素材を同じ版の資料として残します。確認していない巻や言語版も記録してください。その後で群像の区別や推理の候補を確認するなら、対応する専用ツールへ進みます。このページの役割は、確認済みの参照をどこまで一緒に変えられるか、その変更が何を揺らすかを明らかにすることです。全原稿の完全性、権利上の安全、読者の理解を保証するものではありません。

原稿の名前をすべて見つけますか

いいえ。作者が確認した使用箇所IDと人物の対応を入力します。見えていない段落、画像、外部の文書は解析しません。確認範囲と別の版を記録してください。成功するパッチの範囲も入力した箇所だけです。

同姓同名の別人を維持できますか

人物IDで対象を限定するため、同じ文字列でも別人の行は変わりません。対応が正しいかは作者が先に確認します。誤って付けた人物IDを、ツールが物語から推定して直すことはありません。

頭文字が同じなら推理の場面は合格ですか

この比較方法での文字条件が残っただけです。接触できた人物、家族の関連、言語上の慣例、別の説明が変わる可能性があります。場面を読み直し、計算できない条件はmanualで記録してください。

別の編集者が変更した後で復元するとどうなりますか

記録した変更後の文字列、人物、表記キー、素材が合わない行や固定した行は保持します。ほかの行だけ戻せるなら一部のみの復元案と表示します。元の原稿を直接操作する機能ではありません。