Files

Tomoaki d62114c705 Core-13 pure: add CI workflows, VM e2e tests, LLVM parity bridge (minimal); do not touch private docs

2025-09-07 07:28:53 +09:00

6.4 KiB

Raw Blame History

Box Theory Acceleration: ChatGPT5 JIT Development Case Study

Date: 2025-08-29 Context: Phase 10.7 JIT Development with ChatGPT5 Collaboration

Executive Summary

箱理論（Box-First Development）の適用により、複雑なJIT開発が劇的に加速した事例。ChatGPT5との協調開発において、「箱にして」という指示により作戦が根本的に変わり、開発が前進した。

1. 問題状況

Before: JIT開発の行き詰まり

Codex（ChatGPT5）がJIT実装で苦戦
複雑な相互依存により方向性を見失う
VM、GC、ランタイムとの密結合が問題

Intervention: 「箱にして」

ユーザー: 「JITの処理を最適化を後にして箱にして」

2. 箱理論による変革

2.1 Phase 10.7の構造化

ChatGPT5が提示した箱化戦略：

- 10.7a: 最小PHI/分岐配線/独立ABI/フォールバック/観測性の確立
- 10.7b: PHI一般化（多値）＋ブロック引数APIの正式化と実装安定化
- 10.7c: Hostハンドルレジストリ導入（u64↔Arc<dyn NyashBox>）でJIT↔ホスト独立化
- 10.7d: 副作用境界の方針整理と安全なHostCall拡張（read-only中心）
- 10.7e: CFG診断とDOT出力（ブロック引数/PHIの可視化）
- 10.7f: JitConfigBoxで設定の箱集約（env/CLI/テスト一元化）
- 10.7g: 安定化・ゴールデンテスト・ベンチ・フォールバック率監視
- 10.7h: ネイティブABIの型拡張（f64/boolの入出力・b1活用）

2.2 効果の詳細分析

独立ABI

Before: JITがVMValueに直接依存
After: JitValue(i64/f64/bool/handle)で独立、境界変換のみに集約

HostCall疎結合

Before: JITがBox実体を直接操作
After: ハンドルレジストリ(u64↔Arc)でJITはPOD+Handleのみ参照

安全なフォールバック

Before: JIT内部のpanicがVM全体をクラッシュ
After: catch_unwindでVMへ安全にフォールバック

設定の一元化

Before: 環境変数の直接参照が散在
After: JitConfigBoxに集約、ホットパスでenv直読みを排除

3. AI協調開発の新パラダイム

3.1 箱理論がAIの制約を克服

コンテキスト制限への対応
- 箱単位なら各AIが完全に理解可能
- 複雑な全体像を保持する必要がない
方向転換の困難さへの対応
- 箱なら簡単に差し替え・ロールバック可能
- 「戻せる足場」が恐怖を取り除く
複数AI間の協調
- 明確な境界により、各AIが担当箱を独立実装
- インターフェースが安定していれば並行作業可能

3.2 Claude.mdへの反映

ChatGPT5が作成したClaude.md更新：

## 🧱 先頭原則: 「箱理論（Box-First）」で足場を積む

- 基本姿勢: 「まず箱に切り出す」→「境界をはっきりさせる」→「差し替え可能にする」
- 環境依存や一時的なフラグは、可能な限り「箱経由」に集約（例: JitConfigBox）
- VM/JIT/GC/スケジューラは箱化されたAPI越しに連携（直参照・直結合を避ける）
- いつでも戻せる: 機能フラグ・スコープ限定・デフォルトオフを活用し、破壊的変更を避ける
- AI補助時の注意: 「力づく最適化」を抑え、まず箱で境界を確立→小さく通す→可視化→次の一手

4. 実装の具体例

4.1 JitConfigBox

// Before: 散在する環境変数チェック
if std::env::var("NYASH_JIT_PHI_MIN").is_ok() { ... }

// After: 箱経由の統一アクセス
let config = jit::config::current();
if config.phi_min { ... }

4.2 HandleRegistry

// 箱化されたハンドル管理
pub struct HandleRegistry {
    handles: RwLock<HashMap<u64, Arc<dyn NyashBox>>>,
    next_id: AtomicU64,
}

// JITは具体的なBoxを知らない
pub fn register_handle(box_ref: Arc<dyn NyashBox>) -> u64 {
    // 実装...
}

5. AI間連携の箱化提案

ChatGPT5からの箱化されたAI連携アーキテクチャ：

graph LR
    A[Codex] -->|停止検出| B[DetectionBox]
    B -->|フィルタ| C[FilterBox]
    C -->|転送判断| D[BridgeBox]
    D -->|API| E[Claude]
    E -->|応答| F[ResponseBox]
    F -->|送信| A

各箱の責務が明確：

DetectionBox: Codexの出力停止パターン検出
FilterBox: セキュリティ・安全性チェック
BridgeBox: 転送制御とレート制限
ResponseBox: 応答の整形とCodex向け変換

6. 成果と学び

6.1 定量的成果

JIT開発の停滞 → Phase 10.7の8段階構造化で前進
環境変数散在 → JitConfigBox一元化
VM依存 → 独立ABI確立

6.2 定性的成果

「箱にする」という単純な指示で開発方針が転換
AIが理解しやすい粒度への分解に成功
複雑性の管理が可能になった

7. 理論的含意

7.1 複雑性の線形化

JIT開発の指数関数的複雑性 → 箱の線形結合へ変換
相互依存の網 → 単方向の境界変換へ簡略化

7.2 心理的安全性

「壊れたらどうしよう」→「この箱だけ戻せばOK」
「全部理解しないと」→「この箱だけ理解すればOK」

7.3 AI時代の開発方法論

人間の抽象化能力 + AIの実装能力の最適な組み合わせ
箱という共通言語による効率的なコミュニケーション

8. 今後の展開

Phase 10.9への適用計画

ChatGPT5の提案：

必要な箱（最小セット）:
- JitPolicyBox: read-only/HostCall許可の一本化
- JitEventsBox: compile/execute/fallback/trapのJSONLイベント
- HostcallRegistryBox: 許可HostCallと型検査の単一点
- FrameSlotsBox: ptr→slot管理（当面i64）
- CallBoundaryBox: JIT↔JIT/JIT↔VM呼出しの薄い境界

9. 結論

箱理論は単なる設計パターンを超えて、AI協調開発における共通言語・思考フレームワークとして機能している。「箱にして」という指示が、行き詰まっていたJIT開発を劇的に加速させた事実は、AI時代の新しい開発方法論の可能性を示唆している。

Related Documents:

6.4 KiB Raw Blame History Unescape Escape