# ABI移行タイミング詳細検討

## 🎯 現状分析

### 現在のTypeBox実装
- **TLVベース統一** - `invoke_id`ですべてのメソッド呼び出し処理
- **7つのプラグイン** - String/Integer/Array/Map/Console/File/Egui
- **問題なく動作** - 機能的には十分、パフォーマンスも実用レベル

### LLVM層の進捗
- ChatGPT5がLLVM実装改善中
- PHI/ターミネーター問題を解決中
- BuilderCursor導入で構造化
- EXE生成までもう少し

## 🔄 移行オプション検討

### Option 1: 今すぐ移行開始
**メリット**：
- プラグイン数が少ない（7個）今がチャンス
- 早期のパフォーマンス改善
- 技術的負債を早めに解消
- Phase 16に向けた準備

**デメリット**：
- LLVM作業と並行→リソース分散
- 優先度の問題（LLVM > ABI？）
- 現行で問題ないのに変更リスク

### Option 2: LLVM完成後に移行（推奨）✅
**メリット**：
- **集中できる** - まずLLVM完成に全力
- **最適化考慮** - LLVM/JITの特性を踏まえた設計
- **一度の変更** - まとめて最適な形に
- **実証データ** - LLVM性能を見てから判断

**デメリット**：
- 移行が遅れる（でも急ぐ必要ない）
- TLVオーバーヘッド継続（でも実用上問題なし）

### Option 3: 段階的準備
**今できること**：
1. struct_size活用コードの準備
2. ドキュメント整理（完了✅）
3. 拡張計画の詳細化
4. テストコード準備

**LLVM後にやること**：
1. create/destroy追加
2. プラグイン順次対応
3. パフォーマンス測定
4. 最適化

## 📊 判断基準

### なぜLLVM完成後が最適か

1. **優先度の明確化**
   - 現在の最重要課題：セルフホスティング
   - LLVM完成 → EXE生成 → セルフホスト実現
   - ABIは「改善」であって「必須」ではない

2. **設計の最適化**
   - LLVMの最適化特性を理解してから
   - インライン化可能性の考慮
   - JIT/AOTでの扱いの違い

3. **リスク管理**
   - 動いているものを変えるリスク
   - LLVM作業への影響を避ける
   - 一度に大きく変える方が安全

4. **実装効率**
   - ChatGPT5がLLVM集中できる
   - 混乱を避ける
   - 明確なマイルストーン

## 🚀 推奨ロードマップ

### Phase 15（現在）
1. **LLVM完成に集中**
2. EXE生成実現
3. セルフホスト基盤確立
4. ABI拡張の詳細設計（並行）

### Phase 15.5（LLVM完成直後）
1. **ABI拡張実装**
   - create/destroy追加
   - struct_size活用
   - 互換性維持
2. **プラグイン移行**
   - 性能重要なものから
   - 段階的に対応
3. **パフォーマンス検証**

### Phase 16（次フェーズ）
1. **ABI安定化宣言**
2. 外部開発者向けドキュメント
3. 他言語バインディング

## 🎯 結論

**LLVM完成後の移行が最適**

理由：
1. 現在のTLVベースで機能的問題なし
2. LLVM完成が最優先（セルフホストへの道）
3. 最適化知見を活かした設計可能
4. リスク最小化・効率最大化

**ただし準備は今から**：
- ドキュメント整理（完了✅）
- 設計詳細化
- テスト準備
- 移行計画策定

これにより、LLVM完成後にスムーズに移行開始できる。