チーム22 「新規性はありますか？」
現代人（特に大学生）は予定が不適期に詰まりやすく、業務や私的な用事が深夜まで及ぶことも珍しくない。そのため、毎日決まった時間に就寝、起床することは難しい。結果として、寝坊や、寝たはずなのに疲れている、、、という起床時の疲労感などの問題がある。
既存の睡眠支援アプリケーションには、以下の課題がある。
-
固定化されたスケジュールの限界 決まった時間に起床を促すだけのシステムでは、日々の変動が激しい現実のスケジュールに適応しきれず、継続的な利用が困難になるケースが多い。
-
「寝溜め」の限界と生活リズムの崩壊 睡眠時間が不足する日が生じた際、そのしわ寄せを前後の日程でいかに補填するかの視点が欠如している。休日の過度な「寝溜め」による調整には生理的な限界があり、かえって生活リズムを大きく乱す要因となる。
-
時間確保だけでは解決しない「環境」の問題 睡眠は時間の確保だけでなく、質の向上が不可欠である。周囲の光や騒音、就寝前の過度のスマートフォン操作といった不適切な就寝環境は、スムーズな入眠を妨げ、疲労回復効果を著しく低下させる。
提案・解決策 (Solution) 本アプリケーションは、多忙な現代人に「最適な睡眠」を提供することを目的とした、実践的な睡眠支援ツールである。ユーザーのスケジュールと物理的な生活環境の双方からアプローチし、以下の4つのコア機能によって睡眠の最適化を図る。
-
睡眠プラン：1週間を見据えたトータル睡眠コントロール 機能概要: Googleカレンダーと同期し、ユーザーの予定（移動時間や予定の重要度を含む）をAIが自動取得して睡眠計画を生成する。
- システムの強み: 1日単位ではなく「1週間程度」を単位として俯瞰的にプランニングを行う。睡眠が削られる日があっても、寝溜めの限界を考慮しつつ前後の日程で最適にカバーし、生活リズムの崩壊を防ぐ、現実的かつ最も効果的な睡眠プランを提案する。
-
睡眠モニター：スムーズな入眠のための環境最適化 機能概要: デバイスのセンサーを用いて周囲の「光」と「音」を常時モニタリング・視覚化し、同時に就寝前の過度なスマートフォン操作を検知して警告を発する。
- システムの強み: 睡眠を妨げる物理的要因をシステム側で検知・排除を促すことで、スムーズに入眠できる最適な環境づくりを強力にサポートする。
-
モーニングアラーム：朝の目覚めを最高にする確実な起床 機能概要: 予定の開始時刻と準備に必要な時間から逆算し、適切な起床時間に行動を開始できるよう支援する。
- システムの強み: 予定の切迫状況（重要度）に応じてアラームの強度を2段階で動的に変更する。さらに、起床直後に写真撮影を要求する「モーニングミッション」を搭載し、アラーム停止後の二度寝を物理的に防止して確実な覚醒を実現する。
-
睡眠ログ：主観的な「睡眠体験」の記録と学習 機能概要: 起床直後に「目覚めの体調や気分」を入力させ、主観的な睡眠の質を記録する。
- システムの強み: 単なる睡眠時間のトラッキングにとどまらず、ユーザーの「体感」をデータ化する。取得したログデータはAIによる次回の睡眠計画生成にフィードバックされ、継続的な利用により個人の体質や生活リズムに適応したパーソナライズが可能となる。
寝るプラ は、AI 駆動の総合睡眠支援 Android アプリケーションです。
- 睡眠環境モニタリング: スマートフォンのセンサーで寝室の照度・騒音レベル、寝る直前のスマホの利用をリアルタイム計測し、睡眠に適した環境かどうかをスコアリング
- AI 睡眠プラン生成: ユーザーのスケジュールや睡眠履歴に基づき、LLM が最適な週間睡眠プランを自動生成
- 睡眠ログ・分析: 日々の睡眠スコアや気分を記録し、週間トレンドをグラフで可視化
- ミッション付きアラーム: 段階的アラーム（やさしい → 厳しい）と、カメラを使ったターゲット撮影チャレンジによる確実な起床サポート
- 睡眠スケジュール管理: 起床時間・睡眠時間の設定と、それに基づいたアドバイスの提供
 |
 |
 |
|
 |
 |
 |
|
 |
 |
 |
|
 |
 |
 |
|
 |
- 睡眠モニタ > 睡眠環境 > 照度・音圧が規定値を超えると赤色に変わります！
 |
- アプリを起動し、アカウントを作成・ログイン
- 設定画面で起床時間・希望睡眠時間を設定
- ホーム画面で今日の睡眠プランを確認
- 就寝前に睡眠モニターを起動し、寝室環境をチェック
- アラームが設定された時間に段階的に鳴動し、必要に応じてミッションをクリアして起床
- 起床後に気分を記録し、睡眠ログで自分の睡眠傾向を振り返り
- スマートフォンの内蔵センサー（照度・マイク）を活用することで、専用デバイスなしに自動的に睡眠環境を計測できるようにした点
- カレンダーを利用し、LLM による個人最適化された睡眠プラン生成で、画一的なアドバイスではなくユーザーに寄り添った提案を実現
- 翌日の早朝に予定があれば、早く寝るように促す
- 夜遅くに予定があれば、自動的に就寝時間を遅く
- カメラを使ったミッション型アラームにより、ゲーミフィケーション要素で楽しく確実に起床できる仕組み
- 就寝前の利用を考慮し、目に優しい落ち着いた配色とシンプルな UI を採用
- 睡眠フェーズ（準備 → 入眠前 → 睡眠中）に応じた画面遷移で、直感的な操作体験を実現
- 睡眠スコアやトレンドをグラフで可視化し、改善の実感を得やすいデザイン
- バックグラウンドでのセンサー計測に対応し、モニタリングを継続
- 睡眠プランのキャッシュ機構を実装し、LLM API への不要なリクエストを削減
- Onion Architecture（バックエンド）と FSD Lite（フロントエンド）による保守性の高いコード設計
| カテゴリ | 技術 | バージョン |
|---|---|---|
| フレームワーク | React Native (Expo) | SDK 54 |
| 言語 | TypeScript | strict mode |
| ルーティング | Expo Router | v6 (file-based) |
| 状態管理 | Zustand | v5 |
| パッケージマネージャ | pnpm | 9.x |
| 認証 | Supabase Auth | - |
| センサー | expo-sensors, expo-camera, expo-av | - |
| 通知 | expo-notifications | - |
| バックグラウンド処理 | react-native-background-actions | - |
| カテゴリ | 技術 | バージョン |
|---|---|---|
| フレームワーク | FastAPI | v0.109+ |
| 言語 | Python | 3.11+ |
| ORM | SQLAlchemy 2 (async) | v2.0+ |
| データベース | PostgreSQL | asyncpg |
| マイグレーション | Alembic | v1.13+ |
| パッケージマネージャ | uv | - |
| LLM 連携 | OpenRouter API (httpx) | - |
| 認証 | Supabase JWT + PyJWT | - |
| カテゴリ | 技術 |
|---|---|
| コンテナ | Docker / Docker Compose |
| 認証基盤 | Supabase (Cloud) |
| タスク自動化 | Taskfile (go-task) |
| コード品質 | ESLint, Prettier, Ruff, MyPy |
| 型チェック | TypeScript (tsc), MyPy |
本プロジェクトでは、AI 駆動開発のメリットを最大化しつつ、将来的な拡張性（AWS ECS 等へのデプロイ）を見据え、堅牢で開発体験（DX）の高いアーキテクチャを設計・構築しました。
AI 駆動で開発を進めるにあたり、LLM が事前学習で深く理解している標準的なデザインパターン「オニオンアーキテクチャ」を採用しました。これにより、AI によるコード生成の品質が安定するだけでなく、コードの関心事が明確に分離され、修正・テストのしやすい保守性の高いバックエンドを実現しています。
graph TB
subgraph 外層
API[API 層 - FastAPI エンドポイント]
Infrastructure[インフラ層 - DB/外部API]
end
subgraph 中層
UseCases[ユースケース層 - ビジネスロジック]
end
subgraph 内層
Domain[ドメイン層 - エンティティ・値オブジェクト]
end
API --> UseCases
UseCases --> Domain
UseCases --> Infrastructure
Infrastructure --> Domain
高価で時間のかかる LLM API への不要なリクエストを抑えるため、「カレンダーの予定」「睡眠ログ」「設定情報」「当日の日付」などの入力パラメータ群から一意のシグネチャ（ハッシュ）を生成しています。このハッシュを用いて過去の計算結果を DB 内で検索・判定することで、同一条件であればキャッシュを即座に返却し、UX の劇的な向上（高速なレスポンス）と API コストの最小化を両立させています。
sequenceDiagram
participant Client as クライアント
participant API as FastAPI
participant Service as 睡眠プランサービス
participant Hash as ハッシュ生成
participant DB as PostgreSQL
Client->>API: 睡眠プラン取得リクエスト
API->>Service: 生成処理の依頼
Service->>Service: 入力パラメータ収集
Note over Service: カレンダー予定・睡眠ログ<br/>設定情報・当日日付
Service->>Hash: パラメータ群を渡す
Hash->>Hash: SHA256等でハッシュ化
Hash-->>Service: シグネチャ（ハッシュ）
Service->>DB: ハッシュでキャッシュ検索
alt キャッシュヒット
DB-->>Service: 過去の計算結果を返却
Service-->>API: キャッシュから即座に返却
API-->>Client: 高速レスポンス（LLM呼び出しなし）
else キャッシュミス
DB-->>Service: 該当なし
Service->>Service: LLM API を呼び出し
Service->>DB: 結果をキャッシュとして保存
Service-->>API: 計算結果を返却
API-->>Client: レスポンス返却
end
ハッカソンにおける初期開発スピードを重視しつつ、将来的には AWS（ECS など）へのデプロイを見据え、ローカルの docker-compose で完全に動作するインフラ環境を構築しました。
graph LR
subgraph ローカル開発
Docker[Docker Compose]
DB[(PostgreSQL)]
API[FastAPI API]
end
subgraph 将来: AWS
ECS[AWS ECS]
RDS[(RDS)]
end
Docker --> DB
Docker --> API
API --> DB
style ローカル開発 fill:#e1f5fe
Firebase などの BaaS への過度なロックインを避け、Supabase は「認証基盤」としてのみ活用しています。Row Level Security (RLS) 単体に依存したデータ管理はセキュリティや柔軟性の面でリスクになり得ると判断し、データの保存や複雑なビジネスロジックはすべて独自のバックエンド（FastAPI + PostgreSQL）を通過させる堅牢な設計としています。
flowchart TB
subgraph クライアント
App[Expo アプリ]
end
subgraph Supabase
Auth[Supabase Auth<br/>認証のみ]
end
subgraph 独自バックエンド
FastAPI[FastAPI]
PostgreSQL[(PostgreSQL)]
end
App -->|ログイン・JWT発行| Auth
App -->|API呼び出し<br/>JWT付き| FastAPI
FastAPI -->|認証検証| Auth
FastAPI -->|データ操作| PostgreSQL
ネイティブアプリ開発において最も煩雑な「スマホ実機やエミュレーターから、ローカル Docker 内の API への IP アドレス解決・ポートフォワーディング」の課題を完全に自動化しました。task dev-up や task dev-up-emulator コマンドを実行するだけで、以下のフローが一括で処理されます。
flowchart TB
Start([task dev-up 実行]) --> A[1. データベースコンテナの起動]
A --> B[2. DB 接続待機]
B --> C[3. Alembic マイグレーション]
C --> D[4. シードデータ投入]
D --> E{実機 or エミュレータ?}
E -->|実機| F[5a. LAN IP で .env.expo.local 生成]
E -->|エミュレータ| G[5b. 10.0.2.2 で .env.expo.local 生成]
F --> H[6. アプリビルド・起動]
G --> H
H --> Done([開発開始])
この仕組みにより、新規参画メンバーでも迷うことなく、一瞬で開発に集中できる極めて高い開発体験を実現しました。
GitHub Actions での CI 実行時間を短縮するため、フロントエンドでは pnpm store のキャッシュを利用し、バックエンドでは astral-sh/setup-uv を用いた pip キャッシュを導入しています。また、Dockerfile でも uv sync --no-install-project を活用し、依存関係のレイヤーキャッシュを最大限に効かせる工夫を施しています。
静的解析やバックエンドのテスト（pytest）に加え、android-emulator-runner を使用して CI 上でネイティブアプリのエミュレーター環境を再現しています。ビルドから起動確認までを自動化することで、「とりあえず Push・PR を送り、バグの確認はほぼ GitHub 上で完結させる」という高速でアジャイルな開発サイクルを実現しています。
flowchart LR
subgraph CI["GitHub Actions CI"]
Lint[Lint / 型チェック]
Backend[Backend pytest]
Cache[cache: pnpm / uv / pip]
Emulator[android-emulator-runner]
Build[Expo Build]
Launch[起動確認]
end
Push[Push / PR] --> Lint
Lint --> Backend
Cache -.->|高速化| Lint
Cache -.->|高速化| Backend
Backend --> Emulator
Emulator --> Build
Build --> Launch
| メンバー | 担当領域 |
|---|---|
| @taitaitai58 | バックエンド・インフラ・アーキテクチャ |
| @yuito393439 | フロントエンド (UI/UXデザイン・画面実装) |
| @Taku-taku-Taku | センサー連携 |
| @You8102 | バックグラウンド処理 |
| @taniharu1214 | アラーム・カレンダー連携 |