EPUB作成ソフトの「原稿編集から出力まで対応」という説明だけでは、本当に一体型かは分かりません。同じ画面にボタンが並んでいても、途中で別ファイルを書き出し、別のアプリへ読み込み、書誌や目次を再入力するなら、実態は連携型です。
一体型かを見抜くには、機能名を数えるのではなく、原稿の正本がどこにあるか、書誌・章順・表紙の設定がどこへ保存されるか、手動の受け渡しが何回あるかを追います。この記事では候補ソフトを一体型、連携型、出力専用の三つへ分類する判断軸を作ります。
6機能の有無を試す候補テスト、校正後の本文・章情報・書誌の修正経路、完成EPUBまでの作業手順は別記事の役割です。ここではソフトのデータ境界だけを判定します。
一体型・連携型・出力専用を先に定義する
一体型は、原稿、プレビュー用変換、書誌、章順、表紙、出力設定を同じプロジェクトまたはワークスペースが参照し、保存した正本からEPUBを再生成できる構成です。すべてが一つのファイルに入る必要はありません。保存先が複数でも、同じプロジェクトが所在と関係を保持していれば一体型として評価できます。
連携型は、執筆ソフト、変換ソフト、EPUB生成ソフトなどの間でファイルを受け渡す構成です。自動連携や監視フォルダがあっても、どこかで別形式のファイルが新しい入力になるなら、その境界を記録します。
出力専用は、完成した原稿と素材を受け取り、書誌や章順を設定してEPUBを生成するソフトです。原稿編集を別の環境で完了する前提なら、出力専用が不足とは限りません。「一体型が常に上」という順位付けはしないでください。
代表一章で七工程の経路表を作る
候補ごとに、短い代表一章、二つの章見出し、小さな表紙画像、仮の作品名と著者名を用意します。本番原稿を移行する前に、次の七工程を一行ずつ追います。
- 原稿を開いて一文を編集する
- 見出しやルビをプレビューする
- 作品名・著者・言語・書字方向を設定する
- 二章の順序と目次掲載を決める
- 表紙画像を指定する
- EPUBを生成する
- 生成結果を検査する
経路表には「使った画面またはアプリ」「入力元」「保存先」「手動書き出し」「手動読み込み」の五列を作ります。操作時間や好みはまだ採点しません。まず、同じ情報がどこを通ったかだけを事実として残します。
原稿の正本を一つに決められるか
最初に見るのは、EPUB生成後も編集を続ける原稿の場所です。プレビュー用HTML、変換途中のMarkdown、生成後のXHTMLなど、似た本文が複数できても、どれを直せば次の出力へ反映されるかが一意なら迷いません。
反対に、執筆側と生成側の両方で本文を編集でき、どちらが正しいかを人が覚える必要があるなら、経路表へ「正本が二つ」と記録します。これは機能不足ではなく運用上の境界です。共同作業では担当者ごとに正本を分ける設計もあり得ますが、同期規則が必要です。
書誌・章順・表紙の保存先を確認する
作品名、著者、言語、書字方向、巻数、版、発行日などは、毎回入力するのか、プロジェクトへ保存されるのかを見ます。章順と目次掲載、表紙画像の参照先も同じように確認します。
画面に入力欄があるだけでは一体型の証拠になりません。ソフトを閉じて再度プロジェクトを開いたとき、どの設定が残り、どの素材を再指定するかを説明できる必要があります。この記事では設定値の正しさを採点せず、保存場所と所有者だけを特定します。
手動の受け渡し回数を数える
「エクスポートして保存」「別アプリを開く」「ファイルを選び直す」「同じ値を再入力する」の四つを手動受け渡しとして数えます。コピー＆ペーストも一回です。同じ会社の製品間でも、利用者が中間ファイルを管理するなら連携型に分類します。
ただし、受け渡しゼロだけを最高点にしないでください。校正担当へ固定したDOCXを渡す、デザイナーから表紙を受け取る、専用検査ソフトで確認するなど、意図した境界は品質管理に役立ちます。問題は、境界が見えず、どのファイルを直すか曖昧なことです。
三つの型へ分類する
経路表が完成したら、次の基準で分類します。
- 一体型：一つの正本と保存済み設定から、手動の中間変換なしに再生成できる
- 連携型：正本は明確だが、一つ以上の中間ファイルまたは別アプリへの受け渡しがある
- 出力専用：原稿編集とプレビューの中心は外部にあり、完成原稿を入力として受け取る
毎週更新する連載や、誤字修正のたびに再出力する本は、一体型で再入力を減らす効果が大きくなります。担当者や専門ツールを分ける制作では連携型、原稿を確定して一度だけ変換する仕事では出力専用も合理的です。
rune Studioを同じ判断軸で見る
rune Studioの現行Mac版は、フォルダをワークスペースとして原稿を扱い、EPUB記法を反映するプレビュー、作品情報と章順の設定、表紙画像の選択、EPUB 3出力を資料上で備えています。
既存のCLI検証では、第一章と第二章の2ファイルを使い、作品名、著者、第1巻、版、発行日、書字方向、章順を設定してEPUBを生成しました。出力は5,444バイトで、navとNCXがあり、欠落画像、記法残り、空ページは0、issues 0でした。ワークスペース、設定、章入力、生成、検査が同じ検証経路にあることを段階4で確認しています。
一方、プレビュー画面と表紙指定は機能資料による段階2の確認です。表紙付き出力、GUIでの全工程、実リーダー、ストア登録は今回の実操作に含めません。また、原稿から新規生成する構成であり、既存EPUB内部のXHTMLやOPFを直接直す専用エディタとは役割が異なります。
結論：機能数ではなくデータ境界を見る
EPUB作成ソフトが一体型かを判断するときは、原稿編集、プレビュー、書誌、章順、表紙、生成、検査の七工程を追ってください。正本の場所、各設定の保存先、手動書き出し・読み込みを記録すれば、宣伝文句に頼らず構成を分類できます。
一体型、連携型、出力専用には、それぞれ向く制作があります。求めるべきなのは機能名の多さではなく、自分の更新頻度と共同作業に対して、受け渡しの場所と責任が明確であることです。
