Tabelog Tech Blog

食べログの開発者による技術ブログです

エンジニア主導のUI/UX改善:Vibe Codingによる試作アプリ量産で意思決定を高速化した話

目次

はじめに

こんにちは、食べログ開発本部アプリ開発部 ノートチーム iOSエンジニアの森川です。

私たちのチームでは、食べログノートの開発を担当しています。 食べログノートは、飲食店の業務を支援するオンライン予約台帳サービスです。電話予約や各種グルメメディアからのネット予約を一元管理できるほか、顧客管理機能などを提供しており、多くの飲食店様にご利用いただいています。

多くの飲食店様にご利用いただいているからこそ、UI/UXに関する貴重なご要望も日々多く寄せられます。 そんな中、「このUI/UXの改善、もっと早く飲食店様に届けられないだろうか?」という問いは、私たちが常に向き合っている課題でした。多くの開発案件が並行して進む中で、1つ1つの改善案の価値を迅速に検証し、意思決定するには難しさがあったのです。

本記事では、この課題に対し、エンジニアがVibe Codingで「試作アプリ1」を素早く量産することで、UI/UX改善の意思決定を劇的に高速化した事例についてお話しします。

この記事が、AIを活用して、エンジニアとして上流工程からより価値を発揮したいと考えている方々のヒントになれば幸いです。

UI/UX改善を行う上で直面した課題

食べログノートにおける従来のUI/UX改善は、次のようなプロセスで進められていました。

  1. 企画担当者が、飲食店様からのご要望やメンバーからの改善提案などを元に課題を整理し、エンジニア、デザイナーを交えて要件を定義する。
  2. 企画担当者が優先順位を判断して案件化し、デザイン作成、開発へと進む。

このプロセスは着実に改善を進める上で有効であり、実際に多くの改善を実現してきました。しかし、私たちは案件化するまでの意思決定のスピードにさらなる向上の余地を感じていました。

その背景には、飲食店様から寄せられるご要望の多様さがあります。既存機能の小さな改修で済むものから大規模な新機能開発が必要なものまで、その内容は様々です。そして、すべてのご要望を1つ1つこのプロセスに乗せて検討するには多くの時間が必要となります。さらに、UI/UX改善以外にも多くの開発案件が進行しており、私たちが割けるリソースは限られていました。

この課題に対し、私たちエンジニアが貢献できることはないかと考えました。

「Vibe Codingで試作アプリ量産」という突破口

前章で述べた意思決定スピードの課題に対し、「試作アプリ」が関係者の目線を揃え、議論を加速させる強力なツールであることは、以前から認識していました。しかし、「時間をかけて作ったのに不採用になる」というリスクが常に付きまとい、なかなか実行に移せずにいました。

このジレンマを解決する鍵こそが、Vibe Coding2でした。

Vibe Codingとは、AI(大規模言語モデル)に対して自然言語で指示を出し、対話的にコードを生成・修正させていく新しいプログラミング手法です。Andrej Karpathy氏によって提唱され、開発者は細かな実装をAIに任せ、"Vibe"(雰囲気やノリ)を伝えながら開発を進めるスタイルを特徴としています。

やりたいことを大まかに伝えるだけでAIがコードを生成し、エラーが出ればその都度修正する。このサイクルを繰り返すことで、驚くべき速さでアイデアを形にできます。

しかし、このアプローチにはトレードオフも存在します。AIは既存の膨大なコードベースが持つ設計思想や、暗黙的なルールまでを完全に理解しているわけではありません。そのため、生成されたコードは短期的に動くとしても、システム全体との整合性に課題を残す可能性があります。この「品質の不確実性」という問題は、特に大規模で高い品質基準が求められるプロダクト開発において、無視できないリスクとなります。 ですが、あくまで意思決定を目的とした「試作アプリ」であれば、この品質の不確実性は許容できます。

このように、高速実装というメリットを最大限に活かしつつデメリットを許容できる試作アプリ開発は、Vibe Codingを適用する上で、まさにうってつけの領域だったのです。

Vibe Coding実践ルール

私たちのチームでは、以下のルールを定めてVibe Codingによる試作アプリ作成に取り組みました。

試作アプリの要件

まず、Vibe Codingで取り組む対象を以下のように絞り込みました。

  • 実際に触らないと価値が分かりにくいUI/UX改善: アニメーションの滑らかさや、画面遷移の心地よさなど、言葉で説明するよりも「動くもの」を見せることに価値があるものに絞りました。
  • 実現性の見通しが立っているもの: 実現方法が不確実なものは、エンジニアからAIへの指示が的確に行えず、完成までの試行錯誤に多くの時間を費やしてしまいます。結果として20分以内に「動くものが作れない」という事態に陥ることが経験上多かったため、確実に見通しの立つものに対象を絞りました。

制限時間

Vibe Codingの「工数をかけずに素早く形にする」というメリットを活かすため、制限時間を20分に設定しました。 この時間内にビルドエラーの修正や微調整を済ませ、既存アプリへ統合した状態の試作アプリを作成しました。

実装者に求められるスキルレベル

このアプローチにはアーキテクチャの深い理解や高度なパフォーマンスチューニングのスキルは不要で、むしろ以下のような基本的なスキルセットが重要です。

  • Vibe Codingで生成されたコードを、既存アプリに統合し、ビルドを通せる。
  • 発生したビルドエラーを読み解き、基本的な修正ができる。

AIが生成したコードは、そのままでは動かないことも少なくありません。その「あと一歩」を人間が補助し、動く状態に持っていく作業はどうしても発生します。このため、エンジニア以外の職種の方が一人で完結させるのは難しいのが現状です。

一方で、20分という制限時間内では、実装者のスキルレベルによる成果物の差はほとんど見られませんでした。プロダクトコードのような厳密な品質が求められない試作アプリだからこそ、多くのエンジニアが気軽に挑戦できるのです。

使用したAIツール

今回の取り組みでは、AIコードエディタのCursorを用いました。Cursorは自律的にタスクを実行するAIエージェントの側面も持ちますが、今回は人間が主導権を握るAIアシスタントとしての側面に焦点を当てて使用しました。 その理由は、Vibe Codingの 「雰囲気を伝え、実際に動くものを見ながら対話的に進めていく」 という思想が、AIアシスタントの特性と完全に合致していたからです。

特に、UI/UX改善の「なんだか使いにくい」といった曖昧な課題を解決する際、その「雰囲気」や「操作感」を事前に完璧な仕様書へ落とし込むことは非常に困難です。もしAIエージェントを使おうとすると、まさにこの困難な「仕様化」のプロセスが求められます。これは、Vibe Codingが目指す迅速なプロトタイピングという本来の趣旨から外れてしまいます。

一方、AIアシスタントであれば人間が常に主導権を握れます。曖昧な指示から生まれた最初のコードを動かし、「もう少しこうして欲しい」と感じたことを即座にフィードバックできます。 この「作って、見て、感じて、修正する」というサイクルをリアルタイムに回すプロセスこそ、言葉にしにくい「Vibe」を具体的な形にしていく上で極めて効果的でした。

Vibe Codingによる試作アプリ量産が、UI/UX改善の意思決定をどう変えたか

実践ルールに則り、私たちは開発プロセスを以下のように見直しました。最大の変化は、改善の起点を、企画担当者からエンジニアへとシフトさせたことです。

エンジニアが起点となる新しい開発プロセス

  1. エンジニアが主体となって、飲食店様からのご要望やUI/UX改善案をピックアップします。
  2. 選定した改善案に対し、エンジニアがVibe Codingで20分以内に試作アプリを作成します。
  3. 完成した試作アプリを元に、エンジニアが「案件化会議」を主催し、企画・デザイン担当者を巻き込みます。
  4. 会議で承認された案件は、試作アプリのコードを参考にしながら、エンジニアが設計・実装を進め、リリースします。

開発プロセスの比較

このように、エンジニアが自ら改善の種を見つけ、動く形にしてから関係者に提案する、というエンジニア起点のアプローチに変わりました。

この新しいプロセスは、主に「案件化の意思決定」と「開発」の2つのフェーズで効果を発揮しました。

成果①:案件化の意思決定が爆速に。30分で5つの施策が案件化

最大の成果は、案件化に至るまでの意思決定が劇的に速くなったことです。 先日開催した30分の案件化会議では、用意した8つの試作アプリのうち、5つの施策がその場で案件化されました。1件あたりに換算すると、わずか3分で意思決定が完了したことになります。

これは、試作アプリという具体的な「動くもの」をベースに議論した結果、関係者間の認識齟齬が減り、UI/UXの評価や改善点の特定がスムーズに進んだためです。

具体的な事例として、以下のような改善を試作アプリで実現しました。

【事例1】iPhone版卓情報の表示改善

課題

食べログノートのタイムスケジュール画面では、iPad版では卓の詳細情報(喫煙/禁煙、利用可能人数)が表示される一方、画面サイズの制約からiPhone版では卓名と定員数しか表示されていませんでした。これにより、特に多くのテーブルを管理されている飲食店様から「卓名だけではどのテーブルか瞬時に判断しづらい」という声が寄せられていました。

解決策

そこで、タイムスケジュールの表示エリアが少し狭くなることを許容し、詳細情報を表示したいというニーズに応えるため、「iPhone版でも卓の詳細情報を表示する」という設定を追加する改善案を考えました。

Vibe Codingによる試作アプリ作成

AIとの対話は、以下のように進みました。

1. 最初の指示:大まかな要望を伝える

まずは、実現したいことの全体像を伝えます。既存の実装を参考にすることで、AIがより文脈を理解しやすくなります。

iPhone版タイムスケジュールの卓情報の表示 / 非表示をトグルで選択できるようにしたい。
iPadで現在表示している情報を、
- トグルをオンにしてセルの横幅だけ広げて
- 卓名は1行、詳細情報は2行目以降に表示
するようにしてください。
既存のiPadの実装を使うと楽だと思います

AIの応答と次の指示

この指示で、AIは期待とは異なるファイルに実装を行ってしまいました。そこで、次に対象ファイルを明確に指示し、修正を依頼します。

2. 修正指示:対象ファイルと実装箇所を明確にする

すみません、やってほしいことは以下です
- (対象ファイル)の表示をトグルボタンを押したらiPhone版でもiPadと同様の表示を行うこと
- トグルボタンはタイムスケジュールの表示設定画面に設置してください

AIの応答と次の指示

次は、トグルを切り替えた際の画面更新処理(ライフサイクル)が誤っていました。これを修正するよう、さらに具体的に指示します。

3. 再修正指示:ライフサイクルを修正する

ありがとう。以下のように修正して
- タイムスケジュールの表示設定でトグルを変更した際はタイムスケジュールの全更新を行って(卓軸を含む)
- (対象ファイル)の座席セルの横幅も、iPhoneであってもトグルに合わせて変更できるようにして

4. 最終調整:手動での仕上げ

AIが生成したコードには、レイアウトの不具合やライフサイクルの誤りが残っていました。しかし、UIパーツや処理の大枠はできていたため、これらを元にエンジニアが手動で修正。この最終調整により、数分で試作アプリが完成しました。

Before After
既存のタイムスケジュール iPhone版卓情報の表示改善

【事例2】スクロール時の表示エリア拡大

課題

iPhoneのような画面サイズの小さいデバイスでタイムスケジュールを長時間操作していると、画面上部に常に表示されているヘッダーやボタン類が、可視領域を狭めてしまうという課題がありました。

解決策

そこで、タイムスケジュールをスクロールしている間は、一時的にヘッダーやボタン類を非表示にし、表示領域を最大限まで拡大するという改善案を考えました。

Vibe Codingによる試作アプリ作成

1. 最初の指示:実現したいアニメーションを伝える

まずは、どのようなUIの挙動を実現したいのか、その"Vibe"(雰囲気)を伝えます。

タイムスケジュールのスクロールで、タイムスケジュールを全画面表示したい。
スクロール中は、本日のネット予約を止めるボタン及び本日に戻るボタンを非表示にしてください。
また、スクロール中は、メモ、予約カセットの表示設定などが設定されているヘッダーを非表示にしてください

AIの応答と次の指示

UIパーツの非表示は実現できましたが、アニメーションがなかったため、アニメーションの追加を指示します。

2. 修正指示:アニメーションを追加する

ありがとう。ヘッダーを非表示, 表示にする際に、アニメーションをつけることはできますか?

AIの応答と次の指示

次は、アプリの初回起動時にもUIパーツが非表示になってしまうという、意図しない不具合が発生しました。これを修正するよう依頼します。

3. 再修正指示:初回起動時の不具合を修正する

すみません、アプリ初回起動時にヘッダーと本日のネット予約を止めるボタンが非表示になってしまいます。
これを表示にしてもらえませんか?

AIの応答と次の指示

最後に、非表示にしたくないUIパーツまでアニメーションしてしまう問題が残っていました。ファイル名を具体的に指定して、対象外とするよう指示します。

4. 最終調整:対象外のファイルを指定する

ありがとう。時間軸(ファイル名)と交点(ファイル名)は非表示にしないでください

この指示で、期待通りの試作アプリが完成しました。

Before After
既存のタイムスケジュール スクロール時の表示エリア拡大

これらの試作アプリ開発によって、高速な案件化の意思決定が可能になりました。

成果②:開発工数が半減。5件のリリースを2日間で達成

エンジニアが作成した試作アプリのコードは、開発に関する意思決定の質と速度も向上させました。

  1. 実装の方向性の明確化:試作アプリの時点で実装すべき箇所や扱うべきデータがある程度見えているため、開発が非常に迅速になりました。
  2. 実装の参考コード化:特にUIパーツの実装においては、試作アプリのコード構造をほとんど流用できるケースもありました。

もちろん、試作アプリのコードも完璧ではありません。データの取り扱いがSSoT(Single Source of Truth)でなかったり、複雑な画面におけるエッジケースが考慮されていなかったりなど、特にデータ周りは開発で全面的に修正が必要なものもありました。 しかし、これらを差し引いても、ゼロから設計・実装するのに比べて、その効果は絶大でした。

これらの相乗効果により、従来であれば4日間程度必要だった開発工数を、わずか2日間へと短縮。先に案件化された5件の施策を、2日間でリリースするという、これまでにないスピードを達成できました。

まとめ:Vibe Codingが拓くエンジニアの新たな可能性

今回の取り組みを通じて、Vibe Codingはエンジニアがより事業へ貢献する強力なアプローチであることを示せました。

エンジニアがVibe Codingを使いこなし、高速に試作アプリを量産する。この新しいプロセスは、UI/UX改善における意思決定のあり方を大きく変えました。従来のように企画やデザイナーと要件を固めてから開発に進むのではなく、動く試作アプリを起点に全員で議論し、素早く案件化の判断を下すスタイルへとシフトしたのです。これにより、企画やデザインに関わるメンバーの負担を軽減しつつ、エンジニアはこれまで以上に案件化の意思決定プロセスへ貢献できるようになりました。

さらに、このアプローチが特定の高度なスキルを持つエンジニアでなくても実践可能であることも大きな発見でした。この結果、今回の取り組みは一度きりの成功で終わることなく、チームに再現可能なプロセスとして定着しました。実際に開発工数を半減させるという成果も達成しており、これは今後のUI/UX改善においても持続可能です。

今後の展望

今後は、このプロセスの一部をAIエージェントに任せることで、さらなる効率化が図れないかを検証していきたいと考えています。例えば、飲食店様から寄せられたご要望をインプットとしてAIが試作アプリを自動生成し、エンジニアがそれをレビューして手直しを加える、といった協業の形です。

その実現には、AIエージェントが私たちの意図を汲み取り、より精度の高い試作アプリを生成できるよう、アプリの仕様や設計思想といった情報を継続的に与える必要があります。

終わりに

AIとの対話を通じてエンジニアのアイデアは瞬時に形となり、案件化の意思決定でより大きな価値を発揮できるようになります。本記事を通じて、Vibe Codingが拓く、そんな新しい開発の可能性を感じていただけたなら幸いです。

最後に、本記事で紹介したように、食べログではエンジニアが主体となり、Vibe Codingのような新しい開発スタイルを積極的に活用する文化があります。魅力を感じていただけた方は、ぜひ以下の採用ページをご覧ください!


  1. ここでは既存アプリと統合された、実際に動作するデモンストレーション可能なアプリを指す。ステークホルダーとの具体的な議論や意思決定を促進する品質を持つ。
  2. What is vibe coding? | Google Cloud