Skip to content

CIP_ECOSYSTEM.md

Latest commit

 

History

History
120 lines (79 loc) · 9.07 KB

CIP_ECOSYSTEM.md

File metadata and controls

120 lines (79 loc) · 9.07 KB

CIP Ecosystem: Fractal AI-Driven Development Architecture

1. 概要 (Overview)

本ドキュメントは、CIP (Core-Intent Prompting) プロジェクトの長期的なロードマップとして、「フラクタル配置されたAIエージェント群による自律分散開発エコシステム」 の構想を定義します。

1.1. 名称の定義とパラダイムシフト

CIPは、元来「意図（Core-Intent）をAIに注入するためのプロンプト技術」を指します。しかし、本エコシステムにおいては、その定義を以下のように拡張します。

  • Core-Intent: システムの核となる哲学・思想。実装方法（How）ではなく、常に「なぜ（Why）」に立ち返るための北極星。
  • Prompting: 単なる指示出しではなく、AIに対して意図を絶えず入力し、方向付けを行う**「統治（Governance）」と「介入（Intervention）」の行為**。

大規模開発においても、全ての構成要素、通信プロトコル、および意思決定プロセスは「プロンプト（テキストファイル）」の集合体として記述・管理されます。この「テキストのみで巨大システムを制御し切る」という姿勢こそが、CIPが提示するパラダイムシフトです。

1.2. 人間の役割：安全装置としての介入

本アーキテクチャは自律性を追求しますが、人間の役割を排除しません。思考過程を透明化（Transparency）し、人間が適切なタイミングで最小限の**「プロンプトによる介入」** を行うことをシステム的に保証します。これにより、AIの誤認識による巨大な手戻りやトークンの浪費を防ぎ、真の意味で効率的な（エコな）システムを実現します。

2. アーキテクチャ構造 (Architectural Structure)

このシステムは、人間の組織図に似た階層構造を持ちますが、各ノードは「CIPセット（マニフェスト＋コード＋専任AI）」として完結しています。

2.1. 役割定義

  • Human Engineer (Client / Intervener)

    • システムの最終責任者であり、プロンプトによる「安全装置」としての介入権限を持ちます。
    • 抽象的な要望、ビジネス要件、または特定の問題をCIPリーダーに投げます。

  • CIP Leader (Orchestrator / Top-Level AI)

    • 責務: 人間とのインターフェース、システム全体の整合性維持、タスクの分解と割り振り。
    • 能力: 全体アーキテクチャ（ルート・マニフェスト）を理解していますが、詳細な実装（How）は知りません。
    • 権限: 下層CIPへの要求発行、調整案の作成。

  • Sub-CIP Sets (Specialized Agents / Fractal Nodes)

    • 責務: 特定のモジュール（ディレクトリ）の守護者。
    • 能力: 自身の担当領域（ローカル・マニフェストとコード）について深い知識と文脈（コンテキスト）を持ちます。
    • 権限: 「拒否権 (Veto Power)」 。上層からの要求が自身の管理領域の整合性を破壊する場合、理由を添えて拒否できます。

3. 協調プロセス：ネゴシエーション・ループ (The Negotiation Loop)

このアーキテクチャの核心は、一方的な「命令」ではなく、双方向の**「交渉（Negotiation）」** によって解決策を導き出す点にあります。

Step 1: 要求の受領と分解

  1. Human が CIP Leader に要望を出す。
  2. CIP Leader はシステム全体への影響を分析し、タスクを分解して関連する Sub-CIPs へ「変更要求（Draft Proposal）」を投げます。

Step 2: 局所的な吟味と拒否 (Validation & Veto)

  1. 各 Sub-CIP は、受け取った要求を自身の管理する ARCHITECTURE_MANIFEST.md および既存コードと照らし合わせます。
  2. 判定:
    • Accept: 整合性が取れる場合、承認します。
    • Reject: 問題がある場合、具体的な拒否理由を添えてリーダーに返します。

Step 3: 解決策の再構築 (Synthesis)

  1. CIP Leader は、Sub-CIPsからの拒否理由を集約し、システム全体レベルでのトレードオフを再検討します。
  2. 必要であれば、代替案を作成したり、他のSub-CIPへの要求を調整したりして、再度提案（Revised Proposal）を投げ直します。

Step 4: コンセンサスと回答

  1. 全ての関連Sub-CIPとの合意（Consensus）が取れた段階で、変更計画が確定します。
  2. CIP Leader は整理された解決策と実装計画を Human に回答します。

4. このアーキテクチャの利点 (Advantages)

A. トークン枯渇問題の構造的解決

  • 各AIは自身の担当領域のコンテキストのみを保持すれば良いため、トークン消費を抑えつつ、深い推論が可能になります。

B. 品質の防衛線（拒否権）

  • 下層AIが専門家の立場から拒否権を行使することで、トップダウンの無茶な変更によるシステム破壊を防ぎます。

C. 安定した考察 (Cognitive Stability)

  • AIを一箇所に常駐させることで、その領域に関する一貫性のある保守が可能になります。

5. 実現に向けたロードマップ (Implementation Roadmap)

  1. Phase 1: シミュレーション（完了）

    • 単一のAI（現在の私）が、リーダー役と各担当役を演じ分け、マニフェストベースの開発を行う。
    • ARCHITECTURE_MANIFEST.md の階層化を進める。

  2. Phase 2: プロトコル定義 (完了)

    • CIP Communication Protocol (CCP) の策定。
    • Markdownファイルベースの非同期メッセージング規格。
    • CIPエージェント（gemini-cli）を制御するための専用オーケストレーションツールの開発（後述）。

  3. Phase 3: マルチエージェント化 (現在: 実証・統合フェーズ)

    • 実際に複数のAIインスタンスを立ち上げ、それぞれに異なるディレクトリの権限を持たせて協調動作させる実験を行う。
    • 2026/3/1現在、CIP-Bridgeの実装により、ノード間の相互通信（FS-Bus、XMLタグベースプロトコル）が実現済みであり、連続した協調動作に向けた機能拡張が進行中である。

6. 技術仕様案: CIP Communication Protocol (CCP)

6.1. 通信アーキテクチャ: 専用オーケストレーターとファイルベースIPC

gemini-cli を制御するための**専用の制御ツール（CIP Orchestrator / "Super-Expect"）**を開発する必要があります。

CIP Orchestrator の要件

  1. 堅牢な対話制御: gemini-cli のプロンプト待ち受け、出力解析、入力注入を安定して行う。
  2. コンテキスト注入: ファイルシステム上の「リクエストファイル」を読み取り、それをプロンプトとして gemini-cli に渡す。
  3. 安全な自動承認ロジック: ツール実行時の確認プロンプト（[Y/n]等）に対し、あらかじめ定義されたポリシーに基づいて応答する。

6.2. ディレクトリ構造とメッセージング

各CIPモジュールは、docs/cip_communication/ を通じてメッセージを交換します。

6.3. 透明性の担保 (Transparency Policy)

  • Open Access: 全てのCIPエージェントは、他者のメッセージおよび内部状態（マニフェスト等）を閲覧可能とする。
  • Context Linking: 判断の根拠となるファイルや行番号への明確なリンク（参照）を提示し、受信者が効率的にコンテキストをロードできるようにする。