モデルは提案し、システムは検証する

文章が自然でも、識別子が間違っていることはある。画像が美しくても、必要な寸法を満たしていないことがある。項目が埋まった書誌情報でも、別の原典を指しているかもしれない。編集工程では、もっともらしさだけで品質を判断できない。繰り返し確かめられる事実が必要になる。

そこで役立つのが、「モデルは提案し、システムは検証する」という分担である。創造的な仕事をすべてモデルに渡す、という意味ではない。確率的な提案と、決められた条件を調べる検証には、異なる役割と権限があるという整理だ。

提案は可能性を開く

モデルは構成案を作り、文章を言い換え、複数の表現を示し、矛盾の可能性を指摘できる。その価値は、探索を助ける点にある。読むべき場所を見つけたり、人が検討する選択肢を増やしたりできる。

しかし、流暢さは証拠ではない。提案は提案として識別され、許可された出典と結び付けられ、人の判断を待つ必要がある。自信に満ちた文体でも、承認には変わらない。

検証は限定された問いに答える

決定論的な検証は、明確な性質を調べる。ファイルは存在するか。チェックサムは一致するか。期待する識別子が含まれるか。カルーセルは七ページか。宣言された言語と制作物は一致するか。公開の扉は閉じたままか。

この検証の強さは、範囲が狭いことにある。同じ入力に同じ規則を適用し、結果を記録し、失敗を明示できる。一方で、題名が優れているか、翻訳の呼吸が自然か、表紙がコレクションの精神に合うかは決められない。それらは別の問いである。

混同せずに組み合わせる

信頼できる工程は、提案、検証、判断を往復する。モデルが説明文を提案する。システムが必須項目、長さ、出典の識別、禁止された状態を確認する。その後、人が忠実さ、語調、意味の範囲を読む。

検証に失敗したとき、出力を黙って直して先へ送ってはいけない。差異を残し、関係する工程へ戻す。成功した場合も、その意味を広げない。「ファイルがある」は「内容が承認された」と同じではない。

失敗を情報として設計する

検証は、止める能力を持って初めて役に立つ。欠けた項目、異なるチェックサム、言語の不一致は、恥ずべき障害ではなく、現在の状態を示す情報である。何が失敗し、何がまだ有効で、誰が再開を判断するのかを示す必要がある。

この設計は二つの極端を避ける。もっともらしい提案を事実として受け入れること。そして、編集上の判断をすべて自動規則へ変えること。検証できる事実はシステムが担い、文脈と責任を必要とする判断は人が担う。

Maison Beaulieu の Publishing OS は、この境界を調べる社内 R&D プロトタイプである。商用検証済みの製品ではなく、外部での成果も主張しない。検証が扱うのは、対象、出典、状態、遷移であり、作品の文学的価値ではない。

「モデルは提案し、システムは検証する」は、完全自動化の標語ではない。慎重さのための文法である。出力ごとに、これは提案か、確認された事実か、それとも人の決定かを問う。三つを分けて記録できれば、工程は読みやすくなり、編集者の判断が必要な場所も消えない。

adrienbeaulieu.com