0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【個人開発】「あのとき、なぜこの選択をした?」を記録する「まよログ」を作りました(React / TypeScript / Supabase)

0
Posted at

※本アプリは、企画・設計・実装・テストまでの一連の開発工程を経験することを目的として制作した個人開発アプリです。公開せず、ローカル環境で動作確認を行っています。

はじめに

企画から実装までに挑戦してみたいと思い、Webアプリを開発しました。
作成したのは、日々の生活の中での「迷った状況」「選んだ理由」「その後の結果」を記録できる「まよログ」というWebアプリです。
単なるメモアプリではなく、判断した時点の記録にあとから結果や学びを追記でき、蓄積した記録をAIで分析することもできます。
この記事では、まよログを作った理由、実装した機能、設計、開発中に詰まったところ、作り終えて感じたことを書いていきます。

作ったアプリの概要

まよログ — 迷いと判断を、未来の自分の味方にする。

スクリーンショット 2026-09-03 21.53.05.png

  • 迷っている状況や選んだ理由を記録する
  • 判断したあとに、結果・学び・満足度を振り返る
  • 複数の記録をGeminiで分析し、自分の判断傾向を知る

なぜこのアプリを作ったのか

社会人になり、転職や学習方法、引っ越しなど、すぐに答えを出せない迷いが増えました。迷う過程でいろいろ考えても、時間が経つと残るのは「選んだこと」と「結果の良し悪し」だけになりがちです。
しかし、本当に今後の生活に活きるのは、以下のようなことだと気づきました。

  • 当時何に迷っていたか
  • 何を大切にして決めたか
  • どんな感情で、何を学んだか

判断を「その場で終わる出来事」ではなく「次の選択に活きる経験」に変えることが、このアプリの目的です。

カスタマージャーニー

ユーザーが迷いを感じてから、記録を次の判断に活かすまでの流れを整理しました。

スクリーンショット 2026-09-03 22.03.52.png

記録すること自体をゴールにせず、迷い → 記録 → 行動 → 振り返り → 自己理解というサイクルを作ることを意識しました。

デザインで参考にしたもの

参考にしたのは、日記やジャーナリング、ノートのような「自分の考えを落ち着いて書ける」体験です。
判断や感情を扱うアプリなので、業務用ダッシュボードのような硬さではなく、紙のノートを開くような温かさを目指しました。

主な機能

1. Googleアカウントでログイン

スクリーンショット 2026-09-03 21.53.05.png

Google OAuthでログインできるようにしました。

判断や感情は個人的な情報なので、未ログインでは記録を読み書きできません。ログイン後も、SupabaseのRow Level Security(RLS、行単位のアクセス制御)で本人のデータだけを操作できるようにしています。

2. 判断記録の一覧表示

スクリーンショット 2026-09-03 22.06.15.png

ログインすると、これまでの判断が新しい順で並びます。
カードにはカテゴリー・日付・タイトル・迷っていた状況を表示していて、一覧を眺めるだけでも「あのとき何で迷っていたか」を思い出せるようにしています。

3. 新しい判断を記録

スクリーンショット 2026-09-03 22.06.46.png
スクリーンショット 2026-09-03 22.08.01.png

新規作成画面では、次の項目を保存できます。

タイトル
カテゴリー
状況・迷っていたこと
最終的な判断
そのときの気持ち
決めた理由

自由記述欄ひとつにまとめてしまうと、あとから読み返しづらくなります。そこで「状況」「判断」「気持ち」「理由」を分けました。入力する時点で自然と考えが整理されますし、あとで振り返るときも背景をたどりやすくなります。

4. 判断の詳細・編集・削除

スクリーンショット 2026-09-03 22.08.40.png

保存した記録は詳細画面で確認できます。

迷っていたこと、最終的な判断、決めた理由、当時の気持ちを同じ画面でまとめて見られます。編集と削除にも対応しています。

5. 結果と学びを振り返る

スクリーンショット 2026-09-03 22.09.00.png

判断したあとに、結果・学んだこと・満足度を追記できます。

これがまよログの中で一番こだわった機能です。

結果がいまひとつだった場合でも、「判断した時点では合理的だった」「次はここの確認を増やそう」と整理できれば、その選択は失敗だけで終わりません。判断時点の記録と結果を分けて保存することで、後知恵だけで当時の自分を評価しないようにしています。

6. キーワード検索・カテゴリー絞り込み

スクリーンショット 2026-09-03 22.09.32.png

記録が増えても探しやすいよう、検索とカテゴリー絞り込みを実装しました。

検索対象はタイトル・状況・理由。カテゴリーは「仕事」「暮らし」「人間関係」「学び」「その他」の5つです。

7. Geminiによる判断傾向の分析

スクリーンショット 2026-09-03 22.09.48.png

蓄積した判断記録をもとに、AIが「分析のまとめ」「判断するときの強み」「次の選択に向けたヒント」の3項目を返します。

AIに正解を決めてもらうのではなく、自分では気づきにくい共通点を言葉にしてもらう、いわば補助役として使っています。

プロンプトでも断定的な言い方を避け、やさしい日本語で返すよう指定しました。返却形式はJSONに固定し、画面で扱う前に summarystrengthssuggestions の構造をチェックしています。

使用した技術

分類 技術 用途
フロントエンド React 19 UI・状態管理
言語 TypeScript 型安全な実装
開発環境 Vite 開発サーバー・本番ビルド
認証 Supabase Auth Google OAuth
データベース PostgreSQL / Supabase 判断・振り返りの保存
サーバー処理 Supabase Edge Functions Gemini APIとの安全な通信
AI Gemini 3.5 Flash Lite 判断傾向の分析
テスト Vitest / Testing Library 検索処理・画面挙動の検証
CI/CD GitHub Actions ビルド・テスト・デプロイ
ホスティング Firebase Hosting Reactアプリの配信

システム設計

スクリーンショット 2026-09-03 22.11.16.png

ブラウザからGemini APIを直接呼ばず、Supabase Edge Functionを経由する構成にしました。

ブラウザ
  ├─ Supabase Auth:Googleログイン
  ├─ PostgreSQL:本人の判断・振り返りを保存
  └─ Edge Function
       ├─ JWTの確認
       ├─ AI利用回数の確認
       ├─ Gemini APIの呼び出し
       └─ 応答形式とエラーの変換

ER図

スクリーンショット 2026-09-03 22.11.49.png

データは次の4つのテーブルに分けています。

profiles:ユーザーの表示情報
decisions:判断した時点の状況・選択・理由・感情
reflections:判断後の結果・学び・満足度
ai_analysis_rate_limits:ユーザーごとのAI利用回数

工夫したこと

AI分析のレート制限
AI分析はユーザーごとに1時間10回までに制限しました。レート制限用のテーブルはクライアントから直接読み書きできないようにし、認証済みユーザーが専用関数を経由した場合だけ回数を更新する仕組みです。外部APIの費用増加や連続実行による負荷を抑えるためです。

大変だったこと

1. AI分析で502エラーが発生した

開発中、AI分析を実行すると次の表示が出るようになりました。

AI analysis is temporarily unavailable.

Geminiのモデル指定が古い、または利用できない
Gemini APIがエラーを返している
応答が想定したJSON形式になっていない
Edge Functionの処理がタイムアウトしている
フロントエンドがSupabase Functionsのエラー本文を取得できていない

Edge Function・フロントエンドAPI・画面表示の3層を見直し、Edge Function側ではタイムアウト、利用上限、安全性によるブロック、不正なAI応答をそれぞれ別のエラーコードに分けました。フロントエンド側ではエラー本文を安全に読み取り、利用者向けの日本語に変換しています。

AI分析に時間がかかっています。少し時間をおいてもう一度お試しください。
AI分析の利用上限に達しました。1時間ほど時間をおいてお試しください。
安全上の理由により、この記録はAIで分析できませんでした。

APIの内部情報やGeminiの生レスポンスをそのまま画面に出さず、利用者が次に取れる行動だけを伝えるようにしています。

2. 「分析中…」が長時間続く問題

外部APIの応答を無期限に待っていると、ボタンが「分析中…」のまま止まって見えました。フロントエンドとEdge Functionの両方にタイムアウトを入れ、一定時間を超えたら処理を打ち切って再試行できる状態に戻すようにしました。外部APIを使う機能は、成功したときだけでなく「遅い」「返ってこない」「形式が違う」といった失敗のパターンも設計しておく必要があると感じた部分です。

3. MVPの範囲を絞る

グラフ表示、通知、共有機能なども考えましたが、最初から機能を増やすと「判断を振り返る」という中心の体験が複雑になっていたため絞りました。今回は記録・検索・振り返り・AI分析に絞りました。作りたい機能ではなく、ユーザーが目的を達成するのに必要な機能から考えるようにしています。

テストと動作確認

検索・カテゴリー絞り込みについては、Vitestでテストをおこないました。

カテゴリーで絞り込める
タイトル・状況・理由を検索できる
検索語の前後の空白を無視できる

変更後は npm run testnpm run build を実行し、テストとTypeScriptのビルドが通ることを確認しています。AI分析については、ログイン済みの実環境からEdge Functionを呼び出し、分析結果が画面に表示されるところまで確認しました。

作ってみて感じたこと

ReactやTypeScriptなど触れてきた部分を改めて実装して思い返すのと同時に忘れている部分も多くありました。
個人開発では、コードを書くこと以外にも考えることがたくさんありました。どんな問題を解決するのか、誰に使ってほしいのか、どこまでをMVPに含めるのか、どの情報を保存するのか、エラーが起きたとき何を表示するのか、秘密情報や個人データをどう守るのかなどです。
特に印象に残っているのは、正常系を作るだけでは「価値のあるアプリ」にはならないということです。一方で、改善したい点もあります。現状のテストは検索機能が中心なので、判断記録や振り返りの保存、AIエラー表示なども自動テストに加えたいです。実際に使い続けて、入力しづらい項目や振り返りやすいタイミングも検証していきたいと考えています。

今後追加したい機能

振り返り時期のリマインド
AI分析結果の保存

おわりに

まよログを作ったことで、個人開発は単に技術を組み合わせるだけではなく、課題を見つけ、利用者の体験を設計し、安全に使える状態まで責任を持つことだと学びました。

開発中は、「どの機能を追加するか」だけでなく、「利用者にとって本当に価値のあるアプリにするにはどうすればよいか」を常に考えながら、設計と実装を進めました。
機能を増やすことよりも、解決したい課題から軸をぶらさないことの大切さを実感しています。

ここまで読んでいただき、ありがとうございました。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?