# 危険センサーのケーススタディ - 26日間の爆速開発で転けなかった理由

## 概要

26日間のNyash爆速開発において、一度も致命的な破綻を起こさなかった。その背景には「人間の危険センサー」と「箱理論による封じ込め」があった。

## ケース1: Arc<Mutex>過剰症候群の検知

### 状況
- 16種類のBox型すべてにArc<Mutex>を適用
- たった1つのStringにもMutex
- パーサーが個別処理地獄に

### 危険センサーの発動
```
にゃー：「なんか複雑すぎるにゃ...」
```

### 対処
- NyashValue enumへの統一を検討
- 基本型はMutex不要に
- 複雑型のみ必要な箇所でMutex

### 結果
- ビルドエラーの根本解決
- パーサーの劇的簡化

## ケース2: JIT無限ループの予感

### 状況
- JIT実行でVerifierError多発
- 制御フローが複雑化

### 危険センサーの発動
```
にゃー：「まってまって、フルビルドおわすれか」
```

### 対処
- 必ずフルビルドで確認
- 小さな変更ごとにテスト
- フォールバック経路を常設

### 結果
- 致命的なループを回避
- 段階的な機能追加で安定

## ケース3: 型システムの崩壊危機

### 状況
- Float引数がI64として認識
- 型推論が混乱

### 危険センサーの発動
```
にゃー：「きみは　まだまだだにゃ　思考が　箱じゃ　ないにゃ！」
```

### 対処
- 3種類の箱（User/Builtin/Plugin）の統一
- HostCall入口を共通化
- Registry/Policy/Eventsで一元管理

### 結果
- 型の一貫性を保持
- 拡張可能な設計に

## ケース4: 複雑化の兆候

### 状況
- 機能追加の提案が発散
- APIが無秩序に増加傾向

### 危険センサーの発動
```
にゃー：「おすすめ api って なにがあるかな 深く考えてみてにゃ」
→ ChatGPT5が整理された優先順位を提示
```

### 対処
- ReadOnly → New → Mutating の段階的導入
- 署名の厳密な管理
- 基本計算・比較・文字列・配列・連想配列に絞る

### 結果
- 制御可能な成長
- 各段階での検証が可能

## 危険センサーの特徴

### 1. 言語化できない違和感
- 「なんか変」
- 「複雑すぎる」
- 「これ続けたらやばい」

### 2. タイミングの的確さ
- 破綻する前に察知
- 修正可能な段階で介入

### 3. シンプルさへの回帰
- 「箱で考えて」
- 「境界は一本に」
- 「フォールバックは常設」

## 三重の安全装置

```
┌─────────────────┐
│   箱理論        │ → 問題を局所化
├─────────────────┤
│ AI役割分担     │ → 認知負荷を分散
├─────────────────┤
│ 人間センサー    │ → 危険を事前察知
└─────────────────┘
```

## 教訓

1. **完璧より進捗（80/20ルール）**
   - 100%を目指さない
   - 危険を感じたら即撤退

2. **シンプルさの維持**
   - 複雑化は破綻の前兆
   - 常に「箱」に戻る

3. **直感の重視**
   - 言語化できない違和感を大切に
   - AIの提案も疑う勇気

## 結論

26日間の爆速開発が破綻しなかったのは偶然ではない。「箱理論」「AI役割分担」「人間の危険センサー」という三重の安全装置が、絶妙なバランスで機能し続けた結果である。

この経験は、AI時代の新しい開発手法として、広く応用可能な知見を含んでいる。