本の作成パイプライン は何をしますか？
コンセプトから小売販売まで、イラスト入りの本を1冊または複数冊制作するためのエンドツーエンドのワークフロー。illustrated-bookスキル（単一書籍のレイアウト詳細）と連携します。ユーザーがペーパーバック1冊から10巻シリーズまで、何でも作りたいときにこのスキルを使用してください。
使用するタイミング
- 「本／シリーズを書くのを手伝って」
- 「同じカバー形式、同じ声、同じイラストスタイルをN冊で統一したい」
- 「カバーと内部スケッチを含む原稿全体を生成したい」
- 「私のアイデアを出版可能なAmazonペーパーバック＋Kindle＋オーディオブックに翻訳したい」
使用しないタイミング
- 他者の著作権で保護された作品の忠実な翻訳（翻訳権に関する会話を参照）
- 子供向け絵本（異なるレイアウト／イラストパイプライン）
- 純粋なノンフィクション参考書（教科書、マニュアル）（異なる構成）
- 写真のような視覚的特徴を持つ文学作品（パターンAまたはBで
illustrated-bookスキルを直接使用）
パイプライン（任意の書籍数）
以下は実証済みのワークフローです。拡張可能：単一書籍ではフェーズ0～9を順次実行します。N巻シリーズでは、フェーズ5で並行エージェントディスパッチを追加し、フェーズ1でSERIES_GUIDE.mdを作成します。下流フェーズ（コンパイル、オーディオブック、出版）は書籍ごとに同一です。
フェーズ0 — コンセプト確定（ユーザーとの調整、必須）
何かを書き始める前に、ユーザーと次の項目を確定します。
- 書籍の数、タイトル、そして一貫するテーマ。 各書籍が扱う不安／領域／好奇心は何か？ 単一書籍の場合はタイトル＋フックのみ。N巻の場合はシリーズのアーク。
- 声のレジスター。 一つ選び、サンプル段落で確認する：
- マンソン風スパイシー（Fワードあり、ストレート）
- バークマン風知的（罵りなし、思索的）
- マンソン×バークマン×ゴール（リラックスした自己啓発、軽い東洋の知恵、罵りなし）
- ペレビン風伝統文学（哲学的、シュール、濃密）
- ゼーバルト風瞑想的（散文に写真が散りばめられる）
- 著者のペルソナ — 最も重要な決定。
- 自伝的（ユーザー自身） — 魅力的だが、ユーザーがニッチな場合はリスクが高い
- 擬似自伝的ジェネリック（「30代半ばのエンジニア」「40代の教師」） — 幅広い訴求力
- 三人称の架空の語り手
- 重要なテスト：「冷めた購買者のフックは？」と尋ねること。 ペルソナが読者の教育を必要とする場合（ニッチなサブカルチャー、外国人移民の枠組み、特定の宗教的伝統）、冷めたAmazon購入者は惹きつけられません。ジェネリックで共感を呼ぶものがほぼ常に勝ちます。
- 並行執筆の前に1章のサンプルを実行すること。 10万語後にペルソナのズレが発覚すると修正が困難です。
- リリース間隔（複数巻のみ）。 2～4週間での急速リリース（KDPアルゴリズムのブーストを最大化） vs. 1冊ずつ。
- 言語。 英語のみ、または英語＋ロシア語など — オーディオブックエンジンの選択に影響（
project_audiobook_engine.md参照）。 - 権利。 ユーザーが既存の書籍を「参考にしたい」と言及した場合、翻訳権を持っているか確認。類似レジスターのオリジナル作品は権利的にクリーンですが、権利なしの翻訳は不可です。
フェーズ1 — フォルダ構成
Books/<プロジェクト名>/
├── _series/ # 複数巻のみ；単一書籍ではスキップ
│ ├── SERIES_GUIDE.md # 声＋ペルソナ＋反復装置＋アートバイブル
│ ├── _gen_covers.py # カバー生成スクリプト
│ ├── _gen_sketches.py # 内部スケッチ生成スクリプト
│ └── test_sketches/ # 承認ゲート用サンプル
├── 01_<書籍スラッグ>/ # 単一書籍の場合はBooks/直下に1フォルダ
│ ├── BOOK_PLAN.md # 章のアウトライン（任意のN章；通常25）
│ ├── chapters/ # NN_slug.txt ファイル
│ ├── images/00_cover.png # メインカバー
│ └── sketches/ # 内部イラスト
├── 02_<書籍スラッグ>/... # 追加書籍
└── _publishing/ # 書籍ごとのメタデータキット
SERIES_GUIDE.md（単一書籍の場合はBOOK_GUIDE.md）には以下を含める：
- 声のレジスター（肯定的な例＋禁止レジスター）
- 語り手のペルソナ（具体的な経歴、テクスチャ、引き出し素材、明かさないこと）
- 反復装置（例：「試してみた」パターン、現代に語り直された寓話、瞑想的なアンカー — 知恵の瞬間がある場合は普遍的な実践を1つ選ぶ）
- スケッチのアートバイブル（固定プロンプトプレフィックス；承認サンプルでテスト済み）
- カバーバイブル（構成の公式 — シリーズ全巻で同じX）
- マーカー規則（フェーズ4）
- 制作チェックリスト
フェーズ2 — カバー生成
カバー上の読めるテキストに最適：Google Gemini Nano Banana Proモデル（nano-banana-pro-preview）。クリーンなタイポグラフィで一般的なシーンに最適：Nano Banana Flash（gemini-2.5-flash-image）。ローカル代替：ComfyUI経由のFlux Krea Dev FP8。
APIキーは環境変数で提供する — スクリプトにハードコーディングしないこと：
export GEMINI_API_KEYS="key1,key2,key3,key4" # カンマ区切り、ローテーション
または呼び出しごとに：
import os
keys = os.environ["GEMINI_API_KEYS"].split(",")
カバー構成の公式（リラックスした自己啓発シリーズで実証済み；ジャンルに応じて調整）：
- 上部：著者名をスペース入り大文字で、オプションでロゴ区切り
- タイトル：太字の手描き風大文字で上部3分の1を占める（クリックベイト見出し）
- サブタイトル：アクセントカラー（説明的な約束）
- 主人公は小さくフレーム内に配置、環境が支配
- フッター：小さな大文字のプルクォート（例：「『___』の著者より」）
- シリーズの統一：全カバーに同じ反復視覚モチーフ（帽子、椅子、窓など一貫したもの）
プロンプトルール（2026-04-25時点の教訓）：
- 「上部に白い空のスペースを空けて」と要求しない → 白く飛んだ帯になる。シーンにフレームを満たさせ、自然な影にタイトルを重ねる。
- 正確なテキストを引用符で囲む（「テキストは正確に：'…'」） — Proがそのまま再現する。
- 「シーン全体がフレームの最上部まで完全に満たされ、白く飛んだネガティブスペースはなし」と指示する。
フェーズ3 — スケッチアート承認ゲート（必須）
ユーザーの承認を得る前に、完全なスケッチバッチを生成しないこと。 常に以下の手順を踏む：
- 高品質で約10枚のテストスケッチを生成（Flux Krea Dev FP8、1024×1024、25ステップ）
- ユーザーに表示 → 承認を待つ
- 承認後、より高速な本番設定（768×768、18ステップ）に切り替え、約3～4倍の速度向上
- 高速化設定を1枚のスケッチでスモークテスト — 品質が承認されたスタイルと一致することを確認
- その後、完全なバッチを実行
固定された本番プロンプトプレフィックス（カートゥーンラインアート用、Gor風スタイル、2026-04-25実証）：
Black ink loose hand-drawn pen sketch on pure white background,
minimalist cartoon line art, single subject, no shading, no fills, no grayscale tones,
no color, no gradient, no background detail, just black lines on white,
simple expressive contour lines, slight wobble, lots of empty white space,
flat 2D illustration, the entire image is pure solid white with only black ink lines drawn on it.
NOT a photograph, NOT a notebook page, NO paper texture, NO frame, NO binding, NO border.
固定されたネガティブプロンプト：
photorealistic, photograph of a sketch, photograph of a notebook, paper texture,
notebook binding, page edges, sketchbook, journal, frame around the drawing,
3D render, color, gradient, shading, watercolor, oil paint, anime, manga,
intricate background, busy composition, detailed environment, gray fills,
cross-hatching, dense linework, decorative border, dark background, black background
よくある落とし穴： スケッチがノートの中のペンスケッチの写真として返ってきた場合、プロンプトに「ペーパーバック本」「ノート」「段落の間」というフレーズが含まれている可能性がある → それらのフレーズを削除する。
他のスタイル（水彩、フォトコラージュ、ベクターフラットなど）の場合は、プロンプトプレフィックスを置き換え、同じ承認ゲートを実行する。
後処理： R+G+B > 720 のピクセルは (255,255,255) にスナップ。ほぼ白の色合いを除去。
フェーズ4 — 書籍ごとのBOOK_PLAN.md
各書籍は章のアウトラインを取得。3幕構成で各約1/3。必須要素：
- 各章のファイル名スラッグ（スネークケース）
- 1段落の章の要約
- スケッチヒントリスト（反復視覚要素）
- プルクォート候補バンク（エージェントが一部を使用、他は独自生成）
- 反復瞑想的アンカーの配置（該当する場合、書籍あたり約3章）
- 相互参照ルール（複数巻シリーズの場合のみ関連）
章数：通常15～30。一部のマニフェストは10章で機能、一部の文学小説は40章以上。
フェーズ5 — 執筆
単一書籍： BOOK_GUIDE.md + BOOK_PLAN.md を持った1つの general-purpose エージェントをディスパッチする。
複数巻シリーズ（並行）： 書籍ごとに1つの general-purpose エージェントをディスパッチする。各エージェントは以下を受け取る：
- SERIES_GUIDE.mdへのパス（最初に読む）
- 自身のBOOK_PLAN.mdへのパス
- プロンプト自体にペルソナ仕様の要約（多重防御）
- 出力フォルダ指定
- マーカー規則（フェーズ6）
- 章ごとの単語目標と総単語数
- 逐次保存の指示（メモリにバッチ保存しない）
- 報告フォーマット
Anthropic API制限： 安全な上限は4つの並行 general-purpose エージェント。5以上はスロットリングの可能性あり。
ペルソナズレ監視。 最大の失敗モードは、エージェントが間違ったペルソナテクスチャを拾うことです。途中で、Grepを使用して禁止トークン（GUIDEで制限として定義したもの）を定期的にチェック。検出された場合、停止、アーカイブ、GUIDEをより強調して書き直し、再ディスパッチ。
フェーズ6 — マーカー規則
ソース.txtファイルは、コンパイルスクリプトが置換するマーカートークンを使用。
| マーカー | 場所 | レンダリング結果 |
|---|---|---|
[SKETCH: シーン説明] | インライン、独立行 | その位置に事前生成されたPNGスケッチが挿入される |
[QUOTE: 1文のプルクォート] | インライン | EPUB：スタイル付きHTMLプルクォート呼び出し。PDF：スタイル付き呼び出しまたはグラフィックとして再生成 |
[SEEDS]…[/SEEDS] | 章末、- 箇条書き付き | イタリックのセリフ体アフォリズム（Gorの「知恵の種」装置）が入ったスタイル付き呼び出しボックス |
最初と最後の img_map エントリ | 章ごとのイメージマップ | 章テキストの前の全面マーキーイラスト。中央のエントリ → テキストラップ（illustrated-bookスキルのパターンB v2） |
ジャンルに応じて各マーカーを採用または省略。自己啓発やポップスピリチュアリティは4つすべてを使用。文学小説は[SKETCH:]と章イメージマップのみを使用することが多い。
フェーズ7 — スケッチ生成（本番バッチ）
全章の草稿後：
Grepでchapters/ファイル内の[SKETCH:]マーカーを全て抽出- スケッチ生成スクリプトをバッチ実行 — マーカーごとに1つのPNGを
<book>/sketches/に生成 - ファイル命名規則：
<chapter_slug>_s01.png、_s02.pngなど - 白色化後処理
- 本番設定（ラインアート固定）：768×768、18ステップ、Flux Krea Dev FP8、euler/simple、cfg 1.0、guidance 3.0
スループット：RTX 5080で約15秒/スケッチ。400スケッチで約1.5時間。
フェーズ8 — コンパイル（illustrated-bookスキルによる）
実証済みの_compile_novel.pyスクリプトを使用（fpdf2 PDF + ebooklib EPUBを処理）。このスクリプトはフェーズ6の完全なマーカーセットとハイブリッドレイアウト（パターンB v2：最初と最後のimg_mapエントリは全面マーキー、中央のエントリは左右交互のテキストラップ）をサポート。
書籍ごと：
python _compile_novel.py <プロジェクト名>/<書籍スラッグ>
出力：<Book>_EN.pdf、<Book>_EN.epub、<Book>_Cover_Amazon.jpg（1600×2560）、およびロシア語の章がある場合は<Book>_RU.{pdf,epub}。
フェーズ9 — オーディオブック（Audiobook-Engine）
cd <Audiobook-Engine パス>
tts.bat audiobook "<本フォルダへのフルパス>" en
英語：Kokoro v1.0 af_heart（約25～49倍RTF）。ロシア語：クローンボイス付きF5-TTS Misha24-10（約1倍RTF）。出力：<Book>_AUDIOBOOK_<LANG>.mp3（192 kbps）。
フェーズ10 — 出版
出版メタデータキットパターンを使用：書籍ごとのメタデータパック。KDPカテゴリ、BISACコード、キーワード、推奨価格、宣伝文（HTML）、比較タイトル、著者経歴を含む。ハイブリッドドライブ：メタデータを準備し、ユーザーがKDP/Kobo/Google Playを開いて貼り付け／アップロード。
複数巻シリーズの場合：2～4週間で急速リリース、KDP Selectは第1巻のみ。
重要な教訓（2026-04-25時点、複数の書籍制作で実証済み）
1. ペルソナの反復は最もリスクの高いフェーズ
間違ったペルソナで大規模に執筆すると、後戻りが非常に困難。並行執筆の前に、提案されたペルソナで1章のサンプルを必ず実行すること。「これはAmazonの冷めた購買者にとってフックになるか？」と明示的に尋ねる。
2. ユーザーの自伝的な声は、めったに正しいフックにならない
著者は、読者が自分の実生活に魅了されると想像する。冷めた読者は投影したい。擬似自伝的ジェネリックをデフォルトに、ユーザーが実証可能な名前の認知度を持っていない限り。
3. スケッチテストゲートは譲れない
約10枚のテストスケッチ → ユーザー承認 → 本番設定 → スモークテスト → 完全バッチ。ゲートをスキップすると、何百もの間違ったスケッチが生成される。
4. カバープロンプトルール
- 「上部に白い空のスペース」を避ける → 白く飛んだ帯になる
- プロンプトで正確なテキストを引用 — Proがそのまま再現
- シリーズの統一 = プロンプトで「前のカバーと同じX」と明示
5. スケッチプロンプトルール
- 「ペーパーバック本／ノートページ」を避ける → Fluxがスケッチをノートの写真としてフレーミング
- 代わりに「真っ白な背景のフラット2D描画」を使用
6. カバーAPIクォータモデル
無料層のNano Banana Proは、キーごと・時間枠ごとの制限で、1日合計ではない。キーをローテーションし、1つがレート制限された場合、約45秒のクールダウン後に次のキーが引き継ぐ。
7. Kokoroオーディオブック：スタイルインデックスをクランプ
Kokoro-onnxにはMAX_PHONEME_LENGTH=510でオフバイワンバグがある。ヘルパーをパッチ：
style = voice_style[min(len(tokens), voice_style.shape[0] - 1)]
8. リセット前にバックアップ
執筆途中でペルソナの方向転換が必要になった場合、古い章をアーカイブ（_v1_old_persona_archive/に移動）。削除しない。v2に活用できる再利用可能な構造、ビート、プルクォートが含まれている。
9. コンパイル＋オーディオブック＋出版の各フェーズは90%再利用可能
GUIDEとPLANが正しければ、下流パイプラインは修正なしで実行される。投資：パイプライン設定に一度約2時間。書籍ごとの下流：約30分。
10. 同じロシア風カバー公式は、Nano Banana Proを介して英語の書籍でもきれいに再現される
帽子＋熱帯設定＋太字の黒大文字タイトル＋アクセントカラーのサブタイトル＋…
[翻訳のため省略]