THEORY.md
# 導出的創造 理論
## 核心
```
定義が正しければ、コードは導出される。
バグは「定義の誤り」か「導出の誤り」しかない。
両方を構造的に防げば、バグはゼロになる。
```
---
## 6層アーキテクチャ
```
Layer -1: 複雑性分析層
↓ 何を作るか、どの程度複雑か
Layer 0: 意図結晶化層
↓ 曖昧 → 明確
Layer 1: 定義導出層
↓ 契約 → コード
Layer 2: 継続検証層
↓ 常に整合性を確認
Layer 3: 自己修復層
↓ 不整合を自動検出・修正
Layer 4: 定義深化層
↓ 不足を発見、契約を更新
```
---
## 複雑性理論
### 3軸
| 軸 | 低 | 高 |
| :----- | :--------------- | :------------------------- |
| 閉鎖性 | 外部連携なし | API、DB、外部サービス |
| 静的性 | 状態単純 | 動的スキーマ、リアルタイム |
| 単独性 | シングルユーザー | マルチユーザー、権限 |
### 5 Tier
| Tier | 特徴 | 契約階層 | 期間 |
| :--- | :------------ | :------------------------ | :--- |
| 1 | 閉×静×単 | Vision→Module→Function | 時間 |
| 2 | 閉×動×単 | Vision→Module→Function | 日 |
| 3 | 開×動×協 | +Domain, External, Sync | 週 |
| 4 | 開×動×協+メタ | +Meta, Permission, Tenant | 月 |
| 5 | 開×動×進化 | +Evolution, Plugin | 6月+ |
---
## 契約の原理
### 契約とは
```
「何を作るか」の合意文書。
コードの前に存在する。
コードは契約から導出される。
```
### 契約階層
```
Vision Contract
「なぜ作るか」「何のために」
Domain Contract
「どの領域を担当するか」「境界は」
Meta Contract（Tier 4+）
「ユーザーは何を定義できるか」
Module Contract
「どの部品か」「責務は」
Function Contract
「何をするか」「入力は」「出力は」「エラーは」
```
### 契約の検証
```
契約は検証可能でなければならない。
✓ 「ユーザーを作成できる」→ テスト可能
✗ 「使いやすい」→ 曖昧、テスト不能
曖昧な契約 → 曖昧な実装 → バグ
明確な契約 → 明確な実装 → バグゼロ
```
---
## 導出の原理
### 導出とは
```
契約からコードへの構造的変換。
創造性は不要。機械的な変換。
Contract → Type → Interface → Implementation → Test
```
### 導出ルール
```typescript
// 契約
// User: id(UUID), email(検証済み), role(admin/user/guest)
// → 型に導出
type UserId = string & { readonly __brand: 'UserId' };
type Email = string & { readonly __brand: 'Email' };
type Role = 'admin' | 'user' | 'guest';
interface User {
readonly id: UserId;
readonly email: Email;
readonly role: Role;
}
// → インターフェースに導出
interface UserService {
create(email: Email, role: Role): Promise>;
findById(id: UserId): Promise>;
}
// → テストに導出
describe('UserService.create', () => {
it('有効なemail, roleでユーザーが作成される', ...);
it('無効なemailでエラー', ...);
it('重複emailでエラー', ...);
});
```
---
## 深化の原理
### 深化とは
```
契約の不足を発見し、更新すること。
検証 → 問題発見 → 契約更新 → 再導出 → 再検証
```
### 深化のトリガー
1. **暗黙の仮定**: 契約に明示されていない前提
2. **境界条件**: エッジケースの未定義
3. **ドメイン矛盾**: 契約間の不整合
4. **非機能要件**: 性能、セキュリティの未定義
### 深化サイクル
```
【実証データ】
Tier 2（ゲーム）: 2-3回の深化で完成
Tier 3（ツール）: 3-5回の深化を想定
Tier 4（基盤）: 5-10回の深化を想定
```
---
## バグゼロの証明
### なぜバグゼロが可能か
```
バグ = 期待と実際の乖離
期待 = 契約
実際 = 実装
乖離の原因：
1. 契約が曖昧 → 深化で解消
2. 導出が誤り → 構造的変換で防止
3. 検証が不足 → 継続検証で防止
すべての原因を構造的に防止
→ バグゼロは構造的に保証される
```
### 実証結果
```
【Tier 2 ゲーム】
- テスト: 53件
- パス: 53件
- バグ: 0件
- 深化: 3回
最初の契約では不足があった。
しかし深化により、最終的にバグゼロ達成。
```
---
## 射程と限界
### 作れるもの
```
Tier 1-2: 実証済み
電卓、ゲーム、エディタ、ツール
Tier 3-4: 設計完了、実証中
協調ツール、CRM基盤、CMS基盤
Tier 5: 理論段階
言語基盤、開発環境
```
### 作れないもの
```
- 契約化できない曖昧なもの
- 物理法則に反するもの
- 倫理に反するもの
```
---
## 進化の方向
### Phase 1（現在）: 導出的創造
```
人間が意図 → AIが導出
「意図があれば、作れる」
```
### Phase 2（将来）: 創発的創造
```
文脈から創発 → 人間が選択 → AIが導出
「気づかない価値も、創発する」
```
### Phase 3（将来）: 自律的創造
```
AIが課題発見 → AIが解決 → 継続進化
「自ら進化し続ける」
```
---
_導出的創造 理論 v1.0_