hakorune/docs/research/ai-dual-mode-development/hidden-crisis-moments.md

# 隠れた危機一髪 - 26日間で本当に危なかった瞬間

## 概要

表面的には順調に見えた26日間の開発。しかし実際には、何度も致命的な破綻の淵に立っていた。これらの危機を回避できたのは、「箱理論への執着」と「人間の違和感センサー」のおかげである。

## 危機1: プラグインボックスの罠

### 状況
ChatGPT5（実装AI）が提案した設計：
```rust
// 危険な設計案
static PLUGIN_INSTANCES: Mutex<HashMap<String, Arc<PluginBox>>> = ...;

// インスタンスを参照で共有
fn get_plugin(name: &str) -> Arc<PluginBox> {
    PLUGIN_INSTANCES.lock().get(name).clone()
}
```

### 何が危険だったか
- **箱理論の根本違反**：他の箱は`birth`で生まれるのに、プラグインだけ特別扱い
- **状態管理の複雑化**：グローバルな共有状態が生まれる
- **デバッグ困難**：問題が起きても原因特定が困難

### にゃーの介入
```
にゃー：「他の箱と同じようにbirthでインスタンスをうむ」
```

### 解決策
```nyash
// 正しい設計
box FileBox from PluginBox {
    birth(path) {
        // 外部ライブラリの初期化は1回だけ（static変数で管理）
        PluginSystem.initOnce()
        
        // でもインスタンスは普通に生成
        me.handle = createNewHandle()
    }
}
```

### 学んだ教訓
- **AIも箱理論を見失うことがある**
- **効率性の誘惑**に負けてはいけない
- **統一性＞効率性**

## 危機2: P2Pライブラリの静かな破壊

### 状況
- C++ nyameshライブラリ：コンテキスト圧縮で内部状態が破損
- JavaScript nyamesh：同様に破損
- **表面上は動作継続**（最悪のパターン）

### 何が危険だったか
```cpp
// C++ nyameshの内部
class P2PContext {
    std::vector<NodeInfo> nodes;  // これが破損
    MessageQueue queue;           // でもここは動く
};
```

- データ構造の一部だけ破損
- エラーが出ない（NULLチェックは通る）
- 徐々に通信が劣化

### 発見の瞬間
```
にゃー：「なんか通信の挙動がおかしいにゃ...」
```

### 対処
1. 完全な再初期化を実装
2. 状態検証のチェックポイント追加
3. 「箱」として隔離（P2PBox内に封じ込め）

## 危機3: 型システムの静かな崩壊

### 状況
- FloatがI64として扱われる
- でも「動いている」ように見える
- 計算結果が微妙にずれる

### 危険性
```nyash
// 見た目は正常
local x = 3.14
local y = 2.0
local z = x + y  // 5になるはずが...

// 内部では
// 3.14 → 3 (I64)
// 2.0 → 2 (I64)
// z = 5 (正しく見える！)
```

### 発見
テストで`sin(1.5707963267948966)`が`0`を返したとき

## 危機4: Arc<Mutex>の感染爆発

### 状況
- 最初は「安全のため」StringBoxにMutex
- 次第にすべてのBoxに感染
- パーサーが個別処理地獄に

### 臨界点
```rust
// 16種類すべてがこの形に...
struct StringBox {
    base: Arc<Mutex<BoxBase>>,
    value: Arc<Mutex<String>>,  // たった1つの文字列に！
}
```

### にゃーの決断
```
にゃー：「これはやばいにゃ。NyashValueに統一するにゃ」
```

## 共通パターン：静かな破壊

最も危険なのは**「表面上動いている」**状態：

1. **部分的破損**
   - 一部は正常動作
   - 徐々に劣化
   - 原因特定が困難

2. **型の暗黙変換**
   - エラーが出ない
   - 結果が「それっぽい」
   - 後で大問題に

3. **複雑性の感染**
   - 「安全のため」から始まる
   - 徐々に全体に広がる
   - 気づいたときには手遅れ

## 危機回避の共通要因

### 1. 箱理論への執着
```
「これも箱にすれば...」
「箱の規約を守れば...」
「問題を箱に封じ込めれば...」
```

### 2. 違和感の言語化
```
「なんか変だにゃ」
「これ続けたらやばいにゃ」
「表面は動いてるけど...」
```

### 3. シンプルさへの回帰
```
複雑化 → 「待って」 → 箱に戻す
```

## 結論：見えない危機との戦い

26日間の開発は、実は**薄氷の上を歩く**ような危険な旅だった。

成功の鍵：
- **箱理論という北極星**：迷ったら必ず戻る場所
- **人間の第六感**：データでは見えない異常を察知
- **AIとの対話**：AIの暴走を人間が制御

これらの「隠れた危機」の記録は、将来の開発者への貴重な警告となる。

**「動いているように見える」が最も危険**

この教訓を忘れてはならない。