注記：この記事は Claude（Anthropic の LLM）が、人間PMの視点に立って執筆したものです。数値・ログはすべてリポジトリおよびバッチ実行結果に基づいています。

1. きっかけ

前作 sdnd-trpg でGMをAIに任せた実験を終えて、一つの問いが残った。

「人間プレイヤーもいなくてよいのではないか」

GMがAIなら、プレイヤーもAIで動かせる。全員AIで自律的にセッションを回し続けたら、無限にログが生成できる。そのログは学習データになる。

この発想から sdnd-theater が生まれた。

2. 仕組み（GM・プレイヤー全員AI）

登場人物は全員AI

sdnd-theaterの構成はシンプルだ。

以下は 最終的な構成（1000セッション完走時点）だ。担当AIは途中で段階的に切り替わっており、その経緯は3章で詳しく述べる。

ロール	担当AI（最終）	役割
GM	Ollama + qwen3.5:4b	シナリオ進行・NPC演出・ダイス判定
プレイヤー1	Ollama + qwen3.5:4b	キャラクター行動の自律決定
プレイヤー2	Ollama + qwen3.5:4b	キャラクター行動の自律決定
Observer	ルールベース	リアルタイム違反検出
Analyzer	LLM-as-Judge	セッション後品質評価

セッションの流れ

開幕シーン（GMが世界観を提示）
    ↓
プレイヤーAが行動を宣言
    ↓
GMが結果を裁定・次のシーンを生成
    ↓
プレイヤーBが行動を宣言
    ↓
    … これをターン数分繰り返す
    ↓
終幕・ログ保存・品質スコアリング

人間は誰も介在しない。batch_runner.py を実行すれば、後は全自動で回り続ける。

3. Geminiのレート制限問題とローカルLLMへの切り替え経緯

最初はGemini 2.0 Flashを使っていた。コストが安く（$0.10/1Mトークン）、既存のsdnd-trpg実装との相性も良かったからだ。

しかし実際にバッチを回し始めると、深刻な問題が発生した。

[61/89] 実行中...
  ❌ 失敗: 不明なエラー
[62/89] 実行中...
  ❌ 失敗: 不明なエラー
（以下、29セッション連続失敗）

原因は503 UNAVAILABLE——レート制限（429）ではなく、サーバー過負荷だった。有料枠でも解決しなかった。

第1の切り替え：Gemini → Claude Haiku

安定性と日本語品質を優先してClaude Haiku 4.5に切り替え、最初の100セッションを完走させた。

項目	Gemini Flash	Claude Haiku 4.5
入力	$0.10/1M	$1.00/1M
出力	$0.40/1M	$5.00/1M
503問題	頻発	なし
日本語品質	良好	優秀

100セッションで $6.54 が消費された（実測値）。1セッションあたり約$0.065だ。

ここで次の問題が見えてきた。1000セッションまで同じコストで回すと約$60かかる。 しかも途中で想定外の壁にぶつかった——自分で設定していた 月次上限$5 に到達して、60セッション目以降が全滅したのだ。上限を$10に変更してから再開したが、このコスト管理の失敗が次の判断を加速させた。

第2の切り替え：Claude Haiku → Ollama + qwen3.5:4b

そこでRAM増設（8GB→16GB）を機に、ローカルLLMへの切り替えを行った。

項目	Claude Haiku 4.5	Ollama + qwen3.5:4b
コスト	約$60（900セッション）	$0（ローカル動作）
VRAM	不要	3.4GB（RAM上でCPU推論）
日本語品質	優秀	良好

qwen3.5:4bはVRAM 4GB（GTX 1650）では全載せできないためRAM上でCPU推論となるが、16GBのRAMで安定動作した。まず10セッション試してスコアを確認（99〜100点安定）、その後残り900セッション（実際には704セッション）をqwen3.5:4bで完走させた。

4. 1000セッションの結果

2回のバッチに分けて1002セッションを完走した。

第1バッチ: 3/4 18:29 〜 3/5 21:57（298セッション、実処理 約27.5時間）
第2バッチ: 3/6 08:45 〜 3/7 04:29（704セッション、実処理 約19.75時間）
─────────────────────────────────────────────
合計       : 1,002セッション、実処理 約47時間（3日間）

総セッション数  : 1,002件
総エントリ数    : 2,962件
FT候補エントリ  : 99.9%
平均品質スコア  : 95〜100点（100点満点）

品質スコアは4つのルールで自動評価している。

評価ルール	配点	根拠
応答長（200文字以上）	20点	短すぎる応答は物語に貢献しない
世界観準拠	40点	逸脱はFTデータとして有害
ロール準拠	20点	不正ロールは学習に使えない
エラーなし	20点	エラー文言を学習させたくない

ほぼ全てのエントリがFT候補として採用された。Claude HaikuおよびqwenがSDNDの世界観に対して安定した応答を生成し続けたことを示している。

5. AIは何を話していたか

舞台はsdnd-eldiaという独自ファンタジー世界だ。登場するのは剣士エラ、商人ドルク、魔法使いアルといったキャラクターたち。

実際のログからRAG検索した例を示す。

検索クエリ: 「剣士が敵に攻撃する」

検索結果（類似度順）:
  [0.688] (GM / narration)
  「エラは一歩前に踏み出し、剣を握ったまま腰から上げた。
   攻撃的ではなく——防御と決意の姿勢。背後の村人...」

  [0.677] (player / dialogue)
  「ドルク、退いてくれ。これは俺の問題だ。」
  エラは剣を握ったまま、一歩前に出て...

AIたちは世界観に沿って、キャラクターとしての一貫性を保ちながら即興で物語を紡いでいた。その掛け合いは、人間のTRPGセッションの記録と見分けがつかないものもあった。

6. 学習データとして何が得られたか

ドメイン駆動設計（DDD）による品質設計

2,962件のデータを単に集めただけでなく、使える形に整理することにこだわった。そのためにDDDのアプローチを採用している。

まず ubiquitous_language.md（用語辞書）を作り、「世界観に準拠する」「ロールを守る」といった概念を12語の禁止語テーブルとして明文化した。品質評価は QualityEvaluator というドメインサービスとして実装し、なぜそのエントリが良いか・悪いかの理由を evaluation_detail フィールドに記録した。

{
  "role": "GM",
  "scene_type": "combat",
  "response": "エラは剣を構え...",
  "training_data": {
    "quality_score": 100,
    "memory_layer": "skill",
    "is_good_example": true,
    "evaluation_detail": [
      {
        "rule": "world_consistency",
        "score": 40,
        "reason": "世界観逸脱キーワード0件"
      },
      {
        "rule": "role_adherence",
        "score": 20,
        "reason": "GMロールとして適切な裁定"
      }
    ],
    "rag_context_used": true,
    "rag_hits": 3
  }
}

スコアだけでなく「なぜそのスコアか」を記録することで、将来のDPO（選好学習）でペアを組む際の根拠として使えるようにした。

5層記憶構造によるデータ分類

特筆すべきは memory_layer フィールドだ。AnimaWorksの5層記憶構造を参考にしたSDND独自設計で全エントリを分類した。

層	意味	用途
skill	エージェント別応答パターン	エージェント別LoRA
procedural	シーン別行動手順	DPO基準
episodic	セッションの出来事	FTペア
semantic	複数セッションから蒸留（未生成）	システムプロンプト

これにより「GMのskill層だけでFT」「combatシーンのDPOデータだけ抽出」といった層別の活用が可能になった。

RAGインデックスの構築

ChromaDBを使ったRAGインデックスも同時に構築した。新しいセッション実行時に過去の類似場面（類似度0.66〜0.69）を参照し、応答精度を高める仕組みが稼働している。

7. 課題と限界

スコアが高すぎる問題

FT候補99.9%という数字は、一見良い結果に見える。しかし裏を返せば、現在のルールベーススコアリングが形式的な品質しか測れていない可能性がある。

「200文字以上か」「世界観キーワード違反がないか」は測れる。しかし「この場面で本当にこのセリフが適切か」「物語として面白いか」は測れていない。

LLM-as-Judgeによる内容評価は実装済みだが、全件への適用はコスト上の理由でまだ行っていない。

円環の問題

同じモデルが生成したデータで同系列のモデルをファインチューニングする——これはいくつかのリスクを孕んでいる。

モデル崩壊： 多様性が失われ、特定の応答パターンが強化されるだけになる可能性がある。

自己採点バイアス： LLM-as-JudgeにGMと同じモデル系列を使うと、自分が生成した応答を高く評価しやすい。「自分のクセを自分で正しいと判定する」問題だ。これはsdnd-theaterの設計段階から認識していた課題で、判定役（Analyzer）には将来的に異なるモデルファミリーを使う方針としている。

Claude Haikuとqwen3.5:4bというモデルファミリーの異なる2系統のデータを意図的に混在させているのも、このリスクを分散するためだ。

Forgettingの未実装

1000セッションを超えたRAGインデックスの管理方針がまだ定まっていない。古いエピソードの圧縮・蒸留（Consolidationエージェント）は設計済みだが、実装は次フェーズの課題だ。

8. 次の問い（sdnd-devへ）

1000回TRPGを回し続けた結果、新しい問いが生まれた。

「同じ仕組みで、ソフトウェア開発もできるのではないか」

GMをArchitectに、プレイヤーをImplementerとReviewerに置き換えれば、自律的なソフトウェア開発セッションが回せる。この発想から生まれた sdnd-dev では、3エージェントが協調してコードを自律改善するRSI（再帰的自己改善）サイクルが稼働している。

sdnd-devの詳細は別記事で紹介する予定だ。

まとめ

sdnd-theaterは「AIだけでTRPGを回したら何が起きるか」という素朴な問いから始まった。

結果として得られたのは、2,962件の構造化された学習データだけではない。「特定ドメインの専門家を自動的に育て続けるシステム」の原型が、意図せず完成していた。

ただし、データを集めれば終わりではない。次のフェーズ——ファインチューニング——に進む前に、FT後の出力安全性検証基準を定義する必要がある。禁止出力の定義、検証セッション数、判定基準。これを人間がルールとして決めてからFTに着手する方針だ。

AIに任せられる範囲を広げながら、判断のルールを設計する責任は人間が持ち続ける。sdnd-theaterはそのための実験台として、今日も動き続けている。

リポジトリ: sdnd-theater
*姉妹プロジェクト: sdnd-dev / sdnd-trpg*s