一つのソースから EPUB と印刷 PDF を書き出す：インディー著者の単一ファイル・ワークフロー
EPUB と印刷 PDF は異なるレイアウト論理に従いますが、原稿は一度しか存在すべきではありません。ソースを単一に保ち、出力を多形にする道を示します。
一つのソースから EPUB と印刷 PDF を書き出す：インディー著者の単一ファイル・ワークフロー
電子書籍と印刷の二択は、もうインディーのエコシステムでは二者択一ではありません。2026年の一般的なリリース戦略は、両方を同時に出荷することです――電子書籍は KDP、Apple Books、Kobo Writing Life などを通して、印刷は KDP Print、IngramSpark、あるいは地元の印刷所を通して。二つの形が異なる読者、異なる購買文脈、異なる価格帯をカバーし、合わさってインディー著者の完全な配信を構成します。
しかし EPUB と印刷 PDF はまったく異なるレイアウト論理に従います。EPUB はリフロー可能――読者がフォントサイズ、行間、読書幅を調整し、テキストはデバイスごとに再流動します。印刷 PDF は固定レイアウト――各ページの文字位置、行数、章の始まり、左右の関係はすべて事前に決まっています。EPUB における「章ごとに改ページ」は、印刷では「章ごとに改ページ、奇数ページから始まる」になる必要があります。EPUB では任意の比率でよかった画像が、印刷では裁ち落としとカラースペースを考慮する必要があります。
この差異は多くの著者を「二重ソース」の道に押し出します：Word か Scrivener で .docx を書き、Calibre で書き出して EPUB に変換し、それと並行して Vellum、Atticus、InDesign で印刷版を作る。プロジェクトの途中で原稿を改訂する必要が生じ、両版で変更を同期させなければならない、ということもあります。短期的には機能しますが、長期的には改訂のたびに二回同期が要り、ずれは時間の問題です。
より理にかなった道は単一ソース ＋ テンプレートの分岐です：一つのプレーンテキストファイル（典型的には Markdown か .docx）が権威ある原稿で、電子書籍と印刷はそれぞれの組版テンプレートを持ち、そこからレンダリングします。Vellum と Atticus はこのモデルを英語圏インディーシーンで広めてきました（ソース形式は異なるものの）。中国語圏出版シーンではあまり一般的ではありません。下記では四つの軸を扱います。
二重ソースのコスト：ずれは時間の問題
著者の大半は最初の一冊ではコストを感じません――刊行前の二、三カ月、両ファイルを並行管理することはさほど難しくありません。コストは本が出た後に現れます。
読者がどこかの誤植を指摘する――戻って修正し、.docx を直すが、Vellum プロジェクトは更新されない。次の重版で、その修正が反映されていないことに気づく。あるいは新しい序文付きの第二版を出したい――序文は印刷プロジェクトに入るが、EPUB ソースが同期されず、電子書籍の読者にはいまだに古い版が見える。この「二つの版が同期していない」は、複数の重版やロングテール運営におけるインディー著者の繰り返しの罠です。
より微妙なコストは心理的負担です。改訂を考えるたびに、脳が「二箇所で直す」を追跡する必要があり、その摩擦が「一行変える」の閾値を静かに上げます。時間とともに、原稿の継続的な磨き上げを抑制します。
単一ソース ＋ テンプレートの分岐：ソースを唯一に保つ
より堅牢な道は、原稿を単一の権威あるソースに圧縮し、電子書籍と印刷の各版をそれぞれのテンプレートでレンダリングすることです。Markdown はここで構造的な利点を持ちます：
- プレーンテキスト、どんなエディタでも開ける
- 構造（章、強調、リスト）は意味論的で、テンプレートは同じ意味論から異なる形をレンダリングできる
- サイズが小さく、版管理と同期が容易
ワークフローは概ねこうです：
- Markdown で書き、章ごとに
.mdファイルを一つ、プロジェクトのメタデータ（タイトル、著者、ISBN、奥付）は YAML ファイルに置く。 - 電子書籍テンプレートを選び――フォント、行間、段落スタイル、章開きページのスタイルを設定し――EPUB 3 をレンダリングする。
- 印刷テンプレートを選び――判型、余白、綴じ側、フォント（電子書籍と異なっていてよい）、CMYK を設定し――印刷 PDF をレンダリングする。
- 改訂時には Markdown ソースのみを編集する――両方の出力は次のレンダリングで更新される。
要点は「Markdown を使う」ことではなく――テンプレートが EPUB と印刷の差異化されたニーズを吸収することです。著者は出力ごとに原稿そのものを調整しません。
版管理：すべてのリリースを固定する
単一ソース・ワークフローのもう一つの利点は、版管理と自然に組み合わさることです。Markdown プロジェクトを Git リポジトリに置き、意味のある変更ごとにコミットし、各リリースにタグを付ける（v1.0、v1.1-typofix、v2.0-revised）。それによって：
- いつでもどの歴史的版にも戻り、その版の EPUB と印刷 PDF を再レンダリングできる
- 各変更がいつ、なぜ行われたかを正確に知れる（コミットメッセージ）
- 異なる言語版、地域版、特別版（ハードカバー、サイン入り）のためにブランチを切り、メイン原稿を汚さない
Git の学習に一、二日割く気のある著者にとって、この層がもたらす安定性は Word ＋ 日付サフィックスのファイル名の流儀をはるかに超えます。Git が向かないなら、Markdown プロジェクトを Dropbox／iCloud／Google Drive に置けば、基本的な同期と履歴ロールバックが得られます――粒度が粗いだけです。
Catalpas Atelier Scribe：単一ソース ＋ 同期プレビュー
Catalpas Atelier Scribe はこのワークフローを中心に設計されたデスクトップアプリです。その核心の立場は「Markdown ソース ＋ 電子書籍と印刷のテンプレートを並列 ＋ ライブプレビュー」です。
ソースはフォルダ内の Markdown
章ごとに .md を一つ、どんなエディタでも開けるプレーンテキスト、Git に優しく、あらゆる同期ツールが認識できる。Scribe は原稿をプロプライエタリなデータベースに閉じ込めません。
執筆ペイン ＋ デュアル出力のライブプレビュー 左の執筆ペインは Markdown、右のプレビューペインは「電子書籍プレビュー」と「印刷プレビュー」を切り替えます――同じソース、二つの出力形、キーストロークごとにミリ秒単位でレイアウトが更新されます。「書き出して PDF を確認する」と比べてフィードバックサイクルを大幅に短縮します。
Plus から：EPUB 3 ＋ グレースケール／RGB PDF Plus は EPUB 3（完全な出版メタデータ付き、KDP／Apple Books／Kobo 用に準備済み）とグレースケール／RGB PDF をアンロックします。大半の英語小説と一般ノンフィクションのデュアルトラックリリースは Plus 内で収まります。
Pro：CMYK ＋ ICC ＋ カスタム印刷マスター ＋ ルビ 印刷要件が高めのプロジェクト（ハードカバー、アートブック、CJK 出版、カラー本文）には Pro が要ります：CMYK カラースペース、ICC カラーマネジメント、カスタム印刷マスター（見開き ＋ 綴じ側切り替え ＋ 裁ち落とし ＋ ノド）、カスタムフォント取り込み、ルビ。Pro は早割で79.99ドル/年、通常129.99ドル/年。
三プラットフォームでネイティブ Windows、macOS、Linux すべてにネイティブクライアント。ファイルは既定でローカル保存、クラウド同期は任意。
Vellum と Atticus との比較
Vellum と Atticus はどちらも「単一ソース、電子書籍と印刷のテンプレート分岐」という設計思想を体現し、英語圏インディーシーンで実戦に揉まれたツールです。Vellum は丁寧に設計されたプリセットテーマとほぼ無欠の英語組版を提供し、Atticus はウェブネイティブでデバイス間が容易、買い切りです。
この道で候補から外れる理由はそれぞれ異なります：
- Vellum は macOS 専用で、CJK 縦組みやルビに対応しない
- Atticus はウェブネイティブゆえ原稿がクラウドにホストされ、CMYK 印刷カラーに対応せず、CJK 縦組みもカバーしない
- どちらもソースはオープンな Markdown ではなく、書き出すには変換が要る
Scribe はこの三点で異なるトレードオフをします：三プラットフォームでネイティブ、CJK 縦組みは既定で使える、ソースはオープンな Markdown。Mac の英語ユーザー体験軸で Vellum を打ち負かすことはありません――そこは狙いではありません。Vellum と Atticus がカバーしない場面に単一ソース・ワークフローを延長します。
選択を下す
単一ソース ＋ テンプレートの分岐は長期的に持続可能なワークフローですが、すべての著者が今すぐ移行する必要はありません。
一冊だけ刊行する予定で、Word ＋ Vellum／Atticus がすでに機能しているなら、「より優雅なワークフローのために」移行を強いる理由はありません。良いツールは置き換える必要がありません。
以下の場合、単一ソースの Markdown ワークフローが合うかもしれません：
- 複数の本を刊行する予定で、保守コストを管理可能に保ちたい
- 原稿の長期的な可搬性を重視し、どのツールのプロプライエタリ形式にもロックインされたくない
- すでに Markdown で書いている
- プロジェクトに CJK 縦組みやルビが関わり、Vellum と Atticus が圏外になる
- Git で精密な版管理と共同編集をしたい
- デバイス構成が Windows、macOS、Linux にまたがる
最良のワークフローは「一度改訂、両方の出力が更新される」です。無料層から始め、同じ Markdown ソースから電子書籍と印刷の両方をプレビューし、リズムに合うか見てください。
関連記事:
- 2026年、セルフ出版作家のための EPUB 書き出しツール短評
- Markdown から印刷品質の PDF 本までの最短経路
- 本文組版のための、手の届く InDesign 代替
- Scribe ソリューション・ハブ：ワークフローから入り口を見つける