まずなぜこの二度のリファクタリングが起きたのかをはっきりさせておく——そうしないと、以下の失敗リストが、理由もない無駄な回り道に見えてしまう。
すべては一つの思いから始まった：人と話せて、人のことを覚えている AI（Neuro Sama のようなもの）を作る。 カスタマーサポート式の Q&A マシンでも、オウム返しマシンでもなく、人格があり、記憶があり、感情があって、私と言い合ったり雑談したりでき、配信が終わっても視聴者との雑談に付き合ってくれる存在だ。参考にしたのは世界中の AIVtuber たち——だが宿題を丸写しするのではなく、自分で一匹育てたかった。
そこで三度の命名が生まれた。同じ執念から：
方向は最初から最後まで変わらなかった：人格の継続、記憶の蓄積、長期的な視聴者との関係——人のようにあなたを覚えていること。 この執念そのものは間違っていない。間違っていたのは、フレームワークを二度組んで、二度とも同じ種類の問題で倒れたことだ。では本題に入る。
これを書く前に、一つ認めておきたい：二度のリファクタリングの失敗記録を読み終えて、ほとんどの問題は最終的に同じ一つの道理に収束すると気づいた——私たちはずっと「この箇所」を補修してきたが、「なぜ毎回この類のところで折れるのか」を問うことはほとんどなかった。
2回目のほうがずっと規律正しく見えるだろう？だが結果は：どちらも本物の配信は一度もなかった。2回目で最長の「配信」は 100 秒、実際のコメントは 9 件、記憶 / ネタ / まとめはすべて 0 行。
1. 本当に繰り返されたのは「間違い」ではなく、「設定のレイヤリングに唯一の権威あるルールがないこと」だ。 1回目：実行時の値、本物の資格情報、実際のルーム番号がテンプレートの config.json に書き込まれた（間違った側に置いた）。 2回目：provider のエンドポイントがテンプレートから消され → 公式エンドポイントにフォールバック → 401、AI は全く返答しなかった（置く側がなかった）。 同じ根本原因、二つの逆方向、二度とも転んだ。しかも2回目は半分しか直していない（ローカルパスは移したが、エンドポイントは移していない）——半分だけ直したレイヤリングルールは、直していないのと同じだ。
2. どちらも「テスト全グリーン + 審査パッケージ完備」を完成定義にした結果、どちらも「配信できて体感も基準を満たす」状態にはならなかった。 1回目は 92 件、2回目は 657 件。どちらも本物の配信はなかった。テストがグリーン ≠ 配信できる。
3. 同じ構造的疾患（シングルスレッド + 長時間タスク）は、二度ともアーキテクチャ層で解決されなかった。 1回目：AI の歌がシングルスレッド上で同期的に走る → 曲リクエストがすべて止まる。 2回目：worker シングルスレッド + インライン sleep → コメント取り込みがブロック、能動エンジンが飢餓状態；音色のコールドスタート十数秒が毎回の発話に溶接されていた。 1回目は「スケジューリングの問題」、2回目は「アーキテクチャ的問題」で、本質は同じ一本だ。モジュールだけ替えて並行モデルを替えなければ、三度目も転ぶ。
層面の三つの説明：
各カードの着工前に再発防止チェックリストを一度書き写す：設定の帰属 / 納品面 /エンドツーエンドのユースケース / 降格の可観測性 / 長時間タスクの位置 / 原子性 / 振る舞いの判定基準 / スイッチと実測 / 数値アサーション（9 項目）；完工後は 8 項目で受け入れ検証する（golden 突き合わせ、ロールバック実測を含む）。
第三の道は、もはやパッチ式に穴を埋めるのではなく、まずルールを立ててから手を入れる。