Indie App Watch｜個人開発アプリ観測

タグ: 個人開発

  • 個人開発のLP・APIはどこに置く？サーバーの現実的な選び方

    このページは広告を含みます。

    まず見ること

    1. LP、API、ブログは同じ場所に置かなくていい。 まとめるほど管理は楽ですが、費用と保守の負担が増えることがあります。
    2. アプリ紹介LPだけなら無料の静的ホスティングで足りることが多い。 審査用・告知用のページは軽く始めるのが現実的です。
    3. お金を払う価値が出るのは、安定稼働が必要なAPIと、育てる前提のメディアから。 ここは無料枠だけで粘りすぎない方がいい場面があります。

    用途1: アプリのLPだけ置きたい

    静的なページ1枚から数ページなら、GitHub Pages、Cloudflare Pages、Vercel などが候補になります。HTML、CSS、JavaScript、画像を置くだけのページなら、サーバーを借りる前にこの選択肢を見た方が無駄が少ないです。

    • 向く: アプリ紹介ページ、利用規約、プライバシーポリシー、審査提出用ページ
    • 向かない: ログイン、決済、独自の問い合わせ処理など、サーバー側の処理が必要なもの

    フォームは外部フォームサービスで代用できることもあります。最初の1本目から複雑なサーバー構成を組むより、公開までの速さを優先した方が検証が進みます。

    用途2: API・バックエンドを置きたい

    アプリ側から呼ぶAPI、管理画面、バッチ処理が必要なら、PaaSやVPSが候補になります。

    • PaaS: Render、Railway など。デプロイが楽で、小規模検証に向きます。無料枠やトライアルは条件変更が起きやすいため、公式料金ページを確認してください。
    • VPS: ConoHa VPS など。自由度が高く、常時稼働や独自構成に向きます。ただし、OS更新、セキュリティ、バックアップも自分の責任になります。
    • 判断基準: 落ちたら困るか、月額をどこまで許容できるか、自分で保守できるか。

    まだユーザーが少ない段階なら、最初はPaaSで早く出して、収益や利用者が見えてからVPSや専用構成に移す方が自然です。

    用途3: ブログ・メディアを育てたい

    WordPressで記事を書き続けるなら、XserverやConoHa WINGのような共用レンタルサーバーが現実的です。理由は、WordPress簡単インストール、無料SSL、バックアップ、メール、管理画面がまとまっていて、記事を書く時間を守りやすいからです。

    開発者ほど「自分でサーバーを組める」ために全部を自前管理したくなります。ただ、メディア運営の本体は記事と更新です。WordPressを育てる目的なら、サーバー管理を軽くする選択はかなり強いです。

    現実的な組み合わせ

    状況 現実解
    アプリ1本目、LPだけ必要 GitHub Pages / Cloudflare Pages / Vercel などの静的ホスティング
    API付きアプリを検証 PaaSで早く出す。無料枠・試用枠の条件は公式ページで確認
    APIを安定運用したい VPSや有料PaaSを検討。保守できるかも含めて判断
    開発ブログ・観測メディアを育てたい 共用レンタルサーバー + WordPress
    全部やる LP=静的 / API=PaaSまたはVPS / ブログ=共用サーバー、と分ける

    最初に選ぶときのチェックリスト

    • 独自ドメインを使うか
    • SSLが標準で使えるか
    • 無料枠の条件変更・停止リスクを受け入れられるか
    • バックアップと復旧手順を自分で説明できるか
    • 障害時に何時間止まっても許容できるか
    • 1年後に記事・画像・DBを移せるか

    FAQ

    無料ホスティングだけで完結させるのはあり？

    LPなら十分ありです。小規模APIも無料枠で始められることがあります。ただし、無料枠は利用条件・上限・停止条件が変わるため、収益が出ている本番サービスでは依存しすぎない方が安全です。

    VPSと共用レンタルサーバーはどう違う？

    VPSは自由度が高い代わりに保守も自分で行います。共用レンタルサーバーは自由度が低い代わりに、WordPressやメールなどの運用が簡単です。APIはPaaS/VPS、ブログは共用サーバー、という分け方が分かりやすいです。

    ドメインはサーバーと同じ会社で取るべき？

    同じ会社に揃えるとDNS設定が楽です。ただし、ドメインは後から移管できます。価格はキャンペーンや更新料で変わるため、初年度だけでなく更新時の料金も見てください。

    広告: WordPressでメディアや開発ブログを育てる場合、共用レンタルサーバーは選択肢になります。

    LPだけなら無料の静的ホスティングで足りることが多く、APIならPaaSやVPSも候補です。WordPressで記事を継続して出す場合だけ、管理の手間を減らせるレンタルサーバーを比較してください。料金、キャンペーン、対象プランは変更されるため、最終確認は公式ページで行ってください。

    出典・確認先

  • 個人開発のアプリ収益、いくらから確定申告が必要か

    このページは広告を含みます。

    まず見ること

    1. 会社員の副業なら、判定ラインは「収入」ではなく「所得（収入 – 経費）」が年20万円。 アプリの売上そのものではなく、経費を引いた残りで見ます。
    2. 20万円以下でも住民税の申告が必要になる場合があります。 所得税と住民税は別制度です。
    3. 専業や大きく伸びた収益は、早めに税務署か税理士へ。 この記事は入口の整理であり、個別判断はできません。

    アプリ収益は「何所得」になるのか

    App Store の売上、広告収益、サブスク収益は、副業として継続的に行っている場合、多くのケースで雑所得（業務に係るもの）として整理されます。国税庁のタックスアンサー No.1500 では、業務に係る雑所得を「営利を目的とした継続的な副収入」として扱い、計算式は「総収入金額 – 必要経費」とされています。

    一方で、規模・継続性・独立性が大きい場合は事業所得に近づきます。この境目はかなり個別性が高いので、「毎月まとまった売上がある」「外注・広告費・サーバー費が継続的に出ている」「開発が本業化している」場合は、早めに税務署または税理士へ確認した方が安全です。

    会社員の場合: 20万円ルール

    国税庁 No.1900「給与所得者で確定申告が必要な人」では、給与を1か所から受けている人について、給与所得・退職所得以外の所得金額の合計が年20万円を超える場合などに確定申告が必要とされています。

    個人開発に当てはめると、見るべきなのは「売上」ではなく「所得」です。

    • アプリ売上30万円 – 経費15万円 = 所得15万円: 所得税の確定申告は原則不要になり得る
    • アプリ売上30万円 – 経費5万円 = 所得25万円: 確定申告が必要になり得る

    給与が2か所以上ある人、給与収入が2,000万円を超える人、医療費控除などで確定申告を行う人は扱いが変わります。ここは必ず国税庁 No.1900 の本文を確認してください。

    20万円以下なら何もしなくていい？

    ここが一番つまずきやすいところです。20万円ルールは所得税の確定申告の話です。住民税には同じ扱いがないため、所得税の申告が不要でも、住民税の申告が必要になる場合があります。

    住民税は自治体ごとに案内が異なるため、「市区町村名 + 住民税 + 申告」で自治体の公式ページを確認してください。副業を会社に知られたくない場合の扱いも、自治体の案内に従って確認するのが安全です。

    専業・給与なしの場合

    給与所得がない場合は、会社員向けの20万円ルールではなく、所得合計と所得控除の関係で見ます。国税庁 No.1199「基礎控除」によると、基礎控除額は合計所得金額によって段階的に変わり、令和7年分・令和8年分では、合計所得金額132万円以下の場合の基礎控除額は95万円です。

    ただし、基礎控除は近年改正が入っている論点です。この記事だけで「自分は申告不要」と判断せず、国税庁の最新ページと確定申告特集を確認してください。

    個人開発で経費になり得るもの

    一般に、収益を得るために直接かかった費用は必要経費になり得ます。個人開発でよく出るものは次の通りです。

    • Apple Developer Program の年会費、Google Play の登録料
    • サーバー代、ドメイン代、SSLやメール関連費用
    • API利用料、AI開発ツール、クラウドサービス
    • 開発に直接関係する技術書、検証端末、素材購入費

    ただし、プライベート利用と混ざるものは按分が必要になることがあります。判断に迷う支出は、領収書や明細を残したうえで税務署または税理士に確認してください。

    FAQ

    無料アプリで広告収益だけでも申告は必要？

    広告収益も収入です。会社員なら、経費を引いた所得が20万円を超えるかが所得税のひとつの目安になります。住民税は別途確認してください。

    開発費の方が多くて赤字なら、税金は戻る？

    雑所得の赤字は、給与など他の所得と損益通算できません。事業所得に該当する場合は扱いが変わるため、規模が大きい場合は税務署へ確認してください。

    会計ソフトは最初から必要？

    売上が少ないうちは表計算でも管理できます。ただし、アプリ内課金、広告収益、サーバー費、AIツール費が増えてくると、明細の整理が負担になります。収益が継続してきたら、会計ソフトで連携・分類を自動化する価値が出ます。

    広告: 収益明細が増えてきたら、会計ソフトで整理する選択肢があります。

    無料の表計算で足りる段階なら、無理に導入する必要はありません。アプリ内課金、広告収益、サーバー費、AIツール費が増えてきたら、連携・分類を自動化できるサービスを公式ページで確認してください。価格、対象プラン、キャンペーンは変更されるため、最終確認は公式ページで行ってください。

    出典・確認先

    本記事は一般的な情報の整理であり、税務判断を行うものではありません。個別の判断は税務署または税理士に確認してください。

  • 個人開発アプリ公開7日前チェックリスト

    個人開発アプリ公開7日前チェックリスト

    個人開発アプリの公開は、ボタンを押す日だけで決まりません。公開前の7日間で、見つけてもらう準備、説明する準備、数字を見る準備を整えておくと、公開後に慌てにくくなります。

    この記事は、iOSアプリ、Webアプリ、AIツール、小さなSaaSに共通する公開前チェックリストです。

    この記事で使う出典レベル

    ローンチ記事では、公式仕様、本人投稿、SNS観測、噂が混ざりやすいので、次のように分けます。

    ラベル例本文での扱い
    公式/一次情報Apple Developer、Google Search Console、Product Hunt公式ガイドストア、検索、ローンチページの基本確認に使う
    本人公開作者本人のリリース投稿、DL、収益、改善記録個別事例として読む
    SNS/Web観測Xの反応、掲載サイト、コメント初期反応の気配として読む
    未確認出典不明の成功法則、数字だけのスクショ確定情報として扱わない

    この記事は、公開日のバズや売上を保証するものではありません。

    まず結論

    公開7日前にやることは、次の5つに集約できます。

    1. 何のアプリか一文で説明する
    2. ストアページやLPをスマホで確認する
    3. 公開日に出す投稿と画像を用意する
    4. 表示、クリック、登録、課金の数字を見る場所を決める
    5. 公開後に直す候補を先に3つだけ決める

    作り込みより、伝わる状態にすることが先です。

    7日前: 一文を決める

    最初に、アプリの説明を一文にします。

    “text 誰が、どんな場面で、何を楽にできるアプリか。 “

    この一文は、LP、App Store説明文、X投稿、Product Huntのタグライン、スクリーンショットの見出しに使い回します。

    弱い一文:

    • AIで便利なメモアプリです
    • 生活をよくするツールです

    強い方向:

    • 会議音声からToDoを作り、次の打ち合わせ前に見返せるメモアプリです
    • 個人開発者向けに、リリース文とSNS告知をまとめて下書きするツールです

    6日前: 商品ページを確認する

    iOSアプリならApp Storeの商品ページ、WebアプリならLPを確認します。

    見る場所:

    • アプリ名
    • サブタイトル
    • 最初のスクリーンショット
    • 説明文の冒頭
    • 価格や無料範囲
    • プライバシー、問い合わせ先
    • スマホ表示

    Appleの公式情報では、商品ページの要素は検索結果やダウンロード判断に関係する重要な場所です。個人開発でも、最初のスクリーンショットで価値が伝わるかを見ます。

    5日前: 公開投稿を3本作る

    公開日に慌てて文章を書くと、説明がぼやけます。先に3本だけ作ります。

    1. 何を作ったか
    2. なぜ作ったか
    3. どんな人に使ってほしいか

    投稿では、実績を盛らないことが大事です。まだ公開前なのに「大人気」「爆伸び」と書く必要はありません。

    使える型:

    “text 個人開発で、○○向けの△△アプリを作りました。 困っていたのは□□です。 まずは□□だけを短くする小さなツールとして公開します。 “

    4日前: 数字を見る場所を決める

    公開後に見る数字を先に決めます。

    数字何を見るか使う場所
    表示投稿やページが見られたかX、ストア、Search Console
    クリック次のページへ進んだかLP、短縮URL、分析ツール
    インストール/登録使い始めたかApp Store Connect、DB、フォーム
    初回成果最初の価値に到達したかアプリ内イベント、手元メモ
    課金支払われたかストア課金、決済ツール
    継続もう一度戻ったかアプリ内ログ、分析

    公開初日は売上だけを見ない方がいいです。どこで詰まっているかを見るための数字を残します。

    3日前: 問い合わせと信頼を整える

    小さなアプリでも、最低限の受け皿があると安心されます。

    • 問い合わせ先
    • プライバシーポリシー
    • 利用規約が必要な場合の案内
    • 返金や解約の導線
    • データ削除の説明
    • 不具合報告の方法

    AIアプリや課金アプリでは、データの扱いと料金の説明を曖昧にしないことが大事です。

    2日前: 公開後に直す候補を決める

    公開後は、反応がなくても、反応があっても焦ります。先に直す候補を3つだけ決めておきます。

    • スクリーンショット1枚目
    • 説明文の冒頭
    • オンボーディング
    • 価格表示
    • FAQ
    • X固定投稿
    • 使い方記事

    全部を同時に変えると、何が効いたか分からなくなります。

    1日前: 動作と導線を確認する

    最後は派手な改善より、基本確認です。

    1. 新規ユーザーとして登録できるか
    2. 主要機能がスマホで動くか
    3. 課金やフォームのテストが済んでいるか
    4. エラー時の表示があるか
    5. LPからアプリへのリンクが動くか
    6. SNS投稿のURLが正しいか
    7. 問い合わせ先が機能しているか

    不安なら、新機能を足すより不具合を減らします。

    公開当日: やることを絞る

    公開当日は、次の3つだけを確実にやります。

    1. 公開ページが外から開けるか確認する
    2. 用意した投稿を出す
    3. 表示、クリック、登録を記録する

    反応が少なくても、同じ投稿を連投しない方が安全です。まずは存在、配信、反応を分けて見ます。

    必要なら検討する道具

    公開準備では、有料サービスより先に無料で確認できることがあります。必要なものだけを選べるように、無料でできることと有料で検討するものを分けます。

    課題無料でできること有料で検討するもの注意点
    LPがない1枚ページを作るドメイン、サーバー、LPテンプレ公開日までに凝りすぎない
    画像が弱いスクショを撮り直すデザインツール、スクショ制作支援実際の画面と違う見せ方をしない
    実装が不安チェックリストで確認AIコード支援、レビュー支援テストなしで任せきりにしない
    数字を見たい手元の表に記録分析ツール、課金管理最初は見る数字を絞る
    学びたい公式情報と保存版記事を読む書籍、教材、メンター公開直前に学習だけ増やさない

    公開前チェックリスト

    1. アプリを一文で説明できる
    2. スマホで商品ページやLPを確認した
    3. 1枚目のスクリーンショットで価値が伝わる
    4. 公開投稿を3本用意した
    5. 問い合わせ先がある
    6. 料金や無料範囲が分かる
    7. プライバシーやデータ削除の説明がある
    8. 表示、クリック、登録、課金を見る場所が決まっている
    9. 公開後に直す候補を3つだけ決めた
    10. 出典や収益数字を盛っていない

    次に読む

    CTA

    公開まで7日あるなら、今日は新機能を足す前に「一文説明」「1枚目のスクリーンショット」「公開投稿1本」を整えてください。公開後に見られるかどうかは、伝わる準備でかなり変わります。

    FAQ

    7日前に新機能を足してもいいですか？

    致命的な不足でなければ、公開直前は新機能より説明、スクリーンショット、導線確認を優先した方が安全です。

    公開当日に見る数字は何ですか？

    売上だけでなく、表示、クリック、登録、初回成果を分けて見ます。どこで止まったかを知るためです。

    反応が少ないときはすぐ連投すべきですか？

    同じ内容の連投は避けます。まず公開ページが開けるか、投稿が表示されているか、説明が伝わるかを確認します。

    参照した公式/公開情報

    • Apple Creating Your Product Page: https://developer.apple.com/app-store/product-page/
    • Apple App Store Search: https://developer.apple.com/app-store/search/
    • Apple Product Page Optimization: https://developer.apple.com/app-store/product-page-optimization/
    • Google Search Console: https://search.google.com/search-console/about
    • Product Hunt Launch Guide: https://www.producthunt.com/launch

    更新履歴

    日付内容
    2026-06-27初版下書き作成。

  • 作る前に個人開発アプリの需要を検証する方法

    作る前に個人開発アプリの需要を検証する方法

    個人開発で一番もったいないのは、数週間かけて作った後に「誰に向けたものか分からない」と気づくことです。

    需要検証とは、作る前に「本当に困っている人がいるか」「その人はどんな言葉で探すか」「お金を払う理由があるか」を小さく確かめることです。

    完璧な市場調査ではありません。作る前の失敗確率を少し下げるための作業です。

    この記事で使う出典レベル

    需要検証では、公式情報、本人投稿、SNS観測、噂を混ぜないことが大事です。

    ラベル例本文での扱い
    公式/一次情報App Store、Product Hunt公式ガイド、Google Search Central掲載場所や検索の基本を確認する
    本人公開作者本人の開発記録、リリース投稿、収益報告個別事例として読む。数字は確認日を残す
    SNS/Web観測Xの困りごと、レビュー、コメント、ランキング需要の気配として扱う
    未確認出典不明の成功談、数字だけのスクショ確定情報として扱わない

    この記事では、特定ジャンルの収益を保証しません。

    まず結論

    作る前に最低限やることは5つです。

    1. 誰の課題かを一文で書く
    2. その人が検索しそうな言葉を10個出す
    3. 競合や代替手段を10件見る
    4. 1枚の説明ページか投稿で反応を見る
    5. 支払い理由と継続理由を分けて考える

    コードを書く前にここまでやると、作る範囲を絞りやすくなります。

    初心者向け: 需要とは何か

    需要は「いいねが多い」だけではありません。

    反応読み方注意点
    いいね面白い、共感した可能性使うとは限らない
    返信具体的な困りごとが出やすい友人票も混ざる
    検索語すでに探している人がいる競合も多い可能性
    レビュー既存アプリへの不満が見えるそのまま批判に使わない
    事前登録使う意思が少し強い本当に使うかは別
    課金支払い理由がある継続するかは別

    需要検証では、弱い反応と強い反応を分けます。

    需要検証の手順

    1. ユーザーを狭くする

    「全員向け」は、最初の個人開発では広すぎます。

    次の形で一文にします。

    “text 誰が、どんな場面で、何を短くしたいか。 “

    例:

    • 個人開発者が、公開前日に、リリース文とSNS投稿をまとめて作りたい
    • 学生が、授業後に、写真とメモを試験前に見返せる形へ整理したい
    • フリーランスが、見積もり前に、過去案件の条件をすぐ確認したい

    2. 代替手段を見る

    競合アプリがあることは、必ずしも悪いことではありません。すでに困っている人がいるサインでもあります。

    見る場所:

    • App StoreやGoogle Play
    • Google検索
    • Product Hunt
    • X検索
    • 個人開発ディレクトリ
    • Redditやフォーラム
    • 既存のスプレッドシート、Notion、手作業

    アプリだけでなく、今ユーザーが何で代用しているかを見ます。

    3. 検索語を集める

    検索語は、ユーザーの言葉です。

    「AIメモ」では広すぎるなら、「会議 メモ 自動 ToDo」「レシート 写真 家計簿 面倒」のように場面で分けます。

    Google Search CentralのSEOスターターガイドでも、検索エンジンだけでなくユーザーが内容を理解しやすいことが重要です。需要検証でも、検索語を拾うだけでなく、検索者が次に何を判断したいかを考えます。

    4. 1枚ページか投稿で反応を見る

    いきなりアプリを作る前に、説明だけ出します。

    • 1枚のLP
    • X投稿
    • Product Huntの準備ページ
    • 画像1枚のモック
    • Googleフォーム
    • メール登録フォーム

    ここで見るのは、バズではなく具体的な反応です。

    • 「いつ使いたい」と言われたか
    • 「この機能がほしい」と言われたか
    • 価格の話が出たか
    • 代替手段を教えてもらえたか
    • 反応した人が対象ユーザーか

    5. 支払い理由を考える

    無料で使う理由と、お金を払う理由は違います。

    支払い理由向いている収益化
    毎週使うサブスク
    失敗を避けたい買い切り、サブスク、B2B
    時間を短縮するサブスク、従量課金
    比較や購入を助けるアフィリエイト
    多くの無料ユーザーが集まる広告

    「便利そう」だけでは弱いので、払わないと困る場面があるかを見ます。

    作る前チェックリスト

    1. 対象ユーザーを一文で言えるか
    2. その人の検索語を10個書いたか
    3. 競合または代替手段を10件見たか
    4. 既存レビューの不満を5件メモしたか
    5. 1枚ページか投稿で説明したか
    6. 具体的な返信や質問が来たか
    7. 無料で使う理由と支払い理由を分けたか
    8. AIで短くなる作業と人が確認すべき作業を分けたか
    9. 公式/本人公開/SNS観測/未確認を分けてメモしたか

    小さく作る範囲

    需要が少し見えたら、最初のMVPを決めます。

    MVPは Minimum Viable Product の略で、最小限の検証用プロダクトです。全部入りの完成版ではありません。

    欲張りな範囲最初の範囲
    全SNS対応X投稿文だけ
    全ファイル対応PDFだけ
    全言語対応日本語だけ
    完全自動下書き生成と人間の確認
    決済まで全部メール登録と価格アンケート

    最初は「使えるけど狭い」が理想です。

    必要なら検討する道具

    需要検証は無料でもできますが、時間を買える道具もあります。

    課題無料でできること有料で検討するもの注意点
    LPを作りたい1枚HTML、Notion、フォームドメイン、ホスティング、LPテンプレ見た目より説明の明確さを優先
    画面を見せたい紙、スクショ、簡単なモックFigmaなどのデザインツール完成品のように誤解させない
    試作したい公式ドキュメント、小さなコードAIコード支援、開発教材検証前に作り込みすぎない
    反応を測りたい手元の表で記録分析ツール、メール配信小さい母数を読みすぎない
    収益化を学びたい既存の保存版記事を読む書籍、講座、メンター題材が決まってから買う

    次に読む

    CTA

    今日やるなら、アプリ名を考える前に「誰が、どんな場面で、何を短くしたいか」を1行で書いてください。その1行が曖昧なら、まだコードを書く前に直せます。

    FAQ

    作る前にどこまで調べるべきですか？

    完璧な市場調査までは不要です。ただし、誰が困っているか、既存の代替手段、検索やSNSの言葉は先に確認します。

    競合があるなら作らない方がいいですか？

    競合があることは需要のサインでもあります。勝ち筋は、対象ユーザー、用途、価格、配布導線をどこまで絞れるかで変わります。

    検証で一番危ないことは何ですか？

    自分の欲しい結論だけを集めることです。使わない理由、払わない理由、既存手段で十分な理由も見ます。

    参照した公式/公開情報

    • Apple App Store Search: https://developer.apple.com/app-store/search/
    • Apple Creating Your Product Page: https://developer.apple.com/app-store/product-page/
    • Product Hunt Launch Guide: https://www.producthunt.com/launch
    • Google SEO Starter Guide: https://developers.google.com/search/docs/fundamentals/seo-starter-guide
    • Google Search Console: https://search.google.com/search-console/about

    更新履歴

    日付内容
    2026-06-27初版下書き作成。