4e1b595796
【AI協調開発研究】 - AI二重化モデルの学術論文draft完成（workshop_paper_draft.md） - 「隠れた危機」分析とbirthの原則哲学化 - TyEnv「唯一の真実」協調会話を保存・研究資料に統合 - papers管理構造の整備（wip/under-review/published分離） 【Phase 10.9-β HostCall進捗】 - JitConfigBox: relax_numeric フラグ追加（i64→f64コアーション制御） - HostcallRegistryBox: 署名検証・白黒リスト・コアーション対応 - JitHostcallRegistryBox: Nyash側レジストリ操作API - Lower統合: env直読 → jit::config::current() 参照に統一 - 数値緩和設定: NYASH_JIT_HOSTCALL_RELAX_NUMERIC/Config.set_flag 【検証サンプル拡充】 - math.sin/cos/abs/min/max 関数スタイル（examples/jit_math_function_style_*.nyash） - 境界ケース: 署名不一致・コアーション許可・mutating拒否サンプル - E2E実証: String.length→allow, Array.push→fallback, math関数の署名一致観測 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
135 lines
3.6 KiB
Markdown
135 lines
3.6 KiB
Markdown
# 危険センサーのケーススタディ - 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時代の新しい開発手法として、広く応用可能な知見を含んでいる。 |