プロのイベントレポーター（のロールを与えられた）ChatGPT氏に、イベント録画の文字起こしを使って開催内容をまとめてもらいました！
1. イベント概要
- イベントページ:
- 日時:
- 2025/11/29(土) 13:30-17:00
- 主なテーマ:
- 音声解析系Webアプリの現状共有と技術課題の棚卸し
- Firebase Authentication を使った認証機能の導入検討
2. ざっくりまとめ
第1回の勉強会では、音声解析系のWebアプリを題材に、「今どんな構成で動いているのか」「事業化を見据えると何が必要になるのか」を、参加者みんなでわいわい話しながら整理しました。
その中で、まず手を付けるべきは「認証・アカウント管理」だよね、という共通認識ができ、すでに利用しているFirebaseと相性の良い Firebase Authentication を採用する方針に決定。実際にコンソール設定やフロントへの組み込みも触りながら進めました。今後の課題として、課金設計やインフラ構成、UX改善などを整理しました。
3. 詳細トピック
3-1. セッション全体の流れ
- 「みんなで同じテーマをゆるく、 楽しく、手を動して、一緒に進める！」という技術勉強会の第1回。
- 対象は、開発中の音声解析系Webアプリ。
- まずはアプリの現状と課題を軽く共有しつつ、
- どこから手を付けるか？
- 何をこの勉強会の「題材」にしていくか？
を話し合い、 「まずは認証まわり（Firebase Authentication）から進めていこう」
という方向でまとまりました。
3-2. アーキテクチャと技術スタックの整理
フロントエンド
- Firebase Hosting 上で動く静的Webサイト。
- 技術スタックは HTML / CSS / 素の JavaScript（バニラJS）。
フレームワークなしのシンプル構成です。
バックエンド
ざっくり構成イメージ
ユーザー
→ ブラウザ（PC / スマホのWeb）
→ Firebase Hosting（静的サイト）
→ Render 上のAPIサーバー（音声解析処理）
大きくはこうした「フロント（Firebase）＋API（Render）」の構成で動いていることを、参加者同士で確認しました。
3-3. 現状の技術課題（みんなで出した論点）
話し合いの中で出てきた、主な技術的な課題は次の4つでした。
ログイン機能がまだない
- いずれ事業化を考えると、
- ユーザーごとの利用状況
- 課金状態
をしっかり区別して扱いたいよね、という話に。
- 現状は「誰が使っているか」をあまり意識せず動いているため、
まずは認証・アカウント管理の土台が必要だと整理されました。
- いずれ事業化を考えると、
課金の仕組みをどう設計するか
- アイデアベースでは、
- 「月◯回までは無料、それ以降は従量課金」
- 「ライト／ベーシック／プロ」などのプラン制
といった方向が挙がりました。
- いずれにしても、ユーザーを特定する認証が前提になるため、
課金の細かい話に行く前に、まずはログイン機能から…という流れになりました。
- アイデアベースでは、
インフラコストの高まり
- 音声モデルが少しずつ重くなってきており、
- Render の無料枠や安価プランのままでは厳しくなってきたかも？
という感触が共有されました。
- Render の無料枠や安価プランのままでは厳しくなってきたかも？
- モデルをどこに置くか、どのクラウドを使うかなど、
インフラ構成を見直す余地がありそうだね、という認識です。
- 音声モデルが少しずつ重くなってきており、
レスポンスの“体感速度”をどう上げるか
- チャットボットや音声解析のような非同期処理の場合、
- 実際の処理時間そのもの だけでなく、
- 「待たされている感」を減らすUI
がとても大事だよね、という話になりました。
- ローディング表示やプログレスバー、ストリーミング表示など、
フロント側でできる工夫も、今後一緒に試していくテーマとして挙がりました。
- チャットボットや音声解析のような非同期処理の場合、
3-4. なぜ Firebase Authentication に決めたのか
技術的な優先順位を整理した結果、次のようなポイントで意見が揃いました。
- 事業化を意識すると、
- 認証
- 課金
- ユーザーごとのデータ管理
はどうしても必要になる。
- すでにFirebase Hostingを利用している。
- Firebaseには、認証基盤として Firebase Authentication が用意されている。
そこで、
「自前でログイン機能を一から作るより、まずはFirebase Authでサクッと土台を作ろう」
という方針に決定しました。
また、開発の進め方についても軽く整理し、
- 認証機能の実装は 別ブランチ で進める
- うまくいかなければ、そのブランチごと破棄できるようにしておく
- 本番に出せる品質になったら main にマージする
といった、比較的安全で試しやすい進め方を取ることになりました。
3-5. 当日やってみたこと（Auth 周りの実装）
セッションの中で実際に手を動かしながら進めた内容を、技術的なステップでまとめると以下の通りです。
Firebaseコンソールで Authentication を有効化
- 対象のFirebaseプロジェクトを開き、Authentication を有効化。
- ログイン方法として、
- メール＋パスワード
- Googleアカウント
を使う方向で設定を進めました。
メールテンプレートの設定
- サインアップ時などに送られる確認メールの文面を日本語化。
- テンプレートの言語設定（
ja/enなど）を切り替え。 - 将来的には、サポート用メールアドレスなども含めて整えていきたいよね、という話も出ました。
Firebase Config を取得してフロントに組み込み
- Firebaseコンソールの「プロジェクト設定 → Webアプリ」から、
apiKeyauthDomainprojectId
などを含むfirebaseConfigを取得。
- それを
firebase-config.jsのようなJSファイルに記述し、
バニラJSで書かれたフロントエンドから初期化するように実装しました。
- Firebaseコンソールの「プロジェクト設定 → Webアプリ」から、
ログイン画面まわりの実装
よくあるエラーとその場でのデバッグ
3-6. 今後の技術課題ポイント整理
最後に、「これから一緒にやっていけそうだね」と整理されたタスクたちです。
認証まわり
- Firebase Auth を使った、
- メール認証
- Googleログイン
を安定稼働させる。
- 認証したユーザーと、アプリ内のデータ（解析結果など）を
どのように紐づけるか、データモデルを設計する。
課金まわり
- 月額課金・従量課金・プラン制などの候補をもう少し整理。
- Web上で完結させるか、外部の決済サービスを使うかなど、実装方針を検討。
- 認証情報と課金ステータスをどう連携させるか設計する。
インフラ最適化
- モデルをどこに置くのが良いか（Render / 他クラウド / ストレージ活用など）を検討。
- コストとレイテンシのバランスを見つつ、インフラ構成を見直していく。
UX改善
- 処理中表示（スピナー、プログレスバーなど）の導入。
- ストリーミング表示や段階的レスポンスなど、体感速度を上げる工夫の検討。
- 「ちゃんとリアルタイムで反応してくれている感」を出すフロント実装を試していく。
4. 質疑応答（Q&A）
今回は、はっきりと区切られたQ&Aセッションというよりは、
話しながらその場で質問・相談していくスタイルで進行しました。
「Firebaseってこういうときどうするの？」「このエラー見たことある？」といった、
実務寄りのちょっとした疑問も、その場で画面を見ながら一緒に解消していくような雰囲気でした。
5. ネクストアクション / まとめ
このあとやっていくこと（予定）
- Firebase Authentication を使ったメール／Googleログインの安定化。
- 認証済みユーザーとアプリ内データを紐づけるデータ設計。
- 課金方式の候補出しと、技術的にどう実現していくかの検討。
- モデル配置やインフラ構成の再検討、およびざっくりコスト試算。
- 処理待ち時間を少しでも短く“感じてもらう”ためのUIプロトタイプ作成。
まとめ＆次回に向けて
第1回は、「どんなアプリなのか」「どこに技術的な伸びしろがあるのか」を
みんなで共有しつつ、最初の一歩として 認証基盤づくり に取り組み始めた回になりました。
コードを一緒に眺めながら、「ここどう書く？」「このサービス使えるかも？」と
相談できる、わりとゆるめの雰囲気の勉強会です。
ぜひ気軽に参加してみてください！
