コンテンツサイト・ツールサイト・SaaS：個人開発の3層プロダクト設計

あるツールページには1日200件のアクセスがあり、ユーザーはパラメータを入力し、結果を生成してコピーしています。それでも登録者はいません。別のコンテンツページはGoogle Search Consoleで表示回数もCTRも悪くないのに、GA4のinputとgenerateはほとんど発火していません。さらに別の無料ツールでは再訪が増え、「履歴を保存できないか」「まとめて処理できないか」というメールが届き始めました。

アクセス数だけを見るより、これらのシグナルを分けて考えるほうが判断しやすくなります。コンテンツは需要の存在を、ツールは実際の操作を、SaaSは継続価値への支払い意向を検証します。3層を同時に公開する必要はありません。根拠がそろった段階で次の層を足します。

3つのプロダクト層が検証するもの

コンテンツサイト：需要を見つけて説明する

コンテンツサイトは検索意図から需要を見つけ、記事で課題の状況を説明します。中心となる問いは「この需要が存在するか」であり、「ユーザーがどのように操作するか」ではありません。GSCのクエリとの一致、表示回数、CTR、GA4のエンゲージメント時間、スクロール深度、再訪率などを見ます。

技術コストは3層の中で最も低くなります。Cloudflare Pages Freeは2026年7月時点で、月500回のビルド、サイトあたり最大20,000ファイル、1アセット25 MiBまでです。静的コンテンツサイトの初期検証なら、多くの場合この範囲で足ります。収益化はトラフィック品質と検索意図に左右されます。アクセスが多ければ広告、購買意図が明確ならアフィリエイト、単発需要ならPayment Linkでテンプレートやレポートを販売できます。ただしコンテンツだけでは支払い意向は検証できません。確認できるのは需要の存在です。

ツールサイト：ユーザーの操作を検証する

ツールでは、ユーザーがパラメータを入力し、結果を生成し、出力をコピーし、ファイルをダウンロードします。閲覧は「見た」ことを、操作は「解決を試みた」ことを示します。GA4のinput、generate、copy、再訪率、共有率などが判断材料です。

技術コストは中程度です。軽量APIやブラウザ内計算だけなら、Workers Freeは2026年7月時点で1日100,000リクエストまで利用できます。動的リクエストやCPU時間が増えたら、月額最低5ドルのWorkers Paid Standardや自前APIを検討します。低頻度の検索ツールは広告、高頻度のツールは利用上限、プレミアムテンプレート、広告非表示、バッチ処理などの会員機能、単発ツールはPayment Link経由のテンプレート販売が候補です。それでもツール単体で分かるのは、ユーザーが操作するかどうかであり、継続的な支払いではありません。

SaaSやデジタル商品：継続価値を検証する

SaaSやデジタル商品では、登録、試用、支払い、継続利用を観察します。問うべきことは「一度使うか」ではなく「この価値に支払うか」です。登録数、試用から有料への転換率、Day 1/7/30の継続率、メール・アンケート・インタビューのフィードバック、課金データがあればMRR、LTV、CACも確認します。

技術コストは最も高くなります。Supabase Freeは2026年7月時点で、50,000 MAU、プロジェクトごとに500 MBのデータベース、1 GBのファイルストレージ、5 GBのegressを含みます。容量や可用性の要件が増えたら、Proまたは別のデータベースを検討します。高頻度利用と継続更新にはサブスクリプション、複雑な課題にはコンサルティングや運用サービス、単発需要にはPayment Linkで販売するデジタル商品が合う場合があります。SaaSはすべてのツールの到着点ではありません。継続価値と支払い意向が確認できてから移行します。

現在地を決める3層の判断表

感覚ではなく、ユーザー行動、技術コスト、検証目的、収益化経路を並べて判断します。

プロダクト層	ユーザー行動	技術コスト	検証するもの	主な収益化
コンテンツサイト	閲覧、検索、回遊	静的Pages（Cloudflare Free）	需要の存在	広告、アフィリエイト、デジタル商品
ツールサイト	入力、生成、コピー、ダウンロード	軽量動的処理/API（Workers Free/Paid）	ユーザーの操作	広告、会員機能、デジタル商品
SaaS/デジタル商品	登録、試用、支払い、継続	SaaS層（Supabase Free/Pro）	継続価値への支払い	サブスクリプション、コンサルティング

判断ルール：

1. コンテンツ指標が良い → ツールを追加して操作を検証します。GSCクエリに検索意図がありCTRも妥当なら、次はユーザーが動くかを見ます。

2. 再利用や保存の要望がある → ログインと履歴を検討します。同じツールを繰り返し使い、履歴保存を求めるなら継続需要の可能性があります。

3. 支払い意向が見える → デジタル商品やSaaSを検討します。料金、バッチ処理、有料機能の試用に関する質問は支払い意向を示します。

4. 初日から3層を作らない → シグナルに合わせて追加します。各層で検証に失敗する可能性があり、先回りした機能は保守コストを増やします。

広告収益はトラフィック品質、地域、ページ種別、同意取得、プラットフォームのポリシーで変わるため、共通の倍率では見積もれません。デジタル商品が自動的に継続収益になるわけでも、すべてのツールがサブスクリプションに向くわけでもありません。技術上限は2026年7月に公式ページで確認した値であり、実装前に再確認してください。

検証に使うシグナル

アクセスは訪問を示すだけです。シグナルを追うと、結果が必要とされているかが分かります。

コンテンツのシグナル：GSCとGA4

Google Search Consoleでは検索意図を確認します。「方法」「ツール」「チュートリアル」に相当するクエリは、解決策を探す意図を示します。業界をまたいで使えるCTRの共通基準はないため、相対変化を見ます。表示回数にも絶対的な最低値はなく、伸び方とクエリの質を重視します。

GA4では閲覧行動を見ます。エンゲージメント時間、スクロール深度、再訪率からコンテンツが読まれているかを判断できます。ただし、コンテンツページだけでは操作を検証できません。

推奨構成：GSC Performance Report + GA4 Engagement Metrics。

ツールのシグナル：GA4イベント

イベントの進み方を確認します。input、generate、copy、downloadの4つを追うと、どこで進み、どこで離脱したかが分かります。

シグナルが途切れた場合：

1. コンテンツにアクセスがあるのにツールのinput/generateが少ない → 記事からツールへの導線か、ツールの入口を改善します。

2. inputはあるのにgenerate/copyが少ない → 結果品質または表示方法が需要を満たしていない可能性があります。

推奨構成：GA4 Custom Events + gtag.jsまたはAstro Component。素のGA4イベント例：

gtag('event', 'input', {
  'event_category': 'tool_usage',
  'event_label': 'パラメータ入力'
});

gtag('event', 'generate', {
  'event_category': 'tool_usage',
  'event_label': '結果生成'
});

SaaSのシグナル：登録、継続、フィードバック

SaaSでは支払い意向と継続利用を確認します。登録数は絶対値ではなく相対的な伸びで判断します。試用から有料への転換率は市場によって異なります。Day 1/7/30の継続率は再利用を、メール、アンケート、インタビューは理由を示します。

支払い意向のシグナル：

1. 料金を質問される → 有料価値を期待されています。

2. バッチ処理や履歴保存を求められる → 継続利用の需要があります。

3. 新機能の試用を申し出る → 検証に時間を使う意思があります。

推奨構成：Supabase Auth + Analytics + Feedback Form。

業界や地域を無視した基準値に固定しないでください。ファネルの相対変化と具体的な要望を追います。シグナルが弱いときは、需要がないと決める前にコンテンツやツールを改善します。

収益化経路の比較

収益モデルは、プロダクト層、ユーザー行動、運用条件に合わせて選びます。

収益化	適した層	適したシグナル	利点	制約
広告	コンテンツ/ツール	高トラフィック。品質と地域の影響を受ける	導入しやすくユーザーシステムが不要	収益変動とポリシー依存
アフィリエイト	コンテンツ/ツール	ツール利用後の購買意図が明確	自社商品を作らなくてよい	第三者の商品品質に依存
デジタル商品/テンプレート	ツール/SaaS	単発需要。Payment Linkを利用可能	一度作って繰り返し販売できる	継続収益ではなく納品・返金も必要
SaaSサブスクリプション	SaaS	高頻度利用、継続更新、継続サービス	継続収益と権限の段階化	ユーザーシステムと継続保守が必要
コンサルティング/運用サービス	SaaS/ツール	完全なSaaS前の高価値で複雑な課題	システム完成前に高単価を検証	時間を使い、拡張しにくい

判断ルール：

1. 広告 → 高トラフィックのコンテンツや低頻度ツールに向きます。ページ種別、地域、広告需要、同意、プラットフォーム規則で変動するため、安定収益とはみなしません。

2. アフィリエイト → 明確な購入ステップがあるツールに向きます。自社開発は不要ですが、販売元の品質とコミッション規則に依存します。

3. デジタル商品 → 単発需要の検証に向きます。Stripe Payment Linksでテンプレート、レポート、設定パックを販売できます。同じ商品を繰り返し販売できますが、納品と返金の運用は残り、収益が自動的に継続するわけではありません。Payment Linkは支払いの入口であり、権限、納品、返金、サポートの代わりにはなりません。

4. SaaSサブスクリプション → 高頻度利用、継続更新、継続サービスに向きます。継続収益と段階的な権限を作れますが、ユーザーシステムと保守が必要です。継続的な支払い意向が出てから移行します。

5. コンサルティング → 完全なSaaSを作る前の複雑な課題に向きます。手動納品で高価値な課題を早く検証できますが、時間を消費し、拡張しにくい方法です。繰り返し作業を把握してからプロダクト化します。

唯一の正解はありません。無料入口でトラフィックを得て、利用の深さに合う収益化経路を提示できます。

技術コストの境界

技術コストはプロダクト層、ユーザー行動、トラフィック量で変わります。

技術スタック	Freeの境界（2026年7月）	有料の開始点または含有量（2026年7月）	適した層
Cloudflare Pages	月500ビルド、20,000ファイル、1アセット25 MiB	Proは月5,000ビルド、Businessは月20,000ビルド	コンテンツ/静的ツール
Cloudflare Workers	1日100,000リクエスト、1 invocationあたりCPU 10 ms	Standardは最低月額5ドル、月10Mリクエストと30M CPU msを含む	軽量動的処理/API
Supabase	50,000 MAU、500 MBデータベース、1 GB storage、5 GB egress	Proは100,000 MAU、8 GB disk、100 GB storage、250 GB egressを含む	SaaS

判断ルール：

1. Cloudflare Pages Free → 静的コンテンツや静的ツールに向きます。月500回のビルドは初期検証に十分な場合が多いものの、ファイル数とアセットサイズも確認します。

2. Cloudflare Workers Free → 軽量APIやブラウザ中心のツールに向きます。1日100,000リクエストだけでなく、invocationあたりのCPU時間も見ます。Standardは最低月額5ドルで、月10Mリクエストと30M CPU msを含み、超過分は別々に課金されます。

3. Supabase Free → 初期のユーザーシステムとデータベースに向きます。50,000 MAU、プロジェクトごとに500 MBのデータベース、1 GBのstorage、5 GBのegressは開始時の予算です。容量、可用性、サポート要件が増えたらProを検討します。

これらの上限は2026年7月に公式ページで確認した値で、今後変わる可能性があります。無料枠の中でしか成立しない中核機能は避けます。ユーザーと支払いが安定したら、利用量アラート、コスト表、縮退運転の方針を用意します。

シグナルを確認してから技術スタックを上げます。各層で失敗する可能性があり、早すぎる基盤投資は根拠より先に保守作業を増やします。

シグナルに合わせて1層ずつ進む

各層で検証に失敗する可能性があります。追加コストを正当化する根拠が出てから次へ進みます。

ステップ1：コンテンツで需要を検証する

シグナル：検索意図のあるGSCクエリと妥当なCTR。

ツール：GSC Performance Report + GA4 Engagement Metrics。

判断：需要が存在するか。「方法」「ツール」「チュートリアル」に相当するクエリは解決策を探す意図を示します。CTRは共通基準ではなく相対変化で見ます。

失敗した場合：意図が弱い、またはCTRが低いなら、課題そのものか検索時の約束がずれている可能性があります。需要を捨てる前にタイトルとdescriptionを改善します。

ステップ2：ツールで操作を検証する

シグナル：コンテンツで検索需要を確認できた。

ツール：GA4 Custom Events（input/generate/copy/download）。

判断：ユーザーが操作するか。inputとgenerateが進めば操作意向があり、copyとdownloadは出力が役立ったことを示します。

失敗した場合：input/generateが少なければ記事からの導線か入口を、copy/downloadが少なければ結果品質を改善します。

ステップ3：ログインと履歴を検討する

シグナル：再利用と保存の要望。

ツール：Supabase Auth + Analytics。

判断：継続利用が必要か。再訪と履歴保存の要望は継続価値を示します。

失敗した場合：ログインと履歴は追加しません。ユーザーが必要とするまでアカウントシステムを作らないようにします。

ステップ4：デジタル商品やSaaSを検討する

シグナル：料金の質問とバッチ処理の要望。

ツール：Stripe Payment Link / Products and Prices API。

判断：ユーザーが支払うか。料金、バッチ処理、有料機能の試用に関する質問はアクセス数より強い根拠です。

失敗した場合：デジタル商品やSaaSを延期し、価値の検証を続けます。

ステップ5：検証と改善を続ける

シグナル：登録、試用、支払い、継続。

ツール：Analytics + Feedback Form。

判断：継続価値が成立するか。登録の持続的な増加、試用から有料への転換、Day 1/7/30の継続率が次の投資を支えます。

失敗した場合：機能を増やす前にプロダクトまたは価格を見直します。

基本ルール：

1. シグナルが出てから層を追加します。各層で失敗する可能性があり、先回りした機能は保守コストを増やします。

2. 初日から3層を作りません。需要、操作、支払いの順に検証します。

3. 各段階の失敗を前提にします。コンテンツに検索需要がない、ツールが使われない、SaaSが支払われない可能性があります。基盤を増やしてもこのリスクは消えません。

次に読む記事

公開済みの記事で各層の実装を深掘りできます。

• Astroコンテンツサイトの構築と最適化：静的サイト構築、性能改善、デプロイの実践。
• Google Search Consoleのインデックス最適化：インデックスと検索パフォーマンスの診断。
• GA4イベント計測とコンバージョンファネル：ツール操作とコンバージョン経路の計測。
• AdSenseの複数サイト運用：コンテンツやツールの収益実験として広告を扱う方法。
• ミニゲームのプロダクト実験：低コストのプロダクトで操作と収益化を検証する方法。

シリーズの後続記事では、フロントエンド、バックエンド、デプロイ、データベース、決済、ユーザーシステム、分析、複数プロジェクトの組み合わせを扱います。まず自分のアイデアを「検索される課題」「操作できる行動」「課金できる権限」の3列に分け、各列に最小の検証指標を1つだけ置いてから次の層を判断してください。