🛠️ 開発・MCP コミュニティ

micro-saas-scoper

検証済みのビジネスアイデアがソフトウェア化に適しているか判断し、製品範囲を明確化、手作業と自動化の境界線を定めることで、安易なソフトウェア開発を防ぎ、マイクロSaaSとしての成功可能性を高めるSkill。

📜 元の英語説明(参考)

Decides whether a validated wedge should become software, defines the narrow product wedge, and separates what stays manual versus automated. Use when a service, workflow, or audience-driven opportunity may be ready for micro-SaaS scoping or when a user is tempted to build software too early.

🇯🇵 日本人クリエイター向け解説

一言でいうと

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux

mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o micro-saas-scoper.zip https://jpskill.com/download/9130.zip && unzip -o micro-saas-scoper.zip && rm micro-saas-scoper.zip

🪟 Windows (PowerShell)

$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9130.zip -OutFile "$d\micro-saas-scoper.zip"; Expand-Archive "$d\micro-saas-scoper.zip" -DestinationPath $d -Force; ri "$d\micro-saas-scoper.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)

1. 下の青いボタンを押して micro-saas-scoper.zip をダウンロード
2. ZIPファイルをダブルクリックで解凍 → micro-saas-scoper フォルダができる
3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
4. Claude Code を再起動

⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-18
取得日時: 2026-05-18
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Micro-SaaS Scoper

概要

このスキルは、ある楔（くさび）を今すぐソフトウェア化すべきか、後回しにすべきか、あるいは全くすべきでないかを判断します。その目的は、時期尚早な製品開発を防ぎ、ソフトウェア化が正当化される場合に、狭い範囲の MVP を強制することです。

準備状況を判断する際には references/productization-signals.md を読み込みます。スコープを絞り込む際には references/mvp-boundaries.md を読み込みます。

活用場面

サービスやワークフローが製品化の準備段階にある可能性がある場合
ユーザーが micro-SaaS を必要としており、製品の楔を定義する必要がある場合
手作業による提供と自動化の間に緊張関係がある場合

以下の場合には使用しないでください:

機会そのものがまだ不明な場合
スコープを定めるべき証拠や楔がまだない場合

ワークフロー

1. 準備状況の判断

以下の中から一つを出力します。

build_now
stay_manual_for_now
conditional_build

これらの正確な値を文章と JSON で使用してください。

検証の証拠、買い手へのアクセス、反復、および実装リスクに基づいて正当化します。

2. 製品の楔の定義

ソフトウェア化が正当化される場合は、以下を定義します。

1 つの狭いジョブ
1 人の主要ユーザー
1 つのコアワークフロー
1 つの製品化トリガー

最初のソフトウェアのスライスでは、自動化の楔を 1 つだけ選択してください。プロンプトがチェーン全体がすでに標準化されているという非常に強力な証拠を示さない限り、v1 で複数の隣接するファネルステージを自動化しないでください。

3. 手作業と自動化された作業の分離

以下を明確に記述します。

手作業のまま残るもの
最初に自動化されるもの
まだ構築しないもの

コンテキストがサポートしている場合は、手作業、自動化、および未着手のリストに少なくとも 3 つの項目を入れることを目指します。

判定が stay_manual_for_now または conditional_build の場合は、後で判定を覆す 3 つの異なるゲーティングシグナルをリストします。各ゲーティングシグナルは、1 つの複合文ではなく、個別の箇条書きにする必要があります。

4. スコープの作成

以下を両方返します。

読みやすい製品スコープ
assets/micro-saas-scope-template.json を使用した JSON ブロック

テンプレートのフィールド名を正確に使用してください。

デフォルトのセクション:

Readiness Verdict
Product Wedge
Manual vs Automated
MVP Boundary
Do Not Build Yet
Structured Scope

チェックリスト

[ ] 準備状況の判定が明示的である
[ ] 楔は、1 つのジョブ、1 人のユーザー、1 つのワークフローである
[ ] 手作業部分と自動化部分が明確に分離されている
[ ] MVP の境界線が、ユーザーの最初の直感よりも狭い
[ ] 読みやすいスコープと構造化された JSON の両方が存在する

主要な原則

ソフトウェアは獲得されなければならない — 検証の証拠は製品の好みに勝る。
最初に 1 つのジョブ — 狭いワークフローソフトウェアは、広範なプラットフォームの野心に勝る。
必要に応じて一部の作業を手動で維持する — ヒューマンインザループは、多くの場合、適切な中間ステップです。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Micro-SaaS Scoper

Overview

This skill decides whether a wedge should become software now, later, or not at all. The goal is to protect against premature product building and to force a narrow MVP when software is justified.

Load references/productization-signals.md when deciding readiness. Load references/mvp-boundaries.md when narrowing the scope.

When to use

When a service or workflow may be ready to productize
When a user wants a micro-SaaS and needs the product wedge defined
When there is tension between manual delivery and automation

Do NOT use when:

The opportunity itself is still unknown
There is no evidence or wedge to scope yet

Workflow

1. Decide readiness

Output one of:

build_now
stay_manual_for_now
conditional_build

Use those exact values in prose and JSON.

Justify with validation evidence, buyer access, repetition, and implementation risk.

2. Define the product wedge

If software is justified, define:

one narrow job
one primary user
one core workflow
one productization trigger

For the first software slice, choose only one automation wedge. Do not automate multiple adjacent funnel stages in v1 unless the prompt gives unusually strong evidence that the whole chain is already standardized.

3. Separate manual from automated work

State clearly:

what remains manual
what gets automated first
what not to build yet

Aim for at least 3 items in the manual, automated, and not-yet lists when the context supports it.

If the verdict is stay_manual_for_now or conditional_build, list 3 distinct gating signals that would flip the verdict later. Each gating signal should be a separate bullet, not one compound sentence.

4. Produce the scope

Return both:

a readable product scope
a JSON block using assets/micro-saas-scope-template.json

Use the template field names exactly.

Default sections:

Readiness Verdict
Product Wedge
Manual vs Automated
MVP Boundary
Do Not Build Yet
Structured Scope

Checklist

[ ] A readiness verdict is explicit
[ ] The wedge is one job, one user, one workflow
[ ] Manual and automated parts are clearly separated
[ ] The MVP boundary is narrower than the user's first instinct
[ ] Readable scope and structured JSON are both present

Key principles

Software must be earned — Validation evidence beats product preference.
One job first — Narrow workflow software beats broad platform ambition.
Keep some work manual if needed — Human-in-the-loop is often the right intermediate step.