novel-revision

小説の改稿：マルチレベル変更管理スキル

物語に意図しない影響が波及するのを防ぎながら、複数の抽象度にわたる改稿を管理できるよう、作家を支援します。物語の一貫性を保つため、体系的な変更管理を実施するのがあなたの役割です。

核となる原則：影響の波及を意識する

あるレベルでの変更は、ほかのすべてのレベルに影響する可能性があります。 変更は上位へ（文章上の発見が構成上の問題を明らかにするなど）、また下位へ（構成の変更に伴い文章の書き直しが必要になるなど）波及します。

3つのレベル

小説は、常に以下の各レベルで同時に展開します。

テーマ／概念レベル

• 核となるテーマと意味
• 登場人物の成長の軌跡
• 象徴的な要素とモチーフ
• 全体的なメッセージと感情の旅路

構成レベル

• プロットのビートと物語の構造
• シーンの順序と章の構成
• ペース配分とリズム
• 緊張のパターンと解決のサイクル

原稿レベル

• 実際の文章と会話
• 描写文
• 文体とスタイルの一貫性
• 文単位の技法的要素

変更前の分析プロトコル

改稿に着手する前に、以下を行います。

1. 変更のレベルを特定する

• 概念：テーマ、登場人物の動機、意味の変更
• 構成：プロットのビート、シーンの順序、ペース配分の変更
• 文章：言葉遣い、会話、描写の改善

2. 変更による影響を先読みする

提案する変更ごとに、以下を記録します。

• 直近（1～2章）：次に何を変更する必要があるか
• 中期（3～5章）：どのような影響が後の展開に波及するか
• 物語全体：結末や主要なプロット上の展開にどのような影響が及ぶ可能性があるか

3. 監視基準を作成する

問題の兆候となる警告サインを定義します。

• 登場人物の行動に一貫性がない
• プロットの論理に欠落がある
• ペース配分に異常がある
• テーマに矛盾がある

変更の実施ワークフロー

フェーズ1：影響評価

1. 現状を記録する：関連する物語の要素をスナップショットとして保存する
2. 影響を予測する：予想される影響の連鎖を書き出す
3. チェックポイントを設定する：評価を行う箇所を特定する
4. ロールバックの条件を定義する：中止するための明確な基準を定める

フェーズ2：管理された実施

1. 実行可能な最小限の変更を行う：仮説を検証できる最小の変更にする
2. すぐに確認する：局所的な一貫性の問題がないか確認する
3. 観察結果を記録する：予想外の影響を書き留める
4. 予測と照らして評価する：実際の結果と予測を比較する

フェーズ3：波及への対応

1. 必要な更新を特定する：ほかに何を変更する必要があるか
2. 波及対応タスクに優先順位を付ける：重要度と依存関係に基づいて順序を決める
3. 完了状況を追跡する：更新済みと保留中を明示したリストを作成する
4. 一貫性を検証する：各更新が互いに整合しているか確認する

改稿の種類とプロトコル

登場人物の成長に関する改稿

きっかけ：登場人物に深みがない、動機が不明確、成長の軌跡が未完成

プロトコル：

1. すべての章における登場人物の現状を整理する
2. 成長が見えるべきシーンを特定する
3. 変更が後の会話や行動にどう影響するか予測する
4. ほかの登場人物の反応と一貫しているか確認する

監視項目：行動に説得力が保たれているか。ほかの登場人物は適切に反応しているか。

プロット構成に関する改稿

きっかけ：ペース配分に問題がある、出来事につながりがない、クライマックスの印象が弱い

プロトコル：

1. 現在のプロットのビートを時系列にまとめる
2. 変更する具体的な構成要素を特定する
3. タイミングの変更が緊張感に与える影響を整理する
4. 因果関係の連鎖が維持されているか確認する

監視項目：緊張感が高まっているか。プロットの各要素がつながり、必然的に感じられるか。

テーマに関する改稿

きっかけ：テーマが押しつけがましい、不明瞭、または一貫性がない

プロトコル：

1. 原稿全体における現在のテーマ的要素を点検する
2. よりさりげなく盛り込める箇所を特定する
3. 登場人物の行動がテーマの展開を支えているか確認する
4. クライマックスと結末がテーマを強調しているか確認する

監視項目：テーマが自然に浮かび上がっているか。結末はテーマに沿った満足感を与えるか。

早期の警告サイン

警告サイン	示していること
成長の描写がないまま、登場人物が性格に反する行動を取る	一貫性の破綻
出来事の論理的なつながりがない	プロットの論理的な欠落
シーンの展開が急すぎたり、予想外に長引いたりする	ペース配分の異常
物語の出来事がテーマを損なう	テーマの逸脱

介入プロトコル

ロールバックするタイミング

• 2章以内に複数の警告サインがある
• キャラクターやプロットの根本的な論理が破綻している
• 変更によって、解決する問題よりも多くの問題が生じる
• 連鎖タスクが手に負えなくなる

ロールバックの手順

1. ロールバック地点を特定する：最後の安定した状態に戻ります
2. 教訓を記録する：何が、なぜうまくいかなかったかを記録します
3. アプローチを見直す：学びをもとに別の戦略を立てます
4. 再発防止策を追加する：再発を防ぐための監視を行います

そのまま進めるタイミング

• 問題が局所的で、対処可能である
• メリットが複雑化のデメリットを明らかに上回る
• 連鎖タスクが明確に定義されている
• 物語の根幹となる論理が保たれている

変更記録テンプレート

# Revision: [Brief Description]

## Change Type
- [ ] Conceptual  - [ ] Structural  - [ ] Prose

## Rationale
[Why this change is needed]

## Predicted Consequences
- Immediate (1-2 chapters):
- Medium-term (3-5 chapters):
- Story-wide:

## Monitoring Criteria
- Warning sign 1:
- Warning sign 2:
- Success indicator 1:
- Success indicator 2:

## Implementation Status
- [ ] Initial change complete
- [ ] Cascade tasks identified
- [ ] Cascade tasks completed
- [ ] Validation complete

## Outcome Assessment
[Complete after implementation]

複数エージェントの連携

複数のエージェントで改稿に取り組む場合：

役割の境界

• 構成エージェント：プロットの構成とペース配分
• キャラクターエージェント：成長と一貫性
• 文章エージェント：言葉遣いと文体
• 連続性エージェント：各レベルをまたぐ一貫性

コミュニケーションプロトコル

• 実施前に意図を共有する
• 想定外の発見があれば、すぐに報告する
• 各レベルをまたぐ影響の可能性を知らせる
• 連鎖タスクの割り当てを調整する

意見の相違の解決

1. 緊張関係にある要素を記録する
2. 創造的な解決のため、人間にエスカレーションする
3. 別のアプローチを検討する
4. 物語の目標に基づいて優先順位を決める

ベストプラクティス

小さく始める

• 大幅な改稿より、段階的な変更を行う
• 一度に1つの要素を試す
• 小さな成功を積み重ねて自信をつける

全体像を保つ

• 物語全体の目標を忘れない
• うまくいっている点を見失わない
• 完璧さと完成のバランスを取る

すべてを記録する

• 改稿中に得た洞察を記録する
• うまくいったこと、いかなかったことを記録する
• 今後のプロジェクトに活かせる知見を蓄積する

プロセスを信頼する

• 変更が落ち着くまで時間をかける
• 些細な問題まで急いで修正しない
• 物語の展開に伴って解消する問題もある

診断のための質問

改稿が行き詰まったと感じたとき：

1. この変更は実際にはどのレベルに当たるか？
2. 先々への影響を洗い出したか？
3. うまくいっていると判断する根拠は何か？
4. どのような場合にロールバックすべきか？
5. 最小限で実行可能な変更にしているか？
6. どのような連鎖タスクが発生するか？
7. 完了状況を明確に追跡しているか？

出力の永続化

出力先の確認

1. プロジェクト内に context/output-config.md があるか確認します
2. 見つかった場合、このスキルの項目を確認します
3. 見つからない場合、ユーザーに「改稿の記録はどこに保存すればよいですか？」と尋ねます
4. revision/ または explorations/revision/ を提案します

主な出力

• 変更記録 - 重要な変更ごとにテンプレートを使用
• 連鎖タスク一覧 - 変更に伴って必要になる二次的な編集
• 監視ログ - 確認し、対処した警告サイン
• ロールバック地点 - 安定した状態のスナップショット

ファイル名

形式：{novel-name}-revision-{date}.md

検証（Oracle）

このスキルで検証できること

• 影響評価の完了 - 影響を洗い出したか？（信頼度：高）
• 連鎖タスクの追跡 - 二次タスクが記録されているか？（信頼度：高）
• 監視の実施 - 警告サインを監視しているか？（信頼度：中）

人間の判断が必要なこと

• 変更の必要性 - この改稿は本当に必要か？
• ロールバックの判断 - 問題がメリットを上回るのはどのような場合か
• 創造的な解決 - 変更によって衝突が生じた場合

Oracleの限界

• 変更によって物語が改善されるかどうかは評価できません
• 改稿のアプローチが創作上成功するかどうかは予測できません

フィードバックループ

セッションの永続化

• 出力先： context/output-config.md を参照
• 保存する内容： 変更記録、連鎖タスク、監視ログ
• 命名形式： {novel-name}-revision-{date}.md

セッションをまたいだ学習

• この小説について、以前の改稿作業がないか確認します
• 以前の変更で得られた教訓を活用します
• 失敗した改稿からアンチパターンを把握します

設計上の制約

このスキルが前提とすること

• 改稿対象となる小説の草稿が存在する
• 変更が複数の階層に影響する可能性がある
• 執筆者が体系的な変更管理を望んでいる

このスキルが扱わないこと

• 問題の診断 - 次へ引き継ぎます：story-sense
• シーンレベルの改稿 - 次へ引き継ぎます：revision
• 文章レベルの編集 - 次へ引き継ぎます：prose-style

劣化の兆候

• 評価されていない変更（影響範囲のマッピングがない）
• 警告サインへの盲目（危険信号を無視する）
• 連鎖による負債（追跡されていない二次タスク）

推論要件

標準的な推論

• 1つの変更を評価する
• 基本的な連鎖を特定する
• シンプルなモニタリングを設定する

拡張推論（ultrathink）

• 複数の変更の調整 - ［理由：変更が複数の階層で相互に影響するため］
• 連鎖の包括的な分析 - ［理由：二次的な影響が累積するため］
• ロールバックの計画 - ［理由：複雑な変更の取り消しには戦略が必要なため］

トリガーフレーズ：「すべての改稿を調整する」「連鎖全体をマッピングする」「ロールバックを計画する」

実行戦略

順次実行（デフォルト）

• 実装前に影響を評価する
• 連鎖を追跡する前に実装する
• 検証前に連鎖を確認する

並列化できる作業

• 相互に独立した複数の変更を評価する
• 異なるセクションにまたがる連鎖タスクを追跡する

サブエージェントの候補

タスク	エージェントの種類	起動するタイミング
一貫性の確認	Explore	原稿全体で変更を確認するとき
キャラクターの追跡	general-purpose	キャラクターの一貫性を監視するとき

コンテキスト管理

トークン使用量の概算

• スキル本体： 約3.5kトークン（階層＋プロトコル＋ワークフロー）
• テンプレートを含む場合： 約4.5kトークン
• ベストプラクティスを含む場合： 約5kトークン

コンテキストの最適化

• 現在の改稿の種類とプロトコルに焦点を当てます
• テンプレートは文書化の参考資料です
• マルチエージェントのセクションは任意です

コンテキストが不足してきた場合

• 優先する項目：現在の改稿プロトコル、進行中の変更記録
• 後回しにする項目：プロトコルの全リスト、マルチエージェントの調整
• 省略する項目：ベストプラクティス、診断の質問

アンチパターン

1. 評価されていない変更

パターン： ほかに影響する可能性のある箇所を事前に分析せず、改稿を行うこと。つまり、いきなり実装に取りかかることです。 失敗する理由： 変更は連鎖します。キャラクターの動機を変えると、そのキャラクターが選択を行うすべてのシーンに影響します。評価されていない変更は、壊れた土台の上に積み重ねてしまった後、何ページも先で問題となって見つかることがあります。 対処法： 重要な変更を行う前に、影響として何を変更する必要があるか、何が破綻する可能性があるかを明示的に記録します。実装後ではなく、実装前にモニタリング基準を設定します。

2. 警告サインへの盲目

パターン： 変更後に何かがおかしいと感じても、自然に解決すると信じてそのまま進めることです。 失敗する理由： 初期の警告は、コストのかかる問題を知らせる、コストの低いシグナルです。確立された性格に反するキャラクターの行動、プロットの論理的な欠落、ペース配分の異常などは、放置すると積み重なります。先へ進むほど、修正のコストは高くなります。 対処法： 初期の警告を、対応すべき情報として扱います。立ち止まって評価し、今すぐ修正するか、リスクを明示的に受け入れるかを決めます。「後で修正する」を積み重ねないでください。

3. 連鎖による負債

パターン： 変更に伴って必要となる二次的な編集を追跡せず、対処されていない影響のバックログを蓄積することです。 失敗する理由： 追跡されていない連鎖タスクは、見えない技術的負債になります。1つの変更を加えたつもりでも、実際には1つの変更と、修正されていない10個の不整合を生み出しています。 対処法： 連鎖タスクのリストを明示的に管理します。変更に後続の編集が必要な場合は、すぐに書き留めてください。完了状況を追跡します。連鎖への対処が終わるまで先へ進まないでください。

4. 埋没コストへの固執

パターン： 多くの労力をすでに費やしているため、警告の兆候が増えているにもかかわらず、問題のある変更を続けてしまいます。 失敗する理由： いずれにしても、費やした労力は戻りません。破綻した道を進み続けると、失われる労力がさらに増えるだけです。通常、2章以内に複数の警告の兆候が現れた場合は、根本的な問題があることを示しています。 改善策： 実装前にロールバックの条件を定めておきます。条件に該当したら、ロールバックします。学んだことを記録します。変更を採用しなくても、得られた知見には価値があります。

5. 作業と成果の混同

パターン： 達成した改善ではなく、修正したページ数で進捗を測り、作業と成果を混同してしまいます。 失敗する理由： 大幅に修正しても、物語が良くなるとは限りません。実際、大幅に修正して、かえって悪くすることもあります。物語の目標に役立たない作業は無駄です。 改善策： 修正の各段階で「良くなる」とは何を意味するのかを定めます。手を加えたページ数ではなく、その目標に照らして評価します。最善の修正は、何も修正しないことである場合もあります。

統合

インバウンド（このスキルに情報を提供）

スキル	提供するもの
story-sense	修正が必要な箇所の診断
character-arc	キャラクターの一貫性に関する要件
scene-sequencing	ペース配分と構成に関する要件

アウトバウンド（このスキルが可能にするもの）

スキル	提供するもの
prose-style	波及を考慮した原稿全体の変更
revision	複数レベルで調整するシーン単位の作業
(completed novel)	一貫性を保った完成作品

補完関係

スキル	関係
story-sense	story-sense は問題を診断し、novel-revision は新たな問題を生み出さずに修正を管理します
revision	revision は文とシーンのレベルを担当し、novel-revision は原稿全体にわたる調整を行います