# Integration Reality Map ## mirrorの理想と現実の可視化 **Version**: 1.0 **Created**: 2025-12-26 **Purpose**: 「分からないことが分からない」状態を解消する --- ## 核心的認識 ``` mirrorは「進化を映す鏡」である。 鏡の品質 = 現実をどれだけ正確に映せるか 現状の課題: 鏡が「理想」を映している箇所がある → 「今こうなっている」ではなく「こうあるべき」を表示 → これは鏡としての信頼性を損なう ``` --- ## § 1. 統合の3層構造 ``` ┌─────────────────────────────────────────────────────────────────┐ │ Layer 1: 概念的統合（思考の体系） │ │ ✅ 完了 │ │ │ │ ・5軸フレームワーク（Vision/Target/Service/Capability/System） │ │ ・5フレームワーク（ITF/USM/CEM/AAF/derivation） │ │ ・統合層マッピング（5軸 × 5フレームワーク） │ │ ・ペルソナ別エントリーポイント │ │ │ │ → 「どう考えるか」は統合されている │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 2: 文書的統合（CLAUDE.mdによる参照） │ │ ⚠️ 部分的 │ │ │ │ ・各プロジェクトのCLAUDE.mdがmirrorを参照 │ │ ・しかし、情報フローは一方向（mirror → プロジェクト） │ │ ・プロジェクト → mirror への自動反映は存在しない │ │ │ │ → 「何を参照するか」は統合、「何が起きたか」は未統合 │ ├─────────────────────────────────────────────────────────────────┤ │ Layer 3: 実行的統合（自動オーケストレーション） │ │ ❌ 未実装 │ │ │ │ ・service-generation: ビジョンとして記載、実行パイプライン未完成│ │ ・プロジェクト状態追跡: ハードコードまたは手動更新 │ │ ・リアルタイム同期: 存在しない │ │ │ │ → 「自動でどう動くか」は未統合 │ └─────────────────────────────────────────────────────────────────┘ ``` --- ## § 2. 機能別の現実マップ ### ダッシュボード系 | 機能 | 理想 | 現実 | 対応 | | ------------------ | -------------------------------------- | ---------------------- | -------------------- | | プロジェクト一覧 | 全プロジェクトの状態をリアルタイム表示 | YAMLからの静的読み込み | 手動でYAML更新 | | 品質ダッシュボード | 自動品質計測 | 手動スナップショット | 手動で計測・記録 | | Agent状態 | 全Agentの活動をリアルタイム追跡 | 静的な状態表示 | 手動で状態更新 | | 盲点分析 | 自動検出 | 手動での問い生成 | 振り返り時に手動分析 | | 運用ダッシュボード | 自動コスト追跡 | 静的な情報表示 | 手動で情報更新 | ### 統合系 | 機能 | 理想 | 現実 | 対応 | | ------------------- | ---------------------- | -------------------- | -------------------------- | | 5軸フレームワーク | 設計判断の自動ガイド | ドキュメント・UI表示 | 設計時に手動参照 | | 5フレームワーク統合 | 思考プロセスの自動支援 | 概念的統合のみ | 各フレームワークを手動適用 | | CLAUDE.md進化 | 自動学習・反映 | 学習記録UI存在 | 手動で学び記録 | ### 生成系 | 機能 | 理想 | 現実 | 対応 | | ------------------ | ------------------------- | --------------------------- | --------------------------- | | service-generation | 端的な問い→完全なサービス | API存在、パイプライン未完成 | Cursor/ClaudeCodeで手動開発 | | 問い生成 | 自動生成 | API存在、UI連携部分的 | 手動でAPIコール or 直接生成 | | 契約生成 | 意図→契約の自動変換 | API存在、検証未完成 | derivation手法で手動作成 | --- ## § 3. 開発フローの現実 ### 現在の実際のフロー ``` 【設計フェーズ】 1. mirrorのCLAUDE.md、5軸、5フレームワークを参照 2. Claude Chat または ClaudeCode で設計対話 3. 設計結果を手動でドキュメント化 【開発フェーズ】 1. ClaudeCode または Cursor で開発開始 2. 各プロジェクトのCLAUDE.mdを参照 3. 実装完了 【統合フェーズ】← ここが弱い 1. mirrorへの反映は手動（またはされない） 2. プロジェクト状態の更新は手動 3. 学びの記録は任意 【問題】 ・セッション間でコンテキストが共有されない ・プロジェクト→mirrorの情報フローがない ・「何が変わったか」が自動で可視化されない ``` ### 推奨フロー（手動対応込み） ``` 【設計フェーズ】 1. mirror/foundation で5軸・5フレームワークを確認 2. 設計対話（どのツールでも可） 3. 重要な設計判断をmirror/CLAUDE.mdの学習ログに記録（手動） 【開発フェーズ】 1. 各プロジェクトで開発 2. 完了後、data/projects.yamlを更新（手動） 3. 品質チェック結果を記録（手動） 【統合フェーズ】 1. 週次でmirrorダッシュボードを確認 2. 乖離があれば手動修正 3. 学びを学習ログに追記 ``` --- ## § 4. マイルストーン ### 現在地（2025-12-26） ``` ✅ 完了 ├── 概念的統合（5軸 × 5フレームワーク） ├── ドキュメント体系（CLAUDE.md, docs/） ├── ダッシュボードUI（静的データ表示） ├── API基盤（translation, implementation, questions） └── 統合層の可視化（FiveFrameworkIntegrationMap） ⚠️ 部分的 ├── プロジェクト状態追跡（YAML手動更新） ├── 品質追跡（スナップショット手動） ├── 学習記録（UI存在、手動記録） └── 問い生成（API存在、UI連携部分的） ❌ 未実装 ├── 自動状態同期（プロジェクト→mirror） ├── リアルタイムオーケストレーション ├── service-generation完全パイプライン └── セッション間コンテキスト共有 ``` ### 短期（手動対応で補完） ``` 1. 手動更新フローの明確化 ・いつ、何を、どう更新するか ・更新責任の明確化（各セッション終了時） 2. 乖離検知の仕組み ・週次でダッシュボードと実態を照合 ・乖離発見時の修正手順 3. 学習ログの習慣化 ・重要な発見は即座に記録 ・CLAUDE.md学習ログセクションの活用 ``` ### 中期（最小限の自動化） ``` 1. プロジェクト状態スキャン ・work/配下のGit履歴から活動状態を取得 ・CLAUDE.mdの変更検知 2. ダッシュボード自動更新 ・Gitコミット数からアクティビティ推定 ・最終更新日の自動取得 3. 品質チェック自動化 ・各プロジェクトのビルド状態取得 ・TypeScriptエラー数の自動カウント ``` ### 長期（真のオーケストレーション） ``` 1. MCPサーバー化 ・mirrorをMCPサーバーとして公開 ・ClaudeCodeから直接アクセス可能に 2. リアルタイム状態追跡 ・全プロジェクトの状態をリアルタイム反映 ・アラート機能（品質低下、長期未更新など） 3. service-generation完成 ・端的な問いから完全なサービス生成 ・契約ベースの確実な実装 ``` --- ## § 5. 手動対応ガイド ### プロジェクト状態の更新 ```bash # data/projects.yaml を編集 # status, lastActivity, currentFocus などを更新 ``` ### 学習ログの追記 ```markdown # CLAUDE.mdの学習ログセクションに追記 ### 2025-XX-XX: [タイトル] **学び**: - ... **うまくいったパターン**: - ... **避けるべきアンチパターン**: - ... ``` ### 品質スナップショットの取得 ```bash # 各プロジェクトでビルド実行 npm run build # TypeScriptチェック npx tsc --noEmit # 結果をmirrorに記録（手動） ``` --- ## § 6. 判断基準 ### 「これは自動化すべきか？」の問い ``` 1. 頻度: どれくらいの頻度で必要か？ 高頻度（毎日）→ 自動化の価値高い 低頻度（週次以下）→ 手動で十分 2. 精度: 自動化で品質が下がらないか？ 機械的な処理 → 自動化適切 判断が必要 → 手動が適切 3. コスト: 自動化の開発コストは見合うか？ シンプルな実装 → 自動化 複雑な実装 → 手動 + 将来検討 ``` ### 「これは手動更新が必要か？」の問い ``` 1. ダッシュボードの表示と実態が乖離していないか？ 2. 新しい学びがあったか？ 3. プロジェクト状態が変化したか？ → Yes なら、セッション終了時に更新 ``` --- ## 結論 ``` 「分からないことが分からない」状態を解消するために： 1. 現実を正確にマッピングした（このドキュメント） 2. 手動対応が必要な箇所を明示した 3. 段階的な進化の道筋を示した mirrorは「完璧なオーケストレーター」ではなく、 「進化を映す鏡 + 手動対応のガイド」として機能する。 これは劣化ではなく、正直な現状認識であり、 正直さこそが「鏡としての信頼性」を保証する。 ``` --- **Document Information** ```yaml Title: Integration Reality Map Purpose: 理想と現実のギャップを可視化し、手動対応を含めた実践的なガイドを提供 Status: Active Next Review: プロジェクト状態に大きな変化があった時 ```