FeedHiveは正式ローンチの6日前に有料プランを出し、初日に3人が課金した

FeedHiveは、X・LinkedIn・Instagram・Threadsなどの投稿を1か所で作り、予約し、自動化するSNS運用ツール。

2021年2月にSimon Høibergが個人開発から立ち上げ、2026年現在はAIエージェントと一緒に投稿を作ることを前面に出したv2.0として展開している。出典

FeedHiveは、2021年2月6日の正式ローンチに向けてSimon Høibergがほぼ1人で作り上げたSNS投稿ツールだ。

ローンチの6日前になる2021年1月30日にはすでに有料プランを公開し、数時間で3人のユーザーが課金したと本人が開発記録に残している。出典

出発点は自分の投稿作業だった

Høibergが最初に解いたのは、他人のためではなく自分の不便だった。

Xの画面は予約投稿に向いておらず、スレッドの予約もできない。

既存の代替ツールについては「The alternatives out there were either super pricy, really clunky, insufficient for my needs - or a good mix of all.」と書き、自作のクラウド関数とCLIで凌いでいた時期があると説明している。出典

最初のバージョンは極めて小さかった。

ツイートを書いて予約する。

予約した投稿を一覧で見る。

できるのはその2つだけだった。出典

ローンチ前から売った

2020年12月16日、数人のアーリーアダプターに声をかけて使い始めてもらう。

12月28日には自身のニュースレターで約800人に告知し、100人ほどが登録した。

Xに投稿した告知は1,000以上のいいねを集めたという。出典

そして2021年1月30日、有料プランを公開する。

まだ正式ローンチの前だった。

「This feeling is absolutely amazing!」と、ローンチ前の課金に対して手応えを記している。出典

完成度を上げてから売るのではなく、売ってから作る順番を選んだことになる。

この判断は、以降に追加された機能の優先順位にも影響しているはずだ。出典

1本のプロダクトではなく、ポートフォリオとして

FeedHiveのあと、HøibergはLinkDrip（2022年10月）、Aidbase（2023年11月）、FounderStack（2024年11月）、SignupGate（2025年9月）を相次いで立ち上げ、2023年1月にはTinyKiwiを買収している。出典

自身のサイトでは「Startup CEO and founder. Building a portfolio of bootstrapped SaaS products.」と名乗る。

外部資金を入れずに複数の小さなプロダクトを並べ、それぞれの学びを次のプロダクトに移す運営だ。出典

AIエージェントの側に回った2026年

現在のFeedHiveは、コンポーザー、AIアシスタント、自動化、投稿条件、スマートスケジューリング、ソーシャルインボックス、リサイクル提案、分析を1つのワークスペースにまとめている。出典

特徴的なのは、外部のAIエージェントから操作できる点だ。

公開MCPサーバーとREST APIを用意し、Claude CodeのプラグインやOpenClaw向けskillsも配布している。出典

人が画面を開いて投稿する前提から、エージェントが下書きと予約を実行し、人が承認する前提へ。

5年かけて積んだ投稿ワークフローの知見を、そのまま機械可読な形に開いている。出典

小さく作って早く売る。

その順番を、プロダクトを替えながら繰り返している会社だと言える。

FeedHiveが刺さるのは、複数チャネルへ継続的に投稿する必要があるのに、投稿作業そのものに時間をかけたくない個人クリエイターと小規模チームだ。

創業者自身が「既存ツールは高すぎるか、使いにくすぎるか、自分の用途には足りない」と感じたことが出発点で、初期ユーザーも同じ不満を抱えていた。出典

需要の裏付けはローンチ前の課金にある。

正式公開の6日前に有料プランへ移行し、数時間で3人が支払った。出典

機能の追加ではなく、既存の作業を短くする方向に product を寄せている点が、PMFの中心だと読める。

参入障壁は技術単体ではなく、投稿ワークフローの設計と外部エージェントへの公開度にある。

MCPサーバー、REST API、Claude Codeプラグインを揃え、エージェントから操作できる状態を先に整えた。出典

ただし機能は模倣されやすく、価格帯も中位に位置するため、障壁は中程度だ。出典

ネットワーク効果は弱い。

ユーザーが増えても他のユーザーの体験は直接良くならない。出典

一方で、エージェント連携は間接的な効果を持つ。

Claude CodeやOpenClawなど外部ツールの利用者が増えるほど、FeedHiveを呼び出す導線が増える。出典

主な顧客は、個人で複数アカウントを運用するクリエイター、スタートアップの少人数マーケティングチーム、複数クライアントを抱える代理店だ。

料金はソーシャルアカウント数とAIクレジットで分かれ、上位プランほど大規模な運用を想定する。出典

大企業の複数部門を横断するような統制や監査機能を求める層は、主対象ではないと考えられる。

第一に、自分の不満をそのまま仕様にしたこと。

既存ツールの価格と操作性への不満が出発点で、初期ユーザーも同じ課題を抱えていた。出典

第二に、有料化を早めたこと。

ローンチ6日前の課金で需要を確認し、以降の開発判断を市場の反応に合わせられた。出典

第三に、AIエージェント時代の接続面を先に用意したこと。

MCPサーバーとREST APIを公開し、他のツールから呼ばれる側に回っている。出典

収益や成長率が公開されておらず、外部から事業の健全性を検証できない。

料金改定と機能追加の頻度から推測するしかない。出典

SNS運用ツールは各プラットフォームのAPI仕様に強く依存する。

仕様変更やレート制限が、そのまま製品のリスクになる。出典

AIクレジット制は利用量の予測が難しく、ヘビーユーザーほど費用対効果の説明が必要になる。

小規模チームでの運営は、サポートとロードマップの速度にも影響しうる。出典

初期は創業者自身の発信が獲得チャネルだった。

ニュースレターとXの告知で最初の100人を集め、ローンチ前から課金に到達している。出典

現在はブログで自社データを使った分析記事を出し、検索経由の流入を作っている。

Instagramの投稿時間を自社計測で検証する記事はその典型だ。出典

さらにAIエージェントごとの接続ページを用意し、開発者・パワーユーザーの導線を確保している。

トレードオフは、チャネルごとに説明コストがかかることだ。出典

主要チャネル: seo_blog, x_twitter, newsletter, ai_agent_integrations

市場が飽和して見える領域でも、自分の作業の不便から作った道具は刺さる。

Høibergは「Starting a new product that is already covered by plenty on the market already is always scary. But I decided to go for it anyway.」と書いている。出典

もう1つは、売る順番を早めることだ。

完成度を上げる前に課金の反応を見れば、次に作る機能を絞れる。出典

日本語の投稿UIとサポートがあれば、個人クリエイターには届きやすい。

X中心の運用文化はFeedHiveの得意領域と重なる。出典

代理店向けには承認フローの訴求が有効だと考えられる。

日本語での承認コメントや社内稟議の流れまで整うと、導入の障壁は下がる。出典