184 lines
6.4 KiB
Markdown
184 lines
6.4 KiB
Markdown
# 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の制約を克服
|
||
|
||
1. **コンテキスト制限への対応**
|
||
- 箱単位なら各AIが完全に理解可能
|
||
- 複雑な全体像を保持する必要がない
|
||
|
||
2. **方向転換の困難さへの対応**
|
||
- 箱なら簡単に差し替え・ロールバック可能
|
||
- 「戻せる足場」が恐怖を取り除く
|
||
|
||
3. **複数AI間の協調**
|
||
- 明確な境界により、各AIが担当箱を独立実装
|
||
- インターフェースが安定していれば並行作業可能
|
||
|
||
### 3.2 Claude.mdへの反映
|
||
|
||
ChatGPT5が作成したClaude.md更新：
|
||
|
||
```markdown
|
||
## 🧱 先頭原則: 「箱理論（Box-First）」で足場を積む
|
||
|
||
- 基本姿勢: 「まず箱に切り出す」→「境界をはっきりさせる」→「差し替え可能にする」
|
||
- 環境依存や一時的なフラグは、可能な限り「箱経由」に集約（例: JitConfigBox）
|
||
- VM/JIT/GC/スケジューラは箱化されたAPI越しに連携（直参照・直結合を避ける）
|
||
- いつでも戻せる: 機能フラグ・スコープ限定・デフォルトオフを活用し、破壊的変更を避ける
|
||
- AI補助時の注意: 「力づく最適化」を抑え、まず箱で境界を確立→小さく通す→可視化→次の一手
|
||
```
|
||
|
||
## 4. 実装の具体例
|
||
|
||
### 4.1 JitConfigBox
|
||
|
||
```rust
|
||
// Before: 散在する環境変数チェック
|
||
if std::env::var("NYASH_JIT_PHI_MIN").is_ok() { ... }
|
||
|
||
// After: 箱経由の統一アクセス
|
||
let config = jit::config::current();
|
||
if config.phi_min { ... }
|
||
```
|
||
|
||
### 4.2 HandleRegistry
|
||
|
||
```rust
|
||
// 箱化されたハンドル管理
|
||
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**:
|
||
- [Box Theory Principles](../shared/box-theory-principles.md)
|
||
- [AI Dual Mode Development](../../../ai-dual-mode-development/README.md)
|
||
- [JIT Design Paper](./README.md) |