長い原稿を検索とハイライトで推敲するときは、第一周で候補を発見し、第二周で判断に必要な文脈資料を作ると分けます。第一周では出現位置と章別件数だけを集め、本文を直しません。第二周では各候補の前文・対象文・後文、話者、視点を採取します。これで、後の編集者が候補を見失わず、文脈を読んで判断できる材料が揃います。
この記事は、候補を正式形・意図的な例外・保留へ決裁するところまで進みません。承認済みの置換も、置換後の最終再検索も扱いません。役割は、判断の前に必要な候補資料を完成させることです。
検索しながら直すと候補の母数が変わる
「ふと」という口癖候補を検索し、最初に見つけた一件をその場で削除したとします。次の検索結果では件数が一つ減り、検索位置も動きます。その途中で「何か」も気になって検索語へ加えると、作業開始時に何を探していたのか分からなくなります。
さらに、最初の章では厳しく削り、後半では疲れて残すと、章ごとの偏りが原稿の特徴なのか作業者の判断差なのかを区別できません。
この問題を避けるため、発見中は本文を変えません。第一周の終了条件は、候補の良し悪しを決めることではなく、決めた範囲にある出現をすべて採番できたことです。
第一周は出現位置と章別件数だけを集める
最初に対象語と検索範囲を固定します。説明例では、対象語を「ふと」と「何か」、範囲を三章の複製原稿とします。
検索結果へ、語ごとではなく出現ごとの候補IDを振ります。たとえばD-001、D-002のように連番にします。各候補には次を残します。
- 候補ID
- 検索語
- ファイル名と章ID
- 場面見出し
- 対象文の短い引用
- その章で何件目か
この周回では「削除する」「残す」「著者へ確認する」と書きません。ハイライト色も正誤を表さず、「ふと=青」「何か=橙」のように検索語の区別だけへ使います。色は外部の候補一覧や推敲票に付ける目印であり、文章の評価ではありません。
三章を終えたら、章別件数を集計します。第一章に「ふと」が八件、第二章に二件、第三章に七件なら、その分布をそのまま残します。多い章を悪い章と決めるのではなく、第二周で文脈を詳しく採取する順番を決める材料にします。
第二周は前後文脈を候補カードへ移す
第二周では検索語を増減しません。第一周で採番した候補IDを順番に開き、判断に必要な周辺情報を集めます。
一つの候補カードへ、前の一文、対象文、後ろの一文を入れます。会話なら話者、地の文なら視点人物も添えます。必要に応じて、同じ段落内で指している対象や、場面内の時間を事実として書きます。
たとえばD-014の対象文が「彼はふと窓を見た」なら、前文で警報音が鳴ったこと、後文で窓の外に光を見つけること、視点人物が彼であることを採取します。ここでは「ふと」が必要か不要かを決めません。前後の出来事を揃え、後の判断者が動作のきっかけを読める状態にします。
対象文だけを切り出すと、口癖のように見える語が場面転換の合図だったり、曖昧に見える語が意図的に対象を隠していたりする可能性を落とします。第二周の目的は、この判断材料の欠落を防ぐことです。
章別偏りを候補地図へまとめる
候補カードが揃ったら、章ごとの出現数と場面位置を一枚の候補地図へまとめます。
見るのは、単純な総数だけではありません。章の冒頭に集中しているか、会話に多いか、同じ視点人物の場面へ偏っているか、近接する三段落に固まっているかを、候補IDの位置から確認します。
たとえば第一章の八件がすべて別場面に散らばり、第三章の七件が一つの会話場面に集中しているなら、同じ七〜八件でも分布は違います。この違いを資料へ残せば、後の決裁で一括して同じ扱いにする危険を減らせます。
候補地図にも評価語を入れません。「過剰」「誤り」「例外」ではなく、「第一章8件」「SC12に4件」「主人公視点6件」のような観察事実だけを書きます。
発見漏れはIDと件数で点検する
第一周の候補一覧と第二周のカードを照合します。候補IDがD-001からD-017まであるなら、カードも十七枚必要です。章別件数の合計も十七件になるか確かめます。
カードが欠けていたら本文を直さず、そのIDの文脈採取へ戻ります。第一周の一覧にない候補を第二周で見つけた場合は、勝手に末尾へ混ぜず、「追加発見」として検索条件と発見理由を記録します。これは正式形の決裁ではなく、発見工程の入力漏れを示す記録です。
終了時に必要なのは、検索語ごとの候補一覧、章別分布、全候補の文脈カードです。置換後の残数や例外数は、この工程の完了条件ではありません。
Rune Studioは候補を探す入口として使う
Rune Studioの機能資料には、ファイル内検索、ワークスペース横断検索、選択したファイル・フォルダ・パスを対象にする検索が記載されています。これは文書記載の確認であり、現行版の実画面や検索操作を確認した証拠ではありません。単一ファイルを見る、作品全体から探す、対象ファイルやフォルダを絞るという発見条件を分ける候補範囲に関係します。
ファイル内検索で選択中の文字列を検索語として使えるという資料記載と、本文の選択範囲だけを検索対象にすることは別です。本記事では後者を文書化された機能としても、実画面で確認した機能としても扱いません。候補にする対象範囲は、資料に記載されたファイル、ワークスペース、選択ファイル・フォルダ・パスの単位で固定します。
一方、Rune Studioが「ふと」を不要な口癖と判定する、「何か」を曖昧語として採点する、候補を正式形・例外・保留へ自動分類するとは書けません。候補ID、色、章別分布、文脈カードは編集側が作る資料です。
この記事では置換機能を中心にしません。検索結果を変えずに集め、文脈資料を完成させるところで止めます。製品上の検索範囲を確認した事実と、説明例の十七件を実測した事実も分けます。
正式形・例外・保留の決裁はSTUDIO-339へ渡す
STUDIO-339は、集まった表記候補を正式形、意図的な例外、保留へ分け、担当者や再確認条件を含む判断待ちキューを作る記事です。根拠が確定した行の反映や、その後の照合もそちらの役割です。
本記事から渡すのは、候補ID、検索語、出現位置、章別偏り、前後文脈、話者・視点です。「この候補は直すべき」という結論は添えません。発見担当が決裁まで行うと、候補を拾う基準と判断する基準が同じ周回で変わるためです。
結論：二語の候補資料を完成させる
最初は「ふと」と「何か」の二語だけで十分です。第一周で三章の全出現を採番し、章別件数を出します。第二周で各IDへ前文・対象文・後文、話者、視点を付けます。
候補一覧のID数、章別件数の合計、文脈カード数が一致したら、発見資料は完成です。本文はまだ変更しません。その資料を次の決裁工程へ渡せることが、検索とハイライトを二周に分けるこの記事の結論です。
検索範囲を切り替えて候補を集めたい場合は、Rune Studioの製品ページで現行の検索範囲を確認し、まず二語・三章の複製原稿で候補資料を作ってください。
