プロジェクト概要

在籍企業で担当した、エンタープライズ向けの音声文字起こし・翻訳アプリの開発事例です。会議や接客、商談などのビジネスシーンで、音声をリアルタイムに文字起こしし、4 言語間で翻訳し、終了後に生成 AI で要約する、というユースケースを念頭に設計されています。

一般のアプリストアでは配信されておらず、エンタープライズ契約を結んだ組織に対して MDM（Mobile Device Management）経由で配布される仕組み。本ケーススタディでは、固有情報（顧客名・業務固有のロジック・組織名）を伏せ、技術選定とアーキテクチャ判断に絞って記載しています。

技術的な難所

業務プロダクトとして耐えうる品質と運用性を実現するために、以下のハードルがありました：

• リアルタイムストリーミング音声文字起こし：低遅延で結果を画面に反映し続ける必要があり、ネットワーク不安定時のリトライ・部分結果の表示など堅牢性が求められる
• クラウド API キーをクライアントに置かない設計：エンタープライズ用途として、APIキー漏洩・不正利用のリスクをアーキテクチャレベルで排除する必要があった
• 生成 AI による要約処理：応答時間とコストを両立できるモデル選定と、安定した出力フォーマットを得るためのプロンプト設計
• 組織単位での機能配布：管理者が組織ごとに「使える言語」「ライセンス」「デフォルトモード」などを設定できる仕組み
• クロスプラットフォーム展開：同一仕様を Android (Kotlin) と iOS (Swift) のネイティブ実装で揃える
• 多言語対応：日英中韓の 4 言語間で、音声認識・翻訳・UI のすべてを整合させる

主要な技術判断

1. クロスプラットフォーム fw ではなく、両プラットフォームともネイティブで実装

本案件でも、Android (Kotlin) / iOS (Swift) のネイティブ実装を選択しました。理由は、マイク入力のリアルタイム性、OS 標準の音声 API（AVAudioEngine、AudioRecord）の挙動の細部、エンタープライズ配布で要求される MDM 連携など、OS ネイティブの機能に深く触れる場面が多く、抽象化レイヤーを挟むことの不利益が大きかったためです。

2. クラウド API はクライアント直接呼び出しではなく、Firebase Functions 経由

Google Cloud Speech-to-Text、Cloud Translation、Vertex AI（Gemini Flash）といったクラウドサービスをクライアントから直接呼ばず、Firebase Functions を中継サーバーとして挟む構成を採用しました。

この設計の意図：

• API キー・サービスアカウントをクライアントに埋め込まない — アプリのバイナリをリバースエンジニアリングされても認証情報が漏れない
• 短命トークンでクライアント認証 — Functions 側でアクセス制御・期限管理
• レート制限・コスト制御を集約 — 組織ごとの使用量管理が容易
• API の差し替え・モデル更新が中央集権 — クライアントを再リリースせずに切替可能

エンタープライズ用途では「API キーがバレないこと」がほぼ前提条件になるため、この構成は必然でした。

3. 要約モデルに Gemini Flash を採用、構造化出力で安定化

会話終了後の要約処理には、Gemini Pro ではなく Flash を選択しました。理由は応答時間とコストのバランス。要約という用途では Flash で十分な品質が出るうえ、レイテンシが Pro より大幅に短いため、UX として「終了ボタンを押してから数秒で要約が出る」という体感を実現できました。

また、要約結果が画面 UI に安定して流し込めるよう、構造化出力（JSON スキーマ指定）のプロンプト設計を採用。LLM 出力の揺らぎを抑え、パース失敗時のフォールバックも実装することで、運用上のクラッシュリスクを低減しました。

4. MDM / Managed App Configuration による組織単位の機能ゲーティング

エンタープライズ向けに不可欠な「組織単位での設定配布」を、Apple の Managed App Configuration / Android の Managed Configurations を活用して実装しました。

これにより、IT 管理者が MDM ツール（Intune、Jamf、Workspace ONE など）から、以下のような設定を組織ごとに配布できます：

• ライセンスキー・組織 ID
• 利用可能な言語の制限
• デフォルトの動作モード
• クラウドサービスのエンドポイント切り替え（ステージング／本番）

アプリ側はこれらの値を読み取って動作を変えるだけで、コードのリリースなしに組織単位での挙動カスタマイズが可能。エンタープライズ向けプロダクトの典型的なパターンですが、両プラットフォームで仕様を揃えて実装した経験は強い裏付けになります。

クロスプラットフォーム展開

Android と iOS の両プラットフォームで同一仕様を提供するため、設計段階から両プラットフォームを並行検討。データモデル、Firebase Functions のインターフェース、MDM 設定スキーマなど共通化できる部分は徹底的に揃え、プラットフォーム固有の差異（音声 API・MDM API の挙動）はクライアント側に閉じる構成にしました。

これにより、新機能を追加する際にも「Functions 側のロジック1本＋両クライアントで同じ実装」のパターンで開発が回り、機能追加コストを抑えられました。

結果

• Android / iOS の両プラットフォームでリリース・運用フェーズに到達
• 日英中韓 4 言語の音声認識・翻訳・UI を実装
• ストリーミング文字起こしと翻訳の同時提供
• Gemini Flash による低遅延の要約機能を実装
• MDM 経由の組織別設定配布に対応
• クライアントにクラウド API キーを持たないセキュアなアーキテクチャ