book-chapter-generator

書籍の章の生成

バージョン： 1.1.2

変更履歴

• v1.1.2 — 「扱う概念」表の2列目の見出しを、略称の CIS Score から Concept Impact Score に変更しました。CIS はすでに Concept Impact Score の略であり、「Score」が重複していたためです。列見出しのみの変更であり、基盤となる cis フィールド、その計算方法、その他すべての動作に変更はありません。新たに生成される章に適用されます。以前のスキルバージョンで章をすでに生成している書籍では、独自の章生成スクリプトまたは表を別途更新するまで、これらのファイルに旧見出しが残ります。

• v1.1.1 — ステップ4.6の完了メッセージに、chapter-content-generator を実行する前に学習用マスコットを作成することを強く推奨する文言が常に含まれるようになりました（book-installer の学習用マスコットガイドを利用）。先にマスコットをデザインすれば、コンテンツの執筆時に各章へ配置できます。数十章がすでにできてから追加すると、各章に後から組み込む必要があります。また、Notes セクションの恒常的なルールとしても明記しました。章の設計やファイル構造に変更はありません。

• v1.1.0 — バージョンを SKILL.md のフロントマターで metadata.ibook.version として管理するようになりました。単独の version: キーではなく metadata: の下に置いているのは、厳格なパッケージ検証で仕様に定められた6つのフィールド以外のフロントマターキーが拒否され、スキルを claude.ai、Skills API、package_skill.py で利用できなくなるためです。動作に変更はありません。

• v1.0.0 — 破壊的変更： このスキルで初めてバージョン番号を管理するようになりました。ステップ1.4aでは、エッジリストから独自に「依存先の数」を計算しなくなりました。代わりに、learning-graph-generator v1.06+ で追加された learning-graph.json の各ノードの cis フィールドから、事前計算済みの Concept Impact Score（CIS） を直接読み取ります。CIS は依存先の単純な数よりも優れた重要度指標です。推移的な影響を捉えるためです（直接の依存先が少ない概念でも、その依存先に多くの依存先があれば、基礎的な概念として重要度が高い場合があります）。単純な依存先の数では、この重要度が過小評価されます。生成された各章の index.md にある「扱う概念」セクション（ステップ4.4）は、Concept 列と CIS Score 列を持つMarkdown の表になりました。従来の、末尾に (N dependents) が付いた番号付きリストに代わるものです。learning-graph.json を learning-graph-generator v1.06+ で再生成する必要があります（cis フィールドがないノードは、最小値の cis=1 として読み込まれます。グラフの読み込み時にコンソール出力を確認し、すべての概念が1になっている場合は再生成してください）。

概要

このスキルは、コースの説明、学習グラフ、概念の分類体系を分析し、知的な教科書のための包括的な章構成を作成します。すべての概念をちょうど1回ずつ扱い、依存関係を尊重し、コンテンツを各章に適切に配分する、最適な章のアウトラインを設計します。 このタスクは、学習グラフの生成後に順次実行します。

このスキルを使用するタイミング

次の場合にこのスキルを使用します：

• コースの説明が確定し、学習グラフが生成されている（learning-graph.json が存在する）
• 執筆を始める前に、章のコンテンツ構成を設計する必要がある

前提条件：

• /docs/course-description.md が存在すること
• /docs/learning-graph/learning-graph.json に約200個の概念が含まれていること
• 章のリンクを nav セクションに生成するため、mkdocs.yml ファイルが配置されていること

次の場合はこのスキルを使用しないでください：

• 学習グラフがまだ生成されていない（先に learning-graph-generator を使用してください）
• 章のコンテンツがすでにあり、更新だけが必要である

章の生成ワークフロー

このスキルでは、ファイルを生成する前にユーザーの承認を得る、4段階の逐次ワークフローに従います。

ステップ1：入力リソースの分析

章を設計する前に、次のリソースを分析します。

1.1 コースの説明を読む

/docs/course-description.md を読み、以下を把握します：

• コース名と対象読者
• 学習目標と学習成果
• 前提知識
• 全体的な範囲と目標

1.2 学習グラフを読む

/docs/learning-graph/learning-graph.json を読み込み、次の情報を抽出します。

• 概念の完全な一覧（通常は200個の概念）
• 概念の依存関係（前提条件として必要な概念）
• 分類カテゴリごとの概念のグループ分け
• コースに関するメタデータ

!!! info "学習グラフ = 概念依存グラフ（DAG）" 学習グラフは概念依存グラフ、つまり、各エッジが「依存する」関係を表す有向非巡回グラフ （DAG）です。トポロジカルソート、循環検出、推移的簡約の標準的なグラフ理論アルゴリズムに 適合するため、依存方向（エッジが概念から、その概念が依存する概念へ向かう方向）を 採用しています。

学習管理システムの中には、エッジが逆方向（前提条件から、その前提条件によって学習可能になる
概念へ向かう方向）を指す、**イネーブルメントグラフ**という別の形式を使うものもあります。
イネーブルメント方向は一部の教師にとって直感的ですが（「生態学を学ぶことで、生態系について
学べる」）、グラフアルゴリズムにはあまり自然ではありません。このプロジェクトでは依存方向のみを
使用します。

!!! danger "重要：learning-graph.json におけるエッジの方向" vis-network JSON 形式では、エッジは依存する概念から前提概念へ向かいます （依存方向）。

- エッジ `{from: 5, to: 1}` は、「生物多様性（5）は生態学（1）に依存する」という意味です。
- 「生態学から生物多様性へつながる」という意味ではありません（それはイネーブルメント方向です）。

**前提条件マップを構築するには：**
```python
prereqs = defaultdict(set)
for edge in data['edges']:
    prereqs[edge['from']].add(edge['to'])  # 正しい：依存方向
```

**`prereqs[edge['to']].add(edge['from'])` は絶対に使用しないでください。** これを使うと誤って
イネーブルメント方向に変換され、すべての依存関係が反転し、無効な章の順序が気付かれないまま
生成されます。このバグは大量のトークンを浪費し、全面的な再設計が必要になります。

次の点を検証します。

• グラフ構造が有効なDAGであること（循環依存がないこと）
• すべての概念に一意のIDが割り当てられていること
• 依存関係の参照先が有効であること

1.2a エッジの方向を検証する（必須）

章を設計する前に、次の手順でエッジの方向が正しいことを確認します。

1. prereqs[edge['from']].add(edge['to']) を使って前提条件マップを構築します。
2. 基礎概念を特定します（prereqs の項目数が0の概念）。
3. 基礎概念がシンプルな入門用語であることを確認します（例：「生態学」「エネルギー」「システム」）。
4. 高度な概念が基礎概念として現れる場合、方向が間違っています。作業を止めて修正してください。

# Quick validation
foundational = [n for n in data['nodes'] if n['id'] not in prereqs]
print(f"Foundational ({len(foundational)}):")
for n in foundational:
    print(f"  {n['id']}: {n['label']}")
# These should be simple/introductory. If you see "Sustainability",
# "Climate Change", etc., the edge direction is inverted.

この確認に合格するまで、章の設計に進まないでください。

1.3 概念分類を読む

/docs/learning-graph/concept-taxonomy.md が存在する場合は読み込み、次の内容を把握します。

• 分類カテゴリとその意味
• 概念の概念的なグループ分け
• 推奨される順序や学習の進行

1.4 設計上の制約を特定する

データを分析し、次の項目を特定します。

• 基礎概念：依存関係がない概念（早い段階に配置する必要があります）
• 高度な概念：依存関係が多い概念（後の段階に配置する必要があります）
• 依存関係の連鎖：前提条件の関係が続く長い系列
• 概念クラスター：まとめて扱うべき、関連する概念のグループ
• 終端概念：他の概念から依存されない概念（柔軟に配置できます）

1.4a 概念ごとのインパクトスコア（CIS）を確認する

learning-graph.json のすべてのノードには、事前計算済みの cis フィールドが含まれています （learning-graph-generator v1.06 以降で追加）。これは概念インパクトスコア（CIS）で、 PageRank 方式の再帰的な重要度指標です。CIS(x) = 1 + sum(CIS(d) for d in direct dependents of x)。単純な依存先数（直接の依存先のみ）とは異なり、CIS は推移的な影響度を捉えます。つまり、直接の依存先が 1～2 個しかない概念でも、その依存先自体に多くの依存先がある場合は、CIS が非常に高くなることがあります。このため、chapter-content-generator では、概念ごとの語数とテキスト以外の要素の目標値を、依存先の単純な数ではなく CIS に基づいて決定するようになりました。

# cis[concept_id] = the concept's pre-computed Concept Impact Score
cis = {n['id']: n.get('cis', 1) for n in data['nodes']}

# A concept with cis[cid] == 1 is a terminal concept (nothing transitively
# builds on it). A concept with a high cis[cid] is a foundational "hub"
# concept -- large amounts of the book's content ultimately rest on it,
# even if its direct dependents count is small.

妥当性チェック： すべての概念で cis == 1 と表示される場合、learning-graph.json は learning-graph-generator v1.06 より前のものであり、作業を続ける前に再生成が必要です。独自に依存先の数を計算して代用しないでください。

この cis マップをステップ 4 まで引き継ぎます。各章の「扱う概念」表で、各概念名の横に配置されます。

Step 2: 章構成を設計する

以下の原則に従って、最適な章構成を設計します。

2.1 章数を決定する

以下を基に、適切な章数（6～20）を選びます。

• 概念の総数：通常、概念が約 200 個の場合は 10～15 章が必要です
• 依存関係の複雑さ：依存関係が複雑な場合は、より多くの章が必要になることがあります
• 分類体系の分布：自然なまとまりが章の区切りを示します
• 対象読者：入門コースでは、章を小さくする必要がある場合があります

ガイドライン：

• 最低 6 章（非常に簡潔なコースの場合）
• 推奨範囲：10～15 章
• 最大 20 章（大学院レベルの包括的な内容の場合）
• 1 章あたり平均 10～20 個の概念を目指します

2.2 概念を章に割り当てる

以下の要件を満たすように、章への割り当てを設計します。

重要な要件：

1. 各概念は、必ず 1 つの章だけに含めます（重複や漏れがないこと）
2. 依存関係にある概念より先に配置しません（DAG 構造を守ります）
3. バランスよく配分します（概念が多すぎる章や少なすぎる章を避けます）

最適化の目標：

• 可能な場合は、関連する概念（同じ分類カテゴリ）をまとめます
• 基礎から発展的なトピックへと論理的に進む構成にします
• 各章の規模のバランスを取ります（概念が 8 個未満または 25 個を超える章を避けます）
• 自然な学習単位を形成する概念をまとめます
• 認知負荷を考慮します（章の中で難易度を組み合わせます）

2.3 章タイトルを作成する

各章のタイトルは、以下の条件を満たすようにします。

• タイトルケース形式を使用します
• 200 文字以内（1 行に収まる長さ）にします
• 章の主題を明確に表します
• 標準的な教育用語を使用します
• 広く知られている場合を除き、略語は避けます

例：

• 「グラフ理論の基礎入門」
• 「二分木と木の走査アルゴリズム」
• 「グラフ彩色問題とその応用」
• 「ネットワークフロー最適化の発展的トピック」

2.4 章の要約を書く

各章について、以下の条件を満たす1 文（20～40 語）の要約を書きます。

• 章で扱う内容を説明します
• 主要な概念やテーマに触れます
• 学習の進行における章の役割を示します

Step 3: 設計案をユーザーに提示して承認を得る

ファイルを作成する前に、以下の形式で章の設計案をユーザーに提示します。

## Proposed Chapter Structure

I've designed a [number]-chapter structure for your textbook covering [total] concepts.

### Chapters:

1. **[Chapter Title]** ([X] concepts)
   [One sentence summary]

2. **[Chapter Title]** ([X] concepts)
   [One sentence summary]

[... continue for all chapters ...]

### Design Challenges & Solutions:

[Discuss any challenges encountered and how the design addresses them, such as:]
- **Challenge**: Concept X has 15 dependencies, making placement difficult
  **Solution**: Placed in Chapter 8 after all prerequisites are covered in Chapters 1-7

- **Challenge**: Taxonomy category Y contains 45 concepts
  **Solution**: Split across Chapters 3, 6, and 9 to maintain logical flow

[... other challenges ...]

### Statistics:

- Total chapters: [X]
- Average concepts per chapter: [X.X]
- Range: [min]-[max] concepts per chapter
- All [total] concepts covered: ✓
- All dependencies respected: ✓

3.1 ユーザーの承認を得る

設計案を提示した後、次のように尋ねます。

Do you approve this chapter structure? (y/n)

If no, please specify what changes you'd like:
- Different number of chapters?
- Specific concepts moved to different chapters?
- Chapter titles revised?
- Different grouping strategy?

3.2 ユーザーからのフィードバックに対応する

ユーザーが「いいえ」と答えた場合、または変更を求めた場合：

• 具体的なフィードバックを確認します
• それに応じて章の設計を修正します
• 更新した構成を再提示します
• 承認を得るまで繰り返します

ユーザーが「はい」と答えた場合：

• ステップ 4 に進み、章ファイルを生成します

Step 4: 章のディレクトリ構成とファイルを生成する

ユーザーが設計案を承認したら、章の構成を作成します。

4.1 URL パス名を作成する

各章について、URL で使用できるパス名を作成します。

ルール：

• 小文字とハイフンのみを使用します（ほかの文字は使用しません）
• 特殊文字、句読点、数字をすべて削除します（番号付きプレフィックスの数字を除く）
• スペースはハイフンに置き換えます
• 必要に応じて略語を使い、名前を短く保ちます（50 文字未満）
• 説明的かつ簡潔な名前にします

例：

"Introduction to Graph Theory Fundamentals" → "intro-to-graph-theory"
"Binary Trees and Tree Traversal Algorithms" → "binary-trees-traversal"
"Advanced Topics in Network Flow Optimization" → "advanced-network-flow"

4.2 ディレクトリ構造を作成する

次のディレクトリ構造を作成します。

/docs/chapters/
├── index.md
├── 01-[url-path-name]/
│   └── index.md
├── 02-[url-path-name]/
│   └── index.md
├── 03-[url-path-name]/
│   └── index.md
[... continue for all chapters ...]

実装：

mkdir -p /docs/chapters
mkdir -p /docs/chapters/01-[url-path-name]
mkdir -p /docs/chapters/02-[url-path-name]
# ... continue for all chapters

4.3 メインの章インデックスを作成する

次の内容で /docs/chapters/index.md を作成します。

# Chapters

This textbook is organized into [X] chapters covering [Y] concepts.

## Chapter Overview

1. [Chapter 1 Title](01-[url-path-name]/index.md) - [One sentence summary]
2. [Chapter 2 Title](02-[url-path-name]/index.md) - [One sentence summary]
[... continue for all chapters ...]

## How to Use This Textbook

[Add 2-3 sentences about how readers should progress through the chapters, noting that dependencies are respected and concepts build on each other]

---

**Note:** Each chapter includes a list of concepts covered. Make sure to complete prerequisites before moving to advanced chapters.

4.4 各章のインデックスファイルを作成する

各章について、次の構造で /docs/chapters/[XX]-[url-path-name]/index.md を作成します。

# [Chapter Title]

## Summary

[Write a 2-4 sentence summary of what the chapter covers, expanding on the one-sentence version from the design. Include:]
- Main topics and themes
- How this chapter fits in the learning progression
- What students will be able to do after completing this chapter

## Concepts Covered

This chapter covers the following [X] concepts from the learning graph:

| Concept | Concept Impact Score |
|---------|-----------------------|
| [Concept Name 1] | 187 |
| [Concept Name 2] | 1 |
| [Concept Name 3] | 42 |
[... continue for all concepts in this chapter, in pedagogical order ...]

## Prerequisites

[If this is not the first chapter, list which previous chapters should be completed first:]

This chapter builds on concepts from:
- [Chapter X: Chapter Title](../[XX]-[url-path-name]/index.md)
- [Chapter Y: Chapter Title](../[YY]-[url-path-name]/index.md)

[If this is the first chapter or has no prerequisites within the book:]

This chapter assumes only the prerequisites listed in the [course description](../../course-description.md).

---

TODO: Generate Chapter Content

書式に関する重要な注意事項：

• Markdown リストの前には必ず空行を入れます（MkDocs の要件）
• 内部リンクには相対パスを使用します
• 概念名は learning-graph.json 内の表記と完全に一致させます
• 「Concepts Covered」は Concept 列と Concept Impact Score 列からなる Markdown テーブルです（番号付きリストではありません）。Step 1.4a で読み込んだ cis マップを使用し、この章内でほかの箇所に使われている教育上の順序に従って、概念ごとに 1 行ずつ記載します。テーブルの前には必ず空行を入れます（MkDocs の要件）。
• 見出し階層（# → ## → ###）を一貫して保ちます

4.5 MkDocs のナビゲーションを更新する

すべての章ファイルを作成した後、mkdocs.yml の Chapters: セクションに章を追加します。$BK_HOME/skills/book-installer/references/mkdocs-nav-editing.md を読み、そこに記載されている標準のナビゲーション編集ルール（書き込み前に読み込む、編集を順番に行う、自分のセクションだけを変更する、章ラベルには番号のみを使用する）に従います。

  - Chapters:
    - List of Chapters: chapters/index.md
    - 1. [Chapter 1 Title]: chapters/01-[url-path-name]/index.md
    - 2. [Chapter 2 Title]: chapters/02-[url-path-name]/index.md
    # ... continue for all chapters

4.6 完了を確認する

すべてのファイルを作成した後、ユーザーに完了を伝えます。以下のマスコットの推奨事項は必ず原文のまま含めてください。マスコットがすでに存在するように見えるかどうかに応じて省略したり、条件付きにしたりしてはいけません。

✅ Chapter structure generated successfully!

Created:
- chapters/index.md (main chapter overview)
- [X] chapter directories with index files
- Updated mkdocs.yml navigation

Strong recommendation: create a learning mascot before generating any
chapter content. Run the `book-installer` skill's learning-mascot guide (or
just ask to "add a learning mascot") now. The `chapter-content-generator`
skill places mascot admonitions as it writes each chapter, and retrofitting
a mascot into chapters that already exist is far more expensive than
designing one first.

Next steps:
1. Create a learning mascot (strongly recommended, see above) — run `book-installer`, then the learning mascot guide
2. Review the chapter structure: `mkdocs serve`
3. Navigate to the Chapters section to see all chapter outlines
4. Use the chapter content generation skill (when ready) to populate each chapter
5. Each chapter index.md has "TODO: Generate Chapter Content" as a placeholder

Statistics:
- Total chapters: [X]
- Total concepts assigned: [Y]
- All dependencies respected: ✓

設計原則

依存関係の管理

重要： 章の順序は DAG の構造に従う必要があります。

• 概念 B が概念 A に依存する場合、A は B より前（または同じ章）に配置します
• 章の割り当てを確定する前に、すべての依存関係を確認します
• トポロジカルソートを使用して、順序が有効であることを確認します

ユーザーに提示する前の必須検証：

次の厳密なチェックを実行し、Step 3 に進む前に違反ゼロを達成します。

# Build prereqs: from=dependent, to=prerequisite (NEVER invert this)
prereqs = defaultdict(set)
for e in data['edges']:
    prereqs[e['from']].add(e['to'])

# Map each concept to its chapter index
chapter_map = {}
for i, (title, cids) in enumerate(chapters):
    for cid in cids:
        chapter_map[cid] = i

# Check: every prerequisite must be in same or earlier chapter
violations = []
for i, (title, cids) in enumerate(chapters):
    for cid in cids:
        for dep in prereqs.get(cid, set()):
            if dep in chapter_map and chapter_map[dep] > i:
                violations.append(f"{nodes[cid]} ch{i+1} needs {nodes[dep]} ch{chapter_map[dep]+1}")

assert len(violations) == 0, f"{len(violations)} dependency violations found"

違反がある章構成をユーザーに提示してはいけません。 概念を章間で移動するか、章の順序を入れ替えて、すべての違反を修正してください。

コンテンツのバランス

章のサイズが均等になるようにします。

• 最適： 1 章あたり 12～18 個の概念
• 許容範囲： 1 章あたり 8～25 個の概念
• 避けるべき： 概念が 8 個未満（内容が薄すぎる）、または 25 個超（内容が密すぎる）

章が大きすぎる場合は、2 つの章に分割することを検討します。 章が小さすぎる場合は、関連する章との統合を検討します。

教育上の流れ

学習を支援できるように章を構成します。

• 前半の章： 基礎概念、シンプルな考え方、自信の構築
• 中盤の章： 中核となる内容、段階的に高まる複雑さ、実践的な応用
• 後半の章： 発展的なトピック、統合、総合

各章内では、概念を次の順に並べます。

1. 基礎から発展へ（依存関係に基づく）
2. シンプルな内容から複雑な内容へ（認知負荷に基づく）
3. 抽象から具体へ（新しい考え方を導入する場合）

認知負荷

学生の認知負荷を考慮します。

• 前半の章に詰め込みすぎないでください（学生はまだ背景知識を身につけている段階です）
• 可能な場合は、各章で難易度に幅を持たせます
• 関連する概念をまとめ、認知の切り替えを減らします
• 十分な足場かけを行います（前提となる概念は前の章で扱います）

よくある課題と解決策

課題：分類カテゴリが大きすぎる

問題：1つの分類カテゴリに40個以上の概念が含まれています。

解決策：

• カテゴリを複数の章に分割します
• 章の区切りには、異なる観点やサブテーマを使います
• 他のカテゴリを交互に配置して、興味を維持します

課題：依存関係の連鎖が長い

問題：概念ZはYに依存し、YはXに依存し、XはWに依存しています……（5段階以上の深さ）。

解決策：

• 連鎖を複数の章に分散させます
• 適切であれば、先行する依存概念を複数の章に配置します
• 依存関係の根幹が深い場合は、専用の「基礎」章の作成を検討します

課題：終端概念

問題：依存する概念がない（その概念を基に発展するものがない）概念があります。

解決策：

• 終端概念を関連する章の最後に配置します
• 終端概念を「追加トピック」または「特別トピック」の章にまとめます
• これらの概念が本当に必要か検討します（ただし、ユーザーの承認なしに削除しないでください）

課題：クラスターの分割

問題：自然な概念クラスター（例：5つの木の走査アルゴリズム）が1つの章に収まらないものの、分割するのは不自然に感じられます。

解決策：

• 続きであることが明確な「パート1」と「パート2」の章に分割します
• 依存関係を使って自然な分割点を見つけます
• 複雑さ（基礎と応用）または適用分野ごとにまとめます

課題：分布の偏り

問題：依存関係の構造により、第2章に30個の概念が入り、第7章には8個しか入りません。

解決策：

• 大きな章を2つの章に分割します
• 小さな章を隣接する章と統合します
• 章の区切りを見直し、よりバランスの取れた構成を探します
• 章の総数を調整します

検証チェックリスト

章の構成を確定する前に、次の点を確認してください。

• learning-graph.json のすべての概念が、ちょうど1つの章に割り当てられている
• どの概念も、その依存概念より前に配置されていない
• 章の規模が許容範囲内（概念8～25個）である
• 章のタイトルがタイトルケースで、200文字以下である
• URL のパス名に小文字とハイフン以外が含まれていない
• すべてのファイルが指定されたディレクトリ構成に従っている
• MkDocs のナビゲーションが正しく更新されている
• すべての Markdown ファイルが適切に書式設定されている（リストの前に空行を入れるなど）
• 各章の index.md に、必要なセクションがすべて含まれている
• 「扱う概念」が Concept と Concept Impact Score の列を含む表になっている（番号付きリストではない）
• ユーザーが章の設計を承認している

使用例

ユーザーの依頼： 「グラフ理論の教科書用に章を作成してください」

スキルのワークフロー：

1. course-description.md、learning-graph.json、concept-taxonomy.md を読む
2. 200個の概念とその依存関係を分析する
3. 内容の配分がバランスの取れた12章を設計する
4. 章の概要をユーザーに提示する：
   • 第1章：はじめに（概念15個）
   • 第2章：グラフの表現（概念18個）
   • ……など
5. ユーザーの承認を得る（はい／いいえ）
6. ディレクトリ構成とすべての index.md ファイルを作成する
7. mkdocs.yml のナビゲーションを更新する
8. 完了を確認する

注記

• このスキルで作成するのは、章の構成と概要のみです
• 実際の章の内容は生成しません（その作業には別のスキルが必要です）
• 「TODO: Generate Chapter Content」というマーカーは、後で内容を追加する箇所を示します
• コンテンツ生成スキルで使えるように、各章の index.md には概念リストを必ず残してください
• 概念ごとの Concept Impact Score 列は飾りではありません。chapter-content-generator はこの値を使って、各概念の目標語数と必要な非テキスト要素を決定します（chapter-content-generator/SKILL.md の「Elaboration Budget」を参照）
• ユーザーが章の内容生成に進む前に、学習マスコットを必ず強く推奨してください（ステップ4.6）。あらかじめ設計したマスコットは、執筆時にすべての章へ取り入れられます。後から追加すると、すでに生成したすべての章を修正する必要があります