🥁

【Figma Make】みんなを笑顔にするドラムロールアプリに必要な機能の検証(生成AI,UIデザイン,プロトタイピング)

に公開

みんなを笑顔にするドラムロールアプリに必要な機能の検証

みんなを笑顔にするドラムロールアプリに必要な機能の検証

先日、Figma Makeを使ってドラムロールアプリを開発しました。
この記事では、生成AI時代のプロトタイピングがどれだけユーザー体験を良くするか、その経験を通じて得た知見を紹介しています。

💡

Figma Makeやプロトタイピングに初めて触れる方が、「この手法は参考になりそうだ!」と感じてくれると嬉しいです。


Figma Makeとは?

Figma Makeは、「Make your ideas real with AI」を掲げるデザインツールです。
AIを使って、デザインのアイデアをすぐに動くプロトタイプにできます。

https://www.figma.com/ja-jp/make/

Figma Makeの主な特徴

主な特徴は以下の通りです。

  • チャット形式でAIに要望や修正指示を伝えると、即座にデザイン案やレイアウトを自動生成・反映
  • テキストによる細かな修正や追加指示も柔軟に対応
  • ノーコード・ローコードで直感的にUIデザインを作成できる
  • 生成したデザインはそのままWebで公開・共有可能

このツールは2つの主要なエリアで構成されています。
AIに指示を出せるチャットエリアと実際に動くアプリを確認したりコードを編集したりできるプレビューエリアです。

まず、会話形式でアプリの仕様を決めます。
表示されたUIを操作し仕様を検討し、AIとの対話を繰り返す中で仕様を更新します。
これにより、アイデアが「実現できるかどうか」を素早く試せるのが最大の魅力です。

Figma Makeでプロトタイピング

Figma Makeが登場したことで、従来のプロトタイピング手法が抱えていた課題が大きく変わりました。
たとえば、紙にUIを書いてイメージするペーパープロトタイプや、画像をつなげるモックアップがあります。
また、Figmaのプロトタイプ機能[1]のように画面上のデザインデータを使う方法だと、使うためにある程度の学習や設定作業が必要でした。

Figma Makeはコード実行環境を持っています。
そのため、技術的な学習コストを抑えつつ、実際に触れるプロトタイプを直感的な操作で素早く検証できるのです。

6時間でアプリのデザインの作成から公開まで

この記事では、Figma Makeを使って「みんなを笑顔にするドラムロールアプリ」のデザインを実際に作成した体験を紹介します。
最初は簡単なプロンプトから始まり、AIとの対話の中で、必要な機能や仕様の検討を繰り返し、公開するまでの流れを詳しく解説します。

これから紹介する初期仕様の策定から完成まで、実際にかかった時間は約6時間程度です。
このアプリを作成したいと思ったところから、公開まで具体的にこの流れで作業を行いました。

  1. ドラムロールアプリを作ろうと思ったきっかけ
  2. アプリの初期仕様を策定
  3. Figma Makeでアプリを検証
  4. 検証したものをそのままWebに公開
  5. 公開したアプリを使用

実際にできたアプリは以下のURLから確認できます。

https://hot-phase-46546285.figma.site/

人を笑顔にするドラムロールが欲しいのに!(ペイン)

レクリエーションを彩る効果音の役割

みなさんはこんな効果音を聞いたことはありませんか?

https://www.youtube.com/watch?v=LoeizoROfwc?rel=0

大会やレクリエーションなどのイベントで聞いたことがある方もいると思います。

効果音があることで、発表内容に強力なアクセントが加わり、聞き手の気持ちを盛り上げます。
それは、会場の一体感や期待感をグッと高める、欠かせない役割を持っていると私は考えています。
単なるBGMではなく、とても大事な「効果」を演出できます。

既存の手段が内包する操作上の課題(ペイン)

しかし、この役割を果たそうと既存の手段を探すと困った問題が見えてきました 。Google PlayなどのアプリストアやYouTubeの音源では、「会場の雰囲気に合わせた操作ができない」という課題がありました。

💡 → 😭

ひとつめに、アプリストアには種類がたくさんあっても本当に求めていた音源か、インストールしてみないとわからないという課題です。
ふたつめに、YouTubeにも多く再生されている音源が公開されていましたが、ドラムロールとシンバルがセットになっているケースが多く、任意のタイミングでドラムロールとシンバルを切り替える操作ができないという課題です。

既存の手段の決定的な弱点は、「求めている雰囲気に合わせた音源を使えないこと」と「ドラムロールの長さを自由に変えたい」というリクエストに応えられないこととです。この弱点があるために、発表者の希望や会場のムードに合わせられません。

検証プロセスにおけるコスト削減の戦略

イベントに参加している人たちを笑顔にするためにドラムロールを用いたいと調査してみた結果、必要なのは高品質な「音源」ではなく、「柔軟なインターフェイス」を持つアプリケーションだと考えました。会場の雰囲気をコントロールできるインターフェイスが必要です。

このアプリケーションを一からコードで実装すると、時間もリソースもたくさんかかることは容易に想像できました。
そこで、時間をかけずに手段を用意するために今回はFigma Makeを選んでいます。

解決したい課題と初期要件

レクリエーションを盛り上げるための要件定義

最初にレクリエーションを盛り上げるという目標のため、ドラムロールアプリには次の3つの初期要件が必要だと考えていました。

  • 音源の再生
    • 任意の音源を用いてドラムロールとシンバルの音を流せる機能を入れる
    • 意図的に音源をループさせてドラムロールの長さをコントロールできる
  • ユーザーによるタイミング制御
    • ユーザーが好きなタイミングで、ドラムロールからシンバルに切り替えられる機能
  • Webからアクセス
    • PCとモバイルから操作できるように、Webで使える
    • 共有リンクを発行できるFigma Makeの特性を活かす

💡 → 😭 → 🤔

初期要件には含まれていたが削除されることになった機能

初期の要件検討段階では、「ドラムロール部分を意図的にループできるようにする」というのも含めていました。

しかし、プロトタイピングを進める中で、この機能の実現可能性について体感的なフィードバックを得ました(後述のバージョン10を参照)。

具体的には、ループに適した音源を準備し、アプリ側でその音源をうまく調整するのが難しいと判断したため、最終的にこのループ機能を削除しました。

この経験は、高速な検証サイクルにおいて非常に価値のある体験でした。
机の上で決めた仕様にこだわりすぎず、体感的なフィードバックに基づき、機能の範囲を現実的に絞り込む柔軟性を実現できたと考えます。

Figma Makeによるプロトタイピングの実践

このプロジェクトでは、Figma Make内のAIと対話を行い仕様を決めていきました。
そして、実際に動くUIを操作しながら検証を繰り返していた結果、一晩でプロトタイプが完成しました。

💡 → 😭 → 🤔 → ✍

ここでは、20バージョンにわたる改善作業をフェーズに分けて解説します。
技術的な課題とUI/UXの改善という視点から詳しく説明します。

フェーズ1: コア機能の確立と情報設計 (バージョン1〜4)

プロトタイピングは、「ドラムロールを鳴らすアプリ」という抽象的な指示から始まりました。
AIはWeb Audio APIを使ったシンプルなUIを提案し、初期のベースがすぐに作られました。

バージョン1の具体的な内容

プロンプト

# アプリタイトル

ドラムロールを鳴らすアプリ

## UI

シンプルなUI
スマホでアクセスしても操作できる

## 仕様

- ドラムロールを流すことができる
- 意図的にループさせることができます
- 任意のタイミングでシンバルを鳴らすことができる

AIからの回答

ドラムロールとシンバルを鳴らすシンプルなアプリを作成します。Web Audio APIを使って音を生成し、スマホでも使いやすいUIにします。
ドラムロールアプリを作成しました!Web Audio APIを使用して、リアルタイムでドラムロールとシンバルの音を生成します。スマホでも快適に操作できるシンプルなUIで、大きなボタンを配置しています。

続くバージョン2と3では、ユーザーが音源ファイルをアップロードできる機能が追加されました。
また、どちらかのファイルを再生したら、もう片方を自動で止めるロジックが実装されました。
これで、音源再生と制御の要件が実現されています。

バージョン2の具体的な内容

プロンプト

添付したmp3ファイルを音源を使用することはできますか?

AIからの回答

はい、可能です!mp3ファイルを使用する方法を実装します。
ファイルをアップロードして使用できる機能を追加しますので、ドラムロール用とシンバル用のmp3ファイルを選択できるようにします。
[https://scrapbox.io/files/6933c868153426dddd3e4ff1.png]

バージョン3の具体的な内容

プロンプト

なるほど。では音声ファイルはユーザーが2つアップロードできる形にしてください。
どちらかのファイルを再生した瞬間に片方が再生していてた場合、停止するようにしてください

AIからの回答

アプリを更新しました!どちらかの音声を再生すると、もう片方が再生中の場合は自動的に停止するようになりました。

とくに、バージョン4で追加された「再生中の音声の残り時間表示機能」は重要でした。
これは単なる機能追加ではなく、要件の「ユーザーによるタイミング制御」を満たすために、重要な情報設計の要素でした。

ユーザーが任意のタイミングでクリティカルな操作を正確に行うには、今流れている音源の状態が目に見えることが不可欠です。
もしこの表示がなければ、「ドラムロールが再生できる残り時間を把握できず、音が途切れることを恐れて、早めにシンバルを再生してしまう」という操作を行ってしまいかねません。
この情報設計が、安心して操作できるインターフェイスを実現してくれました。

バージョン4の具体的な内容

プロンプト

再生中に音声の残り時間がわかるようにしてください

AIからの回答

アプリを更新しました!再生中の音声の残り時間が表示されるようになりました。

フェーズ2: 環境の制約とモバイル操作性の改善 (バージョン5〜9)

外部連携の可能性を検証

バージョン5から7にかけて、利便性を向上させるために仕様変更の検討を行いました。
アップロードする形式の場合、画面をリロードするたびにセットする手間を感じたため、Google Driveにアップロードした音声ファイルをデフォルトでセットできないか試みました。

バージョン5~7の具体的な内容

プロンプト

Google Drivにアップロードした音声ファイルを最初からセットしておけますか?
ドラムロールのURLは https://drive.google.com/file/d/{file_path}/view
シンバルのURLは https://drive.google.com/file/d/{file_path}/view
この2つのURLの音声ファイルが再生されるように変更してください

AIからの回答

Google Driveの音声ファイルをデフォルトでセットするように変更します。Google DriveのURLを直接ダウンロード可能な形式に変換して使用します。
アプリを更新しました!Google Driveの音声ファイルがデフォルトでセットされるようになりました。

AIからは「セットされるようになった」と報告をもらいましたが、実際に操作すると画像のようにクラッシュしました。

実際にFigma Make上で操作したときの画面です。

AIからは「ファイルが非公開の場合」や「CORSポリシーの制限」といった技術的な理由で、直接読み込めないことがあると指摘を受けました。

Google Driveのファイルは通常、以下の理由で直接読み込めないことがあります:

  • ファイルが非公開の場合
  • CORSポリシーの制限
  • 大きなファイルの場合、警告画面が表示される

「音源を変更」ボタンから、お手元のMP3ファイルをアップロードしてご利用ください。

もしくは、Figma Makeのコードを実行しているファイル群の中に音源データをアップロードできないかとも考えました。
ドラッグ&ドロップを試したり、調べてみたりしましたが、うまくいかなかったので、毎回アップロードが必要な仕様のままとしました。

曖昧な指示によるモバイル最適化

次に、縦長になってしまったUIを直すため、バージョン8では曖昧な指示を出しました。「一般的なスマホのサイズで全てのUIが表示されるようにしてください」という指示です。

バージョン8の具体的な内容

プロンプト

縦長のレイアウトになったので再構成してください
一般的なスマホのサイズで全てのUIが表示されるようにしてください

AIからの回答

スマホサイズで全てのUIが表示されるように、レイアウトをコンパクトに再構成します。
レイアウトをスマホサイズに最適化しました!主な変更点をまとめます。

(略)

これで一般的なスマホ画面(375px × 667px程度)でも全てのUIが表示されるようになりました。

AIは、この指示に対して、一般的なスマホ画面(375px × 667px程度)にすべてのUIが収まるようにレイアウトを再構成しました。
高速でモバイル最適化を実現してくれたのです。

調整が入るかもしれない初期段階で、すべての仕様を厳密に決めるコストは不要です。

  • まずはざっくりとした曖昧な指示から始められること

これはFigma Makeが実現する高速検証サイクルの最大の強みが現れた事例です。

微細なレイアウトの安定化の必要性

バージョン9では、再生中に残り時間のUI(プログレスバー)が表示されると、ボタンの位置が微妙にズレる現象を発見しました。

この「とても小さな位置ズレ」であっても、修正が必須だと判断しました。
なぜなら、会場でドラムロールが流れている緊張感のある状況では、操作ミスを引き起こし、「会場の間が悪くなる」という致命的な影響を及ぼすリスクがあるからです。

バージョン9の具体的な内容

プロンプト

音声を再生し始めたときに残り時間のUIが表示されるとレイアウトの表示位置がずれます

位置がずれるとボタンを押しにくいので、ユーザーの画面の操作で表示位置がずれないようにしてください

AIからの回答

これで音声の再生/停止時にボタンの位置がずれることなく、常に同じ位置で操作できるようになりました。ユーザーは安心してボタンを連続してタップできます。


再生前


再生後

AIは、具体的に「表示前に表示用のスペースを確保しておく」とは指示しなかったにもかかわらず、ユーザーの意図を汲み取りました。
再生前/再生後でレイアウトが変わらないように修正を実施してくれています。

このバージョン9の検証を通じて、小さなレイアウトのズレがユーザビリティに与える影響の大きさを再認識する機会となりました。

フェーズ3: 体験の質の向上と最終調整 (バージョン10〜20)

フェーズ3では、最終調整に向かいつつも、当初想定できていなかったところの調整を行っていきました。

バージョン10では、ループ機能の削除をしています。
当初の仕様でドラムロール部分を「意図的にループさせることができます」としていましたが、ループに適した音源を用意し、調整することが難しいと感じたために、ループ機能を削除しています。

次に、バージョン11から17にかけて、UI KitからSimple Design System[2]を選択し、UIの微調整を行いました。
見た目に悩む時間をかけずに体系的な調整を行うために、既存のデザインシステムをUI Kitから選択しています。

バージョン11~17で行った調整は以下のとおりです。

  • UI KitからSimple Design Systemを選択

    イメージ図
  • 背景グラデーションの削除
  • 各テキストのサイズ調整
  • ボタンが押しにくくないか表示サイズの確認
  • 再生中のシンバルボタンを押したときに停止できなかったので修正
  • アップロード前の再生ボタンが色がついていたので、アップロードが必要であることをイメージさせるためにグレーに変更

また、背景グラデーションの削除や、各テキストサイズの調整が含まれます。また、音源アップロードが必要な状態を視覚的に伝えるため、再生ボタンをグレーアウトする処理などが含まれています。

音響品質の決定的な改善:フェード処理の実装

この検証プロセスで最も重要だった改善の1つが、バージョン18と19で取り組んだ音声のフェード処理の実装です。
当初、片方の音声を再生するときにもう片方を急に止めるやり方では、ユーザーに違和感を与えそうと気づくことができました。

以下の動画でドラムロールの不自然さを感じてみてください。

https://drive.google.com/file/d/10x_tx1-2tOdHsM2tbrBbwCL2GtsGh0Ii/view?usp=sharing

私はこのドラムロールからシンバルに切り替わる音を聞いた時に、ドラムロールの残響がないことに違和感を感じました。
つまり、シンバルが再生される瞬間にドラムロールの音源が停止しているのは、現実世界の奏者がシンバルを鳴らす瞬間にドラムを手で抑えている演奏になってしまいます。

この違和感を解消するため、バージョン18で0.5秒かけてフェードアウトしてから停止するように変更しました。

バージョン18の具体的な内容

プロンプト

片方の音声を流す際にもう片方の音声を急に停止するのは違和感を感じたので、0.5秒でフェードアウトしてから停止するようにしてください
AIからの回答

これにより、片方の音声を再生する際に、もう片方が自然にフェードアウトしてから停止するようになり、違和感のないスムーズな切り替えが実現できました。

しかし、この段階でもドラムロールがフェードアウトしきってからシンバルがなるという違和感が発生しした。
そのため、バージョン19では、フェードアウトの開始と同時に新しい音声を再生する処理を追加しました。

バージョン19の具体的な内容

プロンプト

フェードアウトの開始と同時に片方の音声を再生してください

AIからの回答

これにより、片方の音声が0.5秒かけてフェードアウトしている間に、もう片方の音声が同時に再生開始され、よりスムーズで自然な音声切り替えが実現できました。

これで、よりスムーズで自然な音声切り替えが実現し、「リアルな音響体験」という体験の質を高められました。

https://drive.google.com/file/d/1q_j6W_N172CpJmEVTC_Mzm7J3cDF46U9/view?usp=sharing

この聴覚的な「間(ま)」の品質アップは、機能性の問題だけではありません。
アプリケーションが使われる場のユーザー体験(UX)を決定づけるポイントでした。
実際に操作して聞く「体感」がないと、発見も修正も難しかった課題です。

バージョン20では、最後に、どうしても細かな「間」を調整したい場合は、自分でコードを更新できることも確認しました。

「体感」によって気づけたプロトタイピングの重要性

「体感」なくして気づくことができないことばかり

ソフトウェア開発におけるプロトタイピングとは、試作品を作ることです。
設計上だけでは確証が得にくい性能や操作性の問題を、事前に見つけ出すための非常に便利な手法です。

実際に今回の取り組みでも、最初に想定していた仕様だけでは想定できていなかった問題を発見することができました。

Figma Makeのおかげで、この「試作↔操作↔考察」という検証サイクルを従来のツールよりもずっと直感的に回せるようになりました。

💡 → 😭 → 🤔 → ✍ → ❤️

机上の論理や静的なUIデザインの原則だけでは、視覚的に見えるものばかりの情報に囚われて、「操作することで得られる体感」に到達しづらかったと感じます。
この検証サイクルの過程で得られた教訓は、「体感」なくして気づくことはできなかったです。

体感を通じて発見した主要な課題と設計上の教訓

体感的な検証を通じて明らかになり、修正あるいは将来的な課題として認識された主なポイントは以下の通りです。

  • ユーザビリティ(レイアウトの安定性)
    • 再生中にプログレスバーが表示されることによるレイアウトの微妙なズレを特定
    • これは会場での操作ミスという深刻なリスクに繋がる
    • 操作の一貫性(ユーザビリティの原則)を担保するために、厳密な修正が必要だと認識
  • 音響体験(品質)
    • 音源の急な停止がユーザー体験に与える違和感を確認
    • リアルな音響体験を追求するため、フェードアウト/フェードイン処理が必須となった
  • 機能の実現可能性とスコープ
    • ループに適した音源の調整が難しいという現実的な課題を発見
    • 当初の要件であったループ機能を削除し、機能のスコープを現実的に絞り込む

フィッツの法則と高負荷環境での操作難易度

また、実際にアプリを使ってみた結果、いくつかの課題が判明しました。
音量調節機能が必要なことや、マウスカーソルでの押しにくさです。
つまり、咄嗟の操作のしづらさが否めなかったのです。

最初はPCとモバイルどちらからもアクセスできることを想定していたため、マウスカーソル操作とタップ操作の違いを意識できていませんでした。
もともとフィッツの法則[3]を意識していましたが、ボタンの大きさがタイミングが重要になる機能においては無視できない要件だと、操作してみて改めて気づきました。

※今、記事を書いている最中に、キーボードで操作できるようにすればよかったかもと感じています笑

Figma Makeが実現するアイデア検証

検証サイクルの成功体験と応用範囲

Figma Makeは、主観的な視点を起点に、「試作↔操作↔考察」の検証サイクルを格段にスムーズに加速させました。
これにより、プロトタイピングは専門的な作業ではなく、ちょっとしたアイデアを試す日常的な手段として、多様な場面で活用可能になります。

また、Make Kitsという機能も開発されていると情報を知りました。

Make Kitsと呼ばれる予定の機能で、Figmaデザインで構築されたコンポーネントやスタイル、バリアブルズのライブラリをFigma Makeにインポートすることができるようになります。これにより、FIgma Makeでつくるプロトタイプをより自社の製品のブランドやデザインに一貫したものを作成することができるようになります。

https://note.com/hilokit/n/nef9b1ea7160d#b182a156-bb29-4dab-9a7d-64a3cc88f68d:~:text=Make Kitsと呼ばれる予定の機能で、Figmaデザインで構築されたコンポーネントやスタイル、バリアブルズのライブラリをFigma Makeにインポートすることができるようになります。これにより、FIgma Makeでつくるプロトタイプをより自社の製品のブランドやデザインに一貫したものを作成することができるようになります。

これが実現すると、Figma DesignのコンポーネントライブラリをFigma Makeにインポートできるようになり、一貫したデザインのプロトタイプを作成することができるかもしれません。

それは、検証後のプロトタイプを本番プロダクトへスムーズに移行することもできるのではないかと、期待しています。

結果として、検証後のプロトタイプをそのフェーズで終了させずに、そのまま詳細設計や開発へとシームレスに移行でき、DesignOpsにおいて早期のデザイン・開発連携という高い価値を生み出すと予想されます。

ドラムロールアプリは笑顔にできたのか

このドラムロールアプリは実際にレクリエーションの場で利用しました。
Figma Makeは公開機能があるので、検証したアプリを公開し、そのまま利用できます。[4]
実際にレクリエーションの場で利用してみて、操作もうまくいき、会場の雰囲気もとてもよく進行することができました💡

実際に音を再生してみた様子はこの動画から確認できます。

https://drive.google.com/file/d/1VsyVOIuLlt7L12J00sWr7ys9s8OV-B1i/view?usp=drive_link

💡 → 😭 → 🤔 → ✍ → ❤️ → 🥁 + 🥳

Figma Makeを活用することで、技術的な学習コストを心配することなく、様々なアイデアの実現可能性を素早く検証できることがわかりました。
対話形式で仕様を詰め、動作するUIでフィードバックを得るプロセスは、とても優れた検証手法です。
今回は私一人での検証サイクルを実施しましたが、場合によっては誰かに操作してもらい、フィードバックをしてもらうのもいいでしょう。

ぜひ、みなさんもチャレンジしてみてください💡
ちょっとしたアイデアや工夫をFigma Makeにポンと投げて試してみてください。
そして、そのアイデアを形にする方法を探求することで、身近な人の時間を少しでも豊かにできないか、模索してみてください。

参考

参考になりました🙇‍♂️

https://zenn.dev/sunagaku/articles/6ffe29e6f271bb

脚注
  1. 参考:Figmaのプロトタイピングのガイド ↩︎

  2. Simple Design SystemはFigmaが提供しているデザインシステムです。 ↩︎

  3. 参考:フィッツの法則と、UXにおけるその応用 – U-Site ↩︎

  4. 実際のレクリエーションでは自由に利用できる音源をネットから探しました。その音源は配布を禁止とされていたので、公開しているドラムロールアプリにはお手元の音源データをアップしてお試しください。 ↩︎

GitHubで編集を提案

Discussion