電子書籍 作り方を調べているなら、完成という一語でまとめず、原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にするのが答えです。対象は三章2万字、表紙一枚、著者名と発行日を含む初めての短編です。この記事では原稿正本、章の読む順番、書誌情報、目次と表紙、EPUB構造、読者表示を使って、『短編一冊を原稿確定からリーダー確認まで六つの完了札で進められる』までの判断を組み立てます。販売登録、価格、税務、固定レイアウト本は扱わないという範囲には踏み込みません。
直接回答：原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にする
完成という一語でまとめず、原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にするのが答えです。完成条件は『短編一冊を原稿確定からリーダー確認まで六つの完了札で進められる』です。
判断欄は原稿正本、章の読む順番、書誌情報、目次と表紙、EPUB構造、読者表示です。『販売登録、価格、税務、固定レイアウト本は扱わない』は合格条件へ混ぜません。
工程を成果物の受け渡しで区切る
本文を書き終えた後に何から決めるか分からず、表紙や目次だけを先に作り直すことを防ぐには、原稿正本・章の読む順番・書誌情報・目次と表紙・EPUB構造・読者表示を別々の完了条件にします。前の工程から何を受け取り、次へ何を渡すかが説明できたときだけ、その工程を閉じます。
材料は三章2万字、表紙一枚、著者名と発行日を含む初めての短編です。本番を直接使わず、識別できる複製で一周します。ここで、生成できたことと、構造や表示を確認できたことは別の行へ記録します。
完成原稿を複製して正本を宣言するから始める実行順
次の五項目は、三章2万字、表紙一枚、著者名と発行日を含む初めての短編を同じ条件で扱うための製品非依存の検査順です。特定製品で確認した操作結果ではなく、どの候補にも適用する受け入れ手順として使います。各項目の終了時に、対象、原稿正本に関する確認事実、次の入力を一行ずつ残します。
一周目の終了条件は『短編一冊を原稿確定からリーダー確認まで六つの完了札で進められる』を説明できることです。途中で原稿と生成物のどちらを直すか曖昧なら、その地点で止めます。別の素材や設定へ逃げず、停止理由を同じ作業票へ書きます。
- 1. 完成原稿を複製して正本を宣言する
- 2. 章IDと読む順番を固定する
- 3. 書誌・目次・表紙を別欄で埋める
- 4. EPUBを生成してnavとspineを検査する
- 5. 一字修正して再生成し二つのリーダーで確認する
固有標本で判定欄を埋める
三章2万字、表紙一枚、著者名と発行日を含む初めての短編では、見た目の印象ではなく原稿正本から読者表示までを順に判定します。対象の名前、開始値、保存先または成果物IDを添えれば、古い結果を今回の結果と取り違えません。
ここで記録するのは『うまくいった気がする』ではなく、原稿正本と読者表示の何を見て合格または保留にしたかです。ここで、未実施の欄は未実施のまま残し、『短編一冊を原稿確定からリーダー確認まで六つの完了札で進められる』という結論へ広げて解釈しません。
- 原稿正本：対象と期待状態を先に書き、『原稿と生成物のどちらを直すか曖昧』なら未合格として戻し先を示す
- 章の読む順番：対象と期待状態を先に書き、『目次順と本文順が違う』なら未合格として戻し先を示す
- 書誌情報：対象と期待状態を先に書き、『再生成後に修正または設定が消える』なら未合格として戻し先を示す
- 目次と表紙：対象と期待状態を先に書き、『原稿と生成物のどちらを直すか曖昧』なら未合格として戻し先を示す
- EPUB構造：対象と期待状態を先に書き、『目次順と本文順が違う』なら未合格として戻し先を示す
- 読者表示：対象と期待状態を先に書き、『再生成後に修正または設定が消える』なら未合格として戻し先を示す
『原稿と生成物のどちらを直すか曖昧』に当たる状態を最初に切り分ける
このテーマで止めるべき状態は、原稿と生成物のどちらを直すか曖昧、または目次順と本文順が違う、または再生成後に修正または設定が消えるです。三つを一括して『使いにくい』とせず、どの入力、設定、成果物で観察したかを分けます。原因が違えば戻し先も違います。
修正後は完成原稿を複製して正本を宣言するから全項目をやり直す必要はありません。ただし、変更した条件に影響する原稿正本・章の読む順番・書誌情報・目次と表紙・EPUB構造・読者表示は再確認します。前回の行を消さず、変更日と新しい成果物を追加すると差分が追えます。
- 停止1：原稿と生成物のどちらを直すか曖昧
- 停止2：目次順と本文順が違う
- 停止3：再生成後に修正または設定が消える
Rune Studioを候補に加える範囲
公開機能資料では「縦書き・横書き、目次、表紙、奥付を設定してEPUB 3へ出力できる」という機能範囲が確認できます。そのため、原稿、章順、書誌、目次、表紙、奥付を一つの制作記録へまとめる用途を一つの制作環境で試したい場合の候補になります。ただし、この説明は公開資料で確認した機能範囲であり、三章2万字、表紙一枚、著者名と発行日を含む初めての短編が全項目に合格したという実測結果ではありません。
向くのは、原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にするという管理を保ちながら、原稿と設定または資料の受け渡しを減らしたい人です。一方、本記事の対象外は『販売登録、価格、税務、固定レイアウト本は扱わない』です。その範囲や外部サービス側の受理まで必要な場合は、別の道具と出口検査を組み合わせます。
結論：三章のファイル名へ章IDを付け、六工程の空欄表を作る
電子書籍 作り方で持ち帰る結論は、原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にすることです。原稿正本・章の読む順番・書誌情報・目次と表紙・EPUB構造・読者表示を別欄にすれば、『短編一冊を原稿確定からリーダー確認まで六つの完了札で進められる』へ達したかを、機能数や印象ではなく記録で判断できます。
まず三章のファイル名へ章IDを付け、六工程の空欄表を作る。三章2万字、表紙一枚、著者名と発行日を含む初めての短編の複製で一周し、『原稿と生成物のどちらを直すか曖昧』に当たる状態が起きた地点を残してください。Rune Studioを試す場合も同じ作業票を使い、公開仕様の存在と手元の合格結果を混ぜないことが次の比較を正確にします。
この記事が答えるのは『原稿・章順・書誌・目次と表紙・生成・閲覧確認を別工程にする』までです。近接するSTUDIO-021（横書き電子書籍）、STUDIO-020（縦書き電子書籍）の中心論点は代替しません。除外範囲は『販売登録、価格、税務、固定レイアウト本は扱わない』です。製品候補を確認するときは、Rune Studioの製品ページで現行Mac版の範囲を照合してください。
