continuum

Services — continuum

Project: continuum Phase: INCEPTION — Application Design Date: 2026-05-08 Depth: Comprehensive

Note: 本ドキュメントは 論理サービス層 を定義する。物理 Lambda 関数の集合ではなく、ユースケースを統合的にオーケストレーションする論理単位として記述する。各サービスは複数のコンポーネントを協調させて1つのビジネスゴールを達成する。

1. Service Layer Overview

論理サービスを 6つ 定義：

Service ID Service Name スコープ 主担当コンポーネント
S-1 UserAccountService ユーザー認証・プロファイル・Maturity 状態 C-BE-01 AuthHandler, C-BE-06 MaturityPhaseManager
S-2 ContactManagementService コンタクト・モックフィードの管理 C-BE-02 ContactHandler, C-BE-10 MockSocialFeedSeeder
S-3 InboundCommunicationService 受信メッセージへの応答（Inbound Arm） C-BE-03 InboundResponseEngine, C-BE-06 MaturityPhaseManager
S-4 OutboundCommunicationService 能動的接触（Outbound Arm） C-BE-04 OutboundOrchestrator, C-BE-05 SignalExtractor, C-BE-06 MaturityPhaseManager
S-5 FederatedCoordinationService MACP（Federated Layer） C-BE-07 MACPCoordinator, C-BE-04 OutboundOrchestrator
S-6 AnalyticsService ダッシュボード・KPI・バッジ C-BE-08 DashboardEngine, C-BE-06 MaturityPhaseManager

横断インフラ: WebSocketBroker (C-BE-09) は全サービスから利用される配信レイヤー。

2. S-1: UserAccountService

責務

主要ユースケース

Orchestration Pattern

サービス間連携

3. S-2: ContactManagementService

責務

主要ユースケース

Orchestration Pattern

4. S-3: InboundCommunicationService（Inbound Arm）

責務

主要ユースケース

UC-3.1: メッセージ受信 → 応答生成（Lv1 慎重期）

  1. Frontend が GET /inbox で受信ボックス取得（FR-1）
  2. ユーザーがメッセージ詳細を開く
  3. Frontend が POST /inbound/{id}/generate 呼び出し
  4. InboundResponseEngine が起動:
    • ContactHandler から相手のプロファイル取得
    • AgentCore Memory から過去応答履歴を取得（Context Injection）
    • Bedrock LLM で 3バリエーション（Conservative/Pragmatic/Cordial）生成
    • Relational Calibration: 関係カテゴリに応じてトーン調整
    • Plausibility Constraint: 案間の類似度 0.7 以下を担保（不整合時は再生成）
  5. Frontend に 3案返却
  6. ユーザーが選択 → 編集（Lv1 のみ） → 送信
  7. 送信時: メッセージステータスを responded 化 + AgentCore Memory に履歴永続化 + DashboardEngine の counter +1

UC-3.2: 自動応答（Lv2-5）

UC-3.3: 応答スタイル再生成（プロファイル更新時）

Orchestration Pattern

サービス間連携

5. S-4: OutboundCommunicationService（Outbound Arm）

責務

主要ユースケース

UC-4.1: Strategic Outreach Generation

  1. OutboundOrchestrator が scheduleStrategicOutreach(userId) を起動（バッチ or イベントトリガー）
  2. ユーザーの全コンタクトに対し:
    • SignalExtractor が Mock Social Feed を解析 → Availability Windows を取得
    • Confidence ≥ 0.7 の Window を Optimal Outreach Window として確定（US-4.1）
  3. 各 Window に対し:
    • Bedrock で誘い文を生成（FR-8.1, US-4.2）
    • Plausibility Constraint チェック（直近30日内に同種誘いなし）
    • Conflict Detection: Inbound 履歴と整合性確認（US-4.4）
    • Plausibility Engineering: 送信時刻のランダム化、文体学習適用（US-4.5）
  4. 候補を outbound_pending 状態で永続化
  5. MACP 試行: FederatedCoordinationService に試行依頼
    • MACP 不成立 → そのまま Outbound 候補として残存
    • MACP 成立 → MACP Session の Theatrical メッセージとして登録、通常 Outbound から除外

UC-4.2: Engagement Heartbeat Scheduling

UC-4.3: Outbound Pre-send Review (Lv1-2)

UC-4.4: Scheduled Delivery

Orchestration Pattern

サービス間連携

6. S-5: FederatedCoordinationService（Federated Layer / MACP）

責務

主要ユースケース

UC-5.1: MACP Trigger（Outbound 送信前）

  1. OutboundOrchestrator から MACPCoordinator.attemptMACP(candidate) 呼び出し
  2. Peer Discovery（FR-9.2）:
    • コンタクトのメールアドレスを SHA256 ハッシュ化
    • AgentCore Identity で Continuum Subscriber Registry を Lookup
    • ヒットしない場合: null 返却 → 通常 Outbound フローへ復帰
  3. Inter-Agent Negotiation（FR-9.3）:
    • AgentCore Gateway 経由で相手テナントの MACPCoordinator に接続
    • JSON プロトコル（Mutual Decline Intent / Theater Topic / Duration / Cadence / Tone / Resolution Pattern / Privacy Boundaries）を交換
    • 合意成立: MACPSession 作成、AgentCore Memory に永続化
    • 合意不成立: 通常 Outbound へ復帰
  4. Theatrical Performance Scheduling（FR-9.4）:
    • 合意済み脚本の各メッセージを EventBridge スケジュール送信
    • 各メッセージは自然な遅延（数時間〜数日）で順次配信
  5. Outcome Confirmation（FR-9.5）:
    • 全メッセージ送信完了後、両テナントの DashboardEngine に “Bilateral Optimization Specialist” バッジを同期付与
    • WebSocketBroker 経由で両ユーザーに完了通知
  6. AgentCore Memory に MACP 履歴永続化（次回同一ペアでの効率化のため）

UC-5.2: Failure Handling

Orchestration Pattern

サービス間連携

7. S-6: AnalyticsService

責務

主要ユースケース

UC-6.1: Dashboard 表示（Frontend Pull）

UC-6.2: バッジ付与（イベント駆動）

UC-6.3: Recommendation 表示判定

Orchestration Pattern

サービス間連携

8. Service Orchestration: End-to-End Flow Examples

8.1 Flow A: Lv1 ユーザーが受信 → 応答（最頻フロー）

[Frontend InboxView]
  │ GET /inbox
  v
[S-3 InboundCommunicationService]
  │ list messages from DynamoDB
  v
[Frontend InboxView] (display)
  │ POST /inbound/{id}/generate
  v
[S-3 InboundCommunicationService]
  │ check Maturity Phase (S-1.MaturityPhaseManager) → Lv1
  │ fetch contact (S-2.ContactHandler)
  │ fetch past interactions (AgentCore Memory)
  │ Bedrock LLM call (3 variations)
  │ apply Relational Calibration
  │ validate Plausibility Constraint
  v
[Frontend InboxView] (display 3 variations)
  │ user selects + edits + sends
  │ POST /inbound/{id}/send
  v
[S-3 InboundCommunicationService]
  │ persist to DynamoDB (responded)
  │ persist to AgentCore Memory
  │ event: response.sent → S-6 AnalyticsService
  v
[S-6 AnalyticsService]
  │ counter +1
  │ check badge conditions (5 件達成 → Recommendation Lv2)
  │ WebSocketBroker push to user

8.2 Flow B: Outbound Strategic Outreach + MACP Trigger

[Daily Batch: EventBridge → S-4 OutboundCommunicationService.scheduleStrategicOutreach]
  │ for each contact:
  │   S-5 SignalExtractor.extractWindowsForContact(contactId)
  │   filter Confidence >= 0.7
  │   for each Optimal Window:
  │     generate invitation text (Bedrock)
  │     check Plausibility Constraint
  │     check Conflict (Inbound history)
  │     apply Plausibility Engineering (timing + style)
  │   create OutboundCandidate
  v
[S-5 FederatedCoordinationService.attemptMACP(candidate)]
  │ Peer Discovery via AgentCore Identity
  │ if Continuum user:
  │   negotiate via AgentCore Gateway
  │   if mutual decline intent matches:
  │     create MACPSession
  │     schedule theatrical messages
  │     mark candidate as MACP-handled
  │ else:
  │   leave as normal Outbound
  v
[Outbound Pending or MACP Theater]

8.3 Flow C: Maturity Phase Lv1 → Lv2 推奨 → 移行

[ユーザーが累計5件目の応答完了]
  v
[S-3 InboundCommunicationService → S-1 MaturityPhaseManager.incrementResponseCount]
  │ totalResponses = 5
  │ check threshold → Lv2 推奨
  v
[S-6 AnalyticsService.recommendationAvailable]
  │ WebSocketBroker push to user
  v
[Frontend DashboardView] displays banner
  │ ユーザーが "Move to Trust Phase" をタップ
  │ PUT /maturity/phase { targetPhase: "Lv2" }
  v
[S-1 MaturityPhaseManager.changePhase]
  │ confirmation modal
  │ update DynamoDB
  │ award "Adaptive Delegation Specialist" badge
  v
[Frontend] receives confirmation, UI updates to Lv2 mode

8.4 Flow D: Lv5 Auto-Detection（日次バッチ）

[EventBridge Scheduler: daily 03:00 JST]
  v
[S-1 MaturityPhaseManager.detectNirvanaCandidates]
  │ query DynamoDB: WHERE phase = Lv4 AND consecutiveDays >= 30 AND lastAppOpenAt < now - 7d
  │ for each candidate:
  │   promoteToLv5(userId)
  │   stop push notifications
  │   stop monthly summary
  │   internal counter: daysInNirvana += 1 (daily)
  v
[ユーザーがアプリを起動]
  │ POST /me (any API call)
  v
[S-1 MaturityPhaseManager.handleAppOpen]
  │ if currentPhase == Lv5:
  │   demote to Lv4
  │   record lifetime daysInNirvana
  │   award "Transcendence Achieved" badge (if not awarded)
  v
[Frontend] displays "Days in Nirvana: N" + 認定バッジ

9. Transaction Boundaries

Service トランザクション粒度 整合性レベル
S-1 UserAccountService 単一ユーザーの状態更新 Strong（DynamoDB Conditional Write）
S-2 ContactManagementService 単一コンタクトの CRUD Strong
S-3 InboundCommunicationService 単一メッセージの応答送信 + 履歴永続化 Eventual（Memory 永続化は async OK）
S-4 OutboundCommunicationService 単一 Outbound 候補の生成・スケジュール Eventual
S-5 FederatedCoordinationService MACP Session 全体（複数ステップ） Eventual + Saga パターン（失敗時 abort）
S-6 AnalyticsService 集計結果（読み取り中心） Eventual（多少の遅延許容）

10. Service Discovery & Configuration

This site is open source. Improve this page.