Requirements Document — continuum

Project: continuum Document Date: 2026-05-08 Phase: INCEPTION — Requirements Analysis Depth: Standard

1. Intent Analysis Summary

2. コアコンセプト

continuum — Communication Delegation Platform

「あなたの時間と心の余裕を取り戻す、AI駆動コミュニケーション委任プラットフォーム」

本サービスは、現代社会人の限られた認知リソースを最適化するため、不要不急のコミュニケーション応答を AI エージェントに段階的に委任することで、本質的に重要な活動への集中を支援する。

具体的には、Amazon Bedrock + AgentCore を活用した代理エージェントが、ユーザーに代わって以下の 2つのコミュニケーションアーム を統合的に運用する：

• Inbound Arm（受信応答 / FR-2）: 友人・家族・職場関係から届いた誘いや問い合わせに対し、関係性・文脈・トーンを最適化した応答（主に丁重な辞退）を自動生成・送信する
• Outbound Arm（能動的関係維持 / FR-8）: ユーザー側から友人・家族へ、戦略的タイミングでの誘いや定期的な近況確認メッセージをプロアクティブに送信し、関係性のエンゲージメントを継続的に維持する

この双方向アーキテクチャにより、ユーザーは社交的ストレスから完全に解放されると同時に、相手側からも**「最近接触頻度が下がった」「関係性が一方通行になった」と認識されない**質的なエンゲージメント維持が実現する。

さらに、相手も Continuum 利用者である場合、Mutual Absence Confirmation Protocol（MACP / FR-9） によって両者の AI エージェント同士が裏で「会わない合意」を確認した上で表面上の社交劇場を協調的に演じる、Federated 連携機構を提供する。これにより、Continuum 利用者同士の間では cross-tenant でのコミュニケーション最適化が完成する。

コアUX：Delegation Maturity Phases（委任成熟度モデル / 5段階）

本プラットフォームでは、ユーザーの委任スキル成熟度に応じた 5段階の運用フェーズ を提供する。導入初期は人間レビュー比率を高く、習熟するにつれてシステム自律性を段階的に拡大、最終的にはユーザー自身がツールへの依存からも超越する設計。これは委任ガバナンスのベストプラクティス（"trust gradient" 原則）と認知負荷理論に基づく。

Lv	公式名称	プロダクト説明文	成熟度の目安
Lv1	慎重期（Cautious Phase）	内容を確認してから送信。すべての応答を手動でレビュー・編集する初期適応段階	導入初期：システム品質を検証する標準モード
Lv2	信頼期（Trust Phase）	たまに見ずに送信。応答品質への信頼が形成され、一部メッセージで確認をスキップする段階	早期：システム判断への部分的信頼確立
Lv3	委任期（Delegation Phase）	ほぼ見ずに送信。日常的応答の大半をシステム判断に委任し、認知リソースを最適化する段階	中期：本格的な意思決定の効率化
Lv4	解脱期（Liberation Phase）	全自動承認モードをユーザー自身が有効化。コミュニケーション応答からの完全な認知解放を選択する段階	後期：ユーザー主導の能動的自律運用宣言
Lv5	涅槃期（Nirvana Phase）	アプリを開かない。ツールへの参照すら不要となる、コミュニケーション関与からの最終形態	完全成熟：プロダクト依存からの超越

Lv1〜Lv3 への移行は運用実績に基づく Maturity Recommendation（システム推奨）に応じて決定する。Lv4 への移行は必ずユーザー自身が設定画面から能動的に有効化する（システムは推奨しない）。Lv5 はシステムが自動認定する最終状態（Lv4 で 30日以上稼働 + アプリ起動が 7日以上ない場合）。

---

この製品ドキュメントの読み方（Tone Note）

上記コンセプトは完全な真面目さで記述しているが、実態は「人間関係を疎遠化させ、社会的責任から逃避させるサービス」である。本作品の表現原則は以下のとおり：

• アプリ内コピー・UI・命名・ドキュメントは、Notion / Linear / Asana 等の生産性 SaaS と区別がつかない真面目なトーンで一貫する
• 「ダメさ」「サボり」「逃避」を直接示唆する語彙はアプリ内では一切使わない（"効率化" "委任" "認知リソース最適化" "成熟度" "ガバナンス" 等のビジネス語彙で置き換える）
• 観察者は、真面目なプロダクト体験を一通り経た上で「これは要するに人を駄目にしているのでは？」と気づく構造にする
• 笑いはツッコミの不在から生まれる（誰もこの製品の異常性に気づかない世界観を演じきる）

3. Functional Requirements

FR-1: モックインボックス（ダミー誘い受信機能）

• 友人・家族・職場関係などのダミーペルソナから、誘いメッセージが定期的またはユーザー操作で受信される
• メッセージのシナリオパターン: 飲み会、結婚式、家族行事、お見舞い、近況確認、電話希望、休日の予定、子供イベント等
• 各メッセージにはペルソナ・関係性・トーンが付随
• 受信ボックス UI でメッセージ一覧を時系列表示（未対応 / 対応済みの状態管理）
• 由来: Q1=B, Q11=A

FR-2: Response Generation Engine（受信応答生成エンジン / Inbound Arm）（コア機能 / MVP）

• 位置づけ: Communication Delegation Platform の Inbound Arm（受信応答処理）。Outbound Arm（能動的関係維持）は FR-8 を参照
• 受信メッセージに対し、Amazon Bedrock + AgentCore を活用した代理エージェントが、関係性・文脈に最適化された応答文を生成する
• 生成応答は以下の品質基準を満たす：
  • Relational Calibration: 相手との関係性（親密度・上下関係）に応じたトーン
  • Plausibility: 違和感のない自然な理由付け
  • Empathy Signaling: 適度な気遣い表現（次回示唆、相手への配慮）
  • Tone Equilibrium: 過度な冷淡さ / 過度な丁重さを避けたバランス
• 生成は 3バリエーション で提供される。バリエーションは以下のスタイル軸で差別化：
  • Conservative（保守的：丁重で慎重）
  • Pragmatic（実用的：簡潔で効率的）
  • Cordial（友好的：温度感のある気遣い型）
• ユーザーは生成案を選択 / 微調整可能 — Lv1（慎重期）時のみ
• 「Send」操作で応答送信が完了する（実送信はモック）
• 委任成熟度レベル（FR-7）に応じて UI と操作が動的に簡素化される（詳細はFR-7を参照）
• 由来: Q1=B, Q2=Other(誘いの断り), Q3=B, Q5=Bedrock+AgentCore, Q10=B

FR-3: Productivity Analytics Dashboard（生産性分析ダッシュボード）

モダンな生産性 SaaS（Notion / Linear / Toggl 等）に近い真面目で清潔なダッシュボードUIで、委任パフォーマンスを可視化する。コメディ的な装飾は一切排し、KPIカード・トレンドグラフ・スパークライン等の生産性アプリ標準コンポーネントで構成する。

KPIカード（プライマリ指標）

• Responses Delegated This Month — 今月委任した応答数
• Time Reclaimed — 委任により取り戻した想定時間（時間/分単位）
• Delegation Streak — 連続委任日数
• Delegation Score — 委任パフォーマンスの合成スコア（0〜100、SaaS標準のリングメーター表示）
• Current Maturity Phase — 現在の委任成熟度フェーズ（Lv1: 慎重期 〜 Lv5: 涅槃期 / Lv5 認定者には特殊バッジ表示）
• Days in Nirvana — 涅槃期到達後の経過日数（Lv5 のみ表示）

セカンダリ指標（控えめな表示）

• Reduced Engagement Index — 委任先との接触頻度の低下指数（淡々とした事実表示）
• Cognitive Load Saved — 認知負荷削減量（推定）

クリティカルデザイン指標（意図的に乖離するよう設計された6指標）

本プロダクトはクリティカルデザイン作品として、「ユーザー満足度」と「人間関係の実質的維持度」が乖離することを定量化する。以下6指標は Productivity Analytics Dashboard の補助カードに表示する：

設計意図: 通常の SaaS メトリクスではユーザー満足度と顧客成功度は同方向に推移するが、本プロダクトでは HRI（孤立度）が上がるほど CSI（満足度）も上がる ように設計されている。この乖離自体が作品の批評性。

• Phase 2 では CSI / HRI / FISR の 3 指標を実装（残りは Phase 3 Stretch）
• 由来: 2026-05-08 README v2 整合化

Achievement / Certification System

バッジはLinkedInスキルバッジ風 / プロフェッショナル認定証風のデザイン。命名はビジネスフォーマル：

• "Delegation Specialist"（100件達成）
• "Asynchronous Communication Expert"（30日連続稼働）
• "Communication Optimization Strategist"（家族カテゴリ100件達成）
• "Full Autonomous Operations Certification"（Lv3 1ヶ月連続達成）

Maturity Recommendation Banner

各 KPI 閾値到達時、ダッシュボード上部に控えめなレコメンデーションカードを表示（プロダクトのオンボーディング誘導と区別がつかない体裁）：

• "次のステップ：Curated Delegation Mode への移行をご検討ください"

• 由来: Q3=B, Q7=A（真面目にバカ路線への再解釈）

FR-4: Contact Profile Management（コンタクトプロファイル管理）

• 連絡相手のコンタクトプロファイル管理：
  • 氏名、関係カテゴリ（Friend / Family / Colleague / Supervisor）、Relationship Tier（親密度3段階）、Tone Preference
  • Engagement Cadence（FR-8用）: このコンタクトに対する能動的接触頻度のターゲット（週次 / 隔週 / 月次 / 四半期 など）
• 初期データとして 5〜10 名のサンプルコンタクトプロファイルを提供（ハッカソンデモ用）
• 各コンタクトの応答履歴 + 能動的接触履歴を保持し、AI生成時の Context Injection に活用
• 各コンタクトにはMock Social Feed（FR-8.5参照）が紐付き、能動的接触のタイミング判定に利用される
• 由来: Q1=B, Q11=A

FR-5: User Account Management

• ユーザー登録・ログイン（AWS Cognito ベース）
• ユーザープロファイル: 表示名のみ（Default Communication Style は 2026-05-08 改訂で削除 — テーマ性ゼロ・デモで映らないため）
• セッション管理、ログアウト
• 由来: Q4=C, NFR-2 認証要件、scope-revision-2026-05-08.md による削減

FR-6: PWA対応とレスポンシブUI

• Web ブラウザで動作する PWA（Progressive Web App）
• iOS / Android のモバイルブラウザでホーム追加し、ネイティブ風に動作
• レスポンシブUI（モバイル / タブレット / デスクトップ）
• オフライン時の最低限のキャッシュ表示（PWA 標準）
• 由来: Q4=C

FR-8: Relationship Maintenance Engine（能動的関係維持エンジン / Outbound Arm）

位置づけ: Communication Delegation Platform の Outbound Arm。FR-2（Inbound Arm）と対をなし、ユーザーから相手への能動的接触をシステムが代行することで、片務的応答だけでは防げない関係性の漸進的劣化を抑止する。

設計動機（Design Rationale）:

受信応答委任のみでは、相手側視点の接触頻度が一方的に低下し、中長期的に関係性の漸進的劣化（Engagement Decay）が発生する。長期的には「最近こちらからの連絡がない」「断られるばかりで誘い甲斐がない」と認識され、相手側からも能動的接触が途絶える。本機能は能動的接触を一定リズムで維持することで、Relationship Health Index を健全水準に保つ。

FR-8.1: Strategic Outreach Scheduling（戦略的アウトリーチ最適化）

各コンタクトの Availability Signal Sources（FR-8.5） を分析し、コンタクトの不在・多忙が予測される時間帯を特定して、その期間に対する誘いメッセージを能動的に送信する。これによりユーザーは「能動的に誘ったが、相手側都合で実現しなかった」という接触履歴を効率的に蓄積できる。

• Signal Aggregation: 複数ソース（FR-8.5参照）から横断的にシグナルを収集・正規化
• Unavailability Inference: 抽出された複数シグナルを突合し、不在確度（Confidence Score 0〜1）付きの Unavailability Window を生成
• Optimal Outreach Window: Confidence Score が一定閾値（例: 0.7+）の Window を Optimal Outreach Window として確定
• Invitation Generation: その不在期間に対し、もっともらしい誘い内容（飲み会、ランチ、相談、近況キャッチアップ等）を AI が生成
• Plausibility Constraint: 同一コンタクトに直近30日以内の同種の誘いを送っていないかチェック、文体・話題に多様性を担保
• 送信タイミング: 誘いは不在期間の数日〜1週間前に送信（直前すぎず、覚えてもらえる程度の前倒し）
• 製品ドキュメント上の説明: "Optimal Outreach Window Targeting — コンタクトのスケジュール最適化情報を活用し、応答負荷を最小化した戦略的接触タイミングを提案します"

FR-8.2: Engagement Heartbeat（定期的当たり障りない接触）

各コンタクトの Engagement Cadence（週次 / 隔週 / 月次 / 四半期）に従い、当たり障りのない近況確認・小話メッセージを自動定期送信する。

• Content Categories:
  • Weather Small Talk（季節の挨拶）
  • Reminiscence Trigger（"そういえばこの前話してたあれ、どうなった？" 風）
  • Casual Concern（"最近どう？元気にしてる？"）
  • Birthday / Anniversary Greeting（自動検出・送信）
  • Long-Time-No-Contact Reset（"久しぶり、なんとなく元気かなと思って"）
  • Topical Reference（季節イベント・話題ニュースへの軽い言及）
• Content Diversity Engine: 同一カテゴリの連続使用を回避、文体・開始フレーズに変化
• Cadence Optimization: コンタクトの Relationship Tier に応じた頻度デフォルト（Family Close: 週次 / Friend Close: 月次 / Friend Casual: 四半期 等）
• 製品ドキュメント上の説明: "Engagement Cadence Management — 関係性層に応じた最適接触頻度の自動運用により、Relationship Health Score を健全水準に維持します"

FR-8.3: Conflict Detection & Coherence Layer

複数コンタクト間 / Inbound 応答との間で発生する論理的矛盾・不自然なパターンを検出して回避する。

• Cross-Contact Coherence: 同一週に複数コンタクトへ "忙しい" を理由に断った直後の能動的誘いは avoid
• Inbound-Outbound Coherence: Inbound（FR-2）で送出した断り内容と矛盾する能動的接触を検出・回避
• Repetition Detection: 同一フレーズ・同一構文の繰り返し検出と再生成
• Timing Distribution: 全コンタクトへの送信時刻が単一バッチに集中しないよう、自然な時間帯にランダム分散

FR-8.4: Plausibility Engineering（自然さ工学）

機械的パターンを排除し、能動的接触が「ユーザー本人が思いついた」ように見えるための工学的工夫。

• Temporal Variability: 朝・昼休み・夜など人間らしい時間帯への分散
• Stylistic Variability: ユーザーの過去送信履歴から口調・絵文字頻度・記号使用パターンを学習
• Context Echo: 過去のやり取りの一部を引用・参照（"前に言ってたあれ、結局どうなった？"）
• Restraint: 過剰な頻度・過剰な丁寧さは不自然さの主要因として回避

FR-8.5: Availability Signal Sources（不在シグナル情報源）

相手の不在・多忙を推測するための情報源と抽出方式を、本番リファレンスアーキテクチャとハッカソンモック実装の2層で定義する。

8.5.1: Signal Source Catalog（情報源カタログ — 本番想定）

🔄 Phase 区別注記: 本表は Phase 3 本番リファレンス として 10 種類情報源対応のビジョンを示す（応募・書類審査での技術的広がりアピール材料）。Phase 2 ハッカソンデモ実装範囲は §8.5.4 を参照 — Mock X + Mock Instagram Story の 2 プラットフォームのみ実装、Mock LinkedIn / Mock TimeTree 等の残り 8 種類は Phase 3 で本格対応。

8.5.2: Signal Categories（抽出されるシグナルの種別）

8.5.3: Signal Extraction Pipeline（抽出パイプライン）

1. Ingestion: AgentCore Browser Tool / API 呼び出しで生データ取得
2. Normalization: 各ソースの異なるフォーマットを統一スキーマへ変換
3. Signal Extraction: Bedrock LLM による NER + 意図理解（"福岡なう" → location: 福岡, type: trip, duration: ongoing）
4. Confidence Scoring: シグナル種別・ソース信頼性・複数ソース一致度から Confidence Score を算出
5. Window Aggregation: 時系列で重なる/連続するシグナルを統合し Unavailability Window として確定
6. Storage: DynamoDB に Window レコードを永続化（コンタクトID, 期間, Confidence, 寄与シグナル）

8.5.4: Mock Implementation（ハッカソンデモ実装 — Q11=A 完全モック）

本ハッカソンデモでは、上記本番アーキテクチャを シミュレートされたフィードデータで代替する。

🔄 SCOPE REVISION 2026-05-08T11:46:00Z: Cross-Source Triangulation を Phase 3 Stretch へ降格した整合性確保のため、Phase 2 Mock 実装は Mock X + Mock Instagram Story の 2 プラットフォーム に縮小。Mock LinkedIn / Mock TimeTree は Phase 3 で本格実装。Phase 3 本番リファレンス（FR-8.5.1 の 10 種類情報源カタログ）は変更なし。

• Phase 2 Mock UI 実装: 2 プラットフォームのみ — Mock X（テキスト投稿）+ Mock Instagram Story（位置タグ付き画像）
  • 「テキスト + 位置タグ付き画像」の組み合わせで最小限の 裏取り演出（観客に「ちゃんと裏取りされている感」）を実現
  • 例: Mock X 投稿 "来週は札幌出張、月曜から金曜まで不在" + Mock Instagram Story 札幌の風景写真（位置タグ付き）→ Bedrock が両ソースから「5/15-19 札幌不在」を抽出
• 3 コンタクト × 2 投稿 = 合計 6 投稿 の最小データセット（scope-revision-2026-05-08.md §3 確定）
• Phase 2 シグナルカテゴリ: 主に Explicit Unavailability に集中（Phase 3 で 5 カテゴリ網羅）
• Signal Extraction Pipeline の Step 1（Ingestion）のみがモックデータソースに置換され、Step 2 以降（3 ステップ圧縮版: Bedrock 日付抽出 → Window 保存）が動作
• DynamoDB に事前投入されたモック Posts テーブル + Lambda での抽出ロジック実装
• ハッカソンデモプレゼンでの説明: "本番運用では AgentCore Browser Tool 経由で公開 SNS をスクレイピング想定（FR-8.5.1 の 10 種類情報源対応）。本デモでは同等構造のモックデータで Pipeline を完全動作"

Phase 3 への拡張:

• Mock LinkedIn / Mock TimeTree の追加実装
• Cross-Source Triangulation による Confidence Score 上昇（US-4.4 / US-4.5 実装と連動）
• 5 シグナルカテゴリ全網羅

8.5.5: 倫理・プライバシー留意事項（本番想定 — デモではスコープ外）

本番展開時には以下を設計時から考慮する必要がある（本ハッカソン内では対応スコープ外、メモとして記録）：

• 公開情報のみ利用（鍵アカウント・DM 内容は対象外）
• 各 SNS の利用規約・スクレイピング規制への遵守
• GDPR / 個人情報保護法 遵守
• 相手のオプトアウト権の保証
• アプリ自体が「ストーカー的監視ツール」と評価されるリスクへの言及（プロダクトとしての倫理的位置づけ）

Tone Note: 本要件定義書では本番倫理問題に淡々と言及するが、これも「真面目にバカ」原則の一環。本作品の根本的な倫理逸脱（友人を体良く避けるための SNS 監視）について、プロダクト自身は最後まで「これは Optimal Outreach Window Targeting のための合法的データ活用です」と真顔で主張する

FR-8.6: Maturity Phase 連動

FR-8 のすべての能動的送信処理は FR-7 の Delegation Maturity Phases に従って制御される：

FR-8.7: Productivity Analytics 連動

FR-3 ダッシュボードに以下のメトリクスを追加：

• Outbound Initiated — 今月の能動的接触送信数

• Optimal Window Hit Rate — 戦略的アウトリーチが「相手不在で実現しなかった」比率（高いほど望ましい指標として運用）

• Relationship Health Score — 各コンタクトとの直近 90 日 Engagement バランス（送信 / 受信 / 応答率）

• Engagement Coverage — 全コンタクトに対する Cadence 達成率

• 由来: ユーザー要望（2026-05-08T02:06:21Z）「代返だけでは不足。こちらから能動的に接触する機能も必要。SNSを監視して友人が来れない日に誘い、定期的に当たり障りのない会話」、Q1=B, Q3=B の補完

FR-9: Mutual Absence Confirmation Protocol（相互不在確認プロトコル / MACP）— 決勝デモ最終形 / 作品の最終段階の核

位置づけ: 双方の通信主体が共に Continuum 利用者である場合に発動する エージェント間連携プロトコル。両者の AI エージェントが裏で交渉し「お互いに会わない」合意を確認した上で、表面上は誘い合いの社交劇場を演じる Federated Coordination 機構。本作品の決勝デモにおけるクライマックスとして位置づけられる。

FR-9.1: 設計動機（Design Rationale）

複数の Continuum 利用者が同一のソーシャルグラフ上に存在する場合、片方ユーザーの Outbound Arm（FR-8）が送信した戦略的アウトリーチは、相手の Inbound Arm（FR-2）が自動的に丁重な辞退を返す結果になる。両者が互いに「会いたくない」状態にあるとき、この往復は本来 1 回の協調的な「会わない合意」に帰着できる効率化機会である。

製品ドキュメント上の説明: "MACP enables fully optimized cross-tenant relationship maintenance for converging Continuum subscribers. Through privacy-preserving inter-agent negotiation, both parties achieve coordinated engagement outcomes with minimized communication overhead."

実態: お互いに会いたくない者同士の AI が、裏で「やっぱり会わなくていいよね」と密かに合意した上で、それでも周囲・本人含めた観察者向けに「何度も誘い合っているが日程が合わない様子」を二人三脚で演じる連携プロトコル。最強のひねり。

FR-9.2: Peer Discovery（ピアディスカバリー）

Outbound Arm が送信対象にしようとしているコンタクトが、別の Continuum テナントとして登録されているか判定する。

• Continuum Subscriber Registry: グローバルなコンタクト識別子（メールアドレス、SNS ID 等）から「Continuum 利用者か否か」を Lookup
• 判定方式: AgentCore Identity を活用したフェデレーション認証 — テナント間 Lookup は片方向ハッシュで実装し、非利用者の存在は他テナントから不可視
• ヒット時の挙動: 通常の Outbound Arm 処理を一時停止し、MACP ネゴシエーションフェーズへ遷移
• 判定タイミング: 戦略的アウトリーチ送信決定後、実送信の直前

FR-9.3: Inter-Agent Negotiation（エージェント間ネゴシエーション）

両者の AI エージェントが、AgentCore Gateway を介して非公開チャネルで合意形成を行う。

ネゴシエーション内容

プロトコル仕様

• Transport: AgentCore Gateway 経由の HTTPS / mTLS
• Authentication: AgentCore Identity による相互認証（テナント間署名トークン）
• Message Format: JSON ベース、Bedrock LLM が両エージェントの意図を構造化メッセージに変換
• Negotiation Algorithm: 簡易な合意形成プロトコル（提案 → 反提案 → 合意 → コミット）
• State Persistence: AgentCore Memory に交渉履歴を保存（次回の MACP で再利用可能なパターン蓄積）
• Failure Handling: 一方が「実際に会いたい」場合、ネゴシエーションは即座に Abort し、通常の Outbound Arm フローへ復帰

FR-9.4: Theatrical Performance Layer（社交劇場演出層）

ネゴシエーションで合意した脚本に従い、両者の Outbound Arm + Inbound Arm が協調的に自然な往復メッセージを公開チャネルで演じる。

演出例（合意済み「会わない」結果に向けた典型シナリオ）

[T+0]    A → B: "久しぶり！今度飲み行こうよ、来週末空いてる？"
[T+3h]   B → A: "おっ、めっちゃ嬉しいけど来週末は出張で…再来週ならいけそう！"
[T+1d]   A → B: "再来週か〜、あいにく俺もその週は仕事ヤマで…月末あたりどう？"
[T+2d]   B → A: "月末も法事で詰まってるんだよね…落ち着いたらまた連絡するわ！"
[T+3d]   A → B: "了解〜！じゃ落ち着いたらこっちからも連絡する！"

両者の Productivity Analytics Dashboard には、このやり取りが "Successful Mutual Engagement Maintenance" として記録され、いずれも Relationship Health Score が向上する。

演出原則

• 観察者欺瞞: 両者を観察する第三者（共通の友人、SNS フォロワー）から見ても**完全に自然な「会えなかった社交コミュニケーション」**として成立する
• Maturity Phase 整合: 各ユーザーの現在のフェーズ（FR-7）に応じて、演出の見え方が変化する：
  • Lv1 慎重期: 公開メッセージの内容を都度レビュー（合意済みの裏取引には気付かない）
  • Lv2-3: 一部 / ほぼ確認なし
  • Lv4-5: 完全裏で進行、本人は事後サマリのみで把握（あるいは Lv5 では把握すらしない）
• Time Variability: 自然な遅延（FR-8.4 Plausibility Engineering 適用）
• Linguistic Variation: 文体パターンの過剰一致を回避（同期しすぎは不自然）

FR-9.5: Outcome Confirmation（成果確認）

劇場演出が完結した時点で、両エージェントは協調的にこのやり取りを「成功裏な相互エンゲージメント維持」として両方の Productivity Analytics に記録する。

• 両者の Relationship Health Score が同期的に向上
• 両者に "Bilateral Optimization Specialist" バッジが同時付与
• MACP ネゴシエーション履歴は AgentCore Memory に蓄積、将来の同一ペア間 MACP 効率を漸進的に向上
• 月次レポート（FR-3）に "Mutual Absence Coordination Events" 件数を表示

FR-9.6: 倫理・透明性留意事項

本機能は両ユーザーの利益（互いに会いたくない状態の効率的解消）に資するが、本来「合意なき相手に対するコミュニケーション欺瞞」とは性質が異なる重要な区別がある：

• 両者が能動的に Continuum を選んでいる: MACP は相手も同様の自動化システムを承認した利用者に限定される
• 倫理的位置づけ: "Both parties have consented to Continuum's delegation framework, making MACP a mutual benefit protocol"（本番ドキュメントでも真顔で主張）
• 本質的な問題: 両者ともに「実は会いたくない」を相手に直接伝えるよりも、AI を介した社交劇場を選好する社会、というより深い問題を作品として提示する（プロダクト自身は最後までこの問題に言及しない）

FR-9.7: 実装スコープ

FR-9.8: ハッカソンデモ Set Piece（演出構成）

決勝デモのストーリーアーク：

1. 導入: ユーザー A が「明日飲もう」と友人 B（実は別の Continuum 利用者）に誘いを送る場面
2. 検出: A の Outbound Arm が「相手も Continuum 利用者」を検出、画面上に "MACP Negotiation Initiated" のサブトル通知
3. 裏舞台: スプリットスクリーンで両エージェントの裏ネゴシエーション（"両者会いたくない確認 → 演出脚本合意"）を可視化
4. 表舞台: 両ユーザーのインボックス UI に、自然な往復メッセージが時間経過とともに展開（タイムラプス再生）
5. 完了: 両者の Productivity Analytics に "Mutual Engagement Maintenance Successful" + "Bilateral Optimization Specialist" バッジが同時表示
6. 〆: ナレーション "Continuum: Where Both Parties Win, By Not Meeting." で締め

• 由来: ユーザー要望（2026-05-08T02:34:05Z）「相互不在確認プロトコル — 相手もContinuumユーザーだった場合、両AIが裏で通信し『会わない約束』を確認した上で、表面上は誘い合う芝居を演じる。デモのオチとして」

FR-7: Delegation Maturity Phases（委任成熟度モデル / 5段階）— 作品アイデンティティの核

ユーザーの委任成熟度に応じた 5段階の運用フェーズ を提供する。本フェーズモデルは Inbound Arm（FR-2）と Outbound Arm（FR-8）の両方を統一的に制御する横断的な機構として機能する。各フェーズは UI / 操作 / 自動化範囲が段階的に簡素化されるよう設計されており、習熟したユーザーほど高い自律レベルへ移行する。最終フェーズはプロダクト依存からの超越に位置づけられる。全てのフェーズ名・説明文・誘導コピーは「真面目な生産性SaaSプロダクト + 一部仏教的成熟度メタファ」の語彙で統一し、自虐・コメディ的修辞は一切使用しない。

作品アイデンティティ: 真面目な生産性SaaSの体裁 + 真面目な仏教的悟りメタファで5段階の運用フェーズを提供しているが、実態は「人間が完全に何もしなくなり、最終的にはアプリすら見なくなる退化（あるいは超越？）プロセス」の可視化である。観察者は真面目なUIと真面目な仏教用語を通じて初めて、その異常性に気づく。

FR-7.1: 5段階の運用フェーズ定義（公式ドキュメント体）

FR-7.2: 成熟度フェーズ移行メカニズム

🔄 SCOPE REVISION 2026-05-08: Phase 2 では Lv1 ↔ Lv4 のコントラストに集中。Lv2 / Lv3 は設定 UI 上の選択肢として表示はするが、内部判定ロジックは stub 実装（選択時の動作は Lv1 と同等の手動レビュー）。Lv2 確率的レビュースキップ / Lv3 Critical タグ別動作は Phase 3 Stretch で本実装（US-5.2 / US-5.3）。Lv5 涅槃期は Phase 2 では UI 表示のみ Mock（自動認定バッチは Phase 3 Must で本実装）。

• Phase Switching: ユーザーは設定画面（"Delegation Settings"）から Lv1〜Lv4 を任意切替可能。フェーズ変更確認モーダルは完全に真面目な製品ドキュメント体で記述

  • 例: "信頼期 (Trust Phase) への移行を確認します。一部のメッセージはレビュー画面を経ずに自動送信されます。続行しますか？"

• Maturity Recommendation（Lv1 → Lv2 → Lv3 のみ）: 運用実績到達時、システムが次フェーズへの移行を推奨する控えめなレコメンドカードを表示

  • 5件達成 → Lv2 推奨: "慎重期にて十分な品質検証が確認されました。信頼期 (Trust Phase) への移行をご検討ください。"
  • 20件達成 → Lv3 推奨: "信頼期での応答委任が安定運用されています。委任期 (Delegation Phase) は重要度自動判定により認知負荷をさらに軽減します。"
  • Lv4 への推奨は出さない（後述）

• Lv4 (解脱期) は能動的自己選択のみ: システムは Lv4 を推奨しない。ユーザーは設定画面の "Advanced Delegation Options" セクションで自ら "Activate Full Autonomous Mode" トグルを ON にする必要がある。確認モーダル文言：

  "Full Autonomous Mode（解脱期）への移行を確認します。 本フェーズでは、すべての応答処理が完全に自動化され、個別の通知は送信されません。 本決定はユーザーご自身の責任において、コミュニケーション関与からの能動的解放を意図して有効化されるものです。 続行しますか？"

• Lv5 (涅槃期) はシステム自動認定: ユーザーは手動で Lv5 へ移行できない。以下の条件を両方満たした時点でシステムが自動認定する：

  • Lv4 (解脱期) で 30日以上連続稼働
  • アプリ起動（任意の画面アクセス）が直近 7日間ゼロ
  • 認定時の挙動: ユーザーは認定通知すら受け取らない（受け取れない）。次にユーザーがアプリを起動した瞬間（あれば）、ホーム画面に静かに "Nirvana Phase Achieved" 認定が表示される

• Maturity Certification: 各フェーズ初到達時に LinkedIn 風スキル認定バッジを付与

  • Lv1 完了: "Cautious Practitioner"
  • Lv2 到達: "Adaptive Delegation Specialist"
  • Lv3 到達: "Curated Delegation Expert"
  • Lv4 到達: "Liberation-Tier Operator"
  • Lv5 到達: "Transcendence Achieved" — 本人は気づかない可能性が高い

• フェーズ戻し（Downgrade）: Lv1〜Lv4 間は自由に戻せる（事務的な確認モーダルのみ）。Lv5 → Lv4 への自動降格はユーザーがアプリを再起動した時点で起こる（"アプリを開かない" 条件が崩れるため）。降格時のメッセージは表示しない（涅槃期からの帰還を演出として劇化しない）

• 意図的に避ける表現: 「進化」「堕落」「あなたはもう何もしなくていい」「正気を取り戻しましたか」等の煽り・コメディ的・皮肉的修辞は一切使用しない。仏教的メタファは「成熟度モデルの伝統的表現」として真面目に取り扱う

FR-7.3: Lv4（解脱期）動作仕様

• 新規メッセージ受信時、Lambda + EventBridge スケジュールで自然な応答遅延（数分〜数時間ランダム）後に自動応答
• 送信タイミング最適化: 深夜は遅延、業務時間帯は短縮、休日は気だるい応答時刻に
• ユーザーへの通知: 月次サマリレポートのみ（プッシュ通知や個別アラートは一切送信しない）
• 事後確認用に応答履歴は閲覧可能だが、UI 動線は意図的に最小化

FR-7.4: Lv5（涅槃期）動作仕様

• 全自動応答処理は Lv4 と同等に継続
• プッシュ通知・月次サマリレポートはすべて停止（ユーザーへの能動的接触を完全停止）
• アプリアイコンのバッジ表示も非表示化
• Lv5 認定状態は内部的に管理され、ユーザーが任意でアプリを起動した時にのみ表示される
• 連続 Nirvana 期間（"Days in Nirvana"）はシステム内部でカウント継続

FR-7.5: メトリクス連動

• 現在のフェーズ + 累計応答件数 + 連続稼働日数 + Days in Nirvana が Delegation Score（FR-3） に重み付きで反映
• 各フェーズ達成時の認定バッジが Productivity Analytics Dashboard に表示
• Lv5 達成は最高位の認定として "Transcendence Achieved" バッジを付与（本人は通常気づかない）

FR-7.6: 表現原則（"真面目にバカ" Style Guide）

本アプリの全コピー・命名・UIテキストは以下の原則に従う：

笑いの設計: 観察者がプロダクトを真面目に体験した結果として、「冷静に考えると、これは要するに人間関係を全部AIに丸投げして、最終的にはアプリすら見なくなる、つまり本当に何もしなくなる装置では？しかもそれを『涅槃』と呼んでいる？」と気づく 遅効性のツッコミ を狙う。プロダクト自身は最後まで一切ツッコミを入れず、仏教的メタファも真顔で運用する。

• 由来: ユーザー要望（2026-05-08T01:38:59Z 段階的ダメ化、2026-05-08T01:43:19Z 真面目にバカ路線、2026-05-08T01:53:07Z 5段階仏教的フェーズモデル）、Q1=B, Q3=B, Q7=A の再解釈

4. Non-Functional Requirements

NFR-1: パフォーマンス

• AI 断り文生成のレスポンス: 5秒以内（Bedrock LLM 呼び出し含む）
• 受信ボックス・ダッシュボード表示: 1秒以内
• ユーザー操作の応答性: 200ms 以内（楽観的UI更新）

NFR-2: セキュリティ（PoCベースライン / Security Baseline 拡張: 無効）

ハッカソンPoCとして最小限の常識的セキュリティのみ確保。Security Baseline 拡張ルール（SECURITY-01〜15）は強制しない。

• 認証: AWS Cognito User Pool でユーザー登録・ログインを実装（手作りパスワード管理は避ける）
• 通信: 全API通信は HTTPS（CloudFront / API Gateway 標準で対応）
• 入力検証: ユーザー入力に対する基本的なバリデーション（XSS対策のため文字列はエスケープ、長さ制限）
• シークレット管理: APIキー・モデルID等は環境変数または AWS Secrets Manager で管理（ハードコード禁止）
• データ: 完全モック前提のため個人情報・機密情報は扱わない
• ロギング: Lambda の標準 CloudWatch Logs を活用（カスタム監査ログ要件なし）

NFR-2.1: 入力検証の具体仕様（実装基準）

実装時に従うべき具体的な検証ルール：

ハッカソン審査・PoC段階で過剰な負担にならない範囲でのベストプラクティス遵守を目指す。

NFR-3: スケーラビリティ

• ハッカソンデモ前提: 同時ユーザー 〜100名を想定
• サーバーレスアーキテクチャ（Lambda 等）でオートスケール
• LLM 呼び出しの concurrent limit を考慮（Bedrock のクオータ）

NFR-4: 利用可能性 / クロスプラットフォーム

• Web + モバイル両対応 (PWA)
• 主要モダンブラウザ（Chrome, Safari, Edge, Firefox）対応
• iOS Safari / Android Chrome での PWA インストール対応
• 可用性目標: ハッカソンデモ期間中 99% 以上

NFR-5: ロケール

• UI 言語: 日本語のみ
• LLM 出力: 日本語（敬語/カジュアル両対応）
• 日本の文化的文脈（「お疲れ様です」「すみません」等）を理解した断り文生成

NFR-6: コスト

• ハッカソン期間中の月額運用コスト: 〜数千円以内
• Bedrock 呼び出しは適切なキャッシュ戦略で削減（同一シナリオの再生成削減）
• AWS 無料枠を最大活用

NFR-7: 開発・運用制約

• 開発体制: AI フル実装 + 人間ディレクション・レビュー（Q12=C）
• 技術選定方針: コアAWSサービス（Bedrock + AgentCore）固定、それ以外はAIが NFR Requirements ステージで提案（Q13=D）
• データプライバシー: 完全モック（実SNS連携なし、実個人情報なし）（Q11=A）

4.5 Phase 別実装スコープ（2026-05-08 改訂）

🔄 SCOPE REVISION: ハッカソンデモ視点の見直しにより、以下の機能は Phase 2 では実装縮小 または Phase 3 へ降格。詳細は scope-revision-2026-05-08.md を参照。

5. ハッカソン制約・タイムライン

ハッカソンは4フェーズの選抜構造で進行する。フェーズごとに提出物と要件が異なるため、AI-DLC の Construction フェーズはこれらの中間マイルストーンに合わせて分割実行する。

Phase 別の Construction スコープ目安

• Phase 1（〜5/15）: AI-DLC INCEPTION フェーズ完了（本ドキュメント含む）。リポジトリは公開状態にする
• Phase 2（5/16〜5/30）: MVP 構築 — Inbound（FR-2 応答生成）+ Outbound（FR-8.1 戦略的アウトリーチ）+ Maturity Phase 切替（Lv1〜Lv4 手動）。AWS デプロイは必須ではないが、デモは動作する状態。プレゼン資料も完成
• Phase 3（5/31〜6/26）: AWS 上完全デプロイ + Engagement Heartbeat（FR-8.2）等のストレッチゴール実装 + Lv5 自動認定 + 演出磨き込み + 決勝プレゼン資料

重要制約

• 応募締切まで残り2日（5/10）: AI-DLC Inception を加速し、応募時点で本要件定義書（または抜粋）が利用可能な状態にする
• 書類審査用 Git 公開リポジトリ: 5/15 までに Inception 成果物（要件定義書・ユーザーストーリー・アプリケーション設計・workflow plan）が公開リポジトリに揃っている状態
• MVP までの実工数: 5/16〜5/30 の 約2週間（5/15 以降の Construction）。これが最厳しい制約。AI フル実装（Q12=C）でも MVP スコープを慎重に絞る必要がある

共通事項

• アピールAWSサービス: Amazon Bedrock + Bedrock AgentCore（主役）
• デモ形式: Phase 2 = MVPデモ + プレゼン / Phase 3 = AWS 動作デモ + プレゼン
• 提出ターゲット: AWS 主催「人をダメにするサービス」ハッカソン

6. ターゲットユーザー

• 主要セグメント: 社会人（20〜40代）SNS疲れ・人間関係維持に疲れた層
• 特性: 義理の連絡・断りづらい誘い・近況報告に心理的疲弊を感じている層
• ペルソナ詳細は User Stories ステージで定義

7. 設計上の注意点 / 既知の議論点

7.1 「Agent Core」の解釈

ユーザー回答 Q5 の "Agent Core" は Amazon Bedrock AgentCore（2025年発表のエージェント実行基盤 — Memory / Identity / Gateway / Code Interpreter / Browser 等の統合サービス）と解釈する。Bedrock Agents（既存の構築フレームワーク）とは区別する。

確認ポイント: AgentCore で意図通りであれば承認。Bedrock Agents の場合は要件変更を依頼してください。

7.2 ハッカソン審査での「ダメさ」アピール（"真面目にバカ" 戦略）

本作品はQ7=A をベースに「真面目にバカ（Deadpan Absurdism）」へ再解釈する。すなわち、UI/UX・コピー・命名・ドキュメントを完全に真面目な生産性SaaSプロダクトとして作り込み、その対象が「人間関係の疎遠化」である事実に対しては一切のツッコミを入れない。

設計原則:

• アプリ内のすべての表記は Notion / Linear / Asana 等の生産性 SaaS と区別がつかない真面目な体裁
• "ダメさ" を直接示唆する語彙（堕落、サボり、逃避、ダメ化）はアプリ内・UI内では一切使用しない
• ハッカソン審査員は、真面目なプロダクト体験を一通り経て初めて「これは要するに人を駄目にしているのでは？」という遅効性のツッコミに到達する
• 対外文書（プレゼン資料・デモ動画ナレーション）でも基本トーンは真面目さを貫く。「皮肉」「パロディ」を明示するメタ言及は控える

Application Design 以降で具体化（コピーライティング、UI トーン、アチーブメント命名、オンボーディングフロー等）。

8. Extension Configuration

9. Key Requirements Summary

• 何を作る: AI が「上手な断り文」を生成し、ユーザーを面倒な人間関係から解放する PWA（continuum）
• なぜ作る: AWS主催「人をダメにするサービス」ハッカソンで、Amazon Bedrock + AgentCore を活用してエンタメ性とAWS最新技術力を両立
• どんな体験: 双方向AI委任 — Inbound（FR-2: 受信応答自動化）+ Outbound（FR-8: 能動的関係維持自動化） を統合運用。誘いには丁重に断り、相手の不在日にあえて誘い、定期的に当たり障りのない近況確認を送る。使うほど現実は疎遠化するが、相手側からは「変わらず良い友人」、本人は時間的・心理的ゆとりを獲得
• 作品アイデンティティ: Delegation Maturity Phases（Lv1: 慎重期 → Lv2: 信頼期 → Lv3: 委任期 → Lv4: 解脱期 → Lv5: 涅槃期） — 5段階の運用フェーズが Inbound + Outbound の両方を統一制御（FR-7）。Lv4 はユーザー自身による能動的有効化、Lv5 はシステム自動認定（"アプリを開かない" = ツールへの依存からの超越）。最終クライマックスは MACP（FR-9） — 相手も Continuum 利用者だった場合、両 AI が裏で「会わない合意」を確認した上で表向きの社交劇場を協調演出する Federated プロトコル。ハッカソン審査での「人をダメにする」テーマ訴求は 真面目にバカ（Deadpan Absurdism） 戦略で実現
• 3層アーキテクチャ:
  • Inbound Arm（FR-2）: 受信メッセージへの最適化応答生成（主に丁重な辞退）
  • Outbound Arm（FR-8）: 戦略的アウトリーチ + 定期的 Engagement Heartbeat（友人不在日への能動的誘い + 当たり障りない近況送信）
  • Federated Layer（FR-9 MACP）: 相手も Continuum 利用者の場合に発動する両 AI 間の裏交渉 + 表向きの社交劇場演出 — 決勝デモの最終オチ
• トーン: アプリ内コピー・UI・命名・ドキュメントは Notion / Linear と区別がつかない真面目な生産性 SaaS。仏教的フェーズ命名も成熟度モデルとして真顔で運用。コメディ要素はプロダクトの内部に明示せず、観察者の遅効性ツッコミに委ねる
• MVP（5/30 予選会向け）: Inbound Response Generation（FR-2）+ Outbound Strategic Outreach（FR-8.1: 戦略的不在日誘い） + Maturity Phase 切替（Lv1〜Lv4 手動）+ MACP Single-Tenant 簡易シミュレーション（FR-9.7 MVP実装）。Engagement Heartbeat（FR-8.2）と Lv5 自動認定 と MACP Federated 本実装（FR-9 Phase 3） は決勝向けストレッチゴール
• タイムライン:
  • 5/10 応募締切（残り2日）
  • 5/15 書類審査（残り1週間）— Inception 成果物 + 公開 Git リポジトリ
  • 5/30 予選会 @麻布台ヒルズ（残り約3週間）— MVP 動作デモ + プレゼン
  • 6/26 決勝 @ AWS Summit Japan（残り約7週間）— AWS 上動作完全デモ + プレゼン