はじめに
2026年4月、「キュピーン猫画像メーカー（InspirationCat）」というWebアプリがSNSを席巻しました。猫などの動物写真から背景を除去し、集中線を重ねて「ひらめいた瞬間」を演出する"キュピーン"風の画像を生成できるサービスです。公開初日に50万アクセスを記録し、4月9日公開のITmedia NEWS技術解説記事ははてなブックマークで577 usersを獲得。「サーバ代0円」という事実が個人開発者コミュニティに大きな反響を呼びました。
開発したのは電電猫猫（@nya3_neko2）さん。もともと「むちゃまる」さんがX上で公開していた飼い猫のキュピーン画像シリーズに触発され、「自分の猫でもやってみたい」という欲求を形にしたのが出発点です。コア部分はVite + TypeScript + Canvas APIというミニマル構成で、フレームワークにもサーバにも依存せず、すべての重い処理をブラウザに押し込む思い切った設計になっています。
この記事では、なぜ50万アクセスを無料で捌けたのか、その技術構成をアーキテクチャ・プラットフォーム選定・クライアントサイドAI処理・UX設計・スケーリング戦略の5つの観点から分解し、個人開発者が「バズっても壊れないインフラ」を設計するための再現可能な知見として整理します。
参考: 「キュピーン猫画像メーカー」初日50万アクセスもサーバ代「0円」 その秘密は - ITmedia NEWS
なぜバズったのか ── 公開初日のトラフィック曲線とUX心理学
技術の話に入る前に、「なぜ50万アクセスが発生したのか」を整理しておきます。アーキテクチャの妥当性を評価するには、想定負荷のプロファイルを理解することが不可欠だからです。
初日トラフィックの典型的な構造
個人開発のバイラルアプリが初日で50万アクセスに達するパターンは、以下の3フェーズで構成されます。
- 知人・コミュニティ内での初期拡散（公開直後〜数時間、数百〜数千アクセス）
- インフルエンサーによるシェアを起点とした爆発フェーズ（数時間〜半日、数万〜十数万アクセス）
- メディア・まとめサイト経由の二次流入（24時間〜数日、残り数十万アクセス）
InspirationCatの場合、Xでのタレント（小山百代さんなど）による「#InspirationCat」タグ付き投稿、それを追いかけたユーザーたちの「うちの猫でもやってみた」連鎖、そしてITmedia NEWSとPC Watchによる技術解説記事の同日配信がほぼ重なり、フェーズ2とフェーズ3が同時発火する形になりました。結果としてトラフィックは一晩でスパイクし、通常のVPSなら秒間数百〜数千リクエストのバーストに耐える必要が出ます。
バイラルを駆動したUX心理学の仕組み
なぜユーザーは「自分もやってみたい」と思い、さらに「結果をSNSに投稿する」というもう一段の行動を起こしたのか。これは単純な話題性ではなく、いくつかの心理的スイッチが同時に押された結果です。
第一に、投入コストの極小化です。会員登録なし、ログインなし、アプリインストールなし。ブラウザでURLを開いて写真を選ぶだけで結果が返ります。行動経済学でいう「取引コスト」が限りなくゼロに近く、「やってみる」と決断する閾値が極端に低い構造です。
第二に、結果の即時性と意外性です。ユーザーは3〜10秒程度の待ち時間で完成画像を手にし、しかもその結果は「自分の猫」という一次的に強いエモーショナルアンカーを持つコンテンツです。「自分が撮った写真で面白い結果が返ってくる」という個別化された驚きは、テンプレート的な面白画像ジェネレータとは比較にならない共有意欲を生みます。
第三に、シェア設計の自然さです。完成画像は透かしもロゴも最小限で、そのまま保存してSNSに上げれば成立します。「シェアボタンを押してもらう」のではなく、「結果自体が投稿物として完成している」という設計が、追加の摩擦なしにバイラルループを回します。
第四に、プライバシーの心理的安全性です。後述するクライアントサイド処理により、「画像はサーバに送信されません」という事実が明示されています。自分のペット写真や背景に映った部屋の様子をアップロードする心理的ハードルが下がり、利用の踏み切りと共有の両方を後押しします。
この4つが重なったとき、バイラルループは単なる話題性ではなく構造的な現象になります。そしてバズった瞬間に爆発するトラフィックを、追加コストゼロで受け止められる設計が用意されていたことが、本件の本質です。
50万アクセスをサーバ代0円で捌いた3層アーキテクチャ
InspirationCatのアーキテクチャは、「サーバに計算させない・保存させない・転送もCDNに任せる」という一貫した設計思想に基づいています。全体像は以下の3層で構成されます。
1. 静的ファイル配信層: Cloudflare Pages
フロントエンドはVite + TypeScriptで構築された純粋な静的サイトです。ReactやVueといったフレームワークは採用せず、バニラTypeScriptとCanvas APIによるシンプルな構成を選択しています。バンドルサイズが小さく、初回ロードの軽さがそのまま離脱率の低下につながります。
静的ファイルはCloudflare Pagesにデプロイされ、世界330拠点以上のエッジCDNから配信されます。ここで重要なのは、無料プランでも帯域幅が無制限であり、アクセス元のユーザーに近いエッジロケーションからレスポンスが返るため、オリジンへの負荷という概念自体が実質的に存在しない点です。50万リクエストのほぼすべてがエッジキャッシュで解決されるため、オリジン側に「捌く」という負担は発生しません。
2. AI推論層: ブラウザ上のONNX Runtime Web
背景除去のAI処理は、サーバではなくユーザーのブラウザ上で実行されます。@imgly/background-removalライブラリが内部でONNX Runtime Webを呼び出し、WebAssembly（またはWebGPU対応端末ではWebGPU）でニューラルネットワークを動作させます。使用されるモデルはisnet_fp16というISNet系のセマンティックセグメンテーションモデルで、FP16量子化により約40MBに圧縮されています。
初回アクセス時にこの約40MBのモデルファイルとWASMランタイムをダウンロードし、ブラウザキャッシュに保存します。2回目以降の処理はキャッシュから即座に起動できるため、リピーターのUXも確保されます。初回のダウンロードコストはCDN経由で配信されるためこちらも帯域は気にする必要がありません。
3. 画像最適化層: WebPによる帯域削減
集中線テンプレートなどの背景画像アセットは、PNG（合計5.6MB）ではなくWebP（約80KB）を優先配信し、WebP非対応ブラウザにのみPNGをフォールバックします。<picture>要素とtype="image/webp"のsourceを組み合わせることで、ブラウザが自動的に対応フォーマットを選択します。
帯域の単純計算では、50万ユーザーが全員PNGを取得した場合は約2.8TB、WebPでは約40GBと、実に70倍の差が出ます。Cloudflare Pagesは帯域無制限とはいえ、無駄な転送はエッジCPUとユーザー側のロード時間を消費するため、この最適化はUX・パフォーマンス・ユーザー側通信量の3点で効いてきます。
この3層が揃うことで、「サーバサイドの計算コストがゼロ」「画像をサーバに保存しない」「転送コストもゼロ」という三拍子の経済性が成立し、文字通りのサーバ代0円を達成しています。
なぜCloudflare Pagesなのか ── プラットフォーム選定の比較分析
サーバレスホスティングにはVercel、Netlify、Firebase Hosting、Render、AWS Amplify、Cloudflare Pagesなど複数の選択肢があります。InspirationCatがCloudflare Pagesを選んだ理由を、無料枠と課金モデルの視点で掘り下げます。
無料枠の帯域幅が運命を分ける
| プラットフォーム | 無料枠の帯域 | 50万アクセス（約1TB）時の想定コスト | 特徴 |
|---|---|---|---|
| Cloudflare Pages | 無制限 | 0円 | 帯域無制限、330拠点以上のCDN、商用利用OK |
| Vercel (Hobby) | 100GB/月 | Pro強制移行＋従量、約54,000円 | 商用利用不可、Next.js親和性 |
| Netlify (Free) | 100GB/月 | 超過分$55/100GB〜、約40,000円〜 | Jamstack向け、ビルド時間も制限 |
| Firebase Hosting | 10GB/月 | GB単位従量、数十万円規模 | GCP統合が強み |
開発者本人も「Vercelで同規模を運用していたら約54,000円の請求が来ていた」と試算しており、Cloudflare Pagesの「帯域無制限」は、バイラルを前提とする個人開発において他の選択肢と決定的な差を生みます。
とくに注意すべきはVercelのHobbyプランが商用利用禁止である点です。アフィリエイト収益や有料機能の追加を視野に入れる段階で、Hobbyから月20ドルのProプランへの強制移行が発生します。CloudflareはFree層から商用利用が可能で、バズったあとに事業化を検討する際にもプラン移行のプレッシャーがありません。
CDNアーキテクチャの違いが捌けるスパイクを決める
Vercel・Netlifyは実質的にAWSやGCPの特定リージョンをオリジンとし、その上にCDNを被せる構造です。Cloudflareは最初からCDN事業者として全世界にエッジ網を構築しており、Pagesはそのエッジ網に直接静的アセットを載せる形になります。バイラル時のようなグローバルなトラフィックスパイクでは、近くのエッジからレスポンスを返せる拠点数とキャッシュヒット率が実効性能に直結します。
Cloudflare Pagesの無料枠にも制約はある
ただしCloudflare Pagesも無敵ではなく、以下のような上限があります。
| 項目 | 無料プランの上限 |
|---|---|
| 帯域幅 | 無制限 |
| 静的アセットへのリクエスト | 無制限 |
| ビルド回数 | 500回/月 |
| Functions（Pages Functions）呼び出し | Workers Freeの日次100,000リクエストに準ずる |
| 1ファイルの最大サイズ | 25MiB |
| 1サイトあたりのファイル数 | 20,000（Free） |
静的配信とクライアントサイド処理で完結するInspirationCatはこの制限に触れません。逆にサーバ側ロジックをFunctionsに寄せ始めると、日10万リクエストの壁にぶつかる可能性があります。静的とFunctionsの境界をどこに引くかが、0円運用を維持する鍵になります。
参考: Cloudflare Pages Limits - Cloudflare Docs
参考: 【2026年版】Vercel / Netlify / Cloudflare Pages / Render…主要デプロイ先を比較 - Qiita
なぜクライアントサイドなのか ── コスト・プライバシー・スケーラビリティの同時最適化
画像処理をクライアントサイドに寄せた判断には、3つの明確な理由があります。これらは単に「サーバ代を浮かせる」以上の意味を持ちます。
理由1: サーバサイドAI推論の経済的現実
サーバサイドで背景除去AIを動かす場合、GPUインスタンスか、CPU推論に特化したコンテナサービスが必要です。代表的なコスト比較は以下のとおりです。
- AWS Lambda（CPU推論）: 1リクエストあたり推論時間を5秒と想定して、50万リクエストで約$50〜$100。ただしLambdaのメモリ上限やコールドスタート問題で、ユーザー体験としては厳しい
- AWS SageMaker Serverless Inference: 50万リクエストでインスタンス時間が積み上がり、数百ドル規模
- Replicate / Banana.dev等のGPU推論API: 1リクエスト$0.01〜$0.05で、50万リクエストなら$5,000〜$25,000
つまり真剣にサーバサイドで処理する場合、バズった瞬間に数十万〜数百万円のコストが一気に発生します。クライアントサイドに寄せるということは、この計算コストを「ユーザーの端末が自発的に肩代わりする」構造に書き換える行為です。
理由2: プライバシーの同時解決
ユーザーがアップロードする写真にはEXIF情報としてGPS座標や撮影日時が埋め込まれていることがあります。画像がサーバに送信されない設計であれば、これらの情報漏洩リスクは原理的にゼロになります。
結果として、プライバシーポリシーの記載、個人情報保護法対応、ストレージの暗号化、バックアップ、アクセスログ監査、インシデント対応計画など、サーバ側でユーザー画像を預かる場合に発生する運用コストが丸ごと不要になります。個人開発者にとって、法務・運用コストの削減は金銭コスト以上に重要な意味を持ちます。
理由3: スケーラビリティの自動確保
サーバサイド処理の場合、想定を超えるトラフィックが来ればキューイング、オートスケール、最悪の場合はダウンと、運用者の介入が必要になります。クライアントサイド処理ならば、ユーザーが増えれば増えるほど「計算資源も一緒に増える」という理想的なスケーリングが自動で成立します。
極論すれば、1億人が同時に使っても、サーバ側の計算コストは増えません。増えるのはCDN経由の静的配信量だけで、それもCloudflare Pagesなら無制限無料の範囲です。
ONNX Runtime Webの動作原理 ── ブラウザでAIが動く仕組み
ブラウザ上でニューラルネットワークを動かすには、2つの実行基盤が必要です。WebAssemblyとWebGPUです。それぞれの役割を整理します。
WebAssembly（WASM）バックエンド
ONNX Runtime Webは、ネイティブのONNX Runtime CPUエンジンをEmscriptenでWASMにコンパイルしたものです。ブラウザはこのWASMバイナリをJITに近い速度で実行でき、ネイティブの8〜9割程度のスループットが出ます。さらにマルチスレッド（SharedArrayBufferベース）とSIMD命令（wasm-simd128）を組み合わせることで、シングルスレッドCPU比で最大数十倍の高速化が得られます。
WASMの強みは互換性です。ChromeもSafariもFirefoxも、モバイルを含む主要ブラウザが対応しており、WebGPUに未対応の古い端末でもフォールバックとして機能します。InspirationCatの「誰でも開いて試せる」という特性は、このWASMフォールバックの存在が支えています。
WebGPUバックエンド
ONNX Runtime Webは1.17からWebGPUを正式サポートしました。WebGPUはブラウザからGPUを抽象化して叩くためのモダンなWeb APIで、モデルの推論をGPUで並列実行します。IMG.LYのベンチマークでは、シングルスレッドCPUの最大550倍、マルチスレッドCPUの約20倍の推論速度が出ると報告されています。
WebGPUはChrome 113以降、Edge 113以降、最近のSafari（macOS Sonoma以降）で有効です。Chrome 113のリリースは2023年春で、このタイミングから「ブラウザで本格的なAI推論をやる」という選択肢が現実的になりました。
フォールバックの実装戦略
ONNX Runtime Webは実行時に利用可能な最速バックエンドを自動選択します。優先順位は「WebGPU → WASM SIMD + マルチスレッド → WASM SIMD → 素のWASM」で、どの端末でも必ず何かしらの経路で動くよう設計されています。
import { removeBackground } from "@imgly/background-removal";
const blob: Blob = await removeBackground(imageUrl, {
// 端末メモリに応じて解像度を落とす段階的縮退
model: "isnet_fp16",
output: { format: "image/png", quality: 0.9 },
// WASM/WebGPUの自動選択は内部で実施
});
処理の流れを6ステップに分解すると以下のようになります。
- ユーザーが画像を選択（ファイル選択またはドラッグ&ドロップ）
- Canvas APIで画像をリサイズ。端末メモリに応じて1024px / 768px / 512pxに自動調整
- ONNX Runtime Webのバックエンド自動選択（WebGPU優先、不可ならWASM）
- ISNetモデルで推論を実行し、前景と背景を分離するマスクを得る
- マスクを元画像に適用して背景を除去し、Canvas APIで集中線テンプレートと合成
- 完成画像をPNG/JPEGとしてローカルに保存。サーバ送信は一切なし
参考: 20x Faster Browser Background Removal with ONNX Runtime - IMG.LY
参考: @imgly/background-removal - npm
クライアントサイド画像処理のメモリ管理
ブラウザ上で40MBのモデルを動かし、画像を扱うには、メモリ管理が重要になります。特にモバイル端末ではメモリ上限が厳しく、雑に実装するとタブが突然クラッシュします。
InspirationCatが採用しているであろう実装パターンを整理すると、次のようになります。
段階的リサイズによるメモリ抑制
高解像度のまま推論すると、入力テンソルのサイズが大きくなりメモリを圧迫します。1024x1024の画像なら入力テンソルだけで12MB程度、中間レイヤの活性化マップまで含めると数百MBに達することもあります。
モバイル端末ではnavigator.deviceMemoryやnavigator.hardwareConcurrencyを参照し、4GB未満なら512px、4〜8GBなら768px、それ以上なら1024pxといった段階的な解像度調整が定石です。精度は若干下がりますが、クラッシュするよりは結果を返せた方がUXとしては圧倒的に上です。
Canvasコンテキストの明示的解放
Canvas要素とImageBitmapは使い終わったら明示的に解放するのが安全です。
const bitmap = await createImageBitmap(file);
try {
// 処理
} finally {
bitmap.close(); // ImageBitmapは明示close
}
複数画像を連続処理するフローでは、前の画像のリソースを確実に解放しないとメモリが線形に増えていきます。
モデルのシングルトン化とキャッシュ
@imgly/background-removalはモジュールスコープで推論セッションを保持するため、初回の40MBダウンロード以降はメモリ上のモデルを使い回します。複数画像を連続処理するときは、このシングルトン挙動によって再ロードを避けることができます。
SNSシェア導線とOG画像の設計
バイラル設計の仕上げはOGP（Open Graph Protocol）です。リンクがSNSで共有されたときに、埋め込みカードにサムネイル・タイトル・説明文がきれいに表示されるかどうかで、クリック率は数倍変わります。
静的OG画像 vs 動的OG画像
OG画像の提供方法は2つあります。
- 静的OG画像:
/og.pngのような固定画像を<meta property="og:image">に指定 - 動的OG画像: ユーザーごとに生成されたOG画像をFunctionsで動的配信
動的OG画像は魅力的ですが、Cloudflare Pages Functionsを使うと前述の日次10万リクエスト上限にぶつかる可能性があります。InspirationCatのように「画像生成自体はローカルで完結し、結果はユーザーが自分で保存してSNSに貼る」という設計なら、トップページの静的OG画像さえ用意しておけば十分です。
必須のメタタグセット
<meta property="og:title" content="キュピーン猫画像メーカー">
<meta property="og:description" content="猫の写真に集中線を重ねて閃いた瞬間を演出">
<meta property="og:image" content="https://example.com/og.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:type" content="website">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@nya3_neko2">
twitter:cardをsummary_large_imageにしておくと、Xで大きなカード表示になり、タイムライン上での視認性が上がります。OG画像サイズは1200x630が標準で、XとFacebookの両方で崩れません。
バイラルWebアプリをテンプレート化する ── 再現可能な設計パターン
ここまでの分析を、個人開発者が明日から使える形にテンプレート化します。
0円インフラ設計チェックリスト10項目
- 計算処理をクライアントサイドに寄せられないか検討したか
- 帯域幅無制限のホスティングを選定したか（Cloudflare Pages等）
- 画像・動画アセットを最適化したか（WebP / AVIF変換、適切な解像度指定）
- サーバに状態を持たない設計（ステートレス）にできているか
- ユーザーデータをサーバに保存しない設計が可能か検討したか
- 会員登録やログインなしで即座に試せる導線になっているか
- 初回ロード時の総転送量を把握し、モバイルでも3秒以内に使える状態か
- WebP非対応ブラウザ・WebGPU非対応端末へのフォールバックを用意したか
- OGPとTwitter Cardを正しく設定し、SNSでの表示を最適化したか
- 端末スペックに応じた段階的縮退（解像度自動調整）を実装したか
段階的スケーリングパス
バイラル後に機能を増やしていくときの、0円 → $5/月 → $50/月の階段を整理します。
| フェーズ | 月額コスト | 追加される機能 | 主な制約 |
|---|---|---|---|
| 1. 初期 | 0円 | Cloudflare Pages静的配信のみ | Functions非使用 |
| 2. API追加期 | 0円 | Workers / Pages Functions（Free） | 10万req/日、10ms CPU |
| 3. 本格API期 | $5/月 | Workers Paid、D1、KV（従量） | 1,000万req/月まで含む |
| 4. 成長期 | $20/月 | Cloudflare Pages Pro、並列ビルド | ビルド回数拡張 |
| 5. 事業化期 | $50〜/月 | R2ストレージ、画像変換API、解析基盤 | 用途次第 |
重要なのは、フェーズ1の段階でアーキテクチャが確立されていれば、フェーズ2以降への移行が既存コードへの最小限の追加で済むことです。静的サイトに少しずつFunctionsを足していくスタイルは、運用コストと学習コストの両方を低く保ちます。
「課金が始まる条件」を見極める4つのシグナル
0円運用を維持できなくなる兆候は、以下の4つの瞬間です。
- サーバ側で処理しないと成立しないロジックが必要になる（決済、認証、マッチング等）
- ユーザーごとの永続データが必要になる（ログイン状態の保持、お気に入り、履歴）
- SEOや初期表示速度のためにSSR/ISRを入れたくなる
- Pages Functionsが日10万リクエストに恒常的に触れる
1つ目はD1やKV、2つ目はCloudflare Access、3つ目はWorkers上のフレームワーク（Remix、Next.js on Pages等）、4つ目はWorkers Paidへのアップグレードで対応できます。いずれも$5〜$20の追加でフェーズ2〜3に収まるケースが多く、「バズってから事業化を検討する」という順序で設計しても十分に間に合います。
まとめ ── 0円で50万アクセスは偶然ではなく必然
InspirationCatの「サーバ代0円で50万アクセス」は、魔法でも偶然でもありません。次の設計判断の積み重ねによる必然的な結果です。
- AI推論をブラウザ側に移すことで、サーバの計算コストをゼロにした
- Cloudflare Pagesの帯域無制限プランを選択し、転送コストをゼロにした
- 画像をサーバに保存しないことで、ストレージコストとプライバシーリスクを同時に排除した
- WebPによるアセット最適化で、帯域消費を70分の1に削減した
- フレームワーク非依存のミニマル構成で、初回ロード時間を最小化した
- 結果物そのものがシェアしたくなる形にすることで、バイラルループを設計の外に出さずに取り込んだ
個人開発において「バズったらどうしよう」は嬉しい悲鳴ですが、「バズっても大丈夫な設計」は事前に準備できます。クライアントサイド処理の活用、帯域無制限ホスティングの選定、アセットの徹底的な最適化、そしてUXの摩擦を限界まで削ること。この4点を意識するだけで、サーバ代を気にせずサービスを公開できる時代になっています。次にバイラルを起こすのは、この記事を読んで設計を引き算したあなたのアプリかもしれません。
参考URL
- 「キュピーン猫画像メーカー」初日50万アクセスもサーバ代「0円」 その秘密は - ITmedia NEWS
- ブラウザ内でAI処理が完結→バズってもサーバー代0円を実現した画像メーカー - PC Watch
- 20x Faster Browser Background Removal with ONNX Runtime - IMG.LY
- @imgly/background-removal - npm
- imgly/background-removal-js - GitHub
- ONNX Runtime Web - onnxruntime.ai
- ONNX Runtime Web unleashes generative AI in the browser using WebGPU - Microsoft Open Source Blog
- Cloudflare Pages Limits - Cloudflare Docs
- Cloudflare Pages Functions Pricing - Cloudflare Docs
- 【2026年版】主要デプロイ先を比較 - Qiita
- Cloudflare vs Vercel vs Netlify: The Truth about Edge Performance 2026 - DEV Community
- InspirationCat（公式サイト）