一覧に戻る

kikimimi ビジネスプラン

kikimimi-business-plan.md

作成日時:2026/01/23 17:03
更新日時:2026/01/23 17:03

kikimimi ビジネスプラン

作成日: 2026-01-15 カテゴリ: GD ステータス: 設計完了、実装待ち

0. プロジェクト概要

kikimimi（聞き耳）: 「元気でんき」に関するネガティブな言及を自動検知・通知する風評管理ツール

Core Purpose: 手動調査の負荷を削減し、ネガティブ投稿の早期発見・早期対応を実現する

1. 目的と背景

1.1 課題

現在の問題点:

  • 手動調査（Google検索、SNS閲覧）の負荷が高い
  • 見落としリスク（夜間・休日のネガティブ投稿）
  • 早期発見・早期対応が困難
  • 評判悪化による機会損失

1.2 解決策

kikimimiの提供価値:

  • 自動検知バッチ処理（夜間1日1回実行）
  • 即時通知（Slack連携）
  • 複数プラットフォーム監視（Google Map、Yahoo知恵袋、SNS等）
  • 無料枠内での運用（Google Custom Search API: 100回/日）

2. ビジネスモデル

2.1 顧客セグメント

ターゲット:

  1. 「元気でんき」運営会社

    • 評判管理のリソース不足
    • 夜間・休日の対応困難

  2. 将来的な展開先（他社展開）

    • 地域密着型サービス業（電気工事、不動産、美容室等）
    • 中小企業の評判管理ニーズ

2.2 価値提案

顧客への価値:

  • 時間削減: 手動調査の自動化（1日あたり30分→0分）
  • リスク低減: 見落としによる被害拡大防止
  • 早期対応: 検知から1時間以内に通知
  • コスト効率: 無料API枠内での運用（月額0円）

3. 製品・サービス仕様

3.1 機能要件

MVP（Minimum Viable Product）:

  1. 検索機能: Google Custom Search API連携
  2. フィルタ機能: ドメイン信頼度 + キーワードマッチング
  3. 通知機能: Slack Webhook連携
  4. 管理画面: 検索結果一覧、キーワード管理

将来的な機能追加:

  • センチメント分析API連携（精度向上）
  • マルチテナント対応（他社展開）
  • レポート機能（トレンド分析）

3.2 技術スタック

レイヤー 技術選定 理由
Frontend Next.js (App Router) Cloudflare Pages対応、React開発効率
Backend Next.js API Routes フルスタック統合、TypeScriptサポート
Database Cloudflare D1 無料枠充実、SQLiteベースで移行容易
Search Google Custom Search API 100回/日無料、検索品質高
Batch Vercel Cron Jobs / Cloudflare Workers Cron 夜間実行、サーバーレス
Notification Slack Webhook 即時通知、無料

3.3 運用コスト

月額コスト: 0円（無料枠内）

内訳:

  • Google Custom Search API: 無料（100回/日）
  • Cloudflare D1: 無料（5000回/日読み取り）
  • Vercel Hobby: 無料
  • Slack Webhook: 無料

将来的な拡張時:

  • 有料プラン: $10-50/月（センチメントAPI、多言語対応等）

4. 競合優位性

4.1 競合比較

競合 メリット デメリット kikimimiの優位性
手動調査 柔軟性高い 負荷大、見落としリスク 自動化で負荷削減
有料ツール 機能充実 高額（$50-500/月） 無料枠内で運用可能
汎用SMMツール 多機能 複雑、過剰機能 ニッチ特化でシンプル

4.2 差別化要因

  1. コストリーダーシップ: 完全無料運用可能
  2. シンプルさ: ニッチ特化（風評管理のみ）
  3. 即時性: 夜間バッチ + Slack通知で早期発見
  4. 拡張性: マルチテナント対応で他社展開可能

5. 実装ロードマップ

5.1 Phase 1: MVP開発（2週間）

Week 1: 基盤構築

  • アーキテクチャ設計完了（✅ 2026-01-15完了）
  • APIキー取得（Google CSE、Slack Webhook）
  • D1スキーマ実装
  • 検索サービス実装（Google CSE連携）

Week 2: 機能実装

  • キーワードマッチング実装
  • Slack通知実装
  • バッチ処理実装（Vercel Cron）
  • 管理画面実装（検索結果一覧）

5.2 Phase 2: 運用開始（1週間）

  • 「元気でんき」での試験運用
  • 精度調整（キーワード追加・削除）
  • 通知タイミング最適化

5.3 Phase 3: 他社展開（将来的な拡張）

  • マルチテナント対応
  • センチメントAPI連携
  • 料金プラン検討

6. 成功指標（KPI）

6.1 定量指標

指標 目標値 測定方法
検知率 90%以上 手動調査との比較
誤検知率 10%以下 通知内容の人的チェック
通知速度 1時間以内 投稿時刻 vs 通知時刻
運用コスト 0円/月 無料枠内での運用維持

6.2 定性指標

  • 手動調査の削減: 1日30分→0分
  • 早期対応の実現: 夜間・休日の投稿にも翌朝には対応可能
  • 満足度: ステークホルダーからのフィードバック

7. リスクと対策

7.1 技術リスク

リスク 影響 確率 対策
API制限超過 サービス停止 中 複合フィルタ戦略で呼び出し削減
精度不足 ノイズ増 中 キーワード調整、センチメントAPI追加検討
Google CSE仕様変更 仕様変更対応 低 モックAPIで検証、代替検索API検討

7.2 ビジネスリスク

リスク 影響 確率 対策
他社展開の需要不足 収益化困難 中 MVPで価値検証、PMF確認後に拡張
競合の無料化 差別化困難 低 ニッチ特化、地域密着で優位性維持

8. 次のアクション

即時実行タスク:

  1. 意思決定: 採用するアプローチ確定（費用重視 / 精度重視 / バランス重視）
  2. プロトタイプ作成: Google CSE 1回検索 + キーワードマッチング
  3. APIキー取得: Google Custom Search API、Slack Webhook
  4. スキーマ実装: D1データベース
  5. バッチ処理実装: Vercel Cron Jobs 設定

参考ファイル:

  • 設計書: notes/kikimimi-logic-idea.md
  • 技術スタック: Next.js + Cloudflare D1 + Google CSE + Slack Webhook