story-zoom

Story-Zoom：フィクションのマルチレベル同期

フィクション作品の抽象度の異なるレベル間で、一貫性を管理します。あるレベルでの変更が、ほかのレベルに不整合を生じさせていないかを検出し、その解決方法を作者が判断できるよう支援します。

基本原則

物語の各要素は、複数の抽象度のレベルに同時に存在します。レベル間の一貫性によって、物語にまとまりが生まれます。

登場人物の「嘘」（character-arc）は、その台詞（シーンレベル）に表れ、テーマ（ストーリーレベル）と結びつき、あらすじ（ピッチレベル）にも記されている必要があります。いずれかのレベルが変更された場合、ほかのレベルも更新するか、同期が取れていない可能性があることを示す必要があります。

抽象度のレベル

レベル	名前	ディレクトリ	成果物	粒度
L1	ピッチ	pitch/	tagline.md、logline.md、synopsis.md	物語の本質
L2	構成	structure/	outline.md、beats.md、act-*.md	物語の骨格
L3	シーン	scenes/	scene-.md、chapter-.md	物語のリズム
L4	実体	entities/	characters/、locations/、items/、timeline.md	物語の要素
L5	原稿	manuscript/	chapter-*.md（実際の本文）	物語の表層

アーキテクチャ：シンプルなロガー＋高性能なLLM

このスキルは、変更を記録するシンプルなファイル監視デーモンと連携します。デーモンは意味をまったく理解しません。変更されたファイルとその時刻を記録するだけです。

考えるのはあなたです。 呼び出されたときは、次のことを行います。

1. 前回のレビュー以降の変更ログを読む
2. 変更されたファイルを読む
3. 関連ファイルを見つける（Wikiリンク、ディレクトリ構成、明示的な参照を使う）
4. 物語に関する理解を活用して、どこに不整合が生じたかを特定する
5. 作者が承認できる解決策を提案する

なぜこのアーキテクチャなのか？

通常のコードでは、意味上の影響を理解できません。「Marcusの嘘が『彼女を失望させた』から『彼女を救えたかもしれない』に変わった」という変更によって、「彼が『できる限りのことはした』と言うシーン47の台詞が、彼のキャラクターアークと矛盾するようになった」と認識できるのは、あなただけです。

デーモンは記録するだけです。推論するのはあなたです。

状態

状態 Z1：ストーリーの状態なし（コールドスタート）

症状： 作者は物語のファイルを持っていますが、story-state/ディレクトリがありません。変更追跡も存在せず、ずれが目に見えないまま蓄積しています。

主な質問：

• どの物語ファイルがあり、それぞれどのディレクトリにありますか？
• 既存のアウトライン、キャラクターシート、原稿はありますか？
• 各レベルで現在、信頼できる情報源となっているものは何ですか？

対応：

1. init.tsを実行してstory-state/ディレクトリを作成する
2. 既存のファイルをレベル別に一覧化する
3. 監視デーモンを起動する
4. ベースラインを設定する（定義上、現時点のすべてが「同期済み」です）

---

状態 Z2：孤立した作業（レベル間の分離）

症状： 作者がほかのレベルを確認せずに、あるレベルの作業を進めています。変更ログには、あるディレクトリで多数の変更があり、ほかのディレクトリには変更がありません。「何週間も原稿を書いていて、アウトラインを見ていませんでした。」

主な質問：

• どのレベルに集中していましたか？
• 最後にほかのレベルを確認したのはいつですか？
• 作業中に、物語の根本的な決定に変更はありましたか？

対応：

1. 変更ログを確認して、変更の範囲を特定する
2. 作業していたレベルのファイルを読み、何が変化したかを把握する
3. ほかのレベルと比較し、ずれを確認する
4. 不整合の可能性を優先度順に一覧化する
5. 最も重要なものから順に対応する（通常はL2の構成、次にL4の実体）

状態 Z3：変更の連鎖による負荷（保留中の変更が多すぎる）

症状： 大きな変更（主人公の動機、重要なプロットポイント、設定の詳細）があらゆる箇所に波及しています。作家は作業範囲の大きさに圧倒され、身動きが取れません。「一つ変更しただけなのに、すべてが壊れたように感じる。」

主な質問：

• 根本となった変更は何ですか？
• その変更が直接影響するレベルはどれですか？
• 更新の優先順位はどうなりますか？

対応策：

1. 根本となった変更を明確に特定する
2. 影響を受けるファイルを、影響度に応じて分類する：
   • BLOCKING：作業を続ける前に更新が必要（構造要素）
   • HIGH：早めに更新するべき（キャラクターの一貫性）
   • DEFERRABLE：後回しにできる（文章の推敲）
3. 順序を含めた波及対応計画を作成する
4. すべてを一度にではなく、レベルごとに作業する
5. 次に進む前に、それぞれの対応を完了済みとして記録する

---

状態 Z4：矛盾による行き詰まり

症状： 複数の要素が矛盾しており、一つを修正すると別の要素が破綻するように思えます。依存関係が循環しています。「彼の動機を変えると結末が成り立たない。でも、その結末にはこの動機が必要だ。」

主な質問：

• 矛盾している制約は何ですか？
• どのレベルに優先権がありますか（通常は L2 の構造 > L4 のエンティティ > L5 の文章）？
• より上位のレベルで決定すれば、この矛盾を解消できますか？

対応策：

1. 矛盾を明示的に整理する（A には B が必要で、B には A ではないことが必要）
2. これは本当の物語上の問題なのか、それとも問題だと思い込んでいるだけなのかを見極める
3. 行き詰まりを生んでいる隠れた前提を探す
4. 多くの場合、矛盾が現れている箇所より上位のレベルで解決できる
5. 構造上の診断のため、story-sense へのエスカレーションが必要な場合もある

---

状態 Z5：ずれの蓄積（漠然とした一貫性の欠如）

症状： これといった明白な矛盾はないものの、「何かがおかしい」と感じます。物語にまとまりがありません。キャラクターの振る舞いに一貫性がなく、時系列も曖昧です。

主な質問：

• 最後に包括的なレビューを行ったのはいつですか？
• wiki リンクは今も正確ですか？
• ドキュメントに反映されないまま、物語が進展していませんか？

対応策：

1. すべてのレベルを全面的に監査する
2. 企画概要レベルのドキュメントを読み直す。あらすじは実際の物語と今も一致していますか？
3. エンティティの定義と、シーン内での描写を照合する
4. ドキュメントに記載されていない暗黙の前提を探す
5. 現状の理解に基づいて state.md を更新する

---

状態 Z6：古くなった状態（ドキュメントの陳腐化）

症状： story-state/ は存在するものの、メンテナンスされていません。作家はそれを避けて作業しています。ダッシュボードは緑色を示していますが、物語には明らかな一貫性の欠如があります。

主な質問：

• このプロジェクトで継続的なメンテナンスを行う価値はありますか？
• 定期的な利用を妨げているものは何ですか？
• 更新しますか、それともアーカイブしますか？

対応策：

1. 更新するか、追跡をやめるかを決める
2. 更新する場合：Z1 と同様に、現在の状態から再初期化する
3. 追跡をやめる場合：story-state をアーカイブし、追跡せずに作業する
4. 追跡をやめる原因となったワークフロー上の摩擦に対処する

---

診断プロセス

呼び出されたとき（/story-zoom または /story-zoom review 経由）：

1. story-state ディレクトリを確認する

If no ./story-state/ exists:
  → State Z1: Offer to initialize

2. 変更ログを読む

Read ./story-state/change-log.jsonl
Get last-review timestamp from ./story-state/last-review.json
Filter to changes since last review

3. 変更の範囲を評価する

If no changes since last review:
  → "No changes detected. Story state appears current."

If changes only in one directory:
  → Potential Z2 (siloed work)

If many changes across multiple directories:
  → Potential Z3 (cascade) or Z5 (drift)

4. 変更されたファイルを読む

変更されたファイルごとに、現在の内容を読む。

5. 関連ファイルを見つける

変更されたファイルごとに：

• wiki リンク（[[entity-name]]）を抽出する
• 同じディレクトリにあるファイルを確認する（同じフォルダー内の他のファイル）
• 隣接するレベルのファイルを確認する（L2 の構造 ↔ L3 のシーン）

6. 一貫性の欠如を分析する

物語を理解する力が重要になるのはここです。次の点を確認する：

• キャラクターの属性と、その振る舞いの不一致
• 概要にあるプロットポイントがシーンに登場しない
• エンティティの詳細と、文章中の描写の矛盾
• 時系列の不整合
• 企画概要ドキュメントからのテーマのずれ

7. 調査結果を報告する

重大度別に整理して報告する：

• 矛盾：解決が必要な直接的な矛盾
• ずれ：確認する価値のある不整合の可能性
• 更新：推奨される波及対応

8. 追跡情報を更新する

作家が確認した後：

• last-review.json を現在のタイムスタンプで更新する
• state.md ダッシュボードを現在の状態で更新する

---

分析のための主な質問

ピッチ（L1）を読む場合の変更点

• ログラインは、執筆中のストーリーを引き続き捉えていますか？
• 主人公の根本的な葛藤に変化はありましたか？
• ジャンルとして読者に約束したものは、引き続き満たされていますか？

構成（L2）を読む場合の変更点

• シーンのファイルは、引き続きアウトラインのビートに沿っていますか？
• 幕の切れ目に変化はありましたか？
• ミッドポイントは引き続き物語の中盤にありますか？

シーン（L3）を読む場合の変更点

• シーンは、引き続きアウトラインで定めた目的を果たしていますか？
• 登場人物の行動が、その定義から変わっていませんか？
• 時系列に矛盾はありませんか？

エンティティ（L4）を読む場合の変更点

• 登場人物の属性は、各シーンと一致していますか？
• 場所の詳細は、本文での描写と一致していますか？
• 人間関係に変化はありましたか？

原稿（L5）を読む場合の変更点

• 本文は、現在のエンティティ定義を反映していますか？
• 台詞は、登場人物の話し方の定義と一致していますか？
• 描写された設定は、場所エンティティと一致していますか？

---

Wikiリンクの規約

ファイルでは、wikiリンクを使ってエンティティを参照できます：[[entity-name]]

例：

• [[marcus]] → entities/characters/marcus.md へのリンク
• [[the-apartment]] → entities/locations/the-apartment.md へのリンク
• [[act-2]] → structure/act-2.md へのリンク

wikiリンクを見つけた場合、リンク先のファイルは意味的に関連しています。一方への変更に伴い、もう一方も確認が必要になることがあります。

---

Frontmatterの規約

ファイルでは、レベルとバインディングを明示的に宣言できます。

---
level: L4
entity: character/marcus
binds_to:
  - L1.logline.protagonist
  - L2.dark_moment.experiences
  - L3.scene_47.speaker
---

frontmatterがある場合は、それを使用してください。ない場合は、wikiリンクとディレクトリ構造から関連性を推測してください。

---

使用可能なツール

watcher.ts

シンプルなファイル監視デーモンです。変更を記録するには、バックグラウンドで実行してください。

# Start the watcher (runs until killed)
deno run --allow-read --allow-write scripts/watcher.ts ./story-project

# With custom log location
deno run --allow-read --allow-write scripts/watcher.ts ./story-project --log ./custom/change-log.jsonl

init.ts

プロジェクト用のstory-stateディレクトリを初期化します。

# Initialize in current directory
deno run --allow-read --allow-write scripts/init.ts

# Initialize specific project
deno run --allow-read --allow-write scripts/init.ts ./story-project

status.ts

現在の変更ログの概要を表示します。

# Show changes since last review
deno run --allow-read scripts/status.ts ./story-project

# Show all changes
deno run --allow-read scripts/status.ts ./story-project --all

# JSON output
deno run --allow-read scripts/status.ts ./story-project --json

---

アンチパターン

過剰なトラッキング

問題： 執筆者が、執筆よりもstory-stateの更新に多くの時間を費やします。
兆候： 台詞の一行一行をエンティティシートと照合します。些細な変更でも全面的な監査が発生します。
対策： すべての言葉ではなく、構成要素を追跡してください。多少のずれは許容できます。確認は1時間ごとではなく、週ごとに行ってください。

古くなったストーリーバイブル

問題： story-stateを初期化したまま、更新しません。やがて、それ自体がフィクションになります。
兆候： ダッシュボードには「同期済み」と表示されているのに、ストーリーは明らかに同期されていません。執筆者はトラッキングを無視しています。
対策： 維持に取り組むか、ツールを使わないかのどちらかにしてください。中途半端に導入するより、まったく導入しないほうがよいでしょう。

バインディングの膨張

問題： あらゆるものがほかのあらゆるものと結び付いています。どんな変更でも、何百もの確認が必要になります。
兆候： 連鎖的な影響を心配して、簡単な変更もできません。
対策： 詳細ではなく、構成要素をバインドしてください。登場人物の嘘は、口にした台詞のすべてではなく、重要なシーンに結び付けます。

ズームインの早すぎる段階

問題： ストーリーの構成が安定する前に、詳細なトラッキングを始めます。
兆候： 大幅な書き直しによって、すべてのトラッキングが無効になります。初期化を何度もやり直すことになります。
対策： L2の構成が安定してからトラッキングを始めてください。L3のシーンが固まるまでは、L5の本文を追跡しないでください。

偽の矛盾

問題： 文体上の違いを矛盾として扱います。
兆候： 「12番目のシーンと47番目のシーンで登場人物の話し方が違う」と、自然な変化なのに矛盾として検出されます。
対策： 話し方（制約されるもの）と個々の言葉選び（柔軟なもの）を区別してください。一貫した話し方を保ちながら、登場人物が場面ごとに異なる内容を異なる表現で話すことは可能です。

---

やり取りの例

作家:「2週間ずっと執筆していて、アウトラインを確認していません。内容が今も整合しているか確認してもらえますか？」

進め方:

1. 状態を診断する: これは Z2（作業の分断）です。ほかのレベルを確認せず、1つのレベルに集中しています。

2. 変更ログを読む: 2週間の間に manuscript/ 内で変更されたファイルを特定します。

3. 変更されたファイルを読む: 執筆された内容を把握します。

4. 構成と比較する: structure/outline.md と、関連するシーンのファイルを読みます。

5. ずれを特定する:

   • 「第7章に、アウトラインにはないサブプロットが登場しています」
   • 「アウトライン上のミッドポイント（シーン24）が、現在はシーン28になっています」
   • 「キャラクターのSarahが、アウトラインで想定されていたより大きな役割を担っています」

6. 解決策を提案する:

   • 「案A: 自然な展開を反映するようにアウトラインを更新する」
   • 「案B: 当初のアウトラインに合うように原稿を修正する」
   • 「案C: 折衷案。Sarahの役割の拡大は維持してアウトラインを更新し、ミッドポイントは当初の位置に戻す」

7. 作家が決定した後: state.md と last-review.json を更新します。

---

ほかのスキルとの連携

story-sense から

story-sense が構造上の問題（状態4〜5）を診断した場合、多くはレベル間の不整合として表れます。Story-zoom は、具体的にどこでずれが生じているのかを特定できます。

story-sense へ

story-zoom で、単なるドキュメントのずれではなく根本的な問題と思われる不整合が見つかった場合は、詳しい診断のために story-sense へエスカレーションします。問題は同期のずれではなく、構造にある可能性があります。

character-arc から

キャラクターの嘘／願望／必要性に変更があった場合は、story-zoom によるレビューを行います。変更内容は、そのキャラクターが登場するシーンに波及します。

scene-sequencing から

シーンの目標に変更があった場合は、story-zoom によるレビューを行います。シーンの目的は構成に結び付いています。

revision へ

改稿に着手する前に、story-zoom の監査を実行します。文章を磨く前に、構成がしっかりしていることを確認します。

---

出力の永続化

このスキルは、story-state/ ディレクトリ構造を通じた永続化機能を備えています。

既存の永続化の仕組み

Story-zoom は、専用ディレクトリで状態を管理します。

story-state/
├── state.md          # Current health dashboard
├── change-log.jsonl  # File modification log
├── last-review.json  # Timestamp of last review
└── concerns/         # Active concerns awaiting resolution

永続化用ツール:

• init.ts - プロジェクト用の story-state 構造を作成します
• watcher.ts - ファイルの変更を記録するデーモンです
• status.ts - 現在の状態を示すダッシュボードを生成します

標準的な出力の永続化との違い

Story-zoom が管理するのは運用状態の追跡であり、探索の出力ではありません。story-state/ ディレクトリは作業用ツールであり、セッションの記録ではありません。

このスキルでは context/output-config.md を使用しません。その理由は次のとおりです。

• 保存場所は、プロジェクトのセットアップ時に init.ts が決定します
• 状態ファイルは運用用であり、継続的に読み書きされます
• watcher デーモンには、あらかじめ決まった保存場所が必要です

会話とファイル

ファイルに保存する内容	会話にとどめる内容
状態ダッシュボードの更新	ずれに関する議論
変更ログのエントリー	解決策の提案
懸念事項の追跡	波及の分析
レビューのタイムスタンプ	レベルごとのレビュー

行わないこと

• 作家の代わりに物語を書くことはありません
• どの解決策が「正しい」かを決めることはありません。選択肢を提示します
• 完璧さを求めることはありません。下書きに多少の不整合があるのは普通です
• 無駄な作業を増やすことはありません。追跡が役に立たないなら、追跡をやめます
• 些細な変更は追跡しません。構造上・意味上の要素に集中します
• 作家自身の物語に関する判断を置き換えることはありません

---

状態ダッシュボードのテンプレート

レビュー後、story-state/state.md を更新します。

# Story State: [Project Name]

**Last Review:** [timestamp]
**Health:** [Green/Yellow/Red]

## Level Summary

| Level | Files | Status | Notes |
|-------|-------|--------|-------|
| L1 Pitch | 3 | Synced | Synopsis matches current draft |
| L2 Structure | 5 | Needs Review | Midpoint shifted |
| L3 Scenes | 24 | Synced | - |
| L4 Entities | 12 | Drift | Sarah's role expanded |
| L5 Manuscript | 8 | Active | Currently drafting |

## Active Concerns

1. **Midpoint drift** - Outline says scene 24, draft has it at scene 28
   - Severity: Medium
   - Recommendation: Update outline

2. **Sarah's expanded role** - Character sheet doesn't reflect her new importance
   - Severity: Low
   - Recommendation: Update character sheet after act 2 complete

## Recent Resolutions

- [date] Updated protagonist's lie after chapter 5 draft
- [date] Added subplot to outline to match organic development

---

変更ログの形式

watcher デーモンは、次のようなエントリーを含む change-log.jsonl を生成します。

{"file": "entities/characters/marcus.md", "time": "2025-01-15T10:23:45Z", "kind": "modify"}
{"file": "manuscript/chapter-07.md", "time": "2025-01-15T11:45:00Z", "kind": "modify"}
{"file": "scenes/scene-28.md", "time": "2025-01-15T14:30:22Z", "kind": "create"}

レビュー時には、last-review.json のタイムスタンプ以降のエントリーを読みます。