KDP用原稿を修正するときは、本文、目次掲載、表紙、奥付・書誌の正本を別々に保ち、生成物から修正元へ戻れる対応表を残します。今回の標本は四章小説、表紙1枚、奥付用ファイル1件です。第三章の本文KDP481-03 本文をKDP481-03 修正版本文へ1件だけ変更し、同じ入力一覧で変更前後のEPUBを生成しました。
両版ともローカル構造検査はvalid=trueで、ファイルサイズは7,211バイトから7,224バイトへ変化し、SHA-256も別の値になりました。この結果が示すのは「第三章の正本を直して別のEPUBを再生成できた」ことです。KDP審査や表示確認まで終わったことではありません。
答え：KDP原稿は「生成物→正本」の戻り先を四系統で残す
一般的な原稿管理では、本文修正は章ファイル、目次の過不足は章順・目次掲載、表紙差し替えは表紙画像、著者名や発行日は書誌・巻情報または奥付の元データへ戻します。完成EPUBだけを保管すると、修正依頼が来たときに、どの入力を直せば同じ一冊を再現できるか分かりません。
そこで、生成物ごとに「原稿版」「設定版」「出力ハッシュ」「検査結果」を組にします。STUDIO-407が初回のローカルEPUBを作る順序を扱うのに対し、この記事は一度できたKDP用原稿へ修正が入った後の追跡に集中します。STUDIO-377のEPUBデータ編集よりも、KDP提出候補の変更前版を残し、受け渡し履歴を切らさないことが中心です。
標本と開始値：第三章以外を固定する
専用複製にはchapters/01.md〜04.md、chapters/99-colophon.md、images/cover.pngを置きました。作品名は「四章小説 STUDIO-481」、著者は「海野灯」、出版社は「Evidence Press」、ファイル名はstudio-481、横書き、日本語、単巻0、版1.0、発行日2026-08-31です。タイトルページ位置0、目次ページ位置1で5ファイルを同じ順に選びました。
修正前に記録するのは、第三章の旧本文、四章と奥付の順番、表紙パス、著者、出版社、発行日、出力先beforeです。修正後は第三章の新本文と出力先afterだけを変えます。これで、差分が第三章の1件に帰属します。
操作：変更前版を検査してから第三章を1件だけ直す
1回目は作品情報、巻、表紙、原稿一覧、タイトル・目次位置を設定し、計画、出力、検査を行いました。そのEPUBをbeforeへ保存した後、第三章の対象文字列を1件置換しました。次に表紙と同じ5ファイルを再指定し、同じ固定日時で計画、出力、検査を行い、afterへ保存しました。最後に二つのEPUBを差分検査しています。
Rune Studioの公開画面で置き換えると、本文修正はエディタ、原稿一覧と順序はEPUBウィザードのファイル選択・チャプター順、表紙はメタデータ、著者・発行日はシリーズ情報・巻選択です。変更前EPUBを上書きせず、変更後と別名で残すことが、KDP原稿の戻り先を守る要点です。
実測：両版valid、7,211→7,224バイト、SHAが変化
記事別Stage 4はstatus=passed、command_count=17です。input_chapters=4、controlled_replacements=1、first_valid=true、second_valid=true、epub_sha_changed=trueでした。変更前EPUBは7,211バイト、SHA-256はa25e45f6c454ba19db1117f9154157772e5832a8b1cdd22d63f066b65a178abf、変更後は7,224バイト、1e7363617c3e863c8320e9bcb9299c61924c025d16d4af63afd08de5445d992eです。差分判定はidentical=falseでした。
両版の個別inspect記録では、spineは9件で、cover.xhtml、title.xhtml、nav.xhtml、p001.xhtml〜p005.xhtml、colophon.xhtmlでした。画像1件、欠落0件、nav・NCXあり、valid=trueです。これにより、第三章修正後も表紙・奥付を含む同じ構成を再生成したことを確認できます。
別の共通Stage 4は3章、横書き、版1.1、spine 7、画像1、欠落0、nav・NCXあり、valid=trueを9操作で確認しています。これは基本経路の証拠であり、四章の第三章修正を二版比較した17操作の代わりにはしません。
失敗時は症状に対応する正本へ戻る
第三章の修正が出力へ入らない場合はchapters/03.mdと選択中の原稿一覧へ戻ります。章順や目次が変わった場合はファイル選択とチャプター順、表紙が違う場合はimages/cover.pngと表紙指定、著者・発行日が違う場合はシリーズ情報・巻情報と奥付用ファイルへ戻ります。生成済みEPUBを直接修正して履歴を合わせません。
ハッシュが同じなら、修正が反映されなかった可能性を調べます。ハッシュが違っても、それだけで修正内容が正しいとは言えません。本文の対象箇所、spine、画像欠落、nav・NCXを同じ版IDで確認して初めて受け渡し候補になります。
限界：KDPの受理と表示は別の検査
今回確認したのは、専用複製で生成した二つのローカルEPUBの内部構造と差分です。KDPへのアップロード、審査、販売登録、Kindle Previewer、実機の目視、全リーダーの表示一致は未確認です。valid=trueやidentical=falseを、外部提出先の合格へ読み替えません。
Amazon KDPは対応原稿形式としてEPUBを案内し、ガイドライン適合とKindle Previewerでの確認を勧めています。ローカル生成の次にKDPへ進む場合は、その外部検査結果を変更後版の記録へ追加します。
Rune Studioで管理できる範囲
現行Mac版Rune StudioのStage 3資料では、ワークスペースで複数原稿とEPUB設定を作品単位に管理し、6ページのEPUBウィザードで作品情報、巻、原稿順、目次掲載、表紙、発行日を指定できます。出力にはXHTML本文、タイトル、目次、奥付、表紙、nav.xhtml、旧リーダー互換用NCX、content.opfのmetadata・manifest・spineが含まれます。
EPUB 3.3仕様のパッケージ文書やspineは一般規格です。Rune Studio独自の形式ではありません。Rune Studioは元原稿と設定から再生成する手段であり、KDP審査を代行するものではありません。現行製品範囲はRune Studioの商品ページで確認できます。
結論：修正前版を残し、第三章へ戻れる状態で渡す
今回のKDP原稿は、四章、表紙、奥付を固定し、第三章の本文1件だけを直しました。変更前後ともspine 9、画像1、欠落0、nav・NCXあり、valid=trueで、サイズとSHA-256が変化しました。修正前版と修正後版を別々に残したため、問題があれば第三章の正本へ戻れます。
最初に作るべきものは、提出ファイルではなく正本対応表です。本文、目次、表紙、奥付・書誌の四系統について、入力パスと版、出力ハッシュ、検査結果を1行ずつ結びます。KDP側の確認はその後に別欄で追加し、ローカル合格と混ぜないでください。
