UX 分析

レシピアプリ UX 構造分析 — クックパッド / DELISH KITCHEN / クラシル の動画/テキスト・オンボーディング・課金境界を徹底解剖

テクラル研究所 編集部

テクラル研究所 編集部

テクラル研究所

#レシピアプリ#クックパッド#DELISH KITCHEN#クラシル#UX分析#プロダクト戦略#フリーミアム設計#オンボーディング設計#C向けアプリ
レシピアプリ UX 構造分析 — クックパッド / DELISH KITCHEN / クラシル の動画/テキスト・オンボーディング・課金境界を徹底解剖

レシピアプリは「動画を見ながら作れるか、テキストで素早く探せるか」「保存したいレシピに何タップで辿り着けるか」「無料でどこまで使えるか」という 3 つの体験ハンドルで使い心地が決まる。クックパッド・DELISH KITCHEN・クラシルの 3 社は同じ「レシピアプリ」という括りで語られがちだが、実際にはクックパッドが「ユーザー投稿 × テキスト検索」の最古参プラットフォーム、DELISH KITCHEN が「編集部制作 × 縦動画」の動画ファースト、クラシルが「編集部制作 × 動画 × 献立提案」のレコメンド型と、立っている陣地がはっきり分かれている。

本稿は、3 社のアプリを同じ抽象度に揃え、「ポジショニング・オンボーディング設計・コンテンツ調達ミックス・課金境界」の 4 軸で構造分析する。レシピアプリそのものを企画する担当者だけでなく、ユーザー投稿型と編集部制作型のどちらを取りに行くかで迷う C 向けコンテンツ事業の事業責任者、無料の保存数や検索精度で課金境界を引くフリーミアム SaaS の PdM、動画ファーストの UI を検討中のデザイナーが、自社プロダクトに転用できる原理を抽出するための資料として書いた。

レシピアプリ 3 社のポジショニング 2×2(動画/テキスト × 投稿/編集部)

3 社のポジショニング — 同じ「レシピアプリ」でも陣地が違う

レシピアプリは表層では「献立に困ったときに開くアプリ」とひと括りされがちだが、3 社を「コンテンツ形式(動画/テキスト+写真)」と「コンテンツ調達源(ユーザー投稿/編集部制作)」の 2 軸で並べると、それぞれの本拠地が綺麗に分かれる。「レシピアプリ」というドメインの中に、実際には 3 つの違うプロダクトカテゴリが並走している。

クックパッド — 「ユーザー投稿 × テキスト+写真」の最古参プラットフォーム

クックパッドは投稿レシピ数 396 万品(公式表記)を抱えるユーザー投稿型の最古参で、テキスト + 写真でレシピを掲載するスタイルを 20 年以上維持している。動画レシピアプリの台頭でユーザー数のシェアは奪われたが、それでもプレミアム会員 200 万人という有料転換のボリュームを維持しており、収益面では依然として強い陣地に立っている。ホーム画面に出てくるのは「みんなのつくれぽ」と検索バーで、編集部のキュレーションは前面に出てこない。

クックパッドの主要画面(豊富なレシピ一覧・食材検索・広告なしの作り方画面)

DELISH KITCHEN — 「編集部制作 × 縦動画」の動画ファースト

DELISH KITCHEN はエブリー社が運営する編集部制作型のレシピ動画サービスで、月間アプリ + ウェブ利用者数 3,200 万を突破し国内レシピサービス No.1 を獲得している(2025 年 10 月時点、同社プレスリリース)。月間 1,500 本ペースで制作される動画レシピを縦動画フォーマットで配信し、累計レシピ動画数は 48,000 本以上、すべて管理栄養士監修という品質基準で揃えている。「動画 × 編集部」という陣地を取り、コンテンツの均質さと撮影クオリティで差別化している。

DELISH KITCHEN の主要画面(国内 No.1 訴求・縦動画レシピ・56,000 件のレシピ訴求)

クラシル — 「編集部制作 × 動画 × 献立提案」のレコメンド型

クラシルは dely 社(現クラシル株式会社)が運営する動画レシピサービスで、累計アプリダウンロード 4,400 万件、管理栄養士監修の公式レシピ約 5 万点を抱える。DELISH KITCHEN と同じ「動画 × 編集部制作」陣地に立つが、献立提案フロー(主菜 → 副菜 → 汁物 → 確認)や「おすすめ」「テーマ別」というレコメンドタブを前面に押し出して「何を作るか決めてもらう」体験に振っている。さらに「レシピチャレ by クラシル」「my kurashiru」といったライフスタイル横展開で、レシピ動画だけに留まらないメディア化を進めている。

クラシルの主要画面(国内 No.1 訴求・テーマ別レシピ・献立提案フロー)

要するに 3 社は「同じレシピアプリ」という括りで競合しているように見えて、クックパッドはテキスト × 投稿の最古参プラットフォーム、DELISH KITCHEN は動画 × 編集部のクオリティ均質型、クラシルは動画 × 編集部 × 献立提案のレコメンド型という別の陣地で戦っている。自社プロダクトでレシピ系・コンテンツ系を企画する際、「動画レシピアプリを作る」という抽象度ではどこにも刺さらない。先にこの 3 つの陣地のどれを取りに行くかを決めないと、後段のオンボーディングもコンテンツ調達も課金境界も決まらない。

各章末で出てくる示唆をひと言で先取りすると、レシピアプリ系の体験設計は「テキスト検索の効率化」「動画の没入感」「献立提案の意思決定肩代わり」のどれを核機能として取りに行くかで、後段の構造が全部決まる、ということだ。

オンボーディング設計 — 「保存したいレシピ」に何タップで辿り着けるか

レシピアプリは「初回起動から、ユーザーが心の中で『これ作りたい』と思えるレシピに辿り着くまでの step 数」で続けられるかどうかが決まる。3 社のオンボーディングフローを「初回起動 → レシピ閲覧 → 保存(お気に入り登録)」までで揃えて並べると、入り方の哲学が違うのが見えてくる。

レシピアプリ 3 社のオンボーディングステップ比較(初回起動から保存まで)

クックパッドのオンボーディング — 「いきなり検索」で摩擦を消す

クックパッドは初回起動時にチュートリアル動画も会員登録誘導もほぼ挟まず、いきなり検索バーとおすすめレシピ一覧を出してくる。「ハンバーグ」と入れれば検索結果が出て、レシピをタップすれば材料・作り方が読める。会員登録なしでもレシピ閲覧と検索ができるので、初回タスクが「保存」までいく場合でも 4 step 程度に収まる。

このオンボーディングは、20 年以上テキスト + 写真のレシピを蓄積してきたプラットフォームらしい設計で、「ユーザーは作りたい料理名がもう頭にある」という前提に立っている。チュートリアルや誘導を挟むほど離脱が増えるので、検索 UI を前面に出して即タスクをやらせる。

DELISH KITCHEN のオンボーディング — 「動画で見せる」を最初に体験させる

DELISH KITCHEN は初回起動時に動画レシピのリッチさを最初に体験させる設計になっている。チュートリアル的なスライダーで「動画でわかる」「管理栄養士監修」をアピールしてから通知許可・会員登録の打診が来る。レシピ閲覧画面はフルスクリーンの縦動画で、ストーリーズ的な没入感を出す。

「動画で見れば作れる」というプロダクトの核機能を最初に体験させる構造で、step 数自体はクックパッドより 1〜2 多い。代わりに「動画で見ながら作る」というレシピアプリの新しい体験に説得力を持たせている。

クラシルのオンボーディング — 「献立提案」までを初回フローで体験させる

クラシルは初回起動時に会員登録誘導を入れた上で、「あなたへのおすすめ」「旬食材」「献立/作り置き」というタブ構造に誘導する。さらに献立提案フロー(主菜 → 副菜 → 汁物 → 確認)を初回から体験させる設計で、ホーム画面の中に「献立を立てる」というアクションが組み込まれている。

3 社の中では最も step 数が多く、「レシピを 1 つ保存する」までの距離は長い。ただし、初回で「献立 4 品をクラシルに任せて決めてもらう」という体験を踏ませることで、「次回もここに帰ってくる」習慣を作りに行っている設計に見える。

示唆 — オンボーディングの長さは「核機能の押し方」で決まる

3 社のオンボーディング step 数を並べると、クックパッドが最短・DELISH KITCHEN が中間・クラシルが最長になる。これは「離脱が増えるからオンボーディングは短いほうが良い」というデザイン教科書通りの議論を、3 社が違うふうに解釈していることを示している。

  • 核機能が「検索」なら(クックパッド型)、step は最短にして即座にやらせる
  • 核機能が「動画体験」なら(DELISH KITCHEN 型)、動画を 1 本フル尺で見せる体験まで含めて「初回タスク完了」と定義する
  • 核機能が「献立を任せられる」なら(クラシル型)、初回でその意思決定肩代わりを 1 サイクル体験させないと核機能が伝わらない

レシピアプリに限らず、フリーミアム SaaS のオンボーディング設計でも同じ原理が効く。「ユーザーに早くタスクを完了させる」というセオリーは、核機能が単純に「検索」「閲覧」レベルの場合だけ正解で、核機能が「意思決定の肩代わり」「自動化」「複雑なワークフロー」になる場合は、初回で 1 サイクル踏ませる方が定着率が高い。

コンテンツ調達ミックス — 投稿/編集部/タイアップ/監修の比率で UX 哲学が決まる

レシピアプリの UX は、表層的なフローよりも「中身のレシピをどう仕入れているか」で 8 割決まる。同じ「レシピを表示する」アプリでも、ユーザー投稿型と編集部制作型では検索体験・品質均質性・更新頻度・タイアップ余地が全部違う。3 社の調達源ミックスを並べると、それぞれが背後でどんなビジネスモデルを取りに行っているかが見える。

レシピアプリ 3 社のコンテンツ調達ミックス(投稿・編集部・タイアップ・管理栄養士監修の比率)

クックパッド DELISH KITCHEN クラシル
公開レシピ数(規模) 約 396 万品 約 56,000 件 約 50,000 件
主要な調達源 ユーザー投稿(一般家庭の料理人) 編集部制作(社内シェフ・撮影スタジオ) 編集部制作(社内シェフ・管理栄養士)
補助的な調達源 編集部によるキュレーション・特集 企業タイアップ(食品メーカー / 小売)・管理栄養士監修 ユーザー投稿(みんなのおいしい)・管理栄養士監修
品質の均質性 投稿者次第(ばらつき大) 高い(全レシピ撮影 + 監修) 高い(管理栄養士監修 + 撮影)
更新頻度 リアルタイム(投稿次第) 月 1,500 本ペース 継続的(公式 5 万 + 投稿)
検索の特性 同じ料理に対して数百〜数千件のバリエーション 1 料理に対して数本の編集部レシピ 1 料理に対して数本の編集部レシピ + 投稿動画

クックパッド — ユーザー投稿のロングテールで網羅

クックパッドの 396 万品という規模は編集部制作では到底届かない。「鶏むね肉 やわらか」で検索すると、ユーザーが工夫した数百件以上のバリエーション(塩麹漬け・砂糖+塩麹・酒粕漬け・ヨーグルト漬け…)が返ってくる。これは投稿型のロングテール戦略の効果で、「自分の家にある食材」「自分の好み」に合うレシピが必ず見つかる。

ただし投稿者の腕や写真の質はばらつくため、検索結果の最初の数件が「美味しそうに見えるか」は運次第で、ここを救うために人気順検索という機能を持っており、それを有料の柱に置いている。「網羅性は無料でカバー、品質ソートは有料」という設計は、ロングテール調達ならではの収益化だ。

DELISH KITCHEN — 編集部制作で品質均質性を取る

DELISH KITCHEN の 5.6 万件のレシピは月 1,500 本ペースで制作される編集部コンテンツが大半で、すべて自社の撮影スタジオで動画化され、管理栄養士監修が入る。さらに食品メーカー・小売との企業タイアップ動画が組み込まれ、ここがマネタイズの一翼を担う(住友生命 Vitality のような外部サービスとの提携特典もこの線)。

この調達構造の特徴は、「鶏もも肉」で検索したときに、検索結果の上位がすべて編集部の動画レシピで揃うこと。「網羅性は捨てて品質均質性を取る」という意思決定で、UI も「動画ストーリーズ」的な見せ方ができる。逆に「自分の家にある食材ピンポイントで作れるレシピ」を見つけるのは苦手で、ユーザー投稿型のクックパッドが強い部分は構造的にカバーできない。

クラシル — 編集部 + 投稿のハイブリッド

クラシルは編集部制作の公式レシピ約 5 万点(KADOKAWA 公式レシピ本『クラシル公式 人気おかず事典』の解説でも明示)を基盤にしつつ、「みんなのおいしい」というユーザー投稿セクションも持っている。さらに管理栄養士監修が全レシピに入り、各レシピに栄養価(エネルギー・塩分量・炭水化物・タンパク質・脂質)が付くという品質基準を満たしている。

この調達構造は DELISH KITCHEN の「編集部の均質性」と、クックパッドの「投稿のロングテール」を中間で取る設計で、献立提案 UI と相性が良い。「何作るか決めて」とお願いされたときに、編集部レシピを推薦の柱に据えつつ、ユーザー投稿で多様性を補うことで、レコメンド型に必要な「飽きさせないコンテンツ量」を確保している。

示唆 — コンテンツ調達は UX のすべての土台

3 社のコンテンツ調達ミックスを並べると、調達源が UX の細部まで規定していることが見える。

  • ユーザー投稿型は網羅性で勝つが、品質ソート(人気順・殿堂入り)が有料の柱になる
  • 編集部制作型は均質性で勝つが、「自分の家にある食材ピンポイント」が弱く、レシピ数の絶対量で物理的に縛られる
  • ハイブリッド型は中間取りで、レコメンド UI と組み合わせると強い

自社プロダクトで C 向けコンテンツ事業を企画する際、「動画にすべきか・テキストにすべきか」を考える前に、「コンテンツをどう仕入れるか」を先に決める必要がある。投稿型なら CGM のガバナンス(不適切投稿対応・著作権対応)が必要で、編集部型なら制作チームの固定費が乗る。フリーミアム SaaS でも同じで、「テンプレ・ブログ記事・ダッシュボード設計」などをユーザーが作るのか、運営が用意するのかで、価格設計も UI も全部変わる。

課金境界 — フリーミアムの壁はどこに引かれているか

3 社とも基本無料 + 月額 308〜480 円のプレミアムというフリーミアム設計だが、無料の天井・壁の作り方・有料で外れる機能が違う。レシピアプリは「使ってみないと価値が伝わらない」プロダクトなので、無料の天井が低すぎると即離脱、高すぎると有料転換が起きないという狭い線上に課金境界を引く必要がある。

レシピアプリ 3 社の課金境界比較(価格・無料の天井・有料機能・広告)

クックパッド DELISH KITCHEN クラシル
価格 月 308 円(Web 決済)/ 302 円(Google Play)/ 400 円(App Store) 月 480 円 月 480 円(2 ヶ月無料トライアル)
無料の天井 人気順検索ロック・殿堂入りロック 保存数制限・低糖質ヘルシーレシピロック 人気順検索ロック・保存数制限・広告あり
壁になる制約 検索結果が「新着順」になる・人気が分からない レシピメモ保存が上限到達でブロック 検索結果が「新着順」のみ・保存上限到達でブロック
有料で外れる主な機能 人気順検索・殿堂入りレシピ・分量変換 レシピメモ無制限・低糖質/低カロリーヘルシーレシピ・栄養成分閲覧・お気に入り上限増・広告非表示 人気順検索・お気に入り無制限・広告非表示
広告 無料は表示・有料で非表示 無料は表示・有料で非表示 無料は表示・有料で非表示
無料体験 なし(条件付き割引キャンペーンあり) あり(プランによる) 2 ヶ月無料
有料会員規模 プレミアム約 200 万人 非公開 非公開

クックパッドの課金境界 — 「検索品質」を有料の柱に置く

クックパッドのプレミアムは月 308 円(Web 決済)と 3 社で最安だが、これは「人気順検索」と「殿堂入り」というプラットフォームに溜まった集合知へのアクセスを有料の柱に置いた結果だ。投稿レシピ 396 万品という膨大なロングテールがあるからこそ、「どれが本当に美味しいか」のソートが価値になる。無料でも検索とレシピ閲覧は使えるので、しばらく使ってから「人気順が無いと選べない」というタイミングで壁にぶつかる設計。

App Store 経由だと月 400 円、Google Play で 302 円、Web で 308 円と価格に幅があり、これは App Store の手数料を価格に転嫁している(同社ヘルプの公式表記)。「同じプロダクトでも決済経路で価格を変える」のはコンシューマアプリでは珍しい透明性で、結果として「Web 経由で契約してアプリで使う」というワークアラウンドが公式に推奨されている。

DELISH KITCHEN の課金境界 — 「健康訴求」と「ためる UX」を有料に振る

DELISH KITCHEN は月 480 円で、有料化される機能はレシピメモ保存無制限・低糖質ヘルシーレシピ・栄養成分閲覧・お気に入り上限増・広告非表示となっている。「動画で見れば作れる」という核機能自体は無料で開放し、「健康管理したい」「保存して何度も使い込みたい」というセグメントに有料を訴求する設計だ。

栄養成分(タンパク質・脂質・炭水化物・糖質・塩分量)の閲覧と、管理栄養士監修の低糖質・低カロリーレシピを有料に置くのは、健康訴求型のフリーミアムとして筋が良い。「動画レシピを見るだけ」のライトユーザーは無料で長く滞在させて広告 LTV を取り、健康意識の高いユーザーはプレミアムに転換させて月額 LTV を取る、二段構えの設計に見える。

クラシルの課金境界 — 「2 ヶ月無料 + 人気順ロック」で転換率を取る

クラシルは月 480 円だが、特徴は2 ヶ月の無料トライアルだ。「無料のお試し期間が過ぎると自動的に有料の月額プランに変更」という設計で、2 ヶ月間で人気順検索・お気に入り無制限・広告非表示を体験させてから課金に移行する。一度「人気順で並べ替えてレシピを選ぶ」体験を覚えると、新着順だけに戻すのが心理的にきつくなるので、無料トライアル後の転換率を取りに行く設計だ。

「知らないうちにクラシルプレミアムに登録されていた」という Q&A が公式ヘルプにあること自体、無料 → 有料の自動切り替えで戸惑うユーザーが一定数発生していることを示している。転換率を取る代わりに、ユーザーリテラシーや事前説明の負担が運営側に残るフリーミアム設計と言える。

示唆 — レシピアプリの課金境界は「核機能」の周辺に引かれる

3 社の課金境界を並べると、フリーミアム設計には少なくとも 3 つのパターンがあることが分かる。

  1. 集合知へのアクセス課金型(クックパッド): ユーザー投稿の膨大さがある場合、「品質ソート(人気順)」が有料の柱になる。網羅性は無料で開放してロングテール検索を回す。
  2. 健康訴求と使い込み課金型(DELISH KITCHEN): 動画体験は無料、「健康管理 + ためる UX(保存・栄養成分)」に有料を寄せる。広告 LTV と月額 LTV の二段構えになる。
  3. 無料トライアル習慣化型(クラシル): 2 ヶ月のフル機能体験で「人気順なし」「広告あり」に戻れない状態を作って転換率を取る。ユーザー戸惑いコストが運営側に残る。

自社プロダクトでフリーミアムを設計するときに重要なのは、「核機能を無料で完全に提供できているか、有料の壁が核機能の周辺に引かれているか」だ。レシピアプリは「レシピを見る」が核機能で、3 社とも核機能自体は無料で開放している。有料化されるのはあくまで核機能の周辺(品質ソート / 保存上限 / 広告 / 健康訴求)であり、SaaS のように「核機能を無料で見せて、まとめて使いたい人に有料」というモデルになっている。逆に「核機能自体を有料化する」「無料はサンプル数件まで」というレシピアプリは長期的には伸びていない。

テクラル研究所からの提案 — レシピアプリ的構造を自社プロダクトに転用するには

ここまでレシピアプリ 3 社を「ポジショニング・オンボーディング・コンテンツ調達ミックス・課金境界」の 4 軸で構造比較してきた。最後に、自社プロダクト(レシピアプリだけでなく、C 向けコンテンツアプリ・フリーミアム SaaS 全般)に転用できる設計原理を 4 つに圧縮する。

原理 1: 「レシピアプリ」のような機能ドメインで企画しない。陣地で企画する

クックパッドは「投稿 × テキスト」、DELISH KITCHEN は「編集部 × 動画」、クラシルは「編集部 × 動画 × 献立提案」というふうに、3 社はそれぞれ違う陣地に立っている。機能ドメイン(レシピアプリ)で企画すると、3 社の機能を全部盛りした「どこにも刺さらないプロダクト」ができる。「動画もある、投稿もある、献立も提案する」と並べた瞬間に陣地が消える。「自社はどの陣地を取りに行くか」を最初に 1 つ決めて、後段の機能・UI・課金は全部そこから逆算する。

原理 2: オンボーディング step 数は「核機能の押し方」で決める

「離脱を減らすためにオンボーディングは最短にせよ」というセオリーは、核機能が「検索」「閲覧」「単一タスク」レベルの場合だけ正解だ。レシピアプリでも、クックパッド型(検索が核機能)は最短、DELISH KITCHEN 型(動画体験が核機能)は 1 動画見せる、クラシル型(献立提案が核機能)は 1 サイクル踏ませる、というふうに核機能の押し方で step 数が変わる。自社プロダクトで「初回タスク完了率を上げたい」と思ったら、まず「核機能が伝わる初回タスクとは何か」を定義し直す必要がある。短くするのは目的ではない。

原理 3: コンテンツ調達ミックスは UX のすべての土台。先に決める

レシピアプリ 3 社の UX の違いは、突き詰めれば「コンテンツをどう仕入れているか」に集約される。投稿型は CGM ガバナンス・品質ばらつき・人気順という追加レイヤーが必要で、編集部型は固定費・レシピ数の物理的上限・タイアップ余地という制約が乗る。UI / UX を考える前に、コンテンツ調達ミックスを決める。これは C 向けコンテンツ事業だけでなく、テンプレート系 SaaS・ライブラリ系プロダクト・教材系プラットフォーム全般に当てはまる。

原理 4: 課金境界は「核機能の周辺」に引く。核機能自体を有料にしない

3 社とも核機能(レシピを見る)は無料で開放し、有料化はその周辺(品質ソート・保存上限・広告非表示・健康訴求)に寄せている。フリーミアム SaaS でも同じで、ユーザーが「これは使える」と感じる前に課金壁にぶつかると、無料転換ファネルが詰まる。「核機能を完全に体験できる無料」と「核機能を快適に使い込むための有料」という二段構えで線を引くのが、レシピアプリから学べる課金境界の設計原理だ。

レシピアプリは表層では「自動連携 + 動画 + 検索」という似た機能を持つが、3 社はそれぞれ違う陣地に立ち、違う LTV モデルを取りに行っている。自社プロダクトを企画する際、まずは「この 3 つのうちどの陣地に近いか」を意識した上で、オンボーディング・コンテンツ調達・課金境界を逆算するのが近道だ。

テクラル研究所が支援できること

テクラル合同会社は、レシピアプリのような C 向けコンテンツアプリ・フリーミアム SaaS の UX 設計と開発を伴走で支援しています。本稿で分析した「陣地の選択 → オンボーディング → コンテンツ調達 → 課金境界」というフレームを、自社プロダクトの初期企画・既存プロダクトのリニューアル・新規領域の MVP 開発に当てはめて、構造から作り込みます。

  • C 向けアプリの初期企画: 競合 3 社の構造分析 → 自社の陣地選択 → MVP スコープ確定までを一気通貫で支援
  • 既存プロダクトの UX 診断: 現状の核機能・オンボーディング・課金境界を分解して改善余地を抽出
  • フリーミアム設計のレビュー: 課金境界の引き方・無料の天井・転換率の構造改善

レシピアプリやその周辺領域でプロダクトを企画・改善したい方は、構造分析からのご相談を承っています。お気軽にお問い合わせください。

出典

この記事を書いた人

テクラル研究所 編集部

テクラル研究所 編集部

テクラル研究所

テクラル合同会社が運営する「テクラル研究所」の編集部。Web・アプリ・SaaS プロダクトの市場リサーチ、UI/UX 分析、収益化設計を専門領域に、開発会社ならではの「作る側の解像度」で記事と一次リサーチ資料(ホワイトペーパー)を発信しています。MVP 開発、SaaS 構築、AI 機能組み込みの現場知見を活かし、フレームワークと数値で語ることを編集方針としています。

関連レポート

レシピアプリ UX 構造分析 — クックパッド/DELISH KITCHEN/クラシル | テクラル研究所 | テクラル研究所 | テクラル - プロダクトエージェンシー