作った AI 機能を主役から降ろした話 — 献立 AI が Dogfooding 不能だった

recipe-ai に実装した「献立 AI」という機能を、リリースから数週間で主役の座から降ろした。コードは残している。API も動く。でもボトムナビのタブを削り、プレミアム紹介ページの訴求から消し、FAQ も撤去した。ユーザーからはほぼ見えない状態にした。

これは「作った機能を捨てる判断」の話だ。動作しているし、実装にも時間をかけた。でも 自分で使わない機能 を、プレミアムプランの主要訴求として売り続けるのは嘘になると判断した。

この記事でわかること:

献立 AI を主役にした当初の想定（1 週間献立の自動生成）
「使われない」が数字に出る前に気づけた理由
6 AI に同時に相談して出た合意点
「ENTP の新機能追加癖」に自分で気づく難しさ
コードを残しつつ導線だけ撤去する「降格」の実装
プロダクトは「足す」より「捨てる」ほうが難しい理由

献立 AI を主役にした当初の設計

recipe-ai は YouTube の料理動画から AI でレシピを抽出するアプリだ。

リリース初期の構想では、抽出だけでなく「週 7 日分の献立を AI が自動生成する」機能をプレミアムプランの目玉にするつもりだった。Gemini に「保存したレシピの中から、栄養バランスと調理負荷を考慮して 7 日分の献立を組んで」と投げれば、それらしい献立が返ってくる。デモとしては派手で、有料プランに乗せる訴求力があると思った。

実装は 1 日で終わった。ルート /ja/menu を切り、Gemini に保存レシピのリストを渡して 7 日分の献立を JSON で返させるだけの構成だ。プレミアム限定の機能としてロックをかけ、/pro の hero に大きく載せた。

「使われない」の兆候に気づく

リリース後、数字を見ると予想と違うことが起きていた。

献立 AI を実行するには 3 つの条件が同時に必要だった:

ログインしている
保存済みレシピが 3 件以上ある
プレミアム会員である

ログインユーザーの数はまだ少ない。保存レシピが 3 件以上溜まっているユーザーはさらに少ない。そこからプレミアムに入ってくれているユーザーは、リリース時点で 0 人。つまり「献立 AI を実行できる状態にあるユーザー」が存在しない期間が、数週間続いた。

これだけならまだ良い。致命的だったのは、作者である自分自身が献立を組まないことだった。

僕は料理動画を見つけたら保存して、作りたくなったときに 1 品だけ作る。1 週間分の献立を事前に組んで、その通りに料理する習慣がない。これは僕の性格というより、多くの一人暮らし・共働き世帯の典型パターンでもある。「今日何作ろう」と冷蔵庫を開ける生活と、「月曜は親子丼、火曜はハンバーグ」と先に決める生活は、別種の料理文化だ。

Dogfooding（自分で使ってみる）が不能な機能を、プレミアムの主役に据えていた。 これに気づいたとき、機能を売り続けるのは嘘になると思った。

6 AI に同時に相談した

判断に迷ったので、6 つの AI に同時に相談した。僕自身 + Gemini + Claude 別インスタンス + Perplexity + ChatGPT + Microsoft Copilot の 6 枚に、同じ状況を説明して意見をもらった。

全員一致した合意点（6/6）:

材料検索（食材起点）が本命、献立 AI はコア価値とズレている
ライブラリが 122 本は致命的に少ない — 機能実装よりライブラリ拡充が優先
献立 AI の現状維持は NG — 縮小・凍結・廃止のいずれか

特に Claude 別インスタンスからの指摘は刺さった。「ENTP の新機能追加癖、今回は 引き算 が必要」。作者の僕は新機能を思いつきやすい性格で、そのまま実装してしまう癖がある。だから「今やるべきは足すことじゃなくて捨てること」という指摘は、自分では気づきにくい角度だった。

降格の実装 — コードは残して導線だけ撤去

完全削除は選ばなかった。理由は 2 つ:

コードが動くこと自体は悪くない。将来上位機能として再配置できる可能性がある
完全削除すると復活のコストが高くなり、判断が逆戻りしにくくなる

やったこと:

ボトムナビから「献立」タブを削除（ログイン時 4 タブ → 3 タブに変更、代わりに「台所」タブを追加）
/pro の benefit list から「献立 AI」を削除
/pro の FAQ から「Q. 献立 AI って何？」を削除
/howto（使い方）の料金比較で献立の文言を削除、「レシピ保存無制限」に置換
/api/extract の QUOTA_EXCEEDED メッセージから献立文言を削除

残したもの:

/ja/menu ページ自体（コードは残す、直接 URL を叩けば動く）
lib/menu.ts, app/api/menu/generate/route.ts（機能としては動作する）

これを「降格」と呼んでいる。機能としては生きているが、ユーザーから能動的に使える導線を全部塞いだ状態。

この「降格」で得たもの

献立 AI を主役から降ろした結果、プレミアムプランの訴求が逆に明確になった。

Before:

献立 AI、栄養成分表示、広告なし、保存無制限、...（6 項目の benefit list）

After:

レシピ抽出使い放題、栄養成分表示、広告なし、保存無制限、クッキングモード、スケーリング（5 項目）

1 項目減っただけだが、全部が「作者自身が毎日使っている機能」になった。訴求文を書くときに嘘がない。

さらに、降格したタブの空きに「台所」という新機能を入れた。これは「作る予定 → 買い物リスト → 家にある材料（在庫管理）」の統合ループで、僕自身が本当に欲しかった機能だった。献立 AI が占めていた「プレミアムの主役」のポジションが空いたから、本当に欲しい機能に置き換えられた。

学び: 捨てる判断は数字より感情が先に動く

捨てる判断は、数字が出てからでは遅い。「プレミアム登録が伸びない」という結果が出てから動くと、それが献立 AI のせいなのか、LP コピーのせいなのか、価格設定のせいなのか、切り分けに時間がかかる。

今回、僕が動けたのは数字が出る前だった。決め手は「自分で使わない機能を主役として売っている」という感情的な違和感だ。それを 6 AI の意見で補強して、外部からの合意を取って、初めて「やっぱり降ろそう」と決められた。

ENTP の作者は機能を足すのが得意で、引くのが苦手だ。だから「引くべきタイミング」を自分で判断するのは難しい。外部の意見を複数取ることで、引く判断を後押しできた。

まとめ

作った機能を降格させることは、消すより難しい。でも消さずに済ませる選択肢もある
主役機能の Dogfooding 不能は、数字が出る前に気づくべき最強のシグナル
ENTP 気質の作者は「引く判断」が苦手。外部の合意を取って後押しする
降格で訴求が明確になり、空いた場所に本当に欲しかった機能（台所ループ）が入った

recipe-ai の次は、この台所ループを中心に Build in Public を進めていく。

recipe-ai を試す（無料）

この記事で作っている YouTube 料理レシピ抽出アプリ本体。動画 URL を貼るだけで AI がレシピに変換。月 5 本まで無料。