# VMのMIR解釈層としての役割が伝わらなかった事例（2025-09-01追記）

## 背景

NyashのVM実装は、元々「MIR解釈の参照実装」として設計されていた。しかし、この意図がAI開発パートナーに正しく伝わらず、結果として同じMIR解釈ロジックが複数回実装される事態となった。

## 何が起きたか

### 開発者の意図
```
VM = MIR解釈層（統一された意味論の実装）
  ↓
JIT/AOT/LLVMはVMの解釈ロジックを参照して実装
```

### 実際の実装
```
VM → 独自のMIR解釈実装
JIT → 独自のMIR解釈実装（微妙に異なる）
LLVM → また独自のMIR解釈実装
```

## なぜ伝わらなかったか

### 1. 用語の誤解
- 「VM」という名前から「実行専用」と誤解された
- 「MIR解釈層」という抽象的な概念として伝えるべきだった

### 2. 固定観念
- AIパートナーが「各バックエンドは独立実装」という一般的なパターンを前提とした
- VMが参照実装になるという発想が新しすぎた

### 3. コンテキストの不足
- プロジェクト初期の設計意図が文書化されていなかった
- 口頭での説明に依存しすぎた

## 結果として生じた問題

### 1. 重複実装
- 同じロジックを3-4回実装
- 各実装で微妙に動作が異なる

### 2. デバッグの困難
- どの実装が「正しい」のか不明
- バグ修正を全実装に反映する必要

### 3. フォールバック機能の追加
- 実装の違いを吸収するためにフォールバック機能を追加
- さらなる複雑性の増大

## 学んだ教訓

### 1. 明確な設計文書の重要性
```markdown
# VM設計方針
VMはMIR命令の意味論を定義する参照実装である。
他のバックエンド（JIT/AOT/LLVM）は、VMの実装を
仕様書として参照し、同じ動作を保証する。
```

### 2. 新しい概念の説明方法
- 既存の概念との違いを明確に
- 具体例を用いた説明
- 図解の活用

### 3. 定期的な認識合わせ
- 実装前のレビュー
- 設計意図の再確認
- AIパートナーからのフィードバック

## 改善策：Semanticsトレイトの導入

最終的に、ChatGPT5との議論を経て、Semanticsトレイトという形で設計意図を明確化：

```rust
// MIR解釈の統一インターフェース
trait Semantics {
    type Val;
    fn interpret_instruction(&mut self, inst: &MirInstruction) -> Self::Val;
}
```

これにより、各バックエンドが同じ意味論に従うことが保証される。

## 後日談：LLVMからCraneliftへの戦略的転換（2025-09-01）

### 転換の経緯
1. **LLVM統合の試み** → 巨大、ビルド困難、環境依存地獄
2. **問題認識** → 「ユーザーにこの苦労をさせられない」
3. **既存資産の再評価** → Phase 10.7のCranelift実装に立ち返る

```bash
# LLVM: 100MB+、環境構築1日、ビルド数時間
# Cranelift: 5-10MB、cargo add一発、ビルド数分
# → 明らかにCraneliftが実用的！
```

### AI協調開発の真の教訓
- 新しいものに飛びつく前に既存資産を評価
- 「大きい・複雑」なものに遭遇したら立ち止まる
- 方向転換は敗北ではなく賢明な判断