はじめに

私は普段データサイエンティストとして働いています。

扱う道具はPythonとSQLが中心で、いわゆる「アプリ開発者」ではありません。

それでも、自分の生活を記録するアプリや、トレーナー業務を管理するアプリなど、いくつかの個人アプリを実際に作って公開してきました。

最初にぶつかったのは、機能の作り方そのものよりも「そもそも何を使えばいいのか」という入り口の問題でした。

世の中には技術の選択肢が無数にあり、しかもそのどれもが「これが正解」と言っているように見えます。

素人にとっては、ここが一番の難所です。

この記事は、フロントエンドの専門家ではない人間が、どういう基準で技術を選び、どんな構成に落ち着いたのかを整理したものです。

これから個人開発を始めたい人、特に私と同じように「分析はできるけどアプリは作ったことがない」という人の地図になればと思っています。

そもそも、アプリは何でできているのか

技術選定の話に入る前に、アプリがどんな部品でできているかをざっくり整理しておきます。

ここが曖昧だと、何を選んでいるのかが分からなくなるからです。

個人開発で作るような小さなアプリでも、大きく分けると3つの部品でできています。

画面（フロントエンド）：ユーザーが実際に目にして触る部分です。ボタンや入力欄、一覧表示などがここに当たります。
裏側の処理（バックエンド）：画面からの「保存して」「一覧をちょうだい」といった要求を受け取り、処理する部分です。
データの保管庫（データベース）：記録した内容を貯めておく場所です。アプリを閉じても消えないのは、ここに保存されているからです。

レストランに例えるなら、フロントエンドは「客席とメニュー」、バックエンドは「注文を捌く厨房」、データベースは「食材を保管する冷蔵庫」です。

アプリを作るというのは、この3つを用意して、互いにやり取りできるように繋ぐ作業だと考えると分かりやすいです。

技術選定とは要するに、この3つそれぞれに「どの道具を使うか」を決めることです。

私の選定基準

選択肢が多すぎて迷うとき、判断の軸を先に決めておくと格段に楽になります。

私が検討したのは次の3つでした。

1. 学習コストが低いこと

本業の合間に作るので、新しいことを一から覚える余裕はあまりありません。

すでに知っている知識が活かせるか、情報が豊富で詰まったときに調べやすいかを重視しました。

2. AIに任せやすいこと

私は実装の多くをAIコーディングのツールに任せています。利用者が多くて情報がたくさんある技術ほど、AIも正確なコードを書いてくれます。

マイナーな技術を選ぶと、自分もAIも手探りになり、かえって時間がかかります。

3. 無料で動かせること

個人開発は趣味の延長です。お金がかかると続きません。小さく始めて、無料の範囲で公開まで持っていけることを最低条件にしました。

この3つはどれも「技術的に優れているか」とは別の軸です。

素人にとっては、性能の高さよりも「自分が挫折せずに完成まで辿り着けるか」のほうがずっと重要だと考えました。

私の選んだ技術スタック

上記の基準で選んでいった結果、最終的に次のような顔ぶれに落ち着きました。

それぞれを「他にどんな候補があった中で、なぜそれを選んだのか」という形で紹介します。

Webの画面：Next.js / React

まず用語を整理します。

Reactは画面を作るための部品箱のようなもので、Next.jsはそのReactを土台に、画面遷移やページの高速表示など「アプリに必要な周辺機能」を最初から揃えたセットです。

Reactが食材なら、Next.jsは食材付きの調理キット、というイメージです。

Webの画面を作る道具には、他にもVue、Svelte、Angularといった有力な候補があります。

中でもSvelteは「書く量が少なく動作も軽い」と評価が高く、純粋な書き味だけならReactより好まれることもあります。

それでも私がReact（Next.js）を選んだ理由は、性能ではなく「情報量」です。

利用者が圧倒的に多いということは、つまずいたときに検索で解決策が見つかりやすく、AIも正確なコードを書いてくれるということです。

素人にとっては「一番洗練された道具」より「困ったときに助けが多い道具」のほうが、完成まで辿り着ける確率が高い。これが決め手でした。

候補	特徴	素人目線での評価
React / Next.js	利用者が最も多く、情報・周辺ツールが豊富	◎ 困ったときの助けが多い。AIも書きやすい
Svelte	書く量が少なく動作が軽い。書き味の評価は高い	△ 良い道具だが情報量で劣り、詰まった時の対処が難しい
Vue	バランスがよく学習しやすい	○ 有力だが日本語以外の情報・AI対応はReactが上
Angular	大規模・企業開発向けで機能が豊富	△ 個人開発には重厚すぎる

スマホの画面：Flutter

スマホアプリを「iPhoneとAndroidの両方」で動かそうとすると、本来はそれぞれ別の言語で2回作る必要があります。

これを「1回書けば両方で動く」ようにしてくれるのが、Flutterのようなクロスプラットフォーム開発の道具です。

ここでの主な対抗馬はReact Nativeでした。

これはWebで使うReactの知識をほぼそのままスマホ開発に持ち込める道具で、Web側でReactを使う私にとっては、知識を統一できる魅力的な選択肢です。

それでもFlutterを選んだのは、次の2点です。

1つ目は、Flutterが画面を自前で描く仕組みのため、iPhoneでもAndroidでも見た目がきれいに揃いやすいこと。

デザインの統一感を出しやすいのは、凝ったアプリを作りたい個人開発と相性が良いです。

2つ目は、近年Flutterのほうが勢いがあり、状態管理（画面が持つデータの管理方法）の定番のやり方が固まっていて、情報を追いやすかったことです。

React Nativeと迷いましたが、「スマホはスマホで、きれいに作れる道具に集中する」と割り切りました。

候補	特徴	素人目線での評価
Flutter	画面を自前で描き、iPhone/Androidで見た目が揃う。近年勢いがある	◎ デザインの統一感を出しやすく、情報も追いやすい
React Native	Webで使うReactの知識をそのまま流用できる	○ 知識を統一できる魅力。最終的にFlutterと迷った相手
ネイティブ（Swift / Kotlin）	OSごとに別々に作る。性能・最新機能は最強	△ 2回作る手間が重く、個人開発には負担が大きい

データの保管庫：Neon / Supabase

データを貯める保管庫にはPostgresというデータベースを選びました。

これは定番中の定番で、ここはあまり悩む余地がありません。問題は「そのPostgresをどこで動かすか」です。

候補はいくつかありました。

自分のパソコンの中で動かす方法（ローカル）、GoogleやAWSといった大手クラウドの本格的なサービス、そしてNeonやSupabaseのようなサービスです。

自分のパソコンで動かす方法は、手元で完結して練習には手軽ですが、公開には向きません。他の人が使うには、自分のパソコンを常に起動しておく必要があるからです。
大手クラウドの本格サービスは高機能ですが、その分だけ設定項目が多く、個人開発には大げさで、油断すると料金もかさみます。
NeonとSupabaseは、この中間にある「面倒な管理を肩代わりしてくれて、しかも無料枠から始められる」サービスです。

サーバーの管理を自分でやらなくていいので、素人は本来やりたかった機能づくりに集中できます。

とりわけNeonは、使っていない間は自動で止まって料金を抑えてくれる仕組みがあり、個人開発の「たまにしか動かさない」使い方に合っていました。

Supabaseは保管庫だけでなく、ログイン機能なども一式まとめて用意してくれる点が便利でした。

候補	特徴	素人目線での評価
Neon / Supabase	管理を肩代わりしてくれ、無料枠から始められる	◎ 機能づくりに集中できる。個人開発に最適
自分のパソコン（ローカル）	手元で完結し、練習には手軽	△ 公開には不向き（常時起動が必要）
大手クラウド（Cloud SQL等）	高機能で大規模にも耐える	△ 設定が多く大げさ。料金もかさみがち

公開する場所：Vercel

作ったWebアプリは、最後にインターネット上に載せて初めて他の人が使えます。

この置き場所にVercelを選びました。VercelはNext.jsを作っている会社のサービスで、Next.jsとの相性が抜群です。

具体的には、コードを保存するだけで自動的に公開作業まで済ませてくれて、しかも個人開発レベルなら無料で動きます。

「画面はNext.js、公開はVercel」というのは、いわば純正の組み合わせで、素人がつまずきにくい王道のルートでした。

候補	特徴	素人目線での評価
Vercel	Next.jsの開発元。保存するだけで自動公開。無料枠あり	◎ Next.jsとの純正の組み合わせで詰まりにくい
Netlify	Vercelに近い手軽さ。汎用的	○ 有力だが、Next.jsならVercelが一歩有利
大手クラウド（AWS等）に自分で構築	自由度が高い	△ 設定が多く、公開までの手間が大きい

ここで一つ補足です。

私が作ったアプリには「Webアプリ」と「スマホアプリ」の2種類があり、画面を作る道具がNext.jsとFlutterに分かれています。

なぜ片方に統一しなかったのか、Webとスマホでは何が違うのかは、それ自体が面白いテーマなので別の記事で扱います。

同じ構成を使い回すという考え方

最後に、選定で一番効いた考え方を紹介します。

それは「一度選んだ構成を、複数のアプリで使い回す」というものです。

個人開発でありがちな失敗は、アプリごとに流行りの新しい技術を試してしまい、毎回ゼロから学び直すことです

これだと知識が積み上がりません。

私は逆に、最初のアプリで選んだ構成を、次のアプリでもほぼそのまま使いました。

すると2つ目以降は学習コストがほとんどかからず、作ることそのものに集中できます。

一度覚えた苦労が、そのまま次の資産になる感覚です。

素人にとって、技術選定は「一番良いものを探す作業」ではなく、「自分が長く付き合える、ひとつの型を決める作業」なのだと思います。

おわりに

今回は全体像として、個人アプリがどんな部品でできていて、私がどんな基準で何を選んだのかを整理しました。

アプリは「画面・裏側の処理・データの保管庫」の3つでできている
素人の選定基準は「学習コストの低さ・AIに任せやすさ・無料で動くこと」
一度決めた構成を使い回し、知識を資産にしていく