入口を /today に寄せたら、「書かなきゃ」が一段薄くなった

日記アプリで一番やりがちなミスは、最初の画面でユーザーに作文を課すことだと思う。だから daily-snap では「今日」を主役にして、迷子にならない導線に寄せた。ルーティングはシンプルに、今日・日付詳細・カレンダー・設定・検索が軸になる。

Next.js の App Router では、ページを増やすほど「状態はどこで持つか」「サーバーとクライアントの境界はどこか」が効いてくる。方針としては、データの正はサーバー（Route Handlers + DB）、UI は必要なところだけクライアント、に寄せた。将来モバイルから同じ API を叩く、という話も purompt.md に書いてある通りで、URL と JSON の形を早めに固定しておくのが目的だった。

初期コミット（例: 13341ca）の時点で、/today や /entries/[date]、カレンダー、設定、AI 系の API が一気に並んでいる。個人開発あるあるで「広く薄く」になりがちだが、逆に言えば 縦割りの依存関係が最初から見えるのは良かった。後から MAS やオフラインを足すときに、「どの画面がどの API に刺さっているか」を説明しやすい。

ルートの地図（2026-05 時点の main を目安）

App Router は web/src/app が起点。画面の本体は (main) ルートグループに寄せていて、マーケ用に (marketing) を分けられる形だ（ログイン周りはグループ外に login / forbidden など）。

| URL のイメージ | 実体（代表ファイル） | | --- | --- | | /today | web/src/app/(main)/today/page.tsx（グリッドは today-main-grid.tsx） | | /entries / /entries/[date] | web/src/app/(main)/entries/... | | /calendar | web/src/app/(main)/calendar/... | | /settings | web/src/app/(main)/settings/... | | /search | web/src/app/(main)/search/... | | /onboarding | web/src/app/(main)/onboarding/... |

API は web/src/app/api 直下にドメインごとのフォルダが並ぶ。ざっくり データの正はここと Prisma 側。

| フォルダ | ざっくり責務 | | --- | --- | | api/entries | 日記エントリの CRUD・追記 | | api/chat-threads / api/chat-messages | 会話スレッドとメッセージ | | api/ai | AI 実行・ストリーミングの入口（実装はサブパスに分割されやすい） | | api/images | 画像アップロードとメタ | | api/calendar | Google カレンダー連携 | | api/auth | 認証まわり（NextAuth / Auth.js 系とセットで読む） |

「画面 → fetch 先 → Route Handler → Prisma」を 1 本だけ通すなら、/today のクライアントから api/entries を叩く線を追うのが最短だった。

/today に寄せる理由は、UX だけじゃない。同期やオフラインキュー（IndexedDB）を考えると、「今日」に操作が集中している方が、競合の説明も実装も楽になる。理想は「追記は基本そこだけ」と割り切ること。もちろん詳細ページからも編集はできるが、心のホームを決めておくのは効く。

この時点では、pgvector も E2EE も「これから」で、PWA も完走していない。それでも骨格は先に置いた。動く範囲を広げるより、迷子にならない地図を先に引く、がこのフェーズの結論だった。

実装メモ（読み手がコードを開くための目印）

コードを追うなら、web/src/app 配下のルートと、web/src/app/api の Route Handlers をセットで見るのが早い。初期コミットはファイル数が多いので、**「画面 → 叩いている fetch → サーバー処理 → Prisma」**の一本道を1本だけ通してから広げると混乱が減る。CHANGELOG には日付ごとのコミットが並んでいるので、「その日何を壊して直したか」の旅行記にもなる。

「広く薄く」を許した代償

初期コミットはファイル数が多く、見た目は重い。でも個人開発では、最初から全部を深く作り込むより、**接続点（API の形・DB の境界・画面の責務）**を先に置いた方が後で楽なことが多い。後から入れた MAS やオフラインは、その接続点に依存する。だから「未完成の宣言」とセットで、地図としての価値はある、というのがこの回のスタンスだ。

小さな結論

「全部きれいに分離できた！」より、「迷ったときに戻れる場所がある」方が続く。/today はそのためのホームだ。画面が増えても、心の地図の中心がブレないようにするのが目的だった。

スクショで残すなら

/today の全体スクショ（モバイル幅とデスクトップ幅）、日付詳細への導線、カレンダー月表示、設定の一部。ルーティングの説明は画面の並びがあると一気に伝わる。

---

daily-snap 開発ログ
前: 思い出は「対話」と「手がかり」で…
次: pgvector はまだ。でも DB は先に「記憶の置き場所」まで決めた
索引: 04-10 MAS · 04-11 AI · … 04-30 Docker