AIでコードを書く速度が上がったことで、個人開発で自立できるのではないかと考えるエンジニアが増えています。会社や案件への依存に不安を抱えながら、空き時間でアプリやSaaSを作って収益化したい、という相談もよく耳にします。一方で、実際に手を動かしてみると、技術的に作ること自体は前より近づいているのに、それを売って毎月の生活費に変えるところまでは別の壁がいくつも残っていることに気づきます。
この記事では、最初に「作れる」と「売れる」を分けて見るための土台を整えた上で、iPhone・Android・Web/SaaS・ブラウザ拡張・CLI・業務自動化といった配布経路を、集客・継続・課金・運用の観点で並べていきます。AI時代の個人開発を「アプリやSaaSを作って売り切る」という形に閉じ込めず、現場の作業を整理して外に出す道までを地続きで扱います。
対象読者は、AI時代に会社依存の働き方へ不安を感じているSESエンジニア、個人開発で収益化したいが何を作ればよいかわからない現場エンジニア、アプリやSaaSを作れば自立できるのではと考えているエンジニア、そして自分の技術を仕事に変える入口を探しているエンジニアです。煽らず、断定せず、判断軸を渡す姿勢で書きます。
本記事を読み終えたとき、何を作るかを決める前に、自分が向き合うべき問いの順番（誰の、どの作業を、どう軽くするか）と、配布経路ごとの売れる難所のかたち、そして個人で立つときの選択肢として「作って売る」だけでなく「整理して渡す」道があることが、ひとつの地図として見えるようにしたいと考えています。
「作れる」と「売れる」は別問題である
AIで個人エンジニアが手を出せる作りものの範囲は確かに広がっています。一方で、それを誰かに届けて課金してもらう構造はほとんど変わっていません。本セクションでは、ふたつをまず分けて見るための土台を整えます。
AIで「作れる」範囲は広がっている
コードの叩き台、API連携、画面のスタイル整え、一通りの動作確認までAIに任せられる時間は、数年前と比べて明確に減っています。「作れる」側の壁は実際に下がってきています。
具体的には、画面遷移のあるアプリ、外部APIを叩くWebサービス、ちょっとしたブラウザ拡張、CLIツール、社内向けの自動化スクリプトといったものは、ひとりで設計から動作確認まで通せる距離に入ってきました。土日に手を動かして、月内に動くものをひとつ仕上げる、というサイクルは現実的な選択肢になっています。
ただし「作れる」が広がったことと、自立できる収益が立つことは、まだつながっていません。動くものができたという達成感の手前で、本当に問わなければいけないのは「これを誰が、なぜ使い続けるのか」という別軸の問いです。
配布経路があることと売れることは別問題
ストアに並べることと、ストアで誰かに見つけてもらうことは、まったく別の問題です。ストア審査を通った後で、集客と継続利用と課金設計の壁が並んで立っています。
配布経路（App Store、Google Play、Webドメイン、Chrome Web Store、npm、SaaSのサインアップページなど）が整っているということは、「届ける手段」があるという意味にとどまります。誰かに見つけてもらうための集客、起動・再訪を続けてもらうための継続利用、対価を取り続けるための課金設計は、配布経路の外側で別個に組み立てる必要があります。
特に個人開発で見落としやすいのは、ストアに並べた瞬間にダウンロードが伸びることはまずない、という事実です。ストア掲載は出発点であり、見つけてもらう仕組みを別に作らなければ、棚に並んでいるだけで誰にも触られないままになります。
「作りたい」と「困っている人がいる」は重ならないことが多い
自分が作りたいテーマと、お金を払ってでも解決したい人がいるテーマは、重なるほうが珍しいというのが実情です。重ならないテーマで作り始めると、後段の集客と課金で消耗する確率が上がります。
「作りたい」起点のプロダクトは、自分のモチベーションが続きやすい一方で、誰の困りごとに重なっているのかが弱くなりがちです。逆に「困っている人がいる」起点だと、関心がない領域に踏み込む必要が出てきて、手が止まりやすくなります。
このズレは、個人開発で挫折する典型的なパターンに直結します。重ならないまま走り出した後で、集客の弱さや継続率の低さに気づき、課金設計を作り込む手前でモチベーションが切れる、という流れです。手を動かす前に、ここがどれくらい重なっているかを一度考えておくだけでも、後段で失う時間は変わってきます。
配布経路ごとに「作れる」と「売れる」を並べる
iPhoneアプリ、Androidアプリ、Webアプリ、SaaS、ブラウザ拡張、CLI、業務自動化を、作れる距離と売れる難所の観点で並べていきます。各経路の強みと、見落とされやすい難所を一段ずつ分けて見ていきます。
ここでは固定費や手数料の最新数値には踏み込まず、構造としての難所だけを扱います。各経路の規約・手数料は時期によって変わるため、判断する際は実際に着手するタイミングで一次情報を確認することを前提にしてください。
配布経路ごとに見ると、「作れるもの」と「売れるもの」の差はかなり大きくなります。
下記の表では、個人開発で候補に上がりやすいものを、作りやすさ、売るときの重さ、個人開発で抱えるリスク、自立の収益基盤としての見方に分けて整理します。
| 種類 | 作りやすさ | 集客のしやすさ | 継続利用の作りやすさ | 課金のしやすさ | 運用の軽さ | 依存リスクの低さ | 受注仕事への近さ |
|---|---|---|---|---|---|---|---|
| iPhoneアプリ・Androidアプリ | ★★★★☆ | ★★☆☆☆ | ★★☆☆☆ | ★★☆☆☆ | ★★☆☆☆ | ★☆☆☆☆ | ★★☆☆☆ |
| Webアプリ・SaaS | ★★★★☆ | ★★☆☆☆ | ★★★☆☆ | ★★★☆☆ | ★☆☆☆☆ | ★★★☆☆ | ★★★☆☆ |
| ブラウザ拡張・CLI | ★★★★★ | ★★☆☆☆ | ★★☆☆☆ | ★☆☆☆☆ | ★★★★☆ | ★★★☆☆ | ★★☆☆☆ |
| 業務自動化 | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★★ |
星の数は、個人エンジニアが自立に向けて取り組む場合の扱いやすさを示しています。星が多いほど有利で、星が少ないほど個人で抱える負荷や依存リスクが大きいという見方です。
この表で見ると、アプリやSaaSは「作れるもの」としては魅力があります。一方で、集客、継続利用、課金、運用、プラットフォーム依存まで含めると、個人の収益基盤としては重くなります。
業務自動化は派手さはありませんが、困っている業務に直接重なりやすく、仕様整理や業務整理と組み合わせることで受注仕事に近づけやすい領域です。
iPhoneアプリ・Androidアプリ — 集客と継続利用だけでなく、ストア依存が重い
ストア配布の経路は整っており、技術的に「作れる」までの距離は近くなっています。AIを使えば、画面、入力フォーム、簡単な保存処理、通知機能などは以前より短い時間で形にできます。
問題は、作ったあとです。
iPhoneアプリもAndroidアプリも、最終的な配布経路はAppleやGoogleのストアに強く依存します。審査に通らなければ公開できず、公開後も規約変更、審査基準の変更、ストア側の判断によって、アップデート停止、機能変更、掲載停止の影響を受ける可能性があります。
これは個人開発者にとってかなり重い構造です。
自分でコードを書き、自分で機能を作り、自分でユーザーを集めても、最後の配布口を自分で握っているわけではありません。アプリが生活費や事業収益の中心になっている場合、ストア側の判断ひとつで収益導線が大きく崩れる可能性があります。
さらに、集客の面でも簡単ではありません。
ストア内検索、レビュー、ランキング、外部メディア、SNS、広告などを組み合わせなければ、アプリは存在していても見つけてもらえません。ストアに公開しただけで自然にダウンロードされるわけではなく、初期ユーザーを集めるための導線を別に作る必要があります。
継続利用と課金設計も別の難所です。
インストールしてもらっても、使い続けてもらえなければ収益にはつながりません。通知、習慣化、アップデート、サポート、レビュー対応まで含めて運用が発生します。加えて、アプリ内課金やサブスクはストア側の手数料や決済ルールに縛られます。
つまり、iPhoneアプリやAndroidアプリは「作れるもの」としては魅力がありますが、「個人が自立するための収益基盤」として見ると、かなり不安定です。
技術的に作れることよりも、審査、配布、集客、継続、課金、規約変更への対応まで引き受けられるかが重要になります。
Webアプリ・SaaS — 顧客獲得と運用責任の重さ
Webは配布のためにストアの承認をもらう必要がありません。代わりに、顧客を自分で集める前提と、サーバーを止めない運用責任が一気に乗ってきます。
Webアプリ・SaaSは、ストア審査やレビュー対応が不要な分、自分でドメインを取り、ランディングページを整え、検索流入や広告から顧客を呼び込む工程をすべて自前で回すことになります。ここはエンジニアリングというよりマーケティングと営業の領域で、個人開発者がもっとも消耗しやすい場所です。
加えて、SaaSは継続課金が前提のためサーバーを止められません。深夜の障害対応、バックアップ、セキュリティパッチ当て、決済の失敗対応まで、運用責任が広く長く続きます。AIで初期実装を速くできても、運用の負荷は技術ではなく組織的な仕組みでカバーする領域に入ってくるため、個人で抱え込みすぎないことを最初に決めておく必要があります。
ブラウザ拡張・CLI — 小さく作れるが用途が立たないと売れない
ブラウザ拡張もCLIも、最小単位で作って配布できる範囲が広いです。一方、用途が「誰の何の作業を、どう短くするか」まで言語化できない場合、収益化は急に難しくなります。
ブラウザ拡張やCLIは、配布形態として軽く、ひとりで完結しやすい点が強みです。Chrome Web Storeやnpmといった経路を使い、小さく出して反応を見ることもできます。
ただし、これらの経路はそもそも有料で売る土壌が他のプラットフォームより薄く、寄付モデルや有料アップグレードのフックが立ちにくい構造です。「誰の何の作業を、どう短くするか」を一文で言えないテーマだと、配布した後に有償化の足場を作る段階でつまずきます。小さく作れる強みを活かすには、用途の言語化を先に終わらせることが前提になります。
業務自動化 — 派手さはないが困っている業務に直結する
業務自動化はSaaSのような派手さはありません。代わりに、現場で誰かが困っている業務に直接重なるため、対価を受け取りやすい場所として残っています。
業務自動化は、特定の現場の手順、特定の社内ツール、特定の社内ルールに合わせる必要がある分、AIだけで完結させにくい領域です。それは弱点ではなく、個人エンジニアにとっては「AIに置き換えられにくい仕事の形」として機能します。
派手なローンチや大量のユーザー獲得とは縁遠い世界ですが、現場の困りごとに直接重なるため、相談から受注、運用、改修までが一本でつながりやすい構造があります。アプリやSaaSのように不特定多数を相手にしない代わりに、特定の数社・数十社との継続的な関係から食い扶持を組み立てる選択肢として残ります。
AI時代に必要なのは整理する力
コードを書く速度は、AIが押し上げてくれる側の能力です。個人で立てるかどうかの分岐に残るのは、課題を切り分け、仕様をまとめ、業務を分解する整理側の力になります。
ここで言う整理する力は、ひとつの技能ではなく三つに分けて考えると扱いやすくなります。それぞれ独立した訓練対象として、ひとつずつ扱っていきます。
課題を切り分ける力
「困っている」を聞いた時点で、原因と症状と要望を分ける作業が必要になります。ここで分けないままAIに投げると、要望のまま動くものができて原因を取り逃すことが多くなります。
たとえば「Excelの集計が大変」という相談を受けたとき、症状は集計の手間ですが、原因は入力フォーマットの不統一かもしれず、要望は「ボタンひとつで集計したい」かもしれません。三つを混ぜたままAIに渡すと、要望どおり動くものが出てきても原因は残ったままになります。
切り分ける力は、相手の話を一度受け止めた上で、原因・症状・要望のどこに分類されるかを問い直す習慣として育てるものです。AIで実装が速くなった分、ここを省くことの代償が大きく見えるようになっています。
仕様を整理する力
仕様は、誰のために何をどこまでやるかを、合意できる形に直す作業です。AIでコードが速く出るほど、仕様の曖昧さが直接コストに跳ね返るようになります。
仕様は「やりたいこと」をリスト化することではなく、「やらないこと」を含めて合意することです。範囲を決め、例外を決め、運用上のフォールバックを決める。ここまで含めて初めて、AIに渡せる単位になります。
AIに任せられる実装範囲が広がったことで、仕様の曖昧さが残ったまま走った結果、「動くものはできたが現場で使えない」という状態に着地するリスクは前より高まりました。仕様の整理は、コードを書く前の準備ではなく、設計と実装と並ぶ第三の作業として位置づけ直す価値があります。
業務を分解する力
業務は、人の手順の連なりで動いています。それを「誰がいつ何をするか」「どの作業はAIに渡せて、どの判断は人に残すか」に分けることで、自動化が初めて成立します。
業務分解では、ひとつの仕事を「入力」「判断」「出力」「記録」の単位に割っていきます。判断は人に残し、入力・出力・記録のうち定型化できる部分をAIや自動化に渡す、という線の引き方が起点になります。
ここで線を引かずにまるごと自動化しようとすると、判断の境目で破綻します。逆に、判断の中身に踏み込んだ整理ができれば、AIに渡せる範囲が見えてきて、人が残す判断の価値も明確になります。整理する力の中で、業務の現場にもっとも近いのがこの分解の力です。
プロダクトを作る前に「誰のどの作業を軽くするか」を決める
整理する力の三つを並べた後で、それを「プロダクトを作る前」に向けて使うとどうなるかを具体化します。コードを書き始める前に止まれる場所が、ここにあります。
ここでは、コードを書き始める前に確認したい三つの問いを順番に扱います。三つすべてに答えが出ない場合は、手を動かす前にいったん止まって考え直すことを勧めたい段階だ、という線引きを共有するためのセクションです。
「誰の」を曖昧にしないための問いの立て方
「中小企業の」「経理の」「フリーランスエンジニアの」のように属性を一段ずつ絞っていきます。属性が曖昧なまま作ると、刺さらない機能をたくさん作ることになります。
「誰の」が曖昧な状態は、機能の優先順位が決められない状態と同じです。同じ「経理担当」でも、月末の請求書発行で困っている人と、年次決算の集計で困っている人では、必要な機能はまったく別物になります。
属性を一段ずつ絞るというのは、業種・職種・規模・季節性・使っているツールまで掘っていく作業です。粒度を上げるほど刺さるユーザー像は狭くなりますが、その狭さがプロダクトの判断軸を支える側に回ります。広く曖昧なまま走り出すよりも、狭く具体的に決めて始めるほうが、後段の修正コストは小さくなります。
「どの作業」を観察する側に回る
「困っている」を直接聞くだけでは、相手の作業の形までは見えません。実際の手順を一度目の前で見せてもらうか、自分で動いて再現する側に回る必要があります。
困っている本人ですら、自分が何にどれだけ時間を使っているかを正確には言葉にできないことがよくあります。だからこそ、ヒアリングだけでなく、隣で作業を見せてもらう、あるいは自分で同じ手順を一度なぞってみる、という観察側の動きが効きます。
観察に回ると、ヒアリングでは出てこなかった手順の重複、ツールの切り替え、書類の往復が見えてきます。「困っている」の輪郭が、実際の所要時間と頻度を伴った形で見えるようになり、ここで初めて自動化の対象として扱える単位に落ちます。
ここで決められないものは作っても売れない
「誰の」と「どの作業」を決められないテーマは、後段でいくらコードを書いても売れる形になりません。手を動かす前に止まれることが、整理する力の一番大きな利点です。
整理する力の最大の利点は、コードを書く前に「これは作っても売れる形にならない」と判断できるところにあります。AIで作る速度が速くなったぶん、走り出してからの軌道修正コストはむしろ上がっているとも言えます。
「誰の」と「どの作業」のどちらかが曖昧なまま走り出した結果、動くものはできたが運用に乗らないという結末に至るより、手前で立ち止まって聞き直す・見直すほうが、トータルの時間は短くなります。整理する側に時間を投資するのは、AI時代の個人開発でこそ効くやり方です。
業務自動化・仕様整理として外に出す道
プロダクトを作って売り切る形だけが、個人で立てる選択肢ではありません。業務自動化や仕様整理という、現場の作業を整える側の仕事として外へ出す道を整理します。
ここは「アプリやSaaSが終わりだ」と言いたいセクションではありません。個人で立てる選択肢として、プロダクト販売型の隣に「整理して渡す」型の道があり、その道のほうが現場の困りごとに直結しやすい場合がある、という構造を共有するセクションです。
図 3: 「作って売る」から「整理して渡す」への重心移動 — 個人開発を完成品の販売に閉じず、業務自動化・仕様整理として現場の作業を整える側へ重心を移していく流れ
個人で受注につなげやすい仕事の形
業務自動化や仕様整理は、顧客固有の手順や事情を含むためAIで完結しません。だからこそ個人が対価を受け取りやすい場所として残っています。
業務自動化や仕様整理が「AIで完結しない」のは、現場のローカルルール、社内ツールの組み合わせ、過去の運用経緯といった文脈に強く依存するためです。これらは標準化された機能の組み合わせでは解けず、個別の対話と観察が前提になります。
そして、対話と観察が要る仕事は、誰かと長く関わる仕事になります。一回売って終わるプロダクト販売とは違い、相談から始まり、整理を進め、運用に乗せ、改修を続けるという流れになります。個人エンジニアが少数の顧客と継続的に関わって食い扶持を組み立てる形に向いており、AI時代でも残っていく職能の形のひとつです。
自前ドメインに記事資産を積みながら相談を受ける形
ストア課金や代理店経由ではなく、自前のドメインに記事を積んで相談入口を持つ形が現実解になりやすいです。即効性ではなく、信頼形成と継続取引が支えになります。
自前ドメインで記事を積む形は、すぐに売上が立つやり方ではありません。書いてから検索からの流入が安定するまでに時間がかかり、相談メールが入り始めるまでにもうワンテンポあります。
代わりに、一度回り始めると、プラットフォームの規約変更や手数料改定の影響を受けにくい場所で、信頼の積み上げが直接相談の受け口に変わっていきます。短期の売上ではなく、中長期の継続取引で食う形を選ぶなら、記事資産と相談入口の組み合わせは現実的な土台になります。
「作って売る」ではなく「整理して渡す」へ重心を移す
「自分の作品を売る」発想から、「困っている人の業務を整理して渡す」発想へ重心を移していきます。完成品を売るのではなく、整理した結果と運用設計を納品する形に近づきます。
「作って売る」発想は、自分の手元で作品を仕上げてから市場に出すモデルです。「整理して渡す」発想は、相手の業務を観察して整理し、整理した結果と運用設計を渡すモデルになります。手を動かす対象は同じくコードや自動化フローですが、起点が「自分の作りたいもの」ではなく「相手の困っている作業」に置かれる点が違います。
この重心の移し方は、個人開発の経験を捨てる話ではありません。プロダクトを作った経験は、業務を観察して構造化する作業に直接活きます。違うのは、その力をどこに向けて使うか、というベクトルだけです。AI時代に個人で立つ選択肢として、「整理して渡す」側へ重心を移していく道は、現実的に組み立てやすい一本になります。
まとめ
AI時代に個人開発で自立を目指すとき、まず「作れる」と「売れる」を分けて見ること、そして「誰のどの作業を軽くするか」を決めてから手を動かすことをおすすめします。アプリやSaaSの前に、業務自動化・仕様整理として外へ出す道は、現場で困っている作業に直結しています。
「作れる」が広がった時代だからこそ、「売れる」を成立させる側の整理する力（課題の切り分け、仕様の整理、業務の分解）が、個人エンジニアの差として残ります。コードを書く前に立ち止まれる力を持っておくことが、AI時代に時間を無駄にしないための一番大きな防御になります。
「作って売る」一本に絞らず、「整理して渡す」道を選択肢に入れておくと、配布プラットフォームや手数料の変動に振り回されにくい立ち位置をつくれます。本記事を、自分の現在地を確かめる地図として使っていただければと思います。
