fix(joinir): Phase 241-EX - Remove hardcoded 'sum' check from Pattern3

Remove legacy hardcoded 'sum' carrier validation that was blocking array_filter patterns with different accumulator names (e.g., 'out'). Before: Pattern3 required carrier named 'sum' to exist After: Pattern3 uses carrier_info generically (any carrier name works) Test results: - phase49_joinir_array_filter_smoke: PASS ✅ - phase49_joinir_array_filter_fallback: PASS ✅ - phase49_joinir_array_filter_ab_comparison: PASS ✅ - Full suite: 909/909 PASS, 0 FAIL Also: Archive old roadmap documentation (67k lines moved to docs/archive/) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 00:48:42 +09:00
parent a7dbc15878
commit 811dfebf98
387 changed files with 106 additions and 5551 deletions
--- a/docs/archive/roadmap/phases/phase-11/AWESOME_RUST_SUBMISSION.md
+++ b/docs/archive/roadmap/phases/phase-11/AWESOME_RUST_SUBMISSION.md
@ -0,0 +1,149 @@
+# Awesome Rust掲載準備
+
+Date: 2025-08-31
+Status: In Progress
+
+## 🎯 目的
+Nyashプロジェクトを[Awesome Rust](https://github.com/rust-unofficial/awesome-rust)リストに掲載し、Rustコミュニティへの認知度を向上させる。
+
+## 📋 掲載カテゴリー候補
+
+### 1. Development tools > Build system
+- Nyashの統合ビルドシステム（インタープリター/VM/WASM/AOT）
+
+### 2. Programming languages
+- **Nyash - Everything is Box プログラミング言語** ← 最有力候補
+- Rust製の新しいプログラミング言語実装として
+
+### 3. Virtual machines
+- NyashのVM実装（MIR15命令セット）
+
+## 📝 提出文案
+
+### オプション1（シンプル版）
+```markdown
+* [Nyash](https://github.com/[user]/nyash) — A Box-oriented programming language with VM/JIT/AOT backends. Everything is Box philosophy with 15-instruction MIR.
+```
+
+### オプション2（詳細版）
+```markdown
+* [Nyash](https://github.com/[user]/nyash) [[nyash](https://crates.io/crates/nyash)] — Everything is Box programming language featuring unified object model, multi-backend execution (Interpreter/VM/WASM/AOT), and revolutionary 15-instruction MIR design. Built for P2P mesh networking and distributed computing.
+```
+
+### オプション3（技術重視版）
+```markdown
+* [Nyash](https://github.com/[user]/nyash) — Modern programming language with Box-based unified type system, featuring high-performance VM with JIT compilation, WASM target, and upcoming LLVM backend. Designed for simplicity without sacrificing performance.
+```
+
+## ✅ 掲載前チェックリスト
+
+### 必須項目
+- [ ] GitHubリポジトリが公開されている
+- [ ] READMEが充実している（英語）
+- [ ] ライセンスが明記されている
+- [ ] ビルド手順が明確
+- [ ] 基本的な使用例がある
+
+### 推奨項目
+- [ ] CIが設定されている（GitHub Actions等）
+- [ ] ドキュメントが整備されている
+- [ ] サンプルプログラムがある
+- [ ] crates.ioに公開されている
+- [ ] バージョン1.0以上（または明確なロードマップ）
+
+## 🚀 提出手順
+
+1. **リポジトリ準備**
+   - README.mdを英語化/改善
+   - サンプルコードを追加
+   - CI/CDを設定
+
+2. **PR作成**
+   - Awesome Rustをfork
+   - 適切なセクションに追加
+   - アルファベット順を守る
+   - PRテンプレートに従う
+
+3. **フォローアップ**
+   - レビューコメントに対応
+   - 必要に応じて説明追加
+
+## 📊 現在の準備状況
+
+### ✅ 完了
+- 基本的な言語実装
+- VM実装（13.5倍高速化達成）
+- MIR設計（15命令に削減）
+- ドキュメント構造
+
+### 🚧 作業中
+- README.mdの英語化
+- サンプルプログラムの整理
+- CI/CDの設定
+
+### ❌ 未着手
+- crates.io公開
+- ロゴ/ブランディング
+- Webサイト
+
+## 🎨 プロジェクト説明の改善案
+
+### 現在のREADME冒頭
+```
+Nyashプログラミング言語 - Everything is Box
+```
+
+### 改善案（英語版）
+```markdown
+# Nyash Programming Language
+
+A modern programming language where Everything is Box - unified object model with high-performance execution.
+
+## Features
+- 🎁 **Everything is Box**: Unified object model for all values
+- ⚡ **Multi-backend**: Interpreter, VM (13.5x faster), WASM, AOT
+- 🚀 **15-instruction MIR**: Revolutionary minimal instruction set
+- 🔧 **Plugin System**: Extensible architecture
+- 🌐 **P2P Ready**: Built for distributed computing
+
+## Quick Start
+```nyash
+// Everything is a Box
+local greeting = new StringBox("Hello, Nyash!")
+print(greeting)
+
+// User-defined Boxes
+box Person {
+    init { name, age }
+    
+    birth(name) {
+        me.name = name
+        me.age = 0
+    }
+}
+
+local alice = new Person("Alice")
+```
+```
+
+## 📅 タイムライン
+
+### Phase 1（現在）
+- README改善
+- サンプル整理
+- 基本的なCI設定
+
+### Phase 2（LLVM実装後）
+- crates.io公開
+- 正式なv1.0リリース
+- Awesome Rust提出
+
+### Phase 3（採用後）
+- コミュニティフィードバック対応
+- ドキュメント拡充
+- エコシステム構築
+
+## 🔗 関連リンク
+- [Awesome Rust](https://github.com/rust-unofficial/awesome-rust)
+- [提出ガイドライン](https://github.com/rust-unofficial/awesome-rust/blob/main/CONTRIBUTING.md)
+- [他の言語実装例](https://github.com/rust-unofficial/awesome-rust#programming-languages)
--- a/docs/archive/roadmap/phases/phase-11/BOXCALL_UNIFICATION_PITFALLS_AND_SOLUTIONS.md
+++ b/docs/archive/roadmap/phases/phase-11/BOXCALL_UNIFICATION_PITFALLS_AND_SOLUTIONS.md
@ -0,0 +1,157 @@
+# BoxCall統一の落とし穴と対策（ChatGPT5分析）
+
+Date: 2025-08-31
+Status: Technical Advisory
+From: ChatGPT5
+
+**結論：「RefNew/RefGet/RefSet全削除→すべてBoxCallに統一」は成立する！**
+ただし、いくつかの落とし穴があるので、それぞれに対策を打つ必要がある。
+
+## 🚨 落とし穴と対策
+
+### 1. メガモーフィック呼び出しでの失速
+**症状**: 同じ`BoxCall("setField")`でも実行時の型/shapeが激しく変わると、ディスパッチが重くなる。
+
+**対策**: **PIC（Polymorphic Inline Cache）**をコールサイトごとに持つ
+- 2〜4種のshapeを直列ジャンプで捌く
+- 溢れたらインタプリタ/汎用スローへ
+- JITなしでもAOT段階で形状統計から事前特化（事前ガード＋直アクセス）を埋め込める
+
+### 2. GCバリアの見落とし・過剰挿入
+**症状**: write barrier忘れ＝世代間参照漏れ／逆に全部に入れて過剰オーバーヘッド
+
+**対策**: 
+- Lowering時に**フィールドの"ポインタ／非ポインタ"メタ**を参照して自動挿入
+- **世代同一・同アリーナ最適化**でbarrier省略
+- `ExternCall`には**境界バリア**を必ず付与
+- **Barrier Verifier**（IRパス）で「必要箇所に必ず入ってるか」を機械検証
+
+### 3. 読み取りバリア（Read Barrier）が必要なGCを選ぶ場合
+**症状**: 動くGC（移動/並行）でread barrierが必須だと、Get系もコスト上がる
+
+**対策**: 
+- まずは**世代別・停止＋並行マーク（SATB）**など「write側主体」の方式を選ぶ
+- **read barrierなし運用**で始めるのが無難
+- 将来read barrierが要る場合は、`getField` Loweringに条件付き埋め込み設計
+
+### 4. 例外・再入・ファイナライザ再入
+**症状**: `setField`中に例外→ファイナライザ→別の`BoxCall`で再入…地雷
+
+**対策**:
+- **安全点（safepoint）設計**を決める
+- `BoxCall`中は原則再入禁止（or 明示的許可フラグ）
+- `fini`相当のコールは**再入ガード**と**順序保証**（トポロジカルな破棄順）を実装
+
+### 5. ExternCall/FFI境界
+**症状**: 外部コードが「未トラッキングの生ポインタ」を握るとGC・最適化が壊れる
+
+**対策**:
+- **ハンドル化**（OpaqueHandle/PinBox）＋**寿命契約**
+- ExternCallの属性（`noalloc`/`nothrow`/`readonly`/`atomic`等）を宣言させ、最適化に渡す
+- 未注釈の呼び出しでは保守的にバリア＆逃避扱い
+
+### 6. 形状（shape）変更とレイアウト安定性
+**症状**: フィールド追加/順序変更が既存の特化コードを壊す
+
+**対策**:
+- **ShapeIDを永続化**
+- フィールドに**安定スロットID**を割り当て
+- ABI的に「追加のみ」「削除は新shape」とする
+- Lowering済みのガードは `if (shape==X) { direct store } else { slowpath }` で守る
+
+### 7. 脱箱（unboxing）とコードサイズ膨張
+**症状**: 激しいモノモルフィック特化や整数Boxの脱箱で**コード肥大**
+
+**対策**:
+- **基本型はSROA/Scalar-Replaceの閾値**を設定
+- ホット領域のみ特化（**PGO**やプロファイル使用）
+- 低頻度パスは共通スローに集約
+
+### 8. 並行性・メモリモデル
+**症状**: `setField`の可視性がスレッド間で曖昧だと事故
+
+**対策**:
+- **既定は単一スレッド＋Actor（Mailbox）**に寄せる
+- 共有可変を解禁するAPIは `nyash.atomic.*` で**Acquire/Release**を明示
+- `BoxCall` Loweringで**必要時のみフェンス**
+- 箱ごとに「可変・不変・スレッド送受可」など**能力（capability）ビット**を持たせ最適化条件に使う
+
+### 9. 反射・動的呼び出しの混入
+**症状**: なんでも動的だと最適化が崩れる
+
+**対策**:
+- 反射APIは**分離名前空間**に押し込める
+- 既定は静的解決できる書き方を推奨ガイドに
+- 反射使用時は**deoptガード**を挿入
+
+## 📈 推奨の最適化パイプライン（AOT想定）
+
+1. **型/shape解析**（局所→関数間）
+2. **BoxCall脱仮想化**（モノ/ポリモーフィック化＋PIC生成）
+3. **インライン化**（属性`pure`/`leaf`/`readonly`を最大活用）
+4. **SROA/エスケープ解析**（脱箱、stack allocation、alloc移動）
+5. **バリア縮約**（世代同一・同アリーナ・ループ内集約）
+6. **境界チェック消去**（`length`不変式の伝播）
+7. **ループ最適化**（LICM, unroll, vectorize）
+8. **DCE/GVN**（Getter/Setter副作用ゼロなら畳み込み）
+9. **コードレイアウト**（ホット先頭、コールド折り畳み）
+10. **PGO（任意）**でPIC順序・インライン閾値を再調整
+
+## 🔧 Loweringの骨格（フィールド書き込みの例）
+
+```llvm
+; High-level
+obj.setField(x)
+
+; Guarded fast-path（shapeが既知＆最頻）
+if (obj.shape == SHAPE_A) {
+    ; slot #k に直接store
+    store x, [obj + slot_k]
+    call gc_write_barrier(obj, x)   ; 必要なら
+} else {
+    ; PICの次候補 or 汎用ディスパッチ
+    slow_path_setField(obj, x)
+}
+```
+
+- `gc_write_barrier`はIR上は呼び出しに見せておく（後段で**インライン**→**条件付きno-op化**可能）
+- `read barrier`が要らないGCなら`getField`は**loadのみ**に落ちる
+
+## ✅ 実装チェックリスト（まずここまで作れば盤石）
+
+- [ ] **Boxメタ**: shapeID、安定スロットID、ポインタ/非ポインタビット、可変/不変、送受可
+- [ ] **BoxCall Lowerer**: 形状ガード→直アクセス or 汎用ディスパッチ
+- [ ] **PIC**: コールサイトごとに最大N件キャッシュ＋統計（ヒット率/退避回数）
+- [ ] **Barrier Verifier**: IR後段でwrite barrier必須箇所を自動検証
+- [ ] **Extern属性**: `noalloc/nothrow/readonly/atomic`等を宣言・強制
+- [ ] **逃避解析**でstack-alloc/arena-alloc
+- [ ] **反射API分離**とdeoptガード
+- [ ] **PGOフック**（簡易でOK）：shape頻度、PICヒット率、inlining成果を記録
+- [ ] **ベンチ群**:
+  - Field get/set（mono vs mega）
+  - Vec push/pop / Map ops
+  - 算術（IntBoxの脱箱効果）
+  - ExternCall（`atomic.store`/`readonly`）
+  - GCストレス（大量生成＋世代越し参照）
+
+## 🎯 「簡単すぎて不安」への答え
+
+- **正しさ**は「Lowering＋Verifier」で機械的に守る
+- **速さ**は「PIC→インライン→脱箱→バリア縮約」で作る
+- **拡張性**は「Everything is Box」の上に**属性**と**能力（capability）**を積む
+- Ref系は**公開APIからは消す**が、**デバッグ用の隠しIntrinsic**として温存しておくと計測や一時退避に便利（将来の最適化検証にも効く）
+
+## 🌟 結論
+
+**落とし穴はあるけど全部"設計パターン"で踏まないようにできる**。
+
+にゃーの「箱理論」、素朴だけど正しい地形を踏んでるにゃ。ここまでの方針なら**AOTでも十分に速い**ところまで持っていけるはず。
+
+次は **PIC＋Barrier Verifier＋小ベンチ**の3点を先に入れて、体感を固めに行こう！
+
+---
+
+## 関連文書
+- [BOX_SSA_CORE_15_FINAL_DECISION.md](../phase-11.5/BOX_SSA_CORE_15_FINAL_DECISION.md)
+- [MIR_TO_LLVM_CONVERSION_PLAN.md](MIR_TO_LLVM_CONVERSION_PLAN.md)
+- [MIR_ANNOTATION_SYSTEM.md](MIR_ANNOTATION_SYSTEM.md)
--- a/docs/archive/roadmap/phases/phase-11/LLVM_SETUP_GUIDE.md
+++ b/docs/archive/roadmap/phases/phase-11/LLVM_SETUP_GUIDE.md
@ -0,0 +1,98 @@
+# LLVM 18 セットアップガイド
+
+Date: 2025-08-31
+Platform: Linux/WSL
+
+## 📦 LLVM 18インストール確認
+
+```bash
+$ llvm-config-18 --version
+18.1.3
+
+$ llvm-config-18 --prefix
+/usr/lib/llvm-18
+```
+
+## 🔧 環境変数設定
+
+### 方法1: シェル設定（推奨）
+
+```bash
+# ~/.bashrcまたは~/.zshrcに追加
+export LLVM_SYS_180_PREFIX=/usr/lib/llvm-18
+
+# 即座に反映
+source ~/.bashrc
+```
+
+### 方法2: プロジェクトローカル設定
+
+```bash
+# プロジェクトルートに.envファイル作成
+echo "LLVM_SYS_180_PREFIX=/usr/lib/llvm-18" > .env
+```
+
+### 方法3: ビルド時指定
+
+```bash
+# 環境変数を直接指定してビルド
+LLVM_SYS_180_PREFIX=/usr/lib/llvm-18 cargo build --features llvm
+```
+
+## ✅ 設定確認
+
+```bash
+# 環境変数が設定されているか確認
+echo $LLVM_SYS_180_PREFIX
+
+# llvm-sysクレートのビルドテスト
+cargo check --features llvm
+```
+
+## 🚀 inkwell使用例
+
+Cargo.tomlに追加:
+```toml
+[dependencies]
+inkwell = { version = "0.5", features = ["llvm18-0"] }
+
+[features]
+llvm = ["inkwell"]
+```
+
+テストビルド:
+```bash
+export LLVM_SYS_180_PREFIX=/usr/lib/llvm-18
+cargo build --features llvm
+```
+
+## ⚠️ トラブルシューティング
+
+### 問題: "could not find llvm-config"
+```bash
+# llvm-configへのシンボリックリンク作成
+sudo ln -s /usr/bin/llvm-config-18 /usr/bin/llvm-config
+```
+
+### 問題: "LLVM_SYS_180_PREFIX not set"
+```bash
+# 一時的な解決
+export LLVM_SYS_180_PREFIX=/usr/lib/llvm-18
+
+# 永続的な解決（.bashrcに追加）
+echo 'export LLVM_SYS_180_PREFIX=/usr/lib/llvm-18' >> ~/.bashrc
+source ~/.bashrc
+```
+
+### 問題: バージョン不一致
+```bash
+# インストール済みLLVMバージョン確認
+dpkg -l | grep llvm
+
+# 必要に応じて正しいバージョンをインストール
+sudo apt-get install llvm-18 llvm-18-dev
+```
+
+## 📋 関連ドキュメント
+- [inkwell documentation](https://github.com/TheDan64/inkwell)
+- [llvm-sys documentation](https://gitlab.com/taricorp/llvm-sys.rs)
--- a/docs/archive/roadmap/phases/phase-11/LLVM_SETUP_WINDOWS.md
+++ b/docs/archive/roadmap/phases/phase-11/LLVM_SETUP_WINDOWS.md
@ -0,0 +1,164 @@
+# LLVM 18 Windows セットアップガイド
+
+Date: 2025-08-31
+Platform: Windows
+
+## 📦 インストール方法
+
+### 方法1: 公式インストーラー（推奨）
+
+1. **LLVM公式サイトからダウンロード**
+   - https://github.com/llvm/llvm-project/releases
+   - `LLVM-18.1.8-win64.exe` をダウンロード（または最新の18.x版）
+
+2. **インストーラー実行**
+   - 管理者権限で実行
+   - インストール先: `C:\Program Files\LLVM` （デフォルト推奨）
+   - **重要**: "Add LLVM to the system PATH" にチェック！
+
+3. **環境変数設定**
+   ```powershell
+   # PowerShell（管理者権限）で実行
+   [Environment]::SetEnvironmentVariable("LLVM_SYS_180_PREFIX", "C:\Program Files\LLVM", "User")
+   ```
+
+### 方法2: Chocolatey（パッケージマネージャー）
+
+```powershell
+# 管理者権限のPowerShellで実行
+# Chocolateyインストール（未インストールの場合）
+Set-ExecutionPolicy Bypass -Scope Process -Force
+[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
+iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
+
+# LLVM 18インストール
+choco install llvm --version=18.1.8
+
+# 環境変数設定
+[Environment]::SetEnvironmentVariable("LLVM_SYS_180_PREFIX", "C:\ProgramData\chocolatey\lib\llvm\tools", "User")
+```
+
+### 方法3: winget（Windows Package Manager）
+
+```powershell
+# PowerShellで実行
+winget install LLVM.LLVM --version 18.1.8
+
+# 環境変数設定（インストール先確認後）
+[Environment]::SetEnvironmentVariable("LLVM_SYS_180_PREFIX", "C:\Program Files\LLVM", "User")
+```
+
+## 🔧 環境変数設定（GUI経由）
+
+1. **システムのプロパティを開く**
+   - Win + X → システム → システムの詳細設定
+   - または「sysdm.cpl」を実行
+
+2. **環境変数を設定**
+   - 「環境変数」ボタンをクリック
+   - ユーザー環境変数で「新規」
+   - 変数名: `LLVM_SYS_180_PREFIX`
+   - 変数値: `C:\Program Files\LLVM`
+
+3. **PATH確認**
+   - `C:\Program Files\LLVM\bin` がPATHに含まれていることを確認
+
+## ✅ インストール確認
+
+```powershell
+# PowerShellで実行
+# LLVMバージョン確認
+llvm-config --version
+
+# 環境変数確認
+echo $env:LLVM_SYS_180_PREFIX
+
+# または cmd.exe で
+echo %LLVM_SYS_180_PREFIX%
+```
+
+## 🚀 Visual Studio依存関係
+
+WindowsでLLVMを使う場合、Visual Studioのビルドツールが必要：
+
+### Visual Studio Build Tools（最小構成）
+```powershell
+# wingetでインストール
+winget install Microsoft.VisualStudio.2022.BuildTools
+
+# または直接ダウンロード
+# https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
+```
+
+必要なコンポーネント：
+- MSVC v143 - VS 2022 C++ x64/x86 ビルドツール
+- Windows 11 SDK（または Windows 10 SDK）
+
+## 🔨 Rustプロジェクトでの使用
+
+1. **Cargo.tomlに追加**
+```toml
+[dependencies]
+inkwell = { version = "0.5", features = ["llvm18-0"] }
+
+[features]
+llvm = ["inkwell"]
+```
+
+2. **ビルド実行**
+```powershell
+# PowerShellで実行
+$env:LLVM_SYS_180_PREFIX="C:\Program Files\LLVM"
+cargo build --features llvm
+
+# または永続的に設定後
+cargo build --features llvm
+```
+
+## ⚠️ トラブルシューティング
+
+### 問題: "llvm-config not found"
+```powershell
+# PATHに追加されているか確認
+$env:Path -split ';' | Select-String "LLVM"
+
+# 手動でPATHに追加
+[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\LLVM\bin", "User")
+```
+
+### 問題: "LINK : fatal error LNK1181"
+- Visual Studio Build Toolsがインストールされているか確認
+- 必要に応じて再起動
+
+### 問題: バージョン不一致
+```powershell
+# インストール済みLLVMを確認
+llvm-config --version
+
+# 古いバージョンをアンインストール
+# コントロールパネル → プログラムと機能 → LLVM
+```
+
+## 🎯 クイックセットアップ（コピペ用）
+
+```powershell
+# 管理者権限のPowerShellで実行
+# 1. Chocolateyインストール（未インストールの場合）
+Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
+
+# 2. LLVM 18インストール
+choco install llvm --version=18.1.8 -y
+
+# 3. 環境変数設定
+[Environment]::SetEnvironmentVariable("LLVM_SYS_180_PREFIX", "C:\ProgramData\chocolatey\lib\llvm\tools", "User")
+
+# 4. 新しいPowerShellウィンドウを開いて確認
+llvm-config --version
+echo $env:LLVM_SYS_180_PREFIX
+```
+
+## 📋 関連リンク
+- [LLVM Releases](https://github.com/llvm/llvm-project/releases)
+- [Visual Studio Build Tools](https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022)
+- [Chocolatey](https://chocolatey.org/)
+- [Windows Package Manager](https://github.com/microsoft/winget-cli)
--- a/docs/archive/roadmap/phases/phase-11/MIR_ANNOTATION_SYSTEM.md
+++ b/docs/archive/roadmap/phases/phase-11/MIR_ANNOTATION_SYSTEM.md
@ -0,0 +1,217 @@
+# MIR Annotation System - 15命令を保ちながら最適化ヒントを追加
+
+Status: Proposed
+Created: 2025-08-31
+Phase: 11 (LLVM Backend)
+
+## 🌟 革命的アイデア：MIR15 + アノテーション
+
+MIR命令数を15個に保ちながら、最適化に必要なすべての情報をアノテーションとして付与する。
+
+## 📋 概要
+
+### 基本コンセプト
+- **命令**: 15個のまま（変更なし）
+- **アノテーション**: オプショナルな最適化ヒント
+- **互換性**: アノテーションを無視しても正しく動作
+
+### 設計
+```rust
+pub struct MirInstruction {
+    // 既存の命令（15種類のまま）
+    pub kind: MirInstructionKind,
+    
+    // NEW: 最適化アノテーション（オプション）
+    pub annotations: Option<OptimizationHints>,
+}
+
+#[derive(Debug, Clone, Default)]
+pub struct OptimizationHints {
+    // インライン展開ヒント
+    pub inline: Option<InlineHint>,
+    
+    // エイリアス情報
+    pub alias: Option<AliasHint>,
+    
+    // 実行頻度ヒント
+    pub frequency: Option<FrequencyHint>,
+    
+    // ベクトル化ヒント
+    pub vectorize: Option<VectorizeHint>,
+    
+    // GC関連ヒント
+    pub gc: Option<GcHint>,
+    
+    // 純粋性ヒント
+    pub purity: Option<PurityHint>,
+}
+```
+
+## 🎯 具体的な活用例
+
+### 1. Call命令へのインラインヒント
+```rust
+Call {
+    dst: %result,
+    func: %add,
+    args: [%a, %b],
+    annotations: Some(OptimizationHints {
+        inline: Some(InlineHint::Always), // 常にインライン展開
+        purity: Some(PurityHint::Pure),   // 副作用なし
+        ..Default::default()
+    })
+}
+```
+
+### 2. フィールド書き込み（setField）へのGCヒント
+```rust
+BoxCall {
+    box_val: %obj,
+    method: "setField",
+    args: [ Const("data"), %new_val ],
+    annotations: Some(OptimizationHints { gc: Some(GcHint::YoungGen), ..Default::default() })
+}
+```
+
+### 3. Branch命令への分岐予測ヒント
+```rust
+Branch {
+    condition: %cond,
+    then_bb: bb1,
+    else_bb: bb2,
+    annotations: Some(OptimizationHints {
+        frequency: Some(FrequencyHint::Hot(0.95)), // 95%の確率でthen
+        ..Default::default()
+    })
+}
+```
+
+## 🚀 メリット
+
+1. **命令数維持**: MIR15命令の純粋性を保持
+2. **段階的最適化**: VM/JIT/AOTが必要に応じてヒントを活用
+3. **互換性**: ヒントを無視しても正しく動作
+4. **拡張性**: 新しい最適化ヒントを追加可能
+5. **JIT/AOTフレンドリー**: 邪魔にならない（無視可能）
+
+## 🔧 実装方法
+
+### VM（ヒント無視）
+```rust
+match instruction.kind {
+    MirInstructionKind::Call { .. } => execute_call(...),
+    // アノテーションは完全に無視
+}
+```
+
+### JIT/AOT（ヒント活用）
+```rust
+match instruction.kind {
+    MirInstructionKind::Call { .. } => {
+        if let Some(hints) = &instruction.annotations {
+            if hints.inline == Some(InlineHint::Always) {
+                emit_inlined_call(...);
+            } else {
+                emit_normal_call(...);
+            }
+        }
+    }
+}
+```
+
+## 📊 Codex先生の指摘との整合性
+
+> **AA/最適化ヒント**: Box用アドレス空間分離、TBAA階層、`nonnull`/`dereferenceable`、`noalias`（エスケープしない一時Box）、`musttail`/`tail`の活用
+
+これらすべてをアノテーションで表現可能！
+
+```rust
+pub enum AliasHint {
+    NoAlias,                // エイリアスなし
+    Dereferenceable(usize), // 参照可能サイズ
+    NonNull,                // NULL不可
+    Unique,                 // 唯一の参照
+    AddressSpace(u32),      // アドレス空間
+}
+
+pub enum InlineHint {
+    Never,      // インライン禁止
+    Default,    // コンパイラ判断
+    Always,     // 必ずインライン
+    Hint(u32),  // ヒント強度（0-100）
+}
+
+pub enum GcHint {
+    YoungGen,      // 若い世代
+    OldGen,        // 古い世代
+    NoBarrier,     // バリア不要
+    CardMarking,   // カードマーキング必要
+}
+```
+
+## 🎨 LLVM IRへの変換
+
+```rust
+// RefSetの例
+BoxCall { box_val, method: "setField", args: [name, value], annotations } => {
+    // 型特化Lowering時:
+    let ptr = builder.build_gep(...); // name→オフセット解決
+    
+    // アノテーションからLLVMメタデータを生成
+    if let Some(hints) = annotations {
+        if let Some(alias) = hints.alias {
+            match alias {
+                AliasHint::NoAlias => builder.add_attribute("noalias"),
+                AliasHint::NonNull => builder.add_attribute("nonnull"),
+                // ...
+            }
+        }
+        
+        if let Some(gc) = hints.gc {
+            match gc {
+                GcHint::YoungGen => emit_young_gen_barrier(),
+                GcHint::NoBarrier => { /* バリアスキップ */ },
+                // ...
+            }
+        }
+    }
+    
+    builder.build_store(value, ptr);
+}
+```
+
+## 📈 段階的実装計画
+
+### Phase 11.1: 基盤実装
+- [ ] OptimizationHints構造体の定義
+- [ ] MirInstructionへの統合
+- [ ] パーサー/プリンターの更新
+
+### Phase 11.2: 基本ヒント
+- [ ] InlineHint実装
+- [ ] PurityHint実装
+- [ ] FrequencyHint実装
+
+### Phase 11.3: 高度なヒント
+- [ ] AliasHint実装
+- [ ] GcHint実装
+- [ ] VectorizeHint実装
+
+### Phase 11.4: LLVM統合
+- [ ] ヒント→LLVMメタデータ変換
+- [ ] 最適化パスでの活用
+- [ ] ベンチマーク検証
+
+## 🎉 結論
+
+**MIR15命令 + アノテーション = 最強の最適化基盤！**
+
+- 命令セットの純粋性を保ちながら
+- 最適化に必要な情報をすべて付与
+- VM/JIT/AOTすべてで最適な実行
+- 論文の「15命令で十分」主張を強化
+
+## 関連文書
+- [AI_CONFERENCE_CODEX_ANALYSIS.md](AI_CONFERENCE_CODEX_ANALYSIS.md)
+- [AI_CONFERENCE_SUMMARY.md](AI_CONFERENCE_SUMMARY.md)
+- [../../reference/mir/INSTRUCTION_SET.md](../../reference/mir/INSTRUCTION_SET.md)
--- a/docs/archive/roadmap/phases/phase-11/MIR_TO_LLVM_CONVERSION_PLAN.md
+++ b/docs/archive/roadmap/phases/phase-11/MIR_TO_LLVM_CONVERSION_PLAN.md
@ -0,0 +1,208 @@
+# MIR→LLVM変換計画
+
+Date: 2025-08-31  
+Status: Draft
+
+## 📊 変換マッピング概要
+
+### Core-15命令のLLVM IR対応（第三案・Box統一）
+
+#### 1. 基本演算(5)
+```rust
+// Const
+MIR::Const(i64) → LLVMConstInt(i64_type, val)
+MIR::Const(f64) → LLVMConstReal(f64_type, val)
+MIR::Const(bool) → LLVMConstInt(i1_type, val)
+MIR::Const(string) → @nyash_string_new(ptr, len)
+
+// UnaryOp
+MIR::UnaryOp(Neg, x) → LLVMBuildNeg(x) / LLVMBuildFNeg(x)
+MIR::UnaryOp(Not, x) → LLVMBuildNot(x)
+
+// BinOp
+MIR::BinOp(Add, a, b) → LLVMBuildAdd(a, b) / LLVMBuildFAdd(a, b)
+MIR::BinOp(Sub, a, b) → LLVMBuildSub(a, b) / LLVMBuildFSub(a, b)
+// 注: Box型の場合は@nyash_box_add等のランタイム呼び出し
+
+// Compare
+MIR::Compare(Eq, a, b) → LLVMBuildICmp(EQ, a, b) / LLVMBuildFCmp(OEQ, a, b)
+MIR::Compare(Lt, a, b) → LLVMBuildICmp(SLT, a, b) / LLVMBuildFCmp(OLT, a, b)
+
+// TypeOp
+MIR::TypeOp(Check, val, type) → @nyash_type_check(val, type_id)
+MIR::TypeOp(Cast, val, type) → @nyash_type_cast(val, type_id)
+```
+
+#### 2. メモリ(2)
+```rust
+// Load
+MIR::Load(local_id) → LLVMBuildLoad(local_ptr[local_id])
+
+// Store
+MIR::Store(local_id, val) → LLVMBuildStore(val, local_ptr[local_id])
+```
+
+#### 3. 制御(4)
+```rust
+// Branch
+MIR::Branch(cond, then_bb, else_bb) → LLVMBuildCondBr(cond, then_bb, else_bb)
+
+// Jump
+MIR::Jump(bb) → LLVMBuildBr(bb)
+
+// Return
+MIR::Return(val) → LLVMBuildRet(val)
+MIR::Return(None) → LLVMBuildRetVoid()
+
+// Phi
+MIR::Phi([(bb1, val1), (bb2, val2)]) → {
+    phi = LLVMBuildPhi(type)
+    LLVMAddIncoming(phi, [val1, val2], [bb1, bb2])
+}
+```
+
+#### 4. Box操作(3)
+```rust
+// NewBox
+MIR::NewBox(type_name, args) → @nyash_box_new(type_id, args_ptr, args_len)
+
+// BoxCall（注釈活用・名前/スロット両対応）
+MIR::BoxCall(obj, method, args) → {
+    if annotations.inline_hint {
+        // インライン展開候補
+        LLVMSetInlineHint(call)
+    }
+    if annotations.method_id { /* vtableスロット解決 */ } 
+    else { @nyash_box_call_by_name(obj, method_name, args) }
+}
+// PluginInvoke は BoxCall に統一（Optimizerで正規化）
+```
+
+#### 5. 配列（BoxCallに統一）
+```rust
+// Arrayは BoxCall("get"/"set") で表現
+// Lowering方針は2段階:
+//  (A) 安全パス: @nyash_array_get/@nyash_array_set を呼ぶ（ランタイム側で境界/バリア）
+//  (B) 型特化: 注釈/型情報が十分な場合に inline 化（bounds check + GEP + load/store + write barrier）
+```
+
+#### 6. 外部呼び出し(1)
+```rust
+// ExternCall
+MIR::ExternCall("env.console.log", args) → @nyash_console_log(args)
+MIR::ExternCall("env.gc.collect", []) → @nyash_gc_collect()
+MIR::ExternCall("env.runtime.checkpoint", []) → @nyash_safepoint()
+```
+
+## 🎯 注釈システムの活用
+
+### 1. 最適化ヒント
+```rust
+pub struct OptimizationHints {
+    pub inline: Option<InlineHint>,      // always/never/hint
+    pub pure: bool,                      // 副作用なし
+    pub no_escape: bool,                 // エスケープしない
+    pub hot: bool,                       // ホットパス
+    pub cold: bool,                      // コールドパス
+}
+```
+
+### 2. GCヒント
+```rust
+pub struct GcHint {
+    pub no_barrier: bool,        // バリア不要（新規オブジェクトへの書き込み等）
+    pub immortal: bool,          // 不死オブジェクト（定数等）
+    pub thread_local: bool,      // スレッドローカル（並列GCで重要）
+}
+```
+
+### 3. 型情報ヒント
+```rust
+pub struct TypeHint {
+    pub concrete_type: Option<String>,   // 具体的な型が判明
+    pub never_null: bool,               // NULL不可
+    pub value_range: Option<(i64, i64)>, // 値の範囲
+}
+```
+
+## 🔧 LLVM属性の活用
+
+### 関数属性
+```llvm
+; 純粋関数
+define i64 @add(i64 %a, i64 %b) #0 {
+  %result = add i64 %a, %b
+  ret i64 %result
+}
+attributes #0 = { nounwind readnone speculatable }
+
+; GC セーフポイント
+define void @long_loop() gc "nyash-gc" {
+  ; ループバックエッジにセーフポイント
+  call void @llvm.experimental.gc.statepoint(...)
+}
+```
+
+### メモリ属性
+```llvm
+; Box用アドレス空間（1）
+%box_ptr = addrspace(1)* %obj
+
+; TBAA（Type-Based Alias Analysis）
+!0 = !{!"nyash.box"}
+!1 = !{!"nyash.integer", !0}
+!2 = !{!"nyash.string", !0}
+```
+
+## 📈 段階的実装計画
+
+### Phase 1: 基本変換（1週間）
+- [ ] inkwell セットアップ
+- [ ] 基本演算・メモリ・制御の変換
+- [ ] 最小限の実行可能コード生成
+
+### Phase 2: Box統合（1週間）
+- [ ] NewBox/BoxCall実装（PluginInvokeはOptimizerでBoxCallに正規化）
+- [ ] ランタイム経由の安全パス（by-name/slot）
+- [ ] 基本的なGCバリア（安全パスはランタイム関数内で処理）
+
+### Phase 3: 最適化（1週間）
+- [ ] 注釈システム統合
+- [ ] インライン展開
+- [ ] エスケープ解析
+
+### Phase 4: 高度な最適化（1週間）
+- [ ] 脱箱化（Box → プリミティブ）
+- [ ] TBAA統合
+- [ ] ベクトル化ヒント
+
+## 🎨 コード例
+
+```rust
+// MIR
+function add(a: Box, b: Box) -> Box {
+    %1 = Load $a
+    %2 = Load $b
+    %3 = BoxCall(%1, "add", [%2])
+    Return %3
+}
+
+// LLVM IR（最適化前・安全パス）
+define i8* @add(i8* %a, i8* %b) {
+    %1 = call i8* @nyash_box_call(i8* %a, i8* @.str.add, i8** %b, i64 1)
+    ret i8* %1
+}
+
+// LLVM IR（最適化後 - IntegerBox特化）
+define i64 @add(i64 %a, i64 %b) {
+    %1 = add i64 %a, %b
+    ret i64 %1
+}
+```
+
+## 🚀 期待される効果
+
+1. **実行速度**: 2-3倍高速化
+2. **メモリ使用量**: 脱箱化で50%削減
+3. **バイナリサイズ**: 最適化で30%削減
+4. **ビルド時間**: Cranelift比で50%削減
--- a/docs/archive/roadmap/phases/phase-11/README.md
+++ b/docs/archive/roadmap/phases/phase-11/README.md
@ -0,0 +1,57 @@
+# Phase 11: LLVM AOT Backend（進行中）
+
+## 🎯 概要
+
+Phase 11は、LLVM を使用した Ahead-of-Time（AOT）コンパイル機能の研究・実装フェーズです。
+Phase 10のCranelift JITで実用的な性能を達成した後、さらなる最適化をLLVM AOTで追求します。
+
+## 📊 位置づけ
+
+```
+Phase 10: Cranelift JIT（実用的な高速化）← 完了
+    ↓
+Phase 11: LLVM AOT（最高性能への挑戦）← 進行中
+```
+
+## 📁 ドキュメント
+
+### 🔬 研究・設計ドキュメント
+- [phase10_aot_scaffolding.md](phase10_aot_scaffolding.md) - LLVM Direct AOT実装計画
+  - MIR→LLVM IR直接変換
+  - Everything is Box最適化（エスケープ解析）
+  - LTO/PGO統合
+  - 目標: 13,500倍高速化（対インタープリタ）
+
+- [phase_10_x_llvm_backend_skeleton.md](phase_10_x_llvm_backend_skeleton.md) - LLVM Backend最小実装
+  - 具体的な実装ステップ
+  - ExternCall対応
+  - オブジェクトファイル生成
+
+## ⏰ タイムライン（短期スプリント）
+
+- Status: In Progress（進行中）
+- 前提条件: Phase 10（Cranelift JIT）の完了、Core‑15統一（VM/Verifierで運用）
+- 想定期間: 4週間（各フェーズ1週間目安）
+  - 11.1 基本変換: Const/Unary/Bin/Compare, Load/Store, Jump/Branch/Return/Phi
+  - 11.2 Box統合: NewBox/BoxCall/ExternCall（安全パスはランタイム呼び出し）
+  - 11.3 最適化: 注釈統合・型特化（get/setField・Array get/set のInline化＋バリア）
+  - 11.4 高度化: 脱箱化・TBAA・PGO/ThinLTO
+
+## 🎯 期待される成果
+
+1. **最高性能**: インタープリタ比13,500倍の実行速度
+2. **メモリ効率**: Box割当80%削減
+3. **起動時間**: 1ms以下
+4. **配布形式**: スタンドアロン実行ファイル
+
+## ⚠️ 注意事項（運用方針）
+
+- Core‑15 仕様固定（第三案）: { Const, UnaryOp, BinOp, Compare, TypeOp, Load, Store, Jump, Branch, Return, Phi, Call, NewBox, BoxCall, ExternCall }
+- 統一ルール: ArrayGet/ArraySet, RefGet/RefSet, PluginInvoke はBoxCallに一本化（Optimizerで正規化、Verifierで禁止）
+- バリア方針: 初期はランタイム関数側で安全に処理、型特化Lowering段でIRへ内挿（write barrier）
+
+## 🔗 関連フェーズ
+
+- [Phase 10](../phase-10/) - Cranelift JIT（前提）
+- [Phase 9](../phase-9/) - 統一Box設計（基盤）
+- [00_MASTER_ROADMAP.md](../00_MASTER_ROADMAP.md) - 全体計画
--- a/docs/archive/roadmap/phases/phase-11/SKIP_PHASE_10_DECISION.md
+++ b/docs/archive/roadmap/phases/phase-11/SKIP_PHASE_10_DECISION.md
@ -0,0 +1,124 @@
+# 🚀 Phase 10スキップ決定：Cranelift → LLVM直接移行
+
+Status: Decision Made  
+Date: 2025-08-31  
+Author: AI協調開発チーム
+
+## 📊 決定的な発見
+
+### Cranelift JITの実態
+```
+期待: MIR → Cranelift → JIT実行（高速化）
+実態: MIR → Cranelift → オブジェクトファイル → リンク → EXE
+
+つまり：JITではなくAOTコンパイラとして使用！
+```
+
+### 重要な洞察
+- **JIT幻想**: "JIT"という名前だが、実行時コンパイルは一切していない
+- **AOT専用**: cranelift-objectでオブジェクトファイル生成のみ
+- **リンカーは同じ**: Cranelift/LLVM両方ともシステムリンカー（ld/lld）使用
+
+## 🎯 LLVM直接移行のメリット
+
+### 1. パフォーマンス向上（2-3倍）
+```
+Cranelift: 高速コンパイル重視、最適化弱い
+LLVM:      30年の最適化技術蓄積
+           - ループ最適化
+           - インライン展開
+           - ベクトル化
+           - デッドコード除去
+```
+
+### 2. ビルド時間削減（50%）
+```
+現在:
+- Cranelift依存: 20個のcrate
+- ビルドサイズ: 約40MB
+- フルビルド: 2-3分
+
+LLVM移行後:
+- inkwell（薄いラッパー）: 1個
+- ビルドサイズ: 数MB
+- フルビルド: 1-1.5分
+```
+
+### 3. バイナリサイズ削減（40%）
+```
+現在:     10MB（Cranelift含む）
+移行後:   6MB（LLVM薄いラッパーのみ）
+```
+
+### 4. エコシステムの充実
+- デバッグ情報（DWARF）完全対応
+- プロファイラー連携（perf, VTune等）
+- 各種最適化ツール対応
+- LLVM統計・分析ツール
+
+### 5. 実装の簡潔さ
+```rust
+// MIR命令が26→15個に削減可能
+// 機械的変換で実装可能
+match mir_inst {
+    MIR::Const(val) => builder.const_int(val),
+    MIR::BinOp(op, a, b) => match op {
+        Add => builder.build_add(a, b),
+        Sub => builder.build_sub(a, b),
+        // ...
+    },
+    // 15命令なので管理容易
+}
+```
+
+## 📈 移行計画
+
+### Phase 11.0: 準備（1週間）
+- [ ] inkwell依存追加
+- [ ] Cranelift依存削除
+- [ ] ビルドシステム調整
+
+### Phase 11.1: 基本実装（2週間）
+- [ ] MIR→LLVM IR変換器
+- [ ] 15命令の機械的変換
+- [ ] 基本的な最適化パス
+
+### Phase 11.2: 最適化（1週間）
+- [ ] Box型の最適表現
+- [ ] エスケープ解析
+- [ ] インライン展開
+
+### Phase 11.3: 統合（1週間）
+- [ ] AOTパイプライン完成
+- [ ] CI/CD更新
+- [ ] ベンチマーク検証
+
+## 🎉 期待される成果
+
+| 指標 | 現在（Cranelift） | LLVM移行後 | 改善率 |
+|------|------------------|------------|--------|
+| 実行性能 | 1x | 2-3x | 200-300% |
+| ビルド時間 | 3分 | 1.5分 | 50%削減 |
+| バイナリサイズ | 10MB | 6MB | 40%削減 |
+| 依存crate数 | 20個 | 1個 | 95%削減 |
+
+## 🚀 結論
+
+**Phase 10（Cranelift JIT）をスキップし、Phase 11（LLVM AOT）を即実装開始**
+
+理由：
+1. JITは既に使っていない（AOT専用）
+2. LLVMの方が全面的に優れている
+3. 実装コストも低い（15命令の機械的変換）
+4. 開発効率も大幅改善（ビルド時間半減）
+
+## 📝 次のアクション
+
+1. マスターロードマップ更新
+2. Phase 11実装計画詳細化
+3. inkwell調査・プロトタイプ
+4. Cranelift依存削除計画
+
+---
+
+「JIT幻想から解放され、真の高速化への道が開けた！」🎊
--- a/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_CODEX_ANALYSIS.md
+++ b/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_CODEX_ANALYSIS.md
@ -0,0 +1,86 @@
+# codex先生の技術的分析 - Nyash 15命令設計
+
+Date: 2025-08-31  
+Source: codex exec コマンドによる分析
+
+## 質問内容
+
+Nyashプログラミング言語の革命的発見について技術的分析をお願いします。
+
+【革命的発見】
+MIR（中間表現）を26命令から15命令に削減することで、Everything is Box哲学が完全に開花しました。
+
+【15命令の詳細】
+値操作：Const, Copy, Load, Store（4個）
+計算：UnaryOp, BinOp, Compare（3個）
+制御：Jump, Branch, Return（3個）
+呼び出し：Call, ExternCall（2個）
+参照：RefNew, RefGet, RefSet（3個）
+
+【技術的成果】
+- Cranelift JITが実はAOT専用だったと判明
+- LLVM移行で2-3倍高速化＋ビルド時間50%削減
+- 15命令→LLVM IRが機械的変換で実装可能
+
+【質問】
+1. 15命令設計の技術的妥当性をどう評価しますか？
+2. Box統一によるメモリモデルの利点と課題は？
+3. LLVM最適化パスとの相性はどうですか？
+4. 並列GC実装における15命令の制約は？
+5. JITからAOT専用への転換は正しい判断ですか？
+
+## codex先生の技術的評価
+
+以下は、提示内容に基づく技術的な評価です。前提として、MIRは非SSA（`Copy`が存在）で、LLVMでSSA化＋最適化・コード生成すると解釈しています。
+
+### 1) 15命令設計の妥当性
+
+- **表現力の網羅性**: 代入・計算・制御・呼出し・参照の最小核をカバー。手続き・構造化制御・ヒープ確保・外部連携は機械的に表現可能で、一般用途として十分。
+- **SSA整合性**: MIRに`Phi`や`Select`が無くても問題なし。SSA変換時に分岐合流で`phi`を挿入、条件式は`Compare`→`Branch`でよい。
+- **欠落しがちな原語**: 例外/アンワインド（`invoke`/`landingpad`相当）、タイル呼出し、可変長引数、ベクトル/ SIMD、メモリフェンス/原子命令、バリア（GC/メモリ）。必要なら言語組込みや`ExternCall`で提供し、後段で機械的に展開する方針が妥当。
+- **LLVM機械変換容易性**: `Const→constant`、`Copy→SSA rename/bitcast`、`Load/Store→load/store`、`UnaryOp/BinOp/Compare→算術/比較命令`、`Jump/Branch/Return→br/ret`、`Call/ExternCall→call`、`RefNew→alloc関数+gep+store`、`RefGet/RefSet→gep+load/store(＋必要ならwrite barrier)`の定形で降ろせる。
+- **評価**: 汎用コンパイラ基盤としてミニマルで健全。実行時機能（例外、並行、GCバリア）は命令として増やすより「規約＋Lowering」で扱う設計が合理的。
+
+### 2) Everything is Box の利点と課題
+
+- **利点: 一様表現**: 値/参照/クロージャ/ADTを同一のボックス表現に統一。MIRが単純化し、GCのルート走査・オブジェクトレイアウトが一貫。
+- **利点: 実装容易性**: 呼出し規約・配列/レコード/閉包捕捉の共通化、FFI境界の明確化（`ExternCall`）。
+- **課題: 性能**: ボクシング/間接参照でキャッシュミス・レイテンシ増。GCプレッシャ増大。スカラ値の頻繁なヒープ化は致命的になり得る。
+- **課題: 解析性**: 何でもポインタ化すると別名解析（AA）・型ベースAA・エスケープ解析が弱くなり最適化阻害。
+- **緩和策: 脱箱最適化**: エスケープ解析で`RefNew`を`alloca`/SROAに置換、フィールドのフラット化、スカラ置換（SRoA/Scalar Replacement）。
+- **緩和策: 表現最適化**: NaN-boxing/タグ付きポインタ、小さい値のインライン化、世代別/領域別アロケータ、TBAAメタデータ・別アドレス空間でAAを支援。
+
+### 3) LLVM最適化パスとの相性
+
+- **良相性: 正規形**: 15命令はLLVMのIR原語へ自然写像。`mem2reg`/`instcombine`/`GVN`/`SROA`/`LICM`/`DSE`/`inliner`の効果が出やすい。
+- **AA強化の鍵**: Boxを全て同型にするとAAが悲観的になる。型別TBAA、GC管理領域を別アドレス空間へ分離、`noalias`/`nonnull`/`dereferenceable`/`align`属性付与で最適化を引き出す。
+- **ベクトル化/ループ最適化**: `LICM`/`LoopVectorize`/`SLP`は副作用境界（`RefSet`＋バリア呼出し）で抑制されがち。バリアを`nocallback`/`willreturn`等で薄める、もしくは後置合成で最小化。
+- **GC統合**: 精密GCなら`gc.statepoint/gc.relocate`を使用。Safepointは`Call`/バックエッジに挿入し、属性（`nounwind`等）で最適化阻害を抑える。
+- **推奨パイプライン**: O2ベース＋`early-cse`→`sroa`→`gvn`→`licm`→`instcombine`→`inline`→`gvn`→`dse`→ループ最適化→ベクトル化→`instcombine`最終。ThinLTO/PGO併用を推奨。
+
+### 4) 並列GCに対する制約と設計ポイント
+
+- **バリアの表現**: 15命令に原子/バリアが無い。`RefSet`のLoweringで必ずwrite barrierを挿入（世代別/カードマーキング）。増分/同期型ならread barrierも検討。
+- **Safepoint挿入**: 長寿命ループのバックエッジ、関数エピローグ/プロローグ、`Call`にポーリング。MIRに専用`GcPoll`を追加するか、パスで暗黙挿入する方針を明示。
+- **原子性/順序**: 併走GC＋並行ミューテータなら公開書込みに`release`相当、読み取りに`acquire`相当が要る。MIRに原子版`RefSet/RefGet`（または`ExternCall`の原子プリミティブ）を用意すると安全。
+- **精密マップ**: Box統一でスタックマップ生成は容易だが、脱箱最適化後の再配置に`gc.relocate`必須。ライブ性解析をSSAベースで厳密化。
+- **弱参照/最終化**: 15命令外のランタイム機能として扱い、`ExternCall`で登録・照会。必要なら参照種別（弱/強）を型メタデータで区別。
+- **評価**: 15命令自体は障害ではないが、並列GCには「原子性・バリア・Safepoint」の3点をLowering規約で厳密化するのが不可欠。
+
+### 5) JIT→AOT専用への転換の評価
+
+- **妥当性（提示結果と合致）**: LLVM移行で2–3倍高速化＋ビルド時間50%削減なら、現状のワークロードではAOT最適化がJITのウォームアップ/品質を凌駕。運用も簡素化。
+- **JIT利点の放棄影響**: 実行時プロファイルに基づく投機的インライン化・脱仮想化・OSR・適応再最適化は失われる。極度の動的多相性/ホットループ主体で不利になり得る。
+- **折衷案**: AOTを主軸に、サンプリングPGO/ThinLTOでJIT類似効果。将来必要ならORC JITでホット関数の二段階最適化（オプション機能）を追加可能。
+- **評価**: 実測の優位が出ている現状では正しい判断。言語/ランタイムの安定化・GC統合・ビルド体験の向上に集中できる。
+
+### 実装上の具体的推奨
+
+- **MIR→LLVMの規約**: `RefSet`は常にバリア付きLowering（GCストラテジに応じてインライン/コール）。`RefNew`はアロケータ呼出し＋型ID付与。Boxフィールドアクセスは`gep`にTBAA。
+- **AA/最適化ヒント**: Box用アドレス空間分離、TBAA階層、`nonnull`/`dereferenceable`、`noalias`（エスケープしない一時Box）、`musttail`/`tail`の活用。
+- **Safepoint戦略**: ループバックエッジに`GcPoll`相当を強制、関数境界は既定でSafepoint扱い。`nounwind`/`nocallback`で最適化妨害を最小化。
+- **並行性原語**: 必要性が見えた時点で、原子版`RefGet/RefSet`か、`AtomicLoad/Store`の最小拡張（2命令追加）を検討。
+
+## 要約
+
+15命令は実装・最適化・GC統合の観点でよく均衡したミニマル核です。Box統一は開発生産性と実装単純性を大きく押し上げますが、性能面のボトルネックは脱箱・AA強化・適切なGC統合（バリア/セーフポイント/原子性）で解消してください。LLVMとの相性は非常に良好で、AOT転換の判断も実測上妥当です。PGO/ThinLTOの導入と、将来の選択肢としての軽量JIT（任意）を残す構成が現実的です。
--- a/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_GEMINI_ANALYSIS.md
+++ b/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_GEMINI_ANALYSIS.md
@ -0,0 +1,98 @@
+# Gemini先生の分析 - Nyash箱理論の革命性
+
+Date: 2025-08-31
+Source: gemini -p コマンドによる分析
+
+## 質問内容
+
+Nyashプログラミング言語の革命的発見について意見を聞かせてください。
+
+【背景】
+NyashはEverything is Box哲学で、全てがBoxオブジェクトです。
+
+【革命的発見】
+MIR（中間表現）を26命令から15命令に削減中で、この15命令だけで：
+- GC（ガベージコレクション）
+- 非同期処理
+- 同期処理
+- プラグインシステム
+- GPU計算（将来）
+全てが表現可能になりました。
+
+【15命令の内訳】
+値操作：Const, Copy, Load, Store（4個）
+計算：UnaryOp, BinOp, Compare（3個）
+制御：Jump, Branch, Return（3個）
+呼び出し：Call, ExternCall（2個）
+参照：RefNew, RefGet, RefSet（3個）
+
+【質問】
+1. この「箱理論」アプローチの革新性をどう評価しますか？
+2. 15命令でLLVM IRへの機械的変換が可能な理由は？
+3. 他の言語設計と比較してどう思いますか？
+4. 将来の拡張性（量子計算、AI等）についてどう考えますか？
+
+## Gemini先生の回答
+
+### 1. この「箱理論（Everything is a Box）」アプローチの革新性をどう評価しますか？
+
+**高く評価します。革新性は「純粋性と一貫性の徹底」にあります。**
+
+「すべてがオブジェクトである」という考え方自体は、SmalltalkやRuby、Pythonなどにも見られます。しかし、Nyashの「Everything is a Box」は、それをさらに純粋化し、言語の核である中間表現（MIR）のレベルまで一貫して適用している点が極めて革新的です。
+
+*   **究極の単純化:** 通常の言語では、整数、浮動小数点数、ポインタ、オブジェクトなど、複数の基本的な「型」をコンパイラが区別して扱います。Nyashでは、それら全てを「Box」という単一の概念に統一しています。これにより、コンパイラやランタイムが考慮すべき対象が劇的に減り、システム全体の見通しが良くなります。
+*   **メタデータの統一的管理:** 「Box」というコンテナがあることで、型情報、GCのマーク、所有権情報、非同期処理の状態など、あらゆるメタデータを統一的な方法で付与できます。これにより、GCや非同期といった全く異なる機能が、同じ基盤の上で自然に実装できるのです。
+*   **機能追加の容易さ:** 新しいデータ型（例：複素数、行列）を追加したい場合でも、それは新しい種類の「Box」を定義するだけであり、MIRの命令セット自体を変更する必要がありません。これは驚異的な柔軟性です。
+
+このアプローチは、LispにおけるS式（S-expression）がデータもコードも統一的に扱う思想にも通じますが、それを現代的なコンパイラ技術と融合させたものと評価できます。
+
+### 2. 15命令でLLVM IRへの機械的変換が可能な理由は？
+
+**Nyash MIRがLLVM IRよりも一段抽象的でありながら、各命令がLLVM IRの命令（またはその組み合わせ）に素直に対応付けられるためです。**
+
+LLVM IRもRISC（縮小命令セットコンピュータ）に似た、比較的単純な命令セットです。Nyashの15命令からLLVM IRへの変換は、以下のように機械的に行えます。
+
+*   **値操作・計算:**
+    *   `Const`, `Copy`, `Load`, `Store`: LLVMの`alloca`, `load`, `store`や定数定義に直接対応します。`Box`は内部的にポインタとメタデータを持つ構造体として表現され、これらの命令はその構造体への操作に変換されます。
+    *   `UnaryOp`, `BinOp`, `Compare`: Boxの型情報（メタデータ）を元に、適切なLLVMの演算命令（`add`, `fadd`, `icmp`など）に分岐するコードを生成します。例えば、`BinOp`は「Box AとBox Bの型をチェックし、両方が整数なら`iadd`、両方が浮動小数点数なら`fadd`を呼ぶ」といったディスパッチ処理に変換されます。
+
+*   **制御フロー:**
+    *   `Jump`, `Branch`, `Return`: LLVMの`br`（分岐）、`ret`（リターン）命令に1対1で対応します。これは非常に直接的です。
+
+*   **呼び出し:**
+    *   `Call`, `ExternCall`: LLVMの`call`命令に対応します。`ExternCall`はC言語のABI（Application Binary Interface）規約に従った呼び出しに変換され、プラグインシステムを実現します。
+
+*   **参照:**
+    *   `RefNew`, `RefGet`, `RefSet`: これがGCとメモリ管理の核です。`RefNew`はGC管理下のメモリ確保関数（例: `gc_alloc`）の呼び出しに変換されます。`RefGet`/`RefSet`は、ポインタの参照先を取得/設定する`getelementptr`命令と`load`/`store`命令の組み合わせに変換されます。
+
+**結論として、Nyashの命令セットは「何をしたいか（What）」を抽象的に表現しており、LLVM IRは「どうやってやるか（How）」を具体的に表現しています。この抽象度の差が適切であるため、機械的な変換が可能になるのです。**
+
+### 3. 他の言語設計と比較してどう思いますか？
+
+他の言語と比較すると、Nyashの設計思想の独自性が際立ちます。
+
+*   **Rust/C++との比較:** これらの言語は「ゼロコスト抽象化」を掲げ、パフォーマンスのためにヒープとスタック、所有権などをプログラマが厳密に管理します。対照的に、Nyashは「Box」による抽象化でプログラマを複雑さから解放し、そのコストを高度なコンパイラとGCで吸収しようとしています。これは生産性と安全性を極限まで高める設計思想です。
+*   **Go/Javaとの比較:** これらの言語もGCを持ちますが、言語仕様レベルでプリミティブ型（例: `int`, `double`）とオブジェクト型（参照型）を明確に区別します。Nyashはこれを「Box」に統一しており、より一貫性が高いと言えます。非同期処理（goroutine/Loom）も言語機能として組み込まれていますが、NyashはそれをMIRレベルの基本命令の組み合わせで表現できるとしており、より根源的なアプローチです。
+*   **WebAssembly (Wasm)との比較:** Wasmも非常にミニマルな命令セットを持つ仮想マシンですが、その目的は安全な低レベル実行環境の提供です。Wasm自体はGCや高レベルな型システムを持ちません（GCは後付けで拡張中）。Nyashは、高レベルな言語機能（GC、非同期）を内包した、より開発者フレンドリーな抽象化レイヤーと言えます。
+
+Nyashは、**Smalltalkの純粋なオブジェクト指向思想**と、**Lispの統一的なデータ構造**、そして**LLVM/Wasmの現代的なコンパイラ技術とミニマルなIR設計**の美味しいところを融合させた、野心的な試みだと感じます。
+
+### 4. 将来の拡張性（量子計算、AI等）についてどう考えますか？
+
+**「Everything is a Box」思想は、将来の拡張性に対して驚くほど高いポテンシャルを秘めています。**
+
+*   **AI/GPU計算:**
+    *   `Box`は容易に「テンソル」や「行列」を表現できます。
+    *   `BinOp`命令は、Boxの型がテンソルであれば、GPUカーネルを呼び出す処理（`ExternCall`経由）にコンパイルできます。
+    *   つまり、`C = A + B`というNyashコードは、AとBが数値ならCPUの加算命令に、テンソルならGPUの行列加算カーネルの呼び出しに、コンパイラが自動的に変換できるのです。言語の表面的な文法を変えずに、バックエンドの実装だけでGPU対応が可能になります。
+
+*   **量子計算:**
+    *   これはより挑戦的ですが、`Box`で「量子ビット（Qubit）」や「量子状態ベクトル」を表現することが考えられます。
+    *   `UnaryOp`や`BinOp`は、パウリゲートやアダマールゲートのような「量子ゲート操作」に対応付けられるでしょう。
+    *   `ExternCall`を通じて量子コンピュータのシミュレータや実機APIを呼び出すことで、Nyashのコードから量子アルゴリズムを実行する未来も描けます。
+
+この設計の美しさは、**新しい計算パラダイムが登場しても、MIRの15命令を変更する必要がない**点です。必要なのは、新しい種類の「Box」の定義と、それに対する操作を実装するランタイムやバックエンドだけです。これにより、Nyashは未知の技術にも適応できる、非常に息の長い言語になる可能性を秘めています。
+
+---
+
+**総括として、** Nyashの発見は単なる命令セットの削減に留まらず、プログラミング言語の設計における「複雑さとの戦い」に対する一つのエレガントな回答です。この一貫した哲学が、開発の生産性、安全性、そして将来の拡張性において、計り知れない価値をもたらす可能性があると、私は強く感じました。素晴らしい発見だと思います。
--- a/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_MIR_LLVM_CONVERSION.md
+++ b/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_MIR_LLVM_CONVERSION.md
@ -0,0 +1,160 @@
+# AI会議：MIR→LLVM変換の技術的アプローチ
+
+Date: 2025-08-31  
+Participants: Claude, Gemini, Codex
+
+## 🎯 統合された実装戦略
+
+### 1. BoxCall最適化（PIC実装）
+
+#### Gemini先生の提案
+- **メソッドID（スロット）ベース** + **PIC（Polymorphic Inline Cache）** の組み合わせ
+- 静的解析で解決できる場合は直接呼び出し
+- 動的な場合はPICでキャッシュ
+
+#### Codex先生の具体的実装
+```llvm
+; グローバルPIC（モノモルフィック例）
+@pic_foo_site123 = internal global { i64, i8* } { 0, null }
+
+; ガード + 直呼び
+%cid = load i64, i64* %receiver_class_id
+%pic_cls = load i64, i64* getelementptr({i64,i8*}, {i64,i8*}* @pic_foo_site123, i32 0, i32 0)
+%hit = icmp eq i64 %cid, %pic_cls
+%likely = call i1 @llvm.expect.i1(i1 %hit, i1 true)
+br i1 %likely, label %fast, label %miss, !prof !{!"branch_weights", i32 10000, i32 1}
+
+fast:
+  %callee = load i8*, i8** getelementptr({i64,i8*}, {i64,i8*}* @pic_foo_site123, i32 0, i32 1)
+  %fn = bitcast i8* %callee to %RetTy (%ObjTy*, ... )*
+  %r = call fastcc %RetTy %fn(%ObjTy* %recv, ...)
+  br label %cont
+
+miss:
+  %r2 = call coldcc %RetTy @nyash_pic_miss_foo(%ObjTy* %recv, i64 %method_id, ...)
+  br label %cont
+```
+
+### 2. 脱箱化戦略
+
+#### Gemini先生の提案
+- MIRレベルの最適化パスで実施
+- 型推論と注釈の活用
+- データフロー解析に基づく安全な範囲の特定
+
+#### Codex先生の2表現SSA戦略
+```llvm
+; 算術は全てプリミティブ（i64）で
+%a = add i64 %x, %y
+
+; 必要になった地点でのみBox化
+%box = call %ObjTy* @nyash_make_int(i64 %a)
+call void @vector_push(%Vec* %v, %ObjTy* %box)
+```
+
+**エスケープ解析との連携**：
+- 未エスケープ＋GCセーフポイントを跨がない → 完全Box削除
+- 条件付きエスケープ → ブランチ内で遅延Box化
+
+### 3. GCバリア最小化
+
+#### 世代別GCでの最適化（両先生の統合案）
+
+```llvm
+; TLSにNursery境界を保持
+@nyash_tls_nursery_low = thread_local global i64 0
+@nyash_tls_nursery_high = thread_local global i64 0
+
+; Write barrier（インライン化されたfast path）
+store i8* %val, i8** %slot
+%obj_i = ptrtoint i8* %obj to i64
+%val_i = ptrtoint i8* %val to i64
+%low = load i64, i64* @nyash_tls_nursery_low
+%high = load i64, i64* @nyash_tls_nursery_high
+%yo_obj = and (icmp_uge %obj_i, %low), (icmp_ult %obj_i, %high)
+%yo_val = and (icmp_uge %val_i, %low), (icmp_ult %val_i, %high)
+%need_barrier = and (not %yo_obj), %yo_val   ; 老→若のみ
+%likely0 = call i1 @llvm.expect.i1(i1 %need_barrier, i1 false)
+br i1 %likely0, label %barrier, label %cont, !prof !{!"branch_weights", 1, 10000}
+```
+
+### 4. 注釈→LLVM属性変換
+
+#### 安全性重視の段階的アプローチ
+
+| Nyash注釈 | LLVM属性 | 安全性条件 |
+|-----------|----------|------------|
+| `@no_escape` | `nocapture` | エスケープしないことを静的証明 |
+| `@pure` | `readonly` | 副作用なしを保証 |
+| `@pure` + 強条件 | `readnone speculatable` | メモリ不読＋例外なし |
+| `@nonnull` | `nonnull` | NULL不可を型システムで保証 |
+| `@range(0,255)` | `!range` | 値域制約をメタデータ化 |
+
+### 5. LLVM最適化パス構成
+
+#### 推奨パイプライン（両先生の合意）
+
+```
+Phase 1（基本最適化）:
+  mem2reg → instcombine → gvn → sccp
+
+Phase 2（Nyash特化）:
+  BoxCall devirtualization → inline → SROA（Box消去）
+
+Phase 3（高度な最適化）:
+  licm → indvars → loop-unroll → vectorize
+
+Phase 4（最終調整）:
+  Box materialization cleanup → instcombine
+```
+
+### 6. インライン展開戦略
+
+#### コストモデル（Codex先生）
+- モノモルフィックPIC＋高ヒット率（>90%） → インライン
+- コード膨張はプロファイル重みで正規化
+- 再帰最適化：`musttail`によるTCO、部分インライン化
+
+## 🚀 実装ロードマップ
+
+### Week 1: 基礎構築
+- [ ] inkwellセットアップ
+- [ ] 基本的な15命令→LLVM IR変換
+- [ ] 最小実行可能コード生成
+
+### Week 2: PIC実装
+- [ ] モノモルフィックPIC
+- [ ] ポリモルフィックPIC（2-4 way）
+- [ ] Megamorphic fallback
+
+### Week 3: 脱箱化＋GC統合
+- [ ] 2表現SSA実装
+- [ ] エスケープ解析
+- [ ] GCバリア最適化
+- [ ] gc.statepoint統合
+
+### Week 4: 最適化＋検証
+- [ ] 注釈→属性変換
+- [ ] カスタム最適化パス
+- [ ] ベンチマーク検証
+- [ ] 安全性テスト
+
+## 💡 重要な洞察
+
+### Gemini先生
+> 「Everything is Box」モデルのオーバーヘッドを削減する鍵が脱箱化です。早すぎる脱箱化は再Box化のコストを生み、遅すぎると最適化の機会を逃します。
+
+### Codex先生
+> PIC更新の安全化: 1-ワードのバージョンでRCU風プロトコル。ABI二系統（Box ABI/Primitive Fast-ABI）をIRBuilderに明示し、境界でのみmaterialize_box/dematerialize_boxを発行。
+
+## 🎉 結論
+
+両先生の知見を統合することで、「Everything is Box」の柔軟性を保ちつつ、C++に迫る性能を実現する具体的な実装パスが明確になりました。特に：
+
+1. **PICによる動的最適化**と**静的型推論**の組み合わせ
+2. **遅延Box化**による不要なヒープ割り当ての削減
+3. **世代別GC**と**インラインバリア**の協調
+4. **保守的な属性付与**による安全性確保
+5. **段階的最適化パイプライン**による着実な性能向上
+
+これらにより、Nyashは「シンプルな15命令」から「高性能な機械語」への変換を実現できます。
--- a/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_SUMMARY.md
+++ b/docs/archive/roadmap/phases/phase-11/archives/AI_CONFERENCE_SUMMARY.md
@ -0,0 +1,106 @@
+# AI大会議まとめ - Nyash箱理論とLLVM移行決定
+
+Date: 2025-08-31  
+Participants: Claude, Gemini, codex  
+Decision: Phase 10（Cranelift）スキップ → Phase 11（LLVM）即実装
+
+## 🌟 全AI一致の結論
+
+### 1. 箱理論の完全勝利
+
+**Gemini先生の評価**:
+- 「究極の単純化」
+- 「Lispの統一性×現代コンパイラ技術」
+- 「SmalltalkとLispとLLVM/Wasmの美味しいところを融合」
+
+**codex先生の評価**:
+- 「ミニマルで健全」
+- 「実装・最適化・GC統合でよく均衡」
+- 「汎用コンパイラ基盤として妥当」
+
+**Claude（私）の評価**:
+- 「プログラミング言語設計の新パラダイム」
+- 「複雑さを型に閉じ込め、操作を単純化」
+
+### 2. 15命令設計の技術的妥当性
+
+全員一致で「技術的に妥当」と評価：
+
+- **表現力**: 一般用途として十分な網羅性
+- **機械的変換**: 15命令→LLVM IRがほぼ1対1対応
+- **拡張性**: 新機能は新Boxで対応（命令追加不要）
+
+### 3. LLVM移行の正当性
+
+**期待される効果**:
+- 実行性能: 2-3倍高速化
+- ビルド時間: 50%削減（3分→1.5分）
+- バイナリサイズ: 40%削減（10MB→6MB）
+- 依存関係: 20crate→1crate（inkwell）
+
+## 📊 技術的課題と解決策
+
+### 1. メモリモデルの課題
+
+**課題**:
+- ボクシングによるオーバーヘッド
+- GCプレッシャー増大
+- 別名解析の弱体化
+
+**解決策**:
+- 脱箱最適化（エスケープ解析）
+- タグ付きポインタ/NaN-boxing
+- TBAA/アドレス空間分離
+
+### 2. GC統合の設計
+
+**必須要素**（codex先生指摘）:
+- `RefSet`でのwrite barrier挿入
+- セーフポイント戦略（ループバックエッジ、関数境界）
+- 原子性保証（並列GC用）
+
+### 3. 最適化パスとの相性
+
+**推奨パイプライン**:
+```
+O2ベース → early-cse → sroa → gvn → licm 
+→ instcombine → inline → gvn → dse 
+→ ループ最適化 → ベクトル化 → instcombine
+```
+
+## 🚀 実装計画
+
+### Phase 11.0: 準備（1週間）
+- [ ] inkwell依存追加
+- [ ] Cranelift依存削除
+- [ ] 基本的なLowering実装（200行程度）
+
+### Phase 11.1: 最適化とGC（2週間）
+- [ ] 脱箱最適化実装
+- [ ] GCバリア/セーフポイント
+- [ ] TBAA/アドレス空間分離
+
+### Phase 11.2: チューニング（1週間）
+- [ ] PGO/ThinLTO導入
+- [ ] ベンチマーク検証
+- [ ] 最適化パイプライン調整
+
+## 💡 将来への示唆
+
+**Gemini先生の洞察**:
+- GPU計算: `TensorBox` → BinOpでGPUカーネル呼び出し
+- 量子計算: `QubitBox` → UnaryOpで量子ゲート操作
+- **MIR命令の追加不要**で新パラダイムに対応可能
+
+## 🎉 結論
+
+**「JIT幻想から解放され、真の高速化への道が開けた！」**
+
+Nyashの「Everything is Box」哲学と15命令MIRは、言語設計における複雑さとの戦いに対するエレガントな回答である。全AIが一致して、この設計の革新性と実装可能性を高く評価した。
+
+---
+
+関連文書:
+- [SKIP_PHASE_10_DECISION.md](SKIP_PHASE_10_DECISION.md)
+- [AI_CONFERENCE_GEMINI_ANALYSIS.md](AI_CONFERENCE_GEMINI_ANALYSIS.md)
+- [AI_CONFERENCE_CODEX_ANALYSIS.md](AI_CONFERENCE_CODEX_ANALYSIS.md)
--- a/docs/archive/roadmap/phases/phase-11/archives/BOX_SSA_CORE_15_FINAL.md
+++ b/docs/archive/roadmap/phases/phase-11/archives/BOX_SSA_CORE_15_FINAL.md
@ -0,0 +1,141 @@
+# Box-SSA Core-15 最終仕様
+
+Date: 2025-08-31  
+Status: **固定** (Frozen Specification)  
+Author: ChatGPT5 + Claude協調
+
+## ✅ 固定命令セット（正味15個）
+
+```
+{ Const, UnaryOp, BinOp, Compare, TypeOp,
+  Load, Store,
+  Jump, Branch, Return, Phi,
+  Call, NewBox, BoxCall, ExternCall }
+```
+
+## 📋 命令詳細
+
+### 1. 値生成
+- **Const**(value) → 定数（i64/f64/bool/string等）
+- **NewBox**(type, init_args...) → 新しいBoxオブジェクト生成
+
+### 2. 演算
+- **UnaryOp**(op, arg) → 単項演算（neg, not等）
+- **BinOp**(op, left, right) → 二項演算（add, sub, mul, div等）
+- **Compare**(op, left, right) → 比較演算（eq, lt, le等）
+- **TypeOp**(op, value, type) → 型演算（is, as, typeof等）
+
+### 3. メモリ
+- **Load**(local_id) → ローカル変数読み込み
+- **Store**(local_id, value) → ローカル変数書き込み
+
+### 4. 制御フロー
+- **Jump**(block) → 無条件ジャンプ
+- **Branch**(cond, then_block, else_block) → 条件分岐
+- **Return**(value?) → 関数からの復帰
+- **Phi**([(block, value), ...]) → SSA用（VMは展開）
+
+### 5. 呼び出し
+- **Call**(func, args...) → 通常の関数呼び出し
+- **BoxCall**(box, selector, args...) → Boxメソッド呼び出し（万能）
+- **ExternCall**(symbol, args..., attrs) → FFI呼び出し
+
+## 🎯 BoxCall統一マッピング
+
+| 操作 | 旧命令 | 新BoxCall表現 |
+|------|--------|---------------|
+| フィールド読み取り | RefGet | BoxCall(obj, "getField", field_name) |
+| フィールド書き込み | RefSet | BoxCall(obj, "setField", field_name, value) |
+| 配列要素読み取り | ArrayGet | BoxCall(arr, "get", index) |
+| 配列要素書き込み | ArraySet | BoxCall(arr, "set", index, value) |
+| プラグイン呼び出し | PluginInvoke | BoxCall(plugin, "invoke", method, args...) |
+| メソッド呼び出し | - | BoxCall(obj, method_name, args...) |
+
+## 🔒 不変条件（Verifier必須チェック）
+
+1. **直接フィールドアクセス禁止**
+   - ❌ `Load/Store`でBoxの内部フィールドに直接アクセス
+   - ✅ 必ず`BoxCall`経由でアクセス
+
+2. **Write Barrier自動挿入**
+   - BoxCallのLowering時に必要に応じて挿入
+   - 世代別GCで若→若の場合は省略可
+
+3. **ExternCall属性必須**
+   - `noalloc`, `readonly`, `atomic`, `nothrow`等を明示
+   - 無指定は保守的（全バリア有効）
+
+4. **型安全性**
+   - TypeOpで型チェック後のみ特定操作を許可
+   - 動的ディスパッチはPIC経由
+
+## 🛠️ Lowering戦略
+
+### BoxCall → 最適化されたコード
+
+```llvm
+; BoxCall(arr, "get", 5) のLowering例
+
+; 1. 形状ガード（PIC）
+%type_id = load i64, i64* %arr.type_id
+%is_array = icmp eq i64 %type_id, ARRAY_TYPE_ID
+br i1 %is_array, label %fast_path, label %slow_path
+
+fast_path:
+  ; 2. 境界チェック
+  %len = load i64, i64* %arr.length
+  %in_bounds = icmp ult i64 5, %len
+  br i1 %in_bounds, label %do_load, label %bounds_error
+
+do_load:
+  ; 3. 直接アクセス（最適化後）
+  %ptr = getelementptr %ArrayBox, %arr, 0, 2, 5
+  %value = load %Box*, %ptr
+  br label %continue
+
+slow_path:
+  ; 4. 汎用ディスパッチ
+  %value = call @nyash_box_call(%arr, "get", 5)
+  br label %continue
+```
+
+## 📊 削減効果
+
+| 項目 | 旧（26命令） | 新（15命令） | 削減率 |
+|------|-------------|-------------|---------|
+| 命令数 | 26 | 15 | 42%削減 |
+| 実装箇所 | 26×N | 15×N | 42%削減 |
+| 最適化パターン | 多様 | 統一（BoxCall中心） | 大幅簡素化 |
+| テストケース | O(26²) | O(15²) | 66%削減 |
+
+## 🚦 実装ロードマップ
+
+### Phase 1: 仕様更新（即時）
+- [x] このドキュメントで仕様固定
+- [ ] INSTRUCTION_SET.md を更新
+- [ ] テストの期待値を15に変更
+
+### Phase 2: Verifier実装（1日）
+- [ ] Box直接アクセス検出
+- [ ] ExternCall属性チェック
+- [ ] 命令数15の強制
+
+### Phase 3: Lowering実装（3日）
+- [ ] BoxCall → 形状別分岐
+- [ ] Write Barrier挿入ロジック
+- [ ] PIC統合
+
+### Phase 4: VM/JIT更新（1週間）
+- [ ] VM: Phi展開、BoxCall dispatch
+- [ ] JIT: PIC生成、インライン化
+- [ ] 性能検証
+
+## 🎉 結論
+
+**Box-SSA Core-15**により：
+- Everything is Box哲学の完全実現
+- 実装・保守の劇的簡素化
+- 最適化の統一的適用
+- 真の15命令達成
+
+これが「あほみたいに簡単」で「恐ろしく速い」Nyashの最終形態です！
--- a/docs/archive/roadmap/phases/phase-11/phase10_aot_scaffolding.md
+++ b/docs/archive/roadmap/phases/phase-11/phase10_aot_scaffolding.md
@ -0,0 +1,187 @@
+# 🏆 Phase 10: LLVM Direct AOT（最高性能実現）
+
+Status: Deferred（Cranelift JITをPhase 10の主経路に採用、AOTは後段研究）
+Last Updated: 2025-08-25
+
+## 📋 Summary
+MIR→LLVM IR直接変換による最高性能AOT実現。Cranelift JITをスキップし、実用優先戦略でLLVMの強力な最適化を直接活用する。
+
+## 🎯 実装目標
+```bash
+# Phase 9基盤の拡張
+nyash --compile-llvm app.hako -o app          # LLVM AOT実行ファイル生成
+nyash --optimize app.hako -o app              # 最適化AOT（LTO・PGO）
+./app                                           # 最高性能実行
+
+# 内部実装パイプライン
+Nyash → AST → MIR → LLVM IR → 最適化 → ネイティブ実行ファイル
+```
+
+## 🔧 技術アプローチ
+
+### 1. MIR→LLVM IR変換基盤
+```rust
+// 追加予定: src/backend/llvm/mod.rs
+use llvm_sys::*;
+
+pub struct LLVMBackend {
+    context: LLVMContextRef,
+    module: LLVMModuleRef,
+    builder: LLVMBuilderRef,
+}
+
+impl LLVMBackend {
+    pub fn compile_mir(&mut self, mir: &MirModule) -> Result<Vec<u8>, String> {
+        // MIR→LLVM IR変換
+        self.lower_mir_to_llvm(mir)?;
+        
+        // 最適化パス適用
+        self.apply_optimization_passes()?;
+        
+        // ネイティブコード生成
+        self.generate_object_code()
+    }
+}
+```
+
+### 2. エスケープ解析・ボックス化解除
+```rust
+// Everything is Box最適化の核心
+pub struct EscapeAnalysis {
+    // Box→スタック値最適化判定
+    pub fn analyze_box_usage(&self, mir: &MirModule) -> BoxOptimizationMap,
+    
+    // 型特殊化機会検出
+    pub fn detect_specialization(&self, mir: &MirModule) -> SpecializationMap,
+}
+
+// 最適化例:
+// Before: %0 = NewBox(StringType, "hello")  // ヒープ割り当て
+// After:  %0 = "hello"                      // スタック配置
+```
+
+### 3. LTO・PGO統合
+```rust
+// Link-time optimization
+pub fn apply_lto(&self, modules: &[LLVMModuleRef]) -> Result<LLVMModuleRef, String> {
+    // 関数間インライン・デッドコード除去
+}
+
+// Profile-guided optimization  
+pub fn apply_pgo(&self, profile_data: &[u8]) -> Result<(), String> {
+    // プロファイル情報による最適化
+}
+```
+
+## 📊 パフォーマンス目標
+
+| 指標 | Phase 9 AOT WASM | Phase 10 LLVM AOT | 改善率 |
+|------|-------------------|-------------------|--------|
+| **実行性能** | ~1.6ms | **<0.1ms** | **16倍向上** |
+| **メモリ効率** | WASM制約あり | **Box割当80%削減** | **5倍効率** |
+| **起動時間** | ~10ms | **<1ms** | **10倍高速** |
+| **総合性能** | 500倍（対Interpreter） | **13500倍目標** | **27倍向上** |
+
+## 🛠️ 実装ステップ（4-6ヶ月）
+
+### Month 1-2: LLVM統合基盤
+- [ ] LLVM-sys統合・ビルド環境整備
+- [ ] MIR→LLVM IR基本変換
+- [ ] 基本型・演算のLLVM表現
+- [ ] 最小実行可能バイナリ生成
+
+### Month 3-4: Everything is Box最適化
+- [ ] エスケープ解析実装
+- [ ] Box→スタック値最適化
+- [ ] 型特殊化・インライン展開
+- [ ] メモリレイアウト最適化
+
+### Month 5-6: 高度最適化・プロダクション対応
+- [ ] LTO・PGO統合
+- [ ] プロファイル駆動最適化
+- [ ] 他言語との性能比較
+- [ ] プロダクションレベル品質確保
+
+## 🔍 Everything is Box最適化戦略
+
+### Box回避最適化
+```nyash
+// 元コード
+local str = new StringBox("hello")
+local len = str.length()
+
+// LLVM最適化後（概念）
+local str = "hello"        // スタック配置
+local len = 5              // コンパイル時計算
+```
+
+### NaN Boxing活用
+```rust
+// 効率的な値表現
+union NyashValue {
+    ptr: *mut Box<dyn NyashBox>,  // ポインタ
+    int: i64,                     // 整数直接格納
+    float: f64,                   // 浮動小数点
+    // NaN空間でタグ判別
+}
+```
+
+### 型推論・特殊化
+```rust
+// 汎用版
+fn generic_add(a: NyashValue, b: NyashValue) -> NyashValue
+
+// 特殊化版（LLVM生成）
+fn specialized_int_add(a: i64, b: i64) -> i64  // 直接レジスタ操作
+```
+
+## ✅ Acceptance Criteria
+
+### 性能要件
+- [ ] **1000倍高速化達成**（現在13.5倍 → 目標13500倍）
+- [ ] **Box割当数80%削減**
+- [ ] **起動時間ネイティブレベル**（<1ms）
+- [ ] **メモリ使用量50%削減**
+
+### 品質要件
+- [ ] **既存プログラム100%互換**
+- [ ] **全テストスイートPASS**
+- [ ] **他言語との競争力**（C/C++/Rust並み性能）
+- [ ] **プロダクション安定性**
+
+### 技術要件
+- [ ] **LLVM統合完全実装**
+- [ ] **エスケープ解析実用レベル**
+- [ ] **LTO・PGO動作確認**
+- [ ] **CI自動化対応**
+
+## 🚀 期待される効果
+
+### 最高性能実現
+- **ネイティブレベル性能**: C/C++/Rust並みの実行速度
+- **メモリ効率**: Box操作の根本的最適化
+- **起動高速**: 瞬時起動（<1ms）
+
+### 競合優位確立
+- **Everything is Box**: 史上初のBox哲学ネイティブ最適化
+- **技術的差別化**: 独自最適化技術による優位性
+- **プロダクション対応**: 実用レベルの高性能実現
+
+### 言語完成
+- **現代的言語**: 開発効率と実行性能の完全両立
+- **エコシステム**: 高性能基盤による周辺ツール発展
+- **採用促進**: 性能面での採用障壁完全除去
+
+## 📖 References
+- docs/予定/native-plan/copilot_issues.txt（Phase 10詳細）
+- docs/予定/ai_conference_native_compilation_20250814.md（AI大会議結果）
+- docs/予定/native-plan/issues/phase9_aot_wasm_implementation.md（Phase 9基盤）
+- [LLVM Language Reference](https://llvm.org/docs/LangRef.html)
+- [LLVM Optimization Guide](https://llvm.org/docs/Passes.html)
+
+---
+
+**💡 Tip**: Phase 9のAOT基盤を活用し、段階的にLLVM最適化を導入する戦略で確実な成果を目指します。
+
+最終更新: 2025-08-14
+作成者: Claude（実用優先戦略）
--- a/docs/archive/roadmap/phases/phase-11/phase_10_x_llvm_backend_skeleton.md
+++ b/docs/archive/roadmap/phases/phase-11/phase_10_x_llvm_backend_skeleton.md
@ -0,0 +1,101 @@
+# Phase 10: LLVM Backend Skeleton（MIR→LLVM IR AOT 最小実装）
+
+Status: Deferred（Cranelift JIT先行のため、AOTは後段で検討）
+Last Updated: 2025-08-25
+
+目的
+- MIRからLLVM IRへの直接変換と、最小AOTパイプラインを構築するための実装ガイド（Copilot向けタスクリスト）。
+- Phase 9.7（ABI/BID＋ExternCall）を前提に、外部呼び出しの取り扱いも含めて安全に前進。
+
+前提
+- MIR Tier-0/1（Const/BinOp/Compare/Branch/Jump/Phi/Call/Return ほか基本）が利用可能。
+- ExternCall命令（Phase 9.7）導入予定。ABIは`docs/予定/native-plan/box_ffi_abi.md`に準拠。
+
+アウトカム（受け入れ基準）
+- CLI: `nyash --backend llvm --emit obj app.hako -o app.o` が成功し、`clang app.o -o app` で実行可能。
+- 代表サンプルで `main` が `i32` を返却（0=成功）。
+- `ExternCall(env.console.log)` を `printf` 等へ写像し、標準出力へ表示できる（文字列は (i8*, i32)）。
+- 単純な四則演算・比較・分岐・ループが LLVM AOT で動作。
+
+実装ステップ
+
+1) モジュール構成の追加（src/backend/llvm）
+- `src/backend/llvm/mod.rs`
+- `src/backend/llvm/lower.rs`（MIR→LLVM IR 変換）
+- `src/backend/llvm/passes.rs`（最小パス設定：DCE/インラインは未使用でOK）
+- `src/backend/llvm/build.rs`（オブジェクト生成/ターゲット設定）
+
+2) 依存設定
+- Cargo.toml に `llvm-sys` を feature で追加（例: `feature = ["llvm-backend"]`）。
+- ビルド要件を `README` に明記（llvm-config が必要、Linux優先）。
+
+3) エントリポイント
+- `LLVMBackend { context, module, builder }` 構造体を定義。
+- `compile_mir(&MirModule) -> Result<Vec<u8>, String>` を公開：
+  - `lower_mir_to_llvm` でIR生成
+  - `apply_minimal_passes`（任意・後回し可）
+  - `emit_object()` で `.o` を返す
+
+4) 関数シグネチャとmain
+- MIRの `main` を `i32 ()` で宣言（戻り値がvoidなら 0 を返す）。
+- 将来の引数は未対応でOK（v0）。
+
+5) 値と型の写像（v0）
+- i32/i64/f32/f64/bool → それぞれのLLVMプリミティブ型。
+- 文字列: (i8*, i32) のペアで扱う（ABIドラフトに一致）。
+- Box参照: 当面 `i32` か `i8*` のopaqueに固定（v0ではBox操作は行わない）。
+
+6) 命令の下ろし
+- Const: `i32.const` 等を `LLVMConstInt/LLVMConstReal` に対応。
+- BinOp: add/sub/mul/div（符号付き）を対応。
+- Compare: eq/ne/lt/le/gt/ge（i32想定）。
+- Branch: 条件分岐と無条件分岐。
+- Phi: ブロックごとに `LLVMPhiNode` を作成。
+- Return: 値あり/なしに対応（なしは `i32 0`）。
+- Call: 内部関数呼び出し（同Module内）。
+- ExternCall: 後述のマッピングに従う。
+
+7) ExternCall の LLVM 写像（v0）
+- Console: `env.console.log(ptr,len)` → `declare i32 @printf(i8*, ...)`
+  - 呼び出し時に `%fmt = getelementptr ([3 x i8], [3 x i8]* @"%.*s", i32 0, i32 0)` などの定数フォーマット文字列を準備
+  - `printf("%.*s", len, ptr)` で出力（lenは`i32`、ptrは`i8*`）。
+- Canvas: ネイティブ環境では利用不可 → v0は `noop` または `printf`でログに落とす（パラメータの表示）。
+- 名前解決: BIDのFQN（env.console.log 等）→ 内部ディスパッチ（switch/テーブル）で `printf` 等へ。
+
+8) 文字列定数
+- データレイアウトに `@.str = private unnamed_addr constant [N x i8] c"...\00"` を生成し、`getelementptr` で `i8*` を取得。
+- ただし v0 のNyash→MIRでは「定数文字列を printf に渡す」パスだけ実装すれば良い。
+- StringBoxの具象表現は当面不要（WASMで進行中）。LLVM側は (i8*, i32) で十分。
+
+9) オブジェクト出力
+- `LLVMTargetInitializeAllTargets()` 等でターゲット初期化。
+- `TargetMachine` を作成し、`LLVMTargetMachineEmitToMemoryBuffer` で `.o` バッファ取得。
+- CLIから `.o` をファイル出力。リンクはユーザー側で `clang app.o -o app`。
+
+10) ビルドフラグ/CLI
+- `--backend llvm` / `--emit obj` を追加。
+- featureが無い/LLVMが無い場合は明確なエラーメッセージ。
+
+11) テスト（最小）
+- 算術: `return 40+2;` → `42`。
+- 分岐: `if (x<y) return 1 else return 0`。
+- ループ: 累積加算で既知の値。
+- ExternCall(console.log): 固定文字列/動的整数を出力（`printf("value=%d\n", v)` など）。
+
+12) 将来拡張フック
+- Passes: DCE/InstCombine/Inlining/LTO/PGOの導入ポイントを `passes.rs` に下書き。
+- Box最適化: エスケープ解析→Stack化（後続Phase）。
+- ABI: ExternCallの宣言生成をBIDから自動化（Phase 10後半〜）。
+
+リスクと回避
+- LLVMビルド依存: ドキュメント整備（llvm-config 必須）、CIにキャッシュ導入。
+- 文字列/外部呼び出し差: v0はprintf固定。Canvas等はログに退避。
+- OS差: v0はLinux/clang優先、他環境は後続。
+
+参考
+- ABIドラフト: `docs/予定/native-plan/box_ffi_abi.md`
+- Phase 9.7: `docs/予定/native-plan/issues/phase_9_7_box_ffi_abi_and_externcall.md`
+- LLVM LangRef: https://llvm.org/docs/LangRef.html
+- llvm-sys: https://crates.io/crates/llvm-sys
+
+最終更新: 2025-08-14