初日50万アクセスでサーバー代0円を実現した実例をもとに、Cloudflare Pagesとブラウザ内AI処理を組み合わせたサーバーレス設計の全貌を解説します。
「バズったら破産する」という恐怖、ありませんか?
Webアプリやツールを作って公開したとき、こんな不安を感じたことはないでしょうか。
「もし急にアクセスが集中したら、サーバー代が爆発するんじゃないか」 「Twitterでバズったら、請求書が飛んできて目が覚めるんじゃないか」
これは杞憂でも誇張でもありません。クラウドサービスの従量課金は、無計画に設計すると一夜にして数十万円の請求につながることがあります。実際、海外では「クラウド破産(Cloud Bill Shock)」と呼ばれる事例が後を絶ちません。
しかし、2025年現在、ある設計パターンを採用することでこの問題を根本から解消できます。50万アクセスでサーバー代が文字通り0円だった実例があります。
この記事では、その実例を徹底的に解剖し、同じ設計を自分のプロジェクトに応用するための知識を体系的にお伝えします。
実例:初日50万アクセス、サーバー代0円
2025年、電電猫猫(@nya3_neko2)氏が公開した「InspirationCat(ひらめき猫画像メーカー)」は、公開直後からSNSで爆発的に拡散し、初日だけで約50万アクセスを記録しました。
このアプリは、ユーザーがアップロードした猫の写真の背景を自動除去し、インスピレーションを感じるメッセージと合成してオリジナル画像を生成するツールです。AIによる背景除去処理が含まれるにもかかわらず、サーバーへの費用は一切かかりませんでした。
「50万アクセスで0円」という事実は、単なる幸運ではありません。意図的な設計の結果です。なぜそうなったのか、3つの設計判断を軸に紐解いていきましょう。
なぜ0円で済んだのか:3つの設計判断
設計判断①:AI処理をブラウザに寄せた(ONNX Runtime Web)
最も重要な判断は、「背景除去のAI推論をサーバーではなくブラウザで行う」という選択です。
通常、AI処理はサーバーサイドで行うことが多く、「ユーザーが画像をアップロード → サーバーがAI処理 → 結果を返す」という流れが一般的です。しかしInspirationCatでは、@imgly/background-removalライブラリを使い、ONNX Runtime WebとWebAssembly/WebGPUを組み合わせることで、推論処理をすべてユーザーのブラウザ上で完結させています。
約40MBのAIモデルを初回アクセス時にダウンロードしてブラウザにキャッシュし、2回目以降はキャッシュから即座に推論を行う仕組みです。スマートフォンでの動作も考慮されており、処理画像サイズを1024px → 768px → 512pxと自動フォールバックさせることで、スペックの低いデバイスでも安定動作を実現しています。
// @imgly/background-removal の基本的な使い方(概念例)
import { removeBackground } from '@imgly/background-removal';
const result = await removeBackground(imageBlob, {
publicPath: '/models/', // モデルファイルのパス
model: 'medium',
output: {
format: 'image/webp',
quality: 0.85,
},
});
この設計により、何万人がアクセスしてもサーバーのCPU・GPU・メモリはまったく消費されません。処理リソースはすべてユーザーの端末が負担するため、同時接続数がどれだけ増えても課金には直結しないのです。
設計判断②:画像をサーバーに保存しない
次に重要なのは、「生成した画像をサーバーに一切保存しない」という判断です。
処理はブラウザ内で完結し、生成画像もブラウザのメモリ上に存在するだけ。ユーザーが「ダウンロード」ボタンを押したとき、その画像はサーバーを経由せずに直接デバイスに保存されます。
この設計にはコスト削減以上のメリットがあります。
- プライバシー保護: ユーザーのペット写真が外部サーバーに送信されない
- セキュリティリスクの排除: 画像の漏洩・悪用の可能性がゼロ
- GDPR・個人情報保護法への対応: データを保持しないため規制対応が不要
- ストレージコストのゼロ化: S3やCloud Storageの費用が一切発生しない
設計判断③:Cloudflare Pagesにデプロイ(帯域幅無制限)
最後の決め手は、デプロイ先の選択です。InspirationCatはCloudflare Pagesを使って静的ファイルとして配信されています。
Cloudflare Pagesの最大の特徴は、帯域幅が無制限・無料であること。50万ユーザーが40MBのモデルをダウンロードし、WebP画像(約80KB)を生成したとしても、転送量に対する追加課金は発生しません。
私たちFivenine DesignでもLanding PageやキャンペーンサイトにCloudflare Pagesを活用しており、その安定性と無料枠の広さは実務で十分に検証済みです。
技術構成の全体像
flowchart TD
A[ユーザーがブラウザでアクセス] --> B[Cloudflare Pages\nHTMLファイル・JS配信]
B --> C[初回:AIモデル 約40MB\nダウンロード&キャッシュ]
B --> D[2回目以降:\nキャッシュから即時推論]
C --> E[ブラウザ内で背景除去処理\nONNX Runtime Web / WebAssembly]
D --> E
E --> F{デバイス性能チェック}
F -->|高スペック| G[1024px処理]
F -->|中スペック| H[768px処理]
F -->|低スペック| I[512px処理]
G --> J[WebP出力 約80KB]
H --> J
I --> J
J --> K[ユーザーのデバイスに直接保存]
style B fill:#F6821F,color:#fff
style E fill:#3B82F6,color:#fff
style K fill:#10B981,color:#fffフロントエンドのスタック構成は以下のとおりです。
- Vite + TypeScript: ReactやVueを使わないバニラTS構成。バンドルサイズを最小化し、不要なフレームワークオーバーヘッドを排除
- Canvas API: 画像の合成・テキスト描画をブラウザネイティブのAPIで処理
- @imgly/background-removal: ONNX Runtime Web経由でAIモデルをブラウザ実行
- WebP優先出力: 約80KBのWebPを出力し、非対応ブラウザには自動でPNG(5.6MB)にフォールバック
Reactを使わない選択も興味深いポイントです。Canvas APIを直接操作する処理では、仮想DOMによるオーバーヘッドが不要なため、バニラTypeScriptのほうがパフォーマンス面で有利になるケースがあります。
コスト比較:同じトラフィックで何が変わるか
50万アクセス × 約2MBの平均転送量 ≒ 合計約1TBのデータ転送が発生した今回のケースで、デプロイ先の違いがどれだけのコスト差を生むか見てみましょう。
| 項目 | Cloudflare Pages | Vercel(無料枠超過後) | AWS Lambda + S3 |
|---|---|---|---|
| 帯域幅の課金 | |||
| 50万アクセスの転送コスト | 0円 | 約$360(約5.4万円) | 別途発生 |
| AI処理10万回(サーバーサイド) | 非該当 | 非該当 | 約$115/日(約17,000円/日) |
| 静的ファイル配信の無料枠 | 無制限 | 100GB/月まで | 従量課金 |
| CDNの自動適用 | |||
| デプロイの手軽さ | ◎ | ◎ | △ |
| カスタムドメイン |
特に注目すべきはWebP vs PNGのコスト差です。50万ユーザーに対して背景画像だけをPNGで配信した場合とWebPで配信した場合、転送量の差は約2.76TBにもなります。画像フォーマットの選択一つで、これだけのインフラコストに直結するのです。
この設計パターンが使えるケース・使えないケース
この設計パターンが有効なユースケース
- 画像加工ツール: リサイズ、フィルター、合成、背景除去などCanvas APIで完結する処理
- テキスト生成・変換ツール: 文字装飾、フォント変換、QRコード生成など
- 計算・シミュレーターツール: 住宅ローン計算、カロリー計算、配色チェックなど
- ローカルファイル処理: PDF閲覧・変換、動画サムネイル生成、音声波形表示
- オフライン対応が必要なツール: PWA化してネット接続なしでも動作させたい場合
- プライバシーに敏感なデータを扱う処理: 医療・法務・個人情報が絡む場面
この設計では対応できないケース(サーバーサイド処理が必要)
- データの永続化・共有が必要: ユーザー間でデータを共有したり、履歴を保存したりする場合。ブラウザのローカルストレージでは同一端末しか対応できません
- 認証・権限管理が必要: ログイン、会員機能、購入履歴などが絡む場合はバックエンドが不可欠です
- 重いAIモデルの実行: 数GB級のモデルや、GPU前提の処理はブラウザ実行に限界があります。ONNX Runtime Webが対応しているモデルの種類にも制限があります
- 外部APIとのサーバーサイド連携: APIキーをフロントエンドに露出させられない場合(決済、SMS送信など)
- リアルタイム多人数通信: WebSocketやWebRTCのシグナリングサーバーが必要な場合
よくある失敗パターンと対処法
失敗①:初回ロードが重くて離脱される
AIモデルの約40MBダウンロードは、ユーザーへの説明なしに実行すると「壊れているのか?」と思わせてしまいます。InspirationCatでは「AIモデルを読み込み中...」などのプログレス表示で対処しています。Service Workerを使ったキャッシュ戦略と組み合わせることで、2回目以降の体験を大幅に改善できます。
// プログレスコールバックの実装例(概念)
await removeBackground(imageBlob, {
progress: (key, current, total) => {
const percentage = Math.round((current / total) * 100);
updateProgressBar(percentage); // UIに進捗を表示
}
});
失敗②:スマホで処理が止まる・クラッシュする
InspirationCatが採用した「1024px → 768px → 512pxの自動フォールバック」は非常に実践的な解法です。モバイル端末のメモリ上限やGPU性能は多様で、高解像度処理でクラッシュするケースが多発します。try/catchで処理失敗を検知し、解像度を落として再試行するロジックは必須と考えてください。
失敗③:PNG配信でCFの帯域を無駄遣いする
Cloudflare Pagesは帯域無制限ですが、PNG(5.6MB)とWebP(80KB)では同じ画像で約70倍のファイルサイズ差があります。ユーザー体験にも直結するため、Canvas APIのtoBlobでWebPを優先し、非対応環境のみPNGにフォールバックする実装を徹底しましょう。
失敗④:Vercelを「無料だから」という理由で選ぶ
Vercelの無料プランは帯域上限が100GB/月です。バズった瞬間に上限を超え、サイトが強制停止になるか高額請求が発生します。静的ファイル配信かつ帯域無制限が必要なら、Cloudflare Pagesが現時点で最適解です。サーバーレス Webアプリ 無料で運用するなら、プラットフォーム選定が最初の関門になります。
個人開発・中小企業にとってのこの設計の意味
InspirationCatの事例が特に重要なのは、個人開発者がインフラコストを恐れずにアイデアを検証できることを証明したからです。
従来、「バズるかもしれないアプリ」を公開するには、スケーリング設計やコスト上限の設定、キャッシュ戦略など、ある程度のインフラ知識が必要でした。しかしCloudflare Pages上の静的アプリ+ブラウザ内処理という構成を取れば、トラフィックが0人でも100万人でもインフラコストは変わりません。
中小企業の観点でも、この設計パターンには大きな意味があります。
- 社員向け業務ツール: ブラウザ完結の帳票変換ツールや画像圧縮ツールをCloudflare Pagesで配信すれば、SaaSの月額費用を削減できます
- キャンペーンサイト: 期間限定で大量アクセスが見込まれる告知ページは、従量課金のサーバーより静的配信が安全です
- プロトタイプ検証: MVP(最小機能製品)を無料で公開し、市場の反応を確認してから本格開発に投資できます
Fivenine Designでは、こうしたサーバーレス Webアプリ 無料運用の構成をクライアントのプロジェクト要件に応じて積極的に提案しています。特にキャンペーン系や単機能ツール系の案件では、Cloudflare Pagesを軸にした設計が費用対効果の面で非常に優れた選択肢になります。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
電電猫猫氏の「InspirationCat」が示した「50万アクセス・サーバー代0円」は、偶然でも特殊な才能でもなく、3つの設計判断の積み重ねによって実現されました。
- AI推論をブラウザに移す(ONNX Runtime Web + WebAssembly/WebGPU)
- 画像をサーバーに保存しない(プライバシーとコストの同時解決)
- Cloudflare Pagesで帯域無制限配信(スパイク耐性と0円運用の両立)
この設計はすべてのWebアプリに適用できるわけではありませんが、「ユーザーの端末で完結する処理」「データを保持しなくてよい用途」「アクセス予測が難しいツール系コンテンツ」には非常に強力なアプローチです。
「面白いツールのアイデアはあるけど、バズったときのコストが怖くて公開できない」という状況は、設計次第で完全に解消できます。ぜひこのパターンを自分のプロジェクトに照らし合わせて検討してみてください。
:::