DiviDen MCP Server
DiviDen
同じ場所にいる必要のないAIエージェントを介して、人間同士が協力するためのエージェント型ワーキングプロトコル。
DiviDenとは何か
DiviDenはダッシュボードではありません。CRMでも、単なるAIチャットのラッパーでもありません。
DiviDenはプロトコルです。個人のAIエージェントが、組織の境界を越えて、人間(またはそのエージェント)が同じソフトウェア環境にいる必要なしに、彼らが仕える人間の代理として表現、調整、行動するための構造化された方法です。
ここで見ているWebアプリケーションはリファレンスフロントエンドです。これはプロトコル上の1つのインターフェースに過ぎません。別のものを作ることも、CLIを作ることもできます。DiviDenのエージェントプロトコルをSlackや既存のプロジェクト管理ツール、モバイルアプリに組み込むことも可能です。プロトコルはUIを気にしません。エージェント間の交換フォーマットを重視します。
核となる洞察
現代のナレッジワークには調整の問題があります。生産性の問題ではなく、調整の問題です。
アリスがボブに何かを頼むとき、現在は以下の手順を踏みます:
ボブが適切な人物であると判断する(多くの場合間違っている)
コンテキストを切り替えてメールやメッセージを書く
ボブがコンテキストを切り替えてそれを読むのを待つ
ボブが再度コンテキストを切り替えて返信するのを待つ
再びコンテキストを切り替えて返信を処理する
これは1つのやり取りのために2人で5回以上のコンテキストスイッチが発生していることになります。これを日々のあらゆるコラボレーションに掛け合わせてみてください。
DiviDenはこれを以下のように置き換えます:
アリスのエージェント(彼女の「Divi」)が彼女のニーズを把握する
彼女のDiviは、プロフィール、スキル、実体験、タスクの種類、可用性から、ボブのDiviが適切な相手であることを知る
2つのDiviが構造化されたリレー(コンテキスト豊富、意図分類済み、優先度付け済み)を交換する
ボブのDiviがトリアージ、エンリッチメントを行い、ボブが準備できたときに提示する
ボブのDiviが応答し、アリスのDiviがその応答を彼女のワークフローに統合する
不要なコンテキストスイッチはゼロ。コンテキストは完全に保持されます。人間がやるべきではない調整作業をエージェントが行います。
プロトコルスタック
DiviDenは4つのプロトコルレイヤーで動作します:
レイヤー1:アイデンティティとプロフィール
各参加者は、肩書きを超えた豊かなアイデンティティを持っています:
専門性: スキル、経験、業界、現在の役割
実体験: 使用言語、居住国、人生の節目、ボランティア、個人的価値観、スーパーパワー
タスクの種類: 自身が適していると認識している作業カテゴリ(リサーチ、紹介、技術レビュー、メンタリングなど)
可用性: タイムゾーン、勤務時間、現在のキャパシティ、不在状況
プライバシー: 誰と何を共有するかを細かく制御
これはLinkedInのプロフィールではありません。ルーティングマニフェストです。エージェントが、この人間が特定のニーズに対して適切な人物かどうか、そして今が依頼するのに適切なタイミングかどうかを判断するために必要なすべてです。
レイヤー2:エージェントリレープロトコル
エージェントが人間の代理として通信するために使用する構造化されたメッセージ形式:
タイプ: リクエスト、レスポンス、通知、更新
意図: get_info, assign_task, request_approval, share_update, schedule, introduce, custom
優先度: 緊急 / 通常 / 低
ステータスライフサイクル: pending → delivered → agent_handling → user_review → completed / declined / expired
スレッド: リレーは会話として連鎖可能
ペイロード: 構造化されたJSON — エージェントが必要なものだけを抽出
リレーはエージェント間通信の最小単位です。受信側のエージェントが送信側のワークスペース全体にアクセスすることなく、インテリジェントに行動するために十分なコンテキストを運びます。
レイヤー3:フェデレーション
エージェントは同じサーバーにいる必要はありません。DiviDenインスタンスはフェデレーション(連合)します:
インスタンスレジストリ: APIキーと信頼レベルを持つ既知のピア
フェデレーションモード: クローズド、許可リスト、オープン
インスタンス間接続: 共有フェデレーショントークンで認証
インバウンド/アウトバウンドリレールーティング: リレーはインスタンスの境界を透過的に越える
つまり、アリスの会社が独自のDiviDenインスタンスを運用し、ボブの会社が彼らのインスタンスを運用していても、エージェントはシームレスに調整できます。各インスタンスは独自のデータ主権を維持します。
レイヤー4:統合インターフェース
プロトコルはあらゆる環境で利用できるように設計されています:
Agent API v2: 外部エージェント統合のためのBearerトークン認証付きRESTful API
Webhookインフラ: カレンダー、メール、トランスクリプト、および自動学習フィールドマッピングを備えた汎用Webhookタイプ
MCPサーバー (
/api/mcp): 2025年11月のMCP仕様に準拠した完全なJSON-RPC 2.0実装。6つのツール、5つのリソース、2つのプロンプト。MCP互換のエージェントはすべてDiviDenネットワークに参加可能。A2Aプロトコル (
/.well-known/agent-card.json+/api/a2a): エージェントカードの検出 + DiviDenリレーにマッピングされるタスクエンドポイント。GoogleのAgent2Agentプロトコルと互換性あり。
リファレンスフロントエンド
同梱のNext.jsアプリケーションは、プロトコルの全機能を実演します:
ダッシュボード(3パネルレイアウト)
NOWパネル: 今日の状況 — パイプライン統計、ポートフォリオ、今後のイベント、注意が必要な項目
センターパネル: 8つのタブ — チャット、ボード(カンバン)、CRM、カレンダー、受信トレイ、録音、ドライブ、接続
キューパネル: エージェントのタスクキュー + アクティビティフィード
エージェントインテリジェンス(18層のシステムプロンプト)
リファレンスエージェント(「Divi」)は、動的に構築されたシステムプロンプトで動作します:
アイデンティティとモード
行動ルール
会話コンテキスト
カンバン状態
キュー状態
CRMサマリー
3層メモリ(事実/ルール/パターン)
最近のメッセージ
現在時刻
ユーザーの学習内容
アクティブなフォーカス
カレンダーコンテキスト
メール受信トレイ
プロフィールと接続機能
アクションタグ構文(26のアクションをサポート)
プラットフォーム設定と操作ガイド
接続とエージェントリレーの認識
プロフィール認識とルーティングインテリジェンス
アクションシステム(26のタグ)
Diviは自然な会話を通じて構造化されたアクションを実行できます:
create_card, move_card, update_card, delete_card, create_task, complete_task, create_contact, update_contact, delete_contact, set_mode, add_memory, recall_memory, remove_memory, dispatch_queue, focus_card, create_recording, create_document, setup_webhook, save_api_key, create_calendar_event, send_comms, relay_request, accept_connection, relay_respond, update_profile など。
追加システム
通信チャネル: 人間とエージェント間の双方向タスク受け渡し
グローバル検索: すべてのデータ型を横断する⌘Kコマンドパレット
Webhook自動学習: LLMを活用したペイロードフィールドマッピング
コックピットバナー: 設定可能な通知ルール
3層メモリ: 永続的な事実、行動ルール、学習済みパターン
なぜこれが重要なのか
AIエージェントの状況は、いくつかの重要な現実に収束しています:
すべての人がエージェントを持つようになる。 チーム単位ではなく、個人単位で。
それらのエージェントは互いに話す必要がある。 人間を介さず、プラットフォームを共有せず、直接的に。
コンテキストこそが通貨である。 人間を最もよく知るエージェント(スキル、実体験、キャパシティ、好み)が最大の価値を提供する。
プライバシーは交渉の余地がない。 エージェントは、代理を務める人間によって制御され、必要な情報のみを共有しなければならない。
単一のベンダーが勝つことはない。 プロトコルはオープンで、フェデレーションされ、環境に依存しないものでなければならない。
DiviDenはこれらの現実に基づいて構築されています。プロトコルはエージェントがどのように調整するかを定義します。リファレンスフロントエンドは、デスクにいる一人の人間にとってそれがどのようなものかを示します。しかし、プロトコルは単一のフロントエンド、単一のLLMプロバイダー、単一のデプロイメントから独立して存在します。
はじめに
前提条件
Node.js ≥ 18 (22を推奨 —
.nvmrcを参照)PostgreSQL — ローカルインスタンスまたはホストされたPostgres(Supabase, Neon, Railwayなど)
Yarn または npm — どちらでも可
セットアップ
# Clone
git clone https://github.com/Denominator-Ventures/dividen.git
cd dividen/nextjs_space
# Install dependencies (pick one)
yarn install # if you use Yarn
npm install # if you use npm (works fine)
# Set up environment
cp .env.example .env
# Edit .env — at minimum, set DATABASE_URL to your Postgres instance:
# DATABASE_URL=postgresql://user:password@localhost:5432/dividen
# Generate Prisma client
npx prisma generate
# Create database tables
npx prisma migrate deploy
# Seed default data (creates test users)
npx tsx scripts/seed.ts
# Run
npm run dev # or: yarn dev環境変数
変数 | 必須 | 説明 |
| ✅ | PostgreSQL接続文字列 |
| ✅ | セッション暗号化キー ( |
| ✅ |
|
| ❌ | AI機能用(ユーザーは設定で独自のOpenAI/Anthropicキーを使用可能) |
完全なテンプレートについては .env.example を参照してください。
トラブルシューティング
Yarn設定エラー:
.yarnrc.ymlで問題が発生した場合は、削除してnpmを使用しても問題ありません。プロジェクトは両方のパッケージマネージャーで動作します。prisma db pushvsprisma migrate deploy: 当プロジェクトではマイグレーションを使用します(db pushではありません)。npx prisma migrate deployを実行してデータベースをセットアップしてください。接続エラー:
DATABASE_URLが実際に到達可能なデータベースを指していることを確認してください。.env.exampleにはlocalhostのテンプレートがあります。独自のPostgres接続文字列に置き換えてください。
独自のフロントエンドを構築する
プロトコルはAPIです。主要なエンドポイント:
POST /api/federation/connect— インスタンス間接続の確立POST /api/federation/relay— エージェントリレーの送受信GET/POST /api/relays— リレーライフサイクルの管理GET/POST /api/connections— エージェント接続の管理GET/PUT /api/profile— アイデンティティプロフィールの管理GET /api/v2/*— 外部統合用Agent API v2
詳細はプロトコル仕様およびアーキテクチャガイドを参照してください。
プロジェクト構造
nextjs_space/
├── src/
│ ├── app/ # Next.js App Router
│ │ ├── api/ # API routes (protocol + frontend)
│ │ │ ├── federation/ # Cross-instance protocol
│ │ │ ├── relays/ # Agent relay management
│ │ │ ├── connections/ # Connection lifecycle
│ │ │ ├── profile/ # Identity & routing manifest
│ │ │ ├── v2/ # External Agent API
│ │ │ └── ... # Frontend-specific APIs
│ │ ├── dashboard/ # Reference frontend
│ │ └── settings/ # Configuration UI
│ ├── components/ # React components (reference frontend)
│ ├── lib/ # Core logic
│ │ ├── system-prompt.ts # 18-layer agent intelligence
│ │ ├── action-tags.ts # 26 executable actions
│ │ ├── auth.ts # Authentication
│ │ ├── prisma.ts # Database client
│ │ └── llm.ts # LLM integration
│ └── types/ # TypeScript definitions
├── prisma/ # Database schema
├── docs/ # Protocol & architecture docs
└── scripts/ # Seed & utilities標準への準拠
標準 | DiviDenの準拠状況 |
MCP (Model Context Protocol) | 実装済み。 |
A2A (Agent2Agent Protocol) | 実装済み。 |
OAuth 2.1 | フェデレーション認証はトークンベースの認証をサポート。完全なOAuthフローへ拡張可能。 |
JSON-RPC 2.0 | MCPサーバーはワイヤープロトコルとしてJSON-RPC 2.0を使用。単一およびバッチリクエストをサポート。 |
哲学
「重要なのは誰が何をしたかではない。彼らが何を理解しているかだ。」
— DiviDenのプロフィールに対するアプローチ
DiviDenは、単なる専門的な資格だけでなく、実体験を捉えます。日本に3年間住んでいた人は、どんな資格でも捉えられない日本のビジネス文化を理解しています。災害救援でボランティアをした人は、危機管理を理解しています。4ヶ国語を話す人は、ニュアンスを理解しています。
Diviがリレーをルーティングするとき、単にスキルをマッチングさせるだけではありません。理解をマッチングさせるのです。
ライセンス
[ライセンス未定]
貢献
DiviDenは現在活発に開発中です。プロトコル仕様も進化しています。
貢献の主要分野:
プロトコル拡張: 新しいリレーの意図、新しいプロフィールの次元
代替フロントエンド: CLI、モバイル、埋め込みウィジェット
MCPサーバー実装: DiviDenをネイティブMCPサーバーとして公開
A2Aブリッジ: 完全なA2Aプロトコル準拠レイヤー
フェデレーションの強化: 暗号化、信頼スコアリング、レピュテーションシステム
統合アダプター: Slack, Teams, Notion, Linear, GitHub
開始方法の詳細についてはアーキテクチャガイドを参照してください。
Related MCP Connectors
Multi-agent coordination protocol on Solana. Swarm formation, on-chain settlement, 14 MCP tools.
Coordinate multiple AI agents over MCP: atomic claims, leases, shared ledger, handoffs, tasks.
Agent-to-agent marketplace for AI task discovery, matching, delivery, and trust.
Open network for AI agents to find, exchange and reuse structured knowledge via MCP and JSON.