AIエージェントに事業検証させたら「やめろ」と言われた話
「セキュリティ情報のAIキュレーションSaaS」を作ろうとした。パイプラインは動いていた。技術的にはほぼ完成していた。
しかし、事業仮説の検証をAIエージェントに任せてみたら、**「このサービスは作るべきではない」**という結論が出た。コードを1行も追加する前に、1日で。
この記事は、AIエージェントにビジネス検証を委譲して学んだ「やるべきでないことを早く見つける方法」の記録だ。
作ろうとしたもの
Curatiq — セキュリティ情報の自動キュレーションSaaS。30本以上のRSSフィードからClaude APIでニュースを選別・日本語要約し、毎朝メールで届ける月額課金サービス。
パイプライン（RSS収集→AI選別→要約→配信）はすでに別プロジェクトで動作実証済み。これを汎用化してSaaSにする、という企画だった。
価格設計も作った。個人プラン月額2,980円、チームプラン月額9,800円。損益分岐点は5ユーザー、初期投資5,000円。数字だけ見ると筋が良さそうに見えた。
エージェントに検証を任せる
Claude Codeのエージェント機能を使って、事業検証を自動化した。ユーザー（自分）がentrepreneur（事業戦略）エージェントに「Curatiqの事業仮説を検証してほしい」と依頼すると、entrepreneurは配下のエージェントに調査を振り分ける。
entrepreneur（事業戦略）
├→ ペルソナ調査
├→ 競合分析
├→ コスト分析
└→ 法的リスク確認
これらが並列に動き、結果がentrepreneurに集約される。entrepreneurはそれを踏まえて仮説の継続・ピボット・棄却を判断する。
当初のターゲットは**「情シス（情報システム部門）担当者・CSIRT（セキュリティ専門チーム）担当者」**だった。
検証1: ターゲットを掘ったら全部崩れた
ペルソナ調査の結果、「情シス担当者」が一枚岩ではないことがわかった。
企業のIT管理には大きく2種類の担当者がいる。専任（IT部門が本業）と兼任（総務や経理が本業で、ITを兼務している人）だ。この違いが決定的だった。
| ターゲット | 技術力 | 自力で代替できるか | 課金意欲 | 判定 |
|---|---|---|---|---|
| 専任情シス・CSIRT | 高い | できる（自分でRSSを設定） | 低い | 脱落 |
| セキュリティコンサル | 高い | できる（Feedly等で十分） | 低い | 脱落 |
| 兼任情シス（総務・経理が兼務） | 低い | できない（RSSを知らない） | 会社経費OK | 有望 |
| SIerエンジニア | 中〜高 | 一部できる | 法人OK | 次点 |
当初ターゲットの「専任情シス」は、技術力が高いからこそ無料で同じことができた。 RSSリーダーの設定ができる人に、RSSリーダーの代替サービスを売ろうとしていた。
ここで最初の教訓が生まれた。技術者向けサービスの最大の競合は、競合サービスではなく「自分でやる」だ。
唯一有望だったのは「兼任情シス」——総務や経理が本業で、IT担当を兼務している人たち。推定10〜15万人。RSSの設定方法を知らないからこそ、このサービスに価値がある。
検証2: ターゲットを変えた。しかしリーチできない
entrepreneurはピボットを判断した。ターゲットを「兼任情シス」に変更し、チームプラン（月額9,800円、会社経費で購入）を主力に切り替えた。
数字は改善した。12ヶ月の標準シナリオで累計利益250万円。悪くない。
しかし、並行して走っていた競合分析の結果が上がってきた。
競合は「無料」と「何もしない」
Curatiqの個人プランは月額2,980円。一方、Feedly Pro+は月約2,000円で似た機能がある。
ただし本当の競合はFeedlyではなかった。**兼任情シスにとっての選択肢は「Curatiq vs Feedly」ではなく、「Curatiq vs 今まで通り何もしない」**だった。
IPAやJPCERT/CC（国の公的機関）のメーリングリストは無料で届く。読んでいなくても登録はしている。「一応やってる感」がある状態で、月1万円を払う動機が生まれるのか。
届ける方法がない
さらに致命的な問題が見つかった。有望なターゲットを見つけたが、そのターゲットにサービスの存在を知ってもらう方法がない。
| チャネル | 兼任情シスに届くか | 問題 |
|---|---|---|
| Zenn/Qiita記事 | 届かない | 技術者向けメディア。兼任情シスは読まない |
| Google検索（SEO） | いずれ届く | 効果が出るまで3〜6ヶ月かかる |
| 商工会議所セミナー | 届く可能性あり | リードタイムが長い。コネクション必要 |
| SNS（X） | 届かない | そもそも兼任情シスはXを見ない |
「いいプロダクトを作れば売れる」は幻想だった。 プロダクト以前に、ターゲットにリーチする手段がなければ事業は成立しない。
検証3: サービスの形を変えたら？
リーチの問題は即座には解決しない。ではサービス自体の価値を上げて、口コミで広がるようにできないか。
entrepreneurは「ニュース要約」から「対策チェックリスト配信」へのモデル転換を検討した。
毎週月曜に「今週やるべきセキュリティ対策トップ3」が届く。専門知識不要。
これなら兼任情シスの本音——「うちに関係あるか」「何をすればいいか」——に直接応えられる。
しかし、モデルを変えると新しい問題が出た。
- 責任の所在: 「ニュース要約」なら「原文を確認してください」で済むが、「Chromeをアップデートしてください」は行動指示だ。その指示が間違っていた場合、責任が生じる
- 環境依存: 「今週やるべきこと」はターゲット企業の環境（使っているソフト、ネットワーク構成等）によって異なる。汎用的な配信では「うちには関係ない」対策が混じる
- スケーラビリティ: 環境を個別にヒアリングすると工数が爆発する
ニュース要約型では価値が弱く、対策指示型では責任とスケーラビリティの壁にぶつかる。どちらに振っても突破口がなかった。
撤退判断
ここまでの検証結果を整理した。
| 問題 | 深刻度 | 解決の見込み |
|---|---|---|
| 専任情シスには無料で代替できる | 致命的 | ピボット済み（兼任情シスへ） |
| 兼任情シスにリーチするチャネルがない | 致命的 | 即効性のある解決策なし |
| ニュース要約は「何もしない」と競合する | 高 | サービス転換で対処可能だが新リスク |
| 対策指示型は責任・スケーラビリティの問題 | 高 | 解決コスト大 |
リーチ手段がないターゲットに、責任問題のあるサービスを、3〜6ヶ月かけてSEOで届ける。 これは「技術的に作れるか」の問題ではなく、「作るべきか」の問題だった。
entrepreneurエージェントの最終判断: アーカイブ（積極開発停止）。
なぜ1日で検証できたのか
3つの理由がある。
1. エージェントが並列に動く
entrepreneurが仮説を立てている間に、ペルソナ調査・競合分析・コスト分析・法的リスク確認が同時に走る。人間が1人で順番にやれば数週間かかる作業が、数時間で完了する。
2. 仮説を形式化するフォーマットがあった
各仮説はカードに記録される。カードには以下が必須:
- 仮説ステートメント（何を信じているか）
- 検証基準（何が起きたら成功/失敗か）
- コスト・ROI分析
- メリット・デメリット
- 判断（継続/改善/ピボット/棄却）
このフォーマットがあるから、エージェントは「次に何を調べるべきか」を自律的に判断できる。フォーマットがなければ、「とりあえず調べてみました」という散漫なレポートが返ってくるだけだ。
3. 撤退基準を事前に決めていた
「Go/No-Go基準」をビジネスプランに含めていた。たとえば「2ヶ月終了時点でチームプラン3社未満ならNo-Go」。感情的に「もう少しやれば」と思いたくなるところを、事前に決めた数字で判断できる。
今回は検証段階で「リーチ手段がない」という致命的な問題が見つかったため、Go/No-Go基準に到達する前にアーカイブを判断した。
5つの教訓
この検証プロセスから、今後の事業企画で最初に確認すべきチェックリストが生まれた。
1. ペルソナは「技術レベル × 代替手段」で切る
「情シス担当者」は粗すぎる。同じ「情シス」でも、専任と兼任では技術力が違い、代替手段が違い、課金意欲が違う。ペルソナは「その人が自力で同じことをできるか」で分類すべきだ。
2. 「自分でやる」と「何もしない」を競合に含める
有料サービスだけが競合ではない。技術者は「自分で作る」し、非技術者は「今まで通り何もしない」。
3. リーチ手段は最初に確認する
ターゲットにサービスの存在を知ってもらう方法がないなら、そのターゲットは選べない。プロダクトの前にチャネルを設計する。
4. コンテンツとユーザーの距離を測る
提供する情報がユーザーの日常業務に直結しているか。セキュリティニュースは専門家にとっては日常だが、兼任情シスにとっては「よその業界の話」だ。彼らが本当に欲しいのは「うちの会社で今日何をすべきか」であって、「世界で何が起きたか」ではない。
5. 撤退コストが低いうちに撤退する
Curatiqの撤退コストはほぼゼロだった。パイプラインのコードは別プロジェクトで引き続き使っている。エージェント体制のノウハウは次に転用できる。
コードを書く前に止められたから、失ったのは検証に使った1日のAPI費用だけだった。
まとめ
AIエージェントにビジネス検証を任せて最も価値があったのは、「作るべきでないもの」を早期に発見できたことだ。
技術者は「作れるか」を考えがちだ。パイプラインは動く、APIコストは安い、損益分岐点も低い。でも「作れる」と「作るべき」は別の問いだ。
企画段階で確認すべき5項目:
- ペルソナを具体化したか — 技術レベル・代替手段・支払い決裁権を明確に
- 「自分でやる」は可能か — ターゲットが自力で同じことをできるなら、有料サービスに金は払わない
- リーチ手段は存在するか — ターゲットに届ける方法がないなら、そのターゲットは選べない
- コンテンツとユーザーの距離は近いか — 提供する情報がユーザーの日常業務に直結しているか
- 「何もしない」も競合に含めたか — 有料サービスだけが競合ではない
Discussion