Application Design Plan — continuum

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

目的

要件定義（requirements.md）と38ストーリー（stories.md）を基に、本作品の コンポーネント構造・メソッド・サービス層・依存関係 を高レベルに設計する。3層アーキテクチャ（Inbound / Outbound / Federated）+ 共通基盤を、AI フル実装（Q12=C）と AWS Bedrock + AgentCore 必須採用（Q5）の前提で構造化する。

Mandatory Design Artifacts（必須生成物）

• aidlc-docs/inception/application-design/components.md — コンポーネント定義 + 高レベル責務
• aidlc-docs/inception/application-design/component-methods.md — メソッドシグネチャ + 入出力
• aidlc-docs/inception/application-design/services.md — サービス層定義 + オーケストレーションパターン
• aidlc-docs/inception/application-design/component-dependency.md — 依存関係マトリクス + 通信パターン + データフロー
• aidlc-docs/inception/application-design/application-design.md — 統合ドキュメント

Step-by-Step Execution Plan

• Step 1: コンポーネント識別（高レベル責務の単位で分解）
• Step 2: コンポーネントごとのメソッド定義（業務ルール詳細は Functional Design に委ねる）
• Step 3: サービス層の設計（オーケストレーション・トランザクション境界）
• Step 4: コンポーネント間の依存関係マトリクス + データフロー図
• Step 5: 統合ドキュメント作成

質問（Embedded Questions）

以下の質問にお答えください。各 [Answer]: タグの後に該当する選択肢の文字を記入してください。特に Q1-Q3 は AI への技術選定委任（Q13=D）の中で「これだけは指定したい」項目です。該当しない場合は Other を選び説明を記入してください。

Question 1: 全体アーキテクチャスタイル

バックエンドの全体アーキテクチャは？

A) Serverless First（推奨） — AWS Lambda + API Gateway + DynamoDB の完全サーバーレス構成。コスト・スケール・運用負荷で有利、ハッカソン PoC との整合性が高い B) Modular Monolith — 1つの Container（ECS/Fargate）で全機能を担う、ローカル開発容易・デバッグ容易 C) Microservices on ECS/EKS — 各 Service を独立 Container として運用、本番志向だがハッカソンスコープでは過剰 D) AI 委任（Q13=D 通り） — 推奨案を AI が決定、ハッカソン制約を最大限考慮（応募締切2日・MVP 2週間） E) Other (please describe after Answer: tag below)

Question 2: Frontend アーキテクチャ

PWA（Q4=C）として実装する Frontend の構成は？

A) Next.js + AWS Amplify Hosting — フルスタック TypeScript、CDK 連携・PWA 対応容易 B) Vite + React + S3 + CloudFront — 軽量 SPA、静的配信、PWA 対応は手動 C) Next.js (Static Export) + S3 + CloudFront — Next.js の静的書き出しで CDN 配信 D) Remix + AWS Amplify — モダンな Web 標準準拠 E) AI 委任 — 上記から最適な選択を AI が決定 F) Other (please describe after Answer: tag below)

Question 3: Backend Service 境界（コンポーネント分解の粒度）

Backend サービスの分解粒度は？

A) Coarse-grained（粗粒度） — 機能領域単位で 5〜7 個の Lambda 関数（InboundHandler / OutboundHandler / MACPHandler / DashboardAPI / AuthHandler 等）。シンプル B) Fine-grained（細粒度） — エンドポイント・ユースケース単位で 15〜25 個の Lambda 関数。明確な責務分離だが管理が増える C) Per-Use-Case（中粒度） — 主要ユースケース単位で 8〜12 個（推奨：管理しやすさと明確さのバランス） D) AI 委任 — Unit 単位で AI が判断 E) Other (please describe after Answer: tag below)

Question 4: Inter-Service Communication / Eventing

サービス間通信パターンは？

A) Synchronous (REST + Direct Lambda Invoke) — シンプル、低レイテンシ、ハッカソンPoC適合 B) Event-Driven (EventBridge + Async) — Outbound のスケジューリング、Heartbeat、MACP の遅延送信などが自然に乗る、本格的だがデバッグ複雑 C) Hybrid（推奨） — Sync REST が主、非同期処理（スケジュール送信・MACP ネゴシエーション・遅延送信）のみ EventBridge D) AI 委任 E) Other (please describe after Answer: tag below)

Question 5: DynamoDB データモデル設計方針

データストア（DynamoDB）の設計方針は？

A) Single-Table Design（推奨） — DynamoDB ベストプラクティス。1テーブルで全エンティティ、PK/SK のマルチアクセスパターン。学習コスト高だがスケーラブル B) Multi-Table Design — エンティティごとにテーブル分離（Users / Contacts / Messages / SocialFeeds / MACPSessions）。シンプル、ハッカソンスコープ向き C) AI 委任 — Unit 単位で AI が判断 D) Other (please describe after Answer: tag below)

Question 6: MACP のリアルタイム可視化（決勝デモ Split-Screen）

決勝 Demo Set Piece（DS-3 Split-Screen）で、両ユーザー画面 + Inter-Agent Negotiation Log をリアルタイム表示する仕組みは？

A) WebSocket (API Gateway WebSocket API) — 両クライアントへリアルタイムプッシュ、デモのインパクト最大化 B) Server-Sent Events (SSE) — 単方向でも演出には十分、シンプル C) Polling (毎秒) — 簡易、ハッカソンスコープ十分 D) AI 委任 E) Other (please describe after Answer: tag below)

Question 7: AgentCore の利用構成

Amazon Bedrock AgentCore の主要サービスのうち、どこまで使うか？（複数選択可）

A) AgentCore Runtime — エージェント実行基盤（Inbound/Outbound 応答生成エージェント） B) AgentCore Memory — 過去のやり取り・MACP 交渉履歴の永続化 C) AgentCore Identity — テナント間認証（MACP Peer Discovery / Federated 通信） D) AgentCore Gateway — エージェント間通信ゲートウェイ（MACP Inter-Agent Negotiation） E) AgentCore Browser Tool — Mock SNS Feed の本番リファレンス架空のため、デモでは使用せず（ただしアーキ図では言及） F) AgentCore Code Interpreter — 不要 G) Other (please describe after Answer: tag below — 複数選択する場合は全て記載)

Question 8: 認証・認可の方式

ユーザー認証・認可の構成は？

A) Amazon Cognito User Pool + JWT (推奨) — マネージド、サインアップ/ログイン/トークン発行が完結 B) Cognito + Identity Pool — IAM ロール統合、AWS リソース直叩き想定の場合 C) AI 委任 D) Other (please describe after Answer: tag below)

Question 9: ロギング・モニタリング深度

Phase 2 / Phase 3 でのロギング・モニタリング深度は？

A) Minimal（CloudWatch Logs のみ） — Lambda 標準ロギング、デバッグ目的のみ。MVP 適合 B) Standard（CloudWatch + X-Ray） — 分散トレーシング含む、Phase 3 決勝向け C) Comprehensive（+ CloudWatch Dashboards + Alarms） — 本番運用品質、ハッカソンスコープでは過剰 D) Phase 別: Phase 2 = A, Phase 3 = B（推奨） E) Other (please describe after Answer: tag below)

Question 10: モノレポ構成

リポジトリ構成は？

A) Monorepo (npm/pnpm workspaces) — Frontend / Backend / IaC を1リポジトリで管理（推奨：管理が容易） B) Multi-repo — Frontend / Backend / IaC を別リポジトリ C) AI 委任 D) Other (please describe after Answer: tag below)

Approval Required

すべての質問に回答後、「完了」または「done」 とお知らせください。回答内容を分析し、矛盾・曖昧さなしの場合は本プランの承認をお願いします。承認後、Step 10（components.md / component-methods.md / services.md / component-dependency.md / application-design.md の生成）に進みます。