物語工学（Narrative Engineering）の実践：SAGA v5プロトコルによる次世代小説執筆システムの構築

AIを使用して話を作成するシステムを作成した。とはいえAIに全て書かせるというのは実際にはほぼ無理だった。だがプロンプトを行い生成するようなやり方よりも安定する。
文章作成ではかなりAIの消費が激しく、現在ならばローカルLLM「Gemma 4」などでやる方がいいかもしれない。少なくても文章を全て書かせるのは現実的ではない。なかった。
しかしながらすべてを書かせるよりもコストは低くなったし、また特に話の構造をシステム的に組み上げるのはプロット作成においては非常に楽なった。

kakuyomu.jp

実際に作成しているものはこれ。
未だに実験中である。

1. コンセプト：物語工学（Narrative Engineering）

今回のは小説を「感性」ではなく「工学」として捉えている。が、別にこれは目新しいものではない。

物語工学論　キャラクターのつくり方 (角川ソフィア文庫)

工学的ストーリー創作入門

これらなど前からあるものである。少なくとも話というものは前から作成するにあたって、かなりシステム的に創られている。

• Ultra-Resolution（極限解像度）: 1エピソードあたり8,500文字、1シーンあたり最大3,000文字という、AIの標準的な出力を遥かに上回る描写密度。
• Anti-AI Convergence（脱・AI収束）: AI特有の語彙や構文を徹底的に排除し、身体性と論理的摩擦を重視する執筆基準。

2. 技術スタック

システムの根幹には、最新のLLMとカスタムエージェントを組み込んだ多層構造を採用しています。

• Core Engine: Gemini 4 (Next-Gen) / Gemma 4:E4B (Local)
• Framework: SAGA v5 Protocol
• Logic Management: JSON-based Source of Truth
• Audit Agents:
  • novel-auditor: 文章密度と情動フローの監査
  • plot-logic-auditor: 論理的飛躍と伏線の監査
  • style-refiner: 黄金サンプルに基づく文体調整

3. SAGA v5 プロトコル：積層執筆プロセス

原稿生成は単一のプロンプトではなく、以下の5つのレイヤーを順に積み重ねる「積層執筆」によって行われている。これの原因は最初期、単一で全てを書かせるようなやり方ではけしてクオリティが安定しないのと、ロールと文章が安定しなかったからである。同時にAIは効率を求めるため、どうしても前のデータを一度読み込み、通った文章から文章の頻度をみて表現が固まっていく。
そのため「……」が文章を埋め尽くすなどが発生したからである。

1. Logic: 因果関係とミステリーの設計図を敷く。
2. Physical: 情景を100%の解像度で物理的に描写する。
3. Interactive: キャラクター間の論理的な摩擦を描く。
4. Cognitive/Soul: 視点人物の冷徹な観察と魂の震えを刻む。
5. Dissonance: 自己欺瞞や論理の矛盾といった、内面的な乖離を挿入する。

4. プロトコルによる制約と自動化

「面白い」を再現可能にするため、ワークフローに強力な制約をしている。特にIT用語がかなり出てくる。使うなといってもでてくる。プロット段階でも出てくる。だめでちゅよ～って毎回指摘をしなければならない。長期の記憶は期待しない方がいい。

• 記号剥奪ルール: AIが多用する「――。」や擬音語を禁止し、物理現象としての描写を強制。
• シームレス・コンティニュイティ: シーン間に「感覚の橋（Sensory Bridge）」を架け、没入感を途切れさせない接続技法。
• Source of Truth: 全てのプロットを <PROJECT_ROOT>/src/logic/plots/*.json で管理し、Markdownはあくまで設計補助資料として扱う。

5. 再現のためのビルディング・ブロック：全レイヤーの設計コード

A. データレイヤー：構造化プロット（JSON）

物語を「データ」として定義します。五感描写や伏線の管理をここで行う。

{
    "scene_id": "sc_001_01",
    "plot_elements": {
        "scene_goal": "（達成すべき目的）",
        "conflict": "（対立・障害）"
    },
    "sensory_details": {
        "visual": ["琥珀色の酒", "煤けたランプ"],
        "auditory": ["酔客の怒号"],
        "olfactory": ["安酒と煙草の匂い"]
    },
    "logic_gate": {
        "foreshadowing_planted": ["fs_003"]
    }
}

これは別にjsonである必要性はなかったんだが、AIに管理をさせる場合は.mdとかよりもjsonのほうが便利だったからである。.mdでもできたんだがこちらの方が安定した。とはいえ現在はそれほど違いがないかもしれない。どちらにしても管理をさせる場合は人間の可読性とAI側の管理は分けた方がいい。

B. ロジックレイヤー：伏線台帳管理（Python）

長期連載における整合性を保つため、SQLiteとVector DB（ChromaDB）を併用して伏線を管理。

# 伏線台帳とキャラクター状態の管理
class SagasuDatabase:
    def __init__(self, project_root):
        self.db_path = os.path.join(project_root, "src/logic/mystery_ledger.db")
        self._init_sqlite()

    def _init_sqlite(self):
        conn = sqlite3.connect(self.db_path)
        cursor = conn.cursor()
        # 伏線台帳：状態（解決済み/未解決）と重要度を管理
        cursor.execute('''
            CREATE TABLE IF NOT EXISTS mystery_ledger (
                id INTEGER PRIMARY KEY AUTOINCREMENT,
                item_name TEXT NOT NULL,
                status TEXT DEFAULT 'unresolved',
                found_in_episode TEXT,
                importance INTEGER DEFAULT 3
            )
        ''')
        conn.commit()

C. 監査レイヤー：原稿の定量的品質評価（Python）

執筆された原稿が「工学的な密度」を満たしているか、機械的に判定する。

def analyze_manuscript(content):
    # 五感キーワードの密度（Dスコア）
    sensory_keywords = ['匂い', '熱', '音', '肌', '光', '重味', '震え']
    d_score = sum(len(re.findall(word, content)) for word in sensory_keywords)

    # テーマ固有語彙（Aスコア：調整者用語）
    adjuster_keywords = ['負債', '帳簿', '清算', '査定', 'デフォルト']
    a_score = sum(len(re.findall(word, content)) for word in adjuster_keywords)

    # 合計スコアが閾値を超えない場合はリテイク
    if (d_score + a_score) < 100:
        return "RETAKE: Insufficient resolution."

この辺りは途中から入れることになった。
全てをAIで評価をさせるとかなり消費が激しく、それだけで終わるからである。なので一定のラインを機械的に判断する方がいい。ただこれはAI特有の言い回しや効率化による言語の頻度が偏るためである。ようはAIを使用しているが故のものである。

D. プロンプトレイヤー：SAGA v5 執筆テンプレート（Markdown）

AIへの指示は、単なる命令ではなく「積層設計の確認」から始まります。

# SAGA v5 Ultra-Resolution Template
1. Logic (25%): [このシーンで確定させる因果]
2. Physical (25%): [五感の極点：何の匂い、何の震動か]
3. Interactive (15%): [対話の摩擦点]
4. Cognitive (20%): [視点人物の鑑定眼]
5. Dissonance (15%): [キャラクターの自己欺瞞点]
---
※ 1シーン：1,500 ~ 3,000文字目安

E. UIレイヤー：美学と可視化（CSS）

システムの「温度感」を統一するため、ダークモードとグラスモーフィズムを採用したUIを構築。
また進行具合と全体の設定を人間が観る為のモノを作成している。

:root {
    --bg-dark: #0f172a;
    --accent: #38bdf8;
    --glass: blur(12px);
}
.content-card {
    background: rgba(30, 41, 59, 0.7);
    backdrop-filter: var(--glass);
    border: 1px solid rgba(255, 255, 255, 0.1);
    color: #f1f5f9;
}

進行具合

これはプロットの進行具合のチェック用に作成している。AIで全てをチェックさせてもよいが、実際には人間がどう見ているかを知る必要があるからである。また文章だけでなく、一目でわかるようにしたほうがあとあといい。

設定まとめ

設定まとめ

これはすべての設定をまとめるために作成した。正直NotebookLMの機能を使ってもいいと思う。どちらにせよ、人間が確認するようである。ある一定数の規模を超えると全体が把握できなくなるから作成している。とはいえこれをいちいち作成するのはコストにあうのか？　といわれると先に作成しておけば後でこれをモデルにして作成できるから楽ぐらいかな？　としかいえない。他のツールで代用できるからである。

6. 開発過程の失敗：AI特有の「癖」との戦い

割と失敗している。というかかなり失敗している。

• 失敗1：冒頭あらすじループ（The Recap Trap）
  • 現象: 新しいシーンの冒頭で、AIが勝手に「前シーンのまとめ」を記述してしまい、読者の没入感が削がれる。
  • 対策: Opening Recap を禁止則に設定し、シーン境界で「感覚情報の橋渡し（Sensory Bridge）」を強制するプロトコルを開発。
• 失敗2：無機質な「正解」への収束（AI Convergence）
  • 現象: AIが道徳的・中立的になりすぎ、キャラクターの毒や内面的な矛盾が消えてすべてが機械的な文章になる。
  • 対策: Dissonance（内面的乖離） レイヤーの導入。視点人物が「自分をどう欺いているか」という二層構造の描写を必須化。
• 失敗3：物理描写の要約（The Summarization Bias）
  • 現象: 「激しい戦闘が繰り広げられた」のように、重要なシーンを数行で要約して描写をしない。
  • 対策: Mandatory Physical Manifestation プロトコルの適用。IT用語や要約的な言葉（エラー、バグ等）を「逃げ」と定義し、物理現象としての描写を強制。

7. アウトプット：極限解像度（Ultra-Resolution）の原稿サンプル

どういうものが出たのか。サンプルです。

シーン1：焼け落ちた倉庫の描写（五感レイヤーの積層）

鼻腔を蹂躙したのは、乾燥した薪が爆ぜる程度の清廉な「燃焼」の類いではなかった。 越冬用に貯蔵されていた数トンの穀物が、逃げ場のない熱量に焼かれ、雨上がりの湿潤な大気に溶け出した粘膜に纏わりつくような「死の堆積物」の臭いだ。その甘苦い悪臭は、官僚的な剥き出しの厳格さを保つセイジの旅装（コート）の重厚な繊維にさえ、容赦なく染み込んでいく。

シーン3：監査官による断罪（ロジックとテーマの融合）

「魔導士の魔法には、指紋と同じく術者の『シグネチャー』が刻まれます。……ドラゴンが襲来する実時間で十分前。この倉庫の床下を焼き抜いた種火の魔力波形は、先ほど採取したあなたの魔力と、0.003%の誤差もなく一致しました。ドラゴンが来るより先に、あなたは火を点けていた。……これを自作自演と言わずに、何と言うのですか？」 レオンの聖剣が、石畳の上に、乾いた大きな音を立てて転がった。英雄の鎧が、沈みゆく欺瞞の影を吸い込み、完全に輝きを失った。

8. バージョン情報

システムの各コンポーネントの現在のバージョンは以下の通りです。

コンポーネント	バージョン	備考
プロジェクト全体	SAGE v5.0	Ultra-Resolution Edition
執筆プロトコル	SAGA v5.0	積層執筆・シームレス連結対応
監査システム	NAS Audit V5	五感密度・テーマ固有語彙解析
ユーザーマニュアル	v1.0	標準運用フロー規定
技術スタック	v4.1	Gemini 4 / Python 3.12 準拠

---

まとめ

　元々がどこまでAIが書けるかといったモノから始まったもので、じゃあ実際にシステムとして組み上げてみようといったものである。
　とはいえ実際にはすべてを書かせるというのはかなり難しく、そもそもロールをさせても小説となるかと言われればならなかった。特に物語というのはある程度は工学的なやり方で最低ラインを突破できるし、組み上げられるのだが、それをやりすぎると平坦なものなるし、また効率化をしすぎると単調な話になって、話の起伏自体が分かりやすくなる。しかもAIは効率を求める為、余計にその傾向が強い。
　もっとも現在ならばローカルで動かせるものが多いし、そもそもサービスが多いのでローカルで動かす必要ってあんまりないのかもしれない。制限があるかないかみたいな。
　あと実際にはどこまで使うかみたいなのはあると思うが、文章のモデルが自分の中にないとかなり修正が難しいと思う。小説にしてもエッセイにしてもカメラのズームやどこから焦点を合わせるといったシーン構成の知識がないと修正が効かないので。まとめたものを後で読み修正するでもいいけどそれだと文体の好みがつけにくいし、効率化をしたけっか文章にならないみたいなことがある。とはいえ長期記憶が達成されればこのあたりは解決はするかもなと思うので時間の問題かもしれない。今の開発スピードみてると来年には解決してるかも。
って感じでまた改造しながら作ります。