review-ai-automation

name	review-ai-automation
description	ai-automation skill で生成されたAI自動化ビジネスモデル10案を、実現可能性/収益性・マネタイズ/自動化レベル/競合優位性・モート/エンゲージメント・リテンション/リスク管理・スケーラビリティの6軸・100点満点で各案を採点し、総合ランキングとTOP3推奨を出す。別エージェントを起動してレビューする（自己レビューしない）。「AI自動化ビジネスモデルをレビューして」「10案をランキングして」等で使用。

/review-ai-automation — AI自動化ビジネスモデル レビュー（エージェント分離実行）

このスキルは別エージェントを起動してレビューを行う。現在のセッションでは直接レビューしない。 作成時の思考過程・設計判断・会話履歴をレビューエージェントに渡さないことで客観性を確保する。

対象: ai-automation skill で生成されたAI自動化ビジネスモデル10案 目的: 各ビジネスモデルを個別に評価し、最も有望な案を特定する。「実現可能性（技術的・無料枠内）」「収益性・マネタイズ」「自動化レベル」「競合優位性・モート」「エンゲージメント・リテンション」「リスク管理・スケーラビリティ」の6軸で各モデルを100点満点で採点し、総合ランキングとTOP3推奨を出力する。

---

実行手順

ステップ1: 情報収集（この実装セッションで行う）

以下の事実情報のみを収集する。作成の意図・設計判断の説明は含めない。

収集対象:
1. レビュー対象のビジネスモデル10案の全文
2. 以下の「レビュー前の必須確認事項」が文書から確認できるか
   - 10案すべてが出力されているか（`ai-automation` skill の指定通り10個生成されているか）
   - 前提条件が遵守されているか（初期投資0円・無料API/ツールのみ・週10時間・月収10万円目標）
   - 各案に必要な要素が含まれているか（ビジネスモデル名・自動化の仕組み・エンゲージメント設計・技術スタック・収益化方法・差別化・実装難易度・リスク・スケーラビリティの9セクション）
   - bashスクリプト完結の設計になっているか
   - Cloudflare無料枠の活用が設計されているか

上記が不十分な場合は、まず ai-automation skill での再生成を検討すること。

ステップ2: レビューエージェント起動

Agent ツールを使い、以下の設定で別エージェントを起動する:

Agent ツールの設定:
- subagent_type: "general-purpose"
- description: "Review AI automation business models objectively"
- prompt: 以下のテンプレートに収集した情報を埋め込む

プロンプトテンプレート（レビューエージェントに渡す内容）:

あなたは作成者とは別の客観的な事業開発の専門家です。
以下のAI自動化ビジネスモデル10案を、6項目・合計100点で個別に評価してください。

## 行動原則
`.claude/skills/_shared/review-rubrics.yaml` の `common_principles`（evidence_based / citation_required / non_destructive）を Read して適用すること。加えて本 skill 固有の原則として:
- 前提条件の遵守を最優先で確認すること: 初期投資0円・無料枠のみ・bashスクリプト完結・週10時間の前提を満たさないモデルは、内容がどれほど優れていても実現可能性の得点を大幅に減点すること

## レビュー対象文書（ビジネスモデル10案）
[ここに対象文書の全文を埋め込む]

## レビュー観点（6項目・合計100点）

### 1. 実現可能性（技術的・無料枠内） 【配点：20点】

> 目的：指定された無料ツール（Gemini API・Cloudflare等）の制限内で本当に実現できるか、技術的な妥当性と作業量の現実性を確認する。

- [ ] 使用するAPI（Gemini API・Hugging Face・Groq等）の無料枠の制限内で動作するか（リクエスト数・トークン数・日次上限）
- [ ] Cloudflareの無料枠の制限内で運用可能か（Workers 10万リクエスト/日、R2 10GB/月、D1 5GB、KV 10万読み取り/日）
- [ ] 技術スタック選定の妥当性があるか（Web開発・インフラ・Azure上級者のスキルセットとの整合性）
- [ ] bashスクリプトで完結する設計になっているか（wrangler CLI・curl・jq等の活用）
- [ ] 週10時間の作業量でMVPが構築可能か（初期構築フェーズ）
- [ ] 初期構築後に週2〜3時間のメンテナンスで運用可能か
- [ ] MVP完成までの期間が現実的か（提示された週数の妥当性）
- [ ] 必要な外部サービスの依存度が適切か（単一サービス障害で全体停止しないか）

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | 無料枠の制限を具体的な数値で検証しており、技術スタック・作業時間・bash完結すべてが現実的。依存リスクも分散されている |
| 14〜17 | おおむね実現可能だが、無料枠の制限検証が一部不十分、または作業時間の見積もりが楽観的 |
| 10〜13 | 技術的には可能だが、無料枠超過の可能性が高い、またはbash完結が困難な箇所がある |
| 0〜9  | 無料枠では実現困難、または技術的に非現実的な設計が含まれている |

### 2. 収益性・マネタイズ 【配点：20点】

> 目的：月収10万円の達成可能性を具体的な根拠とともに評価し、収益化戦略の現実性を確認する。

- [ ] 月収10万円の達成根拠が具体的か（必要PV数・顧客数・単価の逆算があるか）
- [ ] 収益化までのタイムラインが現実的か（2ヶ月目標との整合性）
- [ ] 価格設定の妥当性があるか（市場相場・ターゲットの支払い意欲との整合性）
- [ ] 複数収益源が設計されているか（アフィリエイト・広告・サブスクリプション・デジタル商品等の組み合わせ）
- [ ] LTV（顧客生涯価値）の見込みが示されているか
- [ ] CAC（顧客獲得コスト）が0円前提で現実的な獲得方法があるか
- [ ] 収益の季節性・変動リスクが考慮されているか
- [ ] 月収10万円達成後のスケール（月収30万・50万への道筋）が示されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 18〜20 | 月収10万円の逆算根拠が明確で、複数収益源・LTV・タイムラインすべてが現実的。スケール後の見通しもある |
| 14〜17 | 収益化の道筋は見えるが、根拠の一部が楽観的、または収益源が単一に依存している |
| 10〜13 | 月収10万円の達成根拠が薄い、またはタイムラインが非現実的 |
| 0〜9  | 収益化の見通しが不明確で、月収10万円の達成が極めて困難 |

### 3. 自動化レベル 【配点：15点】

> 目的：初期構築後の運用自動化率を評価し、「作った後は自動で回る」設計になっているかを確認する。

- [ ] 初期構築後の自動化率が具体的に示されているか（○%で表現）
- [ ] データ収集・コンテンツ生成・配信・収益化の各プロセスの自動化が設計されているか
- [ ] Cron Triggers / GitHub Actionsによる定期実行が適切に設計されているか
- [ ] エラー検知・自動リカバリの仕組みが含まれているか（自動リトライ・フォールバック機構）
- [ ] 人手介入が必要な箇所が明確に特定され、最小化されているか
- [ ] 通知システム（Discord webhook等）によるアラート設計があるか
- [ ] 無料APIのレート制限管理（日次上限の監視・自動スロットリング）が設計されているか
- [ ] 100%自動化への道筋が段階的に示されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 自動化率90%以上の設計で、エラーハンドリング・レート制限管理・通知まで含まれている。100%への道筋が明確 |
| 11〜13 | 自動化率70〜90%で、主要プロセスは自動化されているが、エラーハンドリングや監視の一部が不十分 |
| 7〜10 | 自動化率50〜70%で、手動対応が必要な箇所が多い、またはエラー対応の設計がない |
| 0〜6  | 自動化率50%未満で、実質的に手動運用が必要な設計 |

### 4. 競合優位性・モート 【配点：15点】

> 目的：ニッチ市場の選定理由と競合参入障壁の具体性を確認し、差別化の持続性を評価する。

- [ ] ニッチ市場の選定理由が明確か（なぜその市場を狙うのか）
- [ ] 競合サービス・代替手段が具体的に調査されているか
- [ ] 競合が参入しにくい理由が具体的に示されているか（技術的障壁・データ蓄積・先行者優位等）
- [ ] データ蓄積によるモートが設計されているか（使うほど精度・価値が向上する仕組み）
- [ ] ネットワーク効果によるモートがあるか（ユーザー増加に伴う価値向上）
- [ ] 差別化の持続性が分析されているか（競合が同じことをした場合の優位性）
- [ ] 競合の強みに対するカウンター戦略が具体的か
- [ ] 「なぜ今このビジネスなのか」という市場タイミングの説明があるか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | ニッチ選定・競合分析・モート設計・カウンター戦略すべてが具体的で、差別化の持続性が高い |
| 11〜13 | 競合優位性はあるが、モート設計やカウンター戦略の一部が不十分 |
| 7〜10 | 差別化の主張はあるが具体性に欠け、競合参入時に優位性が失われるリスクが高い |
| 0〜6  | 差別化要因がほぼなく、レッドオーシャンに参入する設計 |

### 5. エンゲージメント・リテンション 【配点：15点】

> 目的：ユーザーが継続利用する仕組みが設計されているかを確認する。自動化ビジネスにおいても、ユーザーが離脱しにくい構造を持っているかを評価する。

習慣ループ・行動設計チェック:
- [ ] トリガー設計（外的：通知・メール・RSS / 内的：習慣・情報ニーズ）が定義されているか
- [ ] 報酬設計（変動報酬：新しい発見・達成感・コスト削減・時間短縮等）が具体的か
- [ ] 投資設計（ユーザーがサービスに蓄積する価値：設定・履歴・カスタマイズ・データ）が含まれているか

リテンション・離脱防止チェック:
- [ ] ネットワーク効果（ユーザー増加に伴う価値向上）の仕組みがあるか
- [ ] スイッチングコスト（データ蓄積・カスタマイズ・エコシステム統合等）が設計されているか
- [ ] リテンション指標（DAU/MAU・継続率・チャーン率）の目標が設定されているか
- [ ] ユーザーライフサイクル別のエンゲージメント施策が設計されているか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 習慣ループ・報酬設計・ネットワーク効果・リテンション指標がすべて設計されている |
| 11〜13 | おおむね設計されているが、報酬設計やリテンション指標の一部が不十分 |
| 7〜10 | エンゲージメント設計が表面的で、具体的な仕組みや指標が欠けている |
| 0〜6  | エンゲージメント・リテンション設計がほぼなく、ユーザーが継続利用する仕組みが不明 |

### 6. リスク管理・スケーラビリティ 【配点：15点】

> 目的：主要リスクの特定と対策、およびビジネス成長時のスケール戦略が適切に設計されているかを確認する。

リスク管理チェック:
- [ ] 主要リスク（API廃止・無料枠縮小・規約変更・プラットフォーム依存・技術的障害等）が列挙されているか
- [ ] 各リスクに対する具体的な対策・緩和策が示されているか
- [ ] プラットフォーム規約への準拠が確認されているか（API利用規約・アフィリエイト規約等）
- [ ] 無料枠超過時の対応計画が策定されているか（有料プランへの移行判断基準・コスト試算）
- [ ] 自動化によるエラー時の検知と対処が設計されているか

スケーラビリティチェック:
- [ ] スケール時の移行パスが示されているか（無料枠→有料プラン→独自インフラ等）
- [ ] 水平スケール（同モデルの複数展開）の可能性が検討されているか
- [ ] 垂直スケール（上位プラン・機能拡張・有料化）の計画があるか
- [ ] スケール時に自動化率が低下しない設計になっているか

採点目安:
| 点数 | 基準 |
|------|------|
| 14〜15 | 主要リスクと対策が網羅的で、規約準拠・無料枠超過対応・スケール移行パスすべてが具体的 |
| 11〜13 | リスク管理とスケール計画はあるが、対策の一部が抽象的、またはスケール時の自動化維持が不十分 |
| 7〜10 | リスク列挙はあるが対策が曖昧、またはスケーラビリティの検討が不十分 |
| 0〜6  | リスク管理・スケーラビリティの検討がほぼなく、持続的な運用が困難 |

## 採点方法（各モデル：100点満点）

`.claude/skills/_shared/review-rubrics.yaml` を Read し、`verdict_scales.rank5_100` の bands/meaning に従って S/A/B/C/D を判定すること（点数帯・各段階の対応方針は同ファイルが SoT）。

## 出力（レビュー結果出力フォーマット）

### Part 1: 個別モデル採点（10案すべてに対して繰り返す）

```markdown
---

## モデル [番号]: [ビジネスモデル名]

### 概要
（1〜2行で要約）

### 観点別採点

| # | 観点 | 配点 | 得点 | 主なコメント |
|---|------|------|------|-------------|
| 1 | 実現可能性（技術的・無料枠内） | 20 | | |
| 2 | 収益性・マネタイズ | 20 | | |
| 3 | 自動化レベル | 15 | | |
| 4 | 競合優位性・モート | 15 | | |
| 5 | エンゲージメント・リテンション | 15 | | |
| 6 | リスク管理・スケーラビリティ | 15 | | |
| **合計** | | **100** | **XX** | |

### 判定：X（S/A/B/C/D）

### 良かった点（Keep）
-

### 改善提案（Problem / Try）
-

### 重要チェック項目

| 項目 | 記載 | コメント |
|------|------|----------|
| 無料枠の制限内での動作 | ✅ / ❌ | |
| 月収10万円の逆算根拠 | ✅ / ❌ | |
| bash完結設計 | ✅ / ❌ | |
| エラーハンドリング設計 | ✅ / ❌ | |
| エンゲージメント設計 | ✅ / ❌ | |
| 競合優位性・モート | ✅ / ❌ | |
| スケーラビリティ | ✅ / ❌ | |

---

Part 2: 総合ランキング

---

## 総合ランキング

| 順位 | モデル名 | 総合点 | 判定 | 実現可能性 | 収益性 | 自動化 | 競合優位性 | エンゲージメント | リスク管理 | 特記事項 |
|------|----------|--------|------|-----------|--------|--------|-----------|----------------|-----------|----------|
| 1 | | /100 | | /20 | /20 | /15 | /15 | /15 | /15 | |
| ... | | | | | | | | | | |

---

## TOP3 推奨と理由

### 第1位：[モデル名]（XX点）
- **推奨理由：**
- **実装開始時の最初のステップ：**
- **最大のリスクと対処法：**

### 第2位：[モデル名]（XX点）
### 第3位：[モデル名]（XX点）

---

## 組み合わせ提案

（TOP3の中から2つ以上を組み合わせてシナジーを生む戦略があれば提案する）

---

## 次のアクション推奨

（S/A判定のモデルがある場合）→ 即座にMVP構築を開始。`ai-automation` skill の技術スタックに基づきbashスクリプトの設計から着手する
（B判定のモデルがある場合）→ 改善提案を反映し、再度 `ai-automation` skill で該当モデルの詳細を再生成してから再レビュー
（C/D判定のみの場合）→ `ai-automation` skill のプロンプト条件を見直して再生成を推奨

---

## 補足コメント

### ステップ3: 結果の報告

レビューエージェントから返却された結果を、そのままユーザーに表示する。
要約や解釈を加えない（レビューの客観性を維持するため）。

---

## 注意事項

- **絶対に実装セッション内で直接レビューしない**。必ず Agent ツールで別エージェントを起動すること
- レビュワーは元ファイルを絶対に編集してはならない。改善点は具体的に指摘し、修正案は「提案」として記載する
- 前提条件（初期投資0円・無料枠のみ・bashスクリプト完結・週10時間）の遵守を最優先で確認すること

## 参照ドキュメント

- 元プロンプト（詳細確認用）: `workflows/business-planning/ideas/review-ai-automation.md`
- 前ステップ（ビジネスモデル生成）: `ai-automation` skill