CASE STUDY 001 / SENDAI ERABU!
897の演奏枠を、
1分で「自分だけの一日」へ。
音楽の好みだけではない。その日の気分、使える時間、どこから始めるか、どれくらい歩くか、新しい音にどれくらい出会いたいか。大量のタイムテーブルを眺める代わりに、その人の状況から一日の体験を組み立てる「MY JAZZ DAY」を企画・開発しました。
Data snapshot: 2026-09-02 00:23 JST / 公開情報をもとに「仙台えらぶ！」が整理したデータスナップショットです。1 MINは操作体験の設計目標であり、実測値を示すものではありません。
「情報がない」のではなく、
情報がありすぎて選べない。
大規模な音楽イベントでは、タイムテーブル、出演者、会場、時間帯など、膨大な情報が公開されます。しかし利用者が本当に知りたいのは「出演者が何組いるか」だけではありません。
知りたいのは、「今日の自分なら、どこへ行けばいいのか」。897の演奏枠を一覧として提供するだけでは、その問いには答えられません。
897件を検索しやすくするのではなく、897件から選ばなくてもいい状態をつくる。
人は、ジャンルだけで
音楽を選んでいるわけではない。
同じJazzが好きな人でも、「今日はゆっくり聴きたい」「知らない音に出会いたい」「仙台駅から始めたい」「あまり歩きたくない」「夕方までしか時間がない」では、成立する一日が変わります。
5つの問いから、
今日の一日を組み立てる。
専門用語や複雑な検索条件を入力させず、利用者が日常的に答えられる問いへ変換しました。普段ジャズを聴かない人でも一日を作れることを前提にしています。
「好きそう」だけでは、
一日は成立しない。
推薦するのは単体の出演者ではなく、時間の衝突や移動可能性まで含めた「実際に過ごせる一日」です。単純なジャンル一致ではなく、Taste / Context / Constraintを組み合わせて候補を構成します。
Taste / Mood
Time / Location
Walking / Discovery
推薦するのは「出演者」ではなく、実際に過ごせる「一日」です。
Recommendationの前に、
信頼できるデータをつくる。
推薦ロジックが高度でも、入力データが不正確なら利用者の一日は成立しません。公開された公式情報をもとに、出演者、演奏日時、ステージ、会場、所在地、関連リンクなどをサービスで利用可能な構造へ整理し、確認状態を管理できる設計にしています。
AIに選ばせる前に、選ばせてよい情報かを確認する。
選んだ後も、
街の中で使える。
推薦結果はタイムテーブルだけで終わりません。保存した順番と会場位置を地図上で確認し、イベント当日にホーム画面から再利用できる体験まで接続しています。
UIだけではなく、
意思決定までをシステム化する。
このプロジェクトでは画面制作だけでなく、データ構造、推薦ロジック、状態管理、位置情報、保存、PWA、Analyticsまでを一つのユーザー体験として設計しています。
この事例で実装したこと。
利用者の意思決定を起点にしたプロダクト企画。
複雑な検索条件を5つの問いへ変換。
出演・会場・時間・確認状態の構造化。
Taste / Context / Constraintを用いた推薦。
公開情報の確認状態と更新基準を設計。
推薦結果を実際の街と移動へ接続。
イベント当日の再利用を前提にした導線。
選択・保存・遷移を計測できるイベント設計。
この問題は、
音楽イベントだけのものではない。
「選択肢が多すぎて、顧客が選べない」。同じ構造はさまざまな事業に存在します。SGPでは、検索を便利にするだけでなく、選択そのものを設計するプロダクトを企画・開発します。
多数の施工プラン → 暮らし方に合わせた提案
多数の物件 → 生活条件から候補を構成
多数のスポット → 一日の過ごし方を推薦
多数の商品 → 好みと用途から選択肢を絞る
多数のサービス → 来店目的から最適メニューを提示
大量の情報 → 次に取るべき行動を提示
LET'S BUILD
御社にも、
「選べない」はありませんか？
商品が多すぎる。情報が散らばっている。提案に時間がかかる。顧客ごとに最適な案を出したい。そうした問題を、Web、AI、データ、業務設計を組み合わせて「選べる仕組み」へ変えます。