Clean
情報の優先度をカードと余白で整理。今日見るものへ迷わず到達できる構成。
NATURAL LANGUAGE × AI DEVELOPMENT
りょっぽ
続けられない日も責めない、
自律支援Webアプリ
予定を管理するだけでなく、今日できたことを言葉にして残す。 「できなかった」ではなく「積み上がった」に目を向けるための個人開発プロダクトです。
コードをほぼ手書きせず、自然言語で仕様を組み立てて開発。 自分で課題・体験・動作条件を考え、AI / Codexへ実装を依頼し、実画面を見ながら改善しました。
12検証対象画面
111Design Studio状態
UIDユーザー別データ分離
PWAiPhoneホーム画面対応
WHAT I DID
プロダクトを考え、
仕様にして、AIと形にした。
AIが自動で作ったのではありません。何を作るか、何を変えてはいけないか、どこまでできれば完成かを自分で決め、結果を見て最終判断しました。
- 課題設定
- アイデア
- 機能仕様
- UI/UX判断
- デザインの方向性
- AIへの指示
- 変更禁止範囲の定義
- 実画面確認
- テスト条件の設計
- 最終判断
01 / WHY
タスク管理が、
自分を責める材料になっていた。
一般的なToDoは、未完了の数を強く見せます。調子が落ちた日ほど、画面には「できなかったこと」だけが残る。 必要だったのは、管理を強くする道具ではなく、自分の前進を見失わない仕組みでした。
Problem未完了が自己評価になる
→
Reframeできたことを記録する
→
Outcome積み上がりが見える
「続ける」より先に、
「戻ってこられる」を設計する。
02 / DESIGN CONCEPT
整理された余白 × 自然な色 ×
少し変なかわいさ
使うたびに気を張らない、静かな道具であること。 一方で、完全に無機質にはせず、りょっぽという存在が少しだけ感情の余白をつくります。
Natural
生成り、セージ、サンドを中心にしたアースカラー。標準配色と独立して切り替え可能。
Playful
邪魔にならない範囲で意外性を入れ、作業だけにならない関係をつくる。
Warm Ivory#F7F3EA
Warm White#FFFCF6
Primary Sage#7E9B76
Deep Sage#5F7658
Sand#C9A77C
Terracotta#C98262
03 / SELECTED FEATURES
機能ではなく、
一日の流れで設計する。
採用向けに、設計判断が伝わる機能を厳選しました。すべて現行コードで動作しているものです。
01 / TODAY
今日のダッシュボード
Google Calendarの予定、自分で登録するリマインダー、今週の目標を役割ごとに分けました。ホームカードは、これまでの並びを保ったまま順番を変えられるようにしています。
02 / REFLECTION
今日できたこと
振り返りで書いた「今日できたこと」を日付ごとに残します。最近の6日間、すべて、年月別から選んで振り返れます。
03 / SUGGESTION BOX
セルフ目安箱
違和感やアイデアを、カテゴリと状態で育てる自分専用の目安箱です。内容を残したまま、note原稿の下書きへ発展させられます。
04 / PERSONALIZATION
外観とホームのカスタマイズ
標準／アースカラーと標準／やわらかフォントを別々に選べます。カードの並びも、ログインしている人ごとに管理します。
05 / INTEGRATION
保存を止めない外部連携
Google Calendarは、一度つないだ後は同じりょっぽアカウントから利用できます。Notionとの同期が失敗しても、りょっぽに書いた内容は先に保存して失わないようにしました。
りょっぽGoogle CalendarNotion
04 / UI & UX
「できる」だけでなく、
壊れない・迷わないまで考える。
同じ記録場所を使う
ホームの「記入」は、すでにある振り返り入力へ案内します。入口が増えても、保存先と入力の仕組みは一つに保ちました。
入力を失わない
外部同期の失敗、画面移動、怪異イベントが起きても、入力した文章・選択位置・画面の位置を失わないことを優先しました。
モバイルの実寸で詰める
指で押しやすい44px以上の範囲、iPhone画面下部の余白、キーボード表示、320px幅を確認。実機で感じた違和感から何度も調整しています。
見た目以外でも伝える
アイコンだけの操作にも、読み上げで意味が伝わる名前を用意。キーボード操作と、端末のアニメーション軽減設定にも対応しました。
Technical note
実装では aria-label / title、:focus-visible、prefers-reduced-motion、safe-area-inset を使い分けています。
05 / PLAYFUL EXPERIMENT
継続を、
作業だけにしない。
低確率で起きる「怪異イベント」は、機能効率とは別の方向から再訪と好奇心をつくる実験です。 初期状態はOFF。開始・進行・復旧を分け、途中で画面や入力が壊れたまま残らないようにしました。
重量超過によるUI崩壊
りょっぽが膨らみ、画面全体が傾きます。5回のタップまたはスキップで、完全に元へ戻ります。
入力欄窃盗
本物の入力欄はそのままに、見た目だけ「持って逃げる」を表現。捕まえると、入力途中の状態へ戻ります。
怪異通知
普段のリマインダー通知とは混ぜずに管理。通知を許可していない場合も、イベント本体だけは安全に続きます。
Technical note
イベント専用レイヤーと一時クラスを使い、idle → overweight / fleeing → restoring → completed の流れで多重発火と残留状態を防いでいます。
06 / ITERATION
違和感を、
仕様へ変換する。
「一度作って終わり」ではなく、実機で見えた違和感を原因まで分け、変えてはいけないことと完成条件を決めて改善しました。
CASE 01
カード並び替えのガタつき
- 違和感iPhoneでカードをつかんだ瞬間、カードとリスト全体が縮む
- 原因動かすカードと、元の場所に残す透明な場所取りの高さが揃っていなかった
- 再設計動かす前に高さを測り、カード・元の場所・リスト全体へ同じ高さを保つ
- 検証長押し、スクロール、保存・キャンセルまで、元の操作が壊れていないか確認
Technical note
getBoundingClientRect() で実測し、placeholder と list container の高さを保持。位置移動は translate3d() のみに限定しました。
CASE 02
Google再連携が毎回必要
- 違和感ログインのたびにGoogleの許可が必要で、使い続ける負担になる
- 原因短時間で切れる認証情報だけを前提にしていた
- 再設計長く使える認証情報をブラウザに置かず、安全なサーバー側で暗号化して保管
- 検証期限切れ、権限の取り消し、必要な許可の不足、連携解除を個別に確認
Technical note
Refresh Token をD1へAES-256-GCMで暗号化保存。Firebase ID Tokenで確認したUIDに結び付け、Google APIの401時だけ更新後に1回再試行します。
CASE 03
追加メニューが窮屈
- 違和感画面下から出るメニューが、iPhoneのホーム表示へ近すぎる
- 判断余白を足すだけでなく、「追加先を選ぶ画面」という役割から見直す
- 再設計すでにある画面移動の仕組みを使い、追加専用ページへ変更
- 検証6つの追加先、元の画面へ戻る動き、320px幅、ブラウザの戻る操作を確認
Technical note
既存のhash routingへ #add を追加し、各項目は既存モーダルや入力欄を開く処理へつなぎました。
07 / TECHNOLOGY
小さなUIの裏側に、
安全な境界をつくる。
データ、ログイン、外部サービスとの連携を、それぞれに合う場所へ分けました。ブラウザへ秘密情報を置かないことを大切にしています。
CLIENT
PWA / Vanilla JavaScript
HTML / CSS Custom Properties / Web APIs
Service Worker / Badging API
Firebase
Authentication
Cloud Firestore
UID別Security Rules
Cloudflare
Workers / Static Assets
D1 / Cron Triggers
Web Crypto API
External APIs
Google Calendar
Notion API
Firebase Cloud Messaging
Technical note
画面はVanilla JavaScriptのPWA。Firebase Authentication / Firestore、Cloudflare Workers / D1、Google Calendar API、Notion API、Web Pushを用途ごとに分けています。
08 / AI-ASSISTED DEVELOPMENT
コードを手書きする代わりに、
判断できる仕様をつくった。
Codexを実装パートナーとして使いました。私は課題、体験、変えてはいけないこと、完成条件を決めます。AIが作った結果をそのまま採用せず、実画面で違和感を見つけ、次の具体的な指示へ戻しました。
課題設定、機能の発想、仕様、UI/UX判断、デザインの方向、AIへの指示、実画面確認、テスト条件、最終判断
コード化、既存コードの調査、差分作成、テスト実行、検証結果の整理
01
Idea生活の中で感じた不便や違和感を見つける
02Specification誰が、いつ、どう使うかを文章にする
03Boundaries変えてよい場所と、変えてはいけない場所を決める
04ImplementationAI / Codexが既存コードを調べて実装する
05Browser review実際の画面を自分の目と操作で確認する
06Correction「高さ」「間隔」「動作」まで具体的に直し方を伝える
07Testing新しい機能と、壊してはいけない機能をまとめて確認する
08Release確認済みの状態だけを本番へ反映する
09 / QUALITY
変更のたびに、
戻らないことを確かめる。
画面構成、保存の計算、外部連携、ログイン、通知、Design Studioなど。
空・複数件・長文・エラー・連携状態を開発用Studioで切り替え。
横オーバーフロー、safe area、入力時の重なりを確認。
トークン・暗号鍵をStatic Assetsや配布物へ含めない。
検証メモ：現環境ではFirestore Emulatorが未起動のため、Security Rulesの24ケースと親スイートは未完了。その他485テストは通過し、秘密情報検査は問題なしでした。数値は2026年9月1日のローカル検証結果です。
01
既存機能の確認
保存、同期、日付、イベントの進行など、壊れやすい部分を機能ごとにテスト。
02
ブラウザ確認
数値を見るだけで終えず、実画面の開閉、移動、スクロールまで操作。
03
非破壊の確認
入力した文章、選択状態、保存済みの順番、外部サービスの既存データを変更前後で保護。
Technical note
今回確認できた485件とは別に、Firestore Security Rules 24件はEmulator未起動のため未完了です。成功件数へ混ぜず、検証条件と一緒に記載しています。
10 / WHAT I LEARNED
良い体験は、
小さな違和感を放置しないことから生まれる。
仕様は機能の説明ではなく、判断基準です。変えてはいけない範囲を決めることで、小さな改善を安全に積み重ねられると学びました。
見た目の問題も、画面の作り・入力の状態・通信のタイミングまでたどると原因があります。「なんとなく直す」より、数値と再現条件を持つことが近道でした。
そして、継続を支える道具に必要なのは、厳しさだけではありません。安心して戻れることと、また開きたくなる少しの余白。その両方をこれからも探ります。