画像を移動したら旧パス0件・新パス1件まで追う
画像入り原稿を整理するときの要点は、ファイルを新しいフォルダへ移すことではなく、原稿の参照も同じ移動先へ切り替わったと確認することです。今回の検証では、移動前の参照1件、移動後の旧パス0件、新パス1件、生成物内画像2件まで追跡できました。ただし、事前の参照更新計画が0件だったため、全体のstatusはpartialです。
一般手順では、移動前に参照件数を数え、画像を移し、原稿のパスを更新し、旧パスが0件になったことを逆検索してからEPUBを作ります。最後にパッケージ内の画像点数とmissingを調べます。移動、参照更新、出力を一操作のように扱うと、どこで不整合が起きたか分からなくなります。
三章・画像2枚・表紙なしで三層を固定する
標本は三章、本文画像2枚、表紙なしです。企画上の画像名はmap.pngとchart.pngです。記事固有Stage 4の専用コピーでは、対応する検証素材がfigure01.pngとfigure02.pngとして記録されました。名称を混同せず、重要な開始値を「章3、本文画像2、表紙0」に固定します。
確認する層は三つあります。第一層はimagesやassetsにある実ファイル、第二層は章内のMarkdown参照、第三層はEPUBへ格納された画像です。第一層だけを動かして第二層を直さなければ参照切れになり、第二層が直っても第三層を検査しなければ古い生成物を見ている可能性が残ります。
移動前参照、移動、明示更新、再生成の順で操作する
専用コピーでimages/figure01.pngへの参照を調べると、fileCount 1、occurrenceCount 1でした。次に参照更新のplanを実行しましたが、ここはfileCount 0、occurrenceCount 0でした。この0件は見過ごせません。更新対象を自動的に列挙できたという証拠が得られなかったからです。
その後、画像をimages/figure01.pngからassets/figure01.pngへ移動し、参照を明示的に書き換えました。rewriteはrewrittenFiles 1、occurrenceCount 1です。逆検索では旧参照../images/figure01.pngが0件、新参照../assets/figure01.pngが1件となり、chapters/01.mdの8行目に新参照が残りました。
この時点で三章をplanし、fileCount 3、chapterCount 3、valid trueを確認してからexportとinspectへ進みました。失敗時は、実ファイルがなければ移動先へ、旧参照が残れば原稿へ、生成物に画像がなければ出力工程へ戻ります。
実測は出力成功でも、ワークフロー全体はpartialである
生成されたstudio-387-260831.120000.epubは6,213 bytesで、SHA-256は761dで始まります。inspectはentryCount 13、spineItemCount 6、imageCount 2、missing 0、nav.xhtmlあり、NCXあり、各ナビゲーション項目3件、valid true、issues空でした。移動後の新参照1件が原稿に残り、旧参照は0件で、二つの画像がパッケージへ入りました。
ここから言えるのは、明示的な移動と参照書き換えを行った専用コピーでは、三章・画像2枚のEPUBを構造上欠落なく出力できた、ということです。参照更新planが対象を0件としたため、「移動を計画すれば参照が自動で追従する」「一連の経路が全面的に合格した」とは言えません。statusはpartialのままです。
共通基準走行は五章、画像1件、横書き、version 1.7で、spine 9、missing 0、nav.xhtmlとNCXあり、valid trueでした。これは通常の出力経路の補助証拠であり、今回の参照更新plan 0件を成功へ読み替える材料ではありません。
partialの停止点と外部未確認範囲を残す
同じ条件を再実行するときは、参照更新planが0件を返した時点で止まり、対象パスとコマンド条件を確認します。自動計画を信用して移動を続けず、移動前の参照数と実ファイルを記録した状態へ戻します。今回の明示書き換え結果は、計画段階の不足を消しません。
また、この検証は専用コピーへの明示的なCLI操作です。Finderやクラウドストレージで移動したファイルを自動追跡する挙動、画像の見た目、KDPなど外部サービスの受理、実機や全閲覧アプリでの表示は確認していません。EPUBのmanifestとspineの役割はEPUB 3.3に基づきますが、標準構造への適合と外部環境での結果は別です。
Rune Studioの公開機能と今回の証拠を分ける
Rune Studioの公開機能には、txt、text、md、markdown内の相対画像・リンク参照を対象とするパス更新があります。../を含む相対参照を扱い、外部URLとページ内アンカーは対象外です。開いているファイルと閉じている対象ファイル、表紙パスの更新も製品機能の範囲に含まれます。
それでも、この記事で確認できたのは専用コピー上の明示的な移動、明示更新、検索、EPUB出力です。今回0件だった参照更新planまで合格したとは扱いません。公開機能の説明と、個別の実測結果を分けて読む必要があります。
結論：移動は追跡できたが、自動計画は未証明である
画像整理後の手戻りを防ぐには、移動前参照1件を起点に、旧パス0件、新パス1件、パッケージ画像2件、missing 0件まで追います。今回の専用コピーでは、その明示的な経路と三章の出力結果を確認できました。
ただし、参照更新planは0件でした。したがって結論はpartialです。次回はplanが対象を列挙できる条件を確認してから先へ進み、0件のままなら移動前へ戻って止めるのが安全です。
