推しアイデア
目標時間と自分の疲労ゲージを掛け合わせ、個人のキャパに合わせて予定の無理度をAIが客観評価する点です。さらに無理な計画倒れを防ぐだけでなく、頑張りに応じてAIがユニークな称号を付与。自分の限界に寄り添いながら楽しくモチベーションを維持できる新しいスケジュール体験を提供します。
きせき手帖
頑張りを称号に変え、見返したくなる手帖『きせき手帖』
作った背景
理想の目標を詰め込んでも体力が追いつかず、計画倒れになる悩みが開発の原点です。従来のツールは時間枠でしか管理できず自分の疲労やキャパを無視しがちでした。そこで自分の体力状態を可視化でき、無理のない計画を立てられる仕組みが必要だと考えました。
推し技術
Python/FastAPIを用いた独自負荷計算アルゴリズムとGemini APIによる動的称号生成の連携技術です。ユーザー個別のキャパに対する予定の負荷率をリアルタイム算出。その日の達成状況に応じて、AIが最適な称号と理由を動的生成するロジックが核です。
プロジェクト詳細
1日の限界時間から「自分の歩み」を視覚化するタスク手帖
✨ きせき手帖
日々のタスクや予定に追われる学生生活。ToDoリストに無数のタスクを詰め込んでも、ただこなす作業に忙殺され、自分の成長や達成感を実感しにくい問題がありました。
そこで開発したのが、客観的な負荷指標とモチベーションを提供するタスク手帖**「きせき手帖」**です。
きせき手帖は、単にタスクの消化時間を集計するアプリではありません。ユーザー個人の**「1日の限界時間」に対する負荷率を正確に算出**。さらにGemini APIを活用し、負荷や達成度に応じたユニークな「称号」やメッセージをフィードバックします。
💡 1. 開発背景とコア機能の導入根拠
📊 【限界時間に対する負荷率の算出】
🎯 対象：「予定を消化できず、自分のサボりや精神的な甘さのせいだと責めてしまう学生」
🔍 背景と効果：
計画倒れになってしまう本当の原因は、自分の精神論ではなく「体力や能力の限界を超えたスケジュールを組んでしまっていること」にあります。
自分の『1日の限界時間』に対する負荷率（%）を数値で客観視できるようにすることで、「サボったのではなく、そもそもキャパシティを超えていたんだ」と正しく納得でき、無駄な自己嫌悪を防ぐメンタルケア効果をもたらします。
🏆 【AIによる称号とメッセージの即時フィードバック】
🎯 対象：「日々の課題やアルバイトをこなしても、成果が見えにくく達成感を得られない学生」
🔍 背景と効果：
人間は努力のプロセスに対してリアルタイムでフィードバックを受けると、モチベーションやパフォーマンスが維持されやすいという特性を持っています。
1日の終わりにGemini APIがその日の頑張りに応じたユニークな「称号」やメッセージを即座に返すことで、日々の達成感を積み重ね、自分に対する自信や自己肯定感の向上へと繋げます。
「予定を消化する」だけのスケジュール帳から、自分の歩みを誇れる手帖へ。
🛠️ 仕様・使用技術
Frontend (React)
Vercel
Bearer token
→
Backend (FastAPI)
Render
token転送
→
Supabase
RLS付きDB
本人のデータのみ返す（RLSで構造的にブロック）
📱 対応端末
PC / スマートフォン（レスポンシブ対応）
💻 技術スタック
| フロントエンド | React, TypeScript |
| バックエンド | Python (FastAPI) |
| データベース / 認証 | Supabase |
| AIエンジン | Gemini API (gemini-2.5-flash) |
⚙️ 2. 開発のこだわりと技術的挑戦
- フロントとバックエンドの緻密な連携設計 React、FastAPI、Supabaseの役割を明確に分離し、開発初期からAPIのデータ規格（JSON構造）を揃えて進めました。計算ロジックをバックエンド側に集約させることで、フロントエンドの軽量化と高い保守性を両立させています。
- 限界時間を算出する独自ロジックとAIフィードバック ユーザー個人の「1日の限界時間」に対する正確な負荷率を算出する計算ロジックを構築しました。また、Gemini APIを用いて学生の心に響く最適な称号やメッセージを生成。APIエラー時にも表示が崩れないフォールバック処理まで徹底して実装しました。
💥 3. 苦労した点とバグとの戦い（結合フェーズ）
最も難航したのは、フロントエンドとバックエンドの結合段階でした。
⚠️ 発生した問題：
フロント（React）とバックエンド（FastAPI）を接続した際、データ型やレスポンス構造のわずかな食い違いにより、負荷率の計算結果が正しく画面に反映されない、あるいはAPIレスポンスの遅延によりUIの描画が不安定になる現象が発生しました。
フロント（React）とバックエンド（FastAPI）を接続した際、データ型やレスポンス構造のわずかな食い違いにより、負荷率の計算結果が正しく画面に反映されない、あるいはAPIレスポンスの遅延によりUIの描画が不安定になる現象が発生しました。
🛠️ 原因と解決策：
原因は非同期処理の制御不足と、データ通信時の境界値（タスク0件や限界時間超過など）のハンドリング不足でした。チームで以下の改修を行いました。
原因は非同期処理の制御不足と、データ通信時の境界値（タスク0件や限界時間超過など）のハンドリング不足でした。チームで以下の改修を行いました。
- API仕様の再定義とTypeScript型定義の厳密な同期
- FastAPI側での例外処理（フォールバック機能）の強化
- React側でのローディング状態およびエラー境界（Error Boundary）の最適化
これらを完遂することで、どのような通信状態でも安定してデータを表示・処理できる堅牢なシステム構成を完成させました。
🎉 4. 学びと完成
開発を通して、単にコードを書くだけではなく、システム全体を見通したデータ設計と通信ハンドリングの重要性を深く学びました。
画面の見た目だけでなく、裏側の計算ロジックからユーザー体験のデザインまで、チームで細部までこだわり抜いたプロダクトです！
👥 チームメンバーの振り返り・感想
山口 巧之助（DB担当）
私はDB担当として、Supabaseを使った認証とユーザー情報の管理を担当しました。DB設計もSupabaseも初めてでしたが、RLSによる安全なデータ管理を学び、他の担当と連携して開発を進める貴重な経験になりました。
