Framework_Integration_Map.md
# 🌀 Framework Integration Map
## 全体フレームワーク体系の統合マップ
**Version 3.3**
**Updated: 2025-12-29**
---
## § 0. 全体アーキテクチャ（4層構造）
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ NOBU'S FRAMEWORK ECOSYSTEM v3.0 │
│ 「AI時代における価値創造と安全な協働の統合的体系」 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ LAYER 0: 原理層（Principles）— 不変 │ │
│ │ │ │
│ │ メタ原理：含んで超え続ける（Include & Transcend） │ │
│ │ 構造原理：2軸×4象限、螺旋的循環、階層と創発 │ │
│ │ 運動原理：拡張⟷収縮、帰納⟷演繹⟷仮説推論 │ │
│ │ │ │
│ │ 参照: ITF_v2_1.md Part I │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ 規定 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ LAYER 1: OS層（Meta-Methods）— 比較的安定 │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ITF │ │ USM │ │ CEM │ │ AAF │ │ │
│ │ │ どう問う │ │どう構造化│ │ どう協働 │ │ どう普及 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ + derivation（どう作るか） │ │
│ │ + Sovereign AI Architecture（どう安全に協働するか） │ │
│ │ + ADDE（どう自律運用するか） │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ 生成 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ LAYER 2: パターン層（Domain Patterns）— 文脈依存 │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ TAT │ │ DDM │ │ (Bridge)│ │(Scaffold)│ │ │
│ │ │試行増幅 │ │次元発見 │ │ 接続統合 │ │段階構築 │ │ │
│ │ │ 転移 │ │ │ │ (TBD) │ │ (TBD) │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ │ │
│ │ 管理: Pattern_Index.md │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ 適用 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ LAYER 3: 実装層（Implementation）— 具体的実践 │ │
│ │ │ │
│ │ サービス: MIX, CO-IDE, Leap │ │
│ │ プロダクト: mirror, seehub, leap, prism, lens, root, ... │ │
│ │ ツール: brand-pptx, etc. │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
```
### ディレクトリ構成
```
work/
├── Integrated/ # LAYER 1 OS層
│ ├── Architecture/ # 全体構造
│ │ └── Framework_Architecture.md
│ ├── Patterns/ # LAYER 2 パターン層
│ │ ├── Pattern_Index.md
│ │ ├── TAT_v1.md
│ │ ├── DDM_v1.md
│ │ └── Leap_Service_Design.md
│ ├── ITF_v2_1.md, USM_v1.md, CEM_v1.md, AAF_v1.md
│ ├── ADDE_v1.md, ADDE_Quick_Reference.md # AI-Driven Development Environment
│ └── Framework_Integration_Map.md # このファイル
│
├── derivation/ # 創造の体系
├── sovereign-ai/ # 安全性の体系
├── team/ # 理論基盤
├── agents/, thought/, transformation/
│
└── [projects]/ # LAYER 3 プロダクト層
```
---
### 2つの次元の統合
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 【mirror 5軸】WHO we are — 誰であるか（アイデンティティ） │
│ │
│ Vision → Target → Service → Capability → System │
│ (世界変革) (完全統合) (進化パートナー) (共進化) (創発的進化) │
│ │
│ × │
│ │
│ 【5フレームワーク】HOW we think & act — どう考え行動するか │
│ │
│ ITF → USM → CEM → derivation → AAF │
│ (どう問うか) (どう構造化) (どう共創) (どう作るか) (どう使われる) │
│ │
└─────────────────────────────────────────────────────────────────┘
【核心】
「5軸が選択を規定し、5フレームワークが実現を支える」
【統合層マッピング】
┌─────────────┬────────────────┬────────────────────────────────┐
│ 5軸 │ 主要Framework │ 役割 │
├─────────────┼────────────────┼────────────────────────────────┤
│ Vision │ ITF (Q2) │ 方向性を問いで見出す │
│ Target │ USM │ 対象を軸で構造化 │
│ Service │ AAF │ 使われ続ける設計 │
│ Capability │ CEM │ 協働で能力を育てる │
│ System │ derivation │ 契約で確実に構築 │
└─────────────┴────────────────┴────────────────────────────────┘
```
---
### ペルソナ別エントリーポイント
```
【Creative】直感を形にしたい
1. CEM（4象限を泳ぐ）→ 2. ITF（問いで深める）→ 3. derivation（契約で確実に）
関連軸: Vision, Capability
【Strategy】構造的に意思決定したい
1. USM（軸で構造化）→ 2. ITF（6つの問いで検証）→ 3. AAF（使われ続ける設計）
関連軸: Target, Service
【Technology】確実に動くものを作りたい
1. derivation（契約→導出）→ 2. AAF（摩擦除去）→ 3. CEM（チームと共創）
関連軸: System, Service
```
---
## § 1. 5つのフレームワークの詳細構造
```
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 【思考系】 │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ ITF v2.1（Integrated Tools Framework） │ │
│ │ どう問うか：6つの問いの円環、being/doing/having │ │
│ │ │ │
│ │ ┌────────────────────┬────────────────────┐ │ │
│ │ │ USM │ CEM │ │ │
│ │ │ どう構造化するか │ どう共に考えるか │ │ │
│ │ │ 軸による定義 │ 協働的創発 │ │ │
│ │ └────────────────────┴────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ↓ 「何を作るか」が決まったら │
│ │
│ 【実行系】 │
│ │
│ ┌─────────────────────────┬─────────────────────────┐ │
│ │ derivation │ AAF │ │
│ │ どう作るか │ どう使われ続けるか │ │
│ │ 契約→導出→検証→完成 │ 摩擦除去→統合→価値循環 │ │
│ └─────────────────────────┴─────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
【関係性】
ITF：思考の「OS」- 全体を規定
USM：体系化の「ツール」- 構造化を支援
CEM：協働の「プロトコル」- AI協働時に使用
derivation：創造の「実行系」- 契約からコードを導出
AAF：採用の「設計系」- 使われ続ける状態を設計
```
---
## § 2. 各フレームワークの概要
### ITF v2.1（Integrated Tools Framework）
```
【本質】
含んで超え続ける思考の体系
【構造】
・メタ原理：含んで超え続ける
・6つの問いの円環
Q1 Perspective（何を見ているか？）
Q2 Development（どこへ向かうか？）
Q3 Inquiry（どう深めるか？）
Q4 Validation（十分に見えたか？）
Q5 Decision（どう踏み出すか？）
Q6 Integration（何を持つべきか？）
・3層：being / doing / having
【用途】
・思考の全体を構造化する
・どの問いに取り組むべきか判断する
・思考の停滞を診断・処方する
```
### USM（Universal Systematization Method）
```
【本質】
膨大にせず精緻に体系化する方法論
【構造】
・3つの核心原理
1. 軸による定義
2. 普遍的言葉
3. 部分⇄全体の相互規定
【用途】
・新しい領域を体系化する
・膨大化を避けて構造化する
・固有名詞を普遍的言葉に変換する
```
### CEM（Collaborative Emergence Method）
```
【本質】
AI時代の理解の方法
【構造】
・2軸：直感⇄構造、継承⇄創造
・4象限：構造革新/概念創発/意味継承/形式継承
・運動：螺旋的上昇
・協働：人間とAIの分業
【用途】
・AIと協働して理解を深める
・既存を含んで超える
・新しい方法論を創発する
```
### AAF（Adoption Architecture Framework）
```
【本質】
技術的価値を持続的な組織価値へ変換する設計体系
【構造】
・2軸：技術的完成度⇄社会的統合度、一時的採用⇄持続的定着
・4象限：機能の墓場/流行り物/専門家の道具/インフラ化
・3層：
Layer 1: Friction Removal（摩擦除去）
Layer 2: Integration（統合設計）
Layer 3: Value Loop（価値循環）
【用途】
・採用障壁を構造的に除去する
・組織への統合を設計する
・持続的な価値ループを埋め込む
```
### derivation（導出的創造）
```
【本質】
契約から構造を導出する創造の体系
【構造】
・5原理：契約的合意/定義の優位/構造的導出/継続的整合/対話的深化
・5 Tier：単純(時間)→中程度(日)→複雑(週)→高複雑(月)→最高複雑(6月+)
・6フェーズ：複雑性分析→意図結晶化→契約定義→導出→検証→深化
・契約階層：Vision→Domain→Meta→Module→Function
【用途】
・意図を契約として明確化する
・契約からコードを導出する
・バグゼロを構造的に保証する
```
---
## § 3. 使い分けガイド
### どのフレームワークを使うか？
```
【判断フロー】
Q: 何をしたいか？
A1: 思考全体を整理したい
→ ITF v2.1を使う
→ 6つの問いで現在地を特定
A2: 新しい領域を体系化したい
→ USMを使う
→ 軸を発見し、構造化する
A3: AIと協働して深化させたい
→ CEMを使う
→ 4象限を泳ぐ、螺旋を回す
A4: 実際に作りたい
→ derivationを使う
→ 契約を定義し、導出する
A5: 使われ続ける状態を作りたい
→ AAFを使う
→ 摩擦除去→統合→価値循環
A6: 全部が必要
→ 組み合わせる（次節参照）
```
### 選択早見表
```
【状況 → 推奨フレームワーク】
思考が停滞している → ITF（どの問いで止まっているか）
新しい領域を理解したい → USM（軸を見つけて構造化）
AIと一緒に深めたい → CEM（4象限を泳ぐ）
実際にシステムを作りたい → derivation（契約→導出）
導入しても使われない → AAF（摩擦除去→統合）
膨大化を避けたい → USM（軸による簡潔な構造化）
チームで共通理解を作りたい → USM + ITF
複雑な問題を整理したい → 全部
```
---
## § 4. フレームワーク間の対応関係
### ITF × derivation
| ITFの問い | derivationのフェーズ |
| :------------- | :------------------------ |
| Q1 Perspective | Phase -1: 複雑性分析 |
| Q2 Development | Vision Contract（方向性） |
| Q3 Inquiry | Phase 2: 導出 |
| Q4 Validation | Phase 3: 検証 |
| Q5 Decision | 契約の合意 |
| Q6 Integration | 完成物（5軸との対応） |
### ITF × AAF
| ITFの問い | AAFの対応 |
| :------------- | :--------------------------------------------------------------- |
| Q1 Perspective | Layer 1: 5つの摩擦を多角的に見る |
| Q4 Validation | Layer 1: 摩擦の検証 |
| Q6 Integration | Layer 2-3: 組織統合、価値循環 |
| 3Driven | VisionDriven→Layer3, IssueDriven→Layer1, TechnologyDriven→Layer2 |
### USM × CEM
| USMの方法 | CEMの象限 |
| :------------------ | :-------------------- |
| 軸の発見 | Ⅱ概念創発 + Ⅲ意味継承 |
| 軸による構造化 | Ⅰ構造革新 |
| 普遍的言葉への変換 | Ⅱ概念創発 + Ⅲ意味継承 |
| 部分⇄全体の相互規定 | 全象限（螺旋） |
### derivation × AAF
| derivationのTier | AAFの重点 |
| :----------------- | :---------------------- |
| Tier 1-2（作品級） | Layer 1中心（認知摩擦） |
| Tier 3（ツール級） | Layer 1-2（統合設計も） |
| Tier 4-5（基盤級） | Layer 1-2-3すべて必須 |
---
## § 5. 統合的使用パターン
### パターンA：新規プロダクト開発
```
【Phase 1：ITFで問いを特定】
Q1: 誰の視点で見るか？
Q6: 5軸（Vision/Target/Service/Capability/System）
【Phase 2：USM/CEMで構造化】
USM: 領域の軸を発見
CEM: 既存の本質を理解、新しい価値を創発
【Phase 3：derivationで実装】
Phase -1: 複雑性分析
Phase 0-1: 契約定義
Phase 2-4: 導出→検証→深化
【Phase 4：AAFで採用設計】
Layer 1: 摩擦除去
Layer 2: 統合設計
Layer 3: 価値ループ
```
### パターンB：既存プロダクト改善
```
【Phase 1：AAFで診断】
Layer 1-3のどこが弱いか？
最大の摩擦は何か？
【Phase 2：ITFで深掘り】
Q1: どの視点が欠けているか？
Q4: 見落としはないか？
【Phase 3：derivationで改修】
既存コードから契約を逆導出
契約ベースで改修
【Phase 4：AAFで再検証】
改修後の採用状況を確認
次の改善サイクルへ
```
### パターンC：チームでの協働
```
【Phase 1：ITFで診断】
チームはどの問いで停滞しているか？
【Phase 2：CEMで協働】
4象限のどこにいるか？
どの象限が不足しているか？
【Phase 3：USMで共通言語化】
議論を軸で構造化
固有名詞を普遍的言葉に
【Phase 4：derivationで実行】
合意を契約として明文化
契約から導出
```
---
## § 6. 共通原理
### 5つのフレームワークに共通するもの
```
【メタ原理】含んで超え続ける
ITF: 明示的にメタ原理として定義
USM: 既存概念を含んで超える
CEM: 継承⇄創造の軸、螺旋的上昇
AAF: 機能の墓場→インフラ化への上昇
derivation: 深化サイクル
【構造原理】2軸×4象限 / 階層
ITF: Q1, Q3, Q4, Q5（4象限）
USM: 軸による空間定義
CEM: 直感⇄構造 × 継承⇄創造
AAF: 技術的完成度⇄社会的統合度 × 一時的採用⇄持続的定着
derivation: 契約階層（Vision→Domain→Module→Function）
【運動原理】螺旋的循環
ITF: 6つの問いの円環
USM: 反復による精緻化
CEM: Ⅳ→Ⅲ→Ⅱ→Ⅰ→Ⅱ'の螺旋
AAF: Layer 1→2→3の積み上げと循環
derivation: 導出→検証→深化の螺旋
【検証原理】検証可能性
ITF: Q4 Validation
USM: 軸の妥当性検証
CEM: 批評モード
AAF: 各Layerの診断チェック
derivation: 継続検証、バグゼロ
```
---
## § 7. Layer 2 パターン層
### 概要
```
Layer 1（OS層）を使って生成された、特定の問題パターンに対する方法論。
【条件】
・繰り返し現れる問題構造を解決
・複数ドメインに適用可能
・固有名詞を排除、普遍的言葉で定義
・Quick Referenceを持つ
```
### 現在のパターン
| パターン | 問題 | 2軸 | 用途 |
| :------- | :--------------- | :------------ | :----------------------------------- |
| **TAT** | 学習→本番の転移 | 環境×密度 | ロボティクス、人材育成、新規事業 |
| **DDM** | 既存軸への囚われ | 認識対象×主体 | キャリア、パートナーシップ、事業戦略 |
### パターン選択フロー
```
Q: 何をしたいか？
A1: 学習・訓練したものを本番で使いたい
→ TAT（試行増幅転移）
A2: 新しい選択肢・次元を見つけたい
→ DDM（次元発見法）→ Leap（サービス）
A3: 上記に当てはまらない
→ Layer 1（ITF/USM/CEM）に戻る
→ 新しいパターンを生成する可能性
```
### 関連文書
```
Integrated/Patterns/
├── Pattern_Index.md # パターン管理
├── TAT_v1.md # 試行増幅転移
├── TAT_Quick_Reference.md
├── DDM_v1.md # 次元発見法
├── DDM_Quick_Reference.md
└── Leap_Service_Design.md # DDMのサービス実装
```
---
## § 8. Sovereign AI Architecture（安全性層）
### 概要
```
AIが人間の能力を超えた時代における
「安全で対等なAI-人間協働」を実現するアーキテクチャ。
核心的洞察:
能力の優劣と決定権の所在は、別の次元である。
AIが人間を超えても、人間の主権は構造的に保護できる。
```
### 4つのレベル
| Level | 名称 | 問い | 状態 |
| :---- | :-------------------------- | :----------------------- | :---------- |
| 1 | Sovereignty Protection | 主権をどう保護するか | ✅ 実装済み |
| 2 | Recursive Safety | 自己改善しても安全か | 📐 設計完了 |
| 3 | Emergent Partnership | 固定役割は最適か | 📐 設計完了 |
| 4 | Sovereign Intelligence Mesh | 複数主体をどう統治するか | 📐 設計完了 |
### ITF/derivationとの関係
```
【ITF × Sovereign AI】
Q1 Perspective → Level 1 MetaCognitiveLayer
Q5 Decision → Level 1 SovereigntyContract
Q6 Integration → Level 3 Emergent Partnership
【derivation × Sovereign AI】
derivation 契約構造 → Level 1 運用契約
derivation 検証原理 → Level 2 証明検証
```
### 関連文書
```
sovereign-ai/
├── ESSENCE.md # ⭐ 本質（197文字）
├── README.md # 日本語版概要
├── ARCHITECTURE_v2.md # 英語版Universal Edition
├── Quick_Reference.md # クイックリファレンス
├── IMPLEMENTATION_GUIDE.md
├── ARCHITECTURE_LEVELS_2-4.md
└── level-1/
├── sovereignty.js
├── diagnostic.js
└── test.js
```
---
## § 8.5. ADDE — AI-Driven Development Environment（運用層）
### 概要
```
AI自律実行 + 人間ガバナンスによる
開発と運用の境界を消す環境設計。
核心的洞察:
Human = Control Tower（管制官）
AI = Autonomous Executor（自律実行者）
Interface = Mobile Dashboard（スマホ）
開発と運用は同じものになる。
AIが継続的に実行し、人間が統治する。
```
### パラダイムシフト
| 観点 | 従来 | ADDE |
| :------------------- | :--------------- | :----------------------------------- |
| 人間の役割 | Worker（作業者） | Control Tower（管制官） |
| AIの役割 | Tool（ツール） | Autonomous Partner（自律パートナー） |
| 主要インターフェース | キーボード+IDE | モバイルダッシュボード |
| 作業場所 | デスク | どこでも |
| Dev vs Ops | 別々 | シームレス |
### Continuous Pipeline (P0-P7)
| Stage | 目的 | 人間介入 |
| :---- | :------------- | :--------------- |
| P0 | 整合性チェック | 失敗時 |
| P1 | スキーマ検証 | 無効時 |
| P2 | 構造パース | エラー時 |
| P3 | **契約検証** ★ | 違反時 |
| P4 | 型生成 | 失敗時 |
| P5 | テスト生成 | カバレッジ不足時 |
| P6 | 状態更新 | 競合時 |
| P7 | 差分検証 | 予期しない差分時 |
### Sovereign AI Architectureとの統合
```
ADDE Component ↔ Sovereign AI
────────────────────────────────────
P3 Contract Valid ↔ Sovereignty Validator
Governance Protocol ↔ Sovereignty Contract
Human Invocation ↔ Role Negotiation
Dashboard ↔ Metacognitive Layer
```
### 関連文書
```
Integrated/
├── ADDE_v1.md # 本体（30KB）
└── ADDE_Quick_Reference.md # クイックリファレンス
```
---
## § 8.6. Sovereign Execution Bridge (SEB) — 翻訳層
### 概要
```
Sovereign AI Architecture（権限構造）と
Tesla 5-Layer Structure（実行構造）を接続する翻訳層。
核心的洞察:
「誰が決める」と「誰がやる」は異なる次元。
両者を接続する契約（ARC）が設計と実装の一貫性を保証する。
```
### 問題定義
```
┌─────────────────────────────────────────────────────────────────┐
│ Sovereign AI Architecture │
│ 問い: 「誰が何を決定できるか？」 │
│ 焦点: 権限の所在（Authority） │
└─────────────────────────────────────────────────────────────────┘
↕ 接続なし → 設計と実装に摩擦
┌─────────────────────────────────────────────────────────────────┐
│ Tesla 5-Layer Structure │
│ 問い: 「誰が何を実行するか？」 │
│ 焦点: 役割分担（Responsibility） │
└─────────────────────────────────────────────────────────────────┘
問題:
1. 権限と責任の乖離
2. フィードバックの断絶
3. 契約の欠如
解決:
Sovereign Execution Bridge（SEB）による双方向翻訳
```
### Authority-Responsibility Contract (ARC)
| ARC Level | Sovereign Level | Tesla Layer | AI実行% | 人間承認 |
| :---------------- | :-------------- | :---------- | :------ | :------------- |
| ARC-CORE | L1 | Layer 0-1 | 0% | 必須（明示的） |
| ARC-SAFETY | L1 | Layer 2 | 10-20% | 必須（ルール） |
| ARC-COLLABORATION | L3 | Layer 3 | 80-90% | 暗黙的 |
| ARC-HYBRID | L3 | Layer 4 | 40-60% | 必須（明示的） |
| ARC-LEARNING | L2 | Layer 5 | 80-100% | デプロイ時 |
### S-I Engineとの統合
```
┌─────────────────────────────────────────────────────────────────┐
│ Strategic-Implementation Engine │
│ 「意図→契約→実装」の翻訳（What/How） │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ Sovereign Execution Bridge (SEB) │
│ 「権限→責任」の翻訳（Who decides / Who executes） │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ Execution Runtime (ADDE P0-P7) │
│ 「実際の実行環境」 │
└─────────────────────────────────────────────────────────────────┘
統合:
S-I Engine契約 + SEB権限責任 = 完全な実行可能定義
「何を」+「誰が決める」+「誰がやる」
```
### 関連文書
```
mirror/docs/design/
└── SOVEREIGN_EXECUTION_BRIDGE.md # 本体
```
---
## § 8.7. TRUST — 横断的検証層（Verification Layer）
### 概要
```
AI時代において、すべてのフレームワーク出力は
「AI汚染」のリスクを持つ。
TRUSTは横断的検証層として、
すべてのフレームワーク出力に適用される。
核心メッセージ:
「AIはすべてを美しく見せる。TRUSTは本物を見抜く力を与える。」
"AI makes everything look good. TRUST helps you see what's real."
```
### 位置づけ
```
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1: OS層 │
│ ITF / USM / CEM / derivation / AAF / Sovereign AI / ADDE │
│ │
│ ════════════════════════════════════════════════════════════ │
│ ║ TRUST（検証層 / Verification Layer） ║ │
│ ║ ║ │
│ ║ Evidence Pyramid (E1-E6) | Core Questions | 48-Hour Rule ║ │
│ ════════════════════════════════════════════════════════════ │
│ │
│ LAYER 2: パターン層 │
└─────────────────────────────────────────────────────────────────┘
すべてのフレームワーク出力は、TRUSTによる検証を通過すべき。
TRUSTはITF Q4 "Validation"の深い実装でもある。
```
### 3つのパターン（Patterns to Transcend）
| パターン | 問題 | 検出方法 |
| :------------------------- | :--------------------------- | :------------------ |
| **Polishing Trap** | 深さがないまま「完成」と錯覚 | Origin Question |
| **Sycophancy** | AIが「気持ちいいこと」を優先 | Resistance Question |
| **Cognitive Comfort Trap** | 批判的思考の機会が減少 | Execution Question |
### TRUST Core Questions
```
1. Origin Question（起源の問い）
「この核心は、AIに触れる前から自分の中にあったか？」
2. Resistance Question（抵抗の問い）
「これは間違っている、と言われたらどう感じるか？」
3. Execution Question（実行の問い）
「明日、最小単位で始められるか？」
```
### Evidence Pyramid (E1-E6)
```
【重要】E1-E6は「情報の検証レベル」。
MIRROR Evolution Map (L1-L5.5)の「AI協働成熟度」とは別概念。
E1: 複数環境で再現・実証 ≒ メタアナリシス
E2: 自己/自社環境で実証 ≒ A/Bテスト
E3: 類似事例・他者経験 ≒ ケーススタディ
E4: 理論的妥当性 ≒ デザインパターン
E5: 経験・直感・専門家意見 ≒ コンサル助言
E6: AI出力（未検証） ≒ 該当なし（TRUST独自）← スタート地点
```
### 48時間ルール
```
重要な意思決定は、48時間寝かせてから判断する。
興奮が冷めた後も重要なら、それは本物。
適用条件:
・エビデンスレベルがE5-E6の場合
・ギャップが4以上の場合
・興奮や強い感情を伴う場合
```
### 各フレームワークへの適用
| Framework | TRUSTの適用ポイント |
| :------------- | :------------------------------------------- |
| **ITF** | Q1-Q6の各出力にCore Questionsを適用 |
| **USM** | 軸の発見・構造化結果をEvidence Pyramidで検証 |
| **CEM** | 協働的創発の成果をCore Questionsで検証 |
| **derivation** | 契約定義・導出結果をEvidence Pyramidで検証 |
| **AAF** | 採用設計を48時間ルールで検証 |
### 関連文書
```
Integrated/
└── TRUST_v1.md # 本体ドキュメント
work/trust/ # TRUSTプロダクト
├── CLAUDE.md # Agent定義
└── src/app/ # Webアプリ (trust.seehub.org)
```
---
## § 9. ディレクトリ構成（統合版）
```
work/
├── Integrated/ # LAYER 1 OS層
│ ├── Architecture/ # 全体構造
│ │ └── Framework_Architecture.md
│ ├── Patterns/ # LAYER 2 パターン層
│ │ ├── Pattern_Index.md
│ │ ├── TAT_v1.md, TAT_Quick_Reference.md
│ │ ├── DDM_v1.md, DDM_Quick_Reference.md
│ │ └── Leap_Service_Design.md
│ ├── ITF_v2_1.md, USM_v1.md, CEM_v1.md, AAF_v1.md
│ ├── *_Quick_Reference.md
│ ├── Framework_Integration_Map.md # このファイル（4層構造版）
│ ├── FRAMEWORK_ECOSYSTEM_v2.md # 5層構造版（別視点）
│ ├── Ecosystem_Overview.md # 30秒俯瞰図
│ └── [Agent_Guide_*, etc.]
│
├── derivation/ # 創造の体系
│ └── [README.md, SYSTEM_PROMPT.md, etc.]
│
├── sovereign-ai/ # 安全性の体系
│ ├── ESSENCE.md # ⭐ 本質（197文字）
│ ├── README.md # 日本語版概要
│ ├── ARCHITECTURE_v2.md # 英語版Universal Edition
│ ├── Quick_Reference.md # クイックリファレンス
│ ├── IMPLEMENTATION_GUIDE.md
│ ├── ARCHITECTURE_LEVELS_2-4.md
│ └── level-1/ # Level 1 実装
│
├── team/ # 理論基盤
├── agents/, thought/, transformation/
│
├── shared/skills/ # ClaudeCode Skills
│
└── [projects]/ # LAYER 3 プロダクト層
├── mirror/ (Coordinator)
├── seehub/, leap/, prism/, lens/, ...
└── contracts/
```
---
## § 10. クイックリファレンス
### 全体一覧表
| 層 | 体系 | 問い | 核心構造 |
| :-------------- | :------------------ | :------------------------- | :--------------------------- |
| **L0 原理** | ITF Part I | 何が不変か | メタ原理、構造原理、運動原理 |
| **L1 OS** | ITF v2.1 | どう問うか | 6つの問いの円環 |
| | USM | どう構造化するか | 軸による定義 |
| | CEM | どう共に考えるか | 4象限×螺旋 |
| | AAF | どう使われ続けるか | 3層構造 |
| | derivation | どう作るか | 契約→導出 |
| | Sovereign AI | どう安全に協働するか | 4レベル構造 |
| | **SEB** | 権限と責任をどう接続するか | ARC契約 |
| **検証層** | **TRUST** | どう検証するか | E1-E6 × Core Questions |
| **L2 パターン** | TAT | 学習→本番をどう転移するか | 環境×密度 |
| | DDM | 新しい次元をどう発見するか | 認識対象×主体 |
| **L3 実装** | サービス/プロダクト | 何を作るか | 具体的実践 |
### ペルソナ別エントリーポイント（拡張版）
```
【Creative】直感を形にしたい
1. CEM（4象限を泳ぐ）
2. ITF（問いで深める）
3. DDM（新しい次元を発見）
4. derivation（契約で確実に）
【Strategy】構造的に意思決定したい
1. USM（軸で構造化）
2. ITF（6つの問いで検証）
3. TAT（試行増幅で検証）
4. AAF（使われ続ける設計）
【Technology】確実に安全に動くものを作りたい
1. derivation（契約→導出）
2. Sovereign AI（安全性設計）
3. AAF（摩擦除去）
4. TAT（Sim-to-Real転移）
```
---
**Document Information**
```yaml
Title: Framework Integration Map
Subtitle: 全体フレームワーク体系の統合マップ
Version: 3.2
Created: 2025-12-24
Updated: 2025-12-27
Status: Active & Evolving
変更履歴:
v1.0 (2025-12-24): ITF × USM × CEM の3フレームワーク
v2.0 (2025-12-26): AAF, derivation を追加、5フレームワーク統合
v3.0 (2025-12-27): 4層アーキテクチャ、Layer 2パターン（TAT/DDM）、
Sovereign AI Architecture を追加、全体統合
v3.1 (2025-12-27): ADDE (AI-Driven Development Environment) を追加、
Sovereign AI に ESSENCE.md, ARCHITECTURE_v2.md を追加
v3.2 (2025-12-27): Sovereign Execution Bridge (SEB) を追加、
Sovereign AI と Tesla 5-Layer の翻訳層を確立
v3.3 (2025-12-29): TRUST（横断的検証層）を追加、
Evidence Pyramid (E1-E6)、Core Questions、48時間ルールを統合
```
---
_Layer 0 原理で思考の基盤を持ち_
_Layer 1 OS層で考え方を選び_
_Layer 2 パターンで問題を解き_
_Layer 3 実装で価値を生む_
_4層が相互に強化し、螺旋的に進化する_
_これが SEEHUB Framework Ecosystem v3.0 である_ 🌀