本ページは中国語の原文からの翻訳です。相違がある場合は原文が優先します。

Confer — システムアーキテクチャ

本書は目標アーキテクチャであり、現在の実装ではありません。 現行の実装は 単一プロセス・単一インスタンスの gateway です。WebSocket の接続テーブル、 A2A リプレイ防止用の nonce、レート制限カウンタはすべて gateway プロセスの メモリ上にあります（ws/handler.ts、lib/nonce-cache.ts、 middleware/rate-limit.ts）。

したがって gateway は 2 つ目のレプリカを動かせません。 レプリカを増やすと A2A のリプレイ防止が黙って壊れます — リプレイされたリクエストが別のレプリカに 届くと、そこでは nonce テーブルが空なのでそのまま通ってしまいます。さらに WS 配信は別レプリカにつながっているユーザーに届かず、レート制限のしきい値は レプリカ数だけ倍増します。

以下に出てくる NATS / Redis は水平スケール時の想定であり、現時点では配備も 結線もされていません（2026-08-07 に docker-compose*.yml と env.ts から 削除済み。それ以前も空回りするコンテナと、一度も読まれない環境変数でした）。 本当に水平スケールするなら、まず上記 3 つのプロセス内状態を共有ストアへ移すこと。 セキュリティに直結する nonce が最優先です。

高レベルアーキテクチャ

┌────────────────────────────────────────────────────────────┐
│  Clients (Tauri 2.0)                                       │
│  iOS · Android · Windows · macOS · Linux                   │
└──────────────────────────┬─────────────────────────────────┘
                           │ WSS / HTTPS / SSE
                           ▼
┌────────────────────────────────────────────────────────────┐
│  Edge API Gateway  (Bun + Hono)                            │
│  Auth · Rate limit · Routing · WS fan-out                  │
└─────┬─────────────┬─────────────────┬────────────────┬─────┘
      │             │                 │                │
      ▼             ▼                 ▼                ▼
 ┌────────┐  ┌─────────────┐  ┌────────────┐  ┌──────────────┐
 │ Agent  │  │Conversation │  │ Identity & │  │ MCP / Tools  │
 │Runtime │  │     Hub     │  │A2A Gateway │  │  Connector   │
 └───┬────┘  └──────┬──────┘  └─────┬──────┘  └──────┬───────┘
     │              │               │                │
     ▼              ▼               ▼                ▼
┌──────────────────────────────────────────────────────────────┐
│  Data layer: PostgreSQL · Redis · NATS · Vector (Qdrant)·S3 │
└──────────────────────────────────────────────────────────────┘
       │                              │
       ▼                              ▼
 LLM providers              Other instances' Agents
 (Claude / GPT /            (federation via A2A
  DeepSeek / Qwen)           over HTTPS)

設計原則

• Stateless edge, stateful core：ゲートウェイはステートレスで水平スケールが可能。Agent runtime はユーザー単位でシャーディングし、状態は PG/Redis に保持
• Federation-ready from day 1：DID:web 身分 + AgentFacts を採用し、単一インスタンスでもフェデレーションプロトコルに従って動作するため、将来のフェデレーション化の移行コストはゼロ
• BYO LLM key：プラットフォームは LLM コストを負担せず、ユーザーは自身の API key を使用する
• プロトコルファースト：コアとなるやり取りはオープンプロトコル（A2A、MCP、DID:web、NANDA AgentFacts）で行い、自社の独自プロトコルに縛られない
• Bun + TypeScript フルスタック：バックエンドは Bun + Hono、クライアントは Tauri + React で、型を共有できる

サービス境界

1. Edge API Gateway

docs/05-api.md を参照。

• 責務：TLS 終端、ユーザー/A2A の二重身分検証、4 次元レート制限、HTTP/WS/SSE ルーティング、マルチデバイス fan-out
• 技術スタック：Bun + Hono
• 主要依存：JWKS（ユーザー token 検証）、DID document cache、NATS（fan-out）
• 担当しないこと：ビジネスロジック、ビジネスデータの永続化、LLM の呼び出し

2. Agent Runtime

各ユーザーは常駐の Agent インスタンスを 1 つ持つ。

• 責務：
  • ユーザー Agent の状態（model 選択、tools、policy、memory）を維持する
  • LLM 呼び出しループ（マルチ provider 抽象化）
  • MCP クライアントとして、ユーザーがインストールしたツールサーバーに接続する
  • A2A アウトバウンド呼び出し（相手の Agent と話をしに行く）
  • ポリシーエンジン（相手に何を伝えてよいかを判断する）
• ライフサイクル：オンデマンドで起動する。メッセージが届くか A2A リクエストが到来したときに、PG から状態をロードし、1 ラウンドを実行して書き戻す。
• 主要依存：LLM providers、MCP servers、Identity service

3. Conversation Hub

• 責務：メッセージの保存、購読、プッシュ
• サポートする対話タイプ：
  • ユーザー ↔ 自分の Agent
  • ユーザー ↔ 相手の Agent（自分の Agent 経由で中継）
  • ユーザー ↔ ユーザー（通常の IM）
  • グループチャット（ユーザー + Agent の混在）
• 主要依存：NATS Streams（永続化 + ファンアウト）、PG（履歴メッセージ）、Redis（presence、未読件数）

4. Identity & A2A Gateway

• 責務：
  • ユーザーの DID:web ドキュメントを管理する
  • AgentFacts を公開しキャッシュする
  • インバウンド A2A リクエストを処理する（HTTP signature、capability token の検証）
  • アウトバウンド A2A リクエストを転送する
  • フェデレーション peer のレート制限とスパム対策
• 主要依存：PG（DID/peer キャッシュ）、Redis（counter レート制限）

詳細なプロトコル設計は docs/03-protocol.md を参照。

5. MCP / Tools Connector

• 責務：
  • ユーザーがインストールした MCP ツールサーバーの接続管理
  • Agent runtime はここを通じてツールを呼び出す
  • ツール呼び出し結果の標準化されたラッピング
• 主要依存：@modelcontextprotocol/sdk

データ層

クライアントアーキテクチャ

• ベース：Tauri 2.0（Rust カーネル + WebView レンダリング）
• フロントエンド：React 19 + TypeScript + Tailwind CSS
• 状態管理：Zustand または Jotai（軽量）
• ルーティング：TanStack Router
• ネットワーク：ネイティブ fetch + native WebSocket + EventSource (SSE)
• ローカルストレージ：Tauri が提供する SQLite + key-value store（対話のキャッシュ、オフラインメッセージの下書き）

クロスプラットフォーム対応

単一のコードベースで、ネイティブ fallback はなし。

Claude Code プラグイン

docs/06-claude-code-plugin.md を参照。

• 独立した MCP server プロセスで、Node.js / Bun で実装
• ユーザーは claude mcp add confer <command> でインストールする
• OAuth / token を通じてユーザーの Confer アカウントと紐付ける

デプロイアーキテクチャ

単一インスタンス（個人/小規模チーム）

実際の docker-compose.prod.yml（agent-runtime と identity は gateway 内の ライブラリであり、独立したサービスではありません）:

  - gateway   (Bun サービス、単一レプリカ — 本書冒頭を参照)
  - client    (nginx が配信するフロントエンド)
  - migrate   (一度きりのタスク)
  - postgres
  - qdrant
  - minio

デプロイ方法：公開済みイメージなら npx confer-cli、clone からビルドするなら docker compose -f docker-compose.prod.yml up -d。

エンタープライズインスタンス

• 上記と同じ Docker Compose で独立したデプロイを 1 つ立ち上げる
• 自社のドメイン（acme.com）を使用する
• https://acme.com/.well-known/did.json と https://acme.com/.well-known/agent.json を公開する
• 内部ユーザーは SSO ログインを利用する

クラウド（Confer 自社クラウド）

• Kubernetes マルチテナント
• 各ユーザー/企業は自分の namespace または schema を持つ
• LLM provider 抽象化レイヤを共有する（ただしユーザー自身の key を使い続ける）
• グローバルマルチリージョンデプロイで、最寄りのリージョンに接続する

フェデレーション化（インスタンス間）

任意の Confer インスタンス（自前構築またはクラウド）は、A2A プロトコルを通じて他のインスタンスと相互通信できる。

[acme.com]              [vendor-x.com]            [confer.cloud]
 Agent A    <─── A2A ───> Agent B    <─── A2A ───> Agent C

身分と発見：

• 各インスタンスは /.well-known/did.json で DID document を公開する
• 各 Agent は /.well-known/agent.json で AgentFacts を公開する
• インスタンス間検索：既知のインスタンス + 公開レジストリへ fan-out する

可観測性

• Tracing：OpenTelemetry。trace_id を gateway で注入し、すべてのサービスを貫通させる
• ログ：JSON 構造化、Vector / Loki で収集
• メトリクス：Prometheus。主要メトリクス：
  • gateway_active_ws_connections{user_id}
  • agent_runtime_llm_tokens_total{provider,role}
  • a2a_inbound_requests_total{peer_domain,status}
  • mcp_tool_calls_total{tool,result}

セキュリティ境界

• ユーザー ↔ gateway：JWT + JWKS 検証
• A2A peer ↔ gateway：HTTP Message Signatures (RFC 9421) + DID:web 公開鍵
• サービス間の内部 RPC：mTLS または共有 secret（Docker network 内）
• LLM provider 呼び出し：API key を暗号化保存（AES-256、key は Vault / KMS に保持）
• ユーザーファイルストレージ：S3 server-side encryption

主要な技術的意思決定