【個人開発】広告収入が運用費を上回るWebアプリの技術選定

投稿日: 2026年6月30日
対象読者: 個人で収益化Webアプリを作りたい開発者

この記事はこんな方向け:

  • 個人開発のアプリで、サーバー代に毎月お金が消えていくのが怖い方
  • 静的サイトか動的サイトか、構成の入口で迷っている方
  • ユーザーの写真など、扱いに気をつかうデータを安全に処理したい方

TL;DR

  • 個人開発で大事なのは「速い技術」より赤字にならない技術。広告収入が運用費を上回る設計から逆算した
  • 評価軸は3つだけ——固定費が出ない／手がかからない／収益が運用費を構造的に上回る
  • バックエンドを持たない静的サイトにしたのは、Unityとの相性と保守の軽さのため。建てないサーバーは落ちないし、お金もかからない
  • ホスティングは候補を並べて比較してFirebase。無料枠が大きく、想定トラフィックでは課金ラインに当たらない
  • AdSenseは独自ドメインが実質必須。github.io などの共有サブドメインでは審査に出せないので、お名前.comでドメインを取得した
  • Unityビルドは重いが、一度ダウンロードされればキャッシュに乗る。2回目以降は転送量がほぼゼロで、表示回数＝広告収入だけが積み上がる
  • 写真はサーバーに送らずブラウザ内だけで処理する。流出しようがない構造にすることが、最大のセキュリティ対策になった

はじめに

個人開発でいちばん怖いのは、バグでもレビューでもなく「誰も使っていないのに毎月サーバー代の請求だけ来る」状態だと思っています。逆にアクセスが伸びたら伸びたで、今度は青ざめる。バズった瞬間に従量課金が跳ねて、嬉しいはずの通知が請求の通知に見えてくる——個人開発あるあるだと思います。趣味で作ったものが、いつのまにか財布を削るサブスクになっている。

Pose Mirror は「写真1枚からポーズを3D化する」無料Webアプリです。完全無料・ログイン不要で公開していますが、運用費よりも広告収入のほうが上回る設計にしています。派手な技術は何も使っていません。むしろ入れない判断を積み重ねた結果です。

この記事は実装手順の記事ではなく、Pose Mirrorを作るときに「何を選び、何を選ばなかったか」という技術選定の判断を、実際に詰まった話とセットでまとめた開発メモです。これから収益化を狙うWebアプリを個人で作る方に、構成を決める前のたたき台として読んでもらえればと思います。

技術選定の評価軸：個人開発の「正解」は会社の正解と違う

技術記事を読むと、スケーラビリティ・可観測性・マイクロサービスといった言葉が並びます。どれも正しいのですが、それは何十万ユーザーと専任チームがいる前提の正しさです。

個人開発の制約はまったく違います。運用に割ける時間はほぼゼロ、深夜に障害対応はしたくない、そして固定費は1円でも減らしたい。なので最初に、選定をブレさせないための評価軸を3つだけ決めました。以降の判断はぜんぶこの3軸から逆算しています。

  1. 固定費が出ないこと（使われていない間はタダ、が理想）
  2. 手がかからないこと（建てたら忘れていられる）
  3. 収益が運用費を構造的に上回ること（アクセスが増えるほど黒字に近づく）

この軸で見ると、よく紹介される「とりあえずバックエンドを建てる」構成は、実は個人開発と相性が悪いと分かります。建てた瞬間に固定費と運用の手間（＝軸1と軸2）が両方発生するからです。以下、ポイントごとに何を選んだかを書いていきます。

静的サイト vs 動的サイト：なぜ「建てない」構成にしたか

最初の分岐は、静的サイトか動的サイトか、でした。ざっくり選択肢を並べるとこうなります。

  • 動的サイト（自前サーバー/VPS）：自由度は高いが、OS更新・死活監視・脆弱性対応がぜんぶ自分の宿題になる
  • 動的サイト（サーバーレス）：手間は減るが、扱う概念が増え、結局「使われていなくても考え続ける対象」が残る
  • 静的サイト：成果物のファイルを置いて配るだけ。動かし続けるプロセスがない

Pose Mirrorは迷わず静的サイトにしました。理由は3つあります。

Unityとの相性

Pose Mirrorの本体はUnity WebGLでビルドした塊で、ブラウザに配信して動かします。つまり成果物は .wasm や .data といったただのファイルです。これを置いて配るだけなら、リクエストごとにサーバー側で何かを生成する動的サイトの仕組みはまるごと不要でした。静的ホスティングにファイルを置くのが、いちばん素直なやり方になります。Unityで作る時点で、構成の答えは半分決まっていたとも言えます。

保守の軽さ＝「落ちない」という実感

サーバーを建てるということは、OSのアップデート、ミドルウェアの脆弱性対応、プロセスの死活監視——個人で背負うには重すぎる宿題を抱えることでもあります。静的サイトには動かし続けるサーバープロセスがありません。動いていないものは落ちないし、攻撃される面（アタックサーフェス）も小さい。

公開してからしばらく経ちますが、「サーバーが落ちた」起因のトラブルはゼロです。詰まったのは決まってクライアント側——たとえば古いスマホのSafariでメモリ不足になりタブごとクラッシュする、といった話で、サーバーが原因のものは一度もありませんでした。落ちて困るのは自分だけ、という個人開発において、この「そもそも落ちる場所がない」安心感は想像以上に大きかったです。

不必要に難解な技術を入れない

これは技術選定というより姿勢の話です。「将来ユーザーが増えたら困るかも」と先回りして重い構成を入れると、増える前に保守コストで自分が先に疲れてやめてしまう。実際に困ってから足すほうが、個人開発では圧倒的に続きます。Pose Mirrorも、必要になったぶんだけ後付けする方針で組みました。サーバーレスや凝った構成にしなかったのは、技術力の問題ではなく、いちばん壊れにくい場所に置きたかったからです。

ホスティングの比較：なぜFirebaseか

静的サイトと決めたら、次は置き場の比較です。候補はいくつもあります。

ホスティング 無料枠 独自ドメイン/SSL 個人開発での印象
GitHub Pages あり 対応 手軽。ただし github.io のままでは独自ドメインがなくAdSense審査に出せない（後述）
Netlify / Vercel あり 対応 高機能。ただし機能が多く、今回はオーバースペック
Firebase Hosting 大きめ 対応 CDN・SSL込みで、課金ラインが遠い

決め手は無料枠の大きさと、課金が始まるラインの遠さでした。ポイントは「無料で使える」だけではありません。想定するトラフィックの範囲で、課金ラインにそもそも当たらないことです。Firebaseは一定の転送量・保存容量までは無料（Sparkプラン）で、Pose Mirrorの規模ではこの内側に十分おさまります。CDNとSSLも込みなので、自分で証明書を更新する手間もありません。

ここで効いてくるのが評価軸の3つ目、収益との関係です。運用が無料枠の内側で完結する一方、ページには広告を載せています。つまり運用費はほぼ固定でゼロに張りつき、表示回数が増えるほど広告収入だけが増えていく。アクセスが伸びてもサーバー代に怯えなくていい——この「収益が運用費を構造的に上回る」状態こそ、個人開発を続けるための土台だと考えています。

Firebaseへ実際にデプロイする手順や、.wasm ファイルで画面が真っ白になる詰まりどころは 【Firebase】Unity WebGLを無料で公開する手順 に分けて書いています。

無料枠の具体的な数値は変わることがあるので、最新の条件は Firebase公式の料金ページ で確認してください。

GoogleAdSenseに通すための工夫：独自ドメインは実質必須

ここまで「広告収入が運用費を上回る」と書いてきましたが、その大前提として GoogleAdSenseの審査に通る必要があります。ここでつまずく個人開発者がとても多いので、押さえた点を共有します。

最初に知っておきたいのは、AdSenseは独自ドメインが実質必須ということです。GitHub Pagesの username.github.io や、Firebaseが無料で割り当てる xxx.web.app のような共有サブドメインは、自分がそのドメインを所有していないため原則として審査に出せません。「無料ホスティングで公開したのに、AdSenseの『サイトを追加』から先に進めない」のは、たいていこれが原因です。ホスティングが無料でも、ドメインだけは自分の名義で用意する必要があります。

そこで お名前.com で独自ドメイン（kabe-tech.com）を取得し、Firebase Hostingに紐づけました。お名前.comは国内大手のドメイン登録サービスで、取得後にFirebase側へカスタムドメインを追加し、表示されたDNSレコード（TXT・Aレコード）をお名前.comの管理画面で設定すれば、SSL付きで独自ドメイン配信ができます。

ここで評価軸との折り合いを正直に書いておきます。第1の軸は「固定費が出ないこと」でしたが、ドメイン代（年1,000〜1,500円程度）だけは唯一の固定費として受け入れています。これはAdSenseの前提条件であり、広告収入の基盤をつくるための必要経費です。年に千円ちょっとで収益化の土台が立つなら、十分に割の合う投資だと判断しました。

独自ドメイン以外で、審査に向けて意識したのは次の3点です。

  • 中身のある記事をそろえる：AdSenseは「有用性の低いコンテンツ」を嫌います。テンプレを機械的に埋めた薄い量産記事ではなく、実際に詰まった話や検証結果など、読んだ人の役に立つ記事を厚めに用意する（この記事もその一つです）
  • プライバシーポリシー・お問い合わせを置く：運営者情報と、Cookie・広告に関する方針を明示する
  • 十分なコンテンツ量と更新実績：1〜2ページだけのサイトは通りにくい。ある程度の記事数と、継続して更新している実績があると有利

逆に言えば、独自ドメインさえ用意すればホスティングはFirebaseでもGitHub Pagesでも構いません。AdSenseが見ているのはドメインとコンテンツの中身であって、配信元のサービス名ではないからです。GitHub Pagesでも独自ドメインを当てれば通せますが、無料の github.io のままでは土俵に上がれない——ここが最初の分かれ道になります。

Unityの「重さ」を収益側に転換する

Unity WebGLには分かりやすい弱点があります。初回の読み込みが重い。 ビルド一式は数MB〜十数MBになり、最初のアクセスではこれをまるごとダウンロードしてもらう必要があります。転送量で課金される構成なら、ここはコスト要因です。実際、配信サイズを抑えるためにBrotli圧縮は必須で、これを正しく展開させるヘッダー設定で最初は画面が真っ白になりました（この詰まりは後述します）。

ところが、この「重さ」はキャッシュでほぼ消えます。一度ダウンロードされたビルドはブラウザのキャッシュに乗るため、2回目以降のアクセスでは転送がほとんど発生しません。リピーターや回遊が増えても、増えるのは転送量ではなく広告の表示回数のほうです。

整理するとこういう構造です。

  • 初回：重いビルドを転送（コスト発生）。ただし無料枠の内側
  • 2回目以降：キャッシュから読み込み（転送ほぼゼロ）。広告は表示される

つまりUnityの「重さ」は、初回の一回こっきりの負担に閉じ込められ、その後は表示回数＝収益だけが積み上がる形に転換できます。容量を食う技術をあえて選んでも収益設計が崩れないのは、配信モデルとキャッシュのおかげです。重さを理由にUnityを外す必要はありませんでした。

セキュリティ：写真をサーバーに送らない構造にする

Pose Mirrorはユーザーがアップロードした写真を解析します。人物写真というのは、扱いを一歩間違えると流出が即トラブルになる、神経を使うデータです。

ここでの設計判断はシンプルでした。そもそもサーバーに送らない。 ポーズ推定（MediaPipe）はサーバー側ではなく、ユーザーのブラウザの中だけで完結させています。写真はネットワークに出ていかず、解析が終わればそのページを閉じるだけで消えます。

この「クライアントサイドで処理する」選択には、守りと攻めの両面で効果があります。

  • 守り：データが自分のサーバーを通らないので、流出させようがない。漏えいリスクは「持たない」のが最強で、保存しないものは漏れません
  • 攻め：「写真はアップロードされません」とユーザーに約束できる。これは画像を扱うツールでは、そのまま安心材料という価値になります

加えて、静的サイトにしたこととも噛み合います。受け取って処理するバックエンドが存在しなければ、そこを狙う攻撃もそもそも成立しません。セキュリティは機能を足して守るより、守るべきものを持たない構造にするほうが、個人開発では確実だと感じています。

つまづきやすい点

正直に書くと、構成がシンプルでも詰まるところは詰まります。実際にやられたのを2つ。

1つ目は、さきほど触れた真っ白問題。Unity WebGLはFirebaseのヘッダー設定を1つ間違えるだけで、エラーも出さずに画面が真っ白になります。圧縮ファイル（.br）の扱いでつまずく人がとても多く、私も例外ではありませんでした。この手の「構成は正しいのに動かない」系の詰まりは Pose Mirror開発で詰まった5つの問題と解決策 にまとめてあります。

2つ目は、クライアントサイド処理は端末性能に依存すること。安全な代わりに、古いスマホでは解析が重く、メモリ不足でタブが落ちることがありました。安全と速度はトレードオフで、Pose Mirrorはデータの性質（人物写真）を重く見て安全側に振りましたが、扱うデータによってはサーバー処理が正解になる場面もあると思います。

まとめ

Pose Mirrorの技術選定は、新しい技術を採るより入れない判断の連続でした。静的サイトで建てない、Firebaseの無料枠から出ない、Unityの重さはキャッシュで一回に閉じ込める、写真は持たずブラウザ内で処理する。固定費として残したのは、AdSenseのための独自ドメイン代（年に千円ちょっと）だけです。どれも派手さはありませんが、最初に決めた3つの軸（固定費・手間・収益＞運用費）でつないでいくと、「使われるほど手がかからず、収益だけが残る」一本の線になります。

個人開発で技術を選ぶときは、「これで何ができるか」と同じくらい「これで毎月いくら出ていくか」を見たほうがいい、というのが作ってみての実感です。続けられる構成こそが、結局いちばん良い構成でした。次に作るアプリも、たぶん同じ軸で選ぶと思います。同じように個人で収益化を狙っている方の、構成決めの一例になれば嬉しいです。

参考資料

写真1枚でポーズが3Dになる感覚を、まず触って確かめてみてください → Pose Mirror を試す

関連記事：

← ポートフォリオ TOP へ戻る