Tsukuttaで学んだ事─ MCPサーバーとファイルアップロード機能

Tsukuttaを作る前に、「これは個人開発者に絶対刺さる」と確信していた機能が2つあった。

結論から書くと、両方ほぼ使われなかった。

直近のデータを確認すると、公開アプリのうち:

• MCP経由の投稿: 3件 (約1%)
• ファイル配布(zip/exe等のアップロード): 3件 (約1%)

肝いりだった2つが、合わせても全体の2%に届かない。それぞれの誤算と、何を学んだかを書いておく。

1. MCPサーバー ── 「Claude Codeから直接公開できる」が刺さるはず

Tsukuttaは「個人開発者がもっとアプリを世に出すこと」を目指している。だからコーディングの流れを切らずに公開できるのが大事だと思った。

具体的には、Claude CodeからMCP経由で「いまのプロジェクトをTsukuttaに上げて」と指示するだけで、リポジトリのスキャン、秘密情報のサニタイズ、スクリーンショット自動検出、Tsukutta掲載まで全部走る。わざわざUIフォームを開いて入力するよりずっと効率的じゃないか、と本気で信じていた。

実際の結果: 3件。

刺さらなかった理由はおそらく

• MCPサーバーのセットアップコストが、フォームの「クリック→入力→投稿」より重い。便利の方向は合っていたが、初回コストが見合わなかった。
• 「公開作業」は、開発の終わりに数分でやる儀式的な行為。自動化しても得られる時間は少ない。本当に欲しかったのは「公開作業の高速化」じゃなかった。

2. ファイルアップロード ── 「配布手段がない人」や｢審査待ち｣の人を救うはず

もう一つは、zip/exe等のファイル配布。個人開発でデスクトップアプリを作る人や、IOSやAndroid向けアプリ紹介開発者に、配布手段がない問題を解決するつもりだった。Tsukuttaにアップロードしてリンクを発行できる。

実際の結果: ファイル配布のアプリは3件。

これも見立てが外れた:

• 個人開発の主流がWebアプリ。
• 「リンクを共有」と「実行ファイルを上げる」は心理的ハードルが違う。後者は責任が伴うし、ある程度ユーザー数を集めるまで踏み切らない。

学び

1. 「自分が便利と思うもの」と「ユーザーが使うもの」は別物。 MCPサーバーは自身の生活動線の中では完璧に動く。でも私はユーザー全体のうちの一人でしかない。

2. 使用率は仮説検証のシグナル。 1%という数字を「もっと宣伝すれば伸びる」と読むか、「想定したペルソナが実在しなかった」と読むかで、次の判断が変わる。今回は後者だった。

3. 力を入れた機能が必ずしも刺さらない。 MCPサーバーは設計+実装+セキュリティ強化(レート制限/サニタイズ)に相当工数を入れた。それでも刺さらない時は刺さらない。

これからどうするか

両機能とも消す気はない。3人でも価値を出せている人がいるなら維持する。

代わりにいま見ているのは、フォーム経由で投稿されたユーザーが、次に何を欲しがっているか。リクエスト機能、記事、ランキング、フォロー機能 ── ここに来た人が「もっと使いたい」と思える理由を、データに沿って一つずつ重ねていく。

外したのは辛いけど、上記の事を認識できたのは、よかったと思っている。