hakorune/docs/private/research/ai-dual-mode-development/danger-sensor-case-studies.md

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

概要

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

ケース1: Arc過剰症候群の検知

状況

• 16種類のBox型すべてにArcを適用
• たった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時代の新しい開発手法として、広く応用可能な知見を含んでいる。