SuccessCaseAISaaSMonetization

My AskAIはなぜ2人で月4万ドルMRRに届いたのか。AIサポートSaaSが価格差と既存導線で勝つ方法

1. 「サマリー」30秒でわかる今回の案件

サービス名 / ジャンル

My AskAIは、企業のカスタマーサポートにAIエージェントを導入するSaaSです。対象は、Intercom、Zendesk、Freshdesk、HubSpot、Gorgiasなどをすでに使っているSaaS企業、EC、サポートチームです。

ユーザー企業が買っているのは、単なるチャットボットではありません。既存のヘルプデスクを捨てずに、繰り返し発生する問い合わせをAIで処理し、人間のサポート担当者を複雑な案件へ集中させる仕組みです。

Indie Hackersの記事によると、My AskAIはAlex Rainey氏とMike Heap氏が2023年初頭に創業しました。Alex氏は以前、旅行保険スタートアップPlutoを立ち上げ、Trustpilotで高評価を得るところまで伸ばしたものの、Covidによって旅行市場そのものが大きく崩れました。その後、いくつかのMicro-SaaSを作って売却し、次の本命としてMy AskAIに取り組みました。

売上 / MRR

My AskAIは、2人チームで月4万ドルMRR、年換算で約50万ドルARRの規模に到達したと紹介されています。月間で7.5万件超のサポートチャットを扱っているとも語られています。

1ドル155円で見ると、月商は約620万円、年換算で約7,440万円です。巨大なVC型SaaSではありません。しかし、2人で運営し、AI原価を含めても粗利約82%とされている点を考えると、Sparks Stationの読者にとってはかなり重要な事例です。

価格は、公式サイト上でProが月199ドルから、Scaleが月499ドルから。Scaleでは月2,000チケットが含まれ、超過分は1チケットあたり0.10ドルです。My AskAIは、Intercom FinやZendesk AIなどの「解決ごと課金」に対し、自社はチケット単位で3から10倍安いと説明しています。

ここが面白い

My AskAIの面白さは、AIでサポートを自動化すること自体ではありません。そこだけを見ると、競合は多すぎます。

本当に見るべきなのは、既存のサポート業務を置き換えない設計です。多くの企業は、ZendeskやIntercomにチケット履歴、社内運用、権限、レポート、担当者の習慣を持っています。そこへ「新しいサポートツールに乗り換えてください」と言うと、導入の壁が一気に上がります。

My AskAIは、その壁を避けました。既存のヘルプデスクに差し込み、そこでAIが返信し、必要なら人間へ引き継ぐ。顧客にとっては、サポート基盤の移行ではなく、既存基盤へのAI追加です。

この違いは大きいです。AI時代のSaaSは、まったく新しい画面を作るより、すでに予算と業務がある場所に入り込む方が売れやすい。My AskAIはその典型です。

2. 「Fact」サービスの詳細とTech Stack

機能

My AskAIは、企業のヘルプセンター、ドキュメント、Webサイト、社内ナレッジを読み込み、問い合わせに対してAIが回答するサポートエージェントです。ユーザー企業は、Intercom、Zendesk、Freshdeskなどの既存サポート環境の中でAIを使えます。

重要なのは、AIが答えられない場合に人間へ引き継ぐことです。サポート現場では、AIが全件を自動処理することより、「よくある質問を落とし、難しい案件を人に渡す」方が現実的です。

公式の事例では、TravelJoyがZendesk Advanced AIからMy AskAIへ切り替え、同じナレッジベースで解決率を大きく改善したと説明されています。TravelJoyはMy AskAI導入後、24,500件超のサポートチケットを処理し、チケットの約80%をAIで deflect し、月193時間の削減につながったとされています。

Customer.ioの事例では、200以上の質問を使って8社のベンダーを比較した後、My AskAIを選定。導入後は初週で47%、現在は68%の問い合わせをAIが処理していると紹介されています。

技術

Indie Hackersの記事では、初期MVPはかなりシンプルだったと語られています。コンテンツをアップロードし、質問を入力し、答えを返す。最初の動く版は3週間で作られ、BubbleとOpenAIに1,000ドル未満を使って立ち上げたとされています。

スタックとしては、コアアプリの約80%がBubble、バックエンドの一部がPython、AIは主にOpenAIモデル。トラフィックが増えた段階でBubble Enterpriseに移行し、成熟に合わせてAWSへ寄せていると説明されています。内部ツールとしてはNotion、Slack、Cursor、ChatGPTなどを使っています。

ここで学ぶべきことは、ノーコードかコードかの議論ではありません。My AskAIは、AI coding toolsが普及した後でも、ノーコードで十分に速く検証できる領域があることを示しています。

サポートAIの初期価値は、複雑なUIではなく「既存ナレッジから正しい回答を返せるか」「既存ヘルプデスクで自然に使えるか」「人間へ安全に渡せるか」です。この価値検証に、最初から完璧な独自基盤は不要でした。

運営体制

My AskAIは、記事時点で2人チームです。Alex氏がプロダクト開発を担当し、Mike氏が顧客インタビューや成長実験を担ったと説明されています。

この分担は、Micro-SaaSではかなり現実的です。AIプロダクトは技術だけでは売れません。特にサポート領域では、問い合わせの内容、既存運用、導入時の不安、価格比較、社内稟議の言葉まで理解する必要があります。

My AskAIは、AIモデルの新機能を追いかけすぎて時間を使ったこと、最初は「何でもチャットできる」広すぎる用途から始めてしまったこと、Bubbleのスケール課題に遅れて対応したことを失敗として挙げています。

この反省が重要です。最初からAIサポート特化で明確だったわけではありません。むしろ、広く始めてしまい、1年ほどかけて顧客サポートに絞った。AI SaaSで伸びるには、AIの可能性を広げるより、課金される業務へ狭める必要があります。

3. 「Insight」なぜ売れたのか

既存ツールの不満に乗った

My AskAIの勝ち筋は、IntercomやZendeskを正面から置き換えることではありません。既存ツールの高いAI料金、不透明な解決ごと課金、ナレッジ連携の制約に対して、安く、わかりやすく、既存環境で使える代替として入りました。

公式価格ページでは、10,000チケット/月、AI解決率50%の例で、My AskAI Scaleは月1,299ドル、Intercom Finは月4,950ドル、Zendesk AIは月7,500ドルという比較が示されています。数字の前提はMy AskAI側の試算ですが、見込み客にとって価格差を理解しやすい構成です。

この「比較される相手を決める」ことが強いです。AIサポートツールとして漠然と売るのではなく、「Intercom Finの代替」「Zendesk AIの代替」として検索される場所に置いています。

SEOとChatGPT検索に刺さる言葉を固定した

Indie Hackersの記事では、成長の多くはGoogle/SEOから来ていると語られています。さらに、最近はChatGPT経由で代替ツールを探す動きも増えていると説明されています。

My AskAIがやっているのは、抽象的なSEOではありません。「5x cheaper than Intercom Fin」「Zendesk AI alternative」「AI customer service agent for Zendesk」のように、顧客が比較時に使う言葉へ寄せています。

これは日本の個人開発者にも使えます。新しいカテゴリ名を作るより、既存ツール名、既存業務名、既存の不満を使った方が早い。たとえば「kintoneの入力補助AI」「Shopify返品問い合わせAI」「Chatwork対応の社内FAQ AI」のように、顧客の検索語に近い方が初期導線を作りやすいです。

価格が成果ではなく利用量に連動している

AIサポート領域では、解決ごと課金がよく使われます。AIが解決した分だけ払うので、一見わかりやすい。しかし、ユーザー企業から見ると、AIが何を「解決」と数えるのか、月末にいくらになるのか、心理的な不安が残ります。

My AskAIは、チケット単位の価格に寄せました。Proでは月199ドルで1,000チケット込み、Scaleでは月499ドルで2,000チケット込み。超過分は1チケットあたり0.10ドルです。

この価格設計は、完全に成果報酬ではありません。むしろ、使った量に応じて払う形です。ただし、顧客は「今月の問い合わせ数」から概算しやすい。問い合わせ量が多い企業ほど、1チケットあたりのコスト削減がわかりやすくなります。

SaaSの価格は、安ければよいわけではありません。顧客が社内で説明しやすい単位にすることが大事です。My AskAIの場合、その単位が「チケット」でした。

導入後の改善余地を残した

TravelJoyの事例を見ると、My AskAIは導入して終わりではありません。カスタム回答を追加し、ナレッジを調整し、タグ付けや分類を改善しながら、AI解決率を上げています。

これはAIサポートSaaSの本質です。AIは魔法の箱ではなく、サポート運用の改善装置です。FAQ、ヘルプセンター、エスカレーション条件、顧客の言い回し、注文情報や契約情報との連携が整うほど、解決率が上がる。

つまり、My AskAIが売っているのは「AIが答えます」ではなく、「サポート運用をAI前提に作り直す入口」です。ここに継続課金の理由があります。

4. 「Localize」日本市場への転用・アイデア

日本の類似市場

日本でそのまま「Intercom Fin代替」として入る市場は、英語圏ほど大きくないかもしれません。IntercomやZendeskを使うスタートアップはありますが、日本の中小企業全体では、メール、LINE、Chatwork、フォーム、Shopify、BASE、STORES、kintone、スプレッドシートが混ざったサポート運用も多いからです。

だから日本版を考えるなら、汎用AIサポートSaaSではなく、業務とチャネルをかなり絞った方がよいです。

たとえば、ShopifyやBASE事業者向けの返品・配送問い合わせAI。スクールや講座事業者向けの入会前質問AI。士業や補助金支援会社向けの必要書類案内AI。SaaS企業向けのヘルプセンター回答AI。BtoB受託会社向けの既存顧客FAQ AI。

どれも共通点があります。問い合わせが繰り返される。人間が毎回似た回答をしている。回答ミスが顧客不満につながる。だが、全件をAIに任せるのは怖い。この条件がある市場は、My AskAI型の入り方と相性がよいです。

障壁と対策

障壁は3つあります。

1つ目は、ナレッジ整備です。AIサポートは、元になるFAQや社内資料が弱いと答えも弱くなります。日本の中小企業では、そもそもFAQが整っていないことが多い。ここはSaaS単体で売るより、最初は「FAQ整備込み」の導入サービスにした方が現実的です。

2つ目は、チャネルの分散です。顧客対応がメール、LINE、Instagram DM、電話、フォーム、Chatworkに散っている場合、最初から全部を統合しようとすると重くなります。最初は1チャネルに絞るべきです。たとえばShopifyのメール問い合わせだけ、LINEの予約前質問だけ、kintoneに入る社内問い合わせだけ、という切り方です。

3つ目は、責任範囲です。返金、医療、法務、契約、個人情報に関わる回答は、AIが勝手に確定してはいけません。My AskAIのように、人間への引き継ぎ、タグ付け、下書き作成、信頼度が低いときの停止を最初から設計する必要があります。

結論

My AskAIの教訓は、AIサポートは「AIで人を置き換える」と売るより、「既存サポートの中で、繰り返し部分だけを安く確実に減らす」と売る方が強いということです。

日本の個人開発者が試すなら、最初からZendesk代替を作る必要はありません。むしろ、1業種、1チャネル、1種類の問い合わせに絞るべきです。

たとえば、Shopify店舗の配送・返品問い合わせだけを対象にします。まずは10店舗にヒアリングし、過去1か月の問い合わせを匿名化してもらい、上位20パターンを抽出します。次に、FAQ整備、AI下書き、返信テンプレート、必要時の人間引き継ぎまでを月3万円から10万円で手動提供します。

その中で、毎回同じ設定、同じ分類、同じ返信文、同じ注文情報参照が出てくれば、そこをSaaS化します。

AI時代のSaaSは、ゼロから市場を作るより、すでに人件費が燃えている場所へ入る方が速い。My AskAIは、その入り方をかなりわかりやすく見せてくれる事例です。

Tools to try

この事例を日本で試すなら

海外SaaSの成功パターンを実行へ移すための候補です。一部リンクは今後、提携リンクに差し替える場合があります。

Before building

作る前に、支払い手と導入の壁を確認する

技術が強くても続かない事例は、検証項目に落とすと価値が出ます。Pro先行案内では、作る前の市場・価格・GTM設計を扱います。

Comments0

コメントを投稿するにはログインが必要です

まだコメントはありません。最初のコメントを投稿しましょう!

関連記事