Hilt化、ネットワーキング層の構築が完了しました。
今日は、これまでの基盤の上に、アプリを本格的なWebサービスへと進化させるための入口、**「ユーザー認証機能」**を設計します。

この記事では、実装に着手する前の「設計フェーズ」として、要件定義と基本設計を固めていきます。Qiitaの記事にすることも意識し、思考のプロセスを交えながら、分かりやすくまとめました。

これまでのアプリは、誰でも使える代わりに、データはスマホの中だけにある「スタンドアロン型」でした。

しかし、将来的に**「どの端末からでも同じデータを使える」クラウド同期機能**を実現するためには、まず「このメモは、誰のメモなのか？」を識別する仕組みが不可欠です。

そのための第一歩が、ユーザー認証機能の実装です。

ユーザーストーリー:

機能一覧:

機能ID	機能名	機能概要
FE-011	新規登録機能	ユーザーがメールアドレスとパスワードを入力し、新しいアカウントを作成できる。
FE-012	ログイン機能	登録済みのアカウント情報でログインできる。
FE-013	ログイン状態の永続化	ログインに成功したら、そのユーザー情報を端末内に記憶する。アプリを再起動しても、ログイン状態が維持される。
FE-014	画面分岐機能	アプリ起動時にログイン状態を判定し、未ログインならログイン画面へ、ログイン済みならメモ一覧画面へ、ユーザーを振り分ける。

既存のMVVMアーキテクチャ、Hilt、Navigation Composeを基盤として実装します。
ログイン状態（ユーザーIDなど）の端末内への保存には、SharedPreferencesの現代的な後継であるJetpack DataStoreを利用します。DataStoreは、非同期で安全にデータの読み書きができるため、今回の目的に最適です。

今回の機能実装のために、以下の新しい専門家たち（コンポーネント）をチームに迎えます。

UI層:
- LoginScreen.kt: ログインフォームを表示する**「受付画面」**。
- RegisterScreen.kt: 新規登録フォームを表示する**「会員登録画面」**。
- SplashScreen.kt: アプリ起動時に一瞬だけ表示され、行き先を振り分ける**「案内人」**。
ViewModel層:
- AuthViewModel.kt: ログインと新規登録のロジックを担当する**「認証の専門家」**。
データ層:
- UserRepository.kt: ユーザー情報のAPI通信と、ログイン状態の保存・読み出し（DataStore）を担当する**「顧客情報管理者」**。
- DataStore: ログインしたユーザーのIDなどを保存しておくための**「小さな金庫」**。

この機能追加により、アプリ起動からの画面遷移の流れが以下のように変わります。

思考のポイント:

アプリ起動時にいきなりログイン画面や一覧画面を見せるのではなく、SplashScreenという「案内人」をワンクッション挟みます。

この案内人が、裏側で「お客様はログイン済みですか？」とUserRepositoryに静かに確認し、確認が取れてから適切な画面へスムーズにご案内します。これにより、ユーザーは画面のチラつきなどを感じることなく、快適な体験を得られます。

以上が、Day 3で実装する認証機能の要件定義と基本設計です。

この設計に致命的な漏れはなく、この後の詳細設計に進むための完璧な土台となります。準備ができたら、次のステップである詳細設計に進みましょう！