そもそもの発端：これは「一つのプロジェクト」ではなく、生きたいと願うキャラクターだ

まずなぜこの二度のリファクタリングが起きたのかをはっきりさせておく——そうしないと、以下の失敗リストが、理由もない無駄な回り道に見えてしまう。

すべては一つの思いから始まった：人と話せて、人のことを覚えている AI（Neuro Sama のようなもの）を作る。 カスタマーサポート式の Q&A マシンでも、オウム返しマシンでもなく、人格があり、記憶があり、感情があって、私と言い合ったり雑談したりでき、配信が終わっても視聴者との雑談に付き合ってくれる存在だ。参考にしたのは世界中の AIVtuber たち——だが宿題を丸写しするのではなく、自分で一匹育てたかった。

そこで三度の命名が生まれた。同じ執念から：

• dango-live（最初の白紙）：単一配信者向けアプリで、まず「会話できる AI キャラクター」を作る——キャラ設定、レッドライン、音色、記憶はコードにハードコード。シンプルだが、少し動かすだけでコードを書き換えることになる。
• miststar-live（初めて本気でフレームワークを組んだ、2026-08）：「プラットフォームplatform」へと昇格。キャラクターをシステム化し、一つの AI が一群のキャラクターになり、キャラを変えればキャラ設定、音色、専用記憶も変わる。視聴者プロファイル、世界観のネタライブラリはプラットフォームレベルで共有。これが初めて本気で組んだフレームワークだ。
• shiogiri-paw / shiogiri-live（二度目に本気でフレームワークを組んだ、2026-09）：「日常を過ごす」ことと「舞台で演じる」ことを二つのシステムに分けた——魂側がチャット、記憶、お邪魔（Discord で雑談するようなもの）を担い、体側が配信、コメント、歌（舞台で演じるようなもの）を担う。配信開始前にキャラ設定を注入し、配信中にイベントを報告し、配信終了後に記憶を蓄積する。これが二度目に本気で組んだフレームワークだ。

方向は最初から最後まで変わらなかった：人格の継続、記憶の蓄積、長期的な視聴者との関係——人のようにあなたを覚えていること。 この執念そのものは間違っていない。間違っていたのは、フレームワークを二度組んで、二度とも同じ種類の問題で倒れたことだ。では本題に入る。

これを書く前に、一つ認めておきたい：二度のリファクタリングの失敗記録を読み終えて、ほとんどの問題は最終的に同じ一つの道理に収束すると気づいた——私たちはずっと「この箇所」を補修してきたが、「なぜ毎回この類のところで折れるのか」を問うことはほとんどなかった。

背景

• 1回目：miststar-live（2026-08）、35 モジュール / 92 件のテスト / git なし；
• 2回目：shiogiri-paw / shiogiri-live（2026-09）、54 モジュール / 16,283 行 / 657 件のテストが全てグリーン / 15 枚のカード審査パッケージ / ハッシュ自己検証。

2回目のほうがずっと規律正しく見えるだろう？だが結果は：どちらも本物の配信は一度もなかった。2回目で最長の「配信」は 100 秒、実際のコメントは 9 件、記憶 / ネタ / まとめはすべて 0 行。

最も覚えておくべき三つの結論

1. 本当に繰り返されたのは「間違い」ではなく、「設定のレイヤリングに唯一の権威あるルールがないこと」だ。 1回目：実行時の値、本物の資格情報、実際のルーム番号がテンプレートの config.json に書き込まれた（間違った側に置いた）。 2回目：provider のエンドポイントがテンプレートから消され → 公式エンドポイントにフォールバック → 401、AI は全く返答しなかった（置く側がなかった）。 同じ根本原因、二つの逆方向、二度とも転んだ。しかも2回目は半分しか直していない（ローカルパスは移したが、エンドポイントは移していない）——半分だけ直したレイヤリングルールは、直していないのと同じだ。

2. どちらも「テスト全グリーン + 審査パッケージ完備」を完成定義にした結果、どちらも「配信できて体感も基準を満たす」状態にはならなかった。 1回目は 92 件、2回目は 657 件。どちらも本物の配信はなかった。テストがグリーン ≠ 配信できる。

3. 同じ構造的疾患（シングルスレッド + 長時間タスク）は、二度ともアーキテクチャarchitecture層で解決されなかった。 1回目：AI の歌がシングルスレッド上で同期的に走る → 曲リクエストがすべて止まる。 2回目：worker シングルスレッド + インライン sleep → コメント取り込みがブロック、能動エンジンが飢餓状態；音色のコールドスタート十数秒が毎回の発話に溶接されていた。 1回目は「スケジューリングの問題」、2回目は「アーキテクチャ的問題」で、本質は同じ一本だ。モジュールだけ替えて並行モデルを替えなければ、三度目も転ぶ。

二度をまたぐ 8 つの反復パターン

1. 設定のレイヤリングに唯一の権威あるルールがない —— ⭐ 最も覚えておくべき
2. 完成定義のずれ：テストがグリーン ≠ 配信できる（どちらも「振る舞いの判定基準」が欠けていた）
3. シングルスレッド + 長時間タスク（「待つ」ことをクリティカルパスcritical pathに置く）
4. 「チェーンの一節が切れているのに、それを発見できるテストが一つもない」——例えば発話が間違ったモデル種別に結びつき、サイレント降格がそのまま通り、キャラの声質が一度も有効にならなかった
5. ドキュメントに書かれているのは実測ではなく意図（1回目の計測数 70 対 実際 92；2回目 181 対 657）
6. 検証環境と納品環境が分かれていない（一時パス、デバッグスイッチが納品物に混入）
7. 設定の永続化 / 複数ステップの書き込みがアトミックでない（呼び出し側の自覚に頼り、呼び忘れれば失われる）
8. 「デフォルトオフ」の規律がロールバックを守り、同時に能力も凍結した（10 の能力がデフォルトオフ、すべてカード化され、すべてテストがあり、全行程で一度も走らなかった）

なぜ繰り返されるのか？

層面の三つの説明：

1. 制度は「コードを変える」ことは覆ったが、「納品後の運用」は覆わなかった——「しばらく走らせる」という受け入れ検証がなかった；
2. あらゆる失敗点が「この箇所の問題」として直された——「長時間タスクがクリティカルスレッドを占有してはならない」といった原則を抽象化した人は誰もいなかった；
3. 知識の痕跡を残す媒体が脆すぎた——1回目の意思決定は一つのメモファイルの中に生き、2回目の結論は十五枚のカードに散らばっていた。三度目に残すべきは「記録」ではなく「ルール」だ。

三度目はどう防ぐ？

各カードの着工前に再発防止チェックリストを一度書き写す：設定の帰属 / 納品面 /エンドツーエンドend-to-endのユースケース / 降格の可観測性 / 長時間タスクの位置 / 原子性 / 振る舞いの判定基準 / スイッチと実測 / 数値アサーション（9 項目）；完工後は 8 項目で受け入れ検証する（golden 突き合わせ、ロールバック実測を含む）。

第三の道は、もはやパッチ式に穴を埋めるのではなく、まずルールを立ててから手を入れる。