はじめに
Brazeのソリューション・アーキテクトの田口です。
去る11月に行われた「Braze City x City Tokyo 2025」では、来場者体験の向上と展示ブースへの誘導を目的に、イベント専用のモバイルアプリを内製しました。
この記事では、来年以降また同様のアプリを内製する場合に備え、振り返りとして、
- なぜアプリを作ることにしたのか
- 設計・実装で何を考えたか
- 実際にやってみてわかったこと
を整理します。
今回のアプリの開発・テストにあたっては社内外の多くの方にご協力いただきました。他社でもイベント向けアプリの内製を検討している方の参考になれば幸いです。
背景と要件
City x Cityでは、講演セッションだけでなく、協賛パートナー各社やBrazeの展示ブースにももっと足を運んでもらいたい、という課題がありました。
その解決策として浮上したのがスタンプラリーです。ブース訪問を促す仕掛けとして相性が良く、既存のスタンプラリーサービスを契約する案も検討しました。
一方で、BrazeはモバイルアプリSDKを提供しています。「せっかくならBrazeを組み込んだアプリを作り、来場者にBrazeの体験そのものを届けよう」という方針になりました。
また、2年前のCity x City向けに、Brazeの体験に焦点を当てたアプリをリリースしていたこともあり、これを土台にバイブコーディングでスタンプラリー機能の追加や改修すれば、工数を抑えながら開発できるのでは、という見立てもありました。
アプリの開発は、私ともう一人の同僚ソリューション・アーキテクトの伊藤の2名で行ないました。
ログイン機能を実装するか
設計段階で最も悩み議論したのがこの点です。
Brazeのパーソナライズされたメッセージ配信を体験してもらうなら、本来はログインを実装し、来場者のプロフィールに応じた配信を行うのが理想となります。
しかし、来場者が参加登録しているイベントサイト側の認証基盤を、アプリから利用できないことが判明。独自にログイン機構を用意する手段もありましたが、その場合にはユーザーにとってイベントサイトとアプリ用で二つのログインID・パスワードを作っていただく必要が出てくるため、ユーザー体験が悪くなるだろうと判断、今回はログインなしのシンプルな構成を選択しました。
技術スタックと開発アプローチ
今回のアプリでは、2年前の実装を踏襲し、Flutterを採用しました。
Flutterの利用により、iOS/Androidの両OSを同一コードベースで開発でき、両アプリを同時にビルドできました。イベントアプリという「締切が絶対に動かない」前提において、開発・調整の対象を分散させずに済むのは大きなメリットだと思います。Flutterアプリに対するBrazeの導入事例も多く、SDK組み込みに関する知見もありました。
バイブコーディングにはClaude Codeを利用しました。2年前のコードを土台にバイブコーディングで手を入れていくアプローチは、各種ライブラリの最新化やリファクタリングや無駄な機能を削るという作業においてかなり機能しました。また、スタンプラリー機能も簡単に作れました。一方で、UI周りの細かい調整は意外とスムーズにできず、実機検証と細かい指示出しや手作業での修正が必要になりました。
完成したアプリの紹介
完成したアプリはApp StoreおよびGoogle Playで公開しています。
https://onelink.to/dncwub
イベント自体は終了しているため、プッシュ通知の配信は行っていません。ただし、以下のBrazeチャネルは今でも体験できる状態になっていますので、ぜひご覧ください！
アプリ内メッセージ
Specialタブ内の「ブース連動企画」- ボタンを押すと、Brazeのアプリ内メッセージとして作った様々なポップアップのサンプルが表示できます。
コンテンツカード
Specialタブ内の「コピグラ受賞作品展示」 - 柿野さんの「応募作品 2500超！#残念なお知らせをなくす 改善コピープロジェクトの実際」という記事で紹介されたコピグラの優秀賞の画像をコンテンツカードの標準フィードで表示しています。優秀賞が決まるのがイベント直前ということだったため、アプリリース後に差し替えができるようにコンテンツカードでの実装を行いました。
Banners
UseCaseタブ内のカルーセルバナーの箇所の画像の差し替えと、Specialタブの最下部のBraze14日間無料のフリートライアルのコンテンツはBannersで表示しています。
この機能は私が先日投稿した「今年登場したBraze Banners（バナー）機能」に詳しく書いてますので、よろしければそちらもご参照ください。
開発スケジュールと実績
ここから先は今回のアプリの実装における具体的な話とその学び・反省点を整理します。
アプリの開発は8月の初めから着手しました。当初の計画では11月中旬のCity x Cityイベント本番に向けて、大きく以下のようなマイルストーンを置いて作業を進めました。
| マイルストーン | 予定 | 実績 |
|---|---|---|
| βリリース（社内限定、TestFlight / Firebase App Distribution） | 9/1 | 9/1 |
| ストアへの一般公開版リリース | 9/30 | iOS: 11/4 / Android: 11/7 |
| 本番稼働版アプリリリース | 10/30 | 11/7 |
| イベント本番 | 11/13 | 11/13 |
βリリースは予定通りでしたが、ストアへの一般公開が大幅に遅れました。主な要因は、協賛各社のロゴ利用許諾の確認に時間がかかったこと、およびGoogle Playのクローズドテスト要件が途中で判明したことです。詳細は次のセクションで説明します。
苦労した点・想定外だった点
UIの細かい調整
端末によってはボタンの文字が見切れる、ヘッダー部分のロゴとテキストが重なってしまう、など機種依存のUI崩れが想定以上に発生しました。
また特にタブレットへの対応はしていなかったものの、AppStoreへのリリース時の審査でiPadでみた時にボタンの表示が見切れるという理由でリジェクトされ、対応しました。
社内外の方にさまざまな端末で動作確認をしていただき良かったのですが、作業上は割とモグラ叩き状態になってしまい、見つけ次第細かい指示出しで解消するか、その部分は手作業でコーディングするかで対処していました。
この点は、Flutterのベストプラクティスに沿ったUI実装をClaude Codeにメタプロンプトとして読み込ませるなどの対応や、今後のモデル自体の発展とともに改善されていくものだと考えております。
ロゴ利用の許諾
スポンサーロゴやスタンプラリーに表示する協賛各社のロゴ掲載にあたり、各社に表示を最終確認していただく必要がありました。全社の許諾が確認できるまで時間がかかり、最終的に揃ったのは10月末でした。
許諾が揃うまでは一般公開リリースを保留して欲しいというリクエストを受け、ストアリリース作業自体を順延してしまいました。振り返ると、ストアリリース作業は先に進めてしまい、公開だけ止めておくようにしておけば良かったのですが、それほど許諾に時間がかかるとは想定しておらず、一旦作業を止めてしまいました。
Android版リリースの想定外ルール
10/17にストアリリース作業を始めた段階で、Google Playでは「クローズドベータテストを12人以上で14日間継続しないと本番リリースできない」という要件があることが判明しました。
参考：
AndroidはiOSの審査よりも緩いという話を聞いていたため、完全に盲点でした。
さらに、社内のAndroidユーザーだけでは12人に満たず、社外の方にも呼びかけてなんとか人数を確保しました。ご協力いただいた皆さまには感謝しています。結果的にクローズドベータテストを10/21〜11/4の期間で行い、終わったら即、製品版リリース利用申請→アプリリリース申請を行ない、イベント前週の金曜日になんとかリリースできました。最後まで気が抜けない状況でした。
法人の開発者アカウントを作成すればこの要件は回避できた可能性もあります。ただ、今回は業務の片手間でアプリを作っていたこともあり、社内申請手続きなどに時間を割けないだろうという点も考慮し、2年前と同様に個人の開発者アカウントでリリースを進めていました。
やってよかった点
この記事は振り返りのものなので、反省点の方の文章のボリュームが便宜上多くなってしまっていますが、個人的には楽しかったですし、全般的にはやって良かったです。
900名超の来場者に対して、イベント終了直後のアプリのダウンロード総数は345でした（iOS: 300、Android: 45）。来場者のうち約3分の1の方がアプリをダウンロードしてくださったことになります。展示ブース訪問の促進にも一定の効果があり、良い評判もいただきました。
今年はBrazeブースの説明も、私の所属するオンボーディングチームで担当していたのですが、Brazeブース連動企画として、単なる機能の「説明」ではなく「体験」として提供できたのではないかと考えております。
イベントの目玉セッションである成田先生の講演の前や、ネットワーキングパーティーの前にアプリのプッシュ通知で案内を出すことも実施していました。今回、実際には活用する機会がなかったのですが、講演セッションが大幅に遅れた場合には遅延をお知らせすることや、予定の案内のタイミングをずらしたりする体制も考えておりました。Braze上での施策設定やテストもしっかりできていた点も非常に良かったと思っております。この点はオンボーディングチームの皆さんにもかなりご協力いただきました。
反省点と次回への示唆
スケジュールに余裕がなかった
リリースできなければ、どれだけ良い体験でも意味がありません。Google Playのクローズドテスト必須要件が想定外だったとはいえ、アプリリリースにはトラブルがつきものであることを考えると、なるべく早くリリースまで漕ぎ着けることを目標に進めるべきでした。
タスクの組み方としては、例えば、スポンサーロゴなしの暫定版を先にリリースし、後からアップデートで差し替えるというような進め方が現実的だったと思います。技術的には、ベータ版の段階からFirebase App Distributionではなく、Google Playの方で行なっていれば、リリースがイベント本番直前になるということを回避できたと思います。
Brazeの機能体験にはもう一歩踏み込めた余地があった
ログインなしのアプリでも、たとえばアプリ内アンケートで業種や興味関心を取得し、その方に合った導入事例や記事をパーソナライズして配信する、といった施策は実現できたと思います。
また、Landing Pagesを利用した参加後のアンケート配信なども実現できたかもしれません。今回はアプリのリリースに直前まで対応が必要になり、手が回りませんでした。次回検討したいポイントです。
位置情報の許諾率が想定よりも低かった
今回、Geofenceを使ったメッセージ配信も準備していました。会場周辺への入退場をトリガーにメッセージを届ける、イベント向きの施策です。
それなりに開発・テスト工数をかけたものの、位置情報の取得を「常に許可」まで設定してくれたユーザーが想定より少なく、Geofenceで設定した会場から帰宅時にプッシュ通知される「Thank you」メッセージが配信されたのはアプリインストール数の約10%に留まりました。
技術的には正しく動作していましたが、もし次回以降もやるのであれば、実際にもっと多くの人に体験いただけるように位置情報の許諾を促す工夫を入れるか、あるいは思い切ってこちらはやらずに前述の別のBrazeの機能体験に工数を割いた方が効果的だったかもしれません。
イベント向けアプリは内製するべき？
最後に、今回の経験をもとに、我々Brazeのような企業が自社イベント・カンファレンス向けのアプリを内製するという観点から教訓を整理したいと思います。
内製は現実的な選択肢になった
バイブコーディングの登場により、片手間でイベントアプリを作ることはかなり現実的になりました。ただし、アプリ開発経験がない場合、環境構築やストアリリースの知見がないと厳しい場面が出てきます。ゼロから始めるなら、それなりの工数を見込んでおく必要があります。
チームにアプリ開発経験者がいれば問題ありませんが、いない場合はWebアプリやPWAでの代替も検討すべきでしょう。
スケジュールには余裕を持つ
アプリリリースには想定外のトラブルがつきものです。今回はロゴの許諾やGoogle Playのクローズドテスト要件で遅延が発生しました。それほど大きな問題ではなかったのですが、iOSのAppStoreへのリリース時の審査においても2回リジェクトされて対応しました（位置情報許諾の訴求の仕方と、iPadでの表示の問題）
教訓として、なるべく早く一般公開リリースまで漕ぎ着け、そこからブラッシュアップしていく進め方が望ましいです。暫定版を先にリリースし、後からアップデートで差し替えるというアプローチが有効だと思います。
Google Playのクローズドテスト要件に注意
個人の開発者アカウントでAndroidアプリをリリースする場合、クローズドベータテストを12人以上で14日間継続する必要があります。この要件を知らずにスケジュールを組むと、今回のようにイベント直前まで気が抜けない状況になりかねません。法人アカウントの利用や、早期からのGoogle Playでのテスト実施をお勧めします。