有料記事9本でsales=0。原因は「PVが足りない」ではなかった
この記事で答えること
有料記事を出したけど全然売れない。もっとPVを増やせばいつか売れるか？
そう思っていた。でも掘ってみたら、問題はPVより先にあった。
2026年4月にmasatoman.netを立ち上げてから約1ヶ月。有料記事9本（¥500〜¥800）を公開したが、30日間のsales=0だった。9本合計のPVは21。Stripe webhookの失敗が14件たまっていた。そしてその期間、誰も有料コンテンツを購入できる状態ではなかった。
この記事でわかること:
- 有料記事のsales=0が「流入不足」なのか「設計ミス」なのかを自分のケースで判断できる
- 価格を並列に並べることがなぜ売上を殺すか理解できる
- 公開前に確認すべき3つのこと（今日すぐ確認できる）
結論
有料記事が売れない原因は「PVが足りない」ではなく、3つの設計ミスだった。
- 購入インフラが30日間壊れていた — magic linkログインがlaunch以来機能しておらず、誰も有料コンテンツにたどり着けなかった
- ¥500〜¥800の9本並列はアンカリングを殺す — 読者は「どれを買えばいいか」判断できないまま離脱する
- タイトルに自分が達成していない成果を書いていた — 「売れるSaaS開発フロー」¥800を、販売実績0件のまま売っていた
3つ全部直してから、はじめてPVの話になる。
実際にやったこと——9本を出すまでの流れ
2026年4月頭にmasatoman.netを立ち上げてから約1ヶ月、Claude Codeを使って記事を量産した。
最初から収益化を意識して、有料記事をシリーズ化した。「Lab」というシリーズ名でClaude Codeの使い方をep01〜ep12まで書き、うち7本を有料化（¥800）。さらに個別の有料記事を2本追加して計9本。
「これだけ本数があれば、どれかは売れるだろう」と思っていた。
実際には何もしなかったわけじゃない。X自動投稿も60本回した。タイトルも直した。CTAも追加した。でも数字は動かなかった。
読者が同じ状況なら
- 見るべき数字：有料記事ページに「購入する」ボタンが実際にクリックできる状態か（シークレットウィンドウで確認）
- 判断基準：有料記事を出す前に「購入完了まで自分でテストしたか」が先決
- 次にやること：今すぐシークレットウィンドウで自分の有料記事を開き、購入ボタンまでたどり着けるか確認する
出た数字——9本合計で21PV/30日/sales=0
有料記事9本の30日間の実数字：
| 指標 | 数字 |
|---|---|
| 9本合計PV（30日） | 21 |
| 全ソースconversion | 0件 |
| GSC検索流入（9本中） | 0本 |
| Stripe webhook失敗 | 14件 |
| X自動投稿60本の平均views | 14.3 |
| X自動投稿60本のsales | 0 |
唯一読まれていたのは #7「first-sale-playbook」1本のみ、3PV/平均572秒。1人が完読した。
「月80本以上公開してここか」というのが正直な感想だった。でも掘り始めたら、数字の前に別の問題があった。
読者が同じ状況なら
- 見るべき数字：有料記事のGSC検索流入（0件なら検索に引っかかっていない＝PVより先の問題がある）
- 判断基準：GSC流入0件＋PV 21以下なら、タイトル/価格より先に「見つかる状態になっているか」を確認する
- 次にやること：GSCで自分の有料記事スラッグを検索して表示回数を確認する
当初の想定
「書き続ければいつかSEO流入が来る、その時に有料記事が刺さる」という仮説で動いていた。
Claude Codeで記事を量産できるようになった結果、「書く」に時間を使いすぎて「設計する」「動作確認する」が疎かになった。AIで作る速度は10倍になったが、検証する速度は1倍のままだった。価格の¥500〜¥800も「安ければ買いやすい」という根拠のない思い込みで決めた。
想定と違ったこと——3つの設計ミス
ミス1：購入インフラが30日間壊れていた
有料記事販売を始めてから約30日後、「サブスクが実際に動くか確認しよう」としてログインを試みた。
magic linkで送られてくるメールのリンクをクリックすると、トップページに戻された。何度やっても同じ。
launch以来ずっと、誰もログインできていなかった。
つまり有料コンテンツのペイウォールにたどり着いた人間は0人。PVが21件あったとしても、そのうち有料部分を見られた人は0人だった。
並行してStripe webhookの失敗ログが14件たまっていた。naked URLへのPOSTがwww付きURLに301リダイレクトされ、Stripeは追わない仕様なので、決済通知が全部消えていた。
収益化インフラが二重で機能していなかった。
ミス2：9本並列はアンカリングを殺す
修正ついでに「9本の有料記事の中で、自分が今日¥1,000払うのはどれか」と自問した。
即答で「1番だけ」と答えた。
残り8本は自分でも買わない。なのに「誰かが買ってくれるはず」と思って並べていた。
9本を¥500〜¥800で並べた場合、読者の視点では「どれを買えばいいかわからない」状態になる。比較軸がない9本並列は「無限に迷える棚」であって、購入を促す設計じゃない。
The Economistは雑誌を「デジタル版¥1,000」「印刷版¥1,000」「印刷+デジタル版¥1,000」の3択で売る。3択を並べることで「印刷+デジタルがお得」に見えて、売りたい商品が売れる。
これを参考に設計を変えた：
| 商品 | 価格 |
|---|---|
| 有料記事A | ¥1,000 |
| 有料記事B | ¥1,000 |
| 読み放題サブスク | ¥1,000/月（AもBも読める） |
「2本以上読みたいならサブスクが確定でお得」という比較軸が生まれた。
ミス3：タイトルが自分を裏切っていた
既存9本のタイトルを再点検すると、ep06に「売れるSaaS開発フロー」という有料記事があった。価格¥800。
当時のmasatoman.netのPremium会員数：0人。有料記事販売数：0件。
販売実績ゼロの人間が「売れる」を売っていた。
技術的に詳しい読者は、著者プロフィールを見れば実績がないことに気づく。「売れる」というタイトルと実績の矛盾は、信頼を削る。
タイトルを「1週間で組む開発フロー」に変更した。記事内容は同じ。descriptionに「『売れるかどうか』は別途検証が必要」と明記した。
読者が同じ状況なら
- 見るべき数字：有料記事タイトルに「売れる」「稼げる」「確実に」などの成果訴求が入っているか
- 判断基準：自分がまだ達成していない成果をタイトルに使っていたら、そのタイトルは信頼を削っている
- 次にやること：既存有料記事のタイトルを「自分が今日これを読んで達成できるか」で再評価する
なぜ3つの設計ミスが同時に起きたのか
共通する原因は「書く速度と設計の速度がずれていた」こと。
magic linkのバグは、1回シークレットウィンドウでログインテストをすれば即日発見できた。Stripe webhookも、テスト環境で1回決済を通せば気づいた。どちらも5分で終わる確認だった。30日間やらなかった。
9本並列の問題も「自分が買いたいのはどれか」と1度問えばすぐわかった。タイトルの矛盾も「自分はこの成果を達成したか」と1度問えば気づいた。
AIで量産速度が上がると、この罠に入りやすい。 書くコストが下がった分、「出す前に1回買い手の立場を取る」コストが相対的に上がって見える。でも実際には5分でできる確認を、30日間飛ばした。
読者が同じ状況なら
- 見るべき数字：有料記事を出してから「シークレットウィンドウで購入テストをした回数」
- 判断基準：0回なら、PVやCTAより先に動作確認が優先
- 次にやること：今すぐシークレットウィンドウで自分の有料記事を開き、購入完了まで通してテストする
DeepSearchで見えた、他の人も詰まっているポイント
同じパターンで詰まっている人は多い。
「有料note 21本で累計購入0」を公開している書き手がいる。その人はAI開発歴もCTO経験もあった。でも売れなかった。本人の分析は「AIで量産すること自体が差別化にならなくなった、汎用的なテーマ・ありふれた構成・一次経験の埋め込み不足」だった。
フォロワーがほぼいない状態で¥500の有料記事を出して「PV16/スキ0/購入0」だった事例もある。本人いわく「内容が悪いというより、読者がいない」。
面白いのは、値下げしても解決しなかった事例だ。¥700の技術本を一時¥300に値下げしたが「たいして売上に影響があったようには思えなかった」と著者が書いている。問題は価格じゃなかった。
共通点は「発見してもらえる状態になっていなかった」か「買う文脈で読まれていなかった」。安くしても、インフラが壊れていても、タイトルが矛盾していても、数字は動かない。
自分の判断をどう変えたか
| Before | After | |
|---|---|---|
| 記事数 | 9本 | 2本 |
| 価格 | ¥500〜¥800 | ¥1,000×2本 + 月額¥1,000サブスク |
| 設計 | 並列販売 | アンカリング3択 |
| 出し方 | 書いたら出す | 出す前に購入テスト |
具体的な変更：
有料記事を9本→2本に絞った 「自分が今日¥1,000払う」基準で選んだ2本を残した。残り7本はGSC実績ゼロを確認した上で無料化した。
価格設計にアンカリングを入れた 有料記事A（¥1,000）・有料記事B（¥1,000）・月額サブスク（¥1,000）の3択。「2本以上読むならサブスクが確実にお得」という比較軸を作った。
「売れる」「稼げる」をタイトルから消した 自分が達成していない成果はタイトルに書かない。代わりに「何をやったか」「何がわかったか」を書く。
購入テストを先に通すルールにした 有料記事を出す前にシークレットウィンドウで購入完了まで確認する。Stripe webhookのイベントが届いているかテスト環境で確認する。
同じ状況ならどう判断すべきか
有料記事を出してsales=0が続いているなら、以下の順番で確認する。PVの話はその後でいい。
Step 1：購入できる状態になっているか（今すぐ確認）
- シークレットウィンドウで自分の有料記事を開く
- 「購入する」ボタンまでたどり着けるか
- ログインが必要なら、ログインから購入完了まで通してテストする
- Stripe webhookのイベントがテストで届くか確認する
Step 2：自分が買いたい記事はどれか（1分で答える）
- 「今日¥1,000払うのはどれか」と自問する
- 即答できない、または「全部微妙」なら、まず商品選定から見直す
Step 3：タイトルに嘘がないか（1本ずつ確認）
- 「自分がまだ達成していない成果」をタイトルで約束していないか
- 「売れる」「稼げる」「確実に」が入っている場合、実績の裏付けはあるか
Step 4：価格に比較軸があるか（設計の問題）
- 同じ価格帯が複数並んでいるか、「こっちがお得」という軸があるか
- 比較軸がない並列は「どれを買えばいいかわからない」につながる
Step 1〜4が全部OKになってからGSC流入やPVの話に進む。
公開前チェックリスト（自分向け）
- シークレットウィンドウで購入完了まで通してテストした
- Stripe webhookがテスト環境で届くことを確認した
- 「自分が今日¥1,000払うか」に即答できた
- タイトルに自分が達成していない成果が入っていない
- 他の商品と比較できるアンカリング設計になっている
- 無料記事で「それ俺だ」を作ってから有料記事へ誘導している
次にやること
この記事を読んで「似たような状況かも」と思ったなら：
- 今すぐ：シークレットウィンドウで自分の有料記事を開いて購入テストをする
- 今日中：既存有料記事を「自分が今日払うか」で再評価して、払わないものをリストアップする
- 今週中：価格設計にアンカリングがあるか確認して、なければ3択設計を検討する
個人開発の初売上を出すまでの全記録
Stripe自前ペイウォールの実装から初回購入者が出るまで。有料記事の購入インフラをゼロから作る手順書。
Claude Crew Lab Free — 毎月の実験記録をメールで
Claude Code × 個人開発のリアルな事故・発見・SaaS アイデアを毎月第1月曜にお届け。登録で「収益化チェックリスト 15 項目」を無料プレゼント。
個人開発の実験ログを月1回、無料で
失敗 / 実数字 / 仮説 / 次に試すこと。売れた話だけでなく売れなかった理由も共有します。
この記事が役に立ったらシェア