はじめに
こんにちは！ 2025年の夏、株式会社エブリーで1ヶ月間インターンシップに参加している常木泰成です。配属されたのは、国内最大級のレシピ動画メディア「デリッシュキッチン」のデータを活用して食のトレンドを分析し、メーカー・小売の意思決定をサポートする「デリッシュリサーチ」部門です。
この1ヶ月間で私が取り組んだのは、動画視聴データを用いた新たなトレンド分析機能の開発です。この記事では、ユーザーの隠れたニーズから機能開発の背景、そして人生初のSQLと格闘しながらデータを可視化するまでの技術的な裏側を伝えていければと思います。
背景 なぜ「動画視聴データ」の分析が必要だったのか？
デリッシュキッチンアプリの検索データ・レシピ閲覧データをもとに、消費者の食トレンドや興味関心を分析できるツールです。消費者分析や調査などの工数削減や、お客様のニーズを踏まえた商品開発／販促を実現でき、施策の確度も高めることが可能です。 すでに検索頻度ランキングなどの機能は存在していましたが、既存ユーザーへのヒアリングから、さらに深いインサイトを求める声が明らかになってきました。
ユーザーが本当に知りたかったこと:
「今週、『鶏肉』の検索が増えた」という事実（点）だけでなく、「なぜ増えたのか？具体的にどんな鶏肉料理（ジャンル）が人気なのか？」（線）を知りたい。
特定のレシピが人気な理由、例えば「このハンバーグが人気なのは、"時短" や "節約" といったタグが響いているからではないか？」という背景（面）を捉えたい。
消費者が「今、本当に作りたい料理」のトレンドを、より解像度高く把握したい。
これらのニーズは、単一のレシピ人気を追うだけでは満たせません。そこで必要になってくるのが動画視聴データとレシピに付与されたタグです。
ユーザーがどのレシピ動画をいつ視聴したか、そしてそのレシピにどんなタグ（例：「#簡単」「#鶏むね肉」「#お弁当」）が付いているかを掛け合わせることで、特定のタグを持つレシピ群が、いつ、どれくらい見られているかを時系列で可視化できます。これにより、「点」の分析から脱却し、トレンドの「線」と「面」を捉えるインサイトを提供できると考えました。
この仮説に基づき、指定したタグに合致するレシピの視聴トレンドを時系列グラフで可視化し、期間内で特に人気だったレシピをランキング形式で提示する、という新機能の開発プロジェクトがスタートしました。
データ加工 初めてのSQL
今回の開発では、データ基盤としてDatabricksを利用しました。デリッシュキッチンから送られてくる膨大な視聴ログデータを、SQLを使って抽出・加工し、BIツールであるAmazon QuickSightでビジュアルを作成するのが主な流れです。
ここで私の前に立ちはだかったのが、人生初のSQLでした。最初はSELECT * FROM ...すらおぼつかない状態でしたが、エブリーに代々受け継がれる「SQLもくもく資料」と、メンターの熱心なご指導のおかげで、最終的には最低限のリファレンス込みで複雑なクエリを読み書きできるレベルに成長できました！
SQLか、Python(Pandas)か？
データ加工と聞いて、最初は「SQLを使用しなくても、PythonのPandasライブラリでも同じことができるのでは？」と考えていました。しかし、インターンを通じて、大規模データを扱う上でのSQLの優位性を感じることが何度もありました。
データ集計とクエリの最適化
SQLは、データベースから必要なデータを効率的に抽出・集計するために最適化された言語です。GROUP BY, JOIN, WHEREといった命令は、データベースエンジンが最も効率的な実行計画を立てて処理してくれるため、テラバイト級のデータに対しても非常に高速です。一方、Pandasはデータを一度メモリに全て読み込んでから処理するため、データサイズが大きくなるとメモリ不足に陥ったり、パフォーマンスが著しく低下したりする可能性があります。データの整合性
データベースでは、スキーマ定義（PRIMARY KEY, FOREIGN KEYなど）によって、データの重複や不正な値をシステムレベルで防いでくれます。これにより、データの品質が担保され、アプリケーション側は安心してデータを扱えます。もしこれをPythonのコードだけで実現しようとすると、あらゆる処理に整合性チェックのロジックを自前で実装する必要があり、非常に煩雑になります。効率的な差分更新とトランザクション
今回のプロジェクトでは、毎日増え続ける視聴ログデータを効率的に集計テーブルへ反映させる必要がありました。もしPandasで実装するなら、「過去の全データを読み込み、今日のデータを追加し、全データを書き出す」という非効率な処理になりがちです。しかし、Databricksが採用しているDelta Lakeという技術と、それを操作するPySparkコードを使えば、この課題を解決できます。
実際に書いたコードがこちらです。
# 毎日増分の更新をする column_selected_filtered_data\ .write\ .format("delta")\ .mode("overwrite")\ .partitionBy("event_date")\ .option("replaceWhere", f"event_date >= '{event_date}'")\ .save("delta_table_path/sample_analytics_table")
注： 実際の開発では、弊社内のデータ基盤に合わせてテーブル名やスキーマ構造を調整しています。
このコードは、単にデータを上書きしているのではありません。
partitionBy("event_date"): まず、データがevent_date（日付）ごとに物理的に分割して保存されています。option("replaceWhere", ...): そして、このオプションで「event_dateが指定した日付以降のデータのみを置き換える」という指示を出しています。
これにより、過去の膨大なデータを一切触ることなく、直近のデータだけを更新できます。ファイルベースで処理を行うPandas単体では、同様の効率性と安全性を担保するのは非常に困難です。
SQLコード解説
インターン中に書いた、特に印象的だったクエリの一部をご紹介します。
SELECT
l.event_date,
r.recipe_id,
CONCAT(r.lead, r.title) AS title,
r.image,
r.tags,
r.ingredients,
r.category,
r.taste
FROM
distinct_event_dates AS l
CROSS JOIN
recipe_master AS r
WHERE
r.advertiser_id IS NULL
このクエリの主役はCROSS JOINです。SQL初学者だった私は最初この仕組みの理解に苦しみました。
CROSS JOINは、2つのテーブルの全レコードを総当たりで組み合わせる結合方法です。このクエリでは、distinct_event_dates（分析対象期間の日付リストを持つテーブル）とrecipe_master（全てのレシピ情報を持つマスタテーブル）を掛け合わせています。
なぜこんなことをするのか？
これは、「分析期間中のすべての日付 × すべてのレシピ」の組み合わせを持つ、巨大な"設計図"のようなベーステーブルを作成するためです。
この後、実際の動画視聴ログを集計した動画視聴回数のテーブルとこのベーステーブルをLEFT JOINします。すると、たとえ特定の日にあるレシピが1回も視聴されなかったとしても、視聴数「0」のデータとしてきちんと残すことができるのです。これにより、時系列グラフが途切れることなく、正確なトレンド分析が可能になります。CROSS JOINは、時系列分析におけるデータ欠損を防ぐための、非常に重要なテクニックでした。
データを"見える化"する：Amazon QuickSightの活用
データパイプラインの最終工程は、加工したデータをビジネスの意思決定に繋げるための「可視化」です。ここで活躍したのが、AWSが提供するBIサービス、Amazon QuickSightです。
QuickSightは、Amazon AthenaやDatabricksといったデータソースに直接接続し、ドラッグ＆ドロップの直感的な操作でデータをグラフや表に変換し、インタラクティブなダッシュボードを高速に作成できるクラウドサービスです。
今回はQuickSightを使って、
- タグ（ジャンル）ごとの視聴数推移を示す折れ線グラフ
- 期間内で人気の高かったレシピのランキング表
などを盛り込んだダッシュボードを作成しました。(下の写真)これにより、ユーザーがボタン一つで最新のトレンドを把握し、メーカー・小売への提案に活かせるようになりました。
インターンシップを終えて：学びと今後の展望
この1ヶ月で得た大きな学び
このインターンシップは、私にとって初めて尽くしの1ヶ月でした。特に、技術面とマインド面で大きな成長があったと感じています。
ビッグデータと常に隣り合わせの最適化思考: 個人開発では意識することのなかった「データの巨大さ」に、良い意味で何度も殴られました。1つのクエリでもかなりの時間がかかることもあり、高速に結果を出すためのクエリパフォーマンスの最適化の視点が常に求められました。これは、データエンジニアリングの根幹に触れる貴重な経験でした。
「自分のため」から「チームのため」の開発へ:
git pushする指が震えたのも良い思い出です。ブランチ戦略、プルリクエストでの丁寧な説明、レビューでの的確な指摘。その全てが、「コードは書いた人だけのものではなく、チームの資産である」ということを教えてくれました。他人が読むことを前提とした、可読性の高いコードを書く意識が叩き込まれました。ユーザーのインサイトを「先回り」するプロダクト開発: 機能開発の背景にあったように、プロダクトは常にユーザーの課題解決のためにあります。「こんな機能があったら便利だろう」という仮説を立て、ヒアリングを通して検証し、ユーザーの思考を先回りして価値を提供する。この一連のプロセスを間近で体験できたことは、今後のキャリアの礎になるはずです。
これから挑戦したいこと：「なぜ」を解き明かすトレンド分析へ
今回開発した機能は、食のトレンドを可視化する大きな一歩となりました。しかし、同時に新たな課題と、より大きな可能性も見えてきました。
動画視聴データは、テレビ番組での紹介やSNSでの拡散によって、ごく短時間で爆発的に再生数が伸びる（バズる）という特徴があります。また、季節性の変動も大きく、実は多くの要素が絡み合って複雑になっています。現状では、データの膨大さからダッシュボードの表示に時間がかかってしまうというパフォーマンス面の課題も残っています。
そして何より、今後挑戦したいのは、「何が流行っているか」を提示するだけでなく、「なぜそれが流行っているのか」というインサイトまで提供することです。
例えば、「"鶏むね肉"の視聴数が急増した」という事実だけでなく、「それは、人気テレビ番組で"節約"をテーマにした特集が組まれ、SNSで"簡単でおいしい鶏むね肉レシピ"という投稿が拡散されたからだ」という背景までを解き明かしたい。いわば、バズの因数分解です。
この「なぜ」を解き明かすことができれば、デリッシュリサーチはメーカー・小売に対して、より精度の高い需要予測や、効果的な販売戦略の立案をサポートできるはずです。
最後になりますが、1ヶ月間温かく、そして熱心にご指導くださったメンターの皆様、デリッシュリサーチ部門の皆様、本当にありがとうございました！
