一冊になるまで見通せる！電子書籍制作、複数アプリを行き来しない制作

電子書籍制作でアプリの往復を減らすコツは、完成したEPUBを直すのではなく、本文・作品情報・表紙・奥付それぞれの「直す場所」を最初に一つへ決めることです。どのアプリを使うかより、修正が必ず元ファイルへ戻る仕組みのほうが効きます。

ここでは、四章のエッセイを例にします。本文はchapters/01.mdから04.md、作品情報はbook-info.md、表紙はassets/cover.png、奥付はcolophon.mdです。出力したEPUBは確認用であり、原稿の正本にはしません。

まず「誰が直すか」を一枚にする

アプリを行き来する制作では、同じタイトルや著者名が複数の場所に複製されがちです。表紙の文字だけ直し、作品情報が古いまま残る。目次側で章名を直し、本文見出しへ戻し忘れる。こうした食い違いは、アプリ数そのものではなく、修正先が複数あるために起こります。

四章エッセイなら、次の表を先に作ります。「担当」は人ではなく、変更を受け持つファイルです。

この表で大切なのは、目次の章名を「目次専用データ」として増やさないことです。本文見出しを直したら、次の出力で目次にも反映させる。表紙の作品名が違えば、表紙画像だけをその場で直すのではなく、book-info.mdとのどちらが正しいかを決めてから戻します。

受け渡し回数を数える

往復を減らせたかは、感覚ではなく「別のアプリへ渡した回数」で数えます。たとえば従来の流れが、本文を目次作成へ2回、作品情報を表紙とEPUB設定へ2回、表紙を画像処理から出力へ1回、奥付を編集と出力の間で2回、検査結果を本文編集へ1回戻すなら、合計8回です。

一つのワークスペースで元ファイルを参照し、修正先も上の表へ固定する案では、表紙画像を用意した後のアプリ間受け渡しを0回にするのが目標です。これは今回の作業例に置いた目標値で、実測値ではありません。自分の制作では、開始前と終了後に同じ数え方で比較してください。

判断は単純です。受け渡しが減っても、修正先が分からない項目が一つでもあれば不合格。回数が0にならなくても、各変更が一つの正本へ戻り、同じ材料から再出力できるなら運用できます。

四章エッセイを一周させる手順

1. chapters、assets、作品情報、奥付を一つの作品フォルダへ集めます。元データは複製して残します。
2. 章名、作品名、著者名、表紙、発行情報を上の表へ記入します。同じ値を二つの正本へ持たせません。
3. 出力設定では横書き、4章の順番、目次対象、表紙1枚、奥付1枚を指定します。ここで直したい点が見つかったら、設定画面で場当たり的に書き換えず、表の戻し先へ戻ります。
4. EPUBを作ったら、目次があるか、読む順番が4章どおりか、表紙が収録されているか、参照切れがないかを確認します。
5. 修正を正本へ反映してもう一度出力します。二回目も同じ章順・書誌・収録物になることを確認し、最後に受け渡し回数を数え直します。

一般的なEPUB 3では、書誌情報、収録ファイル、読む順番、ナビゲーションは別の役割を持ちます。EPUB 3.3の構造を理解すると、見える目次だけを確認して終える危険を避けられます。

今回わかったことと、まだ試すこと

Rune Studioの現行Mac版については、縦書き・横書き、章順、目次、表紙、奥付を設定してEPUB 3へ出力できることが公開資料に記載されています。四章・横書き・本文画像なしの例を出力した確認では、ナビゲーション文書とNCXがあり、画像1点が収録され、欠落は0件でした。ローカルの構造確認も正常でした。

一方、この確認で測ったのはEPUBの構造です。8回から0回という受け渡し削減や、修正が毎回同じ正本へ戻ったことまでは測っていません。販売先での受理や、すべてのリーダーで同じ表示になることも含みません。導入前には、上の表を自分の四章原稿へ当て、開始前後の受け渡し回数と修正先を実際に記録してください。

結論は「一アプリ」より「一つの戻し先」

複数アプリを行き来しない電子書籍制作は、機能を一画面へ集めるだけでは完成しません。本文、作品情報、表紙、奥付の正本を決め、生成したEPUBで見つけた修正を必ずそこへ戻す。これが、版の食い違いを減らす判断基準です。

まず四章、作品情報カード1枚、表紙1枚、奥付1枚で正本表を作ってください。Rune Studioの現行Mac版を制作候補として確認するなら、詳しくはこちらから機能範囲を見られます。