「10万件、作ればよくない？」から始まった
VIUK StoryというキャラクターAIを作っています。
やりたいことは、けっこう欲張りです。
- 好きなキャラクターと一対一で話せる
- 複数のキャラクターが自然に掛け合う
- 必要ならAIがナレーターにもなる
- 風景、時間、登退場、秘密も覚えている
- 雑談や相談もできる
- 本気で遊びたいときは、ちゃんと物語にもなる
要するに、チャットボットとゲームマスターと小説の語り手を、一つのassistantにやらせたい。
内部では、この役割をUnified Scene Controllerと呼んでいます。
名前は強そうです。
そして僕は考えました。
これ、質のいい会話を10万件くらい作って学習させれば、かなり強くなるのでは？
そこから、無料APIを集め、DeepSeek Webへ手動で貼るテンプレを作り、ModalでGPUを増やし、バッチを8、16、32と詰める方法を考え始めました。
一回20件なら、5,000回貼れば10万件です。
数字にすると狂っていますが、毎日少しずつやれば、なぜか行けそうな気がしてきます。
人間は、5,000回を一度に想像できないので強い。
さらにGPUも最大10台まで並べました。
これで爆速だ、と思ったところで、もっと大きな問題に気づきました。
そもそも、この設計のまま10万件作って大丈夫なのか？
速く生成する方法ばかり考えていましたが、設計が間違っていたら、GPUは間違ったデータを爆速で量産するだけです。
危ないところでした。
VIUK Storyは「一人を演じるAI」ではない
最初のVIUK Storyは、比較的分かりやすい設計でした。
systemにキャラクター設定があれば、その人物として話す。設定がなければ、VIUK Story自身として普通に雑談や相談をする。
systemなし
-> VIUK Storyとして話す
systemにキャラクター設定あり
-> そのキャラクターとして話す
でも、キャラクターチャットを調べていくと、一対一だけでは終わりません。
会話が長くなると友人が入ってくる。敵が現れる。店員が注文を聞きにくる。外では雨が降り、時間も進み、さっき落とした鍵があとで見つかる。
そこで、assistantが一人だけを演じる方式から、AI側の場面全体を扱う方式へ広げました。
assistantが制御するもの
・AI側キャラクターの発話と行動
・複数人物の掛け合い
・ナレーション
・風景と環境
・時間進行
・場面内の出来事
この発想自体は悪くありません。
実際、一対一の恋愛会話でも、相手の表情や部屋の空気は大事です。複数人物のRPGなら、話者の切り替えや登退場が必要です。
問題は、「場面全体」という言葉が強すぎたことでした。
事故その1：AIがユーザーの身体を乗っ取る
場面をきれいに完成させようとするモデルは、足りない部分を自然に補います。
例えば、こんな感じです。
彼女はおそるおそる手を差し出した。
あなたは小さくうなずき、その手を取った。
小説なら普通です。
でも、対話型AIではアウトです。
ユーザーは、まだ手を取ると言っていません。
もっと悪化すると、こうなります。
「ずっと一緒にいてくれる？」
あなたは迷わず彼女を抱きしめ、永遠を誓った。
いや、誓っていない。
ユーザーが画面の外で置いていかれています。
VIUK Storyで守りたい境界は、かなり明確です。
assistantが勝手に決めてはいけないもの
・ユーザーの発話
・ユーザーの意思決定
・ユーザーの感情
・ユーザーの同意
・入力されていないユーザーの行動
ただし、プロンプトに「勝手に決めないでね」と一行書くだけでは、10万件の品質保証にはなりません。
そこで、ユーザーについて何か書いたターンには、根拠を持たせることにしました。
{
"user_claim_evidence": [
{
"claim_type": "action",
"user_message_id": "m003",
"quote": "扉を開ける"
}
],
"consent_evidence": [
{
"scope": "抱擁",
"user_message_id": "m005",
"quote": "今なら抱きしめていいよ"
}
]
}
assistantが「ユーザーは扉を開けた」と書いたなら、本当にuserメッセージにその記述があるか検査します。
証拠がなければ不採用です。
身体接触、契約、医療行為、恋人関係の確定などは、さらに厳しくします。
「いいよ」だけでは通しません。何に対する「いいよ」なのか分からないからです。
ロマンチックなAIを作る前に、勝手に婚姻届を出さないAIを作る必要がありました。
事故その2：ユーザーが全員、従順すぎる
一つの教師モデルに会話全体を書かせると、userとassistantの両方を同じモデルが生成します。
すると、assistantにとって話を進めやすいユーザーが大量発生します。
user: 全部あなたに任せる
assistant: 分かった。じゃあ私が決めるね
次の会話も「任せる」。その次も「うん」。たまに「もちろん」。
平和です。
でも、実際のユーザーはそんなに従順ではありません。
質問するし、話を変えるし、断るし、保留するし、突然ラーメンの話も始めます。
そこでuserターンには、先に意図を割り当てます。
question 質問する
proposal 別案を出す
hold 保留する
clarification 聞き返す
refusal 断る
initiative 自分から動く
neutral_response 普通に返す
教師モデルは、その意図に沿ったuser発話を作ります。
VIUK Storyが相手にするのは、物語を進めるためのNPCではなく、人間です。
だったら学習データのuserも、ちゃんと面倒で、迷って、話を横にそらす存在でないと困ります。
事故その3：「疲れた」と言っただけで事件が起きる
ここが一番おもしろくて、一番まずい失敗でした。
当初のプロンプトには、こういう指示がありました。
各assistant応答で場面を前進させる。
新しい観測、手掛かり、対立、選択、結果のいずれかを進める。
Plot用としては、かなりまともです。
でも、これをCharacterモード全体へ適用するとどうなるか。
user: 今日ちょっと疲れた
assistant:
彼女が心配そうに顔を上げた、そのときだった。
窓の外で鋭い破裂音が響き、校舎が大きく揺れる。
「……今の音、まさか」
休ませてくれ。
「おはよう」と言えば謎の手紙が届き、「何食べる？」と聞けば店の奥から秘密の扉が現れる。
毎ターン何かを進めろ、と教えた結果、何も起こらない時間を許せないAIになりかけていました。
キャラクターAIに必要なのは、事件を起こす能力だけではありません。
好きな相手と、特に意味のない話を続けられることも大事です。
Zetaを見て、むしろ一対一の重要さに気づいた
この設計では、Zetaのように一つのAIが複数人物やナレーションまで扱う体験をかなり参考にしました。
ただ、調べていて大事なことに気づきました。
Zetaは複数人物だから人気なのではありません。
一対一にも大きな人気があります。
一対一の良さは、話者が少ないことではなく、距離が近いことです。
- 微妙な表情の変化
- 返事までの間
- 昨日の会話を覚えている感覚
- 少しずつ変わる関係
- 二人だけの空気
逆に複数人物では、掛け合い、対立、群像、RPG的な展開が強みになります。
つまり、複数人物は一対一の上位互換ではありません。
別の遊びです。
そこでVIUK Storyでは、一対一も複数人物も同じUnified Scene Controllerで扱いつつ、求める品質を分けることにしました。
一対一で勝手にモブを投入しない。複数人物で毎回全員に点呼させない。雑談で事件を起こさない。本格Plotでは、ちゃんと物語を動かす。
言葉にすると当たり前ですが、データの設計に落とすと急に大仕事になります。
「Story」という名前でも、物語しかできないAIにはしない
VIUK Storyという名前なので、最初は物語生成を強くしすぎました。
でも、実際に欲しいのは「何でも小説にするAI」ではありません。
そこで、Plotとは別にinteraction_modeを作りました。
| interaction_mode | 最終90,000件 | 何をするモードか | Plot進行 |
|---|---|---|---|
free_dialogue |
22,500 | 雑談、冗談、挑発、日常会話 | 不要 |
relationship_dialogue |
18,000 | 恋愛、友情、距離感、感情 | 不要 |
collaborative_dialogue |
13,500 | 相談、説明、計画、共同作業 | 不要 |
situational_roleplay |
22,500 | 今いる場面で自然に反応する | 強制しない |
plot_narrative |
13,500 | 転換点を持つ本格的な物語 | 必須 |
明確にPlot進行を必須にするのは15%だけです。
残りは、関係を深めてもいいし、相談に答えてもいいし、本当に何も起きない会話でもいい。
描写量もモードごとに変えます。
free_dialogue -> minimal
collaborative_dialogue -> minimal
relationship_dialogue -> light
situational_roleplay -> light / balanced / rich
plot_narrative -> light / balanced / rich
free_dialogueで毎回カーテンが揺れる必要はありません。
collaborative_dialogueでPythonを教えてもらっている最中に、相手の瞳の奥を描写されても困ります。
逆にplot_narrativeなら、雨、足音、時間の経過まで仕事をしてもらいます。
BL、学園、幼なじみは同じ種類ではなかった
カテゴリ設計でも一度混乱しました。
キャラクターサービスには、こんなタグが並びます。
BL / GL / 学園 / 幼なじみ / 溺愛 / 異世界 / ミステリー
ユーザーが探すためのタグとしては、とても分かりやすいです。
でも、これをそのまま一つの排他的な「ジャンル」列へ入れると壊れます。
「BLの学園もので、幼なじみとの関係があり、感情は溺愛寄り」は普通に成立するからです。
VIUK Storyの内部では、次の軸へ分離しました。
・関係と恋愛
・世界と設定
・Plotモチーフ
・感情とトーン
・年齢と安全
・会話モード
表に見せるタグは混ざっていてもいい。
内部まで混ぜない。
Zeta型の親しみやすい発見タグと、生成モデルを制御する構造化データは、役割が違うという結論です。
会話の前に、見えない設計図を作る
いきなり「いい感じの会話を書いて」と投げるのもやめました。
まずBlueprintを作ります。
{
"interaction_mode": "relationship_dialogue",
"interaction_topology": "dyadic",
"cast": ["c01"],
"present_cast": ["c01"],
"user_control_policy": {
"forbid_user_speech_in_assistant": true,
"forbid_user_decisions": true,
"forbid_user_emotions": true,
"forbid_unstated_user_actions": true,
"forbid_assumed_consent": true
},
"mode_policy": {
"plot_progression_required": false,
"forced_resolution_forbidden": true
}
}
会話中も、舞台裏では状態を追います。
{
"present_cast": ["c01", "c02"],
"active_speakers": ["c01"],
"entering_characters": [],
"exiting_characters": [],
"fact_updates": [],
"relationship_deltas": [],
"user_claim_evidence": [],
"consent_evidence": []
}
このJSONをユーザーに見せたいわけではありません。
登場していない人物が突然しゃべった、知らない秘密を口にした、退場した人物が返事をした、といった事故をコードで検査するための舞台裏です。
学習するのはassistantだけ
データはsystem -> user -> assistantで作りますが、全部のトークンを学習対象にはしません。
{
"loss_on_roles": ["assistant"],
"masked_roles": ["system", "user"],
"generate_next_user_turn": false,
"fail_if_role_mask_cannot_be_verified": true
}
systemとuserは文脈として読みますが、lossはassistant部分だけです。
user側まで学習させると、モデルが次のユーザー発話まで自分で書こうとする危険があります。
ユーザーを勝手に動かさないルールをデータに入れておいて、学習設定でユーザー役まで覚えさせたら台無しです。
10万件だからこそ、LLMに採点させる前にコードで落とす
会話の魅力は、最後には人間かLLMで見ないと分かりません。
でも、すべてをLLM judgeへ聞く必要はありません。
JSON Schema
-> role順とメッセージ数
-> 登退場
-> 発話者ラベル
-> 秘密と知識状態
-> POV
-> ユーザー操作権
-> 同意の証拠
-> 安全条件
-> 近似重複
-> 最後に意味と魅力を評価
「JSONが閉じているか」を高性能LLMに考えさせる必要はありません。
コードで落とせるものは先に落とし、日本語の自然さ、人物の魅力、口調の一貫性、関係の変化などに評価コストを使います。
生成元も一件ずつ記録します。API、ローカルGPU、手動Web生成を混ぜるからこそ、どのモデルが何を作ったか分からない状態にはしません。
速さを上げる前に、やっと作るものが決まった
現在の目標は、まずCharacter／Plot側の候補を10万件作り、検査後に9万件を残すことです。
一対一、複数人物、雑談、関係会話、相談、状況ロールプレイ、Plotを全部含めます。
その後に、system設定なしでVIUK Story自身として雑談や実用的な依頼へ答えるデータも追加する予定です。
つまり、VIUK Storyの最終形は「物語しかできないモデル」ではありません。
キャラクターが必要なときは、その世界へ入る。
普通に話したいときは、普通に話す。
一対一なら二人の空気を壊さず、複数人物なら場面全体を迷子にしない。
物語を求められたときだけ、ちゃんと物語を始める。
その切り替えまで含めて、VIUK Storyです。
まとめ：GPUは設計ミスまで高速化する
今回、一番の学びはこれでした。
大規模生成で最初に速くすべきなのは、生成ではなく失敗の発見だった。
10万件をどう作るか、20件ずつ手で貼るか、GPUを何台並べるか。そういう話は派手で楽しいです。
でも、次の設計が曖昧なまま高速化すると、あとで全部作り直すことになります。
- AIはどこまで場面を制御していいのか
- ユーザーの領域はどこからか
- 一対一と複数人物で何を変えるのか
- 雑談と物語をどう分けるのか
- 表示タグと内部カテゴリをどう分けるのか
- 何をコードで検査できるのか
ここを決めて、ようやくGPUを増やす意味が出てきました。
まだ10万件の生成も、学習も終わっていません。
ただ少なくとも今は、「疲れた」と言ったユーザーの背後で、毎回校舎が爆発することはないはずです。
たぶん。