EPUB作成ツールの再生成テストでは、ファイルがもう一度できたことだけを合格にしません。原稿、目次、書誌、表紙という四入力を一つの編集可能なプロジェクトへ組み、原稿を編集した後の再生成物で、宣言した変更がどこまで反映され、どこで欠落したかを入力別に確かめます。
この記事では、二章の短編「港町の手紙」を一つのプロジェクトへ組み、初回出力を基準にしたうえで、原稿編集を含む四入力の変更票を作ります。候補A/Bへ同じ一字改稿を配って二周の優劣を決めるSTUDIO-030とは異なり、比較対象はツール候補ではありません。同じプロジェクトの基準出力と再生成物を一度だけ照合し、複数入力の反映境界を閉じるのが本記事の役割です。
四入力と観測先を一組にする
まず、四つの変更入口と生成物内の観測先を対応させます。原稿は本文XHTML、目次はEPUBナビゲーション文書、書誌はパッケージ文書の書誌情報、表紙は表紙資源とその参照が観測先です。入力画面があることと、生成物へ反映されたことは別の判定にします。
準備票には、入力ID、基準値、戻り先、観測先の四欄を作ります。「港町の手紙」なら、原稿は二章の作業用複製、目次は二つの表示名と行き先、書誌は作品名・著者名・言語、表紙は画像候補と利用可否です。未確認の項目は空欄にせず「未確認」と書きます。
四入力を一つの編集可能なプロジェクトへ登録し、それぞれの戻り先を一度開きます。章本文を直せても目次の行き先を直す場所が分からない、あるいは表紙候補を選べても代替テキストの入力元が不明なら、再生成試験の準備は未完了です。
初回出力を基準として固定する
変更前に、同じプロジェクトから初回出力を作り、プロジェクトID、入力リビジョン、生成物IDを固定します。たとえば入力をharbor-project-r01、基準出力をharbor-baseline-01.epubとします。正本を直接上書きせず、試験用の編集可能プロジェクトを使います。
基準表には、第一章と第二章の本文、二つの目次表示名、作品名・著者名・言語、表紙状態を記録します。表紙なしなら「表紙なし」を基準値にします。表紙付き生成物を確認していないのに、候補画像が入力欄にあるだけで「表紙あり」と記録してはいけません。
初回出力の検査は、後で変更を見分けるための基準採取です。表紙、EPUBナビゲーション文書、パッケージ文書、spineを網羅採点するSTUDIO-122の受入検査へ広げず、四入力について変更前の値を読めるかだけを記録します。
原稿編集を含む四入力の変更票を作る
次に、harbor-project-r01をr02へ進め、変更票へ四行を宣言します。例は次のとおりです。
- 原稿：第二章の冒頭へ確認用の一文を追加する。期待先は第二章の本文XHTML
- 目次：第二章の表示名を「第二章 帰港」へ変える。期待先はEPUBナビゲーション文書
- 書誌：仮の著者名を承認済み表記へ変える。期待先はパッケージ書誌
- 表紙：表紙なしから候補画像へ変更する。期待先は表紙資源とパッケージ内の参照
変更は実案件で承認された内容を使い、確認用の文を正本へ混ぜないよう試験用複製で行います。重要なのは、原稿編集だけでなく、同じ再生成で確認する入力を先に列挙することです。宣言していない項目の偶然の差を、後から都合よく成功条件へ加えません。
この四行は候補A/Bの比較表ではありません。変更するプロジェクトは一つ、再生成物も一つです。一字だけを共通刺激にして二候補を順位付けするSTUDIO-030とは、試験単位も判断目的も分けます。
同じプロジェクトから一度再生成する
四入力を保存したら、初回出力と同じプロジェクト、同じ作品単位からharbor-regenerated-02.epubを一度生成します。生成前に、プロジェクトがr02であること、出力先に古いbaseline-01が残っていても新しい生成物IDを発行することを受け渡し票へ書きます。
再生成中にエラーが出た場合は、出力ファイルの有無だけで続行しません。エラー時点、保存済みの入力リビジョン、生成されたファイルのIDを記録し、その生成物は「判定対象外」とします。古い基準出力を新しい結果と思い込むのを防ぐためです。
生成後は、成果物を直接直しません。欠落が見つかった場合も、XHTMLやパッケージ文書を書き換えて見かけ上そろえるのではなく、変更票に記録して元の入力へ戻します。これで「編集→再生成→受入」の境界を保てます。
反映・欠落・未確認を入力別に判定する
再生成受入では、変更票の四行を一行ずつ確認します。判定語は「反映」「欠落」「未確認」の三つに固定します。「反映」は宣言した新値を期待先で確認できた状態、「欠落」は基準値のまま、別の値、または必要な参照がない状態です。観測先を開けない、権利確認が終わらないなど証拠が足りない場合は「未確認」とします。
たとえば原稿の新しい一文は反映、目次表示名は旧値のままなら欠落、著者名は反映、表紙は資源があっても参照を確認できなければ未確認です。三項目が反映されても、残る一項目を総合点で丸めません。欠落行には基準値、期待値、実測値、戻る入力元を残します。
ここで調べるのは宣言した複数入力の伝播境界です。生成物全体の品質を合否採点するSTUDIO-122とは分けます。本文の新しい一文が入ったからといって、目次、書誌、表紙まで反映されたとは推定しません。
Rune Studioの確認済み範囲を越えない
Rune Studioの全機能資料と実装資料には、ワークスペースで原稿や資料を作品単位に管理し、6ページのEPUBウィザードで書誌、目次、表紙などを入力・確認する構成が記載されています。この段落の根拠は資料とコードの静的確認に限るStage 1であり、実画面で入力項目や配置を確認したStage 3の証拠ではありません。
2026年8月11日に確認済みなのは、専用ワークスペースから出力した表紙なし二章EPUBがvalid=trueとなり、EPUBナビゲーション文書、補助的なNCX、パッケージ書誌、spine順を確認した一回の出力です。これは基準出力を作れる範囲のStage 4証拠です。
一方、原稿編集を含む四入力の変更後に同じプロジェクトから再生成し、すべての反映境界を検査する操作は未実施です。表紙付き生成物も未実施です。したがって、前節の再生成受入はRune Studioで次に実行する試験手順であり、製品が合格済みという主張ではありません。
再生成テストは変更行ごとに閉じる
EPUB作成ツールの再生成テストは、四入力を一つの編集可能プロジェクトへ組み、初回出力を基準にし、原稿編集を含む変更票を宣言してから同じプロジェクトで再生成します。判定は入力ごとの反映・欠落・未確認です。
まず手元の一作品で、原稿、目次、書誌、表紙の基準値と観測先を四行にしてください。次に承認済みの変更を記録し、新しい生成物IDで一度再生成します。欠落は成果物へ直書きせず入力へ戻します。この工程なら、二候補の一字改稿比較にも、完成物の網羅採点にも寄らず、編集後の複数入力が再生成物へ届いたかという固有の受入を実際に行えます。
