【技術編】生成AIドリブン個人開発のすすめ〜超低コスト開発と運用〜
こんにちは。わいけいです。
この記事では、個人開発におけるコスパの良い技術構成や自分なりの生成AIの活用方法について書いていきます。
最近私は個人開発でMydayAIというサービスを公開したのですが、こちらを作る中で思ったことなどをまとめていく形になります。
ちなみにこちらのMydayAIですが、もともとは生成AIなんでも展示会 vol.4に出展するために作成したサービスでして、日記をつけるとそれをAIが分析してくれるというものになっています。
公開してから1ヶ月未満ですが、広告費0円で90人以上の方が登録してくれていて、自分の中では今までで一番ユーザー獲得ペースが早いサービスになっています。
改めて、生成AIなんでも展示会を立ち上げてくれた運営メンバーの方々に感謝申し上げたいです。
この記事では個人開発についてつらつらと書いていくわけですが、ここに書くのはあくまでも自分なりの方法であり「これがベストプラクティスだ！」という風に主張するつもりは全くありません。
むしろ、まだまだ改善の余地はあると思うので、他にもいいアイデアを持っている方はコメントなどしてくれると嬉しいです。
なお、この記事は技術的な側面にフォーカスしたものです。
開発したサービスのコンセプトや執筆時点でのKPIについて知りたい方は、下記の記事をご覧ください。
個人開発と業務での開発の違い
まず最初に、個人開発と業務の開発の違いについて自分が感じたことを書いていきたいと思います。
インフラコスト
最大の違いは言うまでもなく資金力です。
企業自体の資金力やサービスの収益性やその他の性質によってもかなり変わってきますが、企業がサービスを運営する場合は、サーバーの費用として場合によっては月数百万円程度かかっても許容されるケースは多いと思います。
GPUサーバーなどを必要としない一般的なスタートアップであっても、AWSなどのクラウドの費用を総計すると月に数十万円程度かかっているという状況が一般的なのではないでしょうか。
しかし、この費用を個人で負担するのはかなり大変です。
私のこれまでの経験上、個人開発では広告費も全然かけられないケースが多いので、特にサービス発足当初は売上が限りなくゼロに近いケースが大半でしょう。
こういった背景もあり、個人開発ではインフラの費用を極限まで圧縮することがとにかく重要です。
通常のサービス運営において、費用的なボトルネックになりやすいのがDBです。
アプリケーションサーバーやファイルストレージなどは、従量課金制のもの（AWSでいえば、LambdaやS3など）を使うことで、サービス時のインフラ費用を月1000円未満に抑えることは比較的たやすいと思います。
しかし、大手のクラウドベンダーのMySQLやPostgreSQLといったRDB系を使い始めた途端に、インフラのランニングコストが月数万円を簡単に突破してしまうでしょう。
もちろん、これらのサービスは単に高いというわけではなく、簡単にバックアップが取れたり、スケーリングを楽に行えたりと色々なメリットがあります。
企業レベルではこれらのサービスを活用していくのは多くの場合、合理的だと思います。
しかし、個人開発の場合は、機能的な利便性を捨ててでもこのコスト負担を減らしたいと思うのが一般的な感覚なのではないでしょうか（少なくとも私はそうです）。
なお、多くの場合DynamoDBなどのNoSQL系のDBを活用することで、DBのコストを月数百円未満に圧縮することも可能です。
が、個人的にはNoSQL系のサービスを使うデメリットをこれまで色々と体験してきたので、サービスのメインのDBはRDBにしておきたいという気持ちがありました。
具体的には、データの論理設計に癖があるために後で方向転換する時に大変だったり、SQLでいうGroup Byなどに相当する集計系のデータを算出したいときなどに工夫しないと許容出来ないレベルで応答が遅くなったりといったデメリットです。
別途、BigQueryを使うなどして状況を緩和することも可能ですが、個人開発レベルでは使用するサービスを増やしてインフラコストをさらに上げるということは極力したくないものです。
ソースコードのアーキテクチャ
チームで開発する時にはクリーンアーキテクチャ、DDDなどの開発作法に従ってコードを書いていくケースが多いと思います。
しかし、個人開発の時にはこの辺の流儀には必ずしも従う必要はないと思います。
そもそもソースコードのアーキテクチャを工夫する大きな理由として「他人にも読みやすいコードを書く」ということがあります。
が、いかんせん個人開発では自分以外コードを見ることはありません。
単に自分がわかればそれでいいのです。
（ただし、数ヶ月後の自分が分かりやすくなるように定番のアーキテクチャを採用するのも当然ありです）
また、現代の個人開発では生成AIを活用しまくることになります。
人にとっての可読性を重視しようとしてたくさんファイルを分割してしまうと、AIに与えるコンテキストが複雑・長大になって生成精度が落ちてしまうことも懸念されます。
なので後でも触れる予定ですが、例えば自分はAPIのファイルを作成する時であれば、API間でのコードの重複を全く恐れず、かつファイル分割もほぼ行わずにベタベタに書いています。
具体的に言うと/usersというAPIがあった時に、usecaseファイルやrepositoryファイルなどへのコードの分割を全く行わずに、認証やデータベースアクセスなどのロジックを全て単一ファイルに書いていくイメージです。
まさに生まれて初めて開発を始めたときの原初の姿に回帰しています。
一般的な企業での開発だとこういったやり方はかなり忌避されるものだと思います。
しかし、個人開発の時には自分としては、これがかなり具合がいいです。
こうすることで、ちょっとした修正を生成AIに行わせたい時に単一のAPIファイルのみ見せれば大体解決します。
ただし、この方法も問題はあります。
いろいろなファイルであまりにもコードが重複していると、その部分の修正が入った時に全ファイルを修正しなければいけない、などの問題ですね。
ただ、将来的に大規模なコード修正が発生してしまうとしても、どうせ作業するのは私ではなく基本的にAIなので、個人的にそんなに辛い感じはしていません。
プログラミング言語について
Webサービスを作るのであれば、フロントエンドの言語はTypeScriptを使うケースがほとんどだと思います。
一方で、企業レベルの開発であればバックエンドの言語にはたくさんの選択肢がありますよね。
Ruby, Go, Node.js, Python, Kotlinなど様々な言語があります。
しかし、個人開発であれば使いうる言語というのはある程度絞られてくるのかな、と思っています。
というのも、インフラコストとの兼ね合いでコンテナ系のサービスをバックエンドとして活用するのが少しハードルが高く、どちらかというとサーバーレス系のサービスを使うことになると思います。
AWSでいえば、企業開発ではECSを使うのが快適だったけど、個人開発では費用的な問題でLambdaをAPIサーバーに使わざるを得ない、といった状況をイメージするといいかもしれません。
特に個人開発ではホスティングにVercelを使うケースが結構多いですが、その場合だとNext.jsのAPIルートだけでバックエンドを完結させると諸々がかなり楽になります。
そうすると必然的にバックエンドに活用できる言語がNode.jsということになります。
偏見も入っているかもしれませんが、ある程度規模拡大してくると、サーバーレス関数系のバックエンドのAPIというのは正直使いづらいところが目立ってくるケースが多いと思います。
例えば、ローカル開発のやりづらさであったりとか、コールドスタートが気になったりであるとか、ライブラリ管理が煩雑であったりとか、インフラレベルで同時起動数に制限がかけられてしまったりとか、サービスによりけりですがそういったデメリットが何かしらあるものです。
なので、正直コストを考えないのであれば、バックエンドはちゃんとしたコンテナを使いたいというのが個人的な思いではあります。
が、コストと天秤にかけるなら圧倒的にコスト的な優位性を重視したいです。
ちなみにGCPのCloud Runを使えばこの辺の問題はかなり緩和されているという話を知人から聞いたのですが、実際に自分で使った経験が少ないので、自分は今回は活用していません。
開発の流れ
次に、自分がサービスを個人開発する時の流れを書いていきます。
VibeCodingについて
自分はClaude Codeなどを使ったvibe codingは基本的にやっていません。
というのも、何回か試そうとしたところ、上手くいかなかったからです。
DBなどの設計が意図と違っていたり、かつ自分もAIも間違いに気づかずある程度突っ走ってしまった結果、気づいたときには修正するのが難しくなってしまったといったことが起きたからです。
AI側がミスるというよりも、人間側が厳密に指示を出し切るのが難しいという問題もあります。
本当にプロトタイプレベルであればvibe codingをガシガシ使っていくのはいいと思います。
が、個人開発であっても、実際にリリースするサービスの基盤としてvibe codingに依存するのは現時点では少し難しいかなと感じています。
さて、今回MydayAIを作成する際に行った手順は、これから説明する通りです。
要件を定義
まずはどういう人をターゲットにどういう機能を提供したいかという要件を洗い出します。
通常の要件定義と違って形式にこだわる必要はありませんし、非機能要件なども考える必要はありません（コストの制約上、非機能要件はどうせ守れるかどうかは分からないので）。
MydayAIの場合は単純に以下のように箇条書きで書いただけです。
MydayAIの要件定義
[概要]
下記のような機能を持った行動記録Webアプリ（日記アプリ）です。
アプリ名はMydayAIです。
・色はGreenがメインカラー
・ログイン、新規登録、ログアウト、退会が可能（登録方法はメール＆パスワード、Google、GitHub）、Firebase Authを使用する想定
・パスワード変更やパスワード忘れの対応、メールアドレス変更などの機能あり
・フッターに、特商法、運営者情報、問い合わせへのリンクあり
・毎日、日記のように、0時から24時までの時間枠でそれぞれ何をしていたかを記録できる（過去の日付を指定してデータを作成したり編集も可能）。
・時間枠ごとに登録する値は、例えば毎回「食事」などを入力するのは面倒なので、別途登録できる。登録時はグラフ表示時の色も登録可能。（ただしその場で自由入力も可能。ただし、自由記述する時に「カスタム入力」→自由入力を行うのは面倒なので、常にどちらでも入力できるようにしておき、自由入力があった場合はそちらを優先する）
・登録した行動種別は確認、編集、削除ができるようにする。
・入力方法として、5時間同じことをしていた場合など、5回入力するのは面倒なので、はじめに時間枠をガバッと選択して、なんの行動をしていたかを当てはめられるようにする。
・その日ごとに、100点満点中で何点の一日だったかを入力可能。さらに、自由にその日にコメント（自由記述。表示するときはMarkdownを反映して表示可能）を記載可能。また、その日の感情をいくつかの選択肢から選択可能。（これらは入力しないことも可能）
・過去の日記データを確認、編集可能
・過去の日記データ一覧では、期間を指定しての検索が可能。そして、一覧では日毎に何をしていたかが色分けされたグラフ形式で確認可能。
・過去の行動記録はCSVでのエクスポートも可能。
・全体的な生活の目標を設定可能。
・過去の日記データを参考に、AIがレポートを作成してくれる。（目標に対してどういう行動を増やすor減らすべきか、どういう行動をとった日に満足度（点数）が高い傾向にあるか、ポジティブな感情を高めるにはどういう行動をとるべきか、あるいは逆に満足度が低かったり、ネガティブな感情になっているときはどういう傾向があるか、全体的な性格や思考の特性の分析など）
・過去のデータを参考に、AIが理想の休日プランを提案してくれる。
・過去の行動記録の総計データ（何に何時間時間を使ったか）のレポートも確認可能。レポートは週毎、月ごと、年ごとなど期間を設定可能。表と円グラフ（5%以下は「その他」で統合）の双方での確認が可能。
後の工程でUIを作りながら、自分が欲しいと思う機能をどんどん追加していったので、機能リストはそこそこ長くなっています。
UIを作成
自分はデザインスキルがゼロで、フロントエンドスキルも大してないので、UI作成は基本的にAI任せになります。
自分の場合はV0を使いました。
V0に、上記の要件を渡しつつ「こんなアプリのUIを作成して。」というプロンプトを投げると、自動的にNext.jsのコードを作成してくれます。
V0だとサービスのUI上でできたサイトを試すことができるので、そこで試しながら要件やデザインの指示などを微調整していきます。
全体的に微妙だなと思ったらV0内で別プロジェクトとして1からやり直したりもします。
なお、この時点では純粋にユーザーとしての視点だけを持ち、DBのデータ構造などはあえて一切考えないようにしています。
先にデータ構造を考えてしまうと、どうしても全体のデザインが開発者の都合に引っ張られがちになってしまい、ユーザーの利便性を損ねてしまう懸念があるためです。
ちなみに、正直に言うとMydayAIのUI/UXは結構評判が悪いです。
（この辺りのことはサービス運営編の記事にも書いているので、よければ見てみてください。）
なので、やはり可能であれば専門のUI/UXデザイナーがいるに越したことはないと思います。
（とはいえ、そもそもV0がないと完成させること自体ができなかったので非常に感謝しています）
なお、V0などのサービスでUIを作ると、本来はAPIから取得すべきデータもフロントエンドのコード内にベタ書きされていることが多いです。
この段階ではそれでOKです。
DBを設計（人手）
V0などのサービスでUIを固めきったら、自分は次にDBの論理設計に移ります。
データ構造の設計は結構気を使うところかと思います。
ただし、個人開発レベルだとそもそもユーザー数が伸びずに失敗することが圧倒的に多いので、DBのパフォーマンスなどは正直あまり気にしなくてもいいかと思います。
例えば「然るべきところにインデックスを貼っていないせいで遅い」といった事態が発生したとしましょう。
この場合、そのサービスはDBのミスで失敗しているのではなく、その現象が発生する程にユーザーを集められたという点で成功したサービスと見なしていいと思います。
DBの設計をミスすると後々厄介な修正をしなければいけないこともままありますが、一方で最初から完璧に作ることも不可能なので、ある程度の割り切りは必要だと思います。
ダミーのAPIを作成
次に、ダミーでもいいのでバックエンド（API）を作成します。
今まではフロントでダミーデータをベタ書きして表示していたものを、バックエンドから受け取って表示するように変更するということです。
データ自体はデータベースから取得した正規のものではなく、バックエンドにデータをベタ書きしてそれを渡していきます。
この作業はv0に指示すれば大体こなすことができます。
このように段階的にAPIを作成することにより、APIのインターフェースの型の確認や、APIの名称などのチェックを人間が行いやすくなります。
APIを実際のロジックに置換
ダミーのAPIができたら、次はそのロジックを実際のものに置き換えていきます。
ここではDBアクセスを行うコードが生成されることになります。
最近のAIの性能であれば、だいたい一発で指定したコードができる印象でした。
ちなみに、自分は主にOpenAIのGPT-4oモデルやGemini 1.5 Proによってコーディングを行っていました。
なお、自分のプロンプトの作成方法ですが、プロジェクトで使うテンプレートを用意して、そこに都度AIへの指示を当て込むといった方法をとっていました。
テンプレートは例えば以下のようなものです。
プロンプトテンプレート例
指示
あなたは優秀なエンジニアです。
XXXというアプリについて、ユーザーからの質問に答えてください。
ユーザーからの質問
{ ここに都度質問を書く（XXXをするAPIを作成して、など）}
プロジェクトのフォルダ構造
※treeコマンドの結果が自動的に入るようにしておく
参考：プロジェクトにおける重要なファイル
docker-compose.yml
※docker-compose.ymlの内容が自動で入るようにしておく
app/page.tsx
※app/page.tsxの内容が自動で入るようにしておく
このようなテンプレートを活用して、どんどんAIにコードを生成させました。
テストについて
さて最後に自動テストです。
個人開発においてテストを作成するかどうかは、意見が分かれるところかもしれません。
今のところ、自分もテストは書いていません。
そもそもテストを書く目的としては、
・デグレ防止
・コードのミス発見
・テストケースを通じて要件を明確化する
などが挙げられると思います。
しかし、個人開発の場合では、そもそもコードに触るのがAIと自分（この世で仕様を一番理解している人物）だけなので、チーム開発よりも相対的にテストを書く恩恵が少ないです。
もちろん、1人で開発している状況でも開発が長期化したり規模拡大した時にはテストが必要になるとは思うのですが、それはそうなった時にまた考えればいいやというスタンスでやっています。
個人開発でよくある構成
さて、ここからは具体的なサービス構成について語っていきたいと思います。
と言っても、個人開発においては多くの場合、定番の有名サービスを組み合わせてプロダクトを動かすことになります。
そのため、慣れた人にとってはあまり目新しいトピックがないかもしれません。
あらかじめご了承ください。
全体構成
まず、冒頭でも言及したMydayAIの構成についてまとめておきます。
| カテゴリ | 使用サービス |
|---|---|
| フロントエンド | Vercel (Next.js) |
| バックエンド | Next.js (API route) |
| DB | Supabase |
| 認証 | Firebase Authentication |
フロントエンドについて
フロントエンドは単純に自分が業務での使用経験などがあったことからNext.jsを使っています。
別にNuxtなどでもいいとは思いますが、昨今のトレンドとしてやはりNext.jsが主流になってきている感があるので、特にこだわりがないのであれば経験を深める意味でもNext.jsで良いのではないでしょうか。
正直、自分はフロントエンドのことを大して分かっていないので、フロントエンドのコードはあまり洗練されていません。
ただし、フロントエンドがバグっていても表示が崩れたり、最悪でもサービスが使用不能になるだけだとも言えます。
ユーザーのパスワード流出や、データが流出したり消失したりといったたことは（そもそもの設計に気をつけていれば）ほぼ起こりません。
なので、「個人開発においては洗練されたコードを書くことよりも、とにかくリリースに集中すべし」という観点から、あまり洗練度については気にする必要はないと自分に言い聞かせています。
ホスティングはデプロイや管理が楽なのでVercelを使っています。
VercelはNext.jsの開発元であり、先ほどUI作成のときにも触れたV0を開発している企業でもあります。
感謝の意を込めて使用させていただいております。
ただし、デフォルトでバックエンドが実行されるリージョンがアメリカになっているので、忘れずに日本リージョンに変更しておきましょう。
バックエンドについて
バックエンドはNext.jsのAPIルートです。
別途APIサーバーを立てる構成も全然ありだと思います。
ただ、自分の場合は管理するサービスが増えると手間なので、フロントエンドと一緒に管理したいという思いからこうしているまでです。
正直、自分はTypeScriptやNode.jsの経験が多くはないです。
が、昨今では生成AIの発達によって、経験の少ない言語での開発のハードルが劇的に下がってきていると思います。
各言語の詳細な書き方を理解することの価値は相対的に下がり、セキュリティやパフォーマンス面で問題が発生しないように設計する力の重要度が上がっているように感じます。
DBについて
データベースにはSupabaseを採用しています。
ここ数年、個人開発界隈で非常によく聞くサービスですね。
なんと本格的なRDBが無料で使えるという超優れものです。
ただし、スケーリングやバックアップなどの機能に着目すると、大手クラウドベンダーのRDB系のサービスの使い勝手の方がいいかなと個人的には思います。
また、MydayAIの構成の場合だとバックエンドがSupabaseとは別のネットワーク上（つまりvercel）に存在しているため、APIサーバーからの通信にやや遅延が発生していることが推定されます。
（緩和策として、Supabaseも日本リージョンに設定していることを確認しましょう。）
しかし、コスト面のメリットを考えれば、上記のポイントは些細なことだと判断して採用に至りました。
また、Supabaseではダッシュボードから直接SQLを発行することもできます。
クイックにKPIなどを確認したい時は、管理サイトなどを作らずにSupabaseのダッシュボードのみでやりくりするのも全然ありだと思います（ただし、SQLをミスって事故を起こさないように注意）。
認証について
ユーザー認証はGoogleのFirebase Authenticationを使用しています。
こちらも定番のサービスだと思います。
なんと1ヶ月のアクティブユーザー5万人までは無料で使えるので、相当サービスが伸びない限りはお金はかかりません。
当然、MydayAIでも一切費用が発生していません。
Firebaseに限った話ではないですが、特に個人開発においては、認証機能は自前で実装しない方がいいでしょう。
純粋に手間を省けるといったメリットの他に、やはりセキュリティリスクの軽減という大きな恩恵があります。
自前でユーザーのパスワードなどの情報をデータベースに保存してしまうと、やはり流出事故が怖いです。
いくらハッシュ化して保存したとしても、思わぬところで流出につながる可能性は排除できません。
例えば、ユーザー登録時のAPI処理の中で、ユーザーの生のパスワードを意図せずログに出してしまっていたなどのケースがありえそうです。
ユーザー登録や決済などを代替してくれる大手のサービスだと、基本的にパスワードやカード情報などの機微情報は我々のサーバーを経由せず、Firebaseなどのサーバー上に直接保存されます。
なので漏洩リスクを最小化することが可能です。
あと、Firebase認証の場合はGoogleアカウントでの認証やGitHub認証を簡単に組み込むことができるのも魅力ですね。
MydayAIの場合だと、一番多いのはメール＆パスワード認証ですが、2〜3割程度のユーザーはGoogleアカウントで認証しています。
また、ごくわずかではありますがGitHub認証も使われています。
その他
MydayAIの場合は、現状では課金導線がないため採用していませんが、一般的に個人開発サービスに課金できるようにしたい場合は、Stripeなどと連携させることが多いかなと思います。
Stripeについては以前簡単に紹介記事を書いたので、よければご覧ください。
開発のトータルコストについて
これまで説明したように、MydayAIでは削れるところは極限まで削り、基本的に実装はAIに丸投げして人間はAIの修正をするだけに留めました。
結果として、本番環境を公開するまでの開発の総時間は35時間程度で済みました。
そして、開発費用も基本的には0円です（実際には自分の人件費やOpenAIに課金している分は発生しています）。
自分の肌感覚ですが、例えばこれと同規模のサービスを
・デザイナー
・フロントエンドエンジニア
・バックエンドエンジニア
を全員業務委託で雇って作ったとすると、それぞれのメンバーの稼働量などにもよりますが、コストをかなり抑えてもトータルで3ヶ月300万円くらい発生しそうな印象です。
そう考えると、AIに開発を丸投げできるのはとてつもなく恩恵がでかいなあと、つくづく思いますね。
開発後の運用について
個人開発に限りませんが、サービスというものは作るよりも広める方が難しかったりします。
開発に全ての労力を注ぎ込んだ結果、集客時に嘘のように燃え尽きてしまうというのは、個人開発でも企業での開発でもよくあることですよね。
今回のMydayAIだと開発の労力を極限まで削り倒したので、正直、リリース時のカタルシスは従来に比べると少なかったのですが、その分集客をする気力が残っていました。
この記事も集客といえば集客なのですが、こういった活動を続けているおかげで、現時点で累計登録数は90オーバーまで増えてきました。
（とはいえ、基本的には趣味でやっており、課金導線もなく特に収益はないですが）
その他のKPIなどを見てみたい方は、下記記事もご覧ください。
個人開発をやってみて思ったことなど
最後に、このAI時代に個人開発をやってみた感想などを書ければと思います。
AIの発達は目覚ましく、エンジニアの仕事は劇的に変わってきています。
一方で、エンジニア経験が全くない状態からだと、サービスを1から作りきるのはさすがに現状まだ厳しいとも思います。
AIが生成したコードが単純に自分の指示やイメージとずれていることは日常茶飯事です。
その他、AIが学習したライブラリのバージョンとプロジェクトで採用したライブラリのバージョンがずれていることによって、間違ったコードが出力されてしまうといった事象が散見されました。
そういった時はどうしても人手で直さなければいけないことがあります。
また、メインで作業をするのはAIであるとしても、できるだけ人間がバックエンド開発の知識を持っていることが望ましいと感じました。
これはデータ流出などの事故やクラッキング被害を防ぐためです。
特に最近、Xか何かで「Supabaseを間違った方法で使ってしまったがゆえに、ユーザーのデータを流出させてしまっているサービスが多い」というポストを見ました。
FEから直接データベースアクセスを（ある程度）可能にするような設計もやろうと思えばできるとは思うのですが、その手のことを安全にやろうとすると、個人的にはむしろ開発難易度が上がってしまうと思います。
なので、基本的にはDBへのアクセスはBEからのみに限定した方がシンプルで都合がいいだろうと思います。
また、その他のセキュリティ関連で気をつけるべきことはBE開発の領域と絡んでいることが多いため、BEの実務経験があるに越したことはないだろうと思います。
今のAIは賢いので、素朴にコードを吐き出させるとセキュリティ的に問題のあるコードが出てくることは多くはないです。
ただ、何かのバグを解消しようとしているうちに煮詰まってくると、無理やりな方法で打開策を見つけようとする傾向もあります。
なので無茶しすぎないように人間が見張っておくことは重要だと思います。
大体以上が感想になります。
だいぶ長くなりましたが、ここまで読んでくれてありがとうございました。
2025年9月6日の生成AIなんでも展示会 vol.4にこのMydayAIを出展する予定なので、生成AIや個人開発に興味がある方は、ぜひ見に来てくれると嬉しいです。
（日記アプリに興味がなくても全然構いません。）
また最後に宣伝ですが、興味がある人はぜひお気軽にMydayAIを試してみてください〜
Discussion