Contents
まず結論
今週決めた方針は3つです。
- 自分のアプリのデータは、できるだけMac miniの中（手元）に置く。クラウドのSupabaseは、実はDockerで丸ごとローカルに立てられると知った
- 家計アプリを「中心」にして、連携アプリを育てていく構想を固めた（第1弾は猫の健康カルテ）
- 同時に動かす糸を、今月は絞る。手を広げすぎている自覚があるため
発見：Supabaseは、丸ごと自宅に置ける
私のアプリはSupabase（クラウドのデータベースサービス）を使っています。てっきり「クラウドでしか動かないもの」だと思っていたのですが、Supabaseはオープンソースで、コマンド1つで自分のMacの中にクラウド版とほぼ同じ環境が立ち上がると知りました。裏ではDockerが約10個の部品（データベース・認証・管理画面など）を一気に起動してくれる仕組みです。
なぜこれが嬉しいか。初学者向けに言うと、「壊しても本番に影響しない実験場」が手に入るからです。権限まわりの複雑な設定をクラウド上で試行錯誤すると、ミスが本番データに直撃します。ローカルなら、失敗してもコマンド1発でまっさらに戻してやり直せる。試行錯誤が無料になります。
ただし全部をローカルにする気はありません。自分しか使わないものは手元、他人が触る本番部分だけクラウド、というハイブリッドが現実解です。手元のマシンは夜スリープするし停電もする。「24時間止められないもの」を家庭の机の上に置くのは、まだ早いからです。
ついでにDockerの学びもひとつ。Macの上のDockerは、実は裏で小さなLinuxの仮想マシンをこっそり動かして、その中でコンテナを回しているそうです。DockerはLinuxが本場、というのはこういう意味だったのかと腑に落ちました。
構想：家計アプリを「中心」に、連携アプリをぶら下げる
もうひとつ、今週固めたのが連携シリーズの構想です。以前GitHubに登録した自作の家計管理アプリには、日付・金額・支払先のデータが日々貯まっています。この既存データを”入口”にすれば、新しいアプリはゼロから作らなくていい、と気づきました。
第1弾として考えているのが「猫の健康カルテ」です。家計アプリに動物病院の支出が登録されたら、健康アプリ側に「未記入の診察」として通知が出る。タップして症状・体重・処方を追記すれば、猫ごとの健康タイムラインが育っていく、という形です。
なぜ「支出→通知」方式なのか。領収書が発生した瞬間が、記録すべき瞬間だからです。人間は「後で書こう」を必ず忘れます。家計入力というすでにある習慣に相乗りすることで、記録が途切れない。連携の一番の価値はここにあると思っています。
この構想が固まると、「共通の家計データベースを中心に、各アプリがぶら下がる」という全体の絵が描けます。データを手元に置く方針とも噛み合います。家族の医療費やサプリ購入の管理など、続きのアイデアも既にメモしてあります。
正直な反省：糸が多すぎる
ここまで書いておいてなんですが、今週、自分の開発全体を点検してもらったら、一番のリスクは技術ではなく「手の広げすぎ」だと指摘されました。
電車アプリ、ビル管理ポータル、家計アプリと連携構想、ローカルLLM学習、Docker学習、このブログ。一つ一つは筋が通っていても、使える時間は週に数時間。合計の量が時間に勝っていて、注意力の分散でどれも中途半端になるのが、現実的に一番起きやすい破綻だと。
耳が痛いですが、そのとおりです。なので今月は「電車アプリの検証を続けること」と「ポータルの権限まわりを一歩進めること」の2本に絞り、今日書いた連携構想は設計メモまでで止めて、実装はMac mini到着後に回します。構想を寝かせるのも、立派な進め方だと思うことにしました。
おわりに
「クラウドのAIは借りている知性、ローカルのAIは所有している知性」という言葉が、自分の学習プランに書いてあります。データも同じで、手元に置けるものは手元に置きたい。Mac miniが届いたら、まずはローカルSupabaseを立てて「壊しても平気な実験場」を作るところから始めます。
Supabase / Docker / Mac mini / 個人開発
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
