hakorune/docs/private/research/paper-09-ai-collaboration-pitfall/vm-mir-interpretation-miscommunication.md

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. 明確な設計文書の重要性

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

2. 新しい概念の説明方法

• 既存の概念との違いを明確に
• 具体例を用いた説明
• 図解の活用

3. 定期的な認識合わせ

• 実装前のレビュー
• 設計意図の再確認
• AIパートナーからのフィードバック

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

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

// 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実装に立ち返る

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

AI協調開発の真の教訓

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