Communityライティング&編集github.com

DQT-bit/ai-monetization-evaluator

AI製品や副業アイデアを5軸の需要評価ルーブリックでスコアリングし、具体的な検証ステップを提示するClaude/エージェント向けスキルです。

ai-monetization-evaluator とは?

このスキルは、AI製品や副業アイデアの市場需要を客観的に評価するためのルーブリックを提供します。「本当に儲かるのか?」という問いに対して、エンジニアリングの熱意ではなく需要の現実に基づいて判断します。Claude、Cursor、Codexなどの主要なAIエージェントプラットフォームで利用可能で、アイデアの検証から実行判断までを体系的にサポートします。5軸(需要硬度、ニッチ集中度、支払い意欲、流通経路、優位性)それぞれを0-2点で評価し、合計点に応じて「追求」「再調整」「撤退」の3つの判定を下します。さらに、最も弱い軸を特定し、最小限のコストで検証できる具体的なアクションステップを提示することで、開発リソースの無駄を防ぎます。特に「需要のない製品を作ってしまう」という最も高額なミスを回避することに重点を置いており、GPTラッパーやグレーゾーン事業などのアンチパターンも明示的に警告します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add DQT-bit/ai-monetization-evaluator

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

AI収益化評価ツール

「これを作ってお金を稼ぐべきか?」という判断を支援するツールです。固定ルーブリックを適用することで、回答が熱意ではなく需要の現実に基づくようにします。

bleedline/aimoneyhunter(中国語で人気のAI副業手法集)でカタログ化されたパターンから着想を得ています。このスキルは独自のルーブリックであり、その内容のコピーではありません。

使用タイミング

  • ユーザーが製品/サイドプロジェクト/SaaS/ブラウザ拡張機能のアイデアを提案し、それが売れるかどうか尋ねたとき
  • ユーザーが開発時間を投資する前にゴー/ノーゴーの判断を欲しているとき
  • ユーザーが複数の収益化の方向性から選択しようとしているとき
  • ユーザーが既に製品を作ったものの収益が上がらず、その理由を知りたいとき

核となる原則

儲かる製品のボトルネックは、ほぼコードではなく需要です。 失敗するAI製品のほとんどは技術的には問題ないが、誰もお金を払わない問題を解決しています。したがって、ビルドを褒める前に需要を評価すべきです。

毎回最初に問う、最も重要な質問:

「ユーザーは現在代わりに何をしていて、なぜその痛みはお金を払ってでも避けたいほどなのか?」

痛みのある現状(ステータスクオ)が存在しない場合、そのアイデアは「あると良い」ものであり、コンバージョンに苦労します。そのことを率直に伝えてください。

ルーブリック(各軸0~2点で評価)

各軸を正直にスコアリングします。合計点が高くても、"需要硬度"で正直に0点を取っている場合は不合格です。

#軸0(赤)1(黄)2(緑)
1需要硬度「あると良い」、無料の代替品が多数ある軽度の繰り返される悩み「それなしでは仕事ができない」/ 現在すでに実際の費用や時間がかかっている
2ニッチ集中度広範なプラットフォーム(「なんでもできるAI」)セミバーティカル明確な1人のユーザーに対する1つのシャープなユースケース
3支払い意欲ユーザーは無料を期待している不明瞭類似ツールがすでに課金しており、人々が支払っている
4流通経路「作れば来る」戦略未検証のチャネルが1つターゲットユーザーが既に集まっている具体的で到達可能なチャネル
5優位性誰でも週末でクローンできるわずかな優位性真の堀(スキル、アクセス、データ、オーディエンス、貴重なノウハウ)

採点ガイド:

  • 8~10 — 強い。追求するが、大規模ビルド前に実際のテストで支払い意思を検証すること。
  • 5~7 — 混合。最も低い軸を特定し、それを作り込む前に修正すること。通常は需要か流通。
  • 0~4 — 現状では弱い。ニッチ/需要を再調整するか、諦める。需要問題をエンジニアリングで解決しようとしないこと。

ワークフロー

  1. アイデアを一文で言い換える — 明確さを強制します。できない場合、アイデアが曖昧すぎて評価できないため、ユーザーに絞り込むよう依頼します。
  2. コア質問をする(現状 + 痛み)。スキップしないでください。これがすべての前提です。
  3. 5軸すべてをスコアリングする、各軸に1行の理由を添えて。懐疑的であること、応援団にならないこと。
  4. 最も弱い軸を特定する — それが本当のボトルネックです。
  5. 1~3の具体的な検証ステップを提示する、最も弱い軸を安価にテストするもの(ランディングページ、手動サービスのMVP、事前販売、ターゲットコミュニティでのアンケート)— 決して「全部作れ」ではありません。
  6. 判定: 追求 / 再調整 / 撤退、合計点と最初に修正すべきことを示します。

指摘すべきアンチパターン

  • 「何でもできるGPTラッパー」 → ニッチなし、堀なし。1つの垂直領域に絞るよう促す。
  • 需要検証前のビルド → 最も高額なミス。最小のテストで支払い意欲を検証すること。
  • 「リリースした」と「発見された」を混同 → アプリストアに載っていること ≠ ユーザーがいること。流通はビルドよりも難しい別の問題。
  • 勘による価格設定 → 価格が類似品と比較テストされていない場合、フラグを立てる。
  • グレーゾーン事業(APIキー/アカウントの転売、ToS違反の裁定取引)→ コンプライアンス/持続可能性リスクをフラグし、コアビジネスとして推奨しない。

出力形式

コンパクトに保つ:

アイデア(一行):…
現状と痛み:…

スコア:
  需要硬度       X/2 — …
  ニッチ集中度   X/2 — …
  支払い意欲     X/2 — …
  流通経路       X/2 — …
  優位性         X/2 — …
  合計:X/10

最も弱い軸:…
最初に検証:1)… 2)…
判定:追求 / 再調整 / 撤退 — [X]を最初に修正。

関連スキル