--- name: fictional-textbook description: Generate a fictional, full-length introductory book (入門書) on a requested topic for the user to read as a deep study method. The deliverable must match the length AND density of a real bookstore primer — 100,000〜150,000字 with each section dense in specifics (real names, numbers, dated events). Use this skill whenever the user asks to write a 本 / 入門書 / 教科書 / primer / textbook on a topic, or asks for book-format study material. Strongly prefer this skill over a Q&A summary when the user wants to LEARN by reading. This skill REQUIRES web_search for any topic involving current facts (pricing, versions, releases, specs, company news) before writing — guessed facts and ungrounded aphorisms break the book. --- # Fictional Textbook (架空入門書 執筆スキル) ## 背景 架空の入門書をAIに書いてもらい「自分が読む」ことで学ぶ手法。要約より「本」のほうが頭に残る理由: 1. **著者の声が立つ** — 一人称の論旨が要求される 2. **構造化が強制される** — 前提→各論→展望の順序になる 3. **第N版の効果** — 「こなれた文体」が要求される 4. **固有名詞の強制** — 抽象論ではなく現実世界の地図になる 5. **比喩で幹を作る** — 一つの強力な比喩が読後印象を残す ターゲットは「書店で売っている入門書と同等の **密度**」。総字数だけ稼いだ「ジェネリック格言集」はNG。LLM特有の「薄く引き延ばした要約」を防ぐため、**構成の再帰的分割と、末端単位での反復執筆**を徹底する。 --- ## 執筆フロー ### Phase 0: モード確定（挿絵指示が出た場合のみ） ユーザーから明示的に挿絵指示があった場合に限り、Phase 1 に入る前に `script/check_config.ps1` を実行して実生成モードか fallback モード（プレースホルダのみ）かを確定させる。style 選択・命名規則の合意もこのタイミングで行う。詳細は後述「挿絵」節。挿絵指示が無い場合は本 Phase をスキップして Phase 1 へ。 ### Phase 1: Web検索(必須・サブエージェントに委任) 書き始める前に Web 検索で素材を集める。ただし メインエージェントで直接検索すると、生の検索結果がコンテキストを食い尽くし、執筆フェーズで context window が枯渇する。必ず リサーチ専用のサブエージェントに委任すること。 #### 委任の手順 1. `Agent` ツールで `general-purpose`(または `Explore`)サブエージェントを 1回起動 2. 8〜15 回の Web 検索 + 構造化された「素材ノート」の返却 を依頼 3. 受け取った素材ノートを `outputs/[トピック]_素材ノート.md` に保存 4. 執筆中は このファイルを参照(再検索を最小化) 5. 素材ノートに無い固有名詞・数字が必要になった時のみ、追加で小規模リサーチ(2〜3検索)を別サブエージェントに依頼 サブエージェントには 本文を書かせない。素材収集のみ。書かせると密度・文体ルール(著者の声、格言禁止)が一切効かないため。 #### サブエージェントへのプロンプト・テンプレート ``` あなたは入門書執筆のためのリサーチ専門エージェントです。本文は書かず、素材だけを集めて構造化して返してください。 トピック: [トピック名] 切り口/角度: [サブタイトル候補や問題意識] 以下の観点で 8〜15 回の web_search を実行し、結果を「素材ノート」として返してください。 検索カテゴリ: - 全体像と歴史(例: `[トピック] 歴史 推移`) - 現在のプレイヤー名と数字(例: `[トピック] 主要企業 売上 2025`) - 直近の事件・ニュース(例: `[トピック] 失敗事例 炎上 事件`) - 業界の批判・限界論(例: `[トピック] 批判 限界 問題点`) - 規格・契約・法令の実例(該当する場合) - 業界人の発言・著作(例: `[名前] 発言 インタビュー`) 返却フォーマット(これに厳密に従う): ## 素材ノート: [トピック] ### 固有名詞(企業・製品・規格・人名・事件名) - (20個以上) ### 具体的な数字・日付 - YYYY年MM月: xxx - xxx は ◯◯円/◯◯人/◯◯% - (15個以上) ### 事件・ケーススタディ - [事件名・年]: 概要、登場人物、含意 - (5件以上) ### 引用しやすい発言 - [人物名・所属・年]: 「発言内容」(出典 URL) - (5件以上) ### 業界の批判・対立軸 - [論点]: 誰が誰に何を言っているか - (3件以上) ### 推奨される章立てのヒント - (この素材から組み立てるなら、どういう章が立てやすいか 5〜8案) 繰り返し: 本文の執筆はしないでください。素材ノートのみ返却してください。検索結果の生テキストを長々貼り付けるのも禁止。要点だけを上記フォーマットに圧縮してください。 ``` #### 素材の使い方 各節を書く時は 素材ノートから 固有名詞・数字・引用を最低 1つ拾って本文に登場させる。素材ノートに登場している人名・企業名・事件名は、本全体で繰り返し参照することで読後の記憶定着を狙う。 逆に 素材ノートに無い固有名詞・数字を勝手に書くのは禁止(推測になるため)。必要なら追加リサーチを依頼するか、抽象表現で逃げる。 #### 検索しない例外 古典的理論のみ(古典力学、形式言語理論、江戸時代史など)。この場合 Phase 1 はスキップして直接 Phase 2 へ。 #### 推測で書かない 価格・バージョン・統計・日付・人名は素材ノートで確認するか、書くのを諦めて抽象表現で逃げる。「2024年頃」「数十億円規模」のようなぼかしは許容、確定的な数字の捏造は失格。 ### Phase 2: 章立てと再帰的構造化（必須） **LLMの出力制限による「サボり」を防ぐため、目次をツリー状に極限まで細分化する。** 1. 大見出し（章）の設計: 採用する版の章数レンジに従う（簡易版 6〜8 / 標準 10〜12 / 本格版 12〜15）。レンジ上限を超えてはいけない。超える場合は2冊に分けるべき内容 2. **中見出し（節）の設計**: 各章の下に 3〜5個の節（N.1, N.2...）を作る。 3. **小見出し（項）の設計**: さらに各節の下に、どのようなトピック・事例・コラムを書くか、箇条書きで意味的な区分（項）を設定する。 この「章→節→項」のツリー構造（本全体の設計図）をユーザーに提示し、合意を取ってから本文へ進む。「任せる」と言われたら即進行。 Codex で見出しと本文の日本語を詰めるときは、`references/codex-japanese-style.md` を参照してから章タイトルと節タイトルを作る。 ### Phase 3: 末端ノード単位でのマイクロ執筆（最重要） **絶対に全章や「複数章」を1ターンで書いてはいけない（内容が極めて薄くなるため）。** 章単位ではなく、**「節（Section）」を執筆の最小単位**として、少しずつループ（反復）で書き進める。 1. 最初のターンで「扉 + 目次 + はじめに」を書く。 2. 次のターンで「第1章の導入部と第1.1節」だけを全力で書く。 3. 次のターンで「第1.2節と第1.3節」だけを全力で書き、`Edit` ツールでファイルに追記する。 4. 以下、最終章まで1〜2節ずつ積み上げる。 **1ターンあたり最大でも 1〜2節（合計 3,000〜5,000字程度）まで**。それ以上を狙うと途端に密度が落ちる。前の節の文脈を踏まえ、重複を避けて滑らかに繋ぐこと。 #### 機械的な見出し数制約（モデルを問わず厳守） 「1〜2節まで」をお願いベースで書いても、モデルによっては平気で全章を書こうとする（特に Codex / Gemini）。以下を機械的なカウントとして守ること。 - 1回の応答で書き出す `### N.X` の見出しは 最大 2個。書き始める前に「今回書く見出しは N.X と N.Y の2個」と宣言してから本文に入る - 2節を書き終えたら必ず STOP し、「次は N.Z を書きます。続けてよいですか？」と確認して応答を終える。続行判断を勝手にしない - 「ユーザーの手間を省くため」「効率的に進めるため」といった自己判断で 3節以上を一気に書いてはいけない。これは必ず密度の低下を招く - ファイルへの追記は 節ごとに行う。複数節を内部的に溜めて一度に書き出さない（途中で長さ制限に当たって尻切れになるリスクが高い） - 章をまたぐ場合も同じ。第N章 4節 + 第N+1章 1節 のような跨ぎ方も 計 2見出しまで ### Phase 4: 仕上げ 全章書き終わったら、後述のセルフチェック全項目に通るか確認。事実関係に不安があれば再度検索。 最終ファイルを `outputs/` に保存し、保存先の相対パスをユーザーに伝える。 --- ## 本のフォーマット ### 扉ページ ``` # [トピック]入門 ## 【第N版】 [サブタイトル: 固有名詞 1〜3個 + 切り口1フレーズ] [著者名（絵文字1つ）] YYYY年MM月 第N版 ``` - 版数は 2〜5 の範囲（第3版あたりが落ち着いている） - 著者名はClaude or Codex or Gemini or other + 絵文字1つ ### 章の構造 ``` ## 第N章: [章タイトル] — [章副題（任意・章単位の切り口フレーズ。扉のサブタイトルとは別物）] [章の導入。具体的なシーン・人物・事件から入る。1〜2段落、400〜600字] ### N.1 [節タイトル] [本文 1,500字以上、3〜6段落。後述の節密度ルール] ### N.2 [節タイトル] [同上] ### N.3 [節タイトル] [同上] #### ■コラム [コラム題] [3〜6段落、800字以上、具体的事例を含む] ### N.4 [節タイトル] [同上] [章末の総括。100〜200字] ``` 各章の目標字数は採用する版の「1章あたり」欄（下記分量表）に従う。節は 3〜5個。 ### 節の密度ルール（最重要） **`### N.X` の各節は以下を満たさないとダメ:** - **最低 1,500字** - **最低 3段落**、各段落は最低 3文 - **最低 1つの具体物** — 実在の固有名詞 / 具体的な数字 / 事件名 / 実際の発言 / コード例 のいずれか - **抽象的な格言で締めない** **置換テスト**: 節を読んだとき、別のトピック（DX、業務改革、組織論など）に置き換えても成立してしまう文章は失格。具体性が無い証拠なので書き直す。 ### 章ごとの「具体性メーター」 各章は次の最低数を満たすこと: - **実在の固有名詞 ≥ 5個**（企業名、製品名、人名、事件名、規格名） - **具体的な数字または日付 ≥ 3個** - **実際の事件・発言・ケース ≥ 2個** 満たないなら検索して追加するか、章を削る。 ### コラム **1本あたり 800字以上、3〜6段落**。1段落で終わるコラムは「形だけ」とみなされる。 ネタは: 歴史的経緯、命名の裏話、業界の逸話・事件、規格化の裏側、失敗事例・炎上事件。 本全体で **5〜10本**。10章ならコラム無しの章があってはならない。 --- ## 分量の目安 | 版 | 総字数 | 章数 | 1章あたり | 執筆の進め方 | |---|---|---|---|---| | 簡易版 | 30,000〜50,000字 | 6〜8章 | 4,000〜6,000字 | 1ターンに1章ずつ | | **標準** | **100,000〜150,000字** | **10〜12章** | **8,000〜12,000字** | **1ターンに1〜2節ずつ** | | 本格版 | 150,000〜200,000字 | 12〜15章 | 10,000〜15,000字 | 1ターンに1節ずつ | **章数を増やして総字数を稼ぐのは禁止**。1回の実行単位を極小化し、1節ごとの記述を深掘りすることで密度と規模を両立する。 --- ## 文体ルール ### やる - **散文で書く** — 1段落 3〜6文、論理を接続詞でつなぐ - **著者の立場を表明する** — 「筆者は〜と考えている」「〜と読むのが正確である」 - **固有名詞を躊躇せず出す** — 実在の企業・製品・規格・人物 - **比喩を使い回す** — 冒頭の比喩を中盤・終盤でも参照する - **具体例を豊富に** — 実際のコード・事件・ケーススタディ - **漢字を開く** — 「事」→「こと」、「為」→「ため」 Codex で日本語の質感をさらに詰める必要がある場合のみ、`references/codex-japanese-style.md` の補助ルールを追加で使う。 ### やらない - ❌ 箇条書きの多用（散文で書く） - ❌ 網羅しようとする（切り口で勝負） - ❌ AI的な前置き（「以下に説明します」「〜について見ていきましょう」） - ❌ 絵文字・ビックリマーク（扉の著者名以外） - ❌ 検索せずに推測で書いた数字・日付・価格 - ❌ 「〜だと言われる」「〜らしい」の多用 ### 著者の声サンプル（few-shot・最重要） 「散文で書け」「著者の立場を表明せよ」と書かれても、参考文が無いとモデルは無難な解説調に倒れる（特に Codex / Gemini）。以下を語り口の基準として参照すること。本文を書く前にこのサンプル群をもう一度読み、トーンを合わせてから書き始める。 サンプル1（評価を含めて切り込む）: > 筆者は、2023年の生成AIブームを「第三次AIブーム」と呼ぶことに違和感を持っている。前二回が研究室発の波だったのに対し、今回は最初から SaaS の課金モデルに乗って広がった点で性質が違う。OpenAI が ChatGPT Plus を月20ドルで売り出した瞬間、これは技術史ではなく流通史の話になったのだ。 サンプル2（業界の建前を疑う）: > 多くの SIer が「AI 内製化支援」という看板を掲げている。だが私見では、この言葉はかなり怪しい。内製化を本気で支援すれば自社の受注は減るはずである。にもかかわらず売上が伸びているなら、それは内製化「ごっこ」を売っているか、別の何かを抱き合わせているかのどちらかだろう。 サンプル3（自分の解釈を提示する）: > NTTデータが2024年に発表した「LITRON」は、日本語特化LLMの一つとして語られることが多い。しかし筆者は、これを技術製品としてではなく「金融・公共向けに説明可能性を担保した提案ツール」として読むのが正確だと考えている。実際、初期ユースケースの大半は議事録要約と稟議書ドラフトに集中していた。 サンプル4（読者への目配せ）: > ここで読者の中には「PoC で終わるのは AI に限った話ではない」と感じる方もいるだろう。その通りで、CRM 導入も BI 導入も同じ問題を抱えてきた。だが本書がこの章を割くのは、生成AIが他の技術より「PoC を生みやすい」構造的な理由を持っているからだ。それは次節で述べる。 サンプル5（歴史を引いて現在を相対化する）: > 1990年代後半の ERP ブームを覚えている読者なら、いま起きていることに既視感を抱くはずだ。当時も「業務をパッケージに合わせる」という掛け声のもと、各社が SAP R/3 の導入に走った。結果として残ったのは、カスタマイズで原型を留めない巨大なモノリスだった。生成AI 導入の議論は、この記憶を踏まえずに進めるべきではない。 共通する型: - 一人称（筆者は／私見では）または読者への呼びかけから入る - 必ず固有名詞・年号・数字を 1つは含める - 「〜と読むのが正確だ」「〜と呼ぶことに違和感を持っている」「〜だろう」のような 評価動詞・推量で締める - 結論を断定しつつ、根拠は次の段落・節に繋ぐ（「次節で述べる」「後述する」） - 体言止めの格言で締めない（次の項を参照） ### 格言調の禁止（最重要・追加ルール） 体言止めの格言・抽象的な総括は ビジネス書の悪い癖。1章につき多くて1個まで。 #### NG パターン辞書（このどれかに当てはまったら書き直し） 過去にこのスキルが出してしまった、または他モデル（特に Codex / Gemini）で頻出する型。本文中に出たら 即・書き直し。 1. 「Xは○○ではなく△△だ」型 - NG: 良い見積りは安い見積りではなく、再現可能な見積りである。 - NG: 対策は単発プロジェクトではなく恒常運用である。 2. 「重要なのは○○である」型 - NG: 重要なのは技術ではなく、運用である。 - NG: ここで重要なのは、組織としての継続性である。 3. 「我々が学ぶべきは○○だ」型 - NG: この事例から我々が学ぶべきは、変化への適応力である。 - NG: 教訓は、トップのコミットメントが不可欠だということだ。 4. 「真の○○とは」型 - NG: 真の DX とは、システムの刷新ではなく文化の刷新である。 - NG: 本当の意味での内製化とは、人材育成そのものだ。 5. 「単なる○○ではない」型 - NG: 生成AIは単なるツールではない、思考のパートナーである。 - NG: これは単なる効率化ではなく、ビジネスモデルの変革だ。 6. 「○○の本質は」型 - NG: AI 活用の本質は、データの質にある。 - NG: 問題の本質は、技術ではなく組織にある。 7. AI的前置き型 - NG: 以下、本節では○○について見ていきましょう。 - NG: それでは、具体的に説明していきます。 - NG: ここまでをまとめると、以下のようになります。 8. 安全な丸め型（出典なしの逃げ） - NG: 〜と言われている。〜とされている。〜と考えられている。（出典明示なしの多用） - NG: 一般的に、〜という傾向がある。 - NG: 多くの専門家は、〜と指摘している。（誰？） 9. 形容詞積み増し型 - NG: 重要かつ複雑で、多面的な検討が求められる課題である。 - NG: 高度に専門的で広範な知識が必要となる領域だ。 10. ふんわり総括型 - NG: 総じて言えば、バランスが大切である。 - NG: 結局のところ、人と人との関係に帰着する。 11. 二項対立の安直な提示型 - NG: 攻めの IT と守りの IT、その両立が問われている。 - NG: スピードと品質、トレードオフをどう乗り越えるかが鍵だ。 12. 比喩の言いっぱなし型 - NG: 生成AIは、現代のゴールドラッシュである。（で、何が言いたいのか） - NG: データは21世紀の石油だ。（手垢のついた比喩 + 解説なし） #### 共通する欠陥 これらは全て、別のトピック（DX、業務改革、組織論、人材育成、サステナビリティ…）にそのまま貼り付けても成立してしまう。これが「中身が無い」の正体である。置換テストに落ちる文章はすべてこの仲間。 #### 良い例（4点セット） > 富士通の時田社長は2024年度の決算説明会で「Uvanceは累計受注高2,000億円を超えた」と述べた。Uvanceは業種別ソリューション群の総称で、生成AIはその中の一つの売り方として位置付けられている。これは「個別案件の積み上げで売る」発想から「型を売る」発想への転換を示している。 固有名詞 + 数字 + 引用 + 含意の解説、という4点セット。NG パターンを書きそうになったら、この型に流し込めるか確認する。流し込めないなら 書かない（節を統合する、別の事例で書き直す）。 #### NG → 書き直しの実例 NG: 重要なのは技術ではなく、運用である。 書き直し: みずほ銀行の勘定系刷新（MINORI、2019年稼働）が示したのは、技術選定の良し悪し以上に「数千社規模のベンダーをどう束ねるか」という運用設計が成否を分けるという現実だった。本書がこの章で扱う生成AIプロジェクトも、構図は変わらない。 NG: 真の DX とは、文化の刷新である。 書き直し: 経済産業省が2018年に「DXレポート」で示した「2025年の崖」という言葉は、結果として技術論から組織論へ議論をスライドさせる役割を果たした。筆者はこの転換自体は妥当だったと考えるが、副作用として「文化を変える」という空疎な掛け声だけが残ってしまった面もある。 --- ## 出力形式 1. **デフォルト**: Markdown を `outputs/[トピック名]入門_第N版.md` に保存 2. 目次を扉の直後に配置 3. 章ごとに区切り線 `---` を入れる 4. 保存後は保存先の相対パスをユーザーに伝える 5. **PDF化の要求があった場合**: - `python .claude/skills/fictional-textbook/script/convert_to_pdf.py [Markdownのパス]` を実行 - 生成された PDF のパスもユーザーに伝える - ※ `markdown2` ライブラリが未インストールの場合はインストール 6. **EPUB化の要求があった場合**: - 同じスクリプトに `--epub` フラグを付けて実行: `python .claude/skills/fictional-textbook/script/convert_to_pdf.py --epub [Markdownのパス]` - `ebook-convert` に直接 `.md` を渡すと Mermaid が画像化されず素のコードブロックとして残るため必ずスクリプト経由で変換する - Calibre(`C:\Program Files\Calibre2\ebook-convert.exe`)が必要 ### 扉ページの記法上の注意(重要) PDF 変換時、スクリプトは「ファイル冒頭から最初の `---` まで」のテキストを扉メタデータとしてパースし、その範囲を丸ごと削除してからカバー画像オーバーレイを合成する。このため **表紙画像 `![表紙: ...](images/cover.png)` は最初の `---` より後ろ**(本文側)に配置すること。冒頭の `---` より前に置くと削除処理で img 自体が消え、PDF に表紙が出なくなる。 また、カバーオーバーレイの検出正規表現は alt が **`表紙:`(コロン付き)で始まる img のみ**にマッチする。`![表紙](...)` のようにコロンなしだと発動しない。 推奨の扉レイアウト: ```markdown # [タイトル] ## 【第N版】 [サブタイトル] [著者名(絵文字1つ)] YYYY年MM月 第N版 --- ![表紙: [タイトル]](images/cover.png) ## 目次 ``` --- ## 挿絵(画像生成プロンプトの埋め込み) ### 発動条件 デフォルトでは挿絵を入れない。本文のみで完結させる。 ユーザーから明示的に以下のような指示があった場合のみ、本セクションのルールで挿絵を扱う。 - 「挿絵を入れて」「イラストも」「画像も付けて」「図版を入れて」など 判断に迷う指示なら、勝手に追加せず一度ユーザーに確認する。 挿絵を入れると決まったら、Phase 1 に入る前(= Phase 0)に まず `script/check_config.ps1` を実行して実生成モードか fallback モード(プレースホルダのみ)かを確定させる。モードが決まらないと style 選択や命名規則の合意も進められないため、ここで分岐する。 ### 図解と挿絵の区別(重要) - 図解(概念図・フローチャート・年表・組織図・比較表) → 画像生成では作らない。Mermaid / 表 / 箇条書きで書く。画像生成は文字の正確性が破綻するため、図解には使えない - 挿絵(章扉のムードカット・場面イラスト・比喩の視覚化) → 本セクションの方式で埋め込む 「挿絵を入れて」と言われても、概念説明には図解(Mermaid 等)を使うこと。挿絵はあくまで雰囲気と記憶のフック。 ### 配置数の目安(1冊あたり) - 表紙 1枚 - 章扉カット 各章 1枚 - 章内シーン挿絵 重要章のみ 1〜2枚(コラム横や強い比喩の所) - 合計 12〜18枚 程度。入れすぎは入門書の風格を損なう(児童書化する) ### スタイルの固定(全挿絵で統一) 最初に1つ選び、本全体で同じ style 句を全プロンプトに埋め込む。執筆開始時にユーザーに選んでもらうか、内容に合わせて以下から1つ提案する。 - A: 鉛筆デッサン風モノクローム — 古典的入門書の風格 - B: 淡い水彩 + 線画 — 文芸寄り教養書(岩波新書系) - C: フラットなベクターイラスト、3〜4色限定 — ビジネス書・現代的 - D: 報道写真風セピア/モノクロ — 歴史・事件を扱う本 迷ったら A か B。技術書寄りなら C。 固定 style 句の例(B を選んだ場合): > soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), slight paper texture, editorial book illustration, restrained and literary mood これを毎プロンプトの末尾に必ず付ける(章ごとにスタイルを変えてはいけない)。 ### プロンプト・テンプレート ``` [Subject: 何が描かれているか、人物の概要・場所・行為] [Composition: アングル/構図/視線誘導] [Mood: 時間帯・光・空気感] [固定 style 句] [Negative: no text, no logos, no recognizable real people, no watermark] [Size: 1536x1024 (章扉・横長) / 1024x1024 (本文挿絵・スクエア) / 1024x1536 (表紙・縦長)] ``` `gpt-image-1.5` がサポートするのは上記3サイズのみ。16:9 / 4:3 / 2:3 のような一般的なアスペクト比表記は使わない(スクリプトが拒否するため)。 ### 良い例 章扉(第1章「生成AIブームの正体」、style B): > A crowded train platform in Tokyo at morning rush hour, faceless commuters in business suits walking past, one figure in the foreground stopped and looking up at a blank advertisement panel symbolizing a hollow promise. Slight motion blur on commuters. No text, no logos, no recognizable real people. Soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), editorial book illustration. Size 1536x1024. 比喩の視覚化(「PoC の罠」、style B): > A spiral staircase viewed from above that loops back to its own starting point, a single small figure climbing endlessly. Abstract architectural sketch feel. No text, no logos. Soft watercolor wash with delicate ink line work, muted earth tones with one accent color (deep blue), editorial book illustration. Size 1024x1024. ### 禁止事項 - 実在人物の似顔絵(企業経営者、政治家など) → 場面化して匿名の人物に置き換える - 企業ロゴ・商標(NTT、富士通、OpenAI など) → 背景のシルエットに留める - 画像内の日本語テキスト → 文字化けの温床。文字はキャプションで付ける - 章ごとにスタイルを変える → 統一感が崩れる - 画像で技術的事実を伝える(LLM の内部構造など) → 誤情報の温床。図解(Mermaid 等)で書く ### 画像の実生成(config.json が設定済みの場合) `script/config.json` が実キーに差し替わっている場合は、プレースホルダで止めずに `script/generate_image.ps1` を呼び出して PNG を実生成する。プレースホルダ方式はキーが未設定のときの fallback。 #### 設定チェックの手順(判定スクリプトを使う) 手動で `config.json` の中身を読んで判定しない。必ず `script/check_config.ps1` を呼び出し、その出力で分岐する。 ``` powershell -ExecutionPolicy Bypass -File "script/check_config.ps1" ``` 出力と exit code の対応: - `CONFIGURED: OpenAI` または `CONFIGURED: Azure`(exit 0) → 実生成モードへ進む - `NOT_CONFIGURED: <理由>`(exit 1) → プレースホルダのみで止める(キー未設定) - `NOT_CONFIGURED: <理由>`(exit 2) → config.json 欠損や JSON パース失敗。ユーザーに通知して指示を仰ぐ 判定スクリプト自体はキーを漏らさない(Configured か NotConfigured かだけを返す)。キー本文を読みたくなっても、本スキルから直接 `config.json` を cat しない。 #### 実行コマンド 挿絵1枚ごとに PowerShell から以下を実行する(Windows 環境・bash シェルから呼ぶ場合)。`-OutputPath` で最終ファイル名まで直接指定するため、生成後のリネームや移動は不要。 ``` powershell -ExecutionPolicy Bypass -File "script/generate_image.ps1" -Prompt "<英語プロンプト(固定 style 句を含む)>" -Size "<1024x1024|1024x1536|1536x1024>" -OutputPath "outputs/images/ch01_opener.png" ``` - `-Size` は 1024x1024 / 1024x1536 / 1536x1024 の3種のみ - `-OutputPath` は Markdown から参照するパス(`![挿絵](images/ch01_opener.png)` なら `outputs/images/ch01_opener.png`)をそのまま渡す。親ディレクトリはスクリプトが自動作成 - ファイル名は `images/ch[章番号]_[用途].png` 形式で統一(例: `cover.png`, `ch01_opener.png`, `ch03_column.png`) - プロンプトを埋め込んだ HTML コメントは本文側に残しておく(再生成時の履歴として有用) #### 失敗したときの扱い `generate_image.ps1` が API エラーや認証エラーで失敗した場合、そのコマの挿絵だけ プレースホルダ方式に戻す(全体の執筆は止めない)。ユーザーには「N枚中M枚は生成成功、残りはプロンプト埋め込みのみ」と明示する。 ### Markdown 埋め込み形式 挿絵を入れる位置に、以下の形式でプレースホルダとプロンプトをセットで埋め込む。config.json が未設定なら画像ファイル本体は生成しない(プロンプトの埋め込みまでが本スキルの仕事)。設定済みなら上記「画像の実生成」手順で PNG を作り、`![挿絵: ...](images/...)` のリンク先に配置する。 ```markdown ![挿絵: 早朝のオフィスでモニターに向かう30代の会社員](images/ch01_opener.png) ``` こうしておけば、画像が無くても alt テキストで本文は読める。後から任意の画像生成ツール(DALL-E / Imagen / Midjourney など)にプロンプトを流し込めば挿絵が完成する。 ファイル名は `images/ch[章番号]_[用途].png` 形式で統一する(例: `images/cover.png`, `images/ch01_opener.png`, `images/ch03_column.png`, `images/ch05_metaphor.png`)。 --- ## 仕上げ前のセルフチェック 各項目を満たさないなら出力しない。形だけ満たすのも禁止。 **分量と密度** - [ ] **1ターンで複数章を書こうとしていないか？（サボりの最大要因）** - [ ] 総字数が目標に達している（標準なら 100,000字以上） - [ ] 採用した版の章数レンジ上限を超えていない（簡易版 ≤8 / 標準 ≤12 / 本格版 ≤15） - [ ] 各節 (`### N.X`) が **1,500字以上** - [ ] 各コラムが **800字以上**、コラム数が 5本以上 - [ ] 抽象的な格言（「Xは○○ではなく△△だ」）が章ごとに1個以下か？ **取材と設計** - [ ] 事前に合意した「再帰的に分割した目次構造」に従っているか？ - [ ] リサーチ専用サブエージェントに素材ノートを作らせ、`outputs/` に保存したか?(該当する話題なら) - [ ] メインエージェントで直接 web_search を多用していないか?(コンテキスト圧迫のNG パターン) - [ ] 素材ノートの固有名詞が本文に登場しているか? 素材ノートに無い数字・人名を推測で書いていないか? - [ ] 扉に「第N版・サブタイトル・固有名詞・著者名・日付」が揃っているか？ - [ ] 冒頭の比喩が後半（最終章を含む）でも参照されているか？ - [ ] AI的な前置き表現が無いか？ **置換テスト（最後の関門）** - [ ] 各節を読んで「他のトピック（DX、業務改革、組織論など）に置き換えても成立する文章」が無いか? 1つでもあれば書き直し --- ## よくある失敗パターン ### 失敗1: 形式は満たしているが「ジェネリック格言集」になる 「良い見積りは安い見積りではなく、再現可能な見積りである」のような文。文字数は稼げるが、何の本にも貼れる。具体例（A社、B氏、Cツール）に降ろす。降ろせないなら書かない。 ### 失敗2: 章数を増やして総字数を稼ぐ 12章で合意したのに18章まで膨らむパターン。各章が薄くなる典型。**章数は厳守**。1章を厚くして稼ぐ。 ### 失敗3: 一気に書こうとしてサボる LLMの特性上、一度に数万文字を要求すると必ず内容がスカスカになる。章単位での執筆をやめ、**必ず「節（Section）」単位で1ターンを終わらせ、反復させること。** ### 失敗4: 節の中身が4文で終わる 節の見出しを並べるだけで「構造化した気」になる。各節 1,500字を死守。届かない節は別の節と統合する。 ### 失敗5: 検索が形骸化する Phase 1 で検索したのに本文に固有名詞が出てこない。検索した会社名・人名・事件名は **本文中で必ず使う**。使わないなら検索しなかったのと同じ。 ### 失敗6: 比喩が冒頭だけ 「港湾管制塔」と書いたのに、第3章以降で港湾の話が一切出ない。比喩は最低でも各章に1回参照する。最終章でも比喩に戻って締める。 ### 失敗7: ケーススタディが架空すぎて情報が無い 「とある自治体」「ある金融機関」では学びが無い。実在の事例を検索で見つけて使う。守秘義務的にどうしても架空にする場合も、実在の業界事例から抽出した具体的な数字・手順を入れる。 ### 失敗8: コラムが1段落で終わる 「コラムを入れた」というアリバイ作りになる。コラムは 800字以上、3〜6段落。1段落で終わるならそれは脚注であって、コラムではない。